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
