Getting started on seam-security, picketlink IDM and JPAIdentityStore

I love how JBoss 7(.1) has everything working out of the box – not much fiddling with jars or suchlike and with Arquillian, everything really was a treat to get started on a new project. This was until I had to sort out security with seam-security.

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 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

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.

Continue reading

Using CXF Interceptors to do some magic around your web service calls [1105]

We use JBossWS CXF for a heavily utilised enterprise system. It links into spring to pick up and execute beans. We have a bunch of exceptions that could get thrown.

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.

	private SOAPFaultException convertToSoapException(ApplicationException e)
		try {
			if(null == soapFactory) {
				soapFactory = SOAPFactory.newInstance();
			SOAPFault sf = soapFactory.createFault();
			sf.setFaultString( e.getMessage() );
			sf.setFaultCode( Integer.toString(e.getErrorCode()) );
			return new SOAPFaultException( sf );
		} catch(SOAPException soapException) {
			throw new RuntimeException( soapException );

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…

Continue reading

JBossWS CXF – POJO vs Stateless [1104]

Cleaning up a bunch of code to reduce object instantiations got me thinking about the webservice layer. We are using POJO based webservices but it got to me wondering whether useless Stateless web service beans would improve memory usage. More accurately, whether it would improve garbage collection performance.

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.

Continue reading

Register / Attach Service to JMX

Registering a Bean within JMX (at least in JBoss) is very straightforward. It requires an interface with attributes (getters and setters) and operations.

MBeanServer server =;
ObjectName objectName = new ObjectName("jboss.cache:service=TcpCacheServer");
server.registerMBean(objectToAttach, objectName);

objectToAttach is an object with a JMX’able interface.

Java Object Size In Memory

Anyone who has worked with java in a high end application will be well aware of the double edged sword that is java garbage collection. When it works – it is awesome but when it doesn’t – it is an absolute nightmare. We work on a ticketing system where it is imperative that the system is as near real-time as possible. The biggest issue that we have found is the running of of memory in the JVM which causes a stop the world garbage collection, which results in cluster failures since an individual node is inaccessible for long enough that it is kicked out of the cluster.

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.

Continue reading

rich:calendar and the onchange event

I wanted to trigger some validation based re-renders with the rich:calendar component. I was scratching my head for a while trying to figure out why it wasn’t working.

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…

Maven2, EJB3 and JBoss

I started work on a project called InVision about a year ago but have probably spent about a week or two worth of effort on it in total… 😦

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

<persistence-unit name=”em”>

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…

Hibernate Domain Model Testing

One of my pet peeves with Hibernate has always been how difficult it was to test it. I want to test the persistence of data, loading the data back and any specific funtionality with the domain model.

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:

public class CompanyTest extends DOMTest<Company> {

public CompanyTest() {

The system (with the help of testNG) is also easily flexible to define object model dependencies. Just override the persist method (which just calls the super.persist) and define the groups to be persist and <object>.persist

in this particular case, it would be


@Test(groups={“persist”, “Company.persist”}

public void persist() {



For all dependent classes, I then depend on the Company.persist group (For the ContactTest class for example, since it needs to link to the Company object)

You can specify OneToOne and ManyToOne relationships with just the CSV files – just defining the field name and the id of the object to pull in.

ManyToMany is more complex and requires an interim object to be created within the test section. If the Contact to Company relationship above was ManyToMany, we would create a ContactCompany class with just the two fields – Contact & Company, then create a csv file with three fields, id, Contact, & Company. The framework currently always needs an id field.

You would then need to write a method within the ContactTest or CompanyTest(I use the owning side) to read the CSV file in and pump the data. This process is a little bit complex just now.

With an appropriate amount of test data, you are able to write a test suite that can consistently test your domain model. More importantly, you can configure it to drop the database at the start of each run so that once the tests are complete, you have a database structure and data than can be used for testing of higher level components (EJB/Spring/UI/WebApp)

We currently use this framework to test the domain model as well as distribute a data set for development and testing of the higher tier functionalities.

For the future, there are several additional features this framework needs:

  • It currently needs the setters/getters & constructors to be public. This needs to be FIXED
  • Refactor the ManyToMany Relationship code to make it easier and simpler to test and pump data
  • See if we can ensure that additional tests which data is done within a transaction and rolled back so that the database is left in the “CSV Imported” state on completion of tests
  • Easier Dependency management if possible

This framework is still inside the walls of Kraya, but once the above issues are resolved and it is in a releasable state, it will be published into the open source community. If you are interested in getting a hold of it, email me and I’ll provide you with the latest version.

The easier and quicker it is to test, the more time we can spend on writing code… 🙂 The higher the coverage of the tests, the more confident you can be of your final product.

To more testing…