Andreas Schaefer's Blog

October 2003 Archives

jUnit to the Rescue

I was just recently faced with taunting task to revamping the transaction handling of the J2EE server without breaking it but improving performance and removing any resource leaks. Already two developers tried to do this but had problems to understand the existing code in the first place and so I failed, too. If we could not improve the code we had to dump the implementation and start all over again. Now just a few weeks before shipping I had to rewrite a central component without wasting other developer’s time and/or delaying the project. Lucky me jUnit came to the rescue. Instead of just starting to write a new implementation and then testing it I decided to write a test suite around the currently working code, replace the code and rerun the test suite ensuring that I did not break anything. Finally I had a chance to use test driven development (TDD).

As easy this sounds as difficult it was to implement. I spent around the same time for writing the test suite that to rewrite the transaction code but at the end testing was a breeze. The first hurtle was to decide how to test a transaction implementation because I did not want to rely on a DB, JMS etc and their side effects. So I wrote a fake XA resource that used JMS without transactions to trace the interactions with the transactions, various EJBs and 100+ tests. The first benefit from writing the test suite were a much better understanding of the transaction handling and its interaction with XA resources. At the end testing the new code was easy, straight forward and I missed one bug so far. The tests also made me very confident to put the code in the release branch without fearing to work on weekends just to fix undetected bugs.

So I have to give jUnit and TDD two thumbs up and see a beautiful friendship in the future. Nevertheless I have two little requests to the jUnit folks:

1. A way to write a message to the output file on a per test basis in order to write a description or other information out that later can be read and incorporate in a test suite report.
2. Currently there is only a successful or failed (failure or error) test result possible but sometimes it would be nice to keep non-crucial failures available but they should not fail the test suite. These warnings could be reported and even have a stack trace but would be considered a success. Examples of a warning could be a bug in a particular JDK or third party library that needs a work around but as soon as this is fixed the workaround should be removed or bugs that are postponed etc.

RE: File Access in EJB

As Simon Brown pointed out the J2EE specification restrict you to access files on the file system but sometimes you have to and then you need to control the damage by keeping the breach of the specification local and not to spread it all over your code. Being confronted with this question just recently I came up with these ‘solutions’:

• Putting a file into the archive and read it out as resource. Note that you can only read from this file.
• Using a JNDI environment entry containing the path to the directory and/or file that then can be used to open the file later in the code. This allows the deployer to adjust the value before deployment so that it points to a valid file/directory the application can read from and write to.
• Using JCA to expose a connection to a file that allows the client to retrieve the connection and then open an input stream like you do with an URL.

First I was thinking that only a file service (like JDBC or JMS) provided by the server could solve the problem. But after thinking it through using Entity Beans seems to be a much better way to share the data on a cluster than through a file service. Then I realized that maybe each deployed EJB needs to have its own file that is not shared on the cluster. I think it is very important for each J2EE developer to see that there is much more between heaven and earth that a specification can ever capture. But it is important for the future of the code/project that ‘unportable code’ is kept localized and under control and that the assumptions and restrictions of that code is documented well.

SLSB -> SFSB: Meaningless ?

A colleague of mine just pointed out that in Richard Monson-Heafel’s EJB book (3rd edition) configurations like Stateless Session Bean (SLSB) -> Stateful Session Bean (SFSB) are considered meaningless. I understand that any EJB book cannot deal with all possible scenarios otherwise you need a truck to take the book home but I find it too interesting not to talk about. Luckily I can discuss in my weblog any scenario I like and hopefully I can show you that rules are meant to be broken even when the result only confirms the rule.

Let us assume that we have a SLSB that has at least one business method in it that is quite elaborate and performs many tasks. In addition we want to have multiple resources or a non-standard resource wrapped in an EJB like a raw TCP/IP socket. Because the resource(s) should participate in a transaction and must be opened before usage and closed at the end it cannot be a SLSB because we never know what instance we get back on each invocation due the fact that the pool is returning the next free instance before a method is invoked. The only way left is to use an SFSB because a particular instance is available to the SLSB instance during the entire method call and so at the end I can close the resource(s) or do any other cleanup task. In this case the SLSB method does represent a client towards the SFSB even thought the life span of the SFSB is not that long.

Now one could object that I could just use a plain Java class instead of wrapping the resource(s) into an EJB but an EJB can use JNDI environment variable to specify setup properties, I can look it up very easily on a JNDI server and use an EJB reference in the Environment Naming Context (ENC) of the SLSB. Finally I can deploy the EJB in a separate application and use it throughout the server. One could also suggest using JCA instead but this could either overkill or what is wrapped in the SFSB does not adhere to JCA specification.

I want stress the fact that this rule should only be broken when there are compelling reasons to do so and you checked out the other options like keeping the code in the SLSB, creating a plain old Java object or using JCA and then selected the best solution that does not only fit you best now but also in the (near) future.

This work is licensed under a Creative Commons License.