cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <scher...@gmail.com>
Subject blockcontext protocol (part 2) (was Re: [jira] [Created] (COCOON3-107) ...)
Date Wed, 26 Sep 2012 13:05:16 GMT
On 09/26/2012 10:10 AM, Francesco Chicchiriccò (JIRA) wrote:
> Francesco Chicchiriccò created COCOON3-107:
> ----------------------------------------------
>
>               Summary: With latest cocoon-block-deployment and cocoon-service-impl SNAPSHOTs,
integration tests fail
>                   Key: COCOON3-107
>                   URL: https://issues.apache.org/jira/browse/COCOON3-107
>               Project: Cocoon 3
>            Issue Type: Bug
>            Components: cocoon-sample-webapp, cocoon-servlet, cocoon-sitemap
>      Affects Versions: 3.0.0-beta-1
>              Reporter: Francesco Chicchiriccò
>              Priority: Critical
>               Fix For: 3.0.0-beta-1
>
>
> This is happening as a consequence of COCOON3-105.
>
> Basically, since there is no more an installed URLStreamHandlerFactory, every "new URL()"
should include an instance of BlockContextURLStreamHandler.
>
> This makes every other URL loading (including XSLT sheets in a separate block, like happening
for cocoon-sample-webapp) unaware of "blockcontext://" URLs.
>

Meaning we are back to square one.

Andreas Hartman is ATM in our office and we had a small chat about the 
underlying problem.
We think that blockcontext cannot work as protocol as it is for now.

The above report shows that we need to use a URLStreamHandlerFactory to 
be able to resolve this protocol.

{myblock2=file:/home/thorsten/src/apache/apache-tomcat-6.0.20/work/Catalina/localhost/mywebapp2-1.0-SNAPSHOT/blocks/myblock2/}

Now if we look on the above and how we defined it, we have:

in block-servlet-service.xml

<servlet:context mount-path="/${blockId}" 
context-path="blockcontext:/${blockId}/"/>

will then produce the following blockcontext object:
${blockId}=${tomcat.work}/${servlet_which uses the block}/blocks/${blockId}/

Meaning that blockcontext:/ will be resolved to 
"${tomcat.work}/${servlet_which uses the block}/blocks/"

There are various problematic parts:

As of the looks of it a block is treated as "servlet" mounted to a 
context.  Problematic is that the mount-path in some cases needs to 
become ="" to catch all incoming request, which means root context.
Blocks are treated as servlets meaning you can only mount once a block 
(in a specific version of that block). If another block use this blockId 
it is not possible to use the same mount point. However that has the 
ultimate consequence that you need to manage the name of your block 
manually or ideally the ${blockId} is unique and contains the version of 
the block!
However blocks are more servlets within a servlet, since without a 
servlet that has deps on them they would be not reachable.

This leads to to the "real" mount point "${servlet_which uses the 
block}/{@mount-path_as defined in the block}" in the servlet context and 
the path as above. For example "blockcontext:/test" could refer to  
"${tomcat.work}/${servlet1}/blocks/test" or 
"${tomcat.work}/${servlet2}/blocks/test", depending from which servlet 
the request is issued. Meaning the blockcontext protocol does not 
resolve url (Uniform (or universal) resource locator) since the 
resources it describes are not universal (due to the fixed connection to 
the underlying servlet).

With all the above said the logical consequence is that the pattern of 
blockcontext would need the ${servlet_which uses the block} in it 
somewhere, but that would render the whole block concept useless if used 
within the block. That however would force a url rewritting on the fly 
where the ${servlet_which uses the block} prefixed would be injected 
prior of resolving.

We tested to push the resolving logic into the handler but that failed 
since some calls have no resolvable servlet context while they issue the 
call. We succeed to inject the handler in the servlet context but never 
declared an UrlFactory so xsl imports e.g. are failing now since they do 
not know about our handler.

In the old days (2.1.x) we had our avalon/exaclibur source resolver for 
creating custom protocols within a specific context - with them above 
would not have been a prob.

Anyway, how can we refactor the blockcontext so we can deploy more then 
one c3 webapp? Any ideas?

salu2

-- 
Thorsten Scherler <scherler.at.gmail.com>
codeBusters S.L. - web based systems
<consulting, training and solutions>

http://www.codebusters.es/


Mime
View raw message