Thanks, Thorsten, that makes it a lot clearer.
I will give it a second thought and get back.
Just another question: are there other use cases than:
- within xslt : document() construct
- sitemap
- controller->modelAndView
?
Now that we reanimated the thread, has anyone else ideas? I feel it is an
important issue and I would love to see it solved,
as I have myself two cocoon apps that I would like to deploy to one server.
Kind regards,
Jos
On Fri, Sep 28, 2012 at 2:29 PM, Thorsten Scherler <scher...@gmail.com>wrote:
> On 09/28/2012 07:24 AM, Jos Snellings wrote:
>
> Dear all,
>
> Noticing that is very interesting discussion is getting silent, I'd like
> to ask a question.
> First of all, pardon me my ignorance. (blonde, can't help it).
> So from just a high-level understanding, can I rephrase the problem?
> What we seek to accomplish is:
> * in a sitemap, being able to load resources from another sitemap,
> according to the scheme:
> <map:generate src="cocoon://{relative-url}"/>
> * within an xslt calling
> <xsl:variable name="var" select="'cocoon://{relative-url}'" />
> * within controller logic: redirect, or send the reference of a
> ModelAndView
>
>
> Well the cocoon:/ is/was never a java.net handler but resolved via
> avalon/excalibur. Further the c3 correspond would be more servlet:/
>
>
>
> So now, in C3, we want to address resources cross-block to accomplish
> modularity, right?
>
> <map:generate src="{someBlock}://{relative-url}"/>
>
>
> well yes and no. blockcontext:/ refers to static (resources) and not
> matches in the blockcontext sitemap. If you would want to call the block
> sitemap you would request servlet:${blockId}:/...
>
>
>
> This should be restricted to the instance of the cocoon servlet itself, so
> it can peacefully coexist with another cocoon servlet in the same JVM.
>
>
> The blockcontext protocol once installed only will work for the first
> called servlet. With the change of Fran. we do what you describe but on a
> specific point in the app. BUT we never install the protocol which makes it
> unusable outside the java route where you can pass a URLHandler to the
> context.
>
> So you would like to avoid tweaking "URL" for the servlet without
> interfering with the rest.
>
> - something less invasive than URL.setURLStreamHandlerFactory ?
> - mechanism that keeps track of wich cocoon servlet deployed wich blocks?
>
> Is that a correct way of stating it? Not even my 10 cents, just a question.
>
>
> If we want to keep using blockcontext protocol, the handler needs a
> central place where the different paths are resolved. However due to the
> nature of the problem we can have the same name for a block in 2 different
> servlet but if we resolve the url in the connection we will have the
> problem deciding which path to return to the caller, since it can happen
> that the underlying request has no servlet context associated meaning it is
> impossible to determine which block to use.
>
> Thanks for keeping the thread alive.
>
> salu2
>
>
>
> Cheers,
> Jos
>
>
> On Wed, Sep 26, 2012 at 3:05 PM, Thorsten Scherler <scher...@gmail.com>wrote:
>
>> 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/
>>
>>
>
>
> --
> The doctrine of human equality reposes on this: that there is no man
> really clever who has not found that he is stupid.
> -- Gilbert K. Chesterson
>
>
>
>
> --
> Thorsten Scherler <scherler.at.gmail.com>
> codeBusters S.L. - web based systems
> <consulting, training and solutions>
> http://www.codebusters.es/
>
>
--
The doctrine of human equality reposes on this: that there is no man
really clever who has not found that he is stupid.
-- Gilbert K. Chesterson
