The problems with auto-jcml stuff was that it tried to merge two sets of configuation data, one set that user maintained and another that was application maintained. Maintain both sets of data was tricky and error prone.
So my thoughts are, we need to be able to support: 1. manual service configuration system (what we have today) 2. automatic configuration system (Modified by a config-tool, JMX??) And for a given service, you can't mix the options. So if we had a jboss that supported both of these options, this is what I image the config would look like: /conf/jboss-service.xml : Same as today except that in addition to the URLDeploymentScanner it would have a Scanner that would deploy the services setup by the config-tool. /db/config-tool : would hold a database of the config-tool managed services. /deploy : would hold *-service.xml files like it does today. This config-tool thing would need to be able to import existing *-service.xml files into it's database. It would need to be able to transparently update it's database when MBean attributes are changed. And there's probably a ton of other things this config-tool based service configutation system needs to do. What I just wanted point out is that it should be able to co-exist with the current system, and that giving users raw access to the data file should not be allowed. Regards, Hiram >From: David Jencks <[EMAIL PROTECTED]> >To: Jules Gosnell <[EMAIL PROTECTED]> >CC: Jason Dillon <[EMAIL PROTECTED]>, >[EMAIL PROTECTED] >Subject: Re: [JBoss-dev] SAR... Sucky ARchive ? >Date: Sun, 21 Apr 2002 20:35:32 -0400 > >On 2002.04.21 21:21:55 -0400 Jules Gosnell wrote: > > > > So : > > > > persist any SPECIFIC settings made through the JMX agent and overlay > > them on top of the DEFAULT settings contained in > > .sar/META-INF/jboss-service.xml. > >This might be doable if we are really careful.... however in the bad old >days of jboss-auto.jcml there were frequent problems of mbeans that >wouldn't die -- their configuration had been saved at some point, then the >user removed the mbean conf from jboss.jcml, but the mbean came back to >life-- it was in jboss-auto.jcml. > >We have to be careful about the semantics we intend for the system. I am >starting to think that if we say that only explicit changes made while the >system is running work properly we may be ok. So if you want to change a >mbean config, you can either change it in the running mbean, or undeploy >and redeploy the config file while the server is running. Stopping the >server, changing the file, and restarting the server won't work. > >This seems a little weird right now, but I think it possible that it is the >only way to get consistent semantics. > >Of course you also need to be able to completely clear the configuration >store and start over. > >david jencks > > > > > but desist from the 'it's such a pain to unpack/repack' argument, > > because, as we have shown, there is no need to repack. > > > > > > Jules > > > > > > > > Jason Dillon wrote: > > >>>But we don't do this... Jetty is part of the release, it is not a > > seperate > > >> > > >>>component which users download and configure. > > >> > > >>until the next release/important-bug-fix of Jetty. > > >>I thought your whole point was that they DO configure it ? > > > > > > > > > My point was much larger than Jetty, with respect to the concept of a > > service > > > archice and service instance configuration... which I detailed more in > > my > > > response to Marc. > > > > > > > > >>If Jetty 4.1 comes out with some new feature that someone wants, why > > >>shouldn't they just upgrade their Jetty plugin. Surely the point of a > > >>plugin is that it decoupled from the core distribution. Otherwise - > > why > > >>bother ? > > > > > > > > > Yes, yes... I agree completly it is a plugin. In this sence though it > > would > > > be better if users did not have to crack open the archive. Think if >we > > wanted > > > to start signing these & performing cert verificatrion to ensure users > > have > > > valid plugins. We can't have them changing the contents then. > > > > > > Do you think that 2 files (.sar & .xml) is really that much more > > trouble to > > > manage? > > > > > > What are the advantages to having only .sar w/ embedded config .xml? > > > > > > What are the disadvantages? > > > > > > I believe that the disadvantages out weigh the advantages by a > > landslide when > > > looking at the JBoss distribution. > > > > > > Take a use case where a user downloads JBoss, needs to enable ssl, >then > > a new > > > jetty plugin is released. You can even add flavors to the use case > > where one > > > is the jetty config is compatible with the previous release and one > > where it > > > is not comaptible. > > > > > > Now, do you really think that 2 files (.sar & .xml) is really that >much > > more > > > trouble to manage? Or do you now see that a single file in this case > > is more > > > trouble? > > > > > > Btw, Jetty isn't the only example of this... so I am not trying to >pick > > on > > > you. It is a good example of user wants to change config from the > > current > > > dist which is archived using all in one .sar. > > > > > > > > >>Jetty is still a seperate project in it's own right, as it has always > > >>been (jetty.mortbay.org). It will continue to have it's own release > > >>cycle and many users (particularly in the embedded and small device > > >>market) who do not use JBoss. > > >> > > >>If I want to distribute important changes to Jetty to JBoss/Jetty >users > > > > >>are you saying that I should not just put out a new jetty-plugin.sar ? > > >> > > >>I thought we were moving towards automagic upgrades from the web > > anyway. > > >>In which case you might get a new jetty plugin anytime you restart > > JBoss > > >>and there has been a fresh Jetty release. > > >> > > >>What is the point in loosely coupling all these components if we are > > >>then going to insist on releasing them all ONLY in one monolithic > > distro > > > > > > > > > Yes, I appologize, I was getting heated at the point I was writing > > this. > > > Agreed, but see my point above. > > > > > > > > >>? We might as well just pack the whole of Jboss into one big jar. > > > > > > > > > This is basically a gross example of what .sar could turn into... what > > a mess > > > it would be to configure that beast. > > > > > > > > >>What about simply distributing the sar with instructions to simply >move > > > > >>it into deploy/ if you use a default config, or unpack it there and > > edit > > >>the jboss-service.xml if you need to make changes ? > > > > > > > > > Do you think that is simpiler than haveing a .sar & .xml by default? > > Again > > > look at the use case. Are we expecting that the jetty config that > > comes with > > > jboss is the one that most of our users will use un changed? If so >why > > are > > > there comments to uncomment sections to enable ssl and such? > > > > > > I think that it is very likly that most users will want to change this > > > config... so rather than special case them, special case those few > > which want > > > a single sar with config inside. > > > > > > > > >>Why bother to be able to run everything unpacked if we are not going >to > > > > >>do it in cases where it would be useful ? > > > > > > > > > I am not really sure what you mean here, but I am going to guess that > > you mean > > > that the jetty .sar with nested config is useful... am I correct? > > > > > > I am not saying that it isn't useful to everyone. I am saying that it > > isn't > > > useful to most of our users, rather it is a hinderence. > > > > > > > > >>What do I gain over running the sar unpacked by splitting the contents > > >>into different directories ? This approach simply makes it more > > >>difficult for me to ship users a replacement Jetty installation. > > > > > > > > > I agreed, which is why I think we should have a jetty-plugin.sar & > > jetty- > > > service.xml. User gets new jetty-plugin.sar with new Jetty and drops > > it in... > > > and that is that... > > > > > > No unjar/edit/rejar... > > > > > > No removed the eploded archive and reexplode the new one, then go find > > the > > > config and change it to what it was before... > > > > > > Simply download new version, copy to deploy and we are done. > > > > > > Isn't this better? > > > > > > --jason > > > > > > ------------------------------------------------- > > > This mail sent through IMP: http://horde.org/imp/ > > > > > > _______________________________________________ > > > 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 > > > > > >_______________________________________________ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
