Lets not force every user down that path... lets make it possible then let the user choose.
--jason Quoting David Jencks <[EMAIL PROTECTED]>: > 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 > > > > > ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
