[GLASSFISH-11710] make --contextroot useful for EAR projects... Created: 20/Mar/10  Updated: 16/Apr/13

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: V3
Fix Version/s: not determined

Type: Improvement Priority: Critical
Reporter: vince kraemer Assignee: Hong Zhang
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Solaris
Platform: Sun


Issuezilla Id: 11,710

 Description   

This RFE is based on a query that I found... http://stackoverflow.com/questions/2469284/deploy-
multiple-instances-of-an-ear-representing-versions-to-glassfish

It would be nice to make it easy to deploy multiple instances of the same ear file on single server.

Right now, you have to edit the descriptors or deploymentplan to put the same ear on one instance of
the server.

It looks like we could do the following, though... pretty simply.

assume I have an ear with a war file in it, mapped to /123

We could use the --contextroot option of asadmin to construct a new CR by appending the option's
argument WITH the CR specified in the application.xml

So:

asadmin deploy EarWith123War.ear
results in the same old CR we would get today, "/123"

asadmin deploy --contextroot /abc EarWith123War.ear
results in a constructed CR /abc/123

If the user needed to deploy another version of EarWith123War.ear, they could do

asadmin deploy --contextroot /xyz EarWith123War.ear
to get the constructed CR /xyz/123



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Comment by Jeremy_Lv [ 15/Apr/13 ]

Hong:
I found it is a critical issue, shall we need to support the option of --contextroot when deployed an ear application in the feature?

Thanks

Jeremy

Comment by Hong Zhang [ 16/Apr/13 ]

The complication is an ear application could contain multiple web applications so there needs to be some correlation between the context root and the corresponding war file when you specify the context root. So I am not sure if it's going to provide much more convenience than the deployment plan if we factor this in..

Comment by vince kraemer [ 16/Apr/13 ]

Hmmm. Say you have an ear with multiple CRs... war1.war has a CR of /123; war2.war has a CR of /789.

If the user said something like 'asadmin deploy -contextroot /abc myTwoWar.ear'

The resulting CRs would be war1.war would have CR /abc/123 and war2.war would have CR /abc/789.

I am not sure I see a need to correlate the CRs and wars (other than the data that is already in the application.xml). Did I miss something?

Comment by Hong Zhang [ 16/Apr/13 ]

If the contextroot option have different semantics for ear and standalone module (one provides prefix and the other provide complete context root), will it cause confusion to the user?

Comment by vince kraemer [ 16/Apr/13 ]

that is a good point. we could use the --contextroot for EARs that have a single war file, though, and that would be consistant and useful for a number of users. If the ear had multiple CRs, the use of --contextroot could generate a useful error message that would instruct the user to create a deployment plan to override the CRs that are in the ear...

or

create a new cli option --contextroot-prefix that would be used as outlined in my previous comment.

The goal is to make stuff easy for the user. Creating a deployment plan is not easy (unless it has improved significantly in GF 4).

Comment by Jeremy_Lv [ 16/Apr/13 ]

There's no specification about this situation, So I think we can implement the option of contextroot-prefix in the deployment side, I think the idea vince kraemer suggest is a nice one. I think the user will be more convinent to use this.

Generated at Thu Sep 29 20:49:43 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.