My last talk at Devoxx was the one that perhaps i enjoyed the most and one that I was really impressed by. A lot of neat products based on Groovy were discussed in this talk. They had a lot in common. Besides all being based on Groovy, they also have a very simple installation procedure in common: just download the product, unzip it, and add the executable to the PATH variable. And voilá, you have a command line tool at your disposal linked to the product you downloaded.

The talk was presented by Andres Almiray. All the products he discussed, he demoed by using a text editor and a command line (and sometimes a web browser), which was pretty cool. It furthermore emphasized the simplicity of working with the different products. Like Andres did in his presentation, I will focus this blog on Grails, Griffon and Gradle and only give a short summary of the other products.

Grails

First up was maybe the most widely known product in the Groovy eco-system. Grails is a high-productivity web application framework based on Spring, Hibernate and Sitemesh. It’s a widely used framework and currently there are over 600 plugins available for Grails, facilitating the addition of custom functionality (like file uploading or integration with soap or rest services) to your web application.

With Grails you bring Rapid Application Web Development to the table. In no time Andres got a CRUD application up an running.

First he created a basic Grails application

$ grails create-app devoxx

Next, he added some domain classes

$ grails create-domain-class Author
$ grails create-domain-class Book

This created the Author.groovy and Book.groovy class files.

The relation between the two classes Andres added manually by adding the following line of code to the Author class:

static hasMany [books:Book]

With the domain classes in order, we can now create 2 controller classes AuthorController and BookController:

$ grails create-controller Author
$ grails create-controller Book

Now, to enable auto-generation of the view layer of the application based on the domain classes, we have to enable a feature called scaffolding. The following line of code added to the AuthorController takes care of this:

static scaffold = true

Now all is in place for running the application:

$ grails run-app

With scaffolding in place all the views for the CRUD app get auto-generated (as .gsp pages). The run-app command furthermore packages the application and bootstraps TomCat. Now you can reach the application at the following url: http://localhost:8080/devoxx/author.

One additional benefit of using these basic commands to rapidly generate a prototype is that every generated class gets to appear in its own default package, given that Grails is based on the configuration by exception paradigm. Scaffolding is based on templates and all these templates can be customized to fit your needs.

After the basics Andres shows some additional Grails features. All of them very easy to add to the application:

• Adding constraints to domain classes (Grails error messages support i18n);
• Creating a taglib: $ grails create-taglib;
• Launching the Grails console, an interactive playground, similar to the Groovy console: $ grails console
• The grails war command: $ grails war;
• Installing the Grails REST plugin: $ grails install-plugin rest;
• Creating and packaging a custom plugin: $ grails create-plugin / $ grails package-plugin.

Griffon

Griffon is similar to Grails. It’s a high productivity framework for building Desktop applications. Griffon is a relatively new framework. It already has nearly 200 plugins available though.

A lot of the commands in Griffon are similar to the commands used in Grails. Here are some useful commands:

$ griffon create-app devoxx
$ griffon run-app
$ griffon run-applet
$ griffon run-webstart

Views are by convention filed under the view directory in a Griffon project and are named …View.groovy. Griffon uses bindings to couple fields or properties in the view layer to bean properties in the model layer. Here are some code snippets to illustrate:

DevoxxModel.groovy

@Bindable String input
@Bindable String output

DevoxxController.groovy

def copy = {
  // model gets injected by Griffon
  model.output = model.input
}

DevoxxView.groovy

textField(text:bind(target:model,targetProperty:'input'))
textField(text:bind(source:model,targetProperty:'output'))

The controller copy method copies the input property of the model to the output property. Both properties are bound in the view to text fields.

One of the key concerns that’s difficult to manage in Swing applications is threading. And this is something in which Griffon really shines. For example if you have a controller method you want to execute in a thread separate from the UI Thread, you add the following annotation:

@Threading(Threading.Policy.OUTSIDE_UITHREAD)

As an alternative you can make use of the following Griffon methods to execute pieces of code in the threaded manner you want:

• execAsync: execute the code in the UI Thread asynchronously;
• execSync: execute the code in the UI Thread synchronously;
• execOutside: execute the code outside the UI Thread.

Griffon also supports an event mechanism. You can launch an event called Devoxx and include a list of parameters with the following Griffon code:

app.event('Devoxx',[1,2,3])

Like the exec method, there’s also a variant for asynchronous events (app.eentAsync) and one for outside events (app.eventOutside).

A possible event handler could look like this:

def onDevoxx = { n1,n2,n3 ->
println: "Devoxx $n1,$n2,$n3"
}

A lot of the create- commands from Griffon also let you generate artifacts in Java instead of Groovy. Simply add fileType=java to the command. One interesting, though not very surprising, fact to note is that the Java files are a lot bigger compared to the same files generated in Groovy.

Gaelyk

Gaelyk is a lightweight Groovy toolkit for Google App Engine Java. Google App Engine is a so called Platform As A Service and provides a Java 6 Runtime Environment.

Gradle

Gradle is a Groovy alternative to Maven. It’s a tool for building applications. It uses Groovy DSL (Domain Specific Language) instead of XML and adheres to specific Maven conventions.

This is an example of a simple Gradle build file for a java project (compare that to a simple Maven file):

build.gradle

apply plugin: 'java'

This is a build file for a java project that uses the same default conventions as Maven does (like java source files are by default placed in the src/main/java directory).
To build a project based on this build file, simply type:

$ gradle build

When you issue this command, Gradle bootstraps and builds the project. When you issue the command a next time and there are no changes, Gradle is able to recognize this and doesn’t perform an unnecessary second build. You still lose the amount of time needed for bootstrapping Gradle. There’s also an experimental daemon available, so you can go without even the bootstrapping time. Gradle, like Maven, uses configuration by exception. So, like Maven, you can do without the default structure of a project is that doesn’t fit your needs. But you have to add additional configuration code to your build file.

Dependency management in Gradle by default uses Maven repositories. For example, to add a compile dependency for commons-lang, your build file would need these additional lines of code:

repositories {
    mavenCentral()
}

dependencies {
    compile 'commons-lang:commons-lang:2.6'
}

To view a list of dependencies for the current project you can issue the following Gradle command:

$ gradle dependencies

Multiprojects in Gradle are very easy. Assume you have a multi project with two projects multi-core and multi-ext, where multi-ext is dependent on multi-core. You first add a settings.gradle file next to the build.gradle file for the root project:
settings.gradle

include 'multi-core'
include 'multi-ext'

Next you add a dependency on multi-core in the build.gradle file of the multi-ext project. And that’s all there is to it. When you now build the multi-ext project, the multi-core project also gets build. Changes to the multi-core project are also picked up when rebuilding the multi-ext project.

To build a pom file for your current project, issue the following command:

$ gradle install

Like Maven, you can define properties in Gradle in a gradle.properties file.

The open source projects Grails and Griffon both use Gradle as their build tool.

Gant

Gant is a Groovy version of Ant. You have the power of Ant at your disposal but in a Groovy way, thus without the bloated xml.

easyb

easyb is a behavior driven development (BDD) framework. Stories and specifications are written in Groovy. It is comparable to JBehave, which does the same in Java.

Spock

Spock is a testing and specification framework for Java and Groovy applications.

CodeNarc

CodeNarc is an equivalent to the java tools findBugs and checkstyle. It’s a tool for analyzing Groovy code and detecting bugs, coding malpractices and the like. There are plugins available for Grails, Griffon and Gradle.

GPars

Gpars lastly is a framework aimed to simplify concurrency programming in Java or Groovy.

References

• Devoxx Slides
• Griffon Slides
• Grails in Action
• Griffon in Action
• GroovyMag

The first talk of day 2 I attended, was about integration. Integration frameworks comes into play when you have to integrate between different technologies (JDBC, HTTP, JMS) or different message formats (XML, EDI, CSV, etc.). Charles Moulliard presented this session in which he discussed a bundle of Apache licensed products used to enable integration:

• Apache Camel: java-based routing and mediation engine;
• Apache CXF: web services framework (SOAP/REST);
• Apache ActiveMQ: message broker, a JMS implementation;
• Apache ServiceMix: an open source ESB, based on JBI (Java Business Integration).

Apache Camel

Camel is introduced as an open source integration framework enabling the implementation of Enterprise Integration Patterns (EIP). It has the following features:

• Contrary to a lot of integration frameworks that are out there, with Camel one is able to implement all EIP patterns;
• Supports Java DSL and Spring based XML configuration to transpose EIP patterns into Java;
• It’s an in-memory bus;
• Routes objects (XML, Stream, File, Bytes);
• Transactional;
• Supports Sync/Async exchanges;
• Threads management;
• Error and Exception Handling.

Routing is implemented via Java DSL (Domain Specific Language). Here is an example for integrating 2 endpoints (A and B) and using a filter in between.

public class FilterRoute extends RouteBuilder {
    public void configure throws Exception {
        Endpoint A = endpoint("activemq:queue:quote");
        Endpoint B = endpoint("mq:quote");
        Predicate isWidget = xpath("/quote/product = 'widget'");

        from(A).filter(isWidget).to(B);
    }
}

You can also build a oneliner inside the method that accomplishes the same thing:

        from(endpoint("activemq:queue:quote")).filter().xpath("/quote/product = 'widget'").to(endpoint("mq:quote"));

Java DSL is currently supported by all the major IDEs (Netbeans, IntelliJ and Eclipse). When using an IDE you have the added advantage of code completion. You lose this advantage when you switch to Spring XML configuration.

Apache CXF

CXF is a webservices framework designed to simplify the creation and deployment of webservices. It’s a merge of 2 previous frameworks, XFire (an Apache Axis competitor) and Celtic. CXF provides the following features:

• It has java2wsdl and wsdl2java generation capabilities;
• Supports JAX-WS, JAX-RS, SOAP, WSDL, WS-Security, WS-ReliableMessaging, WS-Addressing;
• Maven plugin cxf-codegen-plugin for code generation (wsdl2java);
• it uses a spring configuration file for setting specific generation properties;
• it generates java classes with JAXB and JAX-WS annotations.

Apache ActiveMQ

The routing done in Apache Camel is all in-memory. This means that exchanges can become lost. Sometimes this is not very desirable. For those situations ActiveMQ provides the solution.

ActiveMQ is based on JMS and supports point-to-point messaging (JMS Queue, one sender, one receiver) as well as publish/subscribe (JMS Topic, one publisher, zero to many subscribers).

Apache ServiceMix

Apache ServiceMix is an ESB and supports the exchange of messages and objects between a range of transport layers. It has the following characteristics:

• provides connectors (endpoints) for receiving messages and sending them on the bus;
• separation of business logic and messaging logic;
• based on JBI;
• uses a Normalized Message Router. Components are never directly coupled, there’s the router in between, which uses a Normalized (based on XML) Message format. This format is a combination of metadata, payload and attachments.

Since the JBI standard is a dead standard, ServiceMix had deviated from it and added additional functionality:

• Modularity based on OSGI (ServiceMix4 can use Felix or Equinox as the OSGI kernel);
• Adopted Camel as the new routing engine.

Apache Karaf

At this point Apache Karaf is introduced. Karaf is a lightweight container to which Java applications, Camel Routes and CXF services can be deployed. It has an OSGI run-time and supports Apache Felix and Eclipse Equinox. It’s also the heart of Apache ServiceMix. If you don’t need ESB or NMR features, Karaf is basically all you need. Furthermore, because it’s a modular container you can choose which options you really need. For example, you can choose only to activate Camel and CXF and do without ActiveMQ.

Apache Karaf has the following characteristics:

• Admin console is available;
• Supports hot deployment and configuration management;
• Security integration (JAAS);
• Logging management (log4j, Logger, commons logging, etc.).

Fuse IDE

Fuse IDE is an Eclipse based IDE with built-in support for Apache Camel, ServiceMix, and ActiveMQ. It offers the following:

• A graphic editor for Camel routes (a graphical representation of the camel-context.xml file, the Spring XML way of defining routes);
• Run-time views and statistics of deployed routes;
• JMX explorer;
• Drag-and-drop of test messages to deployed routes;
• And a lot more.

Fuse Fabric

Fuse Fabric is a piece of software that makes it a lot easier to configure, package and deploy the aforementioned applications, be it an Apache ServiceMix project or an Apache Camel route:

• It helps you with getting the OSGI dependencies right by making use of the Maven dependencies;
• It also eases deployment to clouds;
• With Fabric you can create and manage instances (Karaf or ServiceMix) locally, remotely (ssh) or in the cloud;
• Provides a registry (service and profile repository), based on Apache ZooKeeper;
• Adds an agent to server instances which can act upon these instances by profiles;
• A profile is a list of tasks for an agent to do.

Conclusion

With all the ingredients mentioned above almost any integration challenge can be tackled and any service architecture can be realized. ServiceMix also supports high availability via clustering and master/slave replication. For more information on some of the possible architectures see the slides mentioned in the References section.

References

• Blog Charles Moulliard
• Slides
• Slides (Not the ones from Devoxx)
• Hands on lab

The second talk of day 1 I attended, was a mix of NoSQL and Cloud Computing. And more to the point, how to integrate these technologies into Spring Enterprise Applications. The NoSQL part focussed on two popular NoSQL databases, Redis and MongoDB and was done by Chris Richardson, while the cloud part focussed on vmware’s Cloud Foundry. This part was presented by Josh Long.

Cloud

With a little background to the rise of cloud services and why we need them (Big Data, New Clients, Social Networking to name but a few of the reasons), Cloud Foundry is introduced. Cloud Foundry is a so called Platform As A Service (PAAS). A PAAS provider has the benefits of eg. ease of deployment, application management and can be easily scaled up or down.

Cloud Foundry

Cloud Foundry gives you:

• a tomcat server;
• a choice of programming languages like Java, Scala and Groovy;
• a choice of application services like RabbitMQ, MongoDB, Redis and MySQL;
• a choice of frameworks, like Grails and Ruby on Rails
• a command line interface (vmc);
• an application lifecycle API (lets you eg. start or stop your deployed applications);
• integration with the SpringSource Tool Suite (an IDE based on Eclipse for Spring developers).

Cloud Foundry is also avalilable as a free, so called Micro Cloud, that makes it easy for developers to do some experimenting.

Josh showed a demo of how to deploy applications to Cloudfoundry via the command line interface. For example, with the vmc push command you can deploy web applications to Cloud Foundry’s Tomcat Server and the vmc update command is used for updating those apps (only the changed parts in the source code are transfered to the cloud). With the vmc create-service command you can create application services on Cloud Foundry, like a mysql database. In another demo Josh showed that all this can also be accomplished graphically by using the SpringSource Tool Suite.

Cloud Foundry in Spring

The setup for integrating with Cloud Foundry services is done in the usual Spring style. You declare all the services as Spring beans in a Spring configuration file. For Cloud Foundry services configuration the cloud namespace is available. You need to add a Maven dependency to your pom file – cloudfoundry-runtime – to gain access to this namespace.

• <cloud:data-source>: A regular RDBMS dataservice available in CloudFoundry (MySQL database), can be injected into regular Spring beans;
• <cloud:redis-connection-factory>: Redis application service;
• <cloud:mongo>: MongDB application service.

You can also make use of a very cool feature called auto-reconfiguration. This lets you define a DataSource bean against a local MySQL database or a MongoDbFactory bean against a local MongoDB installation. Once you deploy an application which uses these beans to Cloud Foundry, auto-reconfiguration kicks in and reconfigures those beans to make use of a corresponding Cloud Foundry service.
Furthermore, as of Spring 3.1, you can make use of so-called profiles. You can make a profile with specific service configurations for example for local, testing and cloud deployment. So, when you’re developing you use the local profile and when you’re ready for deployment into the cloud you can switch to the cloud profile.

NoSQL

NoSQL databases are an alternative for traditional relational databases.RDBMS databases like MySQL, Oracle, etc. have been around for quite a while. Chris mentions a couple of problems related to RDBMS databases:

• ORM mismatch, it’s not always easy to map a relational schema to an object oriented model;
• Difficult to handle semistructured data;
• Difficult to scale;
• Poor performance for some use cases.

These are some of the problems that led to the rise of NoSQL databases in the past. NoSQL databases offer high performance, high scalability, a richer datamodel and are schema less. This comes at a price. Chris mentions a few of the drawbacks of NoSQL:

• Limited support for transactions;
• Relaxed consistency;
• Unconstrained data.

As you can see, it depends on the use case, which database to choose. For most use cases RDBMS database are a good choice, but for some specific use cases, NoSQL databases are a way better alternative, eg. when performance is much more important than highly consistent data.

After this introductory talk of NoSQL, two of the more popular NoSQL databases are discussed, Redis and MongoDB. They are both available in Cloud Foundry and can be easily integrated into Spring applications via Spring Templates.

Redis

Redis is a so called advanced Key-Value Store. It’s very fast, persistence is optional and it has support for transactions by the use of optimistic locking. It also supports Master-slave replication. Some of it’s use cases are as a storage for session state or for high performance queries.

MongoDB

MongoDB is a so called document-oriented database. It uses JSON-style documents for storage and retrieval. It’s fast, has a rich query layer and is highly available an scalable. MongoDB uses query by example.

NoSQL in Spring

Spring offers a lot of goodies for integration with a NoSQL database:

• Template classes
• Auto-generation of repositories
• Java <-> NoSQL mapping
• Cross-Store persistence
• Roo Support (Spring Roo is a framework for generating Spring apps)

For both MongoDB and Redis a Spring Template is available. Spring Templates are java classes that perform the role of an abstraction layer on top of a resource. Templates take away a lot of boilerplate code, transform checked into runtime exceptions and transform underlying errors into common exceptions (eg. when you use the JdbcTemplate, your exception will be same for a unique key violation regardless of whether you use a mysql database, or an Oracle database).

For Redis, the RedisTemplate, is available. Spring also offers Redis-backed collections, like the DefaultRedisSet Set. And there is also caching support via the @Cacheable annotation.

For MongoDB, there is a MongoTemplate available. For configuration purposes the mongo namespace is available.  Furthermore annotations are available to do Java <-> NoSQL mapping for MongoDB: @Document, @Id, @Indexed, etc. MongoDB can also leverage the power of the QueryDSL project. This project provides type-safe composeable queries.

Spring Integration

The last small part of the talk is about Spring Integration, and more specifically about the Advanced Message Queueing Protocol (AMQP) and SpringSource’s implementation RabbitMQ.

AMQP is a protocol for message-oriented middleware. Messaging can be used to decouple systems. AMQP is based on open standards, has clustering support, supports transactions, flow control and error handling, to name but a few of it’s features.

RabbitMQ is an implementation of AMQP and is available as an application service in Cloud Foundry. Configuration of RabbitMQ in Cloud Foundry can be done via the following Spring Bean:

• cloud:rabbit-connection-factory

Spring also has two template classes available for use:

• AmqpTemplate
• RabbitTemplate

Conclusion

This talk clearly proved that Cloud Foundry integrates smoothly with Spring applications. So when you’re already building your enterprise applications with Spring, you should definitely consider Cloud Foundry as your PAAS of choice. Cloud Foundry lacks a JEE Server, so for real JEE applications it’s less suitable. For most web applications though, a TomCat server will be sufficient. The choices of programming languages and frameworks in Cloud Foundry should suit a lot of web developers. It’s also great that they added support for an RDBMS database as well as some popular NoSQL databases. And last but not least, the Micro Cloud feature should be a great way to do some experimenting and gain a good insight on what the product has to offer. I for one can’t wait to play a little with it.

The NoSQL integration in Spring is also neatly done. I like the way Spring abstracts all external resources by way of Templates. It’s uniformly done, reliefs the developer of a lot of boilerplate coding and provides a unified way of dealing with exceptions. A lot of NoSQL databases are supported this way. Also the Java <-> NoSQL mapping available for MongoDB should appeal to a lot of programmers familiar with JPA providers like Hibernate.

References

• Spring in the Cloud Slides (not from the Devoxx talk)
• vmc getting started guide
• SpringSource blogs

Devoxx 2011 kicks off with a very impressive demo-based talk on jee6. In a time span of approx. 4 hrs Paul Bakker and Bert Ertman hack together a small enterprise CRUD application showing a lot of the new features present in jee6. And foremost demonstrating how easy it is to quickly set up such an app in jee6. Granted, they use a couple of additional tools to accomplish this feat, but nonetheless, the end result is a plain jee6 web app, easily portable across different application servers and adhering to the jee6 specs.

The application

The application being built, is a Duct Tape Store. It’s a simple online web store. A user can log in, browse through the store inventory, put items in a shopping basket and eventually purchase the items. The application is build in an agile manner. Bert tells Paul which features he wants, Paul builds them on the spot, then Bert adds additional feature requirements, which Paul again adds to the application, and so forth.
One of the key aspects of the application is that it’s build according to a layered design. A higher layer can only call code that’s in the layer directly below, and a layer can never call code in a higher layer. Delegation to a lower layer is achieved via Dependency Injection. There are basically 5 layers in the demo application:

• Presentation – implemented by JSF & facelets
• Navigation – implemented by Named Beans
• Business Logic – implemented by Enterprise Java Beans
• Data Access – implemented by JPA (this could also be a JAX-WS layer or a hybrid)
• Data – MySQL (again as an alternative for a relation database, this could be a NoSQL database or even MQ)

For fun, they throw in some AJAX, JMS and REST as well.

Build tools

Their build kit consists of the following tools:

• IntelliJ – IDE
• JBoss Forge – framework for rapid application jee6 development
• Maven – build tool
• Glassfish 3.1 – jee6 application server
• MySQL – database
• Arquillian – framework for integration testing

The demo

Let’s walk through some of the highlights of the demo. The complete source code is available on GitHub. A link to the code is available in the References section.

Creating the basics

Paul uses Jboss Forge to setup the skeleton of a new jee project:

new-project --named ducttape --topLevelPackage ducttape

This creates a basic Maven project with a minimalistic pom file.

After this Paul again uses Forge to add the necessary JSF and CDI dependencies and files (web.xml, faces-config.xml, beans.xml).

He then adds a prebuilt template.xhtml file which will be the template file from which all other facelets will inherit and adds some resources (css, images) for styling.

Again with Forge persistence is setup using Hibernate as the JPA Provider.

persistence setup --provider HIBERNATE --container CUSTOM_JTA

Filling in the layers

Using Forge an Entity Product is created in the data access layer, and using Hibernate this Entity is used to automatically create a database table PRODUCT in the mysql database:

@Entity
public class Product

In the Business Logic Layer an EJB named ProductManager is created for interacting with the data layer and doing CRUD operations on the PRODUCT table. For this an EntityManager is injected into the EJB to which the data access operations are delegated.

