Seems kind of tricky... but perhaps not. Since when we shutdown the server we don't really undeploy right now, we simply stop and destroy... or do we undeploy? Seems a bit risky, I can see someone developing a deployer whjich would undeploy its children when stopping, which might be desirable for it... but woiuld screw up this method of persistence.
Is there no answer ala JMX for invalidating the persistence of an mbean? Also is this on an mbean by mbean basis? If so then it seems like a lot of trouble to configure persistence for each of them. I browsed through Juha's book. I should go read... is persistence documented well there too? Except I don't really have time for this right now. Can't we solve this problem once some of the other larger problems are fixed? It seems like we are trying to hard to get too much done and end up getting very little done... not that you are anoyone else is not getting things done, just lets get the major things fixed first... deployment dependencies for example. --jason Quoting David Jencks <[EMAIL PROTECTED]>: > Most of this is taken care of by the xmbean persistence descriptors, and we > can add more as necessary. Read Juha's book, and look at the xmbean dtd. > > I think the ways to undo a stored configuration are to explicitly undeploy > the mbean, either individually through some interface or by undeploying the > package it came from. If we save the timestamp of the config file by > making DeploymentInfo a persistent mbean, we will be able to see if a > config file changed while the server was down, and reread it if it has, and > go with the persisted config if not. > > david jencks > > > On 2002.04.22 01:18:08 -0400 Jason Dillon wrote: > > 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/ > > > > > ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
