Automagical JavaFX2 Beans

FX Serials allows your traditional Java Beans to play in the new JavaFX scene.

Why?

JavaFX 2.0 introduced the JavaFX Beans specification that adds properties support to Java objects through the help of the properties classes from the JavaFX 2.0 properties and bindings framework. This allows the JavaFX GUI to bind its controls with the data model without the need for extra binding frameworks.
Although properties support has been long awaited in Java, the adoption of the new JavaFX2 Beans by enterprise application developers faces two challenges:

1. For new applications, there is the questionable need for binding or observing a property on the server side, together with the additional dependencies and performance overhead needed to handle the extended domain model (see James Denvir's One Bean to Bind Them All post);
2. For existing applications, there is the need to re-code the domain model in order to accommodate the new specification.

On the one hand, It would help the decision for new applications if there were some successful case studies. And on the other hand, facilitating the move for existing applications would help create some of those case studies.

How about a solution where you have traditional java beans on the server side which are "automagically" transformed into JavaFX2 Beans on the client side? - The concerns in 1 would be mute and there would be no need to re-code the domain model. Cool!

I implemented a first approach to this solution in my latest project: FXSerials. I hope you find it cool too :)

Version 1.0.1 is out and you can add it as a maven dependency with the following coordinates:

<groupid>io.github.juffrou</groupid>

<artifactid>fx-serials</artifactid>

<version>1.0.1</version>

This is still early stages but you can already proxy a class and a bean instance.

Please see the examples at the FXSerials page and check out the source code on Github.
Don't hesitate to drop me a line if you have a question or a suggestion about FXSerials.

JavaFX2 Message Broker Client For The Rest Of Us

Developers of systems for Enterprise Integration often need to interact with a message broker in order to view messages or send messages to queues or topics. The problem is, a client application which does that is not always readily available.

Now there is one!

You can now use the MQConsole client application (at least for Apache ActiveMQ and HornetQ). MQConsole is an open source application that I started to develop using a maven multi-module project. Each broker support in developed as a maven module and shares the same user interface with the others. The source code is available on Github (here) and the binary distributions for Windows and Mac are available on Bintray (here).

main window - broker destinations

The main window shows a table with information about the queues and topics found in the message broker. There are a number of actions available if you right-click on any queue or topic:

• See the list of messages in a queue or topic
• View the details of a specific message
• Send a new message to a queue or topic
• Subscribe to a queue or topic and display messages as they arrive there.

send a new message window

When sending a new message, you can opt for a request/response scheme by ticking the "Has Response" box. In this case, the application will wait for a response and displays the reply message in the "Response" tab.

Window displaying a received message

When you subscribe to a channel or topic in the main window, a window displaying one message pops up every time a new message arrives.

This window can also be opened to view the details of a message in a message list.

The message details displayed are the message headers and its payload as long as its non binary.

Please download from Bintray and see the Github site to create an issue with your improvement suggestions

Requires Java 8 update 20 or a newer version.

JavaFX2 Websocket Client Deployed by Webstart JNLP

This post builds on the previous Websockets with Spring Framework 3.x and answers 2 questions:

1. How to use webstart-maven-plugin to pack a JavaFX 2 client in a web application and launch it using Java Web Start (JNLP)
2. How to use Tyrus, a java websocket client implementation, for client server websocket communication

The source code referenced here is part of a fully functioning application which can be downloaded and tested from the websocket-test repository at Github. Please read the README file there for pre-requisites and instructions on building and testing.

Project structure:

Maven project called websocket-test (packaging: pom) with two modules:

1. websocket-client - JavaFX 2 application (packaging: jar) 
2. websocket-server - Spring framework web application  (packaging: war)

Project packaging

The websocket-server module is packed with the depicted structure. The webstart folder contains the jar file generated by the websocket-client module and it's transient dependency jars. It also contains the websocket-client.jnlp descriptor file

I - Using webstart-maven-plugin to pack a JavaFX 2 client in a web application and launch it using Java Web Start (JNLP)

On the websocket-server module, configure the webstart-maven-plugin as follows:

Notice the build timestamp passed to the JNLP file. this will allow java web start to detect wether a cached application needs to be refreshed.
The details pertaining to the user certificate in the <sign> section are defined in the maven settings.xml file, so they remain private.

You must also provide a velocity template for the JNLP file, like the following:

This template contains variables. Some of them will be substituted at build time (ex: ${buildTS}) and some will be substituted by the JnlpDownloadServlet at download time (Ex: $$context)

Notice the parameter definition on line 28 (<fx:param name="server-url" value="$$context"/>). This will be passed to the JavaFX2 application and will tell it where to connect the client websocket.

II - Using Tyrus for client server websocket communication

Tyrus is the websocket reference implementation in java therefore it made sense to build this test project using Tyrus, although any other implementation could be used.

The application is going to establish a websocket connection to the server and the address of the server is calculated based on the value of the server-url parameter in the JNLP file:

Starting the Tyrus client manager will create a separate process with several execution threads to control communication between the client and the server. We need to tell the application that the security permissions bestowed by the java web start configuration are needed to launch the Tyrus client, otherwise an "access denied" exception will be thrown. We do this by starting the Tyrus client in a privileged block:

