[
https://issues.apache.org/jira/browse/COCOON-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490054
]
Alexander Klimetschek commented on COCOON-2044:
-----------------------------------------------
I am currently trying to extend the ServletServiceContext.getNamedContext() to
handle bean ids of servlets in addition to the connection names. But I will
look at the other problem as well.
Regarding my last sentence: I was talking about component contracts, ie. formal
definitions of what dependencies a component has. In the case of blocks with
servlets its about all the other servlets that are needed, thus the list of
connections. It is good from a developers point of view to open a yet unknown
block, look at the META-INF/cocoon/spring/servlet*.xml files and see all the
defined servlets and their dependencies on others. For a better tooling it
would even better if those dependencies can be read automatically - which is
the case now, since the xml files have a fixed schema. The only thing missing
is such a tooling ;-) I imagine a cocoon web application manager where you have
a list of block jars available on the internet and which can be automatically
downloaded and included in your webapp. You only need the webservice for the
download and a simple application that parses the servlet xml files, knows your
web application directory and then changes the dependencies in the Maven pom
files to include the new jar. Well, just an idea ... ;-)
> 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.
