Hi, Laird
> On Thu, May 10, 2012 at 10:59 AM, Tim Quinn <tim.quinn_at_oracle.com
> <mailto:tim.quinn_at_oracle.com>> wrote:
>
> 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.
>
>
> That is excellent and gets me partway there. Is that a
> JSR-88-specified thing (the documentation you referred to indicates
> that it is; I'm not familiar with JSR-88 yet)?
You don't need to use deployment plan with JSR88, the deployment plan
support was put in for JSR88, but it could be used with admin CLI
command as well. Just do asadmin deploy --deploymentplan <deployment
plan jar> ..
>
> 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.
>
>
> Meaning...you think that Glassfish happens to behave this way, or is
> intended to behave this way? :-)
Today it's only supporting vendor specific descriptors, but we could
enhance it to support standard deployment 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.
>
>
> It sure is. What I'd really like to see is this expanded even
> further, so that the deployment plan might be programmatic as well.
> Maybe, for example, I really DO want to store my deployment
> information in a database or a file on disk or something. So wouldn't
> it be neat if I could pack up my own Configurator class that could do
> whatever it wanted to come up with the values that the Glassfish
> runtime needs? Then Glassfish could just ask the deployment plan: I
> need a value for X, and if the deployment plan came up with it, it
> would be used; otherwise the default behavior would happen.
>
> I wonder: do these deployment plans persist? That is, if I use one to
> deploy an .ear file, must I always re-reference it when I redeploy the
> .ear file, or is it "sticky"--i.e. Glassfish stashes it away somewhere
> and references it again implicitly if I don't supply one on the
> command line?
No, you have to reference it each time when you redeploy.
>
> Anyway, now that you've pointed me in the general JSR-88 direction
> I'll have a look over there to see if all these features are addressed
> in some way. I was also under the impression that JSR-88 was
> deprecated or otherwise on the way out? Maybe I'm thinking of the
> management stuff instead; have to research that.
As I mentioned earlier in the email, you could just use the deployment
plan with admin CLI.
>
> 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.
>
>
> No, that would be considerably less pain. The nested unzipping is the
> real killer.
>
> 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
>
>
> Appreciate it.
There is actually a discussion currently going on in the Java EE 7 spec
forum with subject "DD Property Substitution" which is intended to
address similar customization issue. Let me see if I find a URL to
access this discussion.
Thanks,
- Hong