geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Binding into global (and other) jndi
Date Sun, 01 Oct 2006 18:16:51 GMT
Dain has been working on a global jndi implementation that looks  
really nice.  However the deployment of bindings part of it has  
brought up some long-festering architectural worries and perhaps we  
are now in a position to deal with them in a systematic manner.

David Blevins pointed out to me a long time ago that one of the core  
principles of openejb was that ejb containers should have nothing  
transport specific attached to them.  This was when I installed a  
TSSBean reference in ejb containers to enable binding ejbs into  
corba.  I pointed out that letting the ejb container know jndi-names  
and local-jndi-names had the same problem, and IIRC he agreed that  
this was an architectural flaw.  In any case, intentionally or not,  
he convinced me that both the tssbean link and the jndi names should  
not be attached to the ejb container.  If you install dain's global  
jndi stuff the jndi names now get recycled up to 3 times: for the  
openejb proprietary jndi impl, global jndi, and corba.  The global  
jndi connector binding creates a similar but worse problem for j2ca  
connectors, since it tries to bind using only the "name" component of  
the abstract name, rather than allowing a specific global jndi name,  
and AFAICT it doesn't let you specify which connectors you want to bind.

I think for all of these situations a cleaner runtime solution is a  
component that links the thing you want to bind and the binding  
context, and includes the name(s) you want to bind under.  Currently  
this would I think have to be a gbean.  This is what Dain implemented  
for gbean bindings.  So, I'm proposing that bindings for connectors  
in global jndi, and ejbs in global jndi, corba, and the openejb jndi,  
each be set up by gbeans, each holding the name(s) to bind under and  
a reference to the object to be bound.  This part is pretty easy to  
write.

Slightly harder is deployment: setting up these gbeans.  If we modify  
our schemas this can be done using NamingBuilders: here they won't be  
constructing the components jndi context but rather exposing the  
component in various naming systems. I think the really hard part is  
figuring out some xml that is manageable to write and expresses the  
meaning clearly.

For connectors it's pretty easy, we can just have a repeating element
<global-jndi-name>foo</global-jndi-name>

For ejbs with the current 3 naming systems it's a bit harder.  One  
possibility would look something like this:

<jndi>
   <global/>
   <corba>
      <tss-link>foo-tss</tss-link>
   </corba>
   <openejb/>
   <remote-name>foo</remote-name>
   <local-name>bar</local-name>
</jndi>

where the global, corba, and openejb elements indicate which naming  
system to bind to and the names are supplied with remote-name and  
local-name.  A remote jndi would ignore the local-name elements.  You  
could have multiple jndi elements to get different bindings in  
different naming systems.

To make this extensible the naming system elements would have to be  
in a substitution group and extend an abstract element.  The ones we  
know about now could all be in the same namespace.


Thoughts?

thanks
david jencks


Mime
View raw message