"gavin.king(a)jboss.com" wrote : anonymous wrote : Really, how so? Package format would remain the same as it currently is, except bootstrap and config of bootstrap is the same as embedded jboss, jboss. | | If this Seam deployer could apply special deployment semantics to a standard Java EE 5 EAR, then great! In JBoss 4 this is not the case, special packaging and descriptors are required. | Like I said before, in MC Kernel every deployer looks at every archive and decides if it needs to do any processing. You could add special Seam deployment semantics to any deployment unit you wanted. The Seam Deployer could even augment the metamodel of a WAR/EJB/EAR, for instance, to add seam filters automatically, or add a default EJB interceptor. In the new architecture, best practices dictate that one logical deployer is at least broken up into 2 separate concrete ones: metadata processing and actual deployment. For instance, there is a single deployer for just parsing bean.xml and a separate deployer for actually taking the metadata and deploying the beans into the kernel. anonymous wrote : | | anonymous wrote : I looked at your code and what you're doing deployment wise is *exactly* the same as what the kernel does except it is solely specific to Seam, minus the flexility. | | Our requirement in terms of deployment are pretty trivial and are handled by a very small amount of code which costs very little to maintain. | That's understandable. But trivial things can start to add up. Also, if we start getting everybody following the same architecture it becomes much easier to integrate things. anonymous wrote : | Our requirements in terms of lifecycle management and context management are extremely nontrivial and can't be implemented on top of any other container that exists today. | | The thing is, other JEMS projects/products have similar/exact requirements. Also, many JEMS projects want to be able to run in other environments other than app server and they are all writing their own configuration/deployment/bootstrapping models. Many JEMS projects also want to be able to leverage other different JEMS projects in non-JBoss-AS environments. For instance, what if we want to combine ESB/Seam/Drools/JBMessaging and run it in Websphere or WLS? That's 4 deployment models, 4 different types of configuration formats, 4 different ways to bootstrap. Yeah sure, the code to do all this stuff is "trivial", but it is a fucking headache for users. The end goal of all of this should be a JEMS stack that can be run integrated a la carte in a multitude of different environments. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4009520#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...