avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject JNDI blues.
Date Sat, 12 Oct 2002 21:46:08 GMT
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:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message