Designing of jain-slee deployers for Jboss5.

[vickyk]

We have starting writing the jain-slee(mobicents components) deployers for Jbos5. I had created couple of deployers as

<?xml version="1.0" encoding="UTF-8"?>
<deployment xmlns="urn:jboss:bean-deployer:2.0">

 <bean name="SleeParserDeployer" class="org.mobicents.slee.container.deployment.jboss5.SleeParserDeployer" />

 <bean name="SleeDeployer" class="org.mobicents.slee.container.deployment.jboss5.SleeDeployer">
 <constructor><parameter><inject bean="JMXKernel" property="serviceController"/></parameter></constructor>
 </bean>

</deployment>

The slee deployment units are packaged as .jar artifact and thus existing Structural Jar Deployer should work as the structural deployer for this deployment unit.
Now as per the jain-slee specs it is required to have the set of MBean's doing the real deployment, these MBeans are already available in the older existing deployer implementation so we got to re-use it.
So the Deployers(parser/real) for the slee should delegate the deployment to those existing MBeans.

I have noticed that for the war deployment the slee deployers are also invoked which looks ok to me, as per my understanding all the deployment unit in Jboss5 will passed through the chain of deployers as added in the MainDeployers.
Am I right here ?

[alesj]

"vickyk" wrote:

 <bean name="SleeDeployer" class="org.mobicents.slee.container.deployment.jboss5.SleeDeployer">
 <constructor><parameter><inject bean="JMXKernel" property="serviceController"/></parameter></constructor>
 </bean>

Now as per the jain-slee specs it is required to have the set of MBean's doing the real deployment, these MBeans are already available in the older existing deployer implementation so we got to re-use it.
So the Deployers(parser/real) for the slee should delegate the deployment to those existing MBeans.

Then only inject those beans, no need for full ServiceControler.
If you need to use ServiceController, then output proper ServiceMetaData, instead of direct use of ServiceController.

"vickyk" wrote:

I have noticed that for the war deployment the slee deployers are also invoked which looks ok to me, as per my understanding all the deployment unit in Jboss5 will passed through the chain of deployers as added in the MainDeployers.
Am I right here ?

All deployers are invoked (per deployment stage) for every (sub)deployment.
It's up to you to 'ignore' them as soon as you know they are not relevant for your deployment unit.
e.g. contains the right attachment or only handle components or only top level ...

[vickyk]

"alesj" wrote:

Then only inject those beans, no need for full ServiceControler.
If you need to use ServiceController, then output proper ServiceMetaData, instead of direct use of ServiceController.

Well we might need to prepare the ServiceMetaData and pass it to Service controller, all this can be done before or after calling the required MBeans which does real deployments.I will need to analyze this in more details, the point is noted.

"alesj" wrote:

All deployers are invoked (per deployment stage) for every (sub)deployment.
It's up to you to 'ignore' them as soon as you know they are not relevant for your deployment unit.
e.g. contains the right attachment or only handle components or only top level ...

Yes I will have to handle in the deployers implementation, that was my understanding too.
Thanks for confirming it.

[alesj]

"vickyk" wrote:

Well we might need to prepare the ServiceMetaData and pass it to Service controller, all this can be done before or after calling the required MBeans which does real deployments.I will need to analyze this in more details, the point is noted.

No, that's exactly what I'm try to explain
--> you shouldn't be using ServiceController in any way.
If you prepare proper ServiceMetaData + output, attach it,
then the right deployer (in this case ServiceDeploymentDeployer) is gonna pick it up.

Since that's the whole purpose to have deployers running off metadata.
It's then super easy to insert additional behavior into deployment chain.

e.g.
1a) parse slee --> slee deployer --> smd transformation --> smd deployer
1b) parse slee --> slee deployer --> smd transformation --> NEW smd handling --> smd deployer
vs.
2) parse slee --> slee deployer + to MBeanServer

Where in 2nd case this 'NEW smd handling' doesn't affect my deployment,
probably making it invalid in the worst case.

[alexandrem]

Hi.

I'm developing the SLEE Deployers with Vicky Kak's help.

At the moment one issue has come which is the fact that the SLEE Deployer will require SLEE to be deployed before it processes any DU's.

If I leave the deployer in the server//deployers folder it starts before SLEE and so it fails when some DUs are delivered, because SLEE is not initialized yet.

I've tried moving it to the Mobicents SAR -beans.xml and what's happening that way is that the DU's which were already present at the deploy folder are not being processed by the deployer.

Is there any way of fixing this? Shouldn't the DU's that were not "accepted" by any deployer be given "another chance" when a new deployer comes in?

Thanks & Best Regards,

Alexandre Mendonca
JBoss R&D

[vicky.kak]

"alexandrem" wrote:

At the moment one issue has come which is the fact that the SLEE Deployer will require SLEE to be deployed before it processes any DU's.

If I leave the deployer in the server/<node>/deployers folder it starts before SLEE and so it fails when some DUs are delivered, because SLEE is not initialized yet.

It looks like the deploy(...) of the SleeDeployer( which extends AbstractSimpleRealDeployer) is getting called before the Slee related MBeans are deployed.
I am not sure about the latest code so can't say much about it.

The SleeDeployer should be dependent on the slee:service=JSLEEDeployer MBean, shold it not be?

Is this the code where it fails

