To be fair, the main issue was just poor documentation. It took me a day to sort out what should essentially have taken an hour(or two)

The documentation you get to from http://www.seamframework.org/Seam3/SecurityModule seems to be out of date. The fact that the page referes to version 3.0.0.Alpha1 and Alpha2 should have tipped me off but the url for the doc suggested it was the latest.

The more up to date documentation I found was at http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/pt04.html

I followed chapter 33 on there and I won't repeat it here for the sake of brevity.

What follows are the additional steps I had to take to get it to work.

I ran into a javax.enterprise.inject.CreationException, the relevant part of the stack trace being:

To resolve this,  I had to add in the @IdentityEntity Annotation to the IdentityObjectType class

The next exception was org.picketlink.idm.common.exception.IdentityException: Error creating identity object. The relevant part of the strack trace being:

It turned out that the entitymanager was not being picked up and it was null. This part was probably in the documentation earlier with regards to configuring seam but I had skipped directly to the security section so missed it. We need to define the persistence unit with the beans.xml. I have included my full file below.

This brought us further forward still. The next exception was:

This was related to missing data in the database. It needed a credential type. I created one for password.

This brought us forward on to the next exception: org.picketlink.idm.common.exception.IdentityException: Exception creating relationship

with the relevant part of

This was solved by adding in a relationship type

Both the sql statements were put into import.sql and hibernate is configured to create tables. My test case is as follows. It was taken from https://github.com/seam/seam-example-confbuzz/blob/develop/src/test/java/seam/example/confbuzz/test/integration/LoginIntegrationTest.java and modified.

Do comment and let me know if it helped :-D

To simplify it, the code was originally written to create an anonymous class a la Runnable which is wrapped around a try catch block. The exceptions that are thrown are then converted to a soap fault and passed back.

Nothing inherently wrong with this. However, there are a couple of issues with this in that each soap method is set to throw an ApplicationException and there is not further documentation of which of the subclasses are actually relevant to that method.

In a runtime environment, this is not hugely relevant. However, when generating documentation from the WSDL’s, it is.

To resolve this, we changed each method to throw their relevant exception, and wrote an interceptor to pick up the exception and convert it…

The first step was to write an interceptor which is surprisingly simple and straightforward.

The class doesn’t need to extend the AbstractSoapInterceptor but you would then have to manually implement a number of mechanisms that the abstract class provides.

The constructor simply defines where this interceptor should be inserted into as part of the chain. There is a whole bunch of different places where it can be inserted based on this. Information can be found in their documentation.

To insert this interceptor into a web service, the service needs to be annotated as follows:

Each exception thrown from the web service will now be intercepted. You can then include any further further information in the soap fault.

In this particular case, the only thing that gets done is to update the fault code with the error code set against the exception. Any additional information can be set against the soap fault at this point. You can also log as we are doing.

To test this, the plan was to build two versions of the same web service and load test it to see the memory and cpu utilisation to compare cost / performance.

In the process, I also discovered other differences.

Both the web services were built against this interface

That is of course a simple enough interface.

The EJB version of this is as follows:

Simple and straightforward enough and the POJO version is not that different

I also used the following web.xml. This may not be a necessary step any more.

Now that was complete, there was the deployment to consider. I had assumed that I could just do one build, package it as an war and just deploy it but as it turns out, that didn’t work. This only deployed the Pojo web service. To deploy the EJB web service, I had to package it as an EJB (maven) and deploy a jar file.

This meant that I ended up with two deployments, wstestpojo.war and wstestejb.jar.

Once deployed, I used SoapUI to load test both the web services and the results were interesting.

In the grand scheme of things, the difference was pretty minimal between the two. However, the Stateless EJB web service used a little extra (3% - 5%) CPU presumably from the pooling of the beans and accessing them.

I used JBoss 5.1 and ran into an issue with log pollution

EJBTHREE-1337: do not get WebServiceContext property from stateless bean context, it should already have been injected

This was printed every time an EJB based web service was called.

I found more information about the EJBTHREE-1337 issue and a workaround for it The workaround simply involves updating log4j to not log it which is good enough for me… :-)

As a final note, I am unsure as to how this would scale with complex web services that have multiple instantiated objects as part of it.  I have a sneaky suspicion that web services with expensive object instantiations would perform better if using Stateless EJB Beans as would web services that are memory hungry. However, this has not been tested.

There are various ways to combat this issue and the first instinct would be suggest that there is a memory leak. After eliminating this as a possibility, the next challenge was to identify where the memory was being taken up. This took some time and effort and the hibernate second level cache was identified. We were storing far too much in the second level cache.

This is another double edged sword. The hibernate second level cache is absolutely imperative to a high performance system. It does however, come with a price. The cache needs to be managed carefully to ensure that balance between performance and memory requirements.

To this end, it was important to be able to identify what was taking up all the memory in the cache. Each object might only take a couple of hundred bytes, but with our second level cache set to store hundreds of thousands of items, this quickly takes up hundreds of megabytes. With the metadata of the cache, this could easily hike it up near a gigabyte of memory usage. This gets substantially worse with cache evictions and the adding of new items into the cache.

