Marc, don't throw the baby out with the bath water. I agree the current situation is too confusing.
However, IMHO, one of the main benefits of the multi-sar/service.xml packaging is exactly the control you get from so many files. It divides pieces of the server up into chunks you don't need to understand in order to select or use. For instance, to add or remove jbossmq, you just add/remove ONE FILE. You don't need to know anything about whats in it. To add or remove jetty, it's ONE FILE. To switch dbs you switch one file. If you put everything into the master jboss-service.xml you will lose the ability to construct the server you want out of complete pieces, and will have to figure out by hoping the comments are still accurate which mbeans go with which chunk of functionality. I've noticed that virtually noone seems to have noticed that you can force jboss to use the db of your choosing simply by replacing the hypersonic db config with one for your favorite database, and eliminating the hsqldb mbean. So, I don't think asking users to configure a large jboss-service.xml file for the particular pieces they want is realistic. With regard to adding stuff to the base jboss-service.xml, I don't recommend it, unless your mbeans really only depend on the beans in that file. I think in the long run it will be way more confusing. I think the best solution is to include a jboss-service.xml file in the ear for your application. (I'm not sure if this is working at the moment - there's some code for it in j2eedeployer, but I haven't tried it). Just my opinions. david jencks On 2001.12.06 13:52:36 -0500 marc fleury wrote: > <I AM WORKING ON IT RIGHT NOW> > > > Could somone possibly supply a v. brief summary of > > the current situation > > and what the final plan is? Some things it would be > > useful to know: > > The current situation is that simple jboss.jcml like deployment which was > in the first "Rabbit-hole" release I did was removed to force the more > advanced sar/dependency framework. > > for example: > > > 1. I take it jboss-service.xml is loaded first - > > would it work if I put > > other (independent) services in here, even though it > > says not to ? > > See my previous mail, I am removing the comment, you are of course > invited to put your mbeans in here. > > > 2. Is the boot-server configuration only used for > > booting over the > > network - can we try this out just now, and how do > > you decide what > > configuration it obtains/supplies?? > > That I really don't know what it is doing there, see my previous mail on > jetty here > http://www.jboss.org/forums/thread.jsp?forum=66=4975 > > It's gone unless I hear from Jules in the next 30 seconds. > > > 3. Why does the jetty mbean in the jboss-service.xml > > (in boot-server) > > refer to two files which don't exist (at least not in > > the current build): > > > see above, > > > 4. Do all my other services go in the deploy > > directory rather than > > conf/blah? This seems to make it a bit harder to set > > up several > > different static configurations (as you would do > > previously by just > > creating new dirs in jboss/conf). I guess the > > hot-deploy of services > > makes this less of an issue. > > this is where a feature made the default went haywire... > > the feature is "can I hotdeploy parts of my server", example scenario > (real life): a large fortune 1000 user is developing custom MBeans and > they use it in their server, they want to hot-deploy the stuff to be able > to DEVELOP FAST with JBoss as the infrastructure. In JBoss 2.x this is > statically linked at boot time, we are building the modular kernel > Linux2.0 style and that is good. > > SHOULD ALL THE CONFIGURATION GO THIS WAY ? hell no! can it? yes! should > it? no! that is what imnsho david was missing. The work is done and is > top class (REALLY) but it shouldn't be the default way to configure. > > About the only real criticism I have is that the support for adding base > directory without specifying anything was removed, that was a mistake. > > > 5. Should they be sars, or plain xml files, or does > > it matter. Are the > > sars only necessary if I want to supply additonal jar > > files without > > putting them in lib/ext? > > Good question that is something I am still thinking about here is my > current understanding (disclaimer: research). > > SARs are nice from a packaging standpoint, (i.e. you ship a SAR to a > client he can just drop it in his server at run time) but a nightmare > from a jar creation/xml file editing standpoint. > > My favorite way to do this, and what I have been saying from the VERY > BEGINNING, (do a search on the early SAR propositions) is let's put the > plain xml file with either 1- the classes in lib/ext (we could hot deploy > and monitor lib/ext actually) 2- a plain URL that references a file on > the system or on a webserver, so you would just put the XML file and say > classpath codebase=file:/myclassesinbulk/. > > I HAD BUILD THAT SUPPORT IN THE FIRST VERSION ON RH I will make sure it > is still there (I think it is actually). Then the *preferred* way is to > just drop the xml snippet or add it to the base jboss-service.xml if you > know it is going to be part of the server always. > The only advantage of doing the snippet would be monitoring and > reconfiguring the service based on this. Could be useful. > > > I'll have a go at redoing the simple mbean lab we did > > in London to see > > if I can clear things up, but any information on the > > basic setup these > > days would be very useful. > > The London lab covers the creation of a standard mbean with the xml file > format, it was quite simple but required a server restart everytime you > changed the class or the configuration jcml. What we are talking about > here is the capacity to hot-deploy these guys. So the next London lab > will probably focus on the ability to change that separate snippet and > develop the class live, soooo easy for development. > > forget the SAR *****packaging***** madness for now. The features are > really nice, but (french saying) we are "butt-fucking flies" :O over > silly packaging issues. > > Is this clear? > > > ---- > View: http://jboss.org/forums/thread.jsp?forum=66&thread=4977 > > _______________________________________________ > 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
