glassfish
  1. glassfish
  2. GLASSFISH-12755

NameNotFoundException: @Resource(name="jdbc/__default") in a cluster

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 3.1
    • Fix Version/s: 3.1
    • Component/s: naming
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

      Description

      @Resource(name="jdbc/__default") has NameNotFoundException
      in a cluster env on v3.1 build 11 (glassfish-3.1-b11.zip)
      The same tests passed on v3.1 build 10.

      To reproduce the issue:
      Set up sqe test env based on
      http://agni-1.sfbay.sun.com/JSPWiki/Wiki.jsp?page=SQECoreFULL
      use "ant -f bootstrap.xml co-jsf" to get test source.

      1) start derby and a cluster of 2 local instances
      % setenv ENABLE_REPLICATION true
      % cd $SPS_HOME
      % ant startDerby
      % ant setup-cluster-profile

      2) reproduce the jsf failure
      % cd $SPS_HOME/pe/jsf/jsf1_2_injections
      % ant ee build deploy
      access url
      http://localhost:18080/jsfinjection-testapp/jsfHello.jsf
      and see error

      root cause
      javax.naming.NamingException: Lookup failed for 'java:comp/env/jdbc/__default'
      in SerialContext
      [Root exception is javax.naming.NamingException: Lookup failed for
      'jdbc/__default' in SerialContext
      [Root exception is javax.naming.NameNotFoundException: __default not found]]

      The related code section is in TestBean.java
      package test;
      import javax.annotation.*;
      import javax.sql.DataSource;

      public class TestBean {
      @Resource(name="jdbc/__default")
      private DataSource ds;

      For tomcat failure,
      use "ant -f bootstrap.xml co-tomcat" to get test source.
      % cd $SPS_HOME/pe/tomcat/servlet/product_test/servlet2_5/annotations
      % ant ee bat
      See similar error:
      javax.naming.NamingException: Lookup failed for
      'java:comp/env/myfilter.MyFilter/ds1'
      in SerialContext [Root exception is javax.naming.NamingException: Lookup failed
      for 'jdbc/__default' in SerialContext
      [Root exception is javax.naming.NameNotFoundException: __default

        Activity

        Hide
        chaoslayer added a comment -

        Hi *,

        just wanted to say that this issue also affects me on a standalone instance
        (default 'domain1') when deploying OSGi bundled applications the first time
        (only during server startup) in glassfish 3.1 b14 (although I observed this
        since b06 in some cases).

        What I have is a web application bundle that looks up a datasource via plain old
        JNDI. The appropriate resource ref as mentioned earlier here is available:

        <servers>
        <server name="server" config-ref="server-config">
        <application-ref ref="_admingui" virtual-servers="_asadmin" />
        <resource-ref ref="jdbc/__TimerPool" />
        <resource-ref ref="jdbc/__default" />
        <resource-ref ref="jdbc/apache_ode" />
        <resource-ref ref="connectionFactory/MessagingConnectionFactory" />
        <resource-ref ref="queue/MessagingQueue" />
        <resource-ref ref="session/MessagingSession" />
        </server>
        </servers>

        But even with that I get:

        ...
        Caused by: javax.naming.NamingException: Lookup failed for 'jdbc/apache_ode' in
        SerialContext [Root exception is javax.naming.NameNotFoundException: jdbc]
        at
        com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:456)
        at javax.naming.InitialContext.lookup(InitialContext.java:392)
        at javax.naming.InitialContext.lookup(InitialContext.java:392)
        at org.apache.ode.il.dbutil.Database.lookupInJndi(Database.java:261)
        at org.apache.ode.il.dbutil.Database.initExternalDb(Database.java:161)
        ... 47 more
        Caused by: javax.naming.NameNotFoundException: jdbc
        at
        com.sun.enterprise.naming.impl.TransientContext.resolveContext(TransientContext.java:266)
        at
        com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:185)
        at
        com.sun.enterprise.naming.impl.SerialContextProviderImpl.lookup(SerialContextProviderImpl.java:72)
        at
        com.sun.enterprise.naming.impl.LocalSerialContextProviderImpl.lookup(LocalSerialContextProviderImpl.java:115)
        at
        com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:444)
        ... 51 more

        When I touch the archive deployed in .../autodeploy/bundles/ to trigger an
        update all things are fine and the datasource can be used. This behavior does
        only happen for me at rather fast machines (at least on a 4-core AMD64). Inside
        a much slower VM with only 2 cores and with limited memory this issue does not
        happen.

        Thanx for any hints.

        Show
        chaoslayer added a comment - Hi *, just wanted to say that this issue also affects me on a standalone instance (default 'domain1') when deploying OSGi bundled applications the first time (only during server startup) in glassfish 3.1 b14 (although I observed this since b06 in some cases). What I have is a web application bundle that looks up a datasource via plain old JNDI. The appropriate resource ref as mentioned earlier here is available: <servers> <server name="server" config-ref="server-config"> <application-ref ref="_ admingui" virtual-servers=" _asadmin" /> <resource-ref ref="jdbc/__TimerPool" /> <resource-ref ref="jdbc/__default" /> <resource-ref ref="jdbc/apache_ode" /> <resource-ref ref="connectionFactory/MessagingConnectionFactory" /> <resource-ref ref="queue/MessagingQueue" /> <resource-ref ref="session/MessagingSession" /> </server> </servers> But even with that I get: ... Caused by: javax.naming.NamingException: Lookup failed for 'jdbc/apache_ode' in SerialContext [Root exception is javax.naming.NameNotFoundException: jdbc] at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:456) at javax.naming.InitialContext.lookup(InitialContext.java:392) at javax.naming.InitialContext.lookup(InitialContext.java:392) at org.apache.ode.il.dbutil.Database.lookupInJndi(Database.java:261) at org.apache.ode.il.dbutil.Database.initExternalDb(Database.java:161) ... 47 more Caused by: javax.naming.NameNotFoundException: jdbc at com.sun.enterprise.naming.impl.TransientContext.resolveContext(TransientContext.java:266) at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:185) at com.sun.enterprise.naming.impl.SerialContextProviderImpl.lookup(SerialContextProviderImpl.java:72) at com.sun.enterprise.naming.impl.LocalSerialContextProviderImpl.lookup(LocalSerialContextProviderImpl.java:115) at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:444) ... 51 more When I touch the archive deployed in .../autodeploy/bundles/ to trigger an update all things are fine and the datasource can be used. This behavior does only happen for me at rather fast machines (at least on a 4-core AMD64). Inside a much slower VM with only 2 cores and with limited memory this issue does not happen. Thanx for any hints.
        Hide
        chaoslayer added a comment -

        Note to my previous comment:

        I have several other OSGi bundles that use JPA for the persistence and get
        loaded much earlier don't have such problems, e.g.:

        [#|2010-08-10T20:15:33.920+0200|CONFIG|glassfish3.1|org.eclipse.persistence.session.file:/tmp/osgiapp1746171678239530334/_UserServicePU.connection|_ThreadID=16;_ThreadName=Thread-1;|connecting(DatabaseLogin(
        platform=>DatabasePlatform
        user name=> ""
        connector=>JNDIConnector datasource name=>null
        ))|#]

        [#|2010-08-10T20:15:33.928+0200|CONFIG|glassfish3.1|org.eclipse.persistence.session.file:/tmp/osgiapp1746171678239530334/_UserServicePU.connection|_ThreadID=16;_ThreadName=Thread-1;|Connected:
        jdbc:postgresql://localhost:5432/vdc?loginTimeout=0&socketTimeout=0&prepareThreshold=5&unknownLength=2147483647&tcpkeepalive=false
        User: glassfish
        Database: PostgreSQL Version: 8.4.4
        Driver: PostgreSQL Native Driver Version: PostgreSQL 8.4 JDBC3 (build 701)|#]

        [#|2010-08-10T20:15:33.928+0200|CONFIG|glassfish3.1|org.eclipse.persistence.session.file:/tmp/osgiapp1746171678239530334/_UserServicePU.connection|_ThreadID=16;_ThreadName=Thread-1;|connecting(DatabaseLogin(
        platform=>PostgreSQLPlatform
        user name=> ""
        connector=>JNDIConnector datasource name=>null
        ))|#]

        [#|2010-08-10T20:15:33.935+0200|CONFIG|glassfish3.1|org.eclipse.persistence.session.file:/tmp/osgiapp1746171678239530334/_UserServicePU.connection|_ThreadID=16;_ThreadName=Thread-1;|Connected:
        jdbc:postgresql://localhost:5432/vdc?loginTimeout=0&socketTimeout=0&prepareThreshold=5&unknownLength=2147483647&tcpkeepalive=false
        User: glassfish
        Database: PostgreSQL Version: 8.4.4
        Driver: PostgreSQL Native Driver Version: PostgreSQL 8.4 JDBC3 (build 701)|#]

        [#|2010-08-10T20:15:33.939+0200|INFO|glassfish3.1|org.eclipse.persistence.session.file:/tmp/osgiapp1746171678239530334/_UserServicePU|_ThreadID=16;_ThreadName=Thread-1;|file:/tmp/osgiapp1746171678239530334/_UserServicePU
        login successful|#]

        ...although this wonders me a bit:

        connecting(DatabaseLogin(
        platform=>PostgreSQLPlatform
        user name=> ""
        connector=>JNDIConnector datasource name=>null
        ))

        datasource name is NULL?!

        Show
        chaoslayer added a comment - Note to my previous comment: I have several other OSGi bundles that use JPA for the persistence and get loaded much earlier don't have such problems, e.g.: [#|2010-08-10T20:15:33.920+0200|CONFIG|glassfish3.1|org.eclipse.persistence.session. file:/tmp/osgiapp1746171678239530334/_UserServicePU.connection |_ThreadID=16;_ThreadName=Thread-1;|connecting(DatabaseLogin( platform=>DatabasePlatform user name=> "" connector=>JNDIConnector datasource name=>null ))|#] [#|2010-08-10T20:15:33.928+0200|CONFIG|glassfish3.1|org.eclipse.persistence.session. file:/tmp/osgiapp1746171678239530334/_UserServicePU.connection |_ThreadID=16;_ThreadName=Thread-1;|Connected: jdbc:postgresql://localhost:5432/vdc?loginTimeout=0&socketTimeout=0&prepareThreshold=5&unknownLength=2147483647&tcpkeepalive=false User: glassfish Database: PostgreSQL Version: 8.4.4 Driver: PostgreSQL Native Driver Version: PostgreSQL 8.4 JDBC3 (build 701)|#] [#|2010-08-10T20:15:33.928+0200|CONFIG|glassfish3.1|org.eclipse.persistence.session. file:/tmp/osgiapp1746171678239530334/_UserServicePU.connection |_ThreadID=16;_ThreadName=Thread-1;|connecting(DatabaseLogin( platform=>PostgreSQLPlatform user name=> "" connector=>JNDIConnector datasource name=>null ))|#] [#|2010-08-10T20:15:33.935+0200|CONFIG|glassfish3.1|org.eclipse.persistence.session. file:/tmp/osgiapp1746171678239530334/_UserServicePU.connection |_ThreadID=16;_ThreadName=Thread-1;|Connected: jdbc:postgresql://localhost:5432/vdc?loginTimeout=0&socketTimeout=0&prepareThreshold=5&unknownLength=2147483647&tcpkeepalive=false User: glassfish Database: PostgreSQL Version: 8.4.4 Driver: PostgreSQL Native Driver Version: PostgreSQL 8.4 JDBC3 (build 701)|#] [#|2010-08-10T20:15:33.939+0200|INFO|glassfish3.1|org.eclipse.persistence.session. file:/tmp/osgiapp1746171678239530334/_UserServicePU |_ThreadID=16;_ThreadName=Thread-1;|file:/tmp/osgiapp1746171678239530334/_UserServicePU login successful|#] ...although this wonders me a bit: connecting(DatabaseLogin( platform=>PostgreSQLPlatform user name=> "" connector=>JNDIConnector datasource name=>null )) datasource name is NULL?!
        Hide
        chaoslayer added a comment -

        Well, I found a workaround for this issue in my case.

        I just included a dummy persistence.xml that referenced the problematic
        jdbc-resource and now the app deploys fine.

        Show
        chaoslayer added a comment - Well, I found a workaround for this issue in my case. I just included a dummy persistence.xml that referenced the problematic jdbc-resource and now the app deploys fine.
        Hide
        Cheng Fang added a comment -

        update it as fixed since the original sqe tests are now passing.

        Show
        Cheng Fang added a comment - update it as fixed since the original sqe tests are now passing.
        Hide
        sherryshen added a comment -

        verified on b23p.

        Show
        sherryshen added a comment - verified on b23p.

          People

          • Assignee:
            Cheng Fang
            Reporter:
            sherryshen
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: