Folks, I need some advice on JNDI (or other). I'll explain the background first :
An AltRMI client can do open a connection to a host:port or an AltRMI server and start invoking method requests (transparently) on those remote objects. It may be that the resource is sourced from the same JVM. If it is, it might be better if the AltRMI client factories created a local (piped) connection to that resource rather than using the slower one using sockets. If the thing could lookup some sort registry of 'in-machine' hosted services, determine this is the same virtual machine, then an optmization could occur. The problem is that the scenario that is most useful for this, is one where IoC does not rule -> servlets in WAR files in Servlet containers. The servlet spec says that the only classes that should be visible to a classloader hosting a servlet should be those from J2SE and those that support the servlet API. All others should be hidden, using decent implementation hiding techniques. That is apart from those you might include with inside the WAR file. One could image that mounting a singleton registry somewhere higher up the classloader tree that was mutually visible to both would be suitable. This would break that class-visibility directive though.... :-( Thus if I need to have a registry of sorts to cross reference factory instances against say port names they are hosted from, it would have to be JNDI. The trouble is that JNDI really likes to store serialized objects. That is no good in that I need real instances being stored. A sort of active bridge between two entirely separate classloaders. My problem is that I cannot see a decent example from Sun that allows instance storage (or alleges to) that does not involve a LDAP server running somewhere. Advice? Regards, - Paul -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
