Issue Details (XML | Word | Printable)

Key: GLASSFISH-11710
Type: Improvement Improvement
Status: Open Open
Priority: Critical Critical
Assignee: Hong Zhang
Reporter: vince kraemer
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
glassfish

make --contextroot useful for EAR projects...

Created: 20/Mar/10 07:02 AM   Updated: 16/Apr/13 03:23 AM
Component/s: deployment
Affects Version/s: V3
Fix Version/s: not determined

Time Tracking:
Not Specified

Environment:

Operating System: Solaris
Platform: Sun


Issuezilla Id: 11,710
Tags:
Participants: Hong Zhang, Jeremy_Lv, Tom Mueller and vince kraemer


 Description  « Hide

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



kenaiadmin made changes - 26/Nov/10 12:11 AM
Field Original Value New Value
issue.field.bugzillaimportkey 11710 43314
Tom Mueller added a comment - 06/Mar/12 09:57 PM

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


Tom Mueller made changes - 06/Mar/12 09:57 PM
Fix Version/s not determined [ 11149 ]
Fix Version/s 3.1 [ 10968 ]
Jeremy_Lv added a comment - 15/Apr/13 06:28 AM

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


Hong Zhang added a comment - 16/Apr/13 01:50 AM

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..


vince kraemer added a comment - 16/Apr/13 03:04 AM

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?


Hong Zhang added a comment - 16/Apr/13 03:10 AM

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?


vince kraemer added a comment - 16/Apr/13 03:18 AM

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).


Jeremy_Lv added a comment - 16/Apr/13 03:23 AM

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.