cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Grzegorz Kossakowski (JIRA)" <j...@apache.org>
Subject [jira] Commented: (COCOON-2044) servlet: protocol URIs have to be globally unique for use as cache-keys
Date Thu, 19 Apr 2007 13:14:15 GMT

    [ 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.


Mime
View raw message