public void deploy(DeploymentUnit unit, SLEEDeploymentMetaData sdmd) throws DeploymentException

 {

 if(sdmd != null)

 {

 System.out.print("Called deploy("+unit+")");



 try

 {

 ObjectName name = new ObjectName("slee:service=JSLEEDeployer");

 String operationName = "accepts";

 Object[] params = new Object[]{new DeploymentInfo(new URL(unit.getName()), null, server)};

 String[] signature = new String[]{params[0].getClass().getName()};



 server.invoke( name, operationName, params, signature );



 operationName = "init";



 server.invoke( name, operationName, params, signature );



 operationName = "create";



 server.invoke( name, operationName, params, signature );



 operationName = "start";



 server.invoke( name, operationName, params, signature );

 }

 catch ( Exception e )

 {

 // TODO Auto-generated catch block

 e.printStackTrace();

 }

 }

[alesj]

"alexandrem" wrote:
Shouldn't the DU's that were not "accepted" by any deployer be given "another chance" when a new deployer comes in?

There is no such mechanism in new deployers.
Since they work on a totally different system of what we used to have.

Before if was (mostly) single deployer that did it all,
not it's a chain of unrelated deployers that are metadata driven.
So, even if some deployer is 'missing' that doesn't mean deployment wasn't deployed.
It just might be that that particualr deployer didn't provide it's input/output,
but that's hard/costly to fix - it would mean you have to re-deploy all deployments.

But I agree, it make sense to do this for those deployments which we know weren't 'touched' by any deployer.
Perhaps a MC/Deployers 2.2 feature. ;-)

"alexandrem" wrote:
Is there any way of fixing this?

In your case I see two options.

1) put SLEE into deployers
- conceptually ugly/wrong and not hot-re-deployable

2) use jboss-dependency.xml
- http://www.jboss.org/community/docs/DOC-13178

e.g. some pseudo xml code

<dependency xmlns="urn:jboss:dependency:1.0">
 <item whenRequired="Describe">SLEEDeployer</item>
</dependency>

Where your SLEEDeployer gets SLEE injected.

The only issue here is in which phase your SLEEDeployer kicks in?
If it's before PreDescribe, this won't work, since we're already past that.

[alexandrem]

"alesj" wrote:
There is no such mechanism in new deployers.
Since they work on a totally different system of what we used to have.

Before if was (mostly) single deployer that did it all,
not it's a chain of unrelated deployers that are metadata driven.
So, even if some deployer is 'missing' that doesn't mean deployment wasn't deployed.
It just might be that that particualr deployer didn't provide it's input/output,
but that's hard/costly to fix - it would mean you have to re-deploy all deployments.

But I agree, it make sense to do this for those deployments which we know weren't 'touched' by any deployer.
Perhaps a MC/Deployers 2.2 feature. ;-)

Hope so! It's a must-have feature, IMO. :)

"alesj" wrote:

In your case I see two options.

1) put SLEE into deployers
- conceptually ugly/wrong and not hot-re-deployable

Hmm... wouldn't like to have this and it's not possible without separating some components, as Mobicents depends on certain components that are not loaded at this stage.

"alesj" wrote:

2) use jboss-dependency.xml
- http://www.jboss.org/community/docs/DOC-13178

e.g. some pseudo xml code

<dependency xmlns="urn:jboss:dependency:1.0">
 <item whenRequired="Describe">SLEEDeployer</item>
</dependency>

Where your SLEEDeployer gets SLEE injected.

The only issue here is in which phase your SLEEDeployer kicks in?
If it's before PreDescribe, this won't work, since we're already past that.

This looked like a good option... but we start at PARSE phase, and that seems like an issue, cause adding the jboss-dependency.xml didn't solved the problem.

Something I might consider would be running everything at the Real deployer, but that was a problem also due to the fact that we relied on the old deployers behavior, which would deliver, in different stages, childs first than parents, ie, if a.jar had {a1.jar, a2.jar} inside, CREATE/START would process it like: {a1.jar, a2.jar, a.jar} but now in order to achieve that behavior I need to call the old ACCEPTS/INIT on Parse and CREATE/START on Real.

One other thing I've noticed and would like some help on it, is the fact that the jars are not exploded anymore into a tmp folder, the reference to them now comes as, and using the above example, .../server/default/deploy/a.jar/a1.jar and .../server/default/deploy/a.jar/a2.jar instead of the old way .../server/default/tmp/deploy/tmpXXXXXa.jar-contents/a1.jar. We used JarFile/JarEntry to handle it but now it fails due to those references not being a valid path for JarFile/JarEntry. I've managed a workaround for it, having a wrapper for the DeploymentUnit which will then enable me to return an InputStream to read the files... but not sure this is a good practice.

Thanks & sorry for the (very) long post,
Alexandre Mendonca
JBoss R&D

[alesj]

"alexandrem" wrote:

Hope so! It's a must-have feature, IMO. :)

- https://jira.jboss.org/jira/browse/JBDEPLOY-135

"alexandrem" wrote:

This looked like a good option... but we start at PARSE phase, and that seems like an issue, cause adding the jboss-dependency.xml didn't solved the problem.

Looks like you're doing too much in PARSE.
Like the stage name says, it should be just parsing. ;-)

That's why I put jboss-dependency.xml handling asap,
so it can add dependencies to as much as stages as possible.

You should split your deployment into more fine grained deployers per stages.

"alexandrem" wrote:

One other thing I've noticed and would like some help on it, is the fact that the jars are not exploded anymore into a tmp folder, the reference to them now comes as, and using the above example, .../server/default/deploy/a.jar/a1.jar and .../server/default/deploy/a.jar/a2.jar instead of the old way .../server/default/tmp/deploy/tmpXXXXXa.jar-contents/a1.jar. We used JarFile/JarEntry to handle it but now it fails due to those references not being a valid path for JarFile/JarEntry. I've managed a workaround for it, having a wrapper for the DeploymentUnit which will then enable me to return an InputStream to read the files... but not sure this is a good practice.

There is this discussion:
- http://www.jboss.com/index.html?module=bb&op=viewtopic&t=146597

But if you ask me,
you should just drop the old way (JarFile/Entry) and use VFS.