glassfish
  1. glassfish
  2. GLASSFISH-11710

make --contextroot useful for EAR projects...

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: V3
    • Fix Version/s: not determined
    • Component/s: deployment
    • Labels:
      None
    • 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

        Activity

        vince kraemer created issue -
        kenaiadmin made changes -
        Field Original Value New Value
        issue.field.bugzillaimportkey 11710 43314
        Hide
        Tom Mueller added a comment -

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

        Show
        Tom Mueller added a comment - 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 -
        Fix Version/s not determined [ 11149 ]
        Fix Version/s 3.1 [ 10968 ]
        Hide
        Jeremy_Lv added a comment -

        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

        Show
        Jeremy_Lv added a comment - 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
        Hide
        Hong Zhang added a comment -

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

        Show
        Hong Zhang added a comment - 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..
        Hide
        vince kraemer added a comment -

        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?

        Show
        vince kraemer added a comment - 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?
        Hide
        Hong Zhang added a comment -

        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?

        Show
        Hong Zhang added a comment - 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?
        Hide
        vince kraemer added a comment -

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

        Show
        vince kraemer added a comment - 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).
        Hide
        Jeremy_Lv added a comment -

        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.

        Show
        Jeremy_Lv added a comment - 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.

          People

          • Assignee:
            Hong Zhang
            Reporter:
            vince kraemer
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: