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
Filip
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: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
