You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Francesco Chicchiriccò (JIRA)" <ji...@apache.org> on 2012/09/26 10:10:08 UTC
[jira] [Created] (COCOON3-107) With latest cocoon-block-deployment
and cocoon-service-impl SNAPSHOTs, integration tests fail
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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: blockcontext protocol (part 2) (was Re: [jira] [Created] (COCOON3-107)
...)
Posted by Thorsten Scherler <sc...@gmail.com>.
On 09/28/2012 02:41 PM, Jos Snellings wrote:
> 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
> ?
Actually since you brought up cocoon:// protocol I think one possible
solution is DROP the blockcontext protocol and force to expose all
static matches via the sitemap. This way the calling instance would need
to use the servlet protocol and there should no problem any more.
Not sure whether you remember the context:/ in c2.1.x which simply
pointed to the underlying serlvet context path. The blockcontext is
based on the same idea. You can reach the path where the actually block
is deployed (within the calling servlet is to say). However as I see it
the only real need to know that path is when we deploy the blocks (where
francesco path works), meaning if we do not use it otherwise the issue
is fixed.
> 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.
>
Well if they are both c3 based that is ATM broken and I agree that this
is an important issue since it renders c3 useless if we not fix it.
salu2
> Kind regards,
> Jos
>
> On Fri, Sep 28, 2012 at 2:29 PM, Thorsten Scherler <scherler@gmail.com
> <ma...@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 <http://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
>> <scherler@gmail.com <ma...@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
>> <http://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 <http://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/
Re: blockcontext protocol (part 2) (was Re: [jira] [Created]
(COCOON3-107) ...)
Posted by Jos Snellings <jo...@upperware.biz>.
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 <sc...@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 <sc...@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
Re: blockcontext protocol (part 2) (was Re: [jira] [Created] (COCOON3-107)
...)
Posted by Thorsten Scherler <sc...@gmail.com>.
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 <scherler@gmail.com
> <ma...@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
> <http://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/
Re: blockcontext protocol (part 2) (was Re: [jira] [Created]
(COCOON3-107) ...)
Posted by Jos Snellings <jo...@upperware.biz>.
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
So now, in C3, we want to address resources cross-block to accomplish
modularity, right?
<map:generate src="{someBlock}://{relative-url}"/>
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.
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.
Cheers,
Jos
On Wed, Sep 26, 2012 at 3:05 PM, Thorsten Scherler <sc...@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<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
blockcontext protocol (part 2) (was Re: [jira] [Created] (COCOON3-107)
...)
Posted by Thorsten Scherler <sc...@gmail.com>.
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/
[jira] [Commented] (COCOON3-107) With latest
cocoon-block-deployment and cocoon-service-impl SNAPSHOTs, integration
tests fail
Posted by "Thorsten Scherler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON3-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482880#comment-13482880 ]
Thorsten Scherler commented on COCOON3-107:
-------------------------------------------
add <bean name="expression-language:blockcontext" class="org.apache.cocoon.sitemap.expression.BlockcontextInterpreter" /> to your app context then use it in your sitemap as {blockcontext:raw-to-internal.xsl} where raw-to-internal.xsl would be resolved against the current blockservice file uri.
> 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
>
> Attachments: BlockcontextInterpreter.java
>
>
> This is happening as a consequence of COCOON3-105, by upgrading cocoon-servlet-service-impl to 1.3.2-SNAPSHOT and cocoon-block-deployment to 1.2.2-SNAPSHOT
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COCOON3-107) With latest cocoon-block-deployment
and cocoon-service-impl SNAPSHOTs, integration tests fail
Posted by "Thorsten Scherler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON3-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thorsten Scherler updated COCOON3-107:
--------------------------------------
Attachment: BlockcontextInterpreter.java
Slimed down version - without client deps ;)
> 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
>
> Attachments: BlockcontextInterpreter.java, BlockcontextInterpreter.java
>
>
> This is happening as a consequence of COCOON3-105, by upgrading cocoon-servlet-service-impl to 1.3.2-SNAPSHOT and cocoon-block-deployment to 1.2.2-SNAPSHOT
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COCOON3-107) With latest cocoon-block-deployment
and cocoon-service-impl SNAPSHOTs, integration tests fail
Posted by "Francesco Chicchiriccò (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON3-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Francesco Chicchiriccò updated COCOON3-107:
-------------------------------------------
Description:
This is happening as a consequence of COCOON3-105, by upgrading cocoon-servlet-service-impl to 1.3.2-SNAPSHOT and cocoon-block-deployment to 1.2.2-SNAPSHOT
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.
was:
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.
> 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, by upgrading cocoon-servlet-service-impl to 1.3.2-SNAPSHOT and cocoon-block-deployment to 1.2.2-SNAPSHOT
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COCOON3-107) With latest cocoon-block-deployment
and cocoon-service-impl SNAPSHOTs, integration tests fail
Posted by "Thorsten Scherler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON3-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thorsten Scherler updated COCOON3-107:
--------------------------------------
Attachment: BlockcontextInterpreter.java
interpreter to resolve blockcontext against actual file system
> 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
>
> Attachments: BlockcontextInterpreter.java
>
>
> This is happening as a consequence of COCOON3-105, by upgrading cocoon-servlet-service-impl to 1.3.2-SNAPSHOT and cocoon-block-deployment to 1.2.2-SNAPSHOT
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (COCOON3-107) With latest cocoon-block-deployment
and cocoon-service-impl SNAPSHOTs, integration tests fail
Posted by "Francesco Chicchiriccò (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON3-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Francesco Chicchiriccò closed COCOON3-107.
------------------------------------------
Resolution: Invalid
This issue is generated by an incorrect fix for COCOON3-105 that I am about to revert.
> 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
>
> Attachments: BlockcontextInterpreter.java, BlockcontextInterpreter.java
>
>
> This is happening as a consequence of COCOON3-105, by upgrading cocoon-servlet-service-impl to 1.3.2-SNAPSHOT and cocoon-block-deployment to 1.2.2-SNAPSHOT
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira