Hello, Laird.
Here is one, quick, shoot-from-the-hip response. It might or might not work for you and it might or might not be ideal, but you should at least consider it.
GlassFish supports a concept known as deployment plans. The original idea is that a developer could build a single, portable application and package it into an EAR and place the vendor-specific descriptors into a second JAR, the deployment plan JAR. When you deploy the app you specify the deployment plan along with the portable application. If GlassFish finds an overriding descriptor in the deployment plan, it uses that one. Otherwise it uses the descriptors in the portable EAR.
Although originally intended to segregate portable from vendor-specific descriptors, I think you might be able to use the deployment plan for your purposes as well and override the standard descriptors as well.
To map this to your use case, you could ship the EAR and perhaps also ship a deployment plan JAR with copies of your descriptors...or at least the ones you want your customers to revise. Your customers would need to unpack the deployment plan, make their modifications to the descriptors within, and then recreate the deployment plan JAR. Then they could deploy the original EAR with their edited deployment plan. This seems sort-of close to what you were describing.
To my knowledge there are no slick tools to help with this, although there could be and I'm just not aware of them. So as of right now there would be some manual steps. And because it involved unpacking and repacking the deployment plan maybe this is not much better than doing that to the original EAR.
The documentation discusses deployment plans far better than I just did. There's some treatment of deployment plans here:
http://docs.oracle.com/cd/E26576_01/doc.312/e24929/deploying-applications.htm
- Tim
On May 9, 2012, at 6:59 PM, Laird Nelson wrote:
> 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
>