Return-Path: Delivered-To: apmail-cxf-dev-archive@www.apache.org Received: (qmail 1361 invoked from network); 28 Sep 2010 11:26:58 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 28 Sep 2010 11:26:58 -0000 Received: (qmail 83046 invoked by uid 500); 28 Sep 2010 11:26:58 -0000 Delivered-To: apmail-cxf-dev-archive@cxf.apache.org Received: (qmail 82749 invoked by uid 500); 28 Sep 2010 11:26:55 -0000 Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cxf.apache.org Delivered-To: mailing list dev@cxf.apache.org Received: (qmail 82737 invoked by uid 99); 28 Sep 2010 11:26:53 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Sep 2010 11:26:53 +0000 X-ASF-Spam-Status: No, hits=-5.0 required=10.0 tests=RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of asoldano@redhat.com designates 209.132.183.28 as permitted sender) Received: from [209.132.183.28] (HELO mx1.redhat.com) (209.132.183.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Sep 2010 11:26:47 +0000 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o8SBQQ7K016777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 28 Sep 2010 07:26:26 -0400 Received: from [10.36.10.183] (vpn2-10-183.ams2.redhat.com [10.36.10.183]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o8SBQO48003710; Tue, 28 Sep 2010 07:26:25 -0400 Message-ID: <4CA1D0E0.7080408@redhat.com> Date: Tue, 28 Sep 2010 13:26:24 +0200 From: Alessio Soldano User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.7) Gecko/20100720 Fedora/3.1.1-1.fc13 Thunderbird/3.1.1 MIME-Version: 1.0 To: Daniel Kulp CC: dev@cxf.apache.org, Andrew Dinn Subject: Re: WS-Addressing asynch MEP, CXF-2167 and WSTF tests References: <4C9CC717.20705@redhat.com> <201009241458.32789.dkulp@apache.org> <4CA0590F.4050105@redhat.com> <201009271425.13123.dkulp@apache.org> In-Reply-To: <201009271425.13123.dkulp@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.16 Hi Dan, On 09/27/2010 08:25 PM, Daniel Kulp wrote: > Hmm..... I wonder if we can tackle some of these things kind of piece meal, > in steps: > > 1) Scenario one is a single Bus, but multiple MAPCodec's. This should be > fairly easy. If the MAPCodec stores it's storage map as a property on the > Bus, then multple MAPCodecs could share the storage and the problem would be > solved for this usecase, right? Right > 2) Scenario two is a single JVM/classlaoder with multiple bus's. This is > similar to (1), but the storage could be pre-configured and shareable. Yes. Btw this is more or less the scenario we're on right now, as we could have this storage as a shared facility provided by CXF libraries which can be seen by all apps using them. > 3) Scenario three would be multiple apps/jvms/classloader. This is trickier. > One solution would be to allow configuring in a distrubted map implementation > for the storage. Yes, this is indeed trickier... and would deal with client and final response endpoint running on different jvm/classloader. IOW what you're suggesting here is that this might basically be a matter of having the user configure the storage with the scope/visibility he needs, right? Thanks Alessio -- Alessio Soldano Web Service Lead, JBoss