glassfish
  1. glassfish
  2. GLASSFISH-18880

Fail to open OSGi console from GF admin console or URL

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 3.1.2, 4.0
    • Fix Version/s: 4.0_b62_ms6
    • Component/s: OSGi, packaging, web_container
    • Labels:
      None
    • Environment:

      Solaris 10

    • Status Whiteboard:
      Hide

      Workaround:
      ----------
      Run the following command so that the admin console does not start as part of server start up. Let it start when user explicitly accesses it:

      asadmin set configs.config.server-config.admin-service.property.adminConsoleStartup=NEVER

      Show
      Workaround: ---------- Run the following command so that the admin console does not start as part of server start up. Let it start when user explicitly accesses it: asadmin set configs.config.server-config.admin-service.property.adminConsoleStartup=NEVER

      Description

      Can not open OSGi console (i.e. HTTP 404) from GlassFish admin console or through http://masterservice:50500/osgi/system/console/bundles

      Exceptions are found in server.log when trying to open the OSGi console:

      [#|2012-07-03T11:05:16.195-0400|SEVERE|glassfish3.1.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=17;_ThreadName=Thread-2;|Failed to start Bundle Id [329] State [RESOLVED] [org.glassfish.admingui.glassfish-osgi-console-plugin(Glassfish OSGI Console Plugin):3.1.1]
      com.sun.enterprise.module.ResolveError: Failed to start Bundle Id [329] State [RESOLVED] [org.glassfish.admingui.glassfish-osgi-console-plugin(Glassfish OSGI Console Plugin):3.1.1]
      at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:177)
      at org.jvnet.hk2.osgiadapter.OSGiModuleImpl$2$1$1.loadClass(OSGiModuleImpl.java:344)
      at com.sun.hk2.component.LazyInhabitant.loadClass(LazyInhabitant.java:124)
      at com.sun.hk2.component.LazyInhabitant.fetch(LazyInhabitant.java:111)
      at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:135)
      at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
      at com.sun.enterprise.v3.server.ClassLoaderHierarchyImpl.createApplicationParentCL(ClassLoaderHierarchyImpl.java:200)
      at org.glassfish.deployment.common.DeploymentContextImpl.createClassLoader(DeploymentContextImpl.java:213)
      at org.glassfish.deployment.common.DeploymentContextImpl.createDeploymentClassLoader(DeploymentContextImpl.java:198)
      at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:346)
      at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:375)
      at com.sun.enterprise.v3.admin.adapter.InstallerThread.load(InstallerThread.java:210)
      at com.sun.enterprise.v3.admin.adapter.InstallerThread.run(InstallerThread.java:108)

      Caused by: org.osgi.framework.BundleException: Cannot start bundle org.glassfish.admingui.glassfish-osgi-console-plugin [329] because its start level is 2, which is greater than the framework's start level of 1.
      at org.apache.felix.framework.Felix.startBundle(Felix.java:1698)
      at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:922)
      at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:169)
      ... 12 more
      ---------------------------------------------------------------------------------------------------------------------------------

      Please find JVM options below:
      --------------------------------------------------------------------------------------------------------------------------------------------
      <java-config debug-options="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=50501" system-classpath="" classpath-suffix="">
      <jvm-options>-Djava.awt.headless=true</jvm-options>
      <jvm-options>-Djava.security.policy=$

      {com.sun.aas.instanceRoot}/config/server.policy</jvm-options>
      <jvm-options>-Dfelix.fileinstall.disableConfigSave=false</jvm-options>
      <jvm-options>-Dosgi.shell.telnet.maxconn=1</jvm-options>
      <jvm-options>-XX:NewRatio=2</jvm-options>
      <jvm-options>-Dfelix.fileinstall.poll=5000</jvm-options>
      <jvm-options>-Djava.endorsed.dirs=${com.sun.aas.installRoot}/modules/endorsed${path.separator}${com.sun.aas.installRoot}/lib/endorsed</jvm-options>
      <jvm-options>-Dosgi.shell.telnet.port=6666</jvm-options>
      <jvm-options>-Dcom.sun.enterprise.config.config_environment_factory_class=com.sun.enterprise.config.serverbeans.AppserverConfigEnvironmentFactory</jvm-options>
      <jvm-options>-Djava.ext.dirs=${com.sun.aas.javaRoot}/lib/ext${path.separator}${com.sun.aas.javaRoot}/jre/lib/ext${path.separator}${com.sun.aas.instanceRoot}

      /lib/ext</jvm-options>
      <jvm-options>Dgosh.args=-nointeractive</jvm-options>
      <jvm-options>-Djavax.management.builder.initial=com.sun.enterprise.v3.admin.AppServerMBeanServerBuilder</jvm-options>
      <jvm-options>-Dcom.sun.enterprise.security.httpsOutboundKeyAlias=s1as</jvm-options>
      <jvm-options>-XX:MaxPermSize=192m</jvm-options>
      <jvm-options>-XX:+UnlockDiagnosticVMOptions</jvm-options>
      <jvm-options>-Dfelix.fileinstall.bundles.startTransient=true</jvm-options>
      <jvm-options>-Dfelix.fileinstall.dir=$

      {com.sun.aas.installRoot}

      /modules/autostart/</jvm-options>
      <jvm-options>-Dfelix.fileinstall.bundles.new.start=true</jvm-options>
      <jvm-options>-Djava.security.auth.login.config=$

      {com.sun.aas.instanceRoot}/config/login.conf</jvm-options>
      <jvm-options>-Dosgi.shell.telnet.ip=127.0.0.1</jvm-options>
      <jvm-options>-Dfelix.fileinstall.log.level=2</jvm-options>
      <jvm-options>-Dorg.glassfish.additionalOSGiBundlesToStart=org.apache.felix.shell,org.apache.felix.gogo.runtime,org.apache.felix.gogo.shell,org.apache.felix.gogo.command,org.apache.felix.fileinstall,org.apache.felix.shell.remote</jvm-options>
      <jvm-options>-client</jvm-options>
      <jvm-options>-Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot}

      /config/keystore.jks</jvm-options>
      <jvm-options>-Xmx512m</jvm-options>
      <jvm-options>-Djdbc.drivers=org.apache.derby.jdbc.ClientDriver</jvm-options>
      <jvm-options>-Djavax.net.ssl.trustStore=$

      {com.sun.aas.instanceRoot}

      /config/cacerts.jks</jvm-options>
      <jvm-options>-DANTLR_USE_DIRECT_CLASS_LOADING=true</jvm-options>
      </java-config>
      ---------------------------------------------------------------------------------------------------------------------------------

      1. DirContextURLStreamHandlerService.java.patch
        1 kB
        Sanjeeb Sahoo
      2. domain_t.xml
        37 kB
        LeoInside
      3. GLASSFISH-18880.patch
        17 kB
        Sanjeeb Sahoo
      4. server_t.log
        837 kB
        LeoInside

        Issue Links

          Activity

          Hide
          Sanjeeb Sahoo added a comment - - edited

          I have fixed the issue on trunk in svn rev #56537 and #56547. You need both the commits, because the first one caused a regression in embedded ejb container tests where OSGi classes were not available. See check-in comments for more details.

          I have asked our build team to create a 3.1.x branch. When that's available, I will also fix it there.

          I will also ask our sustaining team to include this fix in a future patch release.

          Show
          Sanjeeb Sahoo added a comment - - edited I have fixed the issue on trunk in svn rev #56537 and #56547. You need both the commits, because the first one caused a regression in embedded ejb container tests where OSGi classes were not available. See check-in comments for more details. I have asked our build team to create a 3.1.x branch. When that's available, I will also fix it there. I will also ask our sustaining team to include this fix in a future patch release.
          Hide
          TangYong added a comment -

          Hi sahoo,

          I have used the new workaround and tried more than 10 times, the issue including "Unknown protocol:" all did not happen on 3.1.2.2 any longer. The workaround for 3.1.2.x looks very fine!

          Thanks
          Tang

          Show
          TangYong added a comment - Hi sahoo, I have used the new workaround and tried more than 10 times, the issue including "Unknown protocol:" all did not happen on 3.1.2.2 any longer. The workaround for 3.1.2.x looks very fine! Thanks Tang
          Hide
          Sanjeeb Sahoo added a comment -

          After further testing, we discovered that we needed it to be an init service rather than a startup service. So, we fixed it in the following check-in:
          Sending appserver/web/web-naming/pom.xml
          Sending appserver/web/web-naming/src/main/java/org/apache/naming/resources/WebNamingStartup.java
          Transmitting file data ..
          Committed revision 56875.

          Show
          Sanjeeb Sahoo added a comment - After further testing, we discovered that we needed it to be an init service rather than a startup service. So, we fixed it in the following check-in: Sending appserver/web/web-naming/pom.xml Sending appserver/web/web-naming/src/main/java/org/apache/naming/resources/WebNamingStartup.java Transmitting file data .. Committed revision 56875.
          Hide
          Sanjeeb Sahoo added a comment -

          There were multiple check-ins, but the last one was part of b62 and now marking the issue as fixed. Sustaining is back porting it to 3.1.x release.

          Show
          Sanjeeb Sahoo added a comment - There were multiple check-ins, but the last one was part of b62 and now marking the issue as fixed. Sustaining is back porting it to 3.1.x release.
          Hide
          mats.nordgren added a comment -

          In case anyone finds this page in relation to the Unknown protocol: JNDI issue, I'll add my experiences:

          We were trying to find the reason for this error in a production test environment where the admin console refused to load on startup. To make a long story short - the root cause was the /tmp directory having been set to read-only, which caused the OSGI loader spin wildly trying to create a temporary directory and failing. Apparently there is room for improvement in the error handling of OSGI, but once we realized what was happening and set the rights to the /tmp directory things returned to normal.

          Show
          mats.nordgren added a comment - In case anyone finds this page in relation to the Unknown protocol: JNDI issue, I'll add my experiences: We were trying to find the reason for this error in a production test environment where the admin console refused to load on startup. To make a long story short - the root cause was the /tmp directory having been set to read-only, which caused the OSGI loader spin wildly trying to create a temporary directory and failing. Apparently there is room for improvement in the error handling of OSGI, but once we realized what was happening and set the rights to the /tmp directory things returned to normal.

            People

            • Assignee:
              Sanjeeb Sahoo
              Reporter:
              LeoInside
            • Votes:
              4 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: