directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Whitlock <jcscoob...@gmail.com>
Subject Re: [naming] Enable Remote JNDI Access
Date Thu, 27 Oct 2005 19:05:22 GMT
Phil,
Not without rewriting a JNDI SPI. I thought of doing that anyways though. I
like the in-memory directory provided by Naming so that would replace the
need for the RMI/LDAP backend. I just need to figure out the proper
communication/protocol to use for accessing the in-memory directory. That is
where I thought you might be able to help. I've never written a JNDI SPI so
it's new to me. I guess some sort of Socket-based daemon to handle the
request/response to/from the client/server would be an approach. Daemon
listens for connections and based on the request, sends a serialized object
to the client. Client deserializes and uses. LocalContext wouldn't use the
daemon obviously because it would have direct access to the in-memory
directory while the RemoteContext would use this client/server approach for
storing/serving objects stored in the in-memory directory on the server.
Does this make sense?

Take care,
Jeremy

On 10/27/05, Phil Steitz <phil@steitz.com> wrote:
>
> I understand and am intrigued by the idea, just stuck on the protocol
> invention bit. Any ideas on how to do this using another more lightweight
> standard protocol?
>
> -----Original Message-----
> From: Jeremy Whitlock [mailto:jcscoobyrs@gmail.com]
> Sent: Thu 10/27/2005 10:30 AM
> To: Apache Directory Developers List
> Cc:
> Subject: Re: [naming] Enable Remote JNDI Access
>
>
> Phil,
> 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,
> Jeremy
>
>
> On 10/27/05, Phil Steitz <phil@steitz.com> 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
>
>
>
>
>
>

Mime
View raw message