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