> 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 ?
A sar of jars is a convient construct with respect to the build system. No need to use crappy jlink task or to unjar/rejar which will cause thr build to make a new target archive each time. > I assume you are suggesting this is order that people can easily edit > the jetty-service.xml ? Um yes... bingo. Users will want to and need to change the Jetty config. > Both of you guys... > > I have been asked several times why I do not separate jetty > implementation and configuration... I do not recall you ever asking to seperate, only requesting not too for release management reasons. > 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. Yes, it is... but so is everything else. Does this mean that we should make every deployable into an .sar? Certainly not, asd that will be a royal pain in the buttocks. ;) > If you just swap out the config, you are left with a load of classes in > your tree which you are not using. Certainly, but this back to the one vs. two file problem. I belive that when enducated users can handle the extra file. I believe they will appreciate the seperation... and if they don't they are free to make it one. > If you are upgrading versions of a plugin, it is simpler to copy in one > file than two. Please... this is a very, very, very weak argument dude. If a user is upgrading the chances are very high that the configuration will differ in the new config... not that the default Jetty config changed, but that the user changed it.... so if you break it down into steps, 2 files is less work than 1 .sar. Do the math, if you need me to spell it out I will. > Jetty is still an independant project, with it's own release schedules, > and this is a useful feature for us. Yes, but it is also imported into our sources, which removes the release problem... actully replace that problem with a few more (import change management, module integration and build system maintenence). But that is a completly different story. > 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. A unpacked .sar is the .jars in lib/ and the config in deploy/, which gets us back to more than 2 files and thus an mangement problem. > I think that the sar is a nice encapsulation of a JBoss service, the > natural way to deploy services on the JBoss MicroKernel. It is and it is not. It is because it is a natural mechanism to group files and can be used to seal configuration for static services or where jar signing is used to ensure the config integrety. It is not, because it make more work for our users (you know the folks we put all the work in for... that includes folks who give us money too). It makes a desicion for them based on asumptions which may not be true. I assert that the cases where sar with config is useful is relativly minor compaired to the alternative. Jetty sar + config is only useful for people who are fine running on 8080 and are fine with the request log and don't need ssl or anything else. Why do we provide in the default release a component (actually a few components) which are a pain in the ass to configure. The world needs less pain... and if pain is what they want they can .sar it themselves. > Why then are the chief architect and the guy who came up with the idea > no longer backing it ? The service archive/service controller idea I pitched months ago was very specific about keeping configuration seperate from impl classes and resources. VERY SPECIFIFC. I have been working with configuration manegment for close to 10 years.. well could be 8 but whos counting. Binging config up with impl is a nice feature, but is does not make the job of setting up and managing the configuration of a system and easier.. in fact with out tools to automate the work involved with keeping and maintaining config in a sar it is a nightmare. So how does one fix this... well they either write a config system around this (which if you read my original birds email that is what I was leaning twords, a programatical aproache to linking server impl to config) or you unpack all of the sars and manage your own jboss dist... making it more work to update when a new rev is out. * * * There is no reason to put the jetty service config in the plugin sar... there are only reasons not to. As for .sar w/ .jars or a single .jar I don't care. This is like night and day to me. I have looked at this from all sides and the best option is a .sar/fat .jar + service.xml. I have been on the build management side, the webapp developers side, the administartors side as well as the JBoss contributor side and no matter how I look at the problem, the answer is 2 files. It is simple, provides the best coverage of the typical usage of the product, does not force users to work more to get at configuration and yet does not limit them from packing them up in a sar as they wish. --jason --jason ------------------------------------------------- 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
