From users-return-175743-apmail-tomcat-users-archive=tomcat.apache.org@tomcat.apache.org Wed Feb 06 17:36:02 2008 Return-Path: Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: (qmail 20726 invoked from network); 6 Feb 2008 17:36:02 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 6 Feb 2008 17:36:02 -0000 Received: (qmail 6822 invoked by uid 500); 6 Feb 2008 17:35:43 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 6663 invoked by uid 500); 6 Feb 2008 17:35:43 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 6652 invoked by uid 99); 6 Feb 2008 17:35:43 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Feb 2008 09:35:43 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [72.22.94.67] (HELO virtual.halosg.com) (72.22.94.67) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Feb 2008 17:35:27 +0000 Received: (qmail 12030 invoked from network); 6 Feb 2008 11:26:51 -0600 Received: from 63-227-55-166.hlrn.qwest.net (HELO ?192.168.0.32?) (63.227.55.166) by halosg.com with SMTP; 6 Feb 2008 11:26:51 -0600 Message-ID: <47A9EFC3.8000700@hanik.com> Date: Wed, 06 Feb 2008 10:34:59 -0700 From: Filip Hanik - Dev Lists User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Tomcat Users List Subject: Re: Inter-context communication References: <47A9E92E.80100@ailis.de> In-Reply-To: <47A9E92E.80100@ailis.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org