> 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

Reply via email to