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/