Please download the source code for all the details (git clone https://github.com/cemartins/websocket-test.git) and leave a comment here or raise an issue at Github if you have any thoughts or suggestions you'd like to share.

Where is Java on OS X?

Up to Mountain Lion (10.8) both JDK and JRE were supplied by Apple and installed in

/System/Library/Frameworks/JavaVM.framework/Versions

Since Mavericks (10.9) the JDK is supplied by Oracle and installed in

/Library/Java/JavaVirtualMachines

The JRE is installed through Apple software update in

/Library/Internet Plug-Ins/JavaAppletPlugin.plugin

Websockets with Spring Framework 3.x

Spring introduced support for WebSocket-style messaging in version 4.0, but how about spring 3.x?
- Can applications using spring framework 3.x have websocket endpoints integrated with spring's application context?

- Yes, they can.

I developed a small proof-of-concept application to demonstrate this.

This application sets up a websocket server endpoint with uri `/wstest` which will use a `@Autowired` spring bean to select a greeting word and reply to a websocket message.
The websocket connection is initiated and messages sent by an html page (`index.html`) running in a browser that supports websockets.

The Servlet container's scan for WebSocket endpoints is avoided by not using the `@ServerEndpoint` annotation and instead implementing a ServerEndpointConfig and adding it to the server container upon servlet context initialization.
This way, the endpoint instance will be provided by SpringConfigurator, which means it can itself be a spring bean and/or it can have spring dependencies automatically injected with the `@Autowired` annotation.

Checkout the full source and ready to run example on my Github page.

You can run the webapp with jetty executing the maven command `mvn jetty:run`

• start your browser and access the url `http://localhost:8080/websocket-test/index.html`
• type a message, press the button "Send" and see the response message.

You can also deploy and run websocket-test in WildFly 8:

• add `websocket-test.war` to `WILDFLY_HOME/standalone/deployments
• start WildFly 8
• start your browser and access the url `http://localhost:8080/websocket-test/index.html`
• type a message, press the button "Send" and see the response message.

Now this is nice!! The new BMW S1000F for 2015

Messaging Setup using spring on wildfly and hornetq

WildFly 8 is almost final and I bet some people are wanting to upgrade from JBoss. That is our case here at my job and our new setup is like this:

We have App 1 (spring-integration app) running on wildfly 1 and App 2 (spring server app) running on wildfly 2. Both wildfly are standalone instances.

App 2 publishes messages to its wildfly embedded hornetq broker.

App 1 listens to messages published on the hornetq at wildfly 2 using a durable subscription and the remote connection defined in wildfly 1.

First lets look at App 2.

• application-2-context.xml is the snippet of a spring application-context that configures a JmsTemplate to send messages to the hornetq topic.
• Standalone2.xml is the messaging-subsystem part of the wildfly 2 server configuration file:

I added a JMS Topic, disabled security for connections to the embedded hornetq broker and allow Gests to create durable queues. See the inline comments.

Now lets look at App 1.
In node 1, the wildfly server configuration file is partially displayed here in two separate files:

• socket-binding@standalone1.xml shows the socket binding part of the wildfly configuration and the definition of the socket used to connect to the hornetq broker in Node 2.
• messaging@standalone1.xml shows the messaging subsystem - defines the netty connector "netty-node2" and the pooled connection factory that facilitates the durable subscriptions to the EventsTopic on Node 2 - note the client-id definition.
• application-1-context.xml is the snippet of a spring-integration application-context that configures the necessary beans to direct the messages published to EventsTopic ti a specific message channel.

Howdy Fellas

Here I go again venturing into the blogosphere... But this time, I promised myself that I will try to be a bit more "vocal" about the pursued subjects - mostly IT stuff (for a change).

I decided to write in English (even though I am Portuguese) because the subject is mostly IT stuff and I do not like to translate IT terms - It tends to get confusing. So, all you "natives", please accept my apologies for the "Pinglish" hacks every now and again. I will do my best not to be too upsetting.

I decided to start this blog because I think I might have something useful to share - More than 20 years working on IT, makes me sort of a dinosaur so... well I might have something useful to share and I sure as hell can use a memory jolt every now and again :)

VI shortcuts and tips

Goto end of document: SHIFT-g
Goto begining of document 1-SHIFT-g or :0
Goto end of line: $
Goto begining of line: 0
Insert line before current: SHIFT-o
Insert line after current: o
Join with next line: SHIFT-j
Search forward: /
Search backwards: ?

getting rid of ^M: :%s/CTRL-V CTRL-M//g (This will replace all carriage return characters with nothing as they are only needed in windows text editors.)

Many tanks to my friend Batalha - a true living VI encyclopedia!

Remote shell access

This example explains how to use the back channel scheme to remotely access another linux shell and thus fix a problem on the remote user's system. An Admin person will help a user person by getting access to the user's linux shell like so:
If user has nc (netcat):
On the Admin's linux have a terminal window listen on port 80 (or some other):

admin:~# nc -l -n -v -p 80

and on the User's linux connect to the admin's netcat like so:

user:~# nc -e /bin/sh admin_linux_IP 80

If user does not have netcat but has telnet:
On the Admin's linux setup 2 terminal windows listening on two ports like this:

admin:~1# nc -l -n -v -p 80
admin:~2# nc -l -n -v -p 25

and on the user's linux shell initiate the connection:

/bin/telnet admin_linux_IP 80 | /bin/sh | /bin/telnet admin_linux_IP 25

Search files by content

This is a little bash executable to search for files by their content in the current folder and subfolders:

if [ -z "$1" ]; then
echo "Usage: search &lt;file patterns&gt; &lt;phrease to search in contents&gt;"
exit 1
fi

find . -name "$1" | xargs grep -iR $2