tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: Inter-context communication
Date Wed, 06 Feb 2008 17:34:59 GMT
why don't you just create a singleton object, and stuff it in 
common/lib(5.5) or lib(6.0)
and any web app can access it


Klaus Reimer wrote:
> Hello,
> 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
> getTestService)
>   TestService (Interface which defines the test service)
> contextA.war:
>   TestServiceImpl (An implementation of TestService)
> contextB.war:
>   TestServlet
> 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?

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message