Re: lenya 2.0 release preparation - cocoon version dependency (2.1.11?)
Cocoon 2.1 will stay around for a while so same here! Jeroen Antonio Gallardo wrote: Bertrand Delacretaz escribió: Agree with Ralph, there's no need to close anything, if people want to fix bugs on older versions that's one of the beauties of open source: no one forces you to upgrade, as long as you're ready to fix what you're using if needed. +1 Best Regards, Antonio Gallardo.
RE: Deprecation of CInclude transformer
Hello, Grzegorz Kossakowski wrote: Could you elaborate on the known differences between CInclude and Include transformers? Was it discussed somewhere? I am not sure if it was ever discussed somewhere, but I can elaborate a little on it ( though it has been a while, so I might be a little off at some places... though understanding of this IncludeTransformer gives you a very good insight in Cocoon's caching mechanism. ). First of all, I think there are different useages of both transformers, where I must admit I never used the CInclude ( I know you can also POST with it, append parameters, etc etc ). With the includeTransformer, all you do is including a src which can use any of the defined source-factories in you cocoon.xconf, for example include:include src=cocoon://some/pipeline/ or include:include src=file://some/fs/file/ We at Hippo *always* used the IncludeTransformer, because it is way better cacheable (and blistering fast ones includedbut ofcourse, there is a very subtle catch which the author didn't realize i think...or just did not tell :-) .), as opposed to the CInclude transformer. AFAIU, the IncludeTransformer can only be cached by defining some expires. Clearly, you cannot really know how to set this, or if you fetch an external http source, just give it some heuristic value. Now, the IncludeTransformer adds the validity object of the included sources to the validity object of the calling pipeline (pfff). Let's have an example: someXML.xml : doc include:include src=cocoon://fetchSnippet/ /doc map:match pattern=main map:generate src=someXML.xml/ map:transform type=include/ map:serialize/ /map:match map:match pattern=fetchSnippet map:generate src=included.xml/ map:serialize/ /map:match included.xml : includethis/ So, when calling /main, I will get doc includethis /doc and the validity object of the fetchSnippet pipeline is added to the validity of the main pipeline. So, the second call for /main, does the setup for the main pipeline, and computes a cachekeyand finds a hit in the cache with a valid cached object, thus returns the cached result. NOTE: the second pipeline is never used in the second call. Not even the setup! Suppose I change now the second matcher the src from included.xml to included2.xml, and call /main againWell, my cachekey of the first pipeline is unchanged, as well as the validity object (the validity object is with respect to included.xml which did *not* change). So, I still get the same cached result. Now, when I open included.xml, change something and save, then the validity obj of the first pipe is invalid, so the result is re-computed, fetching included2.xml!! Also, if the second pipeline /fetchSnippet start with a map:select first, the things are getting even complexer (the little catch)if somebody wants to know about it I can elaborate. Anyway, why use the IncludeTransformer if you have this 'strange' behaviorWell, it is just way much faster than the CIncludeTransformer, so if you have pipelines with 10-20 includes (which we have in some projects) I want a cached result withing a couplt of ms. Do realize, that setting up a pipeline, compute the compound cachekey of a generators and transformers, check the cache, check the validity object, do take time, which you do not have with the includetransformer (it only returns the validity obj). OTOH, it really only makes sense to use it when you have a lot of traffic, or when pages have to load fast. Hope things are a little clear. Sorry I cannot say to much about the CIncludeTransformer...I just do not know enough about it. I just know it is much slower (I just looked at the code and see it uses a cachingSession with an expires...i do not like it that much i think, though it can be used for much more than the IncludeTransformer) Regards Ard BTW. I forgot to say that I would like to deprecate CInclude in 2.2 only. -- Grzegorz Kossakowski
RE: Deprecation of CInclude transformer
AFAIU, the IncludeTransformer can only be cached by defining some Above is ofcourse a typo...I was talking about the CIncludeTransformer which can only be cached by some expires... expires. Clearly, you cannot really know how to set this, or if you fetch an external http source, just give it some heuristic value.
Re: Deprecation of CInclude transformer
Ard Schrijvers wrote: snip/ Now, the IncludeTransformer adds the validity object of the included sources to the validity object of the calling pipeline (pfff). Let's have an example: someXML.xml : doc include:include src=cocoon://fetchSnippet/ /doc map:match pattern=main map:generate src=someXML.xml/ map:transform type=include/ map:serialize/ /map:match map:match pattern=fetchSnippet map:generate src=included.xml/ map:serialize/ /map:match included.xml : includethis/ So, when calling /main, I will get doc includethis /doc and the validity object of the fetchSnippet pipeline is added to the validity of the main pipeline. So, the second call for /main, does the setup for the main pipeline, and computes a cachekeyand finds a hit in the cache with a valid cached object, thus returns the cached result. NOTE: the second pipeline is never used in the second call. Not even the setup! Suppose I change now the second matcher the src from included.xml to included2.xml, and call /main againWell, my cachekey of the first pipeline is unchanged, as well as the validity object (the validity object is with respect to included.xml which did *not* change). So, I still get the same cached result. Now, when I open included.xml, change something and save, then the validity obj of the first pipe is invalid, so the result is re-computed, fetching included2.xml!! Indeed. I think this is a failure on CocoonSource part. CocoonSource content depends on the sitemap.xmap, but CocoonSource validity does not include validity of the sitemap. As a result, even if sitemap is changed, CocoonSource validity stays valid. I'm not sure though if I want to have this bug fixed - it would add more overhead... Also, if the second pipeline /fetchSnippet start with a map:select first, the things are getting even complexer (the little catch)if somebody wants to know about it I can elaborate. Fire away! ;-) Anyway, why use the IncludeTransformer if you have this 'strange' behaviorWell, it is just way much faster than the CIncludeTransformer, so if you have pipelines with 10-20 includes (which we have in some projects) I want a cached result withing a couplt of ms. Do realize, that setting up a pipeline, compute the compound cachekey of a generators and transformers, check the cache, check the validity object, do take time, which you do not have with the includetransformer (it only returns the validity obj). OTOH, it really only makes sense to use it when you have a lot of traffic, or when pages have to load fast. BTW IncludeTransformer operation can not be changed easily. If you try to resolve each included URI, to check its new key and validity, you'd also have to parse (or store somewhere!) included parts in order to resolve nested includes - if recursive inclusion is switched on. Hope things are a little clear. Sorry I cannot say to much about the CIncludeTransformer...I just do not know enough about it. I just know it is much slower (I just looked at the code and see it uses a cachingSession with an expires...i do not like it that much i think, though it can be used for much more than the IncludeTransformer) IMHO POSTing stuff to a source does not really belong to a include transformer, but rather to some other type of transformer... Vadim Regards Ard BTW. I forgot to say that I would like to deprecate CInclude in 2.2 only. -- Grzegorz Kossakowski
RE: Deprecation of CInclude transformer
Vadim Gritsenko wrote:
Indeed. I think this is a failure on CocoonSource part.
CocoonSource content depends on the sitemap.xmap, but
CocoonSource validity does not include validity of the
sitemap. As a result, even if sitemap is changed,
CocoonSource validity stays valid.
I'm not sure though if I want to have this bug fixed - it
would add more overhead...
Don't think either it is worth the trouble. You can work years with it
without ever noticing, it is only happening during development when you
happen to change something in a way described above (which will hardly
ever happen)
Also, if the second pipeline /fetchSnippet start with a map:select
first, the things are getting even complexer (the little
catch)if
somebody wants to know about it I can elaborate.
Fire away! ;-)
Okay, you asked for it :-)
Suppose I have an include :
include:include src=cocoon://fetchSnippet/
and I have a pipeline :
map:selectors default=parameter
map:selector name=simple
src=org.apache.cocoon.selection.SimpleSelector/
/map:selectors
map:match pattern=fetchSnippet
map:select type=simple
map:parameter name=value
value={request-param:strange}/
map:when test=true
map:generate src=test1.xml/
/map:when
map:otherwise
map:generate src=test2.xml/
/map:otherwise
/map:select
map:serialize type=xml/
/map:match
Now, when your first call is for example : /main?strange=true
and the main pipeline is again
map:match pattern=main
map:generate src=someXML.xml/
map:transform type=include/
map:serialize/
/map:match
You will have included test1.xml, since {request-param:strange}
evaluates to 'true'. Now, calling
/main?strange=false will *not* give you test2.xml as the include,
because, the main pipeline was perfectly cacheable, the 'stange'
parameter was not included in its cachekey and the validity object is
valid since no src whatsoever changed. Touching again test1.xml and
calling again returns you test2.xml. Calling /main?strange=true
afterwards gives you again test2.xml.
You might consider it undesirable/incorrect behavior, but I just learned
to use see the include transformer as if you add some pipeline parts
from another pipe in your pipeline. So, if you have an include involving
a map:select, you might see as if you were adding the pipe parts which
are resolved by the map:select.
Also, the times I had to deal with this are few, but, OTOH, when I got
the pleasure of debugging externally developed websites with a main
sitemap of 4.000 lines, and this was actually one of the problems, you
can imagine how hard it is to find! :-)
BTW IncludeTransformer operation can not be changed easily.
If you try to resolve each included URI, to check its new key
and validity, you'd also have to parse (or store somewhere!)
included parts in order to resolve nested includes - if
recursive inclusion is switched on.
Yes indeed. We certainly do not want that! It is working really fine
ATM, but if you encounter one of the exceptional examples I
describedwell, then you either have to learn about cocoon caching,
or put you pipelines to noncaching :-)
IMHO POSTing stuff to a source does not really belong to a
include transformer, but rather to some other type of transformer...
A PostTransformer :-)
Ard
Vadim
Upgrade to Spring 2.5
Since I've been running successfully two of my custom Cocoon 2.2 apps with
Spring 2.5-rc2
(http://opensource.atlassian.com/projects/spring/browse/SPR-4081), I upgraded
trunk to use Spring 2.5. Since it is aimed to be a drop-in replacement for
2.0.x, I don't expect problems. Doing the upgrade now gives us some time until
we release Cocoon 2.2 final which is scheduled for the end of the year.
Now we can also think about merging Daniel's work on OSGi (whiteboard), which
requires Spring-OSGi, with trunk. Daniel, maybe you can share your thoughts on
what this would mean for trunk (build system, required code changes, etc.) and
how we can keep the experimental OSGi stuff out of our releases.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
[jira] Subscription: COCOON-open-with-patch
Issue Subscription Filter: COCOON-open-with-patch (107 issues) Subscriber: cocoon Key Summary COCOON-2137 XSD Schemas for CForms Development https://issues.apache.org/jira/browse/COCOON-2137 COCOON-2133 Addition of allow-enlarge parameter to ImageOp resize operation https://issues.apache.org/jira/browse/COCOON-2133 COCOON-2114 fix sorting in TraversableGenerator https://issues.apache.org/jira/browse/COCOON-2114 COCOON-2109 Incorrent cleanup of expired continuations https://issues.apache.org/jira/browse/COCOON-2109 COCOON-2104 [PATCH] Add base URI fixup support to XIncludeTransformer https://issues.apache.org/jira/browse/COCOON-2104 COCOON-2100 Retrieving mimeType returned by pipeline executed from Flow https://issues.apache.org/jira/browse/COCOON-2100 COCOON-2074 Build ignores custom applications https://issues.apache.org/jira/browse/COCOON-2074 COCOON-2071 Option to turn off pooling for components (probably faster on new JVMs and simpler debugging) https://issues.apache.org/jira/browse/COCOON-2071 COCOON-2065 huge performance increase of LuceneIndexTransformer on large Lucene indexes https://issues.apache.org/jira/browse/COCOON-2065 COCOON-2063 NekoHTMLTransformer needs to set the default-encoding of the current system to work properly with UTF-8 https://issues.apache.org/jira/browse/COCOON-2063 COCOON-2052 Allow Ajax submission of forms with empty upload field https://issues.apache.org/jira/browse/COCOON-2052 COCOON-2048 ImageOp: overlay a transparent image on another one https://issues.apache.org/jira/browse/COCOON-2048 COCOON-2041 WebDAV Returns improper status on PUT https://issues.apache.org/jira/browse/COCOON-2041 COCOON-2040 Union widget does not work with booleanfield set as case widget https://issues.apache.org/jira/browse/COCOON-2040 COCOON-2037 New DynamicGroup widget https://issues.apache.org/jira/browse/COCOON-2037 COCOON-2035 NPE in the sorter of the EnhancedRepeater https://issues.apache.org/jira/browse/COCOON-2035 COCOON-2032 [PATCH] Sort order in paginated repeater https://issues.apache.org/jira/browse/COCOON-2032 COCOON-2030 submit-on-change doesn't work for a multivaluefield with list-type=checkbox https://issues.apache.org/jira/browse/COCOON-2030 COCOON-2018 Use thread context class loader to load custom binding classes https://issues.apache.org/jira/browse/COCOON-2018 COCOON-2017 More output beautification options for serializers https://issues.apache.org/jira/browse/COCOON-2017 COCOON-2015 Doctype added twice because root element (html) is inlined https://issues.apache.org/jira/browse/COCOON-2015 COCOON-2002 HTML transformer only works with latin-1 characters https://issues.apache.org/jira/browse/COCOON-2002 COCOON-1985 AbstractCachingProcessingPipeline locking with IncludeTransformer may hang pipeline https://issues.apache.org/jira/browse/COCOON-1985 COCOON-1974 Donating ContextAttributeInputModule https://issues.apache.org/jira/browse/COCOON-1974 COCOON-1973 CaptchaValidator: allow case-insensitive matching https://issues.apache.org/jira/browse/COCOON-1973 COCOON-1964 Redirects inside a block called via the blocks protocol fail https://issues.apache.org/jira/browse/COCOON-1964 COCOON-1963 Add a redirect action to the browser update handler https://issues.apache.org/jira/browse/COCOON-1963 COCOON-1960 Pipeline errors for generator/reader already set should provide more information https://issues.apache.org/jira/browse/COCOON-1960 COCOON-1949 [PATCH] load flowscript from file into specified Rhino context object https://issues.apache.org/jira/browse/COCOON-1949 COCOON-1946 [PATCH] - Javaflow Sample errors trying to enhance Javaflow classes and showing cform templates https://issues.apache.org/jira/browse/COCOON-1946 COCOON-1943 [Patch] Parameters in blocks-protocol URIs get decoded too early https://issues.apache.org/jira/browse/COCOON-1943 COCOON-1932 [PATCH] correct styling of disabled suggestion lists https://issues.apache.org/jira/browse/COCOON-1932 COCOON-1929 [PATCH] Reloading classloader in Cocoon 2.2 https://issues.apache.org/jira/browse/COCOON-1929 COCOON-1917 Request Encoding problem: multipart/form vs. url encoded https://issues.apache.org/jira/browse/COCOON-1917 COCOON-1915 Nullable value with additional String or XMLizable in JavaSelectionList https://issues.apache.org/jira/browse/COCOON-1915 COCOON-1914 Text as XMLizable in EmptySelectionList https://issues.apache.org/jira/browse/COCOON-1914 COCOON-1899 [PATCH] Cocoon XML:DB Implementation should not depend on Xindice
Re: Upgrade to Spring 2.5
Reinhard Poetz skrev: Since I've been running successfully two of my custom Cocoon 2.2 apps with Spring 2.5-rc2 (http://opensource.atlassian.com/projects/spring/browse/SPR-4081), I upgraded trunk to use Spring 2.5. Since it is aimed to be a drop-in replacement for 2.0.x, I don't expect problems. Doing the upgrade now gives us some time until we release Cocoon 2.2 final which is scheduled for the end of the year. Great! Now we can also think about merging Daniel's work on OSGi (whiteboard), which requires Spring-OSGi, with trunk. Daniel, maybe you can share your thoughts on what this would mean for trunk (build system, required code changes, etc.) and how we can keep the experimental OSGi stuff out of our releases. I have not worked on it for a while so I don't remember all details. But the main part is making the cocoon jars bundles. This is preferably done with the Felix maven-bundle-plugin. I've written poms that contain the configuration of that plugin for all core blocks. The poms can be found here http://svn.apache.org/repos/asf/cocoon/whiteboard/osgi/core/. Using the Felix maven-bundle-plugin will add OSGi manifest.mf and will not disturb non OSGi usage the slightest. So this can be done right away. Second there are a number of spring-osgi configuration files that are placed in the META-INF/spring directories of the bundles. This directory isn't used in standard Cocoon, so these configuration files could also be added to trunk without cusing any problems. For the Java code I add a package to the cocoon-servlet-service-impl that depends on the OSGi framework and some services. If we don't want such dependencies in trunk we could either add a special block for that package or have some compilation profile. There is also some code that is spring-osgi specific in http://svn.apache.org/repos/asf/cocoon/whiteboard/osgi/core/cocoon-spring-osgi/. I have tried to make the spring-osgi project interested in spring-osgi, but that seem to have low priority right now for them. The main thing that I don't know how to solve is dependencies on bundelized versions of common libraries. I replace all the ordinary block dependencies with dependencies on bundelized versions of the libraries. By doing that I can use the Maven assembly plugin for collecting and installing all the needed bundle dependencies for the Cocoon block, so that it is easy to execute cocoon-osg, see http://svn.apache.org/repos/asf/cocoon/whiteboard/osgi/cocoon-osgi-main/. It would in most cases be possible to used the bundelized versions of the libraries for standard Cocoon as well. But the problem is that the bundelized jars in most cases not are released. The bundelized Cocoon jars can be compiled with the standard dependencies in trunk. But in that case one have to depend explicitely on the bundelized version when creating thee cocoon-osgi assembly. This is rather inconvenient, but I don't see any other option if we want to move the OSGi stuff to trunk. Maybe one can do some clever thing with Maven profiles. /Daniel
Re: Deprecation of CInclude transformer
Ard Schrijvers wrote: Vadim Gritsenko wrote: Indeed. I think this is a failure on CocoonSource part. CocoonSource content depends on the sitemap.xmap, but CocoonSource validity does not include validity of the sitemap. As a result, even if sitemap is changed, CocoonSource validity stays valid. I'm not sure though if I want to have this bug fixed - it would add more overhead... Don't think either it is worth the trouble. You can work years with it without ever noticing, it is only happening during development when you happen to change something in a way described above (which will hardly ever happen) Actually, this may be exactly the reason my developer couldn't get the IncludeTransformer to work. I'll have to have hime take a look at it again. Ralph
Re: Upgrade to Spring 2.5
Daniel Fagerstrom wrote:
Now we can also think about merging Daniel's work on OSGi
(whiteboard), which requires Spring-OSGi, with trunk. Daniel, maybe
you can share your thoughts on what this would mean for trunk (build
system, required code changes, etc.) and how we can keep the
experimental OSGi stuff out of our releases.
I have not worked on it for a while so I don't remember all details. But
the main part is making the cocoon jars bundles. This is preferably done
with the Felix maven-bundle-plugin. I've written poms that contain the
configuration of that plugin for all core blocks. The poms can be found
here http://svn.apache.org/repos/asf/cocoon/whiteboard/osgi/core/.
snip/
Thanks Daniel! I hope to find some time in December to have a closer look on
what needs to be done.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
