Fresh releases from Mobicents Kitchen

Last week or two were quite fruitful for mobicents team. What came out from under our hood?
Well:

• Jain MGCP Stack RC7 - last RC, more info can be found here.
• Diameter 1.2.0 GA - JSLEE 2.x resources, more info can be found here.
• MMS 2.0.0.RC1, first Release Candidate from 2.x trunk of MMS, more info can be found here.

More will come.

Maven Archetypes update

Some changes in maven tools in mobicents platofrm:

• fix metadata
• add jslee 1.1 service archetype

So now all desired archetypes are there.

Maven archetypes can be found here.

Also there is good article how to use archetypes to quick start projects, it can be found here.

How to use archetype from CLI? Please follow:

1. checkout
2. install with mvn install
3. use following command(for service):  mvn archetype:generate -DarchetypeGroupId=org.mobicents.tools.maven.archetype.slee -DarchetypeArtifactId=jain-slee-11-service -DgroupdId=xxx.y -DartifactId=TestSLee11Archetype_service -DarchetypeVersion=1.0.0.BETA2-SNAPSHOT , where:

• archetypeGroupId - archetype group
• archetypeArtifactId - id of archetype
• archetypeVersion - archetype version, once it is released, it should not be required
• groupdId - new groupd id of created project
• artifactId - new artifact id of created project, also directory name

JSLEE 1.1 service composition vs class loading

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.