glassfish
  1. glassfish
  2. GLASSFISH-18591

Odd deployment message in 3.1.2: Loading application [atmosphere-jquery-pubsub] at [/atmosphere-jquery-pubsub.war6673242861965871810]

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 3.1.2
    • Fix Version/s: None
    • Component/s: deployment
    • Labels:
      None

      Description

      From the reporter:
      -----------------------------------------

      java -jar glassfish.jar atmosphere-jquery-pubsub.jar

      produces

      https://gist.github.com/2291932

      (the .warJUNK must not be there That wasn't occurring with 3.1.2 b19 (last time I've checked IIRC).

        Activity

        Hide
        jfarcand added a comment -

        The erro will occurs only if the path to the war file is using symlinks. Direct path works as expected.

        Show
        jfarcand added a comment - The erro will occurs only if the path to the war file is using symlinks. Direct path works as expected.
        Hide
        Shing Wai Chan added a comment -

        Atmosphere-atmosphere-693f03d and GlassFish 3.1.2 FCS are used in the following.
        The following command works for me:
        java -jar glassfish.jar /foo/atmosphere-jquery-pubsub.war
        where
        ls -l /foo
        lrwxr-xr-x 1 root wheel 83 Apr 4 11:15 /foo -> /export/tools/atmosphere/Atmosphere-atmosphere-693f03d/samples/jquery-pubsub/target

        I confirm from Jean Francois that this is the scenario.
        I do not see the error described in the issue.

        Show
        Shing Wai Chan added a comment - Atmosphere-atmosphere-693f03d and GlassFish 3.1.2 FCS are used in the following. The following command works for me: java -jar glassfish.jar /foo/atmosphere-jquery-pubsub.war where ls -l /foo lrwxr-xr-x 1 root wheel 83 Apr 4 11:15 /foo -> /export/tools/atmosphere/Atmosphere-atmosphere-693f03d/samples/jquery-pubsub/target I confirm from Jean Francois that this is the scenario. I do not see the error described in the issue.
        Hide
        Ryan Lubke added a comment -

        JFA reports his platform as MacOS Lion with JDK 6.

        I can't reproduce this on Snow Leopard, but I can reproduce the issue on Lion.

        Show
        Ryan Lubke added a comment - JFA reports his platform as MacOS Lion with JDK 6. I can't reproduce this on Snow Leopard, but I can reproduce the issue on Lion.
        Hide
        Ryan Lubke added a comment -

        Before the deployment message occurs, this is seen in the log:

        [#|2012-04-05T10:01:54.653-0700|INFO|oracle-glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=10;_ThreadName=main;|CORE10013: Source is not a directory, using temporary location /var/folders/82/bn75f0wj48q32qsv296h0qdc0000gp/T/test.war3311041912273045960|#]

        Then later:

        [#|2012-04-05T10:02:09.071-0700|INFO|oracle-glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=10;_ThreadName=main;|WEB0671: Loading application [test] at [/test.war3311041912273045960]|#]

        Show
        Ryan Lubke added a comment - Before the deployment message occurs, this is seen in the log: [#|2012-04-05T10:01:54.653-0700|INFO|oracle-glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=10;_ThreadName=main;|CORE10013: Source is not a directory, using temporary location /var/folders/82/bn75f0wj48q32qsv296h0qdc0000gp/T/test.war3311041912273045960|#] Then later: [#|2012-04-05T10:02:09.071-0700|INFO|oracle-glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=10;_ThreadName=main;|WEB0671: Loading application [test] at [/test.war3311041912273045960] |#]
        Hide
        Shing Wai Chan added a comment - - edited

        I am also using MacOS Lion with JDK 6. I have talked to Jean Francois and followed steps suggested by him. I do not see the issue.
        Is it happen all the time or occasionally?

        It would be good if you can provide precise steps on how to reproduce the issue.

        The above log message is coming from ApplicationLoaderService#postConstruct as follows:

                                if (tmpDir.mkdirs()) {
                                    ArchiveHandler handler = deployment.getArchiveHandler(sourceArchive);
                                    final String appName = handler.getDefaultApplicationName(sourceArchive);
                                    DeploymentContextImpl dummyContext = new DeploymentContextImpl(report, logger, sourceArchive, parameters, env);
                                    handler.expand(sourceArchive, archiveFactory.get().createArchive(tmpDir), dummyContext);
                                    sourceArchive = 
                                        archiveFactory.get().openArchive(tmpDir);
                                    logger.log(Level.INFO, "source.not.directory", new Object[] {tmpDir.getAbsolutePath()});
                                    parameters.name = appName;
                                }
        

        Per discussion with Hong, this is a normal code path for this type of deployment.

        Show
        Shing Wai Chan added a comment - - edited I am also using MacOS Lion with JDK 6. I have talked to Jean Francois and followed steps suggested by him. I do not see the issue. Is it happen all the time or occasionally? It would be good if you can provide precise steps on how to reproduce the issue. The above log message is coming from ApplicationLoaderService#postConstruct as follows: if (tmpDir.mkdirs()) { ArchiveHandler handler = deployment.getArchiveHandler(sourceArchive); final String appName = handler.getDefaultApplicationName(sourceArchive); DeploymentContextImpl dummyContext = new DeploymentContextImpl(report, logger, sourceArchive, parameters, env); handler.expand(sourceArchive, archiveFactory.get().createArchive(tmpDir), dummyContext); sourceArchive = archiveFactory.get().openArchive(tmpDir); logger.log(Level.INFO, "source.not.directory" , new Object [] {tmpDir.getAbsolutePath()}); parameters.name = appName; } Per discussion with Hong, this is a normal code path for this type of deployment.
        Hide
        Shing Wai Chan added a comment -

        I have checked that I also got log messages CORE10013 and WEB0671. But the application is deployed and loaded correctly.

        Show
        Shing Wai Chan added a comment - I have checked that I also got log messages CORE10013 and WEB0671. But the application is deployed and loaded correctly.
        Hide
        Ryan Lubke added a comment -

        Create a symlink to glassfish.jar. Create a symlink to the test war. Invoke java -jar <symlinked glassfish.jar reference> <symlinked war reference>

        Show
        Ryan Lubke added a comment - Create a symlink to glassfish.jar. Create a symlink to the test war. Invoke java -jar <symlinked glassfish.jar reference> <symlinked war reference>
        Hide
        Hong Zhang added a comment -

        Shingwai: I think maybe the deployment was also successful for Jeanfrancois, but just the context root is not the one as expected.

        This behavior change may be related to the fix for this issue:
        http://java.net/jira/browse/GLASSFISH-17021

        where we changed the algorithm of how to compute default context root to be backward compatible with v2.

        For this java -jar glassfish.jar foo.war code path, as the war is expanded to a temporary directory, the default context root (which is archive name minus suffix) could result in a strange name. I can look into it to see what we can do about it.

        Note: This java -jar glassfish.jar is never an officially supported code path. Please use context-root element inside sun-web.xml/glassfish-web.xml to ensure a predictable context root.

        Show
        Hong Zhang added a comment - Shingwai: I think maybe the deployment was also successful for Jeanfrancois, but just the context root is not the one as expected. This behavior change may be related to the fix for this issue: http://java.net/jira/browse/GLASSFISH-17021 where we changed the algorithm of how to compute default context root to be backward compatible with v2. For this java -jar glassfish.jar foo.war code path, as the war is expanded to a temporary directory, the default context root (which is archive name minus suffix) could result in a strange name. I can look into it to see what we can do about it. Note: This java -jar glassfish.jar is never an officially supported code path. Please use context-root element inside sun-web.xml/glassfish-web.xml to ensure a predictable context root.
        Hide
        Hong Zhang added a comment -

        As I mentioned in my previous comments, we made this change to be backward compatible with v2 context root behavior. And I did not see a simple fix for the java -jar code path (which is not officially supported) to restore the previous behavior, so please use context-root element inside sun-web.xml/glassfish-web.xml to ensure a predictable context root.

        Show
        Hong Zhang added a comment - As I mentioned in my previous comments, we made this change to be backward compatible with v2 context root behavior. And I did not see a simple fix for the java -jar code path (which is not officially supported) to restore the previous behavior, so please use context-root element inside sun-web.xml/glassfish-web.xml to ensure a predictable context root.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: