OK, but this limitation is the same for *any* implicit dependency scheme. Either you explicitly state and this problem can be solved or you don't and in the scenario you give A should already fail when we undeploy B (not only when the server restart, but directly after we remove B).
At this point, tracking class usages (which service uses which class that originates from which other service) can help detecting such situations: when undeploying B, the controller would see that A depends on it and undeploy A. People will always find a way to mess up things anyway.. We will never be able to prevent a guy from starting a JMS Topic without starting JMS by itself. It is just about freedom: we sbsolutly need to let the door open for fools to do foolish things ;) > -----Message d'origine----- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]De la part de marc > fleury > Envoye : vendredi, 4 octobre 2002 16:45 > A : [EMAIL PROTECTED] > Objet : RE: [JBoss-dev] creating persistent MBeans dynamically > > > > Why wouldn't it work? Can you give me a simple scenario that > > fails? Maybe that's evident but I don't see it right now... > > A depends on B. We shut down B. There is no way just by the order of > deployment to know that A depends on B. The numbering schemes has the > same limitation (the user provides that "autonumber"). > > marc f > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
