-
1. Re: Why not java:global/datasources?
erhard Apr 17, 2012 6:20 PM (in response to aharshbarger)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:
- 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. - Unqualified "absolute" names like "/jdbc/DefaultDS" should be
qualified relative to a "java:jboss/root" name. - Qualified "absolute" names like "java:/jdbc/DefaultDS" should be
qualified the same way as #2. - The special "java:jboss" namespace is shared across the entire AS
server instance. - 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.
- Unqualified relative names like "DefaultDS" or "jdbc/DefaultDS"
-
2. Re: Why not java:global/datasources?
navurinv Apr 18, 2012 2:40 AM (in response to erhard)<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?
wolfc Apr 18, 2012 3:58 AM (in response to aharshbarger)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 Apr 18, 2012 5:17 AM (in response to wolfc)(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?
swd847 Apr 18, 2012 5:45 AM (in response to aharshbarger)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?
sfcoy Apr 19, 2012 10:08 PM (in response to swd847)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 Apr 18, 2012 1:33 PM (in response to sfcoy)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 Dec 13, 2012 10:03 AM (in response to sfcoy)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?