glassfish
  1. glassfish
  2. GLASSFISH-19216

java.net.MalformedURLException: Unknown protocol: jndi from JSF ConfigManager

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Blocker Blocker
    • Resolution: Duplicate
    • Affects Version/s: 4.0_b60, 4.0_b61
    • Fix Version/s: None
    • Component/s: OSGi
    • Labels:
      None
    • Environment:

      Red Hat Enterprise Linux 6 (64 bits)

      Description

      We are installing Glassfish 3 in Red Hat Enterprise Linux 6. All seems ok, but after deploy jdbc connection pools (over 500) we realized that the Administration Console doesn't run and got the following error in server.log (we don't have deployed any application yet, only jdbc connection pools):

      [#|2012-10-23T04:15:42.163-0400|INFO|glassfish3.1.2|javax.enterprise.resource.webcontainer.jsf.config|_ThreadID=43;_ThreadName=Thread-2;|Initializing Mojarra 2.1.6 (SNAPSHOT 20111206) for context ''|#]

      [#|2012-10-23T04:15:43.239-0400|SEVERE|glassfish3.1.2|javax.enterprise.resource.webcontainer.jsf.config|_ThreadID=43;_ThreadName=Thread-2;|Critical error during deployment:
      com.sun.faces.config.ConfigurationException: java.util.concurrent.ExecutionException: java.net.MalformedURLException: Unknown protocol: jndi
      at com.sun.faces.config.ConfigManager.getConfigDocuments(ConfigManager.java:672)
      at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:322)
      at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:225)
      at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:4750)
      at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:550)
      at org.apache.catalina.core.StandardContext.start(StandardContext.java:5366)
      at com.sun.enterprise.web.WebModule.start(WebModule.java:498)
      at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:917)
      at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:901)
      at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:733)
      at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2019)
      at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1669)
      at com.sun.enterprise.web.WebApplication.start(WebApplication.java:109)
      at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
      at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
      at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:301)
      at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
      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: java.util.concurrent.ExecutionException: java.net.MalformedURLException: Unknown protocol: jndi
      at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252)
      at java.util.concurrent.FutureTask.get(FutureTask.java:111)
      at com.sun.faces.config.ConfigManager.getConfigDocuments(ConfigManager.java:670)
      ... 19 more
      Caused by: java.net.MalformedURLException: Unknown protocol: jndi
      at java.net.URL.<init>(URL.java:617)
      at java.net.URL.<init>(URL.java:480)
      at java.net.URL.<init>(URL.java:429)
      at java.net.URI.toURL(URI.java:1096)
      at com.sun.faces.config.ConfigManager$ParseTask.call(ConfigManager.java:920)
      at com.sun.faces.config.ConfigManager$ParseTask.call(ConfigManager.java:865)
      at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
      at java.util.concurrent.FutureTask.run(FutureTask.java:166)
      at com.sun.faces.config.ConfigManager.getConfigDocuments(ConfigManager.java:656)
      ... 19 more
      Caused by: java.lang.IllegalStateException: Unknown protocol: jndi
      at org.apache.felix.framework.URLHandlersStreamHandlerProxy.parseURL(URLHandlersStreamHandlerProxy.java:372)
      at java.net.URL.<init>(URL.java:612)
      ... 27 more

      #]

      [#|2012-10-23T04:15:43.254-0400|SEVERE|glassfish3.1.2|org.apache.catalina.core.StandardContext|_ThreadID=43;_ThreadName=Thread-2;|PWC1306: Startup of context failed due to previous errors|#]

      The same error occurs in RHEL 5 and Solaris 10.

      You can reproduce the error following these steps:
      1.- Install RHEL 6.3 (64 bits). Basic Server Installation
      2.- Install java-1.6.0-sun-devel and define JAVA_HOME in /etc/profile. Fails with 64 bits and 32 bits. Also fails with java-1.7.0-oracle-devel.
      3.- Disable SELinux and iptables
      4.- Create a test account and install Glassfish 3.1.2.2 (build 5) with this user (typical installation). The installer we've use is glassfish-3.1.2.2-unix-ml.sh

      5.- asadmin start-domain <- We can access Administration Console
      6.- asadmin enable-secure-admin -port 4848; asadmin stopt-domain; asadmin start-domain < We can acces Administration Console
      7.- Create jdbc pool with this script:

      for i in `seq -f "%03g" 1 500`
      do
      echo $i
      asadmin create-jdbc-connection-pool --datasourceclassname oracle.jdbc.pool.OracleConnectionPoolDataSource --restype javax.sql.ConnectionPoolDataSource --property user=user$i:password=password_$i:url=jdbc\\:oracle\\:thin\\:@//desarrollo.test
      :1521/test01 pool$i
      asadmin create-jdbc-resource --target domain --connectionpoolid pool$i jdbc/pool$i
      asadmin create-resource-ref --target server jdbc/pool$i
      done

      8.- Access to Administration Console -> OK
      9.- asadmin stop-domain; asadmin start-domain -> We can't access Administration Console and get the error.

      If you don't try to access Administration Console in step 5 and 8, after step 9 you still can access Administration Console.
      asadmin stop-domain; asadmin start-domain again, try to access Administration Console and then the error appears.

      Althought the Administration Console doesn't run the asadmin utility runs perfect.

      Does anybody have this issue? How can I fix this?

      1. domain.xml
        291 kB
        tesgoran
      2. ds.sh
        0.4 kB
        tesgoran
      3. patch.txt
        1 kB
        Sanjeeb Sahoo
      4. server_windowsxp3.1.2.log
        22 kB
        TangYong
      5. server.log
        20 kB
        tesgoran

        Issue Links

          Activity

          Hide
          Sanjeeb Sahoo added a comment -

          Scott is using a build which has the fix for GLASSFISH-18880, so I have very good feeling that the fix for 18880 actually caused a regression on 4.0 build. So, let's wait for Scott to verify the patch I have attached.

          It is understandable that the problem appears on 3.1.2, because in 3.1.2.x, adminconsole can start as part of server startup and that exposes the race condition. In 4.0, adminconsole does not yet start as part of the server start up, so you have to deploy a JSF app as Scott is deploying to reproduce the problem.

          Sahoo

          Show
          Sanjeeb Sahoo added a comment - Scott is using a build which has the fix for GLASSFISH-18880 , so I have very good feeling that the fix for 18880 actually caused a regression on 4.0 build. So, let's wait for Scott to verify the patch I have attached. It is understandable that the problem appears on 3.1.2, because in 3.1.2.x, adminconsole can start as part of server startup and that exposes the race condition. In 4.0, adminconsole does not yet start as part of the server start up, so you have to deploy a JSF app as Scott is deploying to reproduce the problem. Sahoo
          Hide
          Scott Oaks added a comment -

          Sorry; I thought I included how to reproduce, which is as simple as deploying the sample scrumtoys JSF app from NetBeans and then restarting the server.

          I tried Sahoo's patch and it solves the issue.

          Show
          Scott Oaks added a comment - Sorry; I thought I included how to reproduce, which is as simple as deploying the sample scrumtoys JSF app from NetBeans and then restarting the server. I tried Sahoo's patch and it solves the issue.
          Hide
          Sanjeeb Sahoo added a comment -
          Show
          Sanjeeb Sahoo added a comment - See GLASSFISH-18880 .
          Hide
          tesgoran added a comment -

          I can confirm that executing

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

          in GF3.1.2, as indicated in the workaround of GLASSFISH-18880, I don't get the jndi error and the admin console runs well.

          Thank you

          Show
          tesgoran added a comment - I can confirm that executing asadmin set configs.config.server-config.admin-service.property.adminConsoleStartup=NEVER in GF3.1.2, as indicated in the workaround of GLASSFISH-18880 , I don't get the jndi error and the admin console runs well. Thank you
          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:
              tesgoran
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: