On 18/09/2012 23:57, Thorsten Scherler wrote:
Hi all,
I am working on COCOON3-105 whenever I find a sec, but I am thinking
about the underlying problem for a while now.
Hi Thorsten,
I don't know how much useful can be my contribution in this field,
anyway here are my 2 cents.
To resume, the blockcontext:/ is being registered as an extension to
java.net.URLConnection. In case of a not-known protocol we will create
the StreamHandler (who is responsible to open the urlConnection) once
- for the whole container!
Ok, this is clear: purpose of URLStreamHandlerFactory is to register the
handler for all URLs across the JVM, hence the "whole container" as you say.
This happens in the BlockContextURLStreamHandlerFactory in the method
createURLStreamHandler(String protocol). Like said: only once (!) we
call this method even if we have two different servlets using
different blockcontext. This finally leads to that the
BlockContextURLConnection only knows the blockcontext of the first
requested blockcontext and ignores any others.
Some possible solution I see:
- move the resolving of the blockcontext into the
BlockContextURLConnection. I tried that in the patch I attached to the
issue but the problem is that the second request has no ServletContext
associated to it so we cannot get the blocks. -> since we cannot
resolve here the blockcontext this solution does not work
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.
- use a global blockcontext map. A reference to a global blockcontext
map will be kept and this map needs to be merged when a new app is
deployed (if needed). However that leads to many open issue like
security, version, etc.
I don't see this as viable option anyway.
Further how do you undeploy the protocol since undeploying the
underlying servlet would need to undeploy only a part of the
blockcontext protocol.
I am not sure how to overcome above obstacles and would love any
thoughts from the community.
Regards.
[1]
http://blog.jdevelop.eu/2008/07/06/access-the-spring-applicationcontext-from-everywhere-in-your-application/
--
Francesco Chicchiriccò
ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member
http://people.apache.org/~ilgrosso/
