Jetty
  1. Jetty
  2. JETTY-273

JNDI does not check for env entry and if exists throws NameNotFoundException

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 6.1.2rc2, 6.1.2
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      2

      Description

      Currently, if using JPA (OpenJPA or Hibernate), one may create a full JNDI name in a persitence.xml such as:

      java:comp/env/jdbc/myDS

      WThis would be used in Jetty with the followng configuration:

      <New id="myds" class="org.mortbay.jetty.plus.naming.Resource">
      <Arg>java:comp/env/jdbc/myDS</Arg>
      <Arg>
      <New class="org.apache.commons.dbcp.BasicDataSource">
      <Set name="DriverClassName">org.hsqldb.jdbcDriver</Set>
      <Set name="Url">jdbc:hsqldb:file:<SystemProperty name="dbtest"/></Set>
      <Set name="Username">sa</Set>
      <Set name="Password"></Set>
      </New>
      </Arg>
      </New>

      The following error occurs:

      javax.naming.NameAlreadyBoundException: env
      at org.mortbay.naming.NamingContext.createSubcontext(NamingContext.java:453)
      at org.mortbay.naming.NamingContext.createSubcontext(NamingContext.java:517)
      at org.mortbay.jetty.plus.webapp.EnvConfiguration.createEnvContext(EnvConfiguration.java:52)
      at org.mortbay.jetty.plus.webapp.EnvConfiguration.configureWebApp(EnvConfiguration.java:103)
      at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1171)
      ...

      The error appears that on line 52, of the EnvConfiguration, the "env" is being created without checking to see if it has already been bound (as would occur in a JPA application).

      I have attached a patch that checks for this condition fixes this.

      1. JETTY-273-jgenender.patch
        0.9 kB
        jgenender jgenender
      2. test.src.tgz
        6 kB
        jgenender jgenender

        Activity

        jgenender jgenender made changes -
        Field Original Value New Value
        Attachment JETTY-273-jgenender.patch [ 26349 ]
        Hide
        Jan Bartel added a comment -

        Hi Jeff,

        I can't reproduce the problem in my test setup. I'm using a relative name in jetty.xml and a fully qualified one in a ContextListener (as does Spring/Hibernate apparently) and it is all working.

        On the off-chance that something has changed since the last snapshot, I've pushed a new one.

        If you can try with the new snapshot and there is still an issue, I think I'll need an example webapp before I can get any further with this.

        cheers,
        Jan

        Show
        Jan Bartel added a comment - Hi Jeff, I can't reproduce the problem in my test setup. I'm using a relative name in jetty.xml and a fully qualified one in a ContextListener (as does Spring/Hibernate apparently) and it is all working. On the off-chance that something has changed since the last snapshot, I've pushed a new one. If you can try with the new snapshot and there is still an issue, I think I'll need an example webapp before I can get any further with this. cheers, Jan
        Hide
        jgenender jgenender added a comment -

        I have a test case to attach.

        All source code available for you. Extract it then run 'mvn install' in the root dircetory. After its all built, go into the web dirextory and run 'mvn jetty:run'. You will notice the following exception:

        Caused by: javax.naming.NameNotFoundException; remaining name 'jdbc/myDS'
        at org.mortbay.naming.NamingContext.lookup(NamingContext.java:634)
        at org.mortbay.naming.NamingContext.lookup(NamingContext.java:665)
        at org.mortbay.naming.NamingContext.lookup(NamingContext.java:665)
        at org.mortbay.naming.NamingContext.lookup(NamingContext.java:680)
        at org.mortbay.naming.java.javaRootURLContext.lookup(javaRootURLContext.java:112)
        at javax.naming.InitialContext.lookup(InitialContext.java:351)
        at org.hibernate.connection.DatasourceConnectionProvider.configure(DatasourceConnectionProvider.java:52)

        Then change web/src/test/jetty/hsql/jetty.xml file to use a fully qualified name on line 23 to

        javax.naming.NameAlreadyBoundException: env
        at org.mortbay.naming.NamingContext.createSubcontext(NamingContext.java:453)
        at org.mortbay.naming.NamingContext.createSubcontext(NamingContext.java:517)
        at org.mortbay.jetty.plus.webapp.EnvConfiguration.createEnvContext(EnvConfiguration.java:52)
        at org.mortbay.jetty.plus.webapp.EnvConfiguration.configureWebApp(EnvConfiguration.java:103)
        at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1209)

        This seems to me that the Spring JNDI is getting created before Jetty gets it's opportunity. Regardless, IMHO, the EnvConfiguration should check to see if the env entry already exists, and return it if it does, or create one if it does not. The attached patch does this and everything works. However I think the real issue is that the JNDI engine needs to initialize before deployment.

        Show
        jgenender jgenender added a comment - I have a test case to attach. All source code available for you. Extract it then run 'mvn install' in the root dircetory. After its all built, go into the web dirextory and run 'mvn jetty:run'. You will notice the following exception: Caused by: javax.naming.NameNotFoundException; remaining name 'jdbc/myDS' at org.mortbay.naming.NamingContext.lookup(NamingContext.java:634) at org.mortbay.naming.NamingContext.lookup(NamingContext.java:665) at org.mortbay.naming.NamingContext.lookup(NamingContext.java:665) at org.mortbay.naming.NamingContext.lookup(NamingContext.java:680) at org.mortbay.naming.java.javaRootURLContext.lookup(javaRootURLContext.java:112) at javax.naming.InitialContext.lookup(InitialContext.java:351) at org.hibernate.connection.DatasourceConnectionProvider.configure(DatasourceConnectionProvider.java:52) Then change web/src/test/jetty/hsql/jetty.xml file to use a fully qualified name on line 23 to javax.naming.NameAlreadyBoundException: env at org.mortbay.naming.NamingContext.createSubcontext(NamingContext.java:453) at org.mortbay.naming.NamingContext.createSubcontext(NamingContext.java:517) at org.mortbay.jetty.plus.webapp.EnvConfiguration.createEnvContext(EnvConfiguration.java:52) at org.mortbay.jetty.plus.webapp.EnvConfiguration.configureWebApp(EnvConfiguration.java:103) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1209) This seems to me that the Spring JNDI is getting created before Jetty gets it's opportunity. Regardless, IMHO, the EnvConfiguration should check to see if the env entry already exists, and return it if it does, or create one if it does not. The attached patch does this and everything works. However I think the real issue is that the JNDI engine needs to initialize before deployment.
        jgenender jgenender made changes -
        Attachment test.src.tgz [ 26382 ]
        Hide
        Jan Bartel added a comment -

        Hi Jeff,

        Thanks for the test webapp!

        The web.xml seems to be missing a <resource-ref> to link it to the datasource declared in the jetty.xml file.

        When I added the following, it all works:

        <resource-ref>
        <res-ref-name>jdbc/myDS</res-ref-name>
        <res-type>javax.sql.DataSource</res-type>
        <res-auth>Container</res-auth>
        </resource-ref>

        Perhaps tomcat does this differently, but usual practice is to declare the resources known to the container in the container-specific config file, then each webapp indicates which ones they want to use by putting <resource-ref> entries in web.xml (or these days, you can also do it with annotations).

        It should be fine to leave that <resource-ref> in there also when executing with tomcat, jetty or whatever.

        cheers
        Jan

        Show
        Jan Bartel added a comment - Hi Jeff, Thanks for the test webapp! The web.xml seems to be missing a <resource-ref> to link it to the datasource declared in the jetty.xml file. When I added the following, it all works: <resource-ref> <res-ref-name>jdbc/myDS</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> </resource-ref> Perhaps tomcat does this differently, but usual practice is to declare the resources known to the container in the container-specific config file, then each webapp indicates which ones they want to use by putting <resource-ref> entries in web.xml (or these days, you can also do it with annotations). It should be fine to leave that <resource-ref> in there also when executing with tomcat, jetty or whatever. cheers Jan
        Hide
        jgenender jgenender added a comment -

        Hi Jan,

        Thanks for the resource-ref tip. That got rid of the error. I cannot find anything in the spec that states a resource-ref is required when using a fully qualified name. So I guess it's ultimately up to the container to decide. Some of the other containers, including Weblogic seem to allow a fully qualified name to be used w/o resource-ref. But in any case, your tip worked

        Show
        jgenender jgenender added a comment - Hi Jan, Thanks for the resource-ref tip. That got rid of the error. I cannot find anything in the spec that states a resource-ref is required when using a fully qualified name. So I guess it's ultimately up to the container to decide. Some of the other containers, including Weblogic seem to allow a fully qualified name to be used w/o resource-ref. But in any case, your tip worked
        Greg Wilkins made changes -
        Assignee Jan Bartel [ janb ]
        Hide
        Jan Bartel added a comment -

        Resolved.

        Show
        Jan Bartel added a comment - Resolved.
        Jan Bartel made changes -
        Status Open [ 1 ] Closed [ 6 ]
        Resolution Fixed [ 1 ]

          People

          • Assignee:
            Jan Bartel
            Reporter:
            jgenender jgenender
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: