From dev-return-103894-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Wed Sep 19 13:18:30 2012 Return-Path: X-Original-To: apmail-cocoon-dev-archive@www.apache.org Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9E446DF26 for ; Wed, 19 Sep 2012 13:18:30 +0000 (UTC) Received: (qmail 54914 invoked by uid 500); 19 Sep 2012 13:18:28 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 54469 invoked by uid 500); 19 Sep 2012 13:18:21 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 54407 invoked by uid 99); 19 Sep 2012 13:18:18 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Sep 2012 13:18:18 +0000 X-ASF-Spam-Status: No, hits=2.9 required=5.0 tests=HTML_MESSAGE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [78.134.5.44] (HELO rovere.tirasa.net) (78.134.5.44) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Sep 2012 13:18:13 +0000 Received: from localhost (localhost [127.0.0.1]) by rovere.tirasa.net (Postfix) with ESMTP id 9E2EE1863A3 for ; Wed, 19 Sep 2012 15:17:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at tirasa.net Received: from rovere.tirasa.net ([127.0.0.1]) by localhost (rovere.tirasa.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEjbecLmTNxV for ; Wed, 19 Sep 2012 15:17:43 +0200 (CEST) Received: from [192.168.0.2] (mogano.tirasa.net [192.168.0.2]) by rovere.tirasa.net (Postfix) with ESMTPSA id 9D4EC1863A1 for ; Wed, 19 Sep 2012 15:17:43 +0200 (CEST) Message-ID: <5059C5F7.6010208@apache.org> Date: Wed, 19 Sep 2012 15:17:43 +0200 From: =?ISO-8859-1?Q?Francesco_Chicchiricc=F2?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: BlockContextURLConnection is not context safe References: <5058EE49.3050707@gmail.com> <505970EE.7070709@apache.org> In-Reply-To: <505970EE.7070709@apache.org> Content-Type: multipart/alternative; boundary="------------000906030603030804050300" X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. --------------000906030603030804050300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 19/09/2012 09:14, Francesco Chicchiriccò wrote: > [...] > Indeed, I think this is the route to follow, i.e. move the > blockContexts Map in a place bound to app scope, not to JVM scope > (like as BlockContextURLStreamHandlerFactory). > > What if you get to the servletContext not via > > ServletContext servletContext = > CallStackHelper.getCurrentServletContext(); > > but instead, using an approach like as [1]: > > WebApplicationContext webApplicationContext = > (WebApplicationContext) AppContext.getApplicationContext(); > ServletContext servletContext = > webApplicationContext.getServletContext(); > this.blockContexts = (Map) servletContext > .getAttribute(BlockDeploymentServletContextListener.BLOCK_CONTEXT_MAP); > > i.e. closer to the current implementation inside > BlockContextURLStreamHandlerFactory? > > As soon as I have enough spare time for this, I'll try to play anyway > with this issue. FYI, this approach is not working either, because since BlockContextURLStreamHandlerFactory is executed once per JVM, the AppContext is stuck with that execution either. No way. Anyway, what if we try to use cocoon-jnet [2] for handling blockcontext:// ? AFAIK it is only used for servlet:// ATM. Regards. > [1] > http://blog.jdevelop.eu/2008/07/06/access-the-spring-applicationcontext-from-everywhere-in-your-application/ [2] http://cocoon.apache.org/subprojects/jnet/ -- Francesco Chicchiriccò ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/ --------------000906030603030804050300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 19/09/2012 09:14, Francesco Chicchiriccò wrote:
[...]
Indeed, I think this is the route to follow, i.e. move the blockContexts Map in a place bound to app scope, not to JVM scope (like as BlockContextURLStreamHandlerFactory).

What if you get to the servletContext not via

ServletContext servletContext = CallStackHelper.getCurrentServletContext();

but instead, using an approach like as [1]:

        WebApplicationContext webApplicationContext = (WebApplicationContext)  AppContext.getApplicationContext();
        ServletContext servletContext = webApplicationContext.getServletContext();
        this.blockContexts = (Map<String, String>) servletContext
                .getAttribute(BlockDeploymentServletContextListener.BLOCK_CONTEXT_MAP);

i.e. closer to the current implementation inside BlockContextURLStreamHandlerFactory?

As soon as I have enough spare time for this, I'll try to play anyway with this issue.

FYI,
this approach is not working either, because since BlockContextURLStreamHandlerFactory is executed once per JVM, the AppContext is stuck with that execution either. No way.

Anyway, what if we try to use cocoon-jnet [2] for handling blockcontext:// ? AFAIK it is only used for servlet:// ATM.

Regards.

[1] http://blog.jdevelop.eu/2008/07/06/access-the-spring-applicationcontext-from-everywhere-in-your-application/
[2] http://cocoon.apache.org/subprojects/jnet/
-- 
Francesco Chicchiriccò

ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member
http://people.apache.org/~ilgrosso/
--------------000906030603030804050300--