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/
