On Feb 6, 2007, at 5:34 PM, Dain Sundstrom wrote:
Jee5 makes extensive use of Global JNDI for references.
Specifically, the following use Global JNDI:
It looks to me as if these all mention global jndi but saying they
"use" global jndi seems like an exaggeration to me.
@Resource.mappedName()
This mapped name is often a global JNDI name, but may be a name of
any form.
@EJB.mappedName()
This mapped name is often a global JNDI name, but may be a name of
any form.
@MessageDriven.mappedName()
A product specific name(e.g. global JNDI name of a queue) that this
message-driven bean should be mapped to.
@WebServiceRef.mappedName()
This mapped name is often a global JNDI name, but may be a name of
any form.
<persistence-unit><jta-data-source>
<persistence-unit><non-jta-data-source>
InJavaEEenvironments,thejta-data-sourceandnon-jta-data-
sourceelementsareused
tospecifytheglobal JNDInameoftheJTAand/ornon-
JTAdatasourcetobeusedbythepersistence
provider.
The spec makes it clear that Global JNDI is not required to satisfy
these values, and that the meaning of these fields is completely
vendor specific. In the case of mapped name, the application
server can completely ignore the field.
The problem is our users' applications will make use of mapped name
in other application servers, and since every application server
that I know if is implementing these with Global JNDI, it becomes a
defacto standard and requirement for Jee5. Moreover, I believe
that our GlobalJNDI names must be simple normal names (i.e, not
encoded abstract names) you would see in other application servers,
because users will annotate their code with the mapped names,
effectively locking in the Global JNDI names that they expect to
work in our application server.
umm, that assumes that either every other app server has come up with
exactly the same scheme for global jndi names so they are in fact
interoperable or that we can imitate everyone elses naming scheme at
once. Do you have any evidence for the first? How would you propose
we do the second? What are the jndi naming schemes for each other
app server?
So do you agree that Global JNDI is the defacto required
implementation for these and other similar entries?
no.
Since the beginning of geronimo we've carefully stayed away from
relying on global jndi for resolving references since it imposes
global constraints on what you can deploy at once in the app server,
despite every other app server I know of relying on global jndi for
resolving references. I'm extremely reluctant to abandon the lack of
conflicts between apps that we have now to run after an alleged
similarity with other app servers without thorough investigation of
compatibility between other app servers and thinking about other
choices that would preserve the lack of conflicts.
Note that the use of any particular style of name in such annotations
does not imply that the target is actually bound in jndi: all it
requires is that we can find the resource somehow.
Two alternatives that I would prefer to global jndi are:
1. We know the type of the thing we're looking for, so we can simply
treat the provided string as an (extended) ejb-link, resource-link,
etc and search the ancestor tree of the current app for a unique
match. IMO this would be a lot simpler to implement that relying on
global jndi, because we already have the code implemented and don't
have to bind anything anywhere.
2. "scoped" global jndi. Each application gets a "global" jndi tree
that only includes stuff from itself and its ancestor graph. This
avoids conflicts and should satisfy those with a jndi fetish.
thanks
david jencks
-dain
