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/ > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
