Sacha, 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).
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. - Matt -----Original Message----- From: Sacha Labourey [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 19, 2003 5:53 AM To: Jboss-Dev Subject: [JBoss-dev] [PROPOSAL]: clean conf/jboss-service.xml & deploy Importance: Low Hello, Currently, the content of conf/jboss-service.xml and deploy is not very clean. 1�) Some services defined in conf/jboss-service.xml require services later deployed in deploy Exemples: - the EJBDeployer depends on the JMS Pool - some invokers (3.2+) require jboss-jca.jar Could we avoid that? Why does the DJBDeployer requires the JMS Pool (MDB I guess). In this case, shouldn't we extract the EJBDeployer from conf/jboss-service.xml and create a ejb-service.xml (or better ejb.jar) that contains everything required for EJB behaviour. 2�) IMHO, way to many files exist in /deploy This is counterintuitive for jboss-users: it may be fine for jboss developers but I don't think it is ok for simple users. First suggestion: we add a new directory to be scanned: system => we put all jboss files in /system and users can put their own files in /deploy (empty or almost at first) Second suggestions: we create a SubDirSubDeployer that deploy the content of simple sub-directories in /deploy (that is not the case right now: *.xAR are deployed but xxx-service.xml files are *not*) or we modify the current deployers so that it happens. Then, we create some functionnaly-self-contained directories for each macro-services i.e. /deploy/JMS /deploy/management /deploy/web /deploy/JCA etc. In "/deploy/JMS" we would find jbossmq-destinations-service.xml, jbossmq-service.xml, jms-ra.rar, jms-service.xml. Thus, if a user doesn't want JMS behaviour, he doesn't have to dig in all these files and try to remove them: he simply removes the JMS sub-directory and that's it. BTW, both suggestions can be mixed: we may have JMS, JCA, etc. sub-directories in a system directory. Feedback welcome. 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 ------------------------------------------------------- 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
