On Wed, May 9, 2012 at 6:36 PM, John Clingan <john.clingan_at_oracle.com>wrote:
> Hi Laird. To better understand the use case, do you use any tooling to
> facilitate this or is this all via CLI? Is this during development,
> production, or moving an app from dev->test->pre-prod->production?
>
I'll try to speak for a great class of users that for whatever reason don't
always seem to show up on this list but that are out there, trust me. :-)
In our case we ship an .ear file (currently; we may ship various .*ar files
in the future). It is a product. Our customers take delivery of it and
expect to customize it in various ways.
The first thing that always comes up is binding their LDAP/Active Directory
setup to our roles. I am unaware of any tooling to assist with taking a
black-box .ear or .war file and editing various deployment descriptors
inside it. I would be very excited to know of such tooling if it exists.
So then I get to tell them a story about how they take our product, open
it up, find another product inside it, open it up, edit a file in there,
re-zip up that product, then rezip up the containing product, and hopefully
name it something different or otherwise manage it so they don't now
confuse their customized product with our stock one. Then when they take
delivery of a new version of our product, they need to unzip their
customized one again and diff whatever they've changed against the contents
of whatever we've newly supplied them. Yuck.
The next thing that comes up is various too-lightweight-for-a-database,
set-once-and-forget-it property/environment settings. These are (per the
spec) usually encased inside ejb-jar.xml files. Same thing.
The next thing is frequently our customers will take our .ear file and want
to swap out some of our implementations of a given business interface and
replace them with their own. Some of this is scripted up with build tools,
but incurring a Build here is kind of heavyweight, it seems to me, for what
is fundamentally a packaging operation.
Various people have pointed me towards the alt-dd element as some kind of
magic catch-all that will solve various aspects of this problem, and
perhaps it would, but for me it would only be useful if it could point
"outside" of the .ear file. Of course it cannot, as the spec is currently
written, because the .ear file is the whole world/environment.
Even that wouldn't fully help. One rough partially baked idea I had in
this area was to allow in the spec (or in various vendor implementations) a
way to "chase" an .ear file with another .ear-like archive containing its
configuration. If the application server detected such a configuration and
that configuration matched the current environment in some unspecified way,
then THAT would be the configuration it would use. This way the stock
product could be signed, versioned, etc. safe in the knowledge that it
wouldn't be mauled by the customer, but a solution would exist for
constantly changing configuration data. I'm sure there are all kinds of
problems with this proposal, but my overall aim is to break out the stuff
that people tweak and doctor all the time from the stuff that stays static.
Deploy and manage configurations separately from the product they
customize.
(Note that this is exactly the pattern that is followed by anyone who says
"just put your properties in a database". In this case, a database is
simply a place for your configuration to be managed and versioned and
"redeployed" and whatnot apart from the app which it customizes. I'm just
proposing making this general separation more platform/technology agnostic,
and standardizing its location and how it is activated/deployed: it doesn't
have to be a database, indeed it probably shouldn't, and could easily be a
combination of file-based and Java-class-based customization options. For
example, java.util.logging allows you to customize logging by using a
properties file or by swapping out the customization class altogether. I
think such a feature in Java EE land would be great.)
Thanks; happy to discuss this offline or on another list, and will make
sure not to hijack this list further for this discussion. Thanks for
listening.
Best,
Laird
--
http://about.me/lairdnelson