So then you did like the way jboss-auto.jcml worked. I did not.
Regards, Hiram >From: Jason Dillon <[EMAIL PROTECTED]> >To: Hiram Chirino <[EMAIL PROTECTED]> >CC: [EMAIL PROTECTED], [EMAIL PROTECTED], >[EMAIL PROTECTED] >Subject: Re: [JBoss-dev] SAR... Sucky ARchive ? >Date: Sun, 21 Apr 2002 22:18:08 -0700 > >I don't think that merging two sets of config is that much trouble, if you >start out with the xml, use them as defualts, then invoke the mbean >setBLAH() >an interceptor checks a attrib store for a preconfigued value, if there is >one >then it is used, else the provided value is used and that value is not >stored >in the attrib store. > >The only complicated part that I can think of is providing a way to >invalidate >the stored values. > >If there was an AttributeStore for each MBean which you could get a handle >on >the, the bits that know the last modified date of the input source can >compare >it to the last modified of the stored values. If input config is newer >then >AttributeStore.invalidate() then go on with setBLAH() > >But, all of this should be optional... like uncomment this MBeanAttributePM >from jboss-service.xml and it will work, but otherwise leave it as the xml >is >the only input. This way advanced users can enable this easily but we >don't >confuse users with it up front. > >--jason > > >Quoting Hiram Chirino <[EMAIL PROTECTED]>: > > > > > 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 > > > > > > >------------------------------------------------- >This mail sent through IMP: http://horde.org/imp/ _________________________________________________________________ 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
