directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Whitlock <>
Subject Re: [naming] Enable Remote JNDI Access
Date Thu, 27 Oct 2005 17:30:29 GMT
I want to use ApacheDS but it does not store binary data right now due to a
bug and its not scheduled to be fixed for a few weeks. Basically, I want to
have a lightweight directory for storing MBean/References in the directory
so that I can use JNDI to get to them easily. This approach is similar to
what Geronimo does with it's MBeans and what Weblogic does with it's MBeans.
That being said, I do know that ApacheDS is the directory used in Geronimo
so I don't know why it would work for them but not for me but that is the
information I got from #directory-dev on freenode, the same people that told
me to contact you. Ideally, I would like to have the lightweight provider in
[naming] but have it networkable. It would be nice not to have the overhead
of LDAP but I can go that route if needed. Thanks for getting back to me and
for sharing your ideas.

Take care,

On 10/27/05, Phil Steitz <> wrote:
> Jeremy Whitlock wrote:
> > Hey all,
> > I would like to use directory-naming in my application but I need
> > to enable remote access to the in-memory JNDI provided by
> > directory-naming. It would be great to have a user have a PROVIDER_URL
> > of jndi://host:port and get a reference to the JNDI provided on the
> > server by directory-naming. Can someone assist me with this?
> Why not use ldap into ADS directly? If the problem is that [naming]
> supports some things not provided by ADS (resource factories?) then it
> would make sense to do what Noel suggested some time ago, i.e., to
> integrate naming into ADS and use ldap to provide the remote access.
> Otherwise, we end up needing to invent another remote binding and
> transport protocol, which may not be the best idea.
> If what you are after is the resources, a practical issue is that these
> are mostly returned by [naming] and other JNDI providers as *references*
> to locally generated resource instances - e.g., database connection
> pools. Making use of these resources remotely requires a change in
> their programming model. Not impossible, but requires that the resource
> providers and interface specs currently supported by [naming] be
> redesigned. For things like database connection pools, manageability
> and security would be problematic.
> What is your application trying to do?
> Phil

View raw message