In the last day I’ve fallen foul of five bugs reported against the WLS 10(*) EJB3 implementation.
From the simplest to the worst the bugs are:
The EJB and the resource injection fail
The container says that it fails to inject a resource of type X even if it finds the resource and it reports that it is of the type X. The problem is fixed from the release MP2 and exists a patch for the MP0 release. There’s no public patch for the MP1 .
The workaround is to use the old style JNDI lookup.
Sometimes the container fails to load an EJB into the JNDI tree
The problem occurs if you indicate the remote interface like
@Remote(<Interface>.class). The container loads the EJB, ie into the JNDI tree you found the reference Ear#Jar#Bean_Interface, but it doesn’t insert it into the JNDI tree as an interface instance. As workaround you have to declare the interface as an array, ie:
The @ApplicationException is ignored
Even if you annotate an exception as an application exception it is send to the client wrapped into an EJBException. No workaround exists.
- WLS does not loads class greater than 64 KB
WLS successful starts the application, but the container silently fails to load an EJB where the class file is greater than 64KB, a 2K LOC source file may pass this limit. No workaround exists and a closed bug is reported, against WLS 9.1, with a limit of 40KB.
The T3 protocol does not balance or do fail over for an EJB3 client
In a clustered environment the T3 protocol is adopted instead of the standard IIOP procotol for the load balance and fail over features. The T3 works fine for the EJB2.x but it acts like IIOP for EJB3.
A release was cancelled by this bugs….
(*) The bugs are reported against WLS 10 MP 1.