<giant snip, obscuring the problem that I don't understand what the problems with the current deployer design or scanner design are or why it should be changed... seems fine to me> > > David, if you are reading this... and got this far down... what is the > plan to > have this issue tied down and solved once and for all. I think the > approche > that dain, you and I discussed in Tahoe is along the correct lines. > > Do you have any idea when the wrinkles will be sorted out?
What _ARE_ the wrinkles???? I spent the weekend writing a new local jdbc wrapper rather than looking for deployment problems. I need a clear list of problems without a lot of arguing about solutions. I get distracted easily. We have right now: mbeans depend on their classes, if the class isn't there they wait. If it is removed they save their configuration, and if the class comes back they recreate themselves with the saved config. I am pretty convinced that this cannot be modeled as an mbean dependency without a really major rewrite of the dependency system which I think is undesirable. This dependency is really different from mbean-mbean dependency and I don't think we should try to force it to fit. I think it works fine the way it is now. ejbs can depend on other mbeans. Its not automatic, but you can put a depends element in jboss.xml in the bean config or in the container-conf. We already have depends between mbeans. I'd still like to remove the dependency wait in the create step, but not before 3.0 comes out. Once again... what are the problems? david > > --jason > > ------------------------------------------------- > This mail sent through IMP: http://horde.org/imp/ > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
