OK, It looks like I have been bludgeoned into seperating Jetty config and impl.
Just for the record, Jason, I still don't think you have taken in my suggestion. You seem to think that I am belligerently hanging onto the idea of delivering Jetty in a single file, which needs unpacking, editing and repacking in order to change the port number. If this is not the case - apologies If it is - WAKE UP (I'm allowed to raise my voice here, because I am following precedent). I have suggested delivering the jetty-plugin UNPACKED numerous times (as you will now find it if you build HEAD). There is NO unpack/repack needed to edit the configuration. You just edit deploy/jetty-plugin.sar/META-INF/jboss-service.xml. If I see one more reference to having to pack/repack the sar, I will go mad. The only difference between what you suggest and I suggest is the location of the Jetty files. You want to split them up (into 2 different dirs) across the JBoss distrib. I want to keep them together (in 1 dir), so that it is clearer exactly which parts of JBoss constitute Jetty, in order that anyone can replace that module trivially. I can't make it much clearer than that. I don't think that anyone has made a decent case for not having the Jetty impl present in the deploy directory. The plugin (impl and cfg) IS a deployable. However in the interests of conformity and world peace, I shall fall on my sword and repackage Jetty according to a greater wisdom. Ouch :-) Jules P.S. Did anyone actually have anything constructive to say about where Jasper should go ? Jason Dillon wrote: > dislcaimer, a few beers in me after the laker game... > > >>The natural progression of all this separation of config and >>implementation is that we will begin encouraging people to take all the >>resources out of their ears and deploy them in lib/, then just drop the >>dds into deploy/. > > > Who gives a fuck? My point from the begining was that you are forcing users to > unpack the fucking sar to change the config... which they will want todo. > > >>Ok, so they can edit their descriptors - but it's not J2EE, is it ? > > > Again who cares... j2ee blah. > > >>Likewise, the sar is a nice extension of the J2EE packaging metaphor. > > > Sar is nice when you need to group jars... or if you want to lock config. I am > not saying that sar is bad... only that our usage of it with jetty is. > > WE EXPECT PEOPLE TO CHANGE THE JETTY CONFIG... in fact all of the times I have > used JBoss3 in production (both at work and for the website) I have had to > change the config. > > >>It may not be perfect, but this is the platform that we are >>implementing, and I think consistency is important. >> >>Comments ? > > > Dude... what is the problem with a .sar/.jar + .xml? 2 files... big deal... > tell me what the problem is and we can work a solution. I have already told you > over and over and now over agaion of the problem of shipping the jetty config > inside of a sar. > > I am sorry if I seem harsh, but I think that the answere is obvious... but you > are still balking on it... why? > > --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 _______________________________________________________________ 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
