I agree here completly. In most cases users will want to change the config for jetty... a split impl and config lets them do this with relative ease.
This does not compremise and of the release seperation that Jules has the jones for either, instead of one file to manage he now has 2, big deal. Sar with nested jars is a little easier from the build system perspective, as the jlink taks, which is unsed to merger jars is still kinda wacky. But I don't care one jar or sar w/jars. I do care that the servic.xml is outside of that though... it is the logical and resonable thing todo... so lets do it! --jason Quoting Scott M Stark <[EMAIL PROTECTED]>: > Ultimately the configuration of every mbean is going to be seperate from > its implementation to support persistence of changes made through the > management interface. Install the jetty sar as an unpackaged distribution > then since the web service is the most likely item users will want to > configure > off the default. Sar vs service.xml + jar are the same in my book and > trying to define one as superior to other in all cases is just mental > masterbation. > > xxxxxxxxxxxxxxxxxxxxxxxx > Scott Stark > Chief Technology Officer > JBoss Group, LLC > xxxxxxxxxxxxxxxxxxxxxxxx > ----- Original Message ----- > From: "Jules Gosnell" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]>; "Jan Bartel" <[EMAIL PROTECTED]>; "jason" > <[EMAIL PROTECTED]> > Sent: Friday, May 31, 2002 5:59 PM > Subject: Re: [JBoss-dev] Where should the Jasper jar live ? > > > > > > I had a feeling I would never sneak this through without opening a can > > of worms. > > > > Jason, > > > > Why have a sar of jars and a separate service.xml ? You might as well do > > as Scott suggests and collapse all the jars into one. Besides, if a sar > > is not deployable (because it has no dd) and therefore does not > > encapsulate a JMX service - why call it a sar ? > > > > Scott, > > > > I assume you are suggesting this is order that people can easily edit > > the jetty-service.xml ? > > > > > > Both of you guys... > > > > I have been asked several times why I do not separate jetty > > implementation and configuration... > > > > I see the Jetty plugin as a module of the JBoss MicroKernel. > > That module should be self-contained, so that e.g. you could swap out > > Jetty and swap in Tomcat, or just swap out your web-container if you do > > not want it. > > > > If you just swap out the config, you are left with a load of classes in > > your tree which you are not using. > > > > If you are upgrading versions of a plugin, it is simpler to copy in one > > file than two. > > > > Jetty is still an independant project, with it's own release schedules, > > and this is a useful feature for us. > > > > As I preemtively struck in my first mail - "run the sar unpacked", if > > you need quick access to the config. We could even distribute the > > jetty-plugin unpacked. > > > > > > I think that the sar is a nice encapsulation of a JBoss service, the > > natural way to deploy services on the JBoss MicroKernel. > > > > Why then are the chief architect and the guy who came up with the idea > > no longer backing it ? > > > > > > Jules > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
