tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Klaus>
Subject Inter-context communication
Date Wed, 06 Feb 2008 17:06:54 GMT

For a special application setup I need fast inter-context communication.
 This means in web context A I need to call methods in web context B and
I must be able to retrieve objects from there and send objects to it. It
could be done using a remoting protocol like the Spring HttpInvoker
stuff but isn't there an easier and faster solution which doesn't
serialize and unserialize the whole communication? Both contexts always
run inside the same tomcat installation so I have no need for real
remote calls.

I thought of the following solution: Define interfaces for the whole
communication between the two web contexts and then define something
like a service factory and put all this into the lib directory of tomcat
so it's present in the common class-loader which is shared between both
web contexts. Context A registers services using the global service
factory and context B can get a reference to this registered service and
then call methods on it.

In detail I have three JAR/WAR files with the following example content:

interface.jar (Goes into tomcats lib dir):
  ServiceFactory (Singleton which provides a setTestService and
  TestService (Interface which defines the test service)

  TestServiceImpl (An implementation of TestService)


When contextA.war starts up it instantiates a TestServiceImpl and passes
it to ServiceFactory.setTestService().

When TestServlet in contextB.war is called then it retrieves an instance
of the TestService interface through the ServiceFactory.getTestService()
method and then works with it.

I tested this already and it seems to work fine but I just want to ask
if this violates some classpath/security stuff in Java or Tomcat and may
break in future versions. It should be noted that contextB NEVER works
with classes which are defined in contextA (This wouldn't work because
of the different classloaders). It ALWAYS works with interfaces defined
in the global interface.jar. But the problematic part of the solution
may be that contextA works with OBJECTS which were created in contextB.

Or is there a better solution which doesn't mean using EJB or JMS or
remoting protocols or any other stuff which requires serializing and
deserializing data?

Bye, K <>
[A735 47EC D87B 1F15 C1E9 53D3 AA03 6173 A723 E391]
(Finger to get public key)

View raw message