To recap:
deployment type | Advantages | Disadvantages
----------------------------------------------------------------------------
-
.sar archive | 1 file | Pain in the ass to configure
| digital signature |
| It already works |
----------------------------------------------------------------------------
-
exploded sar | All files organized | Multiple files are exposed
| within one directory | (potentially many jar
files)
| Uses same structure as | Can not use jar-signing
| .sar archive | techniques
| Easy to configure |
| It already works |
----------------------------------------------------------------------------
-
external config | 2 files | Must distribute as 2 files
| Easy to configure | Not set up like j2ee archives
| | Doesn't work yet
----------------------------------------------------------------------------
-
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.)
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?
-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
