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
