[
https://issues.apache.org/jira/browse/COCOON-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490040
]
Grzegorz Kossakowski commented on COCOON-2044:
----------------------------------------------
It's even more weird. I remember that I've seen code of Cocoon's source
resolver that is used by XSLT processor. There was some kind of weird(?)
fall-back mechanism that seemed to work that way:
1. Standard Cocoon/Excalibur source resolver is tried to resolve the source, if
it is successful source is returned
2. If it fails with Cocoon/Excalibur source resolver, it passes the URI to the
standard Java URI handling.
3. Of course, Java does not know "servlet:" so throws the exception you
mentioned.
If I'm not wrong, the issue is on Excalibur/Cocoon side not XSLT processor and
we should fix it. If you want to find the class that is used to resolve URIs in
XSLs files just put servlet: URI into xsl file and put a breakpoint in
ServletSourceFactory. Then you should be able to check call stack to figure out
the class that tries to use servlet: source. It would be great if you could
check the actual behavior of that class.
> If this is the case, we need a globally unique
> servlet:servlet-bean-id:/foo/bar URL that can be resolved by the
> ServletSourceFactory. Currently it can only handle
> connections defined in the servlet bean xml. IMHO these are shortcuts (using
> servlet:myblock: is much shorter than
> serlvet:com.mycompany.mypackage.foobar-servlet). But they also work as a
> contract for the block or servlet, showing which other blocks are needed at
> runtime,
> although this is not used by any tool, its only an information for the
> developer looking at the xml file.
You are right, that they are just shortcuts. However, I do not understand what
you mean at the end.
> servlet: protocol URIs have to be globally unique for use as cache-keys
> -----------------------------------------------------------------------
>
> Key: COCOON-2044
> URL: https://issues.apache.org/jira/browse/COCOON-2044
> Project: Cocoon
> Issue Type: Bug
> Components: - Servlet service framework
> Affects Versions: 2.2-dev (Current SVN)
> Reporter: Alexander Klimetschek
> Assigned To: Grzegorz Kossakowski
> Priority: Critical
>
> All servlet protocol URIs like servlet:/some/thing or servlet:super:/foo/bar
> or servlet:myblock:/another/path have to be globally unique because they are
> used in the cache, of which there is only one global with globally acting
> keys.
> There are two caches in standard Cocoon configuration (the only ones I know
> of ;-), both with a different key generation. Here are ideas how to make the
> keys global:
> a) EHDefaultStore for caching resources of caching pipelines: they use the
> uriPrefix of the Enviroment in the key, so providing a uriPrefix (eg. the
> mount path of the servlet) works here.
> b) DefaultTransientStore which caches XSLT and JX generator sources (don't
> know why this is different from a)): they do not use the uriPrefix and much
> worse, they need correct URIs because they are read by the XSLT processor,
> who does not like things like servlet:uniqueID34:/xsl/stylesheet.xsl
> containing arbitrary schemes at the beginning. Appending an ID via a query
> parameter seems the only working solution (tried it already):
> servlet:/xsl/stylesheet.xsl?servlet-services-id=12345
> Another solution would be to have one cache per sitemap, so that the keys
> don't have to be unique anymore. But I don't know how to configure that and
> if this is feasible.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