@Stateless
public class ProductManager {
    @PersistenceContext
    EntityManager em;

In the Navigation layer the ProductsBean, from where the UI will get his Product information, is created. It gets the following annotations:

@RequestScoped
@Named
public class ProductsBean
    @Inject ProductManager productManager;

The Named annotation enables the bean to be used via EL expression in the facelet pages. The ProductManager bean gets injected into the ProductsBean so the ProductBean can delegate Data Access tasks to the Business Logic layer:

Finally in the UI layer the ProductsBean is being injected using EL expressions:

<h:dataTable value="#{productsBean.products}" var="product" id="products">
    <h:column>
        <f:facet name="header">Name</f:facet>
        #{product.name}
    </h:column>
</h:dataTable>

In the above example the getProducts method is called on the ProductsBean, which spills out a List of Products.

Extending the basics

After the basics some more advanced features are added to the application:

• The Criteria API is used for building some type-safe queries in the beans in the Business Logic Layer;
• A TestDataInserter class is created (using @Singleton and @Startup annotations) with a @PostConstruct method that inserts the testdata;
• A JUnit test class is created with a @RunWith(Arquillian.class) annotation to make use of Arquillian for doing some integration testing;
• Sorting on displayed colums is implemented using a request parameter, which also makes the JSF sorted page bookmarkable;
• Ajax is added on a search text field to do some filtering on the product list (<f:ajax event=”keyup” render=”products”/>);
• A @ConversationScoped ShoppingBasket class is added. The ShoppingBasket bean will be alive as long as the Conversation it belongs to, is alive. The lifecycle of this Conversation is handled programmatically via an @Injected Conversation class;
• Bean Validation is added to the Customer entity. Hibernate Validator is used for this, which adds some extra validation Annotations, like @NotEmpy and @Email;
• The use of Events is demonstrated. In the Producer class an Event class of a specific type (Generic) is injected, which can then be fired in one of the methods. The Consumer classes use the @Observes annotation on the method that can handle the typed Event .
• The Injected event as well as the Method that consumes it can be annotated with a qualifier annotation, so events of the same type can be handled selectively.
• A method can handle an event asynchronously by annotating it with @Asynchronous;
• Using JAX-RS annotation a class is turned into a Rest Service, which can return a List of Product in XML and/or JSON.

For more information regarding the implementations, check out the source code in the References section.

Conclusion

All in all this was a very impressive demo showing a lot of the powerful features of jee6. With the help of the new CDI annotations it’s very easy to setup a layered application. Also worthy of note are Arquillian and Forge. Theey are definitely productivity and quality boosters and i highly recommend in every jee6 project.

References

• The slides
• Demo source code on github
• Jee 6 Refcard

Popups, ADF and browsers is the name of the game in this post. I’ve been developing ADF 11g web applications for some time now and I’ve been running into some issues while working with popups. While the popup mechanism in ADF is easy enough to understand and quite powerful, it has some quirks. This mainly has to do with showing and hiding them.  In this post I will show the various way’s to show and hide popups and what the advantages and disadvantages would be.

Firstly the way we create a popup. This is always the same. We create a “popup” element somewhere in the parent containers page.  Inside this element we can define the contents of the popup. This could be anything. If we would like to perform an action after we are done with the dialog we can use the “dialog” element to specify the actions and display the button’s to initiate these actions.

The hierarchical tree would look like this then:

<!--- pseudoXML -->
<af:popup>
   <af:dialog>
      [contents]
   </af:dialog>
</af:popup>

It might be handy to understand how exactly this popup is being rendered runtime. Essentially the popup is created and exists as soon as you create the page. It is simply hidden so it won’t bother you. So if you have a syntax error in your popup display code this error wil manifest itself when the parent page is being loaded, not when you show the popup. Because you usually want to display the popup without getting a full page refresh the popup will be shown and hidden by using javascript.

So how to interact with the popup?

1. From the JSF page

Showing the popup can be done by using the “showPopupBehavior” element. You create this element as the child of a component that can perform an action, like a button

<!--- pseudoXML -->
<af:commandToolbarButton>
   <af:showPopupBehavior />
</af:commandToolbarButton>

You can use this element to specify which popup needs to be shown and you can set some additional properties to specify where. For example if you set the “alignId” to the id of the button the popup will be shown over this button. If you want even more control you can set “align” property to control if the popup is show before, after, etc.. the button. Don’t forget to set the triggertype property. (in our case to “click”) Or else the popup will not be shown.

Closing the popup is done automatically when you use the “dialog” element and one of it’s buttons is clicked. Now there is another thing you can do using this element. You can perform actions based on which button was clicked. An example:

You have a dialog of the type “okCancel” . This means the popup will get two addtional buttons. One for “Ok” and one for “Cancel”. If we want to do something when one of the buttons is clicked we set the “dialogListener”. This must be a function in a backing bean with a parameter of the type “DialogEvent”. Here is how this function could look like:

public void onDialogClose(DialogEvent dialogEvent) {
    if (dialogEvent.getOutcome().equals(DialogEvent.Outcome.ok)) {
       // do Ok things
    }
}

2. From Backing Bean code

Now there are situations where you do not want to react on a button but a different kind of event. In those cases it might be handy to be able to show a popup from backing bean code. This might pose for some difficulities since backing beans usually run server-side and not client-side (and that’s where the javascript is). Before 11g you had to jump through some hoops to get the job done.  You had to find the current JSF context, then initiate a render kit to provide a pathway to the javascript and eventually inject javascript for the popup to show.

Like so:

FacesContext context = FacesContext.getCurrentInstance();
ExtendedRenderKitService service = Service.getRenderKitService(context, ExtendedRenderKitService.class);
service.addScript(context, "var popup = AdfPage.PAGE.findComponent('"+DIALOG_CLIENT_ID+"'); popup."+action+"();");
AdfFacesContext.getCurrentInstance().addPartialTarget(dialog);

In the example above the “DIALOG_CLIENT_ID” is the id of the popup and the “action” is “show” or “hide”. The bad news is that the above works in older versions of Internet Explorer, but it fails to close the popup in other browsers such as Firefox. The effect is that when using this code and Firefox it will freeze your screen when trying to close (hide) the popup. You can do nothing but to refresh the page and lose all context.

Now on for the good news:

In 11g there is a function that does the work for you and does so equally well in all browsers I have tested. (Firefox, Chrome and IE)

The code for showing and hiding is as follows:

if (action.equals("show")){
  RichPopup.PopupHints ph = new RichPopup.PopupHints();
  popup.show(ph);
} else {
  popup.hide();
}

In the above case “popup” is in instance of RichPopup which can be bound from the JSF page or looked up using its context. The “PopupHints” essentially do the same as the “showPopupBehaviour”. You specify which popup you want to show and provide an alignment if neccesary. Hiding the popup is now as simple as calling “hide()” on the object.

So to recap and conclude:

When working with popups in adf 11g, try to use the “popup”, “dialog” and “showPopupBehaviour” elements. When it is impossible to do so, use the “popup”, “dialog” and the “popupHints” to controll a popup from your backing beans. In all cases try to avoid the use of the renderkit to inject javascript since this code is dependant on the javascript engine of the browser.

Thats all for now! Happy coding!

Connecting to a NTLM web service can be troublesome. This blog post shows the source code of a servlet which converts HTTP calls into HTTPS calls with NTLM. The servlet takes care of the NTLM handshake.

For a customer I needed to create a BPEL process which needed information from a web service that uses NTLM. There are many ways to solve this problem. My colleague used an Authenticator: JAX-WS web service proxy client and HTTP authentication. I followed a different approach. I used the Apache HttpComponents libraries. The idea is to call a servlet as if it is the actual web service. It can be used from any application: e.g. BPEL process or soapUI. The application can be deployed on any servlet container, e.g. Apache Tomcat or OC4J.

So, what is NTLM? NTLM is a Microsoft authentication protocol. Sometimes this protocol is used by applications delevoped using the Microsoft .Net Framework. The protocol involves a handshake in several steps. NTLM is a proprietary protocol, but it is fairly well documented. How to implement NTLM in a Java client? The answer is Apache HttpComponents. The latest version of Apache HttpComponents (version 4.1 GA) has full support for NTLMv1, NTLMv2, and NTLM2 Session authentication.

Since SOAP usually means sending XML over HTTP Post a Servlet can be used to handle these requests. There is no need to modify the contents of the HTTP Post Message. When handling a SOAP request, just remember to copy the HTTP Headers.

The servlet is part of a web application which contains only one class: NTLMProxyServlet. The libraries of Apache HttpComponents (version 4.1 GA) should be included in the war file. Do not forget to map an URL to the servlet in the deployment descriptor (web.xml).

The code of the doPost method of the class NTLMProxyServlet (implements HttpServlet) is shown below. Please replace the hardcoded values for host, domain, user, url, password:

protected void doPost(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
    response.setCharacterEncoding("utf-8");
    PrintWriter out = response.getWriter();

    if(httpclient == null){
        httpclient = new DefaultHttpClient();
        httpclient.getAuthSchemes().register(
                "NTLM", new NTLMSchemeFactory());
        httpclient.getCredentialsProvider().setCredentials(
                new AuthScope("host", 443, "domain"),
                new NTCredentials("user", "password", "host", "domain"));
        httpclient.getParams().setParameter(
                CoreProtocolPNames.USE_EXPECT_CONTINUE, Boolean.FALSE);
        httpclient.getParams().setParameter(
                CoreProtocolPNames.PROTOCOL_VERSION,
                HttpVersion.HTTP_1_1);
        httpclient.getParams().setParameter(
                CoreProtocolPNames.HTTP_CONTENT_CHARSET, "UTF-8");
    }

    HttpPost httppost = new HttpPost(
            "https://host/webservices/getdata.asmx");
    InputStream in = null;

    try {
        in = request.getInputStream();
        Writer writer = new StringWriter();
        char[] buffer = new char[1024];
        Reader reader = new BufferedReader(
                new InputStreamReader(in, "UTF-8"));
        int n;
        while ((n = reader.read(buffer)) != -1) {
            writer.write(buffer, 0, n);
        }
        httppost.setEntity(new StringEntity(writer.toString()));

        Enumeration headernames = request.getHeaderNames();
        while (headernames.hasMoreElements()) {
            String headerName = (String) headernames.nextElement();
            String headerValue = request.getHeader(headerName);
            httppost.setHeader(headerName, headerValue);
        }
        Header h1 = httppost.getFirstHeader(HTTP.CONTENT_LEN);
        if (h1 != null) {
            httppost.removeHeader(h1);
        }
        Header h2 = httppost.getFirstHeader(HTTP.TARGET_HOST);
        if (h2 != null) {
            httppost.removeHeader(h2);
        }
        httppost.setHeader(HTTP.TARGET_HOST, "host");

        HttpResponse httpresponse = httpclient.execute(
                new HttpHost("host", 443, "https"),
                httppost,
                new BasicHttpContext());
        HttpEntity output = httpresponse.getEntity();

        Header[] headers = httpresponse.getAllHeaders();

        for (Header header : headers) {
            if (!header.getName().equals(HTTP.CONTENT_LEN)) {
                response.setHeader(header.getName(),
                        header.getValue());
            }
        }

        if (output != null) {
            out.write(EntityUtils.toString(output));
        }
    } catch (Exception e) {
        e.printStackTrace(out);
    } finally {
        in.close();
        out.flush();
        out.close();
    }
}
private DefaultHttpClient httpclient = null;

If the target server uses self-signed SSL certificates you might want to apply the code in Avoiding the “javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated” with HttpClient.

In order to use use the servlet make a local copy of the WSDL of the target web service and change the port address into the URL of the servlet, e.g.:

<wsdl:definitions>
  [...]
  <wsdl:service name="TargetWS">
    <wsdl:port name="TargetWSSoap12" binding="tns:TargetWSSoap12">
      <soap12:address location="http://localhost:8080/NTLMProxyApp/NTLMProxyServlet" />
    </wsdl:port>
  </wsdl:service>
</wsdl:definitions>

Use this modified copy of the WSDL in your BPEL process of SoapUI project.

Oracle starts 2011 very strong with a major release of FMW 11g Patch Set 3 (PS3). Officially this is a patch but Oracle always adds new functionality to a PS release. First, FMW PS3 is a full release and not a patch on PS1 and PS2. All the products can be directly installed on WebLogic 10.3.4. Big High Five from the administrators and developers. In this post I will tell you the important new features and provide you the PS3 links so you can download or read more about this release.

I start with WebLogic, ADF , SOA Suite and OSB. At this time Oracle did not publish the new features and bugfixes of WebCenter (will be released later) & BPM.

WebLogic, Version = 10.3.4 and in this release Oracle provides a WebLogic Apache Maven Plug-in. This plugin allows you to perform deployment operations similar to those supported by the command-line utility. And in 10.3.4 WebLogic has support for JPA 2.0 Providers.

ADF, with version 11.1.1.4.0 Oracle supports ADF on IBM WebSphere , Significant update to ADF Desktop Integration (Microsoft Excel Client) and Design-time support for creating JMX data controls.

SOA Suite version = 11.1.1.4.0 . The SOA Design plugin in JDeveloper now support BPEL 2.0, The BPEL editor in JDeveloper can generate BPEL 2.0 code and introduces several new activities. SOA Suite can now be run on IBM WebSphere Application Server. And the last is the single server do it all feature, previous called single domain (OSB in PS2 already supported this). This is so called developer release installs BPM, SOA , ADF and EM on one single WebLogic Server (The adminserver), this will reduce the required memory on 1 machine.

OSB also version 11.1.1.4.0. Oracle Service Bus provides support for the Oracle JCA Adapter for Files/FTP , this feature is nice when you have to work with big files and works better then the native file transport with big files. HTTP transport has been enhanced to provide access to individual query parameters in the query string.

Links

• WebLogic 10.3.4 Release notes
• ADF Release notes
• SOA Suite & OSB Release notes
• PS3 Documentation

 
The download page is different then that of PS1 & PS2. For PS3 Oracle made a new page with all the FMW products, here is the link http://www.oracle.com/technetwork/indexes/downloads/index.html.

Apache Camel is an open source integration framework that implemented the patterns which are mentioned in the book Enterprise Integration Patterns. Some many people say this book is the bible in the integration space. According to Claus Ibsen the Camel framework lets you focus on the business problem. Source code can be written in such a way that everybody (‘even your boss’) can read and understand it. Example code:

from("queue:a").filter(header("foo").isEqualTo("bar")).to("queue:b");
from("queue:c").choice()
    .when(header("foo").isEqualTo("bar")).to("queue:d")
    .when(header("foo").isEqualTo("cheese")).to("queue:e")
    .otherwise().to("queue:f");

Apache Camel has no container dependency and is payload agnostic. Camel is just a library. You do not need to use Spring in order to use Camel. It provides a Developer Web Console in which you can edit Routes. Soon a visual tool called FuseSource Rider will be available. Other features include a fully asynchronous non-blocking routing engine, which facilitates high scalability.

Camel offers a few ways of error handling: ErrorHandlers like the DeadLetterChannelErrorHandler or using the doTry and doCatch methods:

from("direct:start")
     .doTry()
        .process(new ProcessorFail())
        .to("mock:result")
    .doCatch(IOException.class)
        .handled(false)
        .to("mock:io")
    .doCatch(Exception.class)
        .to("mock:error")
    .end();

A great article on Camel: architects.dzone.com/articles/apache-camel-integration

Quick Reference card of Camel: cheat-sheets.biz/saved-copy/rc047-010d-enterprise_integration_patterns_1.pdf

Claus Ibsen’s blog: davsclaus.blogspot.com.

In December 2010 Manning will release the book Camel in Action, written by Claus Ibsen.

HTML was never really designed to do what it is doing: Applications. HTML5 is going to change that. HTML5 is a collection of features  which will enable us to build applications.

It seems that Adobe Flash will disappear. Applications like YouTube are moving away from flash video.

With HTML5, instead of trying to figure out which browser is being used, feature detection should be used. Modernizr can be used to do this. If you would like to check the HTML5 features of your current browser you can use the website www.findmebyip.com.

In HTML5 there will be many input new types: for phone numbers, search, date pickers, etcetera. These input provides functionality like form validation of the input. If the browser does not support the input type the input type will be defaulted to “text”.

We have been abusing cookies for a long time. HTML5 offers offline support. The web application is able to cache the data. This is a huge step forward. Other great features of HTML5: multithreaded Javascript support in the background using Web Workers; gradient support, video. Video is not a plugin, but part of the page, so it is possible to style, spin, and drop shadows.

HTML5 resources:

• html5demos.com
• diveintohtml5.org

HK2 is the library used in Glassfish for doing the lookup and instantiation of modules (and all the depending modules). It wraps the OSGi implementation, which can be Felix or Equinox. The OSGi is wrapped because OSGi itself is too complex. The HK2 has a service based architecture. In the modules annotations @Service, @Contract, and @Inject are used. Services are components with a scope. No class-loader is actually created until a service is actually requested. HK2 is open source: hk2.dev.java.net

HK2 is the base of Glassfish and will also be part of WebLogic Server. Glassfish and WebLogic AS have different purposes. According to the speaker the two will co-exist. Glassfish is an application server with a very fast startup-time and loads modules lazily. It is very useful  for developers, because it facilitates changes in source code. You can keep Glassfish running while changing the source code. WebLogic Server is different, because it wants to load many modules at startup. It is more suitable for deploying components in a controlled manner. The lifecycle (runtime states) in WebLogic Server is more sophisticated than the one used by Glassfish.