geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Binding into global (and other) jndi
Date Wed, 18 Oct 2006 01:43:30 GMT
FWIW I've removed the TSSBean reference from the ejb containers and  
made a TSSLink and TSSLinkBuilder that installs them as part of  
separating the corba related classes into a separate jar  
(OPENEJB-280).  The jndi names and local-jndi-names are unfortunately  
still attached to the ejb container.

david jencks

On Oct 1, 2006, at 11:16 AM, David Jencks wrote:

> 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

View raw message