Friday, August 31, 2007

EJB3 local bean access in servlet using glassfish

I was trying out Glassfish.

I made a separate ear with a stateless bean and a war with a servlet that accesses the stateless bean using @EJB injection. I deployed the ejb jar file and also the servlet war file. It did not work. The error was that the servlet did not find the ejb.

Reading the glassfish docs I came across this question in the glassfish faq.


Question: I have an EJB with a Local interface. Can I access it from a web component in a different application?

Answer: No, not in our implementation. The EJB spec only requires local ejb access from within the same application in the same JVM.


Actually that makes a lot of sense.

All I needed to do was to have an ear file with both the war and ear as modules. That way the local EJB could be found by the servlet.

Since the servlet needed to access the local interface I also packaged the interface in WEB-INF/lib/ejbinterfaces.jar folder.

serialVersionUID from java 5

I started using eclipse with java 5. I got this a compilation warning in one of the realizable class, which said something to the effect that it needs a 'serialVersionUID' field.

The 'serialVersionUID' field helps with making sure that the version of the class that has been serialized, is the same as the version of the class that is de-serialized and if it is not the a invalidClassException is thrown.

The field looks like 'private static final long serialVersionUID = 42L'.

Since it needs to be a static field, i guess each class and it's subclasses will need have one field per class declared if there is a heirarchy of classes that need to be serialized.

Tuesday, August 21, 2007

Some notes on the new java 1.5 concurrent api

In the new java 1.5 Concurrent api, there is a lock.tryLock method, which returns false if the lock is already acquired by some other thread.

I have been in situations where I needed to know if an object lock(via synchronized(object a)) had already been acquired or not.

I guess it is simple now with the above 1.5 api.

However the other important thing to know is, if an object lock is in wait state or not before calling wait or notify on the lock. The 1.5 api has a Condition interface, but i did not see any kind of isWaiting method.

In java 1.4 i have achieved this by using volatile booleans, setting the boolean just before calling wait and then unsetting the boolean just after the notify.

Since wait and notify need to happen in synchronized blocks, this method has worked. However i would like to have an isWaiting api for locks.