geronimo-dev mailing list archives

Could you raise a JIRA and attach the patch for review ?
Thanks,
Guillaume Nodet
On 6/23/06, Krishnakumar B <www.bkk@gmail.com> wrote:
>
> hi,
>
> We ( Me & Manu ) have created a implementation of global JNDI based
> on the feedback received on the dev list.
>
> It works like this.
>
> * The implementation uses GeronimoRootContext and ReadOnlyContext
> thats part of naming module to create the root context ( geronimo: ).
> The Context is accessed by means of a Factory
> GeronimoInitialContextFactory that implements InitialContextFactory.
>
> * A GBean ( GeronimoContextGBean ) loads on start of server and
> creates the Root Context. Now applications can bind to this context.
>
> * We have added GBeans to naming ( GlobalJNDIBindingGBean for RA,
> DataSource, QCF/TCF,Queue, Topic and EJBJNDIBindingGBean for EJB )
> that are deployed when an app is deployed.
>
> * The builders add the Gbeans during the deployment process. [
> ConnectorModule Builder, OpenEJBModuleBuilder, ServiceConfigBuilder ].
>
> The plan needs to have some XML Tag to say this resource needs to gets
> into Global JNDI and the builder can then add it to geronimo: Context.
> This is not implemented yet. Currently if we deploy a connector it
> gets in global jndi.
>
> The current code we can add DataSource, RA, EJB, QCF, Queue/Topic,
> GBeans to geronimo: Context. With some changes to context
> implementation any object can be bound to global JNDI. ( Have not
> looked at security aspect and would need some ideas on how to proceed
> ).
>
> This may need some more work and changes before it takes final form to
> get into product. Kindly provide your review, comments and
> contributions from others who are interested and have better ideas.
>
> We are not able to attach the code as mailing list rejects attachments.
>
> Regards
> Krishnakumar B
>
>
> On 5/24/06, Krishnakumar B <www.bkk@gmail.com> wrote:
> > Thanks for the feedback and inputs.
> >
> > Regards
> > Krishnakumar
> >
> >
> > On 5/24/06, Dain Sundstrom <dain@iq80.com> wrote:
> > > On May 23, 2006, at 5:19 PM, David Jencks wrote:
> > >
> > > >
> > > > On May 23, 2006, at 6:28 AM, Krishnakumar B wrote:
> > > >
> > > >> 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?
> > > >
> > > > IIUC java: is reserved by the j2ee spec for what it requires: thus
> > > > IMO we should use something else. IIRC the original global jndi
> > > > context used geronimo: I'm OK with that or maybe global:.
> > >
> > > IIRC some servers use just "/foo/bar" with no context. If I am
> > > correct, we should support that also (but not the default).
> > >
> > > >>
> > > >> * 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
> > > >
> > > > I'm not sure what you're asking about here. Unless you do
> > > > something screwy to link one of these to the other, the contents of
> > > > these contexts will be completely unrelated.
> > >
> > > Looking at the JavaDocs for InitialContext, it does not have a
> > > constructor that takes a String. Did you mean:
> > >
> > > Context context = (Context) new InitialContext().lookup("java:comp/
> > > env");
> > > Context context = (Context) new InitialContext().lookup("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
> > > >
> > > > For j2ee components I think we should bind the same kinds of
> > > > References in the global jndi tree as we bind in the current java:
> > > > context. What we bind for stuff that can't get into the java:
> > > > context needs more thought: it probably depends on what it is. Of
> > > > course if the context is not read-only an app can bind whatever it
> > > > wants wherever it wants, thus bringing to mind the need for
> > > > security and permissions for this stuff.
> > >
> > > I don't think we can use the current Reference object we bind into
> > > our read only context because they do cache the value and never
> > > release it. It is expected that the referece will be GCed when the
> > > J2EE application is unloaded. It shouldn't be hard to either turn
> > > off the cache or to register listener for the reference target life-
> > > cycle events.
> > >
> > > >> Would appreciate any thoughts as i am still learning and might have
> > > >> missed some points to consider while trying to implement something
> > > >> like this.
> > > >
> > > > My plan for implementing this was:
> > > >
> > > > 1. Look at the current ReadOnlyContext implementation and figure
> > > > out how to make a sufficiently synchronized version of it. I'm
> > > > hoping that we can have synchronized wrappers around this
> > > > implementation rather than needing a copy, subclass, or new
> > > > implementation.
> > >
> > > I think a read only JNDI and a mutable one are different enough that
> > > they need separate implementations. Currently our ENC is using a the
> > > EnterpriseNamingContext which does not extend ReadOnlyContext (as it
> > > isn't really read only). I'd like to keep the
> > > EnterpriseNamingContext simple and strictly read only. Therefore,
> > > I'd like to see an new separate implementation. If I were going to
> > > write it, I'd base it on ConcurrentReaderHashMap and future objects
> > > in Java5 (or backport-concurrent-util), but I'm not writing it, so I
> > > say do whatever you are comfortable with.
> > >
> > > > 2. Remind myself of how the geronimo: context used to be
> > > > installed. I think the same method will still work. We might want
> > > > a gbean to specifically install it. Make sure that programmatic
> > > > binding and lookup works.
> > >
> > > IIRC, we add set naming provider package to
> > > org.apache.geronimo.naming and when a user tries to access the "foo:"
> > > root-context, the jvm looks for the class
> > > org.apache.geronimo.naming.foo.fooURLContextFactory. We still have
> > > one named global that most likely gets loaded when someone looks up
> > > "global:"
> > >
> > > > 3. Figure out how to bind stuff into this context from plans rather
> > > > than java code. Currently my idea is to do this with binding
> > > > gbeans: I'm not entirely sure how to do this but one possibility
> > > > would be to have them contain a Reference object and the name to
> > > > bind it under. Another possibility would be to not use References
> > > > but rather have a binding gbean with say a gbean reference to a
> > > > ManagedConnectionFactoryWrapper: the gbean would call $getResource
> > > > () on it and then bind the result directly into jndi. This would
> > > > result in simpler builders but more gbeans: we'd need one for
> > > > resource-refs and resource-env-refs, and another one for ejbs, and
> > > > another for plain gbean bindings. One thing I like about this
> > > > second plan is that the object would only be bound in jndi while
> > > > the resource was actually available. Of course, the component that
> > > > looks up the entry can still keep it until the underlying gbean
> > > > support is long gone, and get exceptions when it tries to use the
> > > > entry.
> > >
> > > I think binding will be the hardest part :)
> > >
> > > -dain
> > >
> >
>