Jeremy Whitlock wrote:
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?
Sorry for the response latency. Yes, the use case makes sense as long as the entries that you want to access remotely are all serializable. I am still resisting the idea of inventing our own protocol, though, given that either LDAP and RMI could be used. I understand that the goal would be to use the federation stuff already in [naming] to hide the protocol from the client, which is the kind of thing that federation was designed for, so I could get over this. Under the covers, we would have to handle both the server infrastructure (which we could use [mina] for, as sort of a compromise to bringing in ads) and the protocol itself. It might be a good idea to start by playing with a simple mina server that passes "jndi urls" from client to server and returns serialized objects. I will think some more about how to represent the remote contexts and operations, but my immediate reaction is just follow the ldap url spec. Patches / better ideas welcome ...
Phil
