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. 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
