My last post about JSLEE 1.1 describes theory of classloading in v1.1 containers. However, how does it look in practice?
Well, I must say it looks and works much better than earlier model. But.. yes, there is one small "but", due to inheritance restriction it may sometime prove to be problematic, atleast for certain cases.
Case 1: General Class Loading scheme
To make problem a bit closer, lets consider two services, each service is composed from the same sbbs:
- Sbb[1]
- Sbb[2]
- Sbb[3]
Each sbb references the same RA Types and Profiles
- RAType[1]
- Profile[1]
- Profile[2]
To make this a bit more complicated - each service is independent. That is each can be deployed separetly and provide service.
Now lets imagine two things:
- SBBs extends super class which provides common fields(RA Type SBB Interface) methods to manipulate profile, etc
- There is shared Utility class which manipulate RA Type message factories to create specific messages, manipulate profiles, etc.
Now there is no problem in 1.0 container as classloading was flat. Everything works fine, one or many sbb jars/DUs - it still works.
However when one wants to deploy this set of services in 1.1 container, problem shows. In 1.1 container (as it is a bit more organized) we would like to have everything separated:
- library(Library[1]) with: super class of SBBs, Utility classes and similar
- sbb-jar.xml, sbb-jar file for each sbb
- DU for each somponent - services,library,profile and RA
Since library contains classes each sbb use, each sbb-jar.xml declares dependency on library.
From first glance it looks like this deployment should work from kick. Well, it wont...
Lets consider Utility class, it operates(depends) on:
- RA Type events
- RA Type classes
Sbb super class is very similar in this matter. Both classes are contained in our Library[1].
What is wrong? Library[1] does not have any way of referencing RAType classes. That means that Utility class (as well as Sbb super class) has no access to definition of those classes. This will cause failure during runtime or sbb verification.
Conclusion: using single jar file for sbbs allows to make this problem dormant. However there seem to be more favored way for 1.1 container. That is:
- each functional component declares library with classes it uses
- functional component declares dependency on its library in its xml file
- any other component may ow declare dependency on library to use certain classes
For this example it would mean following:
RA Type[1] Library[1] is declared. LIbrary[1] declares dependency on RA Type[1] Library[1].
Case 2: Event sharing
This problem happens only on shared deployment. That is JSLEE and non JSLEE aplication is deployed in the same container.
Lets consider simple web application which fires event "X" into SLEE. Event "X" is received and processed by SLEE service.
This makes it clear that X.class should be present in two places:
- SLEE - since there is service depending on it.
- web application archive, since it fires it.
Since JSLEE v1.1 container no longer shares its classes outside container, it is logical to assume that jar containing X.class should be in both: JSLEE and web archive.
Well, logic fails here. It wont work. It will cause well known exception:
ClassCastException: Can't cast X to X
To make this work following steps should be followed:
- jar containing X.class should be in container library directory
- events.jar deployed within SLEE should contain only xml file with even definitions
Thats it.
