Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
In-Reply-To: <75194C6D-F1D6-45A4-B4F4-9FD4FBEBDA21@yahoo.com>
References: <75194C6D-F1D6-45A4-B4F4-9FD4FBEBDA21@yahoo.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <7B5C0783-CFCA-4E0A-A2F4-A73640A1456C@visi.com>
Cc: "Geronimo Dev List (JIRA)" <dev@geronimo.apache.org>
Content-Transfer-Encoding: 7bit
From: David Blevins <david.blevins@visi.com>
Subject: Re: Binding into global (and other) jndi
Date: Mon, 2 Oct 2006 10:00:01 -0700
To: openejb-dev@incubator.apache.org


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?

There was a discussion on this in context of OpenEJB 3.  It was short  
and no real conclusion was made, but let me see if I can't dig it up.

-David


>
> thanks
> david jencks
>