Thursday, November 29, 2012

Polyglot Widgets

JBoss Developer Framework

The JBoss JDF project shows Java EE developers how to build state-of-the-art applications using the JBoss implementations of the Java EE stack. Specifically, the JDF View Frameworks section identifies a number of alternative approaches one can take when developing the view layer of your application. We in the RichFaces project have been working towards better supporting this effort by redesigning our JSF component architecture to allow the javascript part of our components (what we call our “widgets”) to be used independent of JSF, either in a standalone manner or coupled with another web framework.

By isolating the client-behaviour into widgets, we are able to achieve both a faster turnaround on new JSF component development, while at the same time enabling users to achieve a uniform look and feel in their heterogeneous application environments. To demonstrate the impact of this, I’ve prepared a demo application that demonstrates using our standalone javascript widgets in JSF with RichFaces, GWT with Errai, and a plain HTML 5 page with Aerogear.

Polyglot widgets demo

polyglot-widgets

The polyglot-widgets demo takes the RichFaces Sandbox pickList component and builds a GWT and plain HTML5 application using the standalone javascript pickList widget.

Some key points of the demo to call out:

Consistent L&F

Imagine writing “polyglot” web applications with both a consistent Look & Feel, and access to the rich set of enterprise-grade widgets that you’ve come to expect from the RichFaces project. In the demo, the same RichFaces Sandbox pickList widget is used in a JSF, GWT and HTML 5 application. The widget and the demo pages themselves use the Bootstrap project for styling, which is what enables us to achieve a consistent L&F across the pages backed by different web technologies. This common L&F is taken one step further to deliver a consistent user experience by using the same javascript widget implementation across all the demo pages.

CDI Programming model

In the demo, we use the pickList component to make a selection on one of the demo pages, then click the submit button. On navigation to one of the other demo pages, you’ll notice the state persisted. This demonstrates how we can leverage CDI to provide a common programming model across all our web frameworks.

Integrated Ajax Push

Open each page of the demo in a separate window to witness selection updates synchronizing the pages in real time. Taking advantage of RichFaces push, the Errai CDI bus, and HTML 5 Server-Sent-Events (via the Atmosphere project) in each of the respective frameworks provides incredible power in keeping our “polyglot” web-apps in a coherent state.

Screencast

I created a screencast of the demo, to make it easier to see the above points in action. Watch the screencast below, then head off to play with the demo yourself. Even better, fork the demo on github, and see what cool things you can do with it.

Next Steps…

I put this demo together as a proof-of-concept to help me illustrate what I mean when I talk about “standalone widgets” and polyglot/poly-framework applications. The RichFaces team will ramp up development on these new standalone widgets as we wrap up our RichFaces 4.3 effort and shift gears into RichFaces 5. So stay tuned for further development in this area!


Wednesday, October 10, 2012

Back From Java One

Last week I was at Java One, where I can easily say I thoroughly enjoyed the week of chaos that is JavaOne. The quality of people and content was truly astounding – I met a number of people I’d been wanting to meet for a while, and also spent some time getting to know more fellow JBoss developers. I spent the bulk of my time preparing my presentations, leaving little time to attend sessions. Hopefully this extra effort paid off ;)

JBoss Booth Sessions.

The first talk I gave was an impromptu one, filling in a last-minute vacancy in the schedule. I delivered a trimmed down version of the Mobile JSF talk I gave at JBW and JAX last June/July. The talk was well received, “trapping” a fair amount of traffic around the booth, and resulting in some interesting discussion at the end of the session. The slides from this session are available, and the session was filmed – I’ll follow up with links when the videos are available.

My second talk was also a booth session. This time I presented on Leveraging jQuery plugins to build JSF components. This talk demonstrates how to build custom JSF components using first the JSF 2 composite component feature, then the RichFaces CDK. Unfortunately this session was less well attended, which I think had a lot to do with the early morning-timing.

JavaOne Session

Hot dog at Pearl Jam party
Chili dog served at the JavaOne Appreciation Event

Finally I presented a JavaOne session with Lincoln Baxter III on the topic of Testing JSF Applications with Arquillian and Selenium. This slide was recorded, and the videos is available for online viewing. Additionally I’ve posted the slides on my website, and the source code used for the demos is available on github.

The JavaOne session went really well. I was not expecting the audience to be so unfamiliar with Arquillian, given how many times Arquillian was presented at JavaOne. As such we spent more time going over the Arquillian Basics, and this cut quite a bit into the time I wanted to spend on the JSF specific Arquillian Warp slides near the end of the presentation. Nevertheless, the message was well received, and we’ve successfully seeded the brains of a number of JSF developers with thoughts of testing with Arquillian.

Of course one can’t mention JavaOne without talking about the Oracle Appreciation Event. Words cannot express how supremely awesome it was to see Pearl Jam perform live! Larry Ellison’s going to have a tough time topping that next year!

All in all, I’d call the event a success. I’ll definitely be submitting a session abstract again next year!


Friday, September 28, 2012

JSF-Testing Session at Java One

I’ll speaking next week at Java One on the topic of “Testing JSF Applications with Arquillian and Selenium. The Session co-ordinates are as follows:

Testing JSF Applications with Arquillian and Selenium
CON7622: Thursday, Oct 4, 2:00 PM – 3:00 PM – Parc 55 – Cyril Magnin I

Unfortunately the Java One website truncated the abstract, and the bit that’s left doesn’t give you a good idea of what I’m talking about. Let’s correct that right away!

We’ll start with a review of Arquillian and Selenium, then look at the Arquillian extensions Drone, Graphene, and Warp and how we can use them to write effective JSF tests. These tools allow us to write “real” tests without the need for mocking the JSF environment, nor running in a crippled client container.

For the sake of completeness, here’s the abstract as originally submitted:

Abstract

In modern development environments, it’s a “must” to include testing of web applications as a standard part of the development life-cycle. Such tests can also be used as acceptance criteria in enterprise projects. While full-automation is possible, it is considered to be very expensive. As a result, in projects where testing is included as part of the project plan, it is also often the first requirement cut when the project schedule begins to slip.

JSF projects can be particularly difficult to test with basic tools. We’ve seen a revolution with Arquillian that has made integration testing a breeze. Similarly, Selenium helps in UI testing automation. However, neither Arquillian nor Selenium can save the world alone, as their are some outstanding problems that neither of these technologies address:

  • UI test development is slow and decreases developer productivity
  • Client/server co-operation lacks coverage, each is tested independently
  • Selenium tests only: page transitions, JavaScript interaction, and a portion of the DOM
  • The number of Selenium tests can increase quickly, leaving you with maintenance burden

In an effort to reduce the impact of these concerns, we will look at current best practices of how to achieve a rapid turnaround for test development. We’ll also investigate how to take a client-side test to the server and back, verifying state at both ends. Techniques will be shared for minimizing the effort required to write tests, thereby increasing productivity and making your tests future-proof.


Friday, June 17, 2011

Seam Faces @JAXConf/JSF Summit

It’s been a while since my last post, as I’ve gone through a significant career change. I am now working for Red Hat, as a core developer on the RichFaces project. I am also representing Red hat on the JSR-344: JSF 2.2 Expert Group, and will continue in my role as Seam Faces module lead.

As such, I’ll be presenting at JAXConf/JSF Summit on the topic of Seam Faces. I really like this presentation, as I not only go into the features provided by Seam Faces, but I show how some of those features are implemented taking advantage of the platform extension points built into CDI and JSF. I’ll also introduce how we are using Arquillian, Shrinkwrap, and JSFUnit to test Seam Faces, and how you can use the same toolset to test your own applications with independent and isolated in-container tests.

So if you are at JAXConf/JSF Summit, be sure to come see my talk, or grab me at any time to share your thoughts on where you would like to see Seam Faces going in the future – I’ll be more than happy to discuss solutions, and point you to the git repository!


Friday, June 25, 2010

JSF Validation Failed Notice

Here’s how I show a notice on a JSF 2 page indicating that the JSF 2 postback failed due to validation errors. The following facelet snippet is rendered only when validation fails:

<h:outputtext 
   styleclass="errorMessage globalMessage" 
   value="Request *not* saved due to input errors" 
   rendered="#{facesContext.validationFailed}" />

The user then knows they should look through the page to correct the individually marked validation failures.


Wednesday, January 20, 2010

Glassfish V2 and V3 on the same host, behind mod_jk

I’ve jumped on the JavaEE 6 bandwagon, with one application already in production. The developer productivity improvements in JavaEE6/Glassfish V3 are tremendous. The only downside is that I still have some JavaEE 5 applications in production. The JavaEE 5 apps can’t migrate to JavaEE 6 until Icefaces supports JSF 1.2.

