[javaee-spec users] Re: Descriptor overrides
- From: Laird Nelson <ljnelson@...>
- To: users@...
- Subject: [javaee-spec users] Re: Descriptor overrides
- Date: Fri, 27 Jul 2012 12:36:40 -0700
On Fri, Jul 27, 2012 at 12:09 PM, Bill Shannon <bill.shannon@...>
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.