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 Jason Dillon wrote: > Jules, how about making the jetty-plugin.sar just contain the jars and have a > seperate jetty-service.xml? > > --jason > > > On Friday 31 May 2002 04:31 pm, Jules Gosnell wrote: > >>Scott, >> >>Would you mind if I moved the jasper.jar from lib/ to jetty-plugin.sar ? >> >>I figure: >>- jasper is an implementation >>- jasper version is tightly bound to Jetty version >>- Tomcat users will have their own version of Jasper >> >>I think the servlet api jar should stay in lib, seeing as this is part >>of the definition of the JBoss platform and will be needed by users to >>compile against (whilst they should not need Jetty and Jasper classes) >> >>My preemptive advice to anyone concerned that a sar is awkward to work >>with, because the configuration is, hidden is : "run it unpacked". >> >>Concerns ? >> >> >>Jules >> >>P.S. >> >>What is the arrangement between HEAD and Branch_3_0 - would I be >>correct in assuming that bug-fixes should be merged, but new features >>not ? >> >> >> >>_______________________________________________________________ >> >>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 > > > > _______________________________________________________________ > > 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 _______________________________________________________________ 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
