Also.. I think we need a way of feeding configuration change scripts into the server. For example, config snippets showing only the changed values for the mbeans. Furthermore eventually we should make this transactional... all changes succeed or you get back to your original state.
david jencks On 2002.04.22 01:10:06 -0400 Jason Dillon wrote: > What is the hell about jboss-auto.jcml? Is it that you never quite know > what > config is used? If so, then all of these solutions will result in this > hell. > > Though some like it hot... and for them we can provid some abstraction to > > implement a file based persistence or jdbc or whatever. Then the input > xml > files are defaults which are used unless there is a value in the > attribute > store. > > If there is a way to inalidatye the store based on timestamps that would > be > good to... so if a user changes the file it will then override the bits > in the > store. > > --jason > > > Quoting David Jencks <[EMAIL PROTECTED]>: > > > The jmx part of this is the persistence service, which is pretty highly > > configurable. I think jbossmx has an xml-based persistence service > > implementation. I also think it works best with xmbeans or at least > > modelmbeans, another reason to migrate soon. So I think the technical > > issue of storing the mbean attribute values is done, more or less, > rather > > elegantly. I just don't want to get back to the jboss-auto.jcml hell, > and > > am wondering how to think about the problem. > > > > david jencks > > > > On 2002.04.21 21:17:32 -0400 Jason Dillon wrote: > > > Quick thought... if there was a pluggable interceptor in the config > > > service > > > which would filter values as well as some JMX interceptor that would > > > persist > > > attribute changes... > > > > > > Or even a pluggable interceptor around JMX attribute changes (for get > > > config > > > service, cause it will just invoke the server), then we could plug in > any > > > > > > given impl to provide what you are talking about. > > > > > > One that would say create jboss-auto.jcml-like files (only better > > > formatted so > > > we can read them), or a serialzed hashtable with values or a > database. > > > > > > There are some details wich need to be fleshed out, like what happens > > > when the > > > datastore has more values than the config file, how does the mbean > get > > > those > > > config notices. > > > > > > Is there any part of JMX what handles this... lets use it, make it > > > pluggbale, > > > if it isn't already, then provide one ore more impls and let users > choose > > > what > > > posion they eat. > > > > > > Personally I would disable it all and use the static files as the > > > definitive, > > > but others might like to boot up and then fiddle with the html > adapter > > > then > > > expect the changes to remain on reboot. > > > > > > Both are possible... > > > > > > Really, where are the JMX guys... is there something in JMX that buys > is > > > this > > > at ;little design cost? If not, what could we do to implement this? > I > > > think > > > this is easiest done at the jmx level... though it will probably have > to > > > be > > > something that can be described in jboss-service.xml as the first > > > component. > > > > > > --jason > > > > > > > > > Quoting David Jencks <[EMAIL PROTECTED]>: > > > > > > > Jason, thanks for trying to get this discussion back to something > > > useful. > > > > There's another thing I've mentioned a couple of times that I think > is > > > > relevant. > > > > > > > > What's the relationship between the initial config supplied by > > > > *-service.xml files and the possibly modified config in the mbean > > > server? > > > > If someone changes something in the running mbean server, what do > we > > > do? > > > > How persistent is the change? Where do we keep it? I think this is > part > > > of > > > > the same family of questions-- just a different time frame. > > > > > > > > -- how do you easily modify config before deployment > > > > > > > > -- how do you save config changes made to deployed apps. > > > > > > > > I don't have a good answer. I'm trying to think of the situation > like > > > a db > > > > -- deploying an mbean like an insert, modifying its config like > update. > > > > > > > Undeploy should be like delete, but shutting down a server and > > > restarting > > > > is like ????? I think you should perhaps end up with the same > config > > > as > > > > you had before you shut down. But if _you_ change a config file, > > > should > > > > you have to undeploy and redeploy it to get the changes to stick? > I > > > don't > > > > know. > > > > > > > > Thanks > > > > david jencks > > > > > > > > > > > > On 2002.04.21 19:00:31 -0400 Jason Dillon wrote: > > > > > > don't be an ignorant bastard on your own idea and its actual > > > > > > implementation. > > > > > > > > > > Whatever dude... I am enlightened to users needs, to the needs of > IT > > > > > professionsals who need ease of configuration managment... I am > > > > > enlightened to > > > > > the possibilities of creating a super system around JBoss which > will > > > > > dynamiclly generate xml configuration for anonymous hosts in a > mega > > > > > cluster. > > > > > > > > > > I am thinking outside the box, outside the archive... and trying > to > > > get > > > > > the > > > > > usage of .sar back on track to what those fucking birds were > > > saying... > > > > > which > > > > > was seperation of code and configuration. > > > > > > > > > > My email suggested that each service archive contain some config > to > > > show > > > > > what > > > > > classes of services were provided by it. So taking the jetty > example > > > it > > > > > might > > > > > have a list like [ "JettyService" ]. Then an *external* > > > configuration > > > > > system > > > > > (be it xml, database, whatever) could be used to create an > instance > > > of > > > > > that > > > > > service. > > > > > > > > > > If say you have a database which stores this information you > might > > > then > > > > > create > > > > > a configuration entry name "MyJettyService", which is linked to > > > > > the "JettyService" by name and has a text field for storing the > > > actual > > > > > xml > > > > > config. > > > > > > > > > > When the system starts up it loads archives, finds the > > > jetty-plugin.sar > > > > > parses > > > > > its descriptor, finds out that there is a "JettyService" service > > > class in > > > > > > > > > > here, then asks the ConfigurationService for all configs for > > > > > "JettyService" > > > > > and starts up each instance it has. > > > > > > > > > > Now this isn't an ideal design, nor was the original months back, > but > > > one > > > > > of > > > > > the core concepts was seperation of configuration... or rather > > > seperation > > > > > of > > > > > service instance configuration. > > > > > > > > > > Clearly we have lost that direction... which is why I wrote this > > > thread > > > > > and is > > > > > why I have continued to respond trying to communicate why it is > > > better > > > > > for > > > > > this seperation to exist and why we should ship our product with > > > config > > > > > seperated by default. > > > > > > > > > > * * * > > > > > > > > > > > |Take Jetty for example. I am a user and I want to change the > > > > > > |port, or enable SSL or add a non-deployed webapp for > > > > > > |development... how do I do that? I have to break open the > > > > > > |jetty-plugin.sar, change jboss-service.xml, rejar it, then > > > > > > |redeploy. What a huge pain in the ass! > > > > > > > > > > > > wow, which means it is the first time you use that (remember > the > > > mails > > > > > from > > > > > > Bill/me about 6 month ago?) and we already have a solution > > > > > > > > > > No I don't remeber the emails... is there a link in the forum? > > > > > > > > > > > just drop the jboss-service.xml in deploy > > > > > > reference the jar that has the file in the classpath of the > > > service.xml > > > > > > they will be deployed as independent jar (and cycled > accordingly) > > > > > > > > > > BUT MY POINT IS that we should ship like this BY DEFAULT... it is > > > EASIER > > > > > and > > > > > SIMPILER for users to change the config... the alternative is > only > > > more > > > > > complicated. > > > > > > > > > > Shipping components like this vilotates your beloved K.I.S.S. > > > > > principle... > > > > > unless you mean to say that we won't expect users to change the > > > config at > > > > > > > > > > all... but that is just plain ignorance. > > > > > > > > > > > |I think that the concept of a SAR is still useful and we > should > > > > > > |not cast it aside, but there are some limited cases where we > would > > > use > > > > > > one. > > > > > > > > > > > > As Frederick Brier pointed out in response to this, it is > useful > > > for > > > > > > shipping self-contained configuration of beans. End of story, > very > > > > > useful, > > > > > > get off the wanking box. + all the examples you give below. > > > > > > > > > > Yes, it is useflu I am not arguing that is isn't... I think that > it > > > would > > > > > be > > > > > better to have them cleanly seperated, but if you want them all > in > > > one, > > > > > then > > > > > go for it... (see BUT MY POINT IS) > > > > > > > > > > > |For example, SAR is good for grouping like .jar's together. > There > > > > > > |are several jars needed for Jetty to work, and it makes sence > to > > > > > > |group them together inside of a super archive. When used in > this > > > > > > |manner it makes it easy to create an explicit classload > hierachy > > > > > > |(when we have that capability). > > > > > > | > > > > > > |SAR is also good if you want to distribute a set of native > > > > > > |libraries. In this usage you would put in a version of the > lib > > > > > > |for all supported platforms. > > > > > > | > > > > > > |SAR is good to provide a static filesystem, or the intial > > > > > > |structure for a dynamic filesystem which is needed. > > > > > > > > > > > > Jason WTF are you doing, are you trying the negative publicity > > > thing to > > > > > > remind the group that the idea was yours and that it works??? > why > > > this > > > > > > email. > > > > > > > > > > Whatever... I don't need to stoop to such levels to boost my > ego... > > > and > > > > > if I > > > > > did this would have been a rather backassward method todo so. > > > > > > > > > > I believe that we can make the system better, more managable & > more > > > > > coherent > > > > > by keeping the seperation clean. I want to help move the core > system > > > in > > > > > positive directions, which is why I wrote the email, not to > remind > > > anyone > > > > > of > > > > > anything. > > > > > > > > > > > |Serivce config MUST be seperate from the archives. This is a > huge > > > > > > |defficeny with the EJB-JAR, EAR & WAR formats from SUN. While > it > > > > > > |was a good idea to group the support files, it plain sucks ass > to > > > > > > |put the config in there too. > > > > > > > > > > > > IT IS ALREADY SEE ABOVE, SEE MY MAILS FROM THE BILL THREAD ON > THE > > > > > > "PACKAGING > > > > > > NIGHTMARE"... GEEZUS > > > > > > > > > > No it isn't... not in the downloadable from SF.NET. Go download > the > > > RC1 > > > > > and > > > > > then chnage the jetty port. Or enable ssl.... or change the jmx > html > > > > > adapter > > > > > porty or enable authentication. > > > > > > > > > > Take a look at what the user of the product will have to go > through > > > > > change the > > > > > config... or if you prefer what the customer will have to go > through. > > > > > > > > > > We have the power to make it easier for them out of the box... > which > > > will > > > > > > > > > > increase the chances that they will have a good experence and > will > > > stay > > > > > with > > > > > it and not go to another vendor. > > > > > > > > > > Why not make it easier? > > > > > > > > > > --jason > > > > > > > > > > ------------------------------------------------- > > > > > This mail sent through IMP: http://horde.org/imp/ > > > > > > > > > > _______________________________________________ > > > > > Jboss-development mailing list > > > > > [EMAIL PROTECTED] > > > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------- > > > 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 > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
