Kind regards,
Jos
On Fri, Sep 28, 2012 at 2:29 PM, Thorsten Scherler <scher...@gmail.com
<mailto: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 <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
<scher...@gmail.com <mailto: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
<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
