glassfish
  1. glassfish
  2. GLASSFISH-14081

support .xxx (such as .war) as the sub module directory for directory deployment

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.1
    • Fix Version/s: future release
    • Component/s: deployment
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

      Description

      Currently we assume the sub module directory name will always be _xxx (_war)
      for directory deployment. But we should support .xxx (.war) as a valid suffix
      as well.

      Quoting the requirement from Ludo:
      Complete requirement would be: whenever you expect a jar or war or lib real
      file, either it is a file (working today) or it can be a directory. Names stay
      the same.

        Activity

        Hide
        Hong Zhang added a comment -

        target for 3.2

        Show
        Hong Zhang added a comment - target for 3.2
        Hide
        Tom Mueller added a comment -

        Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issues was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.

        Show
        Tom Mueller added a comment - Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issues was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.
        Hide
        Jeremy_Lv added a comment -

        Hong:
        Need this improvement be finished in the next branch of the glassfish? It seems like an interesting issue..

        Thanks

        Show
        Jeremy_Lv added a comment - Hong: Need this improvement be finished in the next branch of the glassfish? It seems like an interesting issue.. Thanks
        Hide
        Hong Zhang added a comment -

        Yeah, I meant to look into this but did not get a chance to. You can look into it if you have time..

        Show
        Hong Zhang added a comment - Yeah, I meant to look into this but did not get a chance to. You can look into it if you have time..
        Hide
        Jeremy_Lv added a comment -

        Hong:
        Can we just decompression the related application and then continue the following steps?

        Suggestion1).
        For example:
        Try to deploy the ear application as "asadmin deploy d:\test_ear", the construct of the directory will be as follows:
        test_ear
        ----A.war
        ----B.jar
        ----META-INF

        After the command has been executed, I think the directory construct of the test_ear should be changed as follows:
        test_ear
        ----A.war
        ----B.jar
        ----META-INF
        ----A_war
        ----B_jar

        Suggestion2).
        If we don't accept the first suggestion, I think we may changed the original syntax about deploying the application for directory application, Which means we should copy the test_ear under the directory of GF_HOME/domains/domain1/application. But it will affect the performance of the deployment and change the syntax about deploying the application for directory deployment.

        If we want to support this new feature, I think the first suggestion would be a good choice. Hong, What else suggestion can you suggest me?

        Thanks.

        -Jeremy

        Show
        Jeremy_Lv added a comment - Hong: Can we just decompression the related application and then continue the following steps? Suggestion1). For example: Try to deploy the ear application as "asadmin deploy d:\test_ear", the construct of the directory will be as follows: test_ear ----A.war ----B.jar ----META-INF After the command has been executed, I think the directory construct of the test_ear should be changed as follows: test_ear ----A.war ----B.jar ----META-INF ----A_war ----B_jar Suggestion2). If we don't accept the first suggestion, I think we may changed the original syntax about deploying the application for directory application, Which means we should copy the test_ear under the directory of GF_HOME/domains/domain1/application. But it will affect the performance of the deployment and change the syntax about deploying the application for directory deployment. If we want to support this new feature, I think the first suggestion would be a good choice. Hong, What else suggestion can you suggest me? Thanks. -Jeremy
        Hide
        Hong Zhang added a comment -

        No, we definitely should not copy directory. And the sub directories in the requested use case are already expanded, but just ends with ".xxx" instead of "_xxx", so we need to find in the current code where it makes assumption that the sub directory would be "_xxx" and make them accept ".xxx" also. I think the tricky part is ".jar" versus "_jar", with "_jar" we know it's a component jar (such as EJB jar) instead of a library jar. With ".jar", we might have to do extra processing to distinguish the component jars from library jars when introspecting application contents.

        Show
        Hong Zhang added a comment - No, we definitely should not copy directory. And the sub directories in the requested use case are already expanded, but just ends with ".xxx" instead of "_xxx", so we need to find in the current code where it makes assumption that the sub directory would be "_xxx" and make them accept ".xxx" also. I think the tricky part is ".jar" versus "_jar", with "_jar" we know it's a component jar (such as EJB jar) instead of a library jar. With ".jar", we might have to do extra processing to distinguish the component jars from library jars when introspecting application contents.
        Hide
        Jeremy_Lv added a comment -

        Hong:
        I have look into the ApplicationLifecycle.java and found the code of archiveHandler.expand(archive, expandedArchive, initial); is start to expand the file into _war or _jar.

        BTW: I found it is illegal to rename the directory with the suffix of .war and .jar on the windows platform. So if we want to implement this, I think it maybe the feature only support on the linux platform.

        I agree with your anxious about the situation to the .jar, As some of the situation seems complex, I think I need to consider more about it...

        Show
        Jeremy_Lv added a comment - Hong: I have look into the ApplicationLifecycle.java and found the code of archiveHandler.expand(archive, expandedArchive, initial); is start to expand the file into _war or _jar. BTW: I found it is illegal to rename the directory with the suffix of .war and .jar on the windows platform. So if we want to implement this, I think it maybe the feature only support on the linux platform. I agree with your anxious about the situation to the .jar, As some of the situation seems complex, I think I need to consider more about it...
        Hide
        Hong Zhang added a comment -

        This is for directory support, so we don't need to expand the directories again. Just the expanded sub directory name is with ".war" instead of "_war" as we currently support.

        Show
        Hong Zhang added a comment - This is for directory support, so we don't need to expand the directories again. Just the expanded sub directory name is with ".war" instead of "_war" as we currently support.

          People

          • Assignee:
            Hong Zhang
            Reporter:
            Hong Zhang
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: