[jira] Assigned: (COCOON-2044) servlet: protocol URIs have to be globally unique for use as cache-keys

2009-04-27 Thread Grzegorz Kossakowski (JIRA)

 [ 
https://issues.apache.org/jira/browse/COCOON-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Grzegorz Kossakowski reassigned COCOON-2044:


Assignee: (was: Grzegorz Kossakowski)

I don't plan to work on this issue in foreseeable future so I leave it 
unassigned.

 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
Reporter: Alexander Klimetschek
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.



[jira] Assigned: (COCOON-2044) servlet: protocol URIs have to be globally unique for use as cache-keys

2007-04-18 Thread Grzegorz Kossakowski (JIRA)

 [ 
https://issues.apache.org/jira/browse/COCOON-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Grzegorz Kossakowski reassigned COCOON-2044:


Assignee: Grzegorz Kossakowski

 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.