I totally agree ;-) I am pulling my hairs cause changing a simple parameter with the SAR means unjar, touch, rejar, this is silly
I REALLY LIKED the one file for the boot > Guys, > > You all may or may not agree, but the current > structure of mbean xml files > is really confusing. I think the concept of one > mbean file containing all > out-of-the-box components that come with JBoss is > much easier for a new user > to understand( and for me for that matter :). In the > 2.4.x series, all you > had to do was look at jboss.jcml to see and configure > all components in > jboss and what order they were brought up in the > system. Yes this was critically simple, configuration is very confusing and putting a comment in the jboss-service.xml that says "don't put your mbeans here is a bad idea > Don't get me > wrong, the hot deploy of mbeans and the ability to > define dependencies is > really really cool, but it is very confusing for the > beginning user( and > users moving from 2.4.x to 3.0). Basically, what I'm > saying is that shit is > everywhere and looks like a mess. Ok, again I will intervene in the defense of the guy that did the work. David has made very important upgrades to the deployer and the configuration but went overboard with it (as usual), also I will say this, David, my heart, you don't have an _ounce_ of admin common sense ;-) but that is ok, what I will do in the near future is still support the SAR PACKAGED FORMAT but be careful with it, namely don't require it (I don't think it is but really we should NOT do the standard JBoss with this, I only put ONE to SHOW HOW IT WORKS, today it is almost IMPOSSIBLE to modify JBoss simply, admin wise it is a step backwards). in order of simplicity there is less simple : all in sars, PACKAGED SARS (with no classes in there either ! X-() medium: all in separate mybean-service.xml it can be good to have the separate files (without the silly packaging) so that the autodeployer can pick up the fact that you have changed one mbean and only one simplest: what I had in the first release of it, meaning one jboss-service.xml file (equivalent of the jboss.jcml) and one example sar and one example myservice-service.xml but for god's sake don't let the sar be the norm, it becomes impossible. David bottom line: I think the work is really good (I really do) but let it up to us to determine what makes sense admin wise, bill you can bring all the sars back under one roof, following the above 2 guidelines. So the infrastructure stays as it WILL BE VERY USEFUL FOR ADVANCED USERS but the simple configuration jboss.jcml like must remain if anything for legacy reasons and because it was less confusing than the current nightmare. > Another thing that really bothers me is that on > boot-up, jboss tells you > "JBOSS 3.0RH Alpa started", then after it says it has > started, a million > other things get deployed including all of your > beans! that is the auto deployer, Remember that JBoss 3.0 is really JBossMX, what I said yesterday, then the microkernel Jboss starts booting stuff up but the microkernel is started. I will change the message to that... > Another question. How do I write initializer mbeans? > What I mean by an > initializer is something that runs AFTER all mbean > components and EJBs have > been deployed. Like WebLogic startup-up classes. > How can I write something > like this in the new architecture. This is unclear. > Regards, > > Bill ---- 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
