On Feb 7, 2007, at 9:54 AM, Dain Sundstrom wrote:
On Feb 7, 2007, at 8:01 AM, David Jencks wrote:
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.
um, I'm not making that assumption. I'm assuming that other
systems are using Global JNDI for resolving refs and that users
will have "normal" JNDI names hardcoded into their apps. By normal
names I would say that they are simple words separated by a '/'
character.
I'm saying:
1. simple names are good
2. simple names have nothing necessarily to do with global jndi
althought that is one possible implementation strategy
3. if users expect portability across app servers we need to do some
actual research on what other app servers do and find out if there is
in fact a de-facto standard. Hand waving won't cut it.
My impression from various code that attempts to locate
TransactionManagers in various app servers jndi is that while
everyone has schemes that are vaguely similar, they are all in fact
different and incompatible. So my initial bias before doing any
research is that compatibility across app servers is going to be
rather hard.
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.
I understand your reluctance and know the history, but reality is
*everyone* uses Global JNDI. I challenge you to find a single JEE
server that doesn't. Since everyone does, it is the defacto
standard, and it is becoming more ingrained into the specs. I
think we need give up on our custom system, and simply implement it
the way everyone else dose.
I don't really understand what your insistence on global jndi has to
do with the problem of resolving these annotations. The user's app
isn't directly using jndi for this. To me you are saying "we can't
do anything better than anyone else because it might be different".
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.
There is nothing wrong with either proposal, and either would be a
step forward. I just think we shouldn't invent something new and
just give users what they expect.
Do you think (2) would surprise people too much? I'm very reluctant
to abandon the conflict avoidance of what we have in order to copy
the lowest common denominator. (1) is the easiest solution I can
think of since it's basically already implemented and doesn't involve
coming up with a binding strategy for everything and (2) seems to me
to combine the advantages of global jndi with the conflict avoidance
we have now. Why is plain global jndi better?
thanks
david jencks
-dain
