<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
