> The thing I care about most is ease of configurability > (which, for the most part, I think we already have). I like > the idea that I can add or remove functionality by adding or > removing "modules" from /deploy. Much of the functionality > of the server works this way (jmx-console, for example). > There is, however, quite a bit of information in > /conf/service.xml. If this information could be refactored > out to /deploy, I'd find that a much simpler situation. At > the moment, if I want to "pare down" jboss to some small > feature set, I need to edit /conf/service.xml. That's not a > big deal, but the less of that I need to do, the better > (especially for automation).
Yes, that is the problem: we should not have to modify this file. > Regarding #2, I find the current state of /deploy to be > highly intuitive, personally. Would it be possible to make > your scheme work by giving .sar's the ability to be nested? > That way, /deploy/JMS.sar (a directory) could contain > jms-foo.sar and jms-bar.sar. That's already possible (russian dolls), but then: - you need a fake META-INF/jboss-service.xml - you cannot simply re-deploy one of the element in the directory: you have to re-deploy the whole JMS thing Cheers, sacha ------------------------------------------------------- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
