8 Replies Latest reply: Dec 13, 2012 10:03 AM by aquijano RSS

Why not java:global/datasources?

Aaron Harshbarger Newbie

We are migrating our spring application over to AS7 and are experiencing issues with getting the datasources to work.  When we update the <datasources> element within the standalone-full.xml file,it will not accept a jndi-name that starts with java:global/datasources.  It only accepts a jndi-name that starts with java:jboss/datasources?

 

We really want to stay away from any proprietary hooks, which is why EE6 spec had a java:global namespace.  Any reason why JBoss AS 7.1.1 doesn't support the java:global/datasources namespace.  I thought it was EE6 certified?  Are we doing something wrong?

 

Below is what we want to have in our Spring EAR/WAR to avoid any tie to a particular vendor.  The reason is this could run in JBoss, Tomcat (Standalone), etc. 

 

<jee:jndi-lookup jndi-name="java:global/datasources/MyDS" id="myDataSource" expected-type="javax.sql.DataSource"/>

 

Any help would be greatly appreciated.

 

Thanks,

Aaron

  • 1. Re: Why not java:global/datasources?
    Erhard Siegl Newbie

    I came across the same question. When I try to use the "java:global" namespace ist says:

    :write-attribute(name=jndi-name, value=java:global/datasources/bookingDatasource)

    {

        "outcome" => "failed",

        "failure-description" => "JBAS010471: Jndi name have to start with java:/ or java:jboss/",

        "rolled-back" => true

    }

     

    and indeed a datasource java:/datasources/bookingDatasource works. From the documentation in https://docs.jboss.org/author/display/AS7/How+do+I+migrate+my+application+from+AS5+or+AS6+to+AS7 I thought it wouldn't work:

    Namespaces should follow these rules:

    1. Unqualified relative names like "DefaultDS" or "jdbc/DefaultDS"
      should be qualified relative to "java:comp/env", "java:module/env", or
      "java:jboss/env", depending on the context.
    2. Unqualified "absolute" names like "/jdbc/DefaultDS" should be
      qualified relative to a "java:jboss/root" name.
    3. Qualified "absolute" names like "java:/jdbc/DefaultDS" should be
      qualified the same way as #2.
    4. The special "java:jboss" namespace is shared across the entire AS
      server instance.
    5. Any "relative" name with a "java:" lead-in must be in one of the five
      namespaces: "comp", "module", "app", "global", or our proprietary
      "jboss". Any name starting with "java:xxx" where "xxx" is a name which
      is not equal to one of the above five would result in an invalid name error.

     

    Especially from 3. I expected "java:/datasources/bookingDatasource" not to be valid and from 5. that "java:global/datasources/bookingDatasource" would be valid. One could argue that the "should" is not a "must" and that "java:/" is not of form "java:xxx", but it would be helpful if someone can clearify this.

  • 2. Re: Why not java:global/datasources?
    navuri prasad Newbie

    <jee:jndi-lookup jndi-name="java:global/datasources/MyDS" id="myDataSource" expected-type="javax.sql.DataSource"/>

     

    try like this way

    <jee:jndi-lookup jndi-name="MyDS" id="myDataSource" expected-type="javax.sql.DataSource"/>

  • 3. Re: Why not java:global/datasources?
    Carlo de Wolf Master

    java:global/datasources is not defined in the spec.

     

    If you truly want to be vendor independent you should bind the datasource to a JBoss valid JNDI name and use only resource refs in your application.

  • 4. Re: Why not java:global/datasources?
    Erhard Siegl Newbie

    (As far as I understand the question is about the "java:global" part and not about the "datasources" part. "java:global/env/MyDS" would be the same)

    So do I interpret your answer correct that the namespaces java:comp, ...,java:global are only specified for EJBs but this can't be applied for other things like datasources and that there is no specified global name for datasources?

    Of course the resource refs are the clean way, but still one has to edit some deployment-descriptors within a package. (As far as I now there is no way to configure it from outside like deployment-profiles in weblogic??? but thats probably another topic.)

  • 5. Re: Why not java:global/datasources?
    Stuart Douglas Master

    I think this is a bug, I can't think of any reason why we don't allow this. Can you file a JIRA?

  • 6. Re: Why not java:global/datasources?
    Stephen Coy Master

    I originally thought that this was a bug too, but I've just re-read the spec (§E5.2.2) on this.

     

    java:comp, java:module, java:app and java:global are all names in the environment naming context (aka ENC).

     

    ie. java:comp/... is not in the global JNDI namespace and neither is java:global/...

     

    As Carlo mentioned, java:global/datasources is undefined. The intent of the spec is that the user can specify java:global/env/datasources/bookingDataSource and that the "deployer" can map this to a physical resource such as java:jboss/datasources/bookingDataSource.

     

    By the way, in my experience, 4 out of 5 "enterprise java" developers have never heard of the ENC and just use global JNDI names everywhere.

  • 7. Re: Why not java:global/datasources?
    Erhard Siegl Newbie

    Stephen, thx for the information and for the reference to the spec (found at http://jcp.org/en/jsr/detail?id=316).

  • 8. Re: Why not java:global/datasources?
    aquijano Newbie

    I'm still not sure I understand this. On the JEE 6 spec section §EE.5.17 "DataSource Resource Definition" it states:

     

    The DataSource resource may be defined in any of the JNDI namespaces

    described in Section EE.5.2.2, “Application Component Environment

    Namespaces”. For example, a DataSource resource may be defined:

    • in the java:comp namespace, for use by a single component;

    • in the java:module namespace, for use by all components in a module;

    • in the java:app namespace, for use by all components in an application;

    • in the java:global namespace, for use by all applications.

     

    And then there's an example of a datasource bound to java:app/MyDataSource, which JBoss wouldn't allow

     

    what am I missing?