The correct way to resolve this is to identify specific object types that “overload” the cache. i.e. items that have an large number of instances stored in the cache. Identifying classes that store a large number of items is easy enough - we just traverse the cache and count up the number of items. However, there might be a class that stores a smaller number of items but take a sizeable amount of memory. For this reason, it is important to understand the object sizes in memory as well.

If you have ever tried to find a way to identify object sizes, you will know that this is no easy task. You can calculate to some degree of accuracy the size of an object based on the data it stores but this is a manual process.

The only real way to get this information is to use a java agent and use that to calculate a more accurate memory usage. For this purpose, we used the classmexer agent which requires a simple installation step of adding the following parameter to java -javaagent:classmexer.jar. You can then figure out the memory utilisation of an object by calling

You can also pass in a collection of objects:

This was the simple part.

Traversing the node structure of jboss cache and collating a collection statistics with regards to the number of each type of object and its memory utilisation was a little more interesting.

I will cover this separately

Then it happened, its supposed to be onchanged. This particular component requires the extra d at the end… and it worked and everyone lived happily ever after…

The Project aim was to bring together the easy time logging capabilities of Process Dashboard along with the project management capabilities of Microsoft Project (including the Server Component). It is also to be integrated into our request tracking System - Request Tracker. Eventually, it is also to integrate with our accounting system and turn into an ERP (Enterprise Resource Planning) system and MIS (Management Information System). There are plans to integrate with our Wiki and our Document Management System too.

But these are all lofty goals.  One of our recent projects introduced me to the Spring Framework. While I am still not a fan of Spring, the scale of the project and the way of approaching it gave me some ideas and additional tools to work with. I wanted to bring these into the InVision Project.

The key one here was Maven 2. InVision already used EJB3 and JBoss (4.2 as it happened). There was one additional issue for me to resolve and that was out of container testing. Something that is very easy to do with Spring but a little more troublesome with EJB3 since it doesn’t have an out of container framework…

I have grown to be a big fan of Maven 2 and using Maven 2 to configure an EJB project is not as easy or straightforward as I would have liked: I wanted to separate the whole project into four parts

• Domain Model (or just the entity beans); Also referred to as a Hibernate Archive (HAR)
• Stateful/Stateless Beans (Just the Beans, since I don’t consider entities beans in EJB3)
• Application Client (J2SE Application)
• Web App (Using SEAM)
• I would also need an EAR project to deploy the DomainModel, Beans & WebApp as one pacakge into JBoss.

I have not got as far as the SEAM project yet but the other ones were straightforward enough to set up with Maven 2.

Both the Domain Model and the Beans project had to be set up as ejb projects and use the maven-ejb-plugin

I set up the persistence context within the Domain Model

I could then reference the context from the Beans project by injecting it with

Easy enough!

Now configuring the EAR project: This was configured as an ear package which depended on the other two projects with the following configuration

With this configured, from the EAR project, I could do mvn ear:deploy to deploy to JBoss.

Additionally, within eclipse, I created a new run-type that ran ear:undeploy package ear:deploy to re-deploy the package to JBoss. Works a treat

There are still a few kinks to be ironed out.

I still need to install (mvn install) the two projects before the EAR will pick it up to deploy. I need to get the ear re-deploy to re-build the other projects. Something to look at another day.

I had manually deployed the DataSource file to JBoss. It might be possible to do this via Maven.

I also very much liked the Eclipse automatic deploy feature. It is possible to use the eclipse plugin on maven to get Eclipse to identify this as a JBoss deployable project but I ran into some problems and gave up. Ideally, Eclipse would auto-deploy the project.

However, the above is less relevant once Out-Of-Container testing is in place. Now, this does work, but I will leave that to another day…

Simple? NO! The main problem was the management of the data set. I had set up, in the past fairly interesting classes to test the functionality using reflection, and injecting the data from the classes themselves through the data provider mechanism of TestNG. However, this was error prone and clunky at best. It also made dependency management of data quite cumbersome.

With a view to resolving this, I also looked at DbUnit, unitils and Ejb3Unit. They all did some things that I liked but lacked some functionality that was important.

This led me to write a simple testing infrastructure. The goal was straightforward.

• I need to be able to define data in a CSV (actually it was seperated by the pipe character |, so PSV) based on entities.
• The framework should automatically persist the data (and fail on errors)
• It should test that it can load all that data back
• It should run as many automated tests on the DOM as possible.

The framework uses the CSV files to read the data for each of the classes (using the excellent SuperCsv library). It needs an Id field for internal reference. As long as the id’s match within the CSV files for the relationships, it will be persisted correctly into the database even when the persisted id’s are different.

For example, I could have a Contact.csv with 5 records (ids 1 through 5) and a Company.csv with 3 records (ids 1 through 3).

The Contact.csv records can map to the id specified in the Company.csv file and when the records get persisted, they will be associated correctly, even if the id’s in the database end up being different.

The framework also looks for the CSV file which has the same name as the class within the location defined within the configuration file. This means that as long as the filename matches the class name, the data loading is automatic.

For simple classes, the Test case is as simple as: