geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Krishnakumar B" <www....@gmail.com>
Subject Re: Implementing Global JNDI
Date Tue, 23 May 2006 13:28:21 GMT
Hi,

I have a few doubts related to implementation of global jndi.

* Currently we have java:comp/env stored in Local JNDI. In Global JNDI
should objects be bound using a different namespace e.g) java: or
java:global?

* When we implement global JNDI we have some entries in Global and All
entries related to application in Local. When a user creates a context
he needs to get from either global or local based on what he needs.
Would it be right for lookup code to decide from where to fetch the
entry based on how the Context is created?

for e.g) if i say InitialContext iniCtx = new
InitialContext("java:comp/env"); fetch from local
and if InitialContext iniCtx = new InitialContext("java:global");
fetch from global

* Currently in Local JNDI we store Resource References. Should global
JNDI also use the same approach or can we use Object references for
e.g) DataSource reference directly put in JNDI

Would appreciate any thoughts as i am still learning and might have
missed some points to consider while trying to implement something
like this.

Regards
Krishnakumar


On 4/28/06, David Jencks <david_jencks@yahoo.com> wrote:
>
> On Apr 27, 2006, at 9:16 AM, Dain Sundstrom wrote:
>
> > I think we need to provide a non-persistent r/w global jndi tree
> > since there are so many apps that depend on it.  In addition, I
> > think we need a way for users to provide a set of bindings (JNDI,
> > cos-naming, jaxr... really anything) to EJBs, RAs, and any GBean so
> > that the services they need are available where their application
> > expect.
> >
> > I have been thinking about the binding problem for a while and just
> > haven't had time to work on it myself.  I think we can do something
> > as simple as this for most services:
> >
> > <gbean name="foo-binding"
> > class="org.apache.geronimo.naming.JndiBinding">
> >    <reference name="object"><name>myService</...>
> >    <attribute name="address">services/myService</...>
> > </...>
> >
> > For J2EE services we want to bind, I think the xml above is way to
> > complex and we need to provide some syntactic sugar.
>
> That's basically what I had in mind, but expressed more clearly and
> concretely
>
> thanks
> david jencks
>
> >
> > -dain
> >
> > On Apr 27, 2006, at 1:22 AM, David Jencks wrote:
> >
> >> I'm not convinced this discussion has got to the hard parts
> >> yet :-)  I hope there turn out not to be any :-)
> >>
> >> Please don't change stuff in the read-only java:comp/env context
> >> since it is pretty much completely specified by the spec.  Note
> >> also that according to the spec a j2ee compliant app will only use
> >> this jndi context, and only use the entries defined in the j2ee
> >> deployment descriptors.
> >>
> >> I think you can use a lot of the jndi infrastructure we already
> >> have including the geronimo context and the references to jca
> >> connection factories, ejbs, etc.
> >>
> >> The missing part is how to get these references bound into your
> >> context.  One approach is to write gbeans that install a reference
> >> when started and remove it when stopped.  I would start by just
> >> including these as plain gbeans in plans, and once that works
> >> consider modifying the builders to add them automatically based on
> >> xml in the geronimo plans.
> >>
> >> An alternative might be to investigating using say Directory to
> >> persist the references directly.  I don't know enough about ldap
> >> to know if this makes any sense at all.
> >>
> >> thanks
> >> david jencks
> >>
> >> On Apr 26, 2006, at 11:56 PM, Manu George wrote:
> >>
> >>> Comments inline
> >>>
> >>> On 4/26/06, Guillaume Nodet <guillaume.nodet@worldonline.fr>
> >>> wrote: Looking more closely, it seems I was wrong.
> >>> Gbeans with a j2eeType=JCAManagedConnectionFactory have a
> >>> connectionFactoryInterface attribute that gives the name of the main
> >>> interface to use when binding the object to the JNDI context.
> >>> For EJB, GBeans with a j2eeType=StatelessSessionBean (or
> >>> EntityBean ...)
> >>> have attributes for the home and business interfaces.
> >>> So i guess it should be ok.
> >>>
> >>> great
> >>>
> >>> Another way to handle that would be to bind the resource to the
> >>> global
> >>> JNDI tree when the resource is created: each configuration would
> >>> contain
> >>> a list of gbeans to bind in the jndi tree when the configuration is
> >>> loaded.  Else, we will need some listener to listen to gbeans
> >>> creation /
> >>> destruction so that we can bind / unbind them from the global
> >>> jndi context.
> >>>
> >>> Binding the resource during creation seems to be the simpler way.
> >>> But what about the next time the server starts up. How is the
> >>> context initialised? Do we populate during startup of each
> >>> resource or application again or is persistence used in some way?
> >>>
> >>> In the case of listeners the above problem won't arise.
> >>>
> >>>
> >>> A few questions:
> >>> * I' m wondering how the global JNDI context will coexist with the
> >>> existing ENC context, especially if the global jndi context is
> >>> read-write ... Maybe there is no need for a local jndi context ...
> >>>
> >>> Yes that is a question i also have :-) . The local jndi context
> >>> allows us to have app specific contexts and this has some
> >>> advantages. A global jndi also has some advantages. Probably by
> >>> default we can use the local context and if the user specifies a
> >>> custom factory the global one or vice versa.
> >>>
> >>> * what is the purpose of the jndiname property ? If this is the
> >>> key for
> >>> a gbean in the jndi tree, I thought we could use the name
> >>> attribute of
> >>> the gbean: "jdbc/TradeDataSource" , "jms/QueueConnectionFactory".
> >>>
> >>> These names can also be TradeDatasource so then we may need to
> >>> add jdbc and if jdbc is there in the name as you mentioned do we
> >>> need to add jdbc to the name or not. These are a few issues which
> >>> made me propose the jndiName property .
> >>>
> >>>   * what about conflicting names for JCA resources... currently
> >>> there is
> >>> nothing to prevent deploying JCA resource (or other resources
> >>> that would
> >>> be bound to jndi) with the same name
> >>> I think deployment should fail with an resource already bound
> >>> exception. Not sure if this or any other validation is
> >>> implemented for the local context.
> >>>
> >>>
> >>> Thanks
> >>> Manu
> >>
> >
>
>

Mime
View raw message