One workaround to this is to bundle the JSF 1.2 implementation with your application, then configure the classloader using the sun-web.xml file to load this bundled JSF library instead of the container’s JSF 2.0 library. This however only works with a standalone WAR file; when the WAR is bundled in an EAR, and references other EJB-JAR’s, this trick isn’t possible. Yet I still wanted to move new application development to JavaEE 6.

My solution was to run both Glassfish V2 and Glassfish V3 on the same box, with mod_jk forwarding requests to the appropriate container. In this way I am able to keep my existing JavaEE 5 / Icefaces applications running, and deploy new applications to the JavaEE 6 environment.

The first step was to get GF v2, and GF v3 running on the same machine. I have GF v2 running on the standard ports, and I incremented each port by 1 for GF v3. It looks like:

GF v2 Port GF v3 Port
HTTP 8080 8081
HTTPS 8181 8182
HTTPADMIN 4848 4849
IIOP 3700 3701
IIOP SSL 3820 3821
IIOP SSL-MUTUALAUTH 3920 3921
JMX 8686 8687
JMS 7676 7677

Next, we had to get mod_jk installed and working. The glassfish support team (yes, I pay for support!) pointed me to the following resources:

These were a great starting point, from which I ended up with the solution.

mod_jk.conf:

#mod_jk/1.2.28
LoadModule jk_module modules/mod_jk.so
JkWorkersFile /etc/httpd/conf.d/worker.properties
# Where to put jk logs
JkLogFile /var/log/httpd/mod_jk.log
# Set the jk log level [debug/error/info]
JkLogLevel info
# Select the log format
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
# JkOptions indicate to send SSL KEY SIZE,
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories +DisableReuse
# JkRequestLogFormat set the request format
JkRequestLogFormat "%w %V %T"

# Should mod_jk send SSL information (default is On)
JkExtractSSL On
# What is the indicator for SSL (default is HTTPS)
JkHTTPSIndicator HTTPS
# What is the indicator for SSL session (default is SSL_SESSION_ID)
JkSESSIONIndicator SSL_SESSION_ID
# What is the indicator for client SSL cipher suit (default is SSL_CIPHER)
JkCIPHERIndicator SSL_CIPHER
# What is the indicator for the client SSL certificated? (default is SSL_CLIENT_CERT)
JkCERTSIndicator SSL_CLIENT_CERT

# Set the following if you want all vhosts to inherhit JkMounts from global
JkMountCopy All

# Send requests to GlassFish
JkMount /javaee6app* worker1
JkMount /javaee6app/* worker1

JkMount /javaee6app* worker2
JkMount /javaee6app/* worker2

# Send all glassfish-test requests to GlassFish
JkMount /glassfish-test/* worker1

JkShmFile /var/log/httpd/jk-runtime-status

And worker.properties:

## Define 1 real worker using ajp13
worker.list=worker1,worker2
# Set properties for worker1 (ajp13)
worker.worker1.type=ajp13
worker.worker1.host=localhost.localdomain
worker.worker1.port=8009
#Only used for a member worker of a load balancer. 
#worker.worker1.lbfactor=50
#Do not use cachesize with values higher then 1 on Apache 2.x prefork
#worker.worker1.cachesize=10
#connection_pool_size replace cachesize as of v1.2.16
worker.worker1.connection_pool_size=1
worker.worker1.connection_pool_timeout=0
worker.worker1.socket_keepalive=1
#Socket timeout in seconds
worker.worker1.socket_timeout=60

worker.worker2.type=ajp13
worker.worker2.host=localhost.localdomain
worker.worker2.port=8010
#Only used for a member worker of a load balancer. 
#worker.worker2.lbfactor=50
#Do not use cachesize with values higher then 1 on Apache 2.x prefork
#worker.worker2.cachesize=10
#connection_pool_size replace cachesize as of v1.2.16
worker.worker2.connection_pool_size=1
worker.worker2.connection_pool_timeout=0
worker.worker2.socket_keepalive=1
#Socket timeout in seconds
worker.worker2.socket_timeout=60

These are not the worker.properties as prescribed in the above links. After implementing the initial solution, I got reports from the wild of users mysteriously losing sessions. After much reading about mod_jk, I think I narrowed down the problem to a cachesize/connection_pool_size > 1 in conjunction with the prefork mpm apache module. Apparently this is a no-no.

So with these settings in place, I am able to develop new apps in JavaEE 6, while still running my older JavaEE 5 apps, on the same box. Looking forward to Icefaces 2.0 though, so I can drop this needless complexity!