RE: [JBoss-dev] current mbean structure confusing
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Maplesden Sent: Sunday, December 09, 2001 3:14 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] current mbean structure confusing Nope, AutoDeployer behavior definately changed. I put an mbean right after the autodeployer declaration in jboss-service.xml and that mbean gets executed at the same time as the autodeployer is deploying things. That mbean does not wait until the AutoDeployer has finished deploying everything. I know marc is trying to kill off this thread (it has been going long enough) but I know what the story is with this one so I thought I would explain (and give you a solution). I'm sorry to drag this out, but I really think this behavior is bad. The AutoDeployer hasn't really changed much at all, but I made one significant change a while back which is causing this behaviour. Originally all of the services the AutoDeployer uses to do the actual deployment of files (like Jetty or J2eeDeployer) had to be started before the AutoDeployer was started, but since we wanted to make shift services like Jetty into their own SAR files I had to change the AutoDeployer code so that the individual deployment services it uses can be started after it is started. Clearly if you want to deploy Jetty via the AutoDeployer, the AutoDeployer has to be started first! Sorry to be blunt, but this behavior is just plain wrong. The AutoDeployer is deploying something it is dependent on? Not good, I must say, not good. You're going to break a lot of 2.4.x applications with this behavior. And it is just crazy to have a circular dependency. IMHO, as I've already stated: MBeans declared after the autodeployer, or with a dependency on the autodeployer should wait until the autodeployer has finished deploying its stuff. I'm going to change the code. Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] current mbean structure confusing
I know marc is trying to kill off this thread (it has been going long enough) but I know what the story is with this one so I thought I would explain (and give you a solution). I want to kill personal attacks on advanced developers of JBoss, I don't want to kill reasonable feature discussion, in fact I am working on this as we speak I am done with it. Sorry to be blunt, but this behavior is just plain wrong. The AutoDeployer is deploying something it is dependent on? Not good, I must say, not good. You're going to break a lot of 2.4.x applications with this behavior. And it is just crazy to have a circular dependency. Get off the high horsey, I solved this problem with 1- page scoping of deployment, meaning if you have N MBeans in the xml page then we create()/start() in lock step (everyone create, then everyone start). 2- do a deployment run in the autodeployer (don't wait for autodeployment but force it in the same thread that does start. MBeans declared after the autodeployer, or with a dependency on the autodeployer should wait until the autodeployer has finished deploying its stuff. yep read the above it will be implicit in the thread doing it. I'm going to change the code. I will commit the above marcf __ View: http://jboss.org/forums/thread.jsp?forum=66thread=4977 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] current mbean structure confusing
I'm going to change the code. I will commit the above FYI I am done with it, turned out that as I was debugging the new invocation chain/proxy I needed this behavior of the deployer so I fixed it, I will do an interim commit of just the deployer logic so we are done with this, I hope this morning marcf __ View: http://jboss.org/forums/thread.jsp?forum=66thread=4977 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: RE: [JBoss-dev] current mbean structure confusing
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Monday, December 10, 2001 11:18 AM To: [EMAIL PROTECTED] Subject: Re: RE: [JBoss-dev] current mbean structure confusing I know marc is trying to kill off this thread (it has been going long enough) but I know what the story is with this one so I thought I would explain (and give you a solution). I want to kill personal attacks on advanced developers of JBoss, I don't want to kill reasonable feature discussion, in fact I am working on this as we speak I am done with it. I hope nobody thinks I was personally attacking anybody. I'm sorry I was combatitive. Its part of my personality. Sorry to be blunt, but this behavior is just plain wrong. The AutoDeployer is deploying something it is dependent on? Not good, I must say, not good. You're going to break a lot of 2.4.x applications with this behavior. And it is just crazy to have a circular dependency. Get off the high horsey, I solved this problem with Sorry. Too lazy to be diplomatic today. Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] current mbean structure confusing
Nope, AutoDeployer behavior definately changed. I put an mbean right after the autodeployer declaration in jboss-service.xml and that mbean gets executed at the same time as the autodeployer is deploying things. That mbean does not wait until the AutoDeployer has finished deploying everything. I know marc is trying to kill off this thread (it has been going long enough) but I know what the story is with this one so I thought I would explain (and give you a solution). The AutoDeployer hasn't really changed much at all, but I made one significant change a while back which is causing this behaviour. Originally all of the services the AutoDeployer uses to do the actual deployment of files (like Jetty or J2eeDeployer) had to be started before the AutoDeployer was started, but since we wanted to make shift services like Jetty into their own SAR files I had to change the AutoDeployer code so that the individual deployment services it uses can be started after it is started. Clearly if you want to deploy Jetty via the AutoDeployer, the AutoDeployer has to be started first! This means that when the AutoDeployer starts it does not have the ability to deploy all the files it finds in the deployment directory (i.e. it cannot deploy ejbs if the J2eeDeployer is not started or wars if Jetty/tomcat is not started) so these files are left until after the appropriate service is started. However if you change your base jboss-service.xml file so that Jetty etc are started before the AutoDeployer is started then it will behave as it always has done. This means of course you can no longer have Jetty etc in seperate SARS, unless someone can figure out how to get the AutoDeployer to deploy the AutoDeployer from a SAR ;-) David --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.303 / Virus Database: 164 - Release Date: 11/24/2001 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] current mbean structure confusing
Marc, Thanks. Regards, Adrian From: marc fleury [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] current mbean structure confusing Date: Fri, 7 Dec 2001 21:17:04 -0500 When you are done with your mbean and explorations send me a sf account and I will give rw marcf _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] current mbean structure confusing
David, 100% agree with you! Our architecture consists of independent services having their own build and runtime configuration. However we also do a master build that dynamically composes the services into one deployment configuration. In 3.0 it just means copying specified archives (with *-service.xml inside) to the deploy directory. Clean and straightforward! In 2.x we had to create an additional ANT's task that was merging the configuration of each service into one master jboss.jcml file. Messy! On the other hand, we are experiencing the same issue as Bill with the need to invoke our EJB from a MBean as soon as the EJB is deployed/available. Jiri. On Thu, 6 Dec 2001 15:04:48 -0500, you wrote: 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).
Re: [JBoss-dev] current mbean structure confusing
I definitely prefer the SAR kind of way to deploy services, even that i understand the maintenance problem. Would it be possible to have a 'global' service.xml file to be updated with new properties when a SAR is deployed with initial properties fetched from SAR xml. Then this 'global' service.xml file can be maintained easily during runtime (maybe changes in it can in some way be copied to the SAR xml also?). And then if a SAR is removed then it disappears from the 'global' service.xml file or put in an undeployed state. Hmmm, this sounds like the old jboss-auto.xml file... with all its problems... :-/ In our app we have an mbean acting as a Service Loader that is watching a directory where we dynamically can deploy/undeploy mbeans packed in jar files using m-let loading service. And it is s nice to add/remove services when everything is running. We can even extend our clients user interface with new dialogs linked to these new services without having to restart the client. Really cool :) More on that later... /Lennart ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] current mbean structure confusing
Lennart, I agree. I want as many services as possible in SARs. That way fixes can be hot deployed without bringing down the server, just a temporary unavailablity of the service and its dependents. Why can't the JBoss distribution have two configurations? Default, everything in one file for compatiblity with 2.4 Advanced?, everthing in deploy/*-service.xml or deploy/lib/*.sar Users migrating from 2.4 only need to know jboss.jcml is now jboss-service.xml Users who want the easier hot deploy can start the server with the advanced configuration. Regards, Adrian From: Lennart Petersson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] current mbean structure confusing Date: Fri, 7 Dec 2001 11:22:07 +0100 I definitely prefer the SAR kind of way to deploy services, even that i understand the maintenance problem. Would it be possible to have a 'global' service.xml file to be updated with new properties when a SAR is deployed with initial properties fetched from SAR xml. Then this 'global' service.xml file can be maintained easily during runtime (maybe changes in it can in some way be copied to the SAR xml also?). And then if a SAR is removed then it disappears from the 'global' service.xml file or put in an undeployed state. Hmmm, this sounds like the old jboss-auto.xml file... with all its problems... :-/ In our app we have an mbean acting as a Service Loader that is watching a directory where we dynamically can deploy/undeploy mbeans packed in jar files using m-let loading service. And it is s nice to add/remove services when everything is running. We can even extend our clients user interface with new dialogs linked to these new services without having to restart the client. Really cool :) More on that later... /Lennart ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] current mbean structure confusing
Jiri, do not overquote please David, 100% agree with you! Our architecture consists of independent services having their own build and runtime configuration. However we also do a master build that dynamically composes the services into one deployment configuration. In 3.0 it just means copying specified archives (with *-service.xml inside) to the deploy directory. Clean and straightforward! In 2.x we had to create an additional ANT's task that was merging the configuration of each service into one master jboss.jcml file. Messy! Having 10 configuration files for newbies is a clear mistake. It is that simple. We are not saying that we will prevent you from shipping many xml services, as they are very useful. The microkernel is there to allow hotdeploy of independent services. On the other hand, we are experiencing the same issue as Bill with the need to invoke our EJB from a MBean as soon as the EJB is deployed/available. An EJB is soon going to be an MBean so MBean refs will be usable. __ View: http://jboss.org/forums/thread.jsp?forum=66thread=4977 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] current mbean structure confusing
On the other hand, we are experiencing the same issue as Bill with the need to invoke our EJB from a MBean as soon as the EJB is deployed/available. An EJB is soon going to be an MBean so MBean refs will be usable. So, in the initializer bean, I have to put a MBean ref for every EJB I use? What a pain! Why can't MBean deployment be held up until the AutoDeployer finishes? So that you could have an MBean with a dependency on the AutoDeployer, and that would be that? ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] current mbean structure confusing
|So, in the initializer bean, I have to put a MBean ref for every EJB I use? |What a pain! Why can't MBean deployment be held up until the AutoDeployer |finishes? So that you could have an MBean with a dependency on the |AutoDeployer, and that would be that? I agree, write it, marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] current mbean structure confusing
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bill Burke Sent: Friday, December 07, 2001 9:48 AM To: marc fleury; [EMAIL PROTECTED] Subject: RE: [JBoss-dev] current mbean structure confusing On the other hand, we are experiencing the same issue as Bill with the need to invoke our EJB from a MBean as soon as the EJB is deployed/available. An EJB is soon going to be an MBean so MBean refs will be usable. So, in the initializer bean, I have to put a MBean ref for every EJB I use? What a pain! Why can't MBean deployment be held up until the AutoDeployer finishes? So that you could have an MBean with a dependency on the AutoDeployer, and that would be that? One more thing. As a user, you're going to have to figure out what the hell the MBean name is for the EJB as well. Maybe I'm just being lazy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] current mbean structure confusing
On 2001.12.07 09:47:31 -0500 Bill Burke wrote: On the other hand, we are experiencing the same issue as Bill with the need to invoke our EJB from a MBean as soon as the EJB is deployed/available. An EJB is soon going to be an MBean so MBean refs will be usable. So, in the initializer bean, I have to put a MBean ref for every EJB I use? What a pain! Why can't MBean deployment be held up until the AutoDeployer finishes? So that you could have an MBean with a dependency on the AutoDeployer, and that would be that? Having a dependency on the autodeployer won't do you much good, will it? The autodeploy being present doesn't mean any particular package is deployed. All the *service.xml and sars are deployed by the autodeployer at present, except for the one in conf/default I think we need mbeans for each package (application, ejb module, etc) that you can depend on. The deployment stuff I'm working on is based on this, but I am finding it slow going. david jencks ___ 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
Re: [JBoss-dev] current mbean structure confusing
Bill, First I want to agree with you that the current deployment system has problems in getting the deployment order right for more than toy examples. It is (or may be) possible to force the correct deployment order by liberal use of anonymous mbean references, but I think that is a bad idea and not maintainable. I think mbean-refs are really good when one mbean needs to use the services of another, such as those in ConnectionFactoryLoader: using them simplified the code considerably while introducing better dependency management. But if there is no natural use of one mbean by another, I think mbean-refs are artificial. What would you think of a deployment script facility, where you listed the packages in the order you wanted them deployed? At most the script would be autodeployed. Also... why are you using autodeployment on a production system? You can write a little program to deploy the packages you want in the order you want, the testsuite has lots of examples of this, see esp. the JBossTestServices class. I think there's a way to do this through a servlet or jsp also, I think Andreas wrote an ejb adaptor or connector for the mbean server. I have been thinking along the lines of large projects being divided up into medium sized chunks: the deployment then involves deploying these chunks in the correct order. I would think this would be easier to understand and maintain than one giant dd at the lowest level of detail. Does this make sense? Finally: I don't think any logic in AutoDeployer changed. If you put the mbeans you want to start last at the end of the main jboss-service file are they deployed before autodeployer goes through and deploys everything it can find? If so, this may be an accident of the ordering of deployers and deploy directories in the autodeployer configuration, and you might be able to reorder these to get the results you want. I would be hesitant to rely on this for a production system. Thanks david jencks On 2001.12.07 14:07:59 -0500 Bill Burke wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Friday, December 07, 2001 1:34 PM To: [EMAIL PROTECTED] Cc: marc fleury; [EMAIL PROTECTED] Subject: Re: [JBoss-dev] current mbean structure confusing On 2001.12.07 09:47:31 -0500 Bill Burke wrote: On the other hand, we are experiencing the same issue as Bill with the need to invoke our EJB from a MBean as soon as the EJB is deployed/available. An EJB is soon going to be an MBean so MBean refs will be usable. So, in the initializer bean, I have to put a MBean ref for every EJB I use? What a pain! Why can't MBean deployment be held up until the AutoDeployer finishes? So that you could have an MBean with a dependency on the AutoDeployer, and that would be that? Having a dependency on the autodeployer won't do you much good, will it? Maybe I'm just really braindead here, but in 2.4.x, MBeans listed after the AutoDeployer(implicit dependency) did not start until the AutoDeployer finished deploying everything. Why was this behavior changed in 3.0? This is very very useful. Otherwise, mbeans depending on EJBs and services deployed by the AutoDeployer will have to list long lists of MBean refs (is this correct?) which are hard to maintain. An even better reason for this behavior is the following scenario we had at Mercantec: Mercantec's application receives HTTP requests many times per second by hundreds/thousands of different clients. Jetty should not be able to accept HTTP requests until JBoss has completely booted up, and this means all AutoDeployed components. Otherwise, UI sessions could come up with errors in this time interval (2-3 minutes to load all our beans), or our batched XML-RPC requests could fail. The way you guys are talking, I'm going to have to list MBean refs for all 80 of our EJBS and other datasouces and MBean components!!! That's a nightmare to maintain and just plain ridiculous. Do you get what I'm saying here? Other than that, IMHO, it is plain ridiculous to have to explicitly type in dependencies for all MBeans. It is just too much work and too hard to maintain for a large application. Having implicit dependencies by MBean ordering in a file is simple and elegant and easy to understand. Yes, specifying dependencies explicitly is very useful, but I'm guessing is not needed for 80% of applications. Bill Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] current mbean structure confusing
Maybe I'm just really braindead here, but in 2.4.x, well, it's the tone that bother me, you sound like me ]:) MBeans listed after the AutoDeployer(implicit dependency) did not start until the AutoDeployer finished deploying everything. Why was this behavior changed in 3.0? As far as I know David M was talking about making the mbeans in one file deploy and start together, I think this behavior is still useful, if it has been removed, why don't you put it back? ask david M that was a valid feature. This is very very useful. Otherwise, mbeans depending on EJBs and services deployed by the AutoDeployer will have to list long lists of MBean refs (is this correct?) which are hard to maintain. yeah yeah we got it Mercantec's application receives HTTP requests many times per second by hundreds/thousands of different clients. Jetty should not be able to accept HTTP requests until JBoss has completely booted up, and this means all AutoDeployed components. Otherwise, UI sessions could come up with errors in this time interval (2-3 minutes to load all our beans), or our batched XML-RPC requests could fail. Then code it biotch :) the fact is that being able to deploy independent services means that you almost must install/conf/start in one batch. Holding the steps in the scope of the PAGE XML being deployed is useful, Code it back, I think it took DavidM one day to code it, You supah man, go Do you get what I'm saying here? YES, go ahead. David J, please make sure this behavior is still there when he puts it, don't remove that, even for the benefit of your dependency stuff. FUCK a little arbitrage never hurt anyone, aaarg this thread is just getting too long, too tense (although I guess I set the tone) and it is time we finish it. maintain for a large application. Having implicit dependencies by MBean ordering in a file is simple and elegant and easy to understand. Yes, yes, we agree, it is, if it was removed then bad, if it is then code it again, and flag it as touch this and I burn your beard david and basta. David J did relevant work, so stop bitching and fix it. David M you got 30 minutes? specifying dependencies explicitly is very useful, but I'm guessing is not needed for 80% of applications. I wouldn't put down the feature, you have seen enough support here on the list for it, they are largely orthogonal (meaning there was no reason to remove it afaict) and we should really kill this thread once and for all. marcf Bill Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-dev lopment __ View: http://jboss.org/forums/thread.jsp?forum=66thread=4977 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] current mbean structure confusing
First I want to agree with you that the current deployment system has problems in getting the deployment order right for more than toy examples. all he is asking for is the page ordering which should be trivial to do. another, I think mbean-refs are artificial. hm there might still be a place. the fact is that even if I automate teh SCL tracking I don't know that I can track non-typed calls, Unless we hack the MBeanServer, but in any case, it is ahead of us. What would you think of a deployment script facility, where you listed the packages in the order you wanted them deployed? At most the script would be autodeployed. similar to one page and basta, more complex... look keep it simple (I think the real problem you have is an incapacity to keep it simple ;-) Also... why are you using autodeployment on a production system? You can write a little program to deploy the packages you want in the order you want, the testsuite has lots of examples of this, see esp. it's a point but the feature is so trivial that I would drop this discussion. I have been thinking along the lines of large projects being divided up into medium sized chunks: the deployment then involves deploying these chunks in the correct order. I would think this would be easier to understand and maintain than one giant dd at the lowest level of detail. Does this make sense? yes Finally: I don't think any logic in AutoDeployer changed. If you put the It is not AD logic it is in service controller do we group the mbeans to init/start, of course the smaller granularity we need to support is the mbean (we do, 2.4 doesn't so that is a very clear improvement) they are saying page scope was useful we agree, let's not let a trivial feature grow out of hand. would be hesitant to rely on this for a production system. bullshit... he does, it works, He loves it, he wants it in 3.0 let him code it, or DavidM, all I ask you is drop it and don't remove it or I come kick your ass on my way down to Miami. oka? good work btw, really, I have calmed down, and I realize that between you and hiram we got some solid coders under the SUN B-) marcf __ View: http://jboss.org/forums/thread.jsp?forum=66thread=4977 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] current mbean structure confusing
Also... why are you using autodeployment on a production system? You can write a little program to deploy the packages you want in the order you want, the testsuite has lots of examples of this, see esp. the JBossTestServices class. I think there's a way to do this through a servlet or jsp also, I think Andreas wrote an ejb adaptor or connector for the mbean server. We used it in production because its fast and easy to maintain. No need to keep/maintain a list of bean dependencies. Remember, I don't want Jetty to startup until everything is done, that's the real problem and I bet many other apps will have the same problem. You shouldn't serve HTTP requests until JBoss is ready. Finally: I don't think any logic in AutoDeployer changed. If you put the mbeans you want to start last at the end of the main jboss-service file are they deployed before autodeployer goes through and deploys everything it can find? If so, this may be an accident of the ordering of deployers and deploy directories in the autodeployer configuration, and you might be able Nope, AutoDeployer behavior definately changed. I put an mbean right after the autodeployer declaration in jboss-service.xml and that mbean gets executed at the same time as the autodeployer is deploying things. That mbean does not wait until the AutoDeployer has finished deploying everything. My instincts tell me that you will piss off a lot of people with this behaviour. I've answered many questions on the User list about How can write initializer classes like Weblogic? initializer classes meaning classes that get run after the app server has booted. I always tell them, write an MBean. Since MBeans declared after the AutoDeployer will start before the AutoDeployer finishes, Im betting you'll break a lot of applications.(Mercantec's is definately one of them since they have both an initializer mbean and the dependency of Jetty not starting up until everything is deployed.) to reorder these to get the results you want. I would be hesitant to rely on this for a production system. Doesn't AutoDeploy = HotDeploy. You can't hot deploy unless you autodeploy it? Is this true? Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] current mbean structure confusing
Doesn't AutoDeploy = HotDeploy. You can't hot deploy unless you autodeploy it? Is this true? No, but I still agree with your other points, that scoping the create/configuration/init/start should follow page as a simple way to group them. marcf (No you can hot-deploy a service by undeploying the URL and redeploying, hot-deploy means the capacity to deal with new class versions dynamically) __ View: http://jboss.org/forums/thread.jsp?forum=66thread=4977 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] current mbean structure confusing
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=66thread=4977 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] current mbean structure confusing
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 It is now coming back to me, someone in the london training (was it you sacha?) was pushing for unix levels you know rc.0 - rc.6 as a way to define dependency in a lose fashion, that was actually pretty good and allows for different files of configuration. I might look into that in the near future for now I want the simpler one jboss-service file I had there in the beginning :) View: http://jboss.org/forums/thread.jsp?forum=66thread=4977 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] current mbean structure confusing
It is now coming back to me, someone in the london training (was it you sacha?) was pushing for unix levels you know rc.0 - rc.6 as a way to define dependency in a lose fashion, that was actually pretty good and allows for different files of configuration. No, I guess it was one of the German guy at the front (sorry... don't remember his name.. he found a bug in the cache or something like this the last training day) And the 5 cents question was: How many unix levels do we have in common unix? And playing with jboss-levels could also solve (once levels are properly defined) Bill's issue: how to start a mbean once everything (services, ejb, ...) is started. We could have such a level. But IMHO, while simple, unix-like levels doesn't seem to be the nicest feature I've ever seen... a bit tricky... maybe that's just me... In that case, why not simply creating subdirectories in the deploy folder and start their content depending on the name of the directory (well... almost like unix...) In fact, on a different topic, when you were speaking about classloaders partitions (to be able to load different classes versions with the same full name in different applications), I was thinking we could simply create sub-directories in /deploy: each would be a partition for the classloader i.e. everything dropped in a sub-directory is not shared/viewed by other sub-directories (i.e. partitions). = both solutions (subfolder for unix-level and subfolder for CL partitions) are not possible at the same time bla bla bla. Cheers, Sacha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] current mbean structure confusing
[EMAIL PROTECTED] wrote: But IMHO, while simple, unix-like levels doesn't seem to be the nicest feature I've ever seen... a bit tricky... maybe that's just me... In that case, why not simply creating subdirectories in the deploy folder and start their content depending on the name of the directory (well... almost like unix...) The nice thing about runlevel style configuration is that there are tons of system admins out there who are already familiar with it. And once something is on a production box... It becomes nigh impossible for a developer or architect to touch. So it would be nice to have something the admins are familiar with. I have had the great luck to be sitting over the shoulder of a sys admin while changing the weblogic properties file on a production box... its not fun. Although in that same vein, and in light of the other thread on here... That is the great thing about weblogic in most peoples minds. Everything is in that one single properties file. (like the old jboss.jcml was) I haven't had too many difficulties getting used to the model in jboss 3 but it was nice to have one single place to go in jboss 2.x :) Al In fact, on a different topic, when you were speaking about classloaders partitions (to be able to load different classes versions with the same full name in different applications), I was thinking we could simply create sub-directories in /deploy: each would be a partition for the classloader i.e. everything dropped in a sub-directory is not shared/viewed by other sub-directories (i.e. partitions). = both solutions (subfolder for unix-level and subfolder for CL partitions) are not possible at the same time bla bla bla. Cheers, Sacha ___ 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
Re: RE: [JBoss-dev] current mbean structure confusing
My plans are way ahead of my time to implement any of this... some comments. 1. Don't confuse the utterly messed up and misleading current use of the classpath element and service.xml packaging with its capabilities and usefulness. There are 2 problems with the current packaging IMHO: a.the base jboss-service.jar includes every jar under the sun that I didn't explicitly remove, rather than the ones actually used in the base package, and b. No one has actually divided up the functionality of jboss into reasonable independently deployable packages. (maybe this would be an actually useful project for that debian packaging guy...???) For instance, there could be a castor-service.xml referencing the castor.jar. Loading castor classes if you aren't going to use them is silly. IMHO having the classpath element is very useful in showing what jars you actually need for certain functionality. The MBeanClassLoader solution AFAIK will not provide this documentation. I think being able to document where the classes you are using come from beats autodeploying everything in sight and hoping the classes you need are present. 2. There is definitely a problem with relying on the autodeployer: although everything may all start in the right order due to automatically computed dependencies, it doesn't look that way and is confusing. My proposed solution for this is a deployment script facility, basically a list,deploy this, now this, now this,... This should make it easy to construct a customized jboss by deploying the appropriate packages, including the ears etc for your application. I think this may be an easier to use and more flexible solution than the run level idea. 3. Scoping... I would like every set of deployment descriptors to be converted to a single jboss-service.xml file that explictly includes security domain/virtual host/classloader information. I think this info should be in attributes in the server element. So, for instance, for an ejb module, I would combine ejb-jar.xml, jaws.xml, and jbosscmp-jdbc.xml into a single jboss-service.xml where the module and each ejb is represented by an mbean config representing the meta data for that object. This combination is pretty easy to do with xslt, and would IMHO greatly simplify metadata loading and provide alternative single dd deployment descriptors. It would also provide a place to put the scoping info about which classloader to use. View: http://jboss.org/forums/thread.jsp?forum=66thread=4977 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: RE: [JBoss-dev] current mbean structure confusing
|a.the base jboss-service.jar includes every jar under the sun that |I didn't explicitly remove, rather than the ones actually used in |the base package, and including jars in classpath as code requirement is the initial problem, remove that. |b. No one has actually divided up the functionality of jboss into |reasonable independently deployable packages. (maybe this would be we shouldn't... the boot should be one file see my previous email |IMHO having the classpath element is very useful in showing what |jars you actually need for certain functionality. The no not as is, as is it is a stepback. put that in a comment, |MBeanClassLoader solution AFAIK will not provide this |documentation. I think being able to document where the classes it might, at least the coarse grained. MBCL- what class- what jar I have to look at it again to make sure. |you are using come from beats autodeploying everything in sight |and hoping the classes you need are present. no it doesn't, clearly doesn't. |2. There is definitely a problem with relying on the autodeployer: |although everything may all start in the right order due to |automatically computed dependencies, it doesn't look that way and |is confusing. My proposed solution for this is a deployment |script facility, basically a list,deploy this, now this, now |this,... This should make it easy to construct a customized which is what the one file achieves implictely. |jboss by deploying the appropriate packages, including the ears |etc for your application. I think this may be an easier to use |and more flexible solution than the run level idea. that could very well be. |3. Scoping... I would like every set of deployment descriptors to |be converted to a single jboss-service.xml file that explictly |includes security domain/virtual host/classloader information. I |think this info should be in attributes in the server element. |So, for instance, for an ejb module, I would combine ejb-jar.xml, |jaws.xml, and jbosscmp-jdbc.xml into a single jboss-service.xml |where the module and each ejb is represented by an mbean config |representing the meta data for that object. This combination is There we totaly agree. I think that would be very good. Although we will find that specifying the services for all the beans will be silly, combining the other files would be very good, packaging madness in the spec |pretty easy to do with xslt, and would IMHO greatly simplify |metadata loading and provide alternative single dd deployment |descriptors. It would also provide a place to put the scoping |info about which classloader to use. I will shoot you in the head if you do this, give the administrator input in the class loader. You are a bit like rickard, you are a wizard in code no doubt about it and in some ease of use instance you are a bit of a moron :) (no offense really, I called you a rickard ;-) Ok I think I got a pretty good handle on your work, sit back bite some rope and let me refactor this, Victor, nettoyeur -- Nikita ca.1988 -- marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] current mbean structure confusing
Bill Burke wrote: Guys, You all may or may not agree, but the current structure of mbean xml files is really confusing. Ah. I'm glad someone else has some reservations. I assumed I was just lagging behind (probably true anyway) and that everyone else knew exactly what was going on from all the discussions on sars and services so it's good to hear a mildly dissenting voice with some clout. 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: 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 ? 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?? 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): Configuration../conf/boot-server/jetty.xml/attribute WebDefault../conf/boot-server/webdefault.xml/attribute 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. 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? 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. thanks, Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] current mbean structure confusing
On 2001.12.06 12:46:21 -0500 Luke Taylor wrote: Bill Burke wrote: Guys, You all may or may not agree, but the current structure of mbean xml files is really confusing. Ah. I'm glad someone else has some reservations. I assumed I was just lagging behind (probably true anyway) and that everyone else knew exactly what was going on from all the discussions on sars and services so it's good to hear a mildly dissenting voice with some clout. On the other hand, I think quite a few people have said it was confusing at first and useful when they got used to it. 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: 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 ? The one in conf/default is. 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?? I have no idea what this is for. 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): Configuration../conf/boot-server/jetty.xml/attribute WebDefault../conf/boot-server/webdefault.xml/attribute I think this is an obsolete antique. 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. Yes. The current situation is way less than ideal. I want a deployment script functionality and pretty much deprecate autodeploy. If you want several configurations, you could have several conf dirs, and for each a separate deploy dir with the stuff to autodeploy. 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? Doesn't matter. I'd use a sar for a package that doesn't need it's mbeans reconfigured frequently and you't like to keep everything together, and a service.xml for things under development. 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. thanks, Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ 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
Re: [JBoss-dev] current mbean structure confusing
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, s 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=66thread=4977 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] current mbean structure confusing
On the other hand, I think quite a few people have said it was confusing at first and useful when they got used to it. It's **killer** stuff, when you are trying to do advanced dependency deployment, but we will not force it on un-suspicious newbies and those used to the simple 2.x deployment. i think it is pretty clear in my mind, we will present the EXACT SAME FACE (that is what I am working on) as the simple jcml stuff even though under the cover it is your stuff running, let's put a smiley face on that stuff, it looks the same, it behaves better, and when it needs to be more powerful (hotdeploy of kernel modules) it is there to do the trick, that is the way I want it. I think this is an obsolete antique. yes, ok I will remove it Yes. The current situation is way less than ideal. I want a deployment script functionality and pretty much deprecate autodeploy. If you want several configurations, you could have several conf dirs, and for each a separate deploy dir with the stuff to autodeploy. ok I will again go to your defense (against yourself it seems). THE SITUATION IS IDEAL, I will take back my criticism, except a few things you removed, we can have pretty much everything I explained in my previous email so that Bill/Luke are happy, and the one difference with the current situation is that *IT WILL BE THE PREFERED WAY TO DO IT* :). This discussion is not a code discussion (except as a said a few minor points your code removed) but the code is core, is there, and I know how to put a friendly prefered face on it, so I will and we will be IN THE BEST SITUATION POSSIBLE :D Doesn't matter. I'd use a sar for a package that doesn't need it's mbeans reconfigured frequently and you't like to keep everything together, and a service.xml for things under development. exactly from our code standpoint *it doesn't matter* since the code you put there covers all cases, these guys are asking for the default configuration and a prefered way to do it, that much is what we are talking about and that much is crystal clear in my mind.I will solve this in 3minutes flat. marcf View: http://jboss.org/forums/thread.jsp?forum=66thread=4977 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] current mbean structure confusing
MBeans in 2.4.x are really really simple and easy to understand. It's also easy to understand the flow of initialization. IMHO, anything new in 3.0 should be an extension of 2.4.x for more advanced configurations. I'm hoping that 3.0 will move back to 2.4.x's simplicity, but be extendible for more advanced users like Marc suggested. 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. I want to have an MBean that can do stuff once all other components are loaded. Stuff like, preload Entity Beans and such. Is there a way to create a dependency between all EJBs and the MBean I want to write? It used to be the AutoDeployer deployed all EJBs before the next MBean was loaded. Why was this changed? (Or was it changed?) View: http://jboss.org/forums/thread.jsp?forum=66thread=4977 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] current mbean structure confusing
I forgot to remind everyone of the point behind these apparently fragmented service.xml files They enable easy deployment/undeployment of large chunks of server functionality (including replacing the classes implementing the functionality) WHILE THE SERVER IS RUNNING. In 2.4, to add a datasource non-programatically you had to modify jboss.jcml, stop jboss, and restart. Now you can just drop a mydb-service.xml file in deploy, and away you go. I think most of the problems people are having are because there is no documentation other than my off the cuff responses to questions and because the current service.xml files are extremely disorganized. The base jboss-service.xml file includes zilliions of jars it isn't using, just becasue they were in marc's lib/ext when he first wrote the example, and I haven't modified or written the appropriate service.xml for the chunk of functionality exposed. For instance, I think it makes sense to put the castor adapter mbean and the castor jar in a sar, and remove all reference to it from the base jboss-service.xml. To get castor, you add the sar. If you don't want castor, you wont have extra classes loaded. david jencks big snip ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] current mbean structure confusing
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/. This wasn't in David J's stuff originally I just added support for it recently. So just to clarify currently you can use... to add directory (so class files and resources in directory are accessible) classpath codebase=directoryURL / to add specific jars in directory classpath codebase=directoryURL archives=jar1.jar,jar2.zip / to add all jars in directory classpath codebase=directoryURL archives=* / 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. It is for development, which is why I put it back in. David --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.303 / Virus Database: 164 - Release Date: 11/24/2001 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] current mbean structure confusing
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 still want me to do this? ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] current mbean structure confusing
David Jencks wrote: On 2001.12.06 12:46:21 -0500 Luke Taylor wrote: Ah. I'm glad someone else has some reservations. I assumed I was just lagging behind (probably true anyway) and that everyone else knew exactly what was going on from all the discussions on sars and services so it's good to hear a mildly dissenting voice with some clout. On the other hand, I think quite a few people have said it was confusing at first and useful when they got used to it. I'm sure it's v. useful and I wasn't intending to make any criticisms one way or the other. It's just that there have been tons of discussions where I haven't had a clue what was going on. I'm not even sure that having a single file is necessarily less confusing than multiple files, one for each service. I like the idea of being able to just drop an encapsulated service description into a running server and having it deployed in the same way as an application. The fact that other servers use a single configuration file isn't really an argument in itself. This system also makes configuration less of an issue - you can just supply someope with the appropriate sar files along with your app and tell them to drop them into the deploy directory. I'm just not quite clear on how it's all fitting together, but thanks for your answers. I can already see the fog lifting ... Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] current mbean structure confusing
On 2001.12.06 14:17:46 -0500 Adam Heath wrote:
On Thu, 6 Dec 2001, David Jencks wrote:
b. No one has actually divided up the functionality of jboss into
reasonable
independently deployable packages. (maybe this would be an actually
useful
project for that debian packaging guy...???)
If this sounded snide I apologize. You seem pretty good and practiced at
tracking down dependencies and I hate doing it and no one else has done
much to organize the 3.0 service.xml files;-)
For instance, there could
be a
castor-service.xml referencing the castor.jar. Loading castor classes
if
you aren't going to use them is silly.
I have done my debian packaging on the 2.4 branch, waiting for 3.0 to
become
at least a beta. To split up the functionality, I created an
/etc/jboss/conf.d/default/jboss.{conf,jcml}/ structure. Each package
then
installs files into one of the above 'fragment' dirs, and the
configuration
files in /etc/jboss/conf/default/ get rebuilt from them, when the package
is
installed.
I keep the implicit order correct by naming the files with a leading
number.
This simulates a dependency chain. 3.0 does this much better.
I certainly hope so;-)))
If one of the config files gets modified, then the jboss server daemon is
automatically restarted.
3.0 eliminates the need for some of this, so I know my work will have to
be
redone for that. That's fine by me.
Package: jboss
Package: jboss-server
Package: jboss-transaction
Package: jboss-tomcat-service
Package: jboss-client
Package: jboss-admin
Package: jboss-common
Package: jnp-server
Package: jnp-client
Package: jbossmq
Package: jbossmq-client
Package: jbosssx
Package: jbosssx-client
Package: jboss-contrib-hsqldb
Package: jboss-contrib-oswego
Package: jboss-contrib-tyrex
Package: jboss-contrib-castor
Package: jboss-contrib
Package: jboss-dev
Package: jboss-docs
Package: jboss-jdbc-postgresql
Package: jboss-mail
jboss is the package that depends on all the other ones, to give you a
proper
server invironment. It does not include any client only support.
jboss-server is the heart of the system. It contains the actual daemon,
with
an init script, that starts jboss as a separate user.
jboss-transaction is a separate package, as jboss-contrib-tyrex also
provides
the same functionality. You can only have one of these packages
installed at
the same time.
jboss-tomcat-service depends on libtomcat-java and libjasper-java(these
latter
2 debs don't exist yet, as I only patched tomcat yesterday to make them).
The
plan is to also make a package of jetty(which doesn't yet exist in
debian),
and then allow for easy integration of that as well.
jboss-client depends on the other -client packages. These packages
contain
the *-client.jars.
jboss-admin contains the untested(at least by me, I have never run it)
-admin
stuff.
jnp-server and jboss-server can not be installed at the same time.
jboss-server has an embedded jnpserver, while jnp-server has it
standalone.
jbossmq and jbosssx contain their respective code. The names for these
packages may not be correct. I basically named them after the
directories
they occupy in cvs, and the names of their jars.
jboss-contrib-* contains files that are either non-free(jboss-contrib),
or
files that should be a completely separate package(jboss-contrib-*).
jboss-dev contains a debian packaging helper script, for those that are
building debs for debian.
jboss-docs contains the jboss documentation. It doesn't have a lot(no
api
docs atm). I need to flesh this out some more.
jboss-jdbc-postgresql depends on postgresql.deb, and enables a
PostgresqlDS.
Additionally, both this package and jboss-contrib-hsqldb(which provides a
HypersonicDS), use debian's alternative mechanism, to provide a
DefaultDS,
that points to either one of these(postgres is prefered over hypersonic,
for
no particular reason.
How do you select which one you get? This could be interesting;-) we
don't have a systematic way at this point I would say.
jboss-mail depends on libactivation-java and libmail-java, and enables
mail
service under jboss.
This looks pretty reasonable to me as a starting point. Not all of these
are deployment units for the server.
2. There is definitely a problem with relying on the autodeployer:
although
everything may all start in the right order due to automatically
computed
dependencies, it doesn't look that way and is confusing. My proposed
solution for this is a deployment script facility, basically a
list,deploy
this, now this, now this,... This should make it easy to construct a
customized jboss by deploying the appropriate packages, including the
ears
etc for your application. I think this may be an easier to use and
more
flexible solution than the run level idea.
Computing stuff at runtime is all nice and good, but it is a performance
hit(even if it is only
Re: [JBoss-dev] current mbean structure confusing
marc fleury wrote: I think this is an obsolete antique. yes, ok I will remove it Marc, could you shed some light on what the boot-server config. does and how it works? Is it all outdated or is that still part of the web-booting infrastructure? David says he doesn't know what this is for which surprised me, so I think it would be useful to know. ok I will again go to your defense (against yourself it seems). THE SITUATION IS IDEAL, I'd just like to clarify again that I'm not in a position to criticise anything - I'm just trying to work out what the differencs are at the moment :). Luke. P.S. I do think the idea of keeping it the same as 2.4.* but with the new features still available sounds good. Then nobody has to worry about them unnecessarily. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] current mbean structure confusing
marc fleury wrote: 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 This draws a blank when I try to browse it... It's gone unless I hear from Jules in the next 30 seconds. OK. I won't lose any sleep over it then :). Is the net booting stuff still active? 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. Can't you monitor and reconfigure the services which are always deployed too? Do you mean that the snippet files would be rewritten (a la jboss-auto.jcml) to reflect changes in the configuration? 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, s easy for development. OK. So to clarify - what's the current situation if I update the snippet file - how do you determine which classes need reloaded? You mentioned that you *could* monitor lib/ext but presumably that doesn't happen currently. Where do I specify which classes my service needs and how are they reloaded? 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? It's much clearer. Once I've tried it out I should get that warm glow for a while... I think the stuff about where my service classes should go in order to be dynamically reloaded should clinch it... As far as I can see all the current services all have classpaths which point to files which are exclusively in lib/ext. Butt-fucking flies is pretty clear and sounds like a useful French phrase to know - what is the original enculer des mouches or something like that?? I know the Chinese would say taking trousers down to fart which is equally appropriate and is a bit less vulgar :). Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] current mbean structure confusing
[EMAIL PROTECTED] wrote: I forgot to remind everyone of the point behind these apparently fragmented service.xml files They enable easy deployment/undeployment of large chunks of server functionality (including replacing the classes implementing the functionality) WHILE THE SERVER IS RUNNING. In 2.4, to add a datasource non-programatically you had to modify jboss.jcml, stop jboss, and restart. Now you can just drop a mydb-service.xml file in deploy, and away you go. Actually I love that. The app I made for commercial use uses that feature precisely. I deploy user Datasources for each user (really its an app) so all i have to do is modify the user-service.xml add in the new DS then rename it to something besides .xm (giving it time to undeploy Thread.sleep heh) then rename it back to .xml and poof they are all deployed. In the original 2.4x version i had to write a batch task to reboot the server nightly. :( Al ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] current mbean structure confusing
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
Re: [JBoss-dev] current mbean structure confusing
On 2001.12.06 14:01:03 -0500 Bill Burke wrote: MBeans in 2.4.x are really really simple and easy to understand. It's also easy to understand the flow of initialization. IMHO, anything new in 3.0 should be an extension of 2.4.x for more advanced configurations. I'm hoping that 3.0 will move back to 2.4.x's simplicity, but be extendible for more advanced users like Marc suggested. I think it's simpler to write a small config file with exactly the config I need for what I'm doing than mess with trying to find the right place in jboss.jcml and figure out what I need to add/subtract without breaking stuff. Since I always get it wrong 15 or 20 times before it works, I enjoy being able to redeploy just my stuff rather than restarting the entire server. For the alleged simplicity of 2.4 configuration how many people using say Oracle do you think turned off hsqldb DefaultDS? Or realized it wasn't magic, they could change DefaultDS to use Oracle? I think whats needed is some documentation and examples. 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. I want to have an MBean that can do stuff once all other components are loaded. Stuff like, preload Entity Beans and such. Is there a way to create a dependency between all EJBs and the MBean I want to write? Probably not at the moment, I have a bunch of ideas, but it will be a while. Basically I'd like to create mbeans for each deployment unit, similar to the RARDeployment mbean, which is used to force ConnectionFactoryLoaders to wait for the rar they use. If Andreas's mangement mbeans are far enough along you could find out what the object name for the mbean representing your ejb package is and use an anonymous mbean dependency on it in the mbean you want to wait. You might also be able to use anonymous mbean dependencies to the Containers. However both of these ideas require the mbeans in question to participate in the dependency tracking by registering with ServiceController, which I doubt they do. Another idea that would work today would be to write an mbean that explicitly deploys your ejb package (see JBossTestServices for some example code, although this is more complicated than you need, just call J2eeDeployer with the path to the package) and have the other mbeans depend on it. BTW an anonymous mbean dependency is like this: mbean-refJBOSS-SYSTEM:service=myservice/mbean-ref where there is no corresponding property on the mbean. It used to be the AutoDeployer deployed all EJBs before the next MBean was loaded. Why was this changed? (Or was it changed?) I think this was accidental behavior. david jencks View: http://jboss.org/forums/thread.jsp?forum=66thread=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
