Hi Jonathan,
As far as JNDI/LDAP, there should be no issues running under an AppServer.
The LDAP protocol is entirely socket based, and the protocol does not
require any behind the scenes behavior. However, I can not speak to any
possible threading that the SPI might utilize.
And I agree that any AppServer that did not work with a standard JNDI
Service Provider, which includes LDAP, would be considered broken, unless
that SPI somehow broke EJB rules in its implementation.
Gee, now that I consider my last sentence, I realize that I once wrote
a JNDI SPI that provided access to a read-only LDIF file, which would
not be valid under the EJB spec. Hmm. So it seems to be a case-by-case
consideration.
tim.
> Tim,
>
> Actually, I think it is a reasonable question. Sun provides
> a JNDI-over-LDAP implementation, and the question (to me)
> was can such a beast be used in conjunction with an AppServer.
>
> <vendor>
> In the case of Borland AppServer, the answer is yes. In
> fact, any proper JNDI SPI implementation can be used. By
> default, we use the JNDI-over-CosNaming implementation provided
> by Sun, which is not proprietary (any more than LDAP is).
> </vendor>
>
> I suspect the JNDI-over-LDAP implementation can be used with
> other AppServers, unless the given AppServer requires some "back
> door" interaction with the naming service, which would lock
> a given AppServer to its particular JNDI implementation.
>
> -jkw
>
> Tim Endres wrote:
> >
> > I think it is even simpler than that. You are confusing LDAP for JNDI.
> >
> > LDAP is a directory service that binds textual or binary data to a named
> > context tree. JDNI is a naming service the provides Objects that are bound
> > to a named context tree. Said Objects include DirContext's which provide
> > attribute functionality. JNDI dishes up LDAP via a "service provider".
> >
> > The InitialContext that you get from JNDI in an application server does not
> > have to represent directory data in any form. It can simply bind contexts in
> > the tree, and dish up any object it wishes in response to a lookup. In other
> > words, the Object that it dishes up does not necessarily have to be conducive
> > to being stored externally, such as in LDAP.
> >
> > Handles might blur that a little, since you could conceivably obtain an EJB
> > handle, and then serialize that Handle into an LDAP directory server.
> >
> > HTH,
> > tim.
> >
> > > I think that a reason that app servers don't let you do that is due to how
> > > they implement
> > > propagating security contexts, "java:comp/env", etc etc. Maybe I am wrong.
> > > It also depends on what references you are dealing with.
> > >
> > > Dion
> > >
> > > -----Original Message-----
> > > From: A mailing list for Enterprise JavaBeans development
> > > [mailto:[EMAIL PROTECTED]]On Behalf Of Maliyackel, Anup Kumar
> > > (CTS)
> > > Sent: Thursday, February 15, 2001 9:39 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: LDAP with EJB
> > >
> > >
> > > Hi all
> > >
> > > Can I use an LDAP directory to store EJB references instead of the
> > > proprietory naming services of the app servers?
> > >
> > > How do I do this?
> > >
> > > Regards
> > > Anup
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
