> digi sigs will not work when you need to change the config. it is only useful > if you have static config and want to ensure that the contents do not change. > the second you need to chagne the config, you must resign...
Right. The point is, it can be distributed with a signature, as long as you don't need to do any custom configuration. > The major disadvantage of this is the added complextity of the > configuration... I (and it sounds like Marc and Jules are with me) will forever disagree with you on the usefulness of exploded archives. I find them useful - you don't. I do agree that they are not the perfect solution, and you also agree that it simplifies things at least a little. I'm content to leave it at that. > So, this does work. Why do you believe it does not? Mental hicup. Of course you are right, the separate configurations do indeed work. > Fuck J2EE config, that is a fucking mess. I am inclined to agree with you here - configuring an ejb is a pain in the ass. I listed it as a disadvantage simply because it is different than what users are used to. > An must distribute as 2 files? What? Now you are talking about distribution, > or do you mean deployment? There are a number of deployments that rarely (or never) need any custom configuration. In these cases, the best solution is the traditional .sar with config included. To make them shuffle 2 files is not a huge deal, but I do count it as a disadvantage. >> I propose we allow the following: For any configuration file (or >> deployment descriptor) that exists within an archive, we allow an external >> version to override it. Ex: >> >> jetty.sar (fully compressed, with META-INF/jboss-service.xml) >> jetty_jboss-service_override.xml (Or something. I suck at coming up with >> names.) > > No, why do we need this at all? Who are we trying to cater too here? Who > will beninfit most from the simple solution (option c), and how will beninift > from the others. I am not suggesting we make it impossible to get a or b if > they want... but I am suggestion that users who want a or b have specific > needs which we can not and must not assume that all of our users will have. Option a is best for those deployment's where you never need to touch a configuration file. Option b is best for people developing something that will eventually be deployed as an Option a. Option c is best for 3rd party deployments where custom configuration is needed. I think we agree here, yes? My proposal offers a solution to two additional problems. 1) How do we persist configuration changes 2) What's the best way to distribute a deployment that rarely needs configuration. We need to solve the persistent configuration problem anyway. The solution that jumps to mind (support an external configuration file that overrides the internal one) also happens to provide an answer for problem 2. -Larry _______________________________________________________________ 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