Hi Laird,
We have been discussing a solution for that exact problem (although the
solution would offer a number of other benefits, as well) in the form of
what could be called a "configuration service". In a nutshell, it would
allow a separate "deployment unit" to specify configuration information
that could apply to one or more applications (the applications to which
the configuration may be currently deployed or deployed at some point in
the future). This would provide an architecture for decoupling the
configuration from the application archive, as well as provide a
potential framework for more sophisticated applications to respond to
dynamic configuration, if such a thing was required in the future.
In your case, if the container supported such a configuration service,
you would be able to submit the configuration to the server and then
deploy the application, having the configured environment injected into
it if desired. Is this close to what you were picturing as well, or did
you have something else in mind?
-Mike
On 10/05/2012 12:18 PM, Laird Nelson wrote:
> On Thu, Apr 19, 2012 at 12:53 PM, Jason T. Greene
> <jason.greene_at_redhat.com <mailto:jason.greene_at_redhat.com>> wrote:
>
> Another consideration is supporting multiple sources (system
> props, container props, password stores, etc). We could leave this
> up to the vendor, or define a common set.
>
>
> Hello; I am a lowly Java EE user who is late to this discussion. I
> happened to have raised a similar set of issues over on the Glassfish
> list
> (http://java.net/projects/glassfish/lists/users/archive/2012-05/message/23 and
> following). They just referred me here.
>
> I don't want to wade into an area that has already solidified, or
> otherwise upset the apple cart. Is this a good place to talk about
> customization/configuration of .*ar files in Java EE?
>
> Briefly, I'm looking to see what can be done in Java EE 7 (or beyond)
> to support managing the configuration and customization of an .ear
> file such that the .ear file could itself be left unmodified. A
> secondary goal would be to follow the general spirit of something like
> java.util.logging where the customization mechanism uses
> files/resources by default, but can be programmatic if that's really
> what the user wants. The driver behind all this is our customers'
> frustration at all the zipping and unzipping they have to do to
> customize our .ear file.
>
> I'll leave things there to start just in case I'm in the wrong place
> or this isn't the time to discuss these issues. I'm also happy to
> flesh out a proposal in more detail offline. I just wanted to see if
> this was a good spot to kick off discussion.
>
> Thanks for your time (and attention),
> Best,
> Laird
>
> --
> http://about.me/lairdnelson