Marc, Mike, et.al.
I've put some JNDI CP documentation on the link from the Components page,
http://wiki.eclipse.org/index.php/JNDI_Context_Provider. Check it out and
let me know if there are things that could or should be clarified.
Thanks,
Tom
>>> "Tom Doman" <TDoman@xxxxxxxxxx> 3/9/2007 9:16 AM >>>
Marc,
I'll add a little to this to try add to the confusion ... er, I mean,
clarify a few more things:
1. The JNDI CP is intended to support any JNDI provider but there are
currently a few LDAPisms in there.
2. The exact behavior of open, close, etc. may fall under #1 in as much as
the env variables and LdapContext APIs we're calling aren't available to
more generic superclasses.
3. At any rate, the exact behavior (at least, intended behavior) of the JNDI
CP today is that open will do an LDAP bind, and close will do nothing to the
connection. Once a subsequent open is called, a new bind may occur based on
the credentials passed. If the creds are the same (actually I need to
override the default "equals" method here still), no rebind occurs. This
may not be the behavior that is ultimately wanted, but, FWIW, that's what
it's doing today because we at least didn't want to tear down the connection
on close.
4. It is our intent to make the JNDI CP Context Factory pool IContext
instances for performance optimization. We may, in fact, create a generic
Pooling CP which can be used to pool in any kind of CP or, perhaps, even
many kinds of different CPs at once. At least that is a thought in our blue
sky but we'll at least implement some pooling at the JNDI CP Context Factory
level.
5. I've been in the process of debugging our Mapping (JavaScript Policy
based) CP and was going to check it into eclipse today with accompanying
JNDI CP changes to remove the lame hard coded in and out mappings for
attributes as well as names. However, I'll suspend that in favor of some
configuration documentation at the location Jim mentioned. However, I will
not document the old ugly methods of doing things that the Mapping CP will
now do, I'll document that "new hotness" on the Mapping CP page when I've
gotten it checked in. Just so you're aware, sadly, even that JNDI CP
configuration documentation will change when the Registry, XRI, XRDS "new
hotness" comes out but we need to have the current stuff documented in the
mean time so I'll get on that now.
Tom
>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 3/9/2007 8:45 AM >>>
Here are some things that might address some of the confusion:
- A CP (Context Provider) can produce any number of IContext instances.
- A CP is just a term meaning a packaging of classes that implement the
various IdAS interfaces.
- An IContext instance provides the view of a Context.
- An IContetFactory is implemented by each CP and produces (and could pool,
cache, etc.) IContext instances.
- A Context is often backed by an underlying data store (as is the case with
the JNDI provider when configured to use LDAP)
So, the relationship between a CP and an underlying connection is really up
to the CP. In the case of the JNDI (using LDAP) CP, the JNDIContextFactory
will produce any number of IContext instances, each with a 1:1 relationship
with an LDAP connection.
Authentication is different. Any IContext instance could have its
open/close method called any number of times. Each time, this could cause a
new authentication to happen. In the case of the JNDI (using LDAP) CP, open
is designed to do an LDAP bind, and close is designed to do an LDAP unbind
(I'm not sure if this is the exact behavior today -- it's what's intended
though).
Jim
>>> "Marc Boorshtein" <mboorshtein@xxxxxxxxx> 3/9/07 7:55 AM >>>
>
> Currently, the only component being automatically built (and thus
> downloadable) is idas. I know you can get and build idas, the jndi cp,
and
> the token service. Each component should have build instructions here.
>
OK, I've got the source for the IdAS and the jndi CP. Thanks.
> Yes, IContext.open is effectively authenticate. close is the opposite of
> open. I'm not sure why, but the idas javadoc from the nightly build seems
> to be broken right now. An alternate (though not in sync with the latest
> head code) version is here:
> http://www.eclipse.org/higgins/org.eclipse.higgins.docs/idas/
>
OK. I'm still a bit confused but I'll go through the IdAS code. The
main point of my confusion is the relationship between a CP and an
underlying connection. IE the jndi cp only has a single JNDI
context. Does this mean that there is a 1-1 relationship between a cp
and an authenticated user? Would this in turn indicate multiple
instances of a context provider are pooled inside of the IdAS?
Thanks again for the help
Marc
> Jim
>
> >>> "Marc Boorshtein" <mboorshtein@xxxxxxxxx> 3/8/07 10:51 PM >>>
>
> > #1 was a topic of discussion a couple days ago on the irc or some form
of
> IM
> > as well. It was suggested that Tom put together instructions on how to
> > install/configure the JNDI context provider. I think it will show up
here
> > soon
> > http://wiki.eclipse.org/index.php/JNDI_Context_Provider
> >
>
> Ok, I'll check it out once it's done
>
> > For #2, there are unit tests for the JNDI CP, but I don't think there's
> much
> > beyond that (we should probably put out some sample code). If you want
to
> > do something more complex, you could deploy the Token Service, backed by
> the
> > JNDI CP which is backed by an LDAP server.
> >
>
> the token service...great.Is that a download yet? I only saw the
> idas.jar under downloads
>
> > At least for #1, to get started you can build IdAS and the JNDI CP
> > (instructions here and here)
> >
>
> Ok, I've got these setup. One question (might be unrelated). Is the
> "open" method on the context provider supposed to be an authentication
> method? It appears to be based on the "sample" in the jndi "dev"
> package.
>
> Thanks
> Marc
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
>
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
>
>
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
