Friday, October 30, 2009

Portal Update November 2009 and Java Buzz

After a busy summer I think it is absolutely necessary to summarize the latest updates in the Java Portal space.

From the commercial side, major players are:
  • Oracle WebLogic Portal:
    The current release is still WLP 10g3 but soon we expect the first 11g release with codename "Sunshine".
    Major improvements are
    - JSR-286 compliance (Portlet 2.0)
    - WSRP 2.0 support (Event based coordination, IPC for remote portlets, resource serving)
    - Full interoperability with WebCenter in both directions
    - Improved Ajax support
    - VCR Direct SPI Support for UCM
    - Even more REST APIs to access portal informations
    - New REST API to access Unified User Profile data
    - First support of the new Content Management Standard driven by Oasis: CMIS
    - Apache Beehive still supported but not enhanced
    - Replacement of Autonomy Search Engine by SES

    The REST API Architecture in WLP 11g:

  • Oracle WebCenter Suite 11g R1:
    WebCenter Suite includes the formerly known product AquaLogic Interaction by BEA, now called WCI, WebCenter Interaction. Download it here.

  • Adobe: Adobe? Yes... Since the new release of Adobe ColdFusion 9, there is a new portal player to be considered when it comes to interoperability based on JSR-168/286 portlets. ColdFusion 9 is now fully compliant with the Portlet Containers from the Java world.

  • IBM WebSphere Portal 6.1: no updates.
Open Source portals that have the most promising potential at the moment are:
  • JBoss Portal and eXo Portal have been merged!

    This latest interesting announcement has been made official on Sep 3rd at the JBoss World in Chicago. eXo has fully committed its entire open source portal stack to Red Hat’s newly introduced GateIn portal project extending it with cutting-edge collaboration features as well as document and content management features.

  • Liferay Portal 5.2: no major updates since last post.

  • SUN continues to offer the Web Space Server based on the Liferay Portal source code. No major updates besides a brand new white paper.

  • JBoss Portal 2.7.2:
    - Since June 2009, JBoss fully focused on the new project GateIn

  • eXo Portal 2.5.1: no updates besides GateIn announcements

  • Jetspeed 2.2.0: After quite a long time without updates a new version has been released (summer 2009) that is fully JSR-286 compliant! The new version comes along with quite a bunch of updated documentation pages... So it would be worth to have a look at it again. Download it here.
Besides the Portal related activities, let's have a look on Java related quick news:
  • Java EE 6: The JSR-316 has reached Proposed Final Draft. The hot discussions between JSR-299 vs JSR-330 have finally found a common resolution and both will be part of EE6 where JSR-299 will be based on the dependency injection specification defined by JSR-330.
  • Oracle has still not acquired SUN : The OK from EMEA is still pending.
  • JSF 2.0 : Mojarra 2.0, the production-quality, reference implementation for JSF 2.0 is out! This will of course be part of GlassFish v3 (final release planned for Dec-12th 2009) but you can grab the bits right now for your first dirty hands-on experience!
  • IntelliJ IDEA is now available in two editions. The Community Edition (JavaSE-focused) is now Available under OpenSource at
  • Geek Food: I discovered mainly two new things that I found diserve a Geek award:
    - Prezi ! Forget PPT and Google Presentations... Old school!
    - Play ! Clean alternative to develop JavaEE apps based on RESTful architectures.
  • Google Wave: I finally got an account (thanks a lot J. !!) but up to now I'm rather disappointed... nonetheless, the full features are not released yet, so I'm ready to get blown away. If you are interested, I still have some invitations left :-) Start your wave!
  • JavaOne 2010 : ... no, still no signs whether there will be a next JavaOne :-(

Unit Testing EJBs and JPA with Embeddable GlassFish

Java EE 6 has been a topic here at CTP for quite a while now. During summer I had the pleasure of conducting an internship which was targeted to explore the possibilities of the upcoming standard, namely EJB 3.1, JPA 2.0, JAX-RS, JSF 2.0 and JCDI on top of GlassFish v3 - and it turned out surprisingly productive, although all implementations were far from being in a release state!

Only one thing we failed to run in a stable way: The new EJB 3.1 container API refused to run our unit tests. The main problem was JPA support - persistence units got not recognized and EJBs usually failed with a NullPointerException calling the EntityManager.

Alexis and Adam recently blogged about this specific feature, and of course I had to get back and try it out myself! Indeed, starting up a container and looking up EJBs works fine. But to test your Entities there are still a few tweaks you might want to apply.

Start with creating a Maven project and add the embeddable GlassFish dependency. I'm also using TestNG instead of JUnit, as it has a nice @BeforeSuite annotation which allows starting the container only once before running your tests.



As described in Alexis' blog, you can start your EJBContainer with a reference to your GlassFish domain. This will allow you to start up data sources you most probably need to properly test your JPA code.

The disadvantage here is that you either depend on a hardcoded location or a system property which each of your team members have to set. Or, in case of your continuous integration system, you might not want to have a GlassFish installation at all.

Fortunately you can create a mini GlassFish domain with only a few files. The image below shows the files you need and how I placed them in my Maven module:

You can take your existing domain.xml containing your data sources and place it in here - you can reference it now relatively to your module location. Your unit tests then start with:

private static Context ctx;
private static EJBContainer container;

public static void createContainer() {
Map<String, Object> properties = new HashMap<String, Object>();
properties.put(EJBContainer.MODULES, new File("target/classes");
container = EJBContainer.createEJBContainer(properties);
ctx = container.getContext();

This will run your unit tests against your development database. In case you want to run them in a local database, you can simple replace the connection pool config in your domain.xml, e.g. with a local Derby installation:

<jdbc-connection-pool datasource-classname="org.apache.derby.jdbc.EmbeddedDataSource"
res-type="javax.sql.DataSource" name="[your DS name]" ping="true">
<property name="ConnectionAttributes" value="create=true" />
<property name="DatabaseName" value="./target/unit-test" />
<property name="Password" value="" />
<property name="User" value="" />

This creates the database in your target folder and requires adding Derby to your Maven POM:


Unfortunately this setup might not match with the configuration in your persistence.xml and generate invalid SQL for your test database. You can either solve this with Maven filters in different profiles, or alternatively create a staging directory for your EJBContainer. I'm using the Apache Commons IO tools here for convenience:

private static final String MODULE_NAME = "embedded";
private static final String TARGET_DIR = "target/" + MODULE_NAME;

public static void createContainer() throws Exception {
File target = prepareModuleDirectory();
Map<String, Object> properties = new HashMap<String, Object>();
properties.put(EJBContainer.MODULES, target);

private static File prepareModuleDirectory() throws IOException {
File result = new File(TARGET_DIR);
FileUtils.copyDirectory(new File("target/classes"), result);
FileUtils.copyFile(new File("target/test-classes/META-INF/persistence.xml"),
new File(TARGET_DIR + "/META-INF/persistence.xml"));
return result;

You can use the @AfterSuite annotation to clean up the temporary folder. Note that with this setup, the EJB lookups change:

protected <T> T lookupBy(Class<T> type) throws NamingException {
return (T) ctx.lookup("java:global/" + MODULE_NAME + "/"
+ type.getSimpleName());

Wednesday, October 21, 2009

Oracle WebLogic Server Versions

I recently got confused with the version numbers of the Oracle WebLogic Application Server, some people use the internal (BEA) version number, some refer to the Oracle release number.

So the following list should clarify the mapping between these two versioning schemes:
  • WLS 10g3 (10.3.0) : recent version but used by latest WebLogic Portal 10g3
  • WLS 11g R1 (10.3.1) : current version
  • WLS 11g R1 PS1 (10.3.2) : upcoming patchset version planned for Nov/Dec 2009
  • WLS 11g R1 PS2 (10.3.3) : another patchset anticipated March / April 2010

  • WLS 11g R2 : Planned for 2010. I haven't found any relation to a 10.x version at this moment.
    Oracle OpenWorld 2009 Updates: WebLogic Server 11g R2 in 2010 will get Oracle RAC and Coherence integrated to make them native in the application server. WebLogic Server will get RAC event awareness, providing fast connection and fail over, while Coherence will be managed as part of WebLogic - currently it's an external application.
  • WLS 12g : Planned for 2011. I assume this will be the Java EE 6 compliant release along with the release of all other Fusion Middleware 12g products.
Comments are welcome!

Friday, October 16, 2009

LambdaJ new trends in Java

I must say I really enjoy the presentations from the JUGS. Couple of days ago there was another one about lambdaj, presented by its author Mario Fusco. He is a big fan of Scala and that's why he wanted to bring this functional way of doing things to Java.

I think this is a trend and we are going to see this more and more. It all started with the dynamic languages built on the JVM and now more and more people want functional things. I guess it has to do with the fact that Java the language did not see much change over the last 8 years, and people see solutions that are nice for specific problems in other languages. For instance Rails, it's very good in solving one particular problem and the Java community did notice that. Not only did it get ported to run on the JVM it also brought us Groovy/Grails.

So the latest thing in Java land is functional programming. There are some things one could solve more "elegantly" by using a language that is functional in nature. An example of this is filtering collections, this is what lambdaj tries to do, making standard Java behave in a more function manner.

To give a couple of examples. To filter a list of beans in lambdaj you could write something like this:
int totalAge = sum(meAndMyFriends, on(Person.class).getAge());

This will work because you would do a static import of the Lambda class that has the sum and on methods. So to explain what happens, the sum method will iterate over the collection of Person objects and invoke the getAge() method and sum all the results. Actually it's very readable what will happen. Because the on method uses generics you'll even get code completion and you'll be able to use refactoring.

Even better is the sumFrom method, it will return a bean of the same type of your list and you can then call any method to get the sum from all the properties. Of course this will only work if your collection contains object instances, because java generics are not reified.

Person totalsPerson = sumFrom(meAndMyFriends);
int totalAge = totalsPerson.getAge();
int totalLength = totalsPerson.getLength();

This works because sumFrom gives back a Proxy object that is the same as the elements in the list. When you invoke a method on it, it still has a reference to the list so it will iterate over the list and sum the properties.

Another example:

List<Person> oldFriends = filter(having(on(Person.class).getAge(), greaterThan(30)), meAndMyFriends);

There are of course more frameworks that can do similar things. When I first saw this I thought of jxpath but the disadvantage of this framework is that when doing refactoring, you'll have to manually change the xpath queries. Another powerful framework that also takes advantage of functional paradigm is google collections.

But as Mario Fusco also pointed out at the end of his presentation.... If you can, you should really give Scala a spin. Then you will not need lambdaj, you will have something more powerful.