How it will differ from [1]? IncludeTransformer was added recently exactly to address this problem with CIncludeTransformer. See also bug #30356.
Vadim
[1] http://svn.apache.org/repos/asf/cocoon/trunk/src/blocks/scratchpad/ java/org/apache/cocoon/transformation/IncludeTransformer.java
Well, at a first glance, I'd say that the IncludeTransformer is breaking up quite a lot of rules regarding caching...
getKey always returns "IncludeTransformer" which I don't know exactly what kind of behaviour might trigger in the backend cache implementation (I'm not saying "it doesn't work", I'm saying it _might_ not work).
If I have a pipeline like the following:
<map:pipeline>
<map:match pattern="*"/>
<map:generate src="{1}.xml"/>
<map:transform type="include"/>
<map:serialize/>
</map:match>
</map:pipeline>When I do a request for "foo" the key for the cache validity produced by the generator will be "file://foo.xml" (for example), if I request "bar" it'll be "file://bar.xml"...
The transformer always returns "IncludeTransformer", no question asked...
So, maybe with the current cache implementation it works, but from what I can see from the API docs, there might be a lot of cases in which you're going to get some pretty weird behaviors out of it, especially when your cache grows _a_lot_ (we have a diversity in URLs alone of approximately 150.000 entries, without counting the internal URLs, cocoon:/....) and you need to start relaying on disk to serialize/de-serialize caches and validities.
Pier
smime.p7s
Description: S/MIME cryptographic signature
