[jboss-dev-forums] [Design of JBoss Deployment Framework] - Re: Designing of jain-slee deployers for Jboss5.

[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

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193913#4193913

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193913