J(2)EE/Java
Create simple Java application to post JSON message to CometD Bayeux Channel using Apache HttpClient and Maven style NetBeans project
Jan 20th
The objective discussed in this article is to post messages to a CometD Bayeux Channel with a standalone Java Class – without dependencies on CometD. For example to control from Java the Slideshow introduced in the synchronized Slideshow demo application created using CometD (see previous articles Push based synchronized Slideshow demo application implemented using CometD and jQuery running on Tomcat and Publishing to CometD Bayeux Channel from inside the Oracle Database – PL/SQL based push to CometD Web Client ).
This article describes the creation of a simple Java Class leveraging Apache HttpClient to post HTTP requests (JSON messages) to a CometD Bayeux Channel. The main point is to show working code with the lest dependencies, not an optimal program (it is far from optimal). The article demonstrates how NetBeans and Maven conspire here to make the task as simple as possible. The Maven support in NetBeans allows me to simply create a new Maven style project of (arche)type Java Application.
Publishing to CometD Bayeux Channel from inside the Oracle Database – PL/SQL based push to CometD Web Client
Jan 19th
In recent articles, I have introduced CometD as framework for Server to Client and Client to Client Push: Running CometD 2 examples – locally on Tomcat using Maven and NetBeans http://technology.amis.nl/blog/14709/running-cometd-2-examples-locally-on-tomcat-using-maven-and-netbeans, CometD 2 Java Client Sample – open project in NetBeans based on Maven pom file, modify sources and run Java Based Comet Client (http://technology.amis.nl/blog/14720/cometd-2-java-client-sample-open-project-in-netbeans-based-on-maven-pom-file-modify-sources-and-run-java-based-comet-client) and Push based synchronized Slideshow demo application implemented using CometD and jQuery running on Tomcat (http://technology.amis.nl/blog/14870/push-based-synchronized-slideshow-demo-application-implemented-using-cometd-and-jquery-running-on-tomcat).
CometD allows web clients (or stand alone Java clients) to subscribe to Bayeux channels maintained by the CometD Server (Servlet). These clients can publish messages to the channels and CometD will deliver the messages to all or to selected clients – in a push-fashion. This makes it possible to push messages from the Java server side of a web application to web clients and indirectly to do the same between web clients. One example I have described of applying this technology is the synchronized slideshow: a web page is opened in two or more browsers. When a slide is selected in one of the browsers, the slide is selected in all browsers (because they all subscribed to the channel that a slide selection event was published to).

This article adds another push channel to the overall picture: it describes how the Oracle Database can publish directly to the Bayeux Channels (by posting to the CometD servlet over HTTP) and thereby perform push to the subscribed web clients. Database to browser push – how does that sound?
Sharing session state between JEE web applications through WebLogic session descriptor of sharing-enabled
Jan 18th
Session state in Java Web application is associated with a single (user) browser session on the one hand and typically with a specific web application on the other (server side) hand. Session state is created and maintained in the context of a usually a single web application. However…
We ran into a situation where our web application was assuming gigantic proportions. To complex to quickly deploy or even easily build, compile and test. On closer inspection, it was quickly revealed that the application really consisted of a number of relatively independent modules – say one for each of the options in the main menu and one for the entry point – main menu, login, manage user preferences etc. From a functional point of view, the big web app monster was by and large a collection of almost individual web applications. Almost because a substantial number of navigations took place between pages in these modules. And some context data – including credentials – should be passed on these navigations. The application was developed with such information stored in the session scope – as all modules always have access to a (shared) session scope, it was thought.
We got to the point where for many reasons we would like the big fat web application to be split in one web application per module. This would allow much easier development, administration, release management etc. However, we could not resolve this issue of shared session state that should be maintained across the web applications-per-module.
We contemplated moving this shared session state to a memory grid – but the impact on the existing application would be quite substantial (although an interesting challenge: introduce a new scope for managed beans (superapplication, cross-application or application-cluster) and create an EL resolver that knows where to find beans referred to with expressions like #{super-application.bean.property}; find a way for all applications in the applicationcluster to identify a user session in the same way to ensure the bean instance associated with the current session in the current application is retrieved).
An easier solution presented itself – after briefly conferring with Mike Lehmann of Oracle’s Application Server team – in the form of WebLogic Server’s session sharing capabilities.
Using custom functions in EL expressions in JSF 1.x
Jan 17th
EL expressions are one of the main driving forces for JavaServer Faces. Most dynamic characteristics of pages and widgets are governed by EL expressions. In JSF 1.x, there are some limitations for EL expressions that can at times be a little frustrating. One of the limitations is the fact that no custom functions or operators can be used in EL expressions. Quite some time ago, I wrote this article – http://technology.amis.nl/blog/622/how-to-call-methods-from-el-expressions-pre-jsp-20-trick-for-jsps-with-jstl – to demonstrate a trick for using a Map interface implementation to access custom functionality from EL expression after all.
However, things can even be better. Rather than jumping through the somewhat elaborate hoops of implementing the Map and consructing complex EL expressions, there are two other approaches. One is to create a custom EL Resolver can configure it in the faces-config.xml. Another is discussed in this article. It involves registering custom Java methods as eligible for use in EL expressions. And that really makes life a lot easier. It allows us to create EL expressions such as:
#{cel:concat (cel:upper( bean.property), cel:max(bean2.property, bean3.property), cel:avg(bean4.list))}
or
#{cel:substr(bean.property, 1, 5)}
Retrieve song lyrics in Java using Screenscraping with JSoup
Jan 16th
Last year I wrote about JSoup, a Java library that helps with screenscraping: Screenscraping from Java using jsoup – effective data gathering from websites (http://technology.amis.nl/blog/13121/screenscraping-from-java-using-jsoup-effective-data-gathering-from-websites). Last month I had another opportunity for using JSoup, this time to gather song lyrics for the songs on a CD. The context in this case was the internal SOA for Java Professionals training program at AMIS. The students did an assignment to complete the second block in this three-piece program. Their assignment required them to implement a Web Service that produced the CD Booklet for a certain CD – returned as PDF document with illustration, song titles and song lyrics. One of the resources we made available to the students was a Java Class that returned song lyrics. It was their challenge to integrate this class in a proper way in their application (be it PL/SQL, SOA Suite 11g or OSB based).
The LyricsGatherer is easily constructed using JSoup and the website http://www.songlyrics.com/ (that suffers from periodic and unfortunate loss of service) :

Using Java to create a report with the JasperReport java API
Jan 15th
In this blog I will describe how to create a Report with JasperReport in Java. For this purpose I have used the Communitie edition of iReport. This edition contains besides JasperReport also iReport. iReport is a report designer for JasperReport. You can download it from http://jasperforge.org/projects/ireport
After installation I started iReport to design a report. I have design a report to create CD booklets. It contains the name of the artist, an album title, an image, the tracklist and the lyrics of these tracks.
Stand-alone Java Client for jWebSocket Server – communicating from Java Client to Web Clients and vice versa over WebSockets
Jan 15th
In a previous article, I have discussed the open source jWebSocket Server and a simple installation and configuration (http://technology.amis.nl/blog/14940/first-steps-with-jwebsocket-open-source-java-framework-for-websockets-installation-and-running-samples). Subsequently, I have shown the implementation of a web client for a synchronized Slideshow application, where WebSocket communication is used to perform Client 2 Client push (http://technology.amis.nl/blog/14949/push-based-synchronized-slideshow-web-application-implemented-using-websockets-and-jwebsocket-server-the-open-source-java-websocket-server). In a third article I have explained how jWebSocket server can be integrated with a Java application that can start the server and interact with it (http://technology.amis.nl/blog/14973/implementing-a-java-server-side-component-for-jwebsocket-server-for-websocket-interaction-with-web-clients). Finally in this article I demonstrate how a stand alone Java Client can connect to a ‘remote’ jWebSocket server and open WebSocket interactions with it.
The functionality realized in this article is a simple Java application that listens to slide selection events as pushed from the clients to the WebSocket and that also pushes slide change instructions over WebSockets to the clients. After starting the jWebSocket server and opening one or more clients, running the Java Application created in this article will guide all clients through a sequence of slides.

and a few seconds later:

Implementing a Java Server Side component for jWebSocket Server for WebSocket interaction with Web Clients
Jan 14th
In a previous post – http://technology.amis.nl/blog/14949/push-based-synchronized-slideshow-web-application-implemented-using-websockets-and-jwebsocket-server-the-open-source-java-websocket-server – I discussed the implementation of the synchronized slideshow application using Web (HTML/JavaScript) clients and jWebSocket as websocket server. In an earlier article, I described the same for the Kaazing WebSocket server – http://technology.amis.nl/blog/14777/push-based-synchronized-slideshow-web-application-implemented-using-websockets-and-kaazing-websocket-gateway – and both stories are (fortunately) fairly similar. In the Kaazing article I also described a Java based Server Side ‘client’ or ‘WebSocket interaction partner’. In the jWebSocket article, that part was missing and in this article I will rectify that.
This article will describe how a Java application can integrate with jWebSocket server – in fact: start the server from within the Java code -and subsequently register listeners that intercept WebSocket communication from other interaction partners such as Web clients. The Java application can also send messages to specific clients or broadcast to all clients. This article will merely scratch the service by describing how a simple Java application interacting in this way with jWebSocket server can be created in NetBeans 7.
Finding the information to achieve this was not very easy by the way. And finding out how a stand alone Java application can connect to a stand alone (separately running) jWebSocket server is still slightly beyond my reach.
First steps with jWebSocket – open source Java framework for WebSockets – installation and running samples
Jan 12th
This month, In have been delving into Push architectures for the Web, looking into WebSockets among several other things. WebSockets, a fairly new standard (!) evolved along with HTML 5, specifies a communication protocol that provides an alternative to classic HTTP communication. WebSocket based interaction has lower overhead and – more importantly – is bi-directional which means that push from server to client is really supported (and not just emulated through poll, long poll or streaming responses as is currently the case in comet push style frameworks).
All modern browsers provide support for the WebSocket specification – meaning they can communicate based on the WebSocket protocol (ws:// and wss:// in addition to http:// and https://) and they implement the WebSocket client side (JavaScript) APIs. These API are well defined – http://dev.w3.org/html5/websockets/ – and seem to be truly standard across all browsers.
The WebSocket server side is at this moment not very well defined. Other than the fact that the communication over ws:// and wss:// should be handled by a server, not much has been decided about the server side of WebSockets. Currently, WebSockets is not supported in classic JEE servers although such support seems imminent with JEE 7 through the Servlet 3.1 specification (JSR 340, http://jcp.org/en/jsr/summary?id=340; also read http://antwerkz.com/websockets-and-java-ee/ on how WebSockets my be included in the Servlet API). Initial support for WebSockets has been shown in Jetty and GlassFish, with other JEE containers undoubtedly following suit in next 18 months or so. In the meanwhile, several stand alone WebSocket servers have been released, including Kaazing (a commercial offering which I mentioned in two earlier articles: http://technology.amis.nl/blog/14755/get-going-with-kaazing-websocket-gateway-html5-edition-installing-locally-and-running-demos and http://technology.amis.nl/blog/14777/push-based-synchronized-slideshow-web-application-implemented-using-websockets-and-kaazing-websocket-gateway) and jWebSocket (an open source offering – http://jwebsocket.org/), that I will introduce in this article.

These WebSocket servers are capable of handling WebSocket interaction with a variety of clients – well, the server should not have to care about the type of client but only about the communication. How the WebSocket server should relay WebSocket messages received from a client to a back end service is not well defined, at least not in a standardized way. Vice versa: how back end services can deliver their push messages and events – chat message, JMS message, mail reception, RSS entry, Tweet, database update, business event … – to the WebSocket server for onward routing to interested clients is not covered by an existing standard either. Even integration of WebSocket interaction into regular JEE Web Applications is very much in question. Kaazing spokesmen even suggested that perhaps WebSocket communication provides the foundation for a whole new type of application in which traditional JEE application servers are no longer needed (see: http://www.businesswire.com/news/home/20111019005426/en).
Well, before going to deep into these discussions, let’s take a look at how we can get the jWebSocket server going to at least run a few demo application on our local machine (or at least my local environment).



