users@glassfish.java.net

Re: Best mailing list to start a Java EE configuration discussion?

From: <hong.hz.zhang_at_oracle.com>
Date: Thu, 10 May 2012 11:59:47 -0400

This is the "Across the board DD property substitution" discussion I
mentioned earlier:

http://java.net/projects/javaee-spec/lists/users/archive/2012-04/message/42

On 5/10/2012 11:53 AM, hong.hz.zhang_at_oracle.com wrote:
> 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