Thanks for the recap, but it is in correct. > deployment type | Advantages | Disadvantages > --------------------------------------------------------------------------- >- - > .sar archive | 1 file | Pain in the ass to configure > > | digital signature | > | It already works |
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... > exploded sar | All files organized | Multiple files are exposed > > | within one directory | (potentially many jarfiles) > | Uses same structure as | Can not use jar-signing > | .sar archive | techniques > | Easy to configure | > | It already works | The major disadvantage of this is the added complextity of the configuration... there are no other directories in deploy... there do not need to be more directories there. Using an explosed archive here just complicates. Though this does simplify, it does not simplify completly... there is still some complexity to be factored out. > external config | 2 files | Must distribute as 2 files > > | Easy to configure | Not set up like j2ee > | archives > | > | | Doesn't work yet > So, this does work. Why do you believe it does not? Fuck J2EE config, that is a fucking mess. If you want J2EE-like config then put it back in the single .sar. I belive that users would rather have easy to config, easy to understand than J2EE-like... fuck that. This is the situation where digi signature could be used to ensure the validitiy of the impl code and resources and allow the config to vary. Consider a company which provides a plugin and they provide support for it. They could sign the impl archive to ensure that users have not mucked with it. An must distribute as 2 files? What? Now you are talking about distribution, or do you mean deployment? For distribution you will want to zip/tgz these up with a simple install guide, other docs, whatever. For deployment, copy files x and y to deploy/... big deal. This is the most complicated part of this option... copying 2 files. All of the are significantly more complex. > 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. > This would give us the best of all solutions. Sar's can be shipped with an > embedded factory default configuration, and the user can easily override > those settings by adding a configuration if they need it. Also, this gives > a simple place for MBean configuration changes to be persisted. What do > you think? Um... users can already override each of these... all of the above are possible with JBoss3 today... ALL OF THEM. The matter is which is the simplest... which is going to be the easiest and most intuitive for the largest number of users who download the release. We want to make JBoss easy to use for the masses... and configurable todo as you please for everyone else. Option C, 2 files, provides the most coverage for all of these problems, and does not introduce any added release management complexity. It is the clear and simple solution... why complicate any further? --jason _______________________________________________________________ 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
