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

"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#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...