On Fri, Jul 27, 2012 at 12:09 PM, Bill Shannon <bill.shannon_at_oracle.com>wrote:
> What do others think?
>
Hi, Bill (and others); we had a conversation about this at JavaOne 2011.
At the time I brought up the concept of a configuration archive (.car?)
that could be deployed separately from an application that depends on it.
(Prior to that many years ago I also advocated for a java.util.prefs
implementation for EE.)
The idea would be that such an archive could be defined in terms of Java
classes, not just XML files (though certainly the default implementation
would read config files). This is very much akin to what, say,
java.util.logging does to initialize: drop a logging.properties file in The
Right Place and the default configurator takes over, or supply your own
configurator to supply all the relevant information by any means you want.
So deploy a .car, and say in its deployment somehow that it is to apply to
new and existing deployments of various other .ar files ("Hi, I am the .car
that will configure ljnelson-foobar-ear (say), should such an application
ever be deployed on this container in the future."). This is very much in
spirit like GlassFish's deployment plan, but removes the restriction that
such a deployment plan must be based on XML files.
I won't speak for Craig, though I suspect that he and I see things almost
identically. The salient point here is that I should NOT have to touch or
repack a .ear or a .war file that I receive from someone else. I know
that's how the specification was designed, I understand how it works; I
understand that these various archives are supposed to contain their own
worlds (.ear files especially). But my customers (understandably) don't
like it. This also explains why the alt-dd mechanism is still quite
unsuitable as it only permits you to refer to a dd that is *inside the ear
file*, the very problem we'd like to avoid.
I will try to put together a more formal proposal if for no other reason
than posterity :-) though, like Craig, I am much more of an end user than a
spec hacker.
Best,
Laird
--
http://about.me/lairdnelson