[jboss-dev-forums] [Design of POJO Server] - Russian dolls and implicit deployment ordering

I don't think creating a pluggable implicit deployment ordering policy is what we should be spending our time on. Russian dolls and other implicit deployent policies are just hiding some of the inherent problems that exist in our code. Specifically, that too many components are using JNDI to obtain references to external services. If we fixed this problem, I don't think we would need to write implicit ordering policies. So how do we fix it? 1) We need a registration deployer as well a parsing and real deployer. Why? Take EJB. @EJB usually does not have any more information for its reference other than the interface type it wants to inject. This is why the EJB deployer is broken up into 2 separate deployers. The Registration Deployer extracts basic metadata like EJB name, exposed business interfaces and registers an unstarted EJB container with an EJB registry. This is needed so that other EJB containers that have an @EJB reference can locate the "real" EJB container bean they depend on and create a kernel dependency. @PersistenceUnit references have similar issues. 2) Stop using JNDI to inject components. Any component that uses a datasource is a culprit. MDB/JMS connector and their destination/connector dependencies are also a culprit. We tried to solve the datasource problem in the EJB container by trying to create a kernel/JMX ObjectName from the datasource JNDI name provided so that we could create a hard dependency. This becomes a problem when JCA gets refactored as we have to write adapters for each JCA implementation to generate these dependencies. So, what I'm saying is that I think the approach of guessing the kernel name based on the JNDI name is too fragile and JCA needs to provide an SPI to give us this capability. 3) Expand our JNDI implementation so that it could be hooked into the MC's controller. So, when things get bound into JNDI, the kernel is notified and could unblock a JNDI dependency. THis is just an idea. 4) Create a JNDI reference bean that polls JNDI for a specific entry, and when it is available triggers a state change in the MC Controller for beans depending on that entry. I don't think solution #2 is going to solve every JNDI dependency problem. Sometimes, specifically in MDB land, we will be working with thirdparty components and not be able to create a hard kernel dependency because the thirdparty components. #3 is a good option, but may not solve corner cases where a component depends on an external JNDI implementation (i.e. LDAP). #4 maybe the best solution as it could probably even be backported to 4.x. Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4037060#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...