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
