Re: [#COCOON-2168] ResourceReader produces Java Heap Overflow when reading a huge resource - ASF JIRA
Joerg Heinicke wrote: On 11.03.2008 08:54, Carsten Ziegeler wrote: We could argue about another default value than -1 though. Something like 1024^2. Hmm, not sure if we should change the default value. The idea of this default was to be sure that error handling works out of the box. If you have special cases like mentioned in the bug, it makes imho more sense to fine tune these special cases (for instance by not buffering). The output buffer value is one of the settings which is optimized for development and it should be tweaked for production usage. Hmm, ok, we could change this in the main sitemap as a default configuration while leaving it in the java code untouched. However, I still think that this is not needed, if people want to stream huge responses, they should think about what they are doing and configure everything accordingly. I totally agree that we lack documentation here. I really don't agree with this reasoning but I don't want to stress it too much to not get on your nerves, so it's my last try :-) Hehe :) Ok, and I try hard that this is my last response :) 1. This IS already documented in the main sitemap and I think though hardly anybody is aware of it: Nobody had reacted on Felix' issue entry for 3 weeks. I can also see why: our main sitemap is the first thing I would get rid of when creating my own Cocoon application ;-) 2. Actually I don't care about the huge resources that much. I rather have big resources in mind - and concurrent users. What's worse as a default behavior for an incautious user: a screwed error page or a server brought down with an OOME? I also wanted to put the default as big as 1 MB so that it hardly affects anybody. I really don't see an additional value of endless buffering over such a big buffer. But I can prevent a fatal user error. And for everything that's beyond the default buffer size, here I completely agree with you, the user should think about potential issues in terms of buffering or caching. 3. Another, I admit minor point after so long time might be the change in behavior compared to former Cocoon versions. According to Robert [1] in Cocoon 2.0.4 it used to work out of the box. Yes, we discussed this for 2.1.0 and decided that it's better to have a correct error response per default. Ok, I agree that the difference is really very subtle, so lets change it; I guess one mb should be enough. I guess you want to change it for 2.1.x as well, right? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Maintenance Release 2.1.12
Hi, I had the thought of doing 2 or 3 maintenance releases of 2.1.x (if there are changes) per year. Following this spirit I would like to cut a 2.1.12 sometime during April. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[continuum] BUILD ERROR: Apache Cocoon [build root]
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=64617projectId=51 Build statistics: State: Error Previous State: Ok Started at: Thu 13 Mar 2008 01:00:01 -0700 Finished at: Thu 13 Mar 2008 01:00:38 -0700 Total time: 37s Build Trigger: Schedule Build Number: 0 Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.4.2_15 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_15-b02) Java HotSpot(TM) Client VM (build 1.4.2_15-b02, mixed mode) Builder version : Maven version: 2.0.7 Java version: 1.4.2_15 OS name: linux version: 2.6.20-16-server arch: i386 SCM Changes: No files changed Dependencies Changes: No dependencies changed Build Error: Provider message: The svn command failed. Command output: --- svn: PROPFIND request failed on '/repos/asf/cocoon/trunk' svn: PROPFIND of '/repos/asf/cocoon/trunk': could not connect to server (http://svn.apache.org) ---
[2.2] A simple CForms example doesn't work...
...so I suppose an upgrade of the doc is in order: I may volunteer in absence of anyone taking care of it him/herself. Regards, Luca Morandini www.lucamorandini.it
[2.2] Forms dependency on Ajax block
I must admit I am a bit uneasy about this dependency, which adds considerably to the JAR-tonnage of Cocoon even when the user is not interested in Ajax forms. Is this inevitable or there is a way to disentangle the two blocks ? As far as I understand one has to change forms-field-styling.xsl to avoid loading DoJo widgets if not needed, but I ignore whether there are other links to sever. Regards, P.S. By the way, I don't know whether this dependency has been discussed (a search on the archives didn't help), so, if the community has already decided to keep it, please disregard my plea. Luca Morandini www.lucamorandini.it
Re: Maintenance Release 2.1.12
+1 Carsten Ziegeler wrote: Hi, I had the thought of doing 2 or 3 maintenance releases of 2.1.x (if there are changes) per year. Following this spirit I would like to cut a 2.1.12 sometime during April. Carsten
Re: Maintenance Release 2.1.12
On Thu, Mar 13, 2008 at 8:53 AM, Carsten Ziegeler [EMAIL PROTECTED] wrote: ... Following this spirit I would like to cut a 2.1.12 sometime during April +1, I'll help testing if before the release. -Bertrand
Re: Maintenance Release 2.1.12
Carsten Ziegeler escribió: I would like to cut a 2.1.12 sometime during April. +1 Best Regards, Antonio Gallardo.
Re: Micro-Cocoon ... Corona
Reinhard Poetz wrote:
We at Indoqa have started to think about working on a slimmed down
version of Cocoon 2.2 (Micro-Cocoon).
snip/
Having said this, I want to mention that, for us, the Micro-Cocoon
effort is a feasability study, that we will conduct over the next 8
weeks.
Working on Mirco-Cocoon was an interesting experience. First Grzegorz, my
colleagues at Indoqa and I began with a code walk-through. Starting with the
second day we got our hands dirty and we did a lot of refactorings (remove
sub-sitemap support, remove sitemap-level components management, remove the
cocoon-protocol, cut some of the dependencies on Avalon/Excalibur, etc.).
In order to make sure that we don't break any functionality that we want to keep
working, I wrote integration tests (see [1] for the sitemap and [2] for the
integration test framework and [3] for the tests) which we let run whenever we
changed something.
This also gave us the chance to use Cobertura to find out how many lines of
Cocoon code are actually needed to make the tests run. The (for me) surprising
result was that of 23581 lines of code in Cocoon core, only 5510 are needed for
the test cases. See [4] for the full reports.
At the end of the third day we began to disucss how much work is still nessary
in order to reach the goal of a light-weight Cocoon. Our estimation is that it
will take somebody, who is familiar with Cocoon, another 20 to 30 days. And, we
are not sure if this enough time to have a clean codebase at the end.
That was the time when the idea of a rewrite was born. (And as I know it is
important for Grzegorz I want to say that he wasn't involved into this rewrite
in any ways.) I know, rewrites are a difficult topic especially in the context
of open source projects but it was just too tempting. Our time budget was that
we wanted to invest another three days (since it is Steven, a colleague at
Indoqa and I, which is 6 days in total) into a rewrite and find out how far it
will take us and to get another time estimation. So far we have invested about
4.5 days of those 6 days and the results are promising.
This rewrite that we gave the name Corona consists of
. a pipeline API (that isn't limited to XML pipelines but would also
support connecting of any types of pipes)
. a sitemap interpreter that interprets the sitemap language of 2.1/2.2
(pipeline, match, generate, transform, serialize, redirect, read,
handle-errors, act)
. the pipeline API and the sitemap interpreter are useable from within
*plain Java code* (- no dependency on the Servlet API) -- if it is used
outside of a web container, the user has to make sure that there is no
component that uses the servlet API
. component lookups are hidden behind an own interface so that any
component container can be used - as you might guess, our current
implementation currently uses Spring but writing e.g. an OSGi component
provider would be simple
. some basic components (resource reader, file generator, XML serializer, etc.)
. expression language support in sitemaps
. thanks to the servlet-service framework, it should work with
. a demo servlet that uses the sitemap interpreter
Corona is inspired by Cocoon 2.x but doesn't use any of its interfaces. The only
exception will be the JNet source resolver[5] that we will integrate very soon.
Apart from that we will also integrate the Include-Transformer, the
XSLTTransformer, provide support for controller implementations, provide
components to use servlet-services from within pipelines and support pipeline
caching. Then we should be able to run the tests cases[3] of Micro Cocoon which
is enough if it is only pipeline processing that you need.
So far Corona has been developed mostly by Steven (~ 90 % by him, 10 % by me)
behind closed doors but we would like to change that, if this community is
interested in adopting it in this or that way. Is there any interest and if yes,
how should we proceed?
Any feedback is highly appreciated!
[1]
http://svn.apache.org/repos/asf/cocoon/whiteboard/micro/misc/cocoon-micro-it-block/src/main/resources/COB-INF/sitemap.xmap
[2] http://svn.apache.org/repos/asf/cocoon/trunk/tools/cocoon-it-fw/
Consists of two parts: (1) HTMLUnit tests + XPath assertions based on the
integration test framework of 2.1.x and (2) a Maven plugin that starts and
stops Jetty.
[3]
http://svn.apache.org/repos/asf/cocoon/whiteboard/micro/misc/cocoon-webapp/src/test/java/org/apache/cocoon/micro/it/
[4] http://people.apache.org/~reinhard/micro-cocoon-cobertura-report/
[5]
http://svn.apache.org/repos/asf/excalibur/trunk/components/sourceresolve/jnet/
--
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] Commented: (COCOON-1985) AbstractCachingProcessingPipeline locking with IncludeTransformer may hang pipeline
[
https://issues.apache.org/jira/browse/COCOON-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578347#action_12578347
]
Alexander Daniel commented on COCOON-1985:
--
Two requests can deadlock each other in Cocoon 2.1.11 (without use of parallel
with include transformer):
* request A: generating lock for 55933
* request B: generating lock for 58840
* request B: waiting for lock 55933 which is hold by request A
* request A: waiting for lock 58840 which is hold by request B
I can reproduce this behaviour with Apache Bench and following pipeline:
* terminal 1: Apache Bench request A (ab -k -n 1 -c 25
http://localhost:/samples/reproduceMultipleThreads/productOfferForDevice/55933/)
* terminal 2: Apache Bench request B (ab -k -n 1 -c 25
http://localhost:/samples/reproduceMultipleThreads/productOfferForDevice/58840/)
* terminal 3: touching the two data files every second to invalidate the cache
(while true; do echo -n .; touch 55933.xml 58840.xml; sleep 1; done)
* pipeline:
map:pipeline type=caching
map:match pattern=productOfferForDevice*/*/
map:generate src=cocoon:/exists/{2}.xml label=a/
map:transform type=xsltc src=productOfferIncludeDevice.xsl label=b
map:parameter name=noInc value={1}/
/map:transform
map:transform type=include label=c/
map:serialize type=xml/
/map:match
map:match pattern=exists/**
map:act type=resource-exists
map:parameter name=url value={1} /
map:generate src={../1} /
map:serialize type=xml /
/map:act
!-- not found --
map:generate src=dummy.xml /
map:serialize type=xml /
/map:match
/map:pipeline
After some seconds the deadlock occurs ==
* Apache Bench requests run into a timeout
* I can see following pipe locks in the default transient store:
PIPELOCK:PK_G-file-cocoon://samples/reproduceMultipleThreads/exists/55933.xml?pipelinehash=-910770960103935149_T-xsltc-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/productOfferIncludeDevice.xsl;noInc=_T-include-I_S-xml-1
(class: org.mortbay.util.ThreadPool$PoolThread)
PIPELOCK:PK_G-file-cocoon://samples/reproduceMultipleThreads/exists/58840.xml?pipelinehash=-499603111986478_T-xsltc-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/productOfferIncludeDevice.xsl;noInc=_T-include-I_S-xml-1
(class: org.mortbay.util.ThreadPool$PoolThread)
PIPELOCK:PK_G-file-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/55933.xml
(class: org.mortbay.util.ThreadPool$PoolThread)
PIPELOCK:PK_G-file-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/58840.xml
(class: org.mortbay.util.ThreadPool$PoolThread)
I added some logging to AbstractCachingProcessingPipeline.java which reconfirms
the explanations above:
INFO (2008-03-13) 13:50.16:072 [sitemap]
(/samples/reproduceMultipleThreads/productOfferForDevice/55933/)
PoolThread-47/AbstractCachingProcessingPipeline: generating lock
PIPELOCK:PK_G-file-cocoon://samples/reproduceMultipleThreads/exists/55933.xml?pipelinehash=-910770960103935149_T-xsltc-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/productOfferIncludeDevice.xsl;noInc=_T-include-I_S-xml-1
INFO (2008-03-13) 13:50.16:074 [sitemap]
(/samples/reproduceMultipleThreads/productOfferForDevice/55933/)
PoolThread-47/AbstractCachingProcessingPipeline: generating lock
PIPELOCK:PK_G-file-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/55933.xml
INFO (2008-03-13) 13:50.16:075 [sitemap]
(/samples/reproduceMultipleThreads/productOfferForDevice/58840/)
PoolThread-6/AbstractCachingProcessingPipeline: generating lock
PIPELOCK:PK_G-file-cocoon://samples/reproduceMultipleThreads/exists/58840.xml?pipelinehash=-499603111986478_T-xsltc-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/productOfferIncludeDevice.xsl;noInc=_T-include-I_S-xml-1
INFO (2008-03-13) 13:50.16:075 [sitemap]
(/samples/reproduceMultipleThreads/productOfferForDevice/58840/)
PoolThread-6/AbstractCachingProcessingPipeline: generating lock
PIPELOCK:PK_G-file-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/58840.xml
INFO (2008-03-13) 13:50.16:281 [sitemap]
(/samples/reproduceMultipleThreads/productOfferForDevice/58840/)
PoolThread-6/AbstractCachingProcessingPipeline: waiting for lock
PIPELOCK:PK_G-file-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/55933.xml
INFO (2008-03-13) 13:50.16:304 [sitemap]
(/samples/reproduceMultipleThreads/productOfferForDevice/55933/)
PoolThread-47/AbstractCachingProcessingPipeline: waiting for lock
[jira] Updated: (COCOON-1985) AbstractCachingProcessingPipeline locking with IncludeTransformer may hang pipeline
[ https://issues.apache.org/jira/browse/COCOON-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Daniel updated COCOON-1985: - Attachment: reproduceMultipleThreads.tar.gz Sample code to reproduce deadlock in Cocoon 2.1.11 with two requests AbstractCachingProcessingPipeline locking with IncludeTransformer may hang pipeline --- Key: COCOON-1985 URL: https://issues.apache.org/jira/browse/COCOON-1985 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.9, 2.1.10, 2.1.11, 2.2-dev (Current SVN) Reporter: Ellis Pritchard Priority: Critical Fix For: 2.2-dev (Current SVN) Attachments: caching-trials.patch, includer.xsl, patch.txt, reproduceMultipleThreads.tar.gz, sitemap.xmap Cocoon 2.1.9 introduced the concept of a lock in AbstractCachingProcessingPipeline, an optimization to prevent two concurrent requests from generating the same cached content. The first request adds the pipeline key to the transient cache to 'lock' the cache entry for that pipeline, subsequent concurrent requests wait for the first request to cache the content (by Object.lock()ing the pipeline key entry) before proceeding, and can then use the newly cached content. However, this has introduced an incompatibility with the IncludeTransformer: if the inclusions access the same yet-to-be-cached content as the root pipeline, the whole assembly hangs, since a lock will be made on a lock already held by the same thread, and which cannot be satisfied. e.g. i) Root pipeline generates using sub-pipeline cocoon:/foo.xml ii) the cocoon:/foo.xml sub-pipeline adds it's pipeline key to the transient store as a lock. iii) subsequently in the root pipeline, the IncludeTransformer is run. iv) one of the inclusions also generates with cocoon:/foo.xml, this sub-pipeline locks in AbstractProcessingPipeline.waitForLock() because the sub-pipeline key is already present. v) deadlock. I've found a (partial, see below) solution for this: instead of a plain Object being added to the transient store as the lock object, the Thread.currentThread() is added; when waitForLock() is called, if the lock object exists, it checks that it is not the same thread before attempting to lock it; if it is the same thread, then waitForLock() returns success, which allows generation to proceed. You loose the efficiency of generating the cache only once in this case, but at least it doesn't hang! With JDK1.5 this can be made neater by using Thread#holdsLock() instead of adding the thread object itself to the transient store. See patch file. However, even with this fix, parallel includes (when enabled) may still hang, because they pass the not-the-same-thread test, but fail because the root pipeline, which holds the initial lock, cannot complete (and therefore statisfy the lock condition for the parallel threads), before the threads themselves have completed, which then results in a deadlock again. The complete solution is probably to avoid locking if the lock is held by the same top-level Request, but that requires more knowledge of Cocoon's processing than I (currently) have! IMHO unless a complete solution is found to this, then this optimization should be removed completely, or else made optional by configuration, since it renders the IncludeTransformer dangerous. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[GSoC_2008] Project ideas
Yesterday I was introduced to an Austrian student who would be interested in
working on a GSoC for the Cocoon project this year.
The best idea we've had so far was was an upgrade of cForms to Dojo 1.x (or
replacing it with something else if that is what the community is interested
in).
Any other suggestions? (the deadline for project proposals is Monday, 17th of
March)
--
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] Commented: (COCOON-1985) AbstractCachingProcessingPipeline locking with IncludeTransformer may hang pipeline
[ https://issues.apache.org/jira/browse/COCOON-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578389#action_12578389 ] Vadim Gritsenko commented on COCOON-1985: - Alexander - if you take a look at the top of this page you will notice that issue has been resolved in trunk (see: Fix version (Component): Cocoon Core - 2.2.0-RC3-dev). If you take a look at the trunk you can also see a test case which was reproducing that issue. The fix is, IIRC, is to synchronize on top level http request. I planned to fix it on branch too but so far had no time to do it. AbstractCachingProcessingPipeline locking with IncludeTransformer may hang pipeline --- Key: COCOON-1985 URL: https://issues.apache.org/jira/browse/COCOON-1985 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.9, 2.1.10, 2.1.11, 2.2-dev (Current SVN) Reporter: Ellis Pritchard Priority: Critical Fix For: 2.2-dev (Current SVN) Attachments: caching-trials.patch, includer.xsl, patch.txt, reproduceMultipleThreads.tar.gz, sitemap.xmap Cocoon 2.1.9 introduced the concept of a lock in AbstractCachingProcessingPipeline, an optimization to prevent two concurrent requests from generating the same cached content. The first request adds the pipeline key to the transient cache to 'lock' the cache entry for that pipeline, subsequent concurrent requests wait for the first request to cache the content (by Object.lock()ing the pipeline key entry) before proceeding, and can then use the newly cached content. However, this has introduced an incompatibility with the IncludeTransformer: if the inclusions access the same yet-to-be-cached content as the root pipeline, the whole assembly hangs, since a lock will be made on a lock already held by the same thread, and which cannot be satisfied. e.g. i) Root pipeline generates using sub-pipeline cocoon:/foo.xml ii) the cocoon:/foo.xml sub-pipeline adds it's pipeline key to the transient store as a lock. iii) subsequently in the root pipeline, the IncludeTransformer is run. iv) one of the inclusions also generates with cocoon:/foo.xml, this sub-pipeline locks in AbstractProcessingPipeline.waitForLock() because the sub-pipeline key is already present. v) deadlock. I've found a (partial, see below) solution for this: instead of a plain Object being added to the transient store as the lock object, the Thread.currentThread() is added; when waitForLock() is called, if the lock object exists, it checks that it is not the same thread before attempting to lock it; if it is the same thread, then waitForLock() returns success, which allows generation to proceed. You loose the efficiency of generating the cache only once in this case, but at least it doesn't hang! With JDK1.5 this can be made neater by using Thread#holdsLock() instead of adding the thread object itself to the transient store. See patch file. However, even with this fix, parallel includes (when enabled) may still hang, because they pass the not-the-same-thread test, but fail because the root pipeline, which holds the initial lock, cannot complete (and therefore statisfy the lock condition for the parallel threads), before the threads themselves have completed, which then results in a deadlock again. The complete solution is probably to avoid locking if the lock is held by the same top-level Request, but that requires more knowledge of Cocoon's processing than I (currently) have! IMHO unless a complete solution is found to this, then this optimization should be removed completely, or else made optional by configuration, since it renders the IncludeTransformer dangerous. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Micro-Cocoon ... Corona
On Mar 13, 2008, at 11:40 AM, Reinhard Poetz wrote: . a pipeline API (that isn't limited to XML pipelines but would also support connecting of any types of pipes) . the pipeline API and the sitemap interpreter are useable from within *plain Java code* (- no dependency on the Servlet API) -- if it is used outside of a web container, the user has to make sure that there is no component that uses the servlet API Speaking of which, I had intention to make a clear separation between pipeline assembly stage - which is currently done by tree processor - and pipeline execution stage - which is currently sometimes is done from within tree processor itself, in case of 'external pipelines', or out of tree processor for 'internal pipelines'. I have done a prototype work - and had it working after ~ 1 day effort. But I noticed that you went in complete opposite direction and were bundling the two stages together in 'micro cocoon'. So what are your thoughts on this one? Vadim
Re: Micro-Cocoon ... Corona
Reinhard Poetz wrote: In order to make sure that we don't break any functionality that we want to keep working, I wrote integration tests (see [1] for the sitemap and [2] for the integration test framework and [3] for the tests) which we let run whenever we changed something. This also gave us the chance to use Cobertura to find out how many lines of Cocoon code are actually needed to make the tests run. The (for me) surprising result was that of 23581 lines of code in Cocoon core, only 5510 are needed for the test cases. See [4] for the full reports. Interesting :) At the end of the third day we began to disucss how much work is still nessary in order to reach the goal of a light-weight Cocoon. Our estimation is that it will take somebody, who is familiar with Cocoon, another 20 to 30 days. And, we are not sure if this enough time to have a clean codebase at the end. That was the time when the idea of a rewrite was born. (And as I know it is important for Grzegorz I want to say that he wasn't involved into this rewrite in any ways.) I know, rewrites are a difficult topic especially in the context of open source projects but it was just too tempting. Our time budget was that we wanted to invest another three days (since it is Steven, a colleague at Indoqa and I, which is 6 days in total) into a rewrite and find out how far it will take us and to get another time estimation. So far we have invested about 4.5 days of those 6 days and the results are promising. This rewrite that we gave the name Corona consists of . a pipeline API (that isn't limited to XML pipelines but would also support connecting of any types of pipes) Do you have use cases for this? (Just curious) . a sitemap interpreter that interprets the sitemap language of 2.1/2.2 (pipeline, match, generate, transform, serialize, redirect, read, handle-errors, act) . the pipeline API and the sitemap interpreter are useable from within *plain Java code* (- no dependency on the Servlet API) -- if it is used outside of a web container, the user has to make sure that there is no component that uses the servlet API Cool . component lookups are hidden behind an own interface so that any component container can be used - as you might guess, our current implementation currently uses Spring but writing e.g. an OSGi component provider would be simple . some basic components (resource reader, file generator, XML serializer, etc.) . expression language support in sitemaps . thanks to the servlet-service framework, it should work with . a demo servlet that uses the sitemap interpreter Corona is inspired by Cocoon 2.x but doesn't use any of its interfaces. The only exception will be the JNet source resolver[5] that we will integrate very soon. Ah, even cooler :) So far I haven't used JNet myself, so it seems you found it usefull. If there is anything missing/not working just let me know. Apart from that we will also integrate the Include-Transformer, the XSLTTransformer, provide support for controller implementations, provide components to use servlet-services from within pipelines and support pipeline caching. Then we should be able to run the tests cases[3] of Micro Cocoon which is enough if it is only pipeline processing that you need. So far Corona has been developed mostly by Steven (~ 90 % by him, 10 % by me) behind closed doors but we would like to change that, if this community is interested in adopting it in this or that way. Is there any interest and if yes, how should we proceed? If you don't mind, commit it to the whiteboard. I'm heavily interested in the stuff :) Carsten Any feedback is highly appreciated! [1] http://svn.apache.org/repos/asf/cocoon/whiteboard/micro/misc/cocoon-micro-it-block/src/main/resources/COB-INF/sitemap.xmap [2] http://svn.apache.org/repos/asf/cocoon/trunk/tools/cocoon-it-fw/ Consists of two parts: (1) HTMLUnit tests + XPath assertions based on the integration test framework of 2.1.x and (2) a Maven plugin that starts and stops Jetty. [3] http://svn.apache.org/repos/asf/cocoon/whiteboard/micro/misc/cocoon-webapp/src/test/java/org/apache/cocoon/micro/it/ [4] http://people.apache.org/~reinhard/micro-cocoon-cobertura-report/ [5] http://svn.apache.org/repos/asf/excalibur/trunk/components/sourceresolve/jnet/ -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Micro-Cocoon ... Corona
On 13.03.2008, at 18:11, Vadim Gritsenko wrote: On Mar 13, 2008, at 11:40 AM, Reinhard Poetz wrote: . a pipeline API (that isn't limited to XML pipelines but would also support connecting of any types of pipes) . the pipeline API and the sitemap interpreter are useable from within *plain Java code* (- no dependency on the Servlet API) -- if it is used outside of a web container, the user has to make sure that there is no component that uses the servlet API Speaking of which, I had intention to make a clear separation between pipeline assembly stage - which is currently done by tree processor - and pipeline execution stage - which is currently sometimes is done from within tree processor itself, in case of 'external pipelines', or out of tree processor for 'internal pipelines'. I have done a prototype work - and had it working after ~ 1 day effort. When we had the whole 'cocoon is dead - let's rewrite it' discussion that was exactly one of the thing I was thinking of. To some extend the sitemap should be just a factory creating pipelines. The pipelines should be a completely separate stand alone API that is just used by the sitemap. cheers -- Torsten
Re: Micro-Cocoon ... Corona
Torsten Curdt wrote:
On 13.03.2008, at 18:11, Vadim Gritsenko wrote:
On Mar 13, 2008, at 11:40 AM, Reinhard Poetz wrote:
. a pipeline API (that isn't limited to XML pipelines but would also
support connecting of any types of pipes)
. the pipeline API and the sitemap interpreter are useable from within
*plain Java code* (- no dependency on the Servlet API) -- if it
is used
outside of a web container, the user has to make sure that there is no
component that uses the servlet API
Speaking of which, I had intention to make a clear separation between
pipeline assembly stage - which is currently done by tree processor -
and pipeline execution stage - which is currently sometimes is done
from within tree processor itself, in case of 'external pipelines', or
out of tree processor for 'internal pipelines'. I have done a
prototype work - and had it working after ~ 1 day effort.
When we had the whole 'cocoon is dead - let's rewrite it' discussion
that was exactly one of the thing I was thinking of. To some extend the
sitemap should be just a factory creating pipelines. The pipelines
should be a completely separate stand alone API that is just used by the
sitemap.
yes, that's the approach that we follow with Corona.
--
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] Commented: (COCOON-1985) AbstractCachingProcessingPipeline locking with IncludeTransformer may hang pipeline
[ https://issues.apache.org/jira/browse/COCOON-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578407#action_12578407 ] Alexander Daniel commented on COCOON-1985: -- Thanks for the hint Vadim. I will have a look into the trunk. In Cocoon 2.1.9 a deadlock could be reproduced with one single request running in one thread. This has been fixed in Cocoon 2.1.11. The issue I described uses two top level http requests which deadlock each other because they depend on the same resources which they acquire in a different order. If Cocoon 2.2 trunk synchronizes on top level http requests the same issue could occur from my understanding. AbstractCachingProcessingPipeline locking with IncludeTransformer may hang pipeline --- Key: COCOON-1985 URL: https://issues.apache.org/jira/browse/COCOON-1985 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.9, 2.1.10, 2.1.11, 2.2-dev (Current SVN) Reporter: Ellis Pritchard Priority: Critical Fix For: 2.2-dev (Current SVN) Attachments: caching-trials.patch, includer.xsl, patch.txt, reproduceMultipleThreads.tar.gz, sitemap.xmap Cocoon 2.1.9 introduced the concept of a lock in AbstractCachingProcessingPipeline, an optimization to prevent two concurrent requests from generating the same cached content. The first request adds the pipeline key to the transient cache to 'lock' the cache entry for that pipeline, subsequent concurrent requests wait for the first request to cache the content (by Object.lock()ing the pipeline key entry) before proceeding, and can then use the newly cached content. However, this has introduced an incompatibility with the IncludeTransformer: if the inclusions access the same yet-to-be-cached content as the root pipeline, the whole assembly hangs, since a lock will be made on a lock already held by the same thread, and which cannot be satisfied. e.g. i) Root pipeline generates using sub-pipeline cocoon:/foo.xml ii) the cocoon:/foo.xml sub-pipeline adds it's pipeline key to the transient store as a lock. iii) subsequently in the root pipeline, the IncludeTransformer is run. iv) one of the inclusions also generates with cocoon:/foo.xml, this sub-pipeline locks in AbstractProcessingPipeline.waitForLock() because the sub-pipeline key is already present. v) deadlock. I've found a (partial, see below) solution for this: instead of a plain Object being added to the transient store as the lock object, the Thread.currentThread() is added; when waitForLock() is called, if the lock object exists, it checks that it is not the same thread before attempting to lock it; if it is the same thread, then waitForLock() returns success, which allows generation to proceed. You loose the efficiency of generating the cache only once in this case, but at least it doesn't hang! With JDK1.5 this can be made neater by using Thread#holdsLock() instead of adding the thread object itself to the transient store. See patch file. However, even with this fix, parallel includes (when enabled) may still hang, because they pass the not-the-same-thread test, but fail because the root pipeline, which holds the initial lock, cannot complete (and therefore statisfy the lock condition for the parallel threads), before the threads themselves have completed, which then results in a deadlock again. The complete solution is probably to avoid locking if the lock is held by the same top-level Request, but that requires more knowledge of Cocoon's processing than I (currently) have! IMHO unless a complete solution is found to this, then this optimization should be removed completely, or else made optional by configuration, since it renders the IncludeTransformer dangerous. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1985) AbstractCachingProcessingPipeline locking with IncludeTransformer may hang pipeline
[ https://issues.apache.org/jira/browse/COCOON-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578414#action_12578414 ] Vadim Gritsenko commented on COCOON-1985: - Interesting. It sounds that you are describing related, but still different issue. If that's the case then it can be present in trunk too. It would be appropriate to file a separate Jira issue for this. AbstractCachingProcessingPipeline locking with IncludeTransformer may hang pipeline --- Key: COCOON-1985 URL: https://issues.apache.org/jira/browse/COCOON-1985 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.9, 2.1.10, 2.1.11, 2.2-dev (Current SVN) Reporter: Ellis Pritchard Priority: Critical Fix For: 2.2-dev (Current SVN) Attachments: caching-trials.patch, includer.xsl, patch.txt, reproduceMultipleThreads.tar.gz, sitemap.xmap Cocoon 2.1.9 introduced the concept of a lock in AbstractCachingProcessingPipeline, an optimization to prevent two concurrent requests from generating the same cached content. The first request adds the pipeline key to the transient cache to 'lock' the cache entry for that pipeline, subsequent concurrent requests wait for the first request to cache the content (by Object.lock()ing the pipeline key entry) before proceeding, and can then use the newly cached content. However, this has introduced an incompatibility with the IncludeTransformer: if the inclusions access the same yet-to-be-cached content as the root pipeline, the whole assembly hangs, since a lock will be made on a lock already held by the same thread, and which cannot be satisfied. e.g. i) Root pipeline generates using sub-pipeline cocoon:/foo.xml ii) the cocoon:/foo.xml sub-pipeline adds it's pipeline key to the transient store as a lock. iii) subsequently in the root pipeline, the IncludeTransformer is run. iv) one of the inclusions also generates with cocoon:/foo.xml, this sub-pipeline locks in AbstractProcessingPipeline.waitForLock() because the sub-pipeline key is already present. v) deadlock. I've found a (partial, see below) solution for this: instead of a plain Object being added to the transient store as the lock object, the Thread.currentThread() is added; when waitForLock() is called, if the lock object exists, it checks that it is not the same thread before attempting to lock it; if it is the same thread, then waitForLock() returns success, which allows generation to proceed. You loose the efficiency of generating the cache only once in this case, but at least it doesn't hang! With JDK1.5 this can be made neater by using Thread#holdsLock() instead of adding the thread object itself to the transient store. See patch file. However, even with this fix, parallel includes (when enabled) may still hang, because they pass the not-the-same-thread test, but fail because the root pipeline, which holds the initial lock, cannot complete (and therefore statisfy the lock condition for the parallel threads), before the threads themselves have completed, which then results in a deadlock again. The complete solution is probably to avoid locking if the lock is held by the same top-level Request, but that requires more knowledge of Cocoon's processing than I (currently) have! IMHO unless a complete solution is found to this, then this optimization should be removed completely, or else made optional by configuration, since it renders the IncludeTransformer dangerous. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Micro-Cocoon ... Corona
On Thu, Mar 13, 2008 at 10:40 AM, Reinhard Poetz [EMAIL PROTECTED] wrote: Reinhard Poetz wrote: sniplots of cool stuff/snip So far Corona has been developed mostly by Steven (~ 90 % by him, 10 % by me) behind closed doors but we would like to change that, if this community is interested in adopting it in this or that way. Is there any interest and if yes, how should we proceed? Very interested. I'd second throwing it into the white board if you're willing? -- Peter Hunsberger
Re: Micro-Cocoon ... Corona
Peter Hunsberger skrev: On Thu, Mar 13, 2008 at 10:40 AM, Reinhard Poetz [EMAIL PROTECTED] wrote: Reinhard Poetz wrote: sniplots of cool stuff/snip So far Corona has been developed mostly by Steven (~ 90 % by him, 10 % by me) behind closed doors but we would like to change that, if this community is interested in adopting it in this or that way. Is there any interest and if yes, how should we proceed? Very interested. I'd second throwing it into the white board if you're willing? +1! /Daniel
Re: Micro-Cocoon ... Corona
Hi Reinhard, Reinhard Poetz pisze: snip/ That was the time when the idea of a rewrite was born. (And as I know it is important for Grzegorz I want to say that he wasn't involved into this rewrite in any ways.) I know, rewrites are a difficult topic especially in the context of open source projects but it was just too tempting. Our time budget was that we wanted to invest another three days (since it is Steven, a colleague at Indoqa and I, which is 6 days in total) into a rewrite and find out how far it will take us and to get another time estimation. So far we have invested about 4.5 days of those 6 days and the results are promising. First of all I would like to say that it wasn't me who opted for rewrite option. My idea of Micro Cocoon has been to have something derived from Cocoon 2.2 with *continuous* history. For me it was quite important to have basic contracts preserved. To be honest, I'm not feeling fine with the progress of events because I'm feeling like an outcast a little bit. I feel like I was really involved in pushing Cocoon forward and now, when there is Corona my opinion doesn't matter because development is isolated in Vienna's office. That I would not call a rewarding experience. This rewrite that we gave the name Corona consists of . a pipeline API (that isn't limited to XML pipelines but would also support connecting of any types of pipes) I second question of Reinhard. If not XML, then what? What's the use-case? . a sitemap interpreter that interprets the sitemap language of 2.1/2.2 (pipeline, match, generate, transform, serialize, redirect, read, handle-errors, act) . the pipeline API and the sitemap interpreter are useable from within *plain Java code* (- no dependency on the Servlet API) -- if it is used outside of a web container, the user has to make sure that there is no component that uses the servlet API Interesting but not sure if much practical. . component lookups are hidden behind an own interface so that any component container can be used - as you might guess, our current implementation currently uses Spring but writing e.g. an OSGi component provider would be simple . some basic components (resource reader, file generator, XML serializer, etc.) . expression language support in sitemaps . thanks to the servlet-service framework, it should work with . a demo servlet that uses the sitemap interpreter Corona is inspired by Cocoon 2.x but doesn't use any of its interfaces. The only exception will be the JNet source resolver[5] that we will integrate very soon. What's the advantage of JNet compared to CocoonSourceResolver? Is there any description available? Apart from that we will also integrate the Include-Transformer, the XSLTTransformer, provide support for controller implementations, provide components to use servlet-services from within pipelines and support pipeline caching. Then we should be able to run the tests cases[3] of Micro Cocoon which is enough if it is only pipeline processing that you need. Hmmm. I presume that Corona won't support any of existing components of Cocoon 2.2? That are *very* bad news IMO. So far Corona has been developed mostly by Steven (~ 90 % by him, 10 % by me) behind closed doors but we would like to change that, if this community is interested in adopting it in this or that way. Is there any interest and if yes, how should we proceed? I've met Steven and I really like him (if you are reading this, greetings from me) but the fact that 90% of the code, fundamental contracts was developed by one developer which is *not* Cocoon committer really worries me. Anyway, I won't moan as long as I don't see the code because it is exactly what I'm interested in mostly. Any feedback is highly appreciated! -- Best regards, Grzegorz Kossakowski
Re: [2.2] A simple CForms example doesn't work...
Luca Morandini pisze: ...so I suppose an upgrade of the doc is in order: I may volunteer in absence of anyone taking care of it him/herself. Hi Luca, I think it would be the best if you could take care of updating the docs because it was you who suffered recently of not up-to-date docs. I'll be happy to provide comments and advice whenever needed. Thank you for your involvement! -- Grzegorz Kossakowski
Re: Micro-Cocoon ... Corona
Grzegorz Kossakowski pisze: This rewrite that we gave the name Corona consists of . a pipeline API (that isn't limited to XML pipelines but would also support connecting of any types of pipes) I second question of Reinhard. If not XML, then what? What's the use-case? Sorry, I meant here I second question of Carsten. -- Grzegorz
Re: [2.2] Forms dependency on Ajax block
Luca Morandini pisze: I must admit I am a bit uneasy about this dependency, which adds considerably to the JAR-tonnage of Cocoon even when the user is not interested in Ajax forms. Is this inevitable or there is a way to disentangle the two blocks ? As far as I understand one has to change forms-field-styling.xsl to avoid loading DoJo widgets if not needed, but I ignore whether there are other links to sever. Dojo is used to only handle Ajax mode of Forms but to handle advanced field styling of Forms widgets as well that has nothing to do with Ajax. Advanced styling means for example date picker which is done by Dojo's widget. This means that Forms must depend on Ajax (Dojo to be more precise) despite the fact you use Ajax or not. I hope this clarifies a little bit. -- Grzegorz Kossakowski
Re: Micro-Cocoon ... Corona
Carsten Ziegeler wrote: Reinhard Poetz wrote: This rewrite that we gave the name Corona consists of . a pipeline API (that isn't limited to XML pipelines but would also support connecting of any types of pipes) Do you have use cases for this? (Just curious) I can think of a lot of them. Any time you want to make replacements in text where the source is not XML this could be useful. How about replacing property keys with property values, just as an obvious example. Or translating a text file to another language by looking up phrases in a resource bundle. Sure, you could use a templating engine, but that may be overkill for some applications and besides, suppose you wanted to do several unrelated replacements that used different kinds of templates? Or suppose you wanted to make changes to HTML generated by some other website that doesn't generate XHTML or even very sensible HTML? There are many reasons you might want to do this: to extract a bit of content from the page, to filter certain words, to alter URLs. I wrote a spider once that archived the state of a web application as of a certain day. It crawled web pages and replaced URLs with file: URLs that pointed to where the web page was stored locally. This was complicated by the fact that many web pages with the same URL would display different data depending on request parameters, and so had to be stored in different places but still be pointed to by the links if you followed a particular path through the stored HTML files. This was only one of many cleanups I needed to make to the archived HTML. Cocoon didn't help me because there was no reasonable way to get the HTML into XHTML. A non-XML pipeline would have helped a lot.
Re: [2.2] Forms dependency on Ajax block
Grzegorz Kossakowski wrote: Luca Morandini pisze: Dojo is used to only handle Ajax mode of Forms but to handle advanced field styling of Forms widgets as well that has nothing to do with Ajax. Yes, I've looked into the code and discovered that ;) This means that Forms must depend on Ajax (Dojo to be more precise) despite the fact you use Ajax or not. Which is a departure from 2.1.9, which, IIRC, worked even with Javascript disabled on the browser. I presume that a way to disentangle forms and ajax blocks would be to make two different forms-field-styling.xsl (one with Javascript and/or Ajax, the other without Javascript), loaded conditionally on ajax=true by forms-samples-styling.xsl. Why I'm making such a plea ? Well, the use of non-Javascript forms is a requirement for making websites accessible, which is a mandatory for governmental websites in Italy. Regards, Luca Morandini www.lucamorandini.it
Re: [2.2] Forms dependency on Ajax block
Luca Morandini pisze: Grzegorz Kossakowski wrote: Luca Morandini pisze: Dojo is used to only handle Ajax mode of Forms but to handle advanced field styling of Forms widgets as well that has nothing to do with Ajax. Yes, I've looked into the code and discovered that ;) This means that Forms must depend on Ajax (Dojo to be more precise) despite the fact you use Ajax or not. Which is a departure from 2.1.9, which, IIRC, worked even with Javascript disabled on the browser. I presume that a way to disentangle forms and ajax blocks would be to make two different forms-field-styling.xsl (one with Javascript and/or Ajax, the other without Javascript), loaded conditionally on ajax=true by forms-samples-styling.xsl. That would be quite difficult because there is no easy way to conditionally load XSL templates. What about making inclusion of JS libraries in generated HTML forms conditional? It would only require tweaking existing templates. This would not remove dependency on ajax block in Forms block but at least you would get clean web-pages. Why I'm making such a plea ? Well, the use of non-Javascript forms is a requirement for making websites accessible, which is a mandatory for governmental websites in Italy. Ah, accessibility is a very important aspect still ignored by too many web developers. Good to hear that Italy's government is making such requirements. -- Grzegorz Kossakowski
Re: [2.2] Forms dependency on Ajax block
Grzegorz Kossakowski wrote: Luca Morandini pisze: I presume that a way to disentangle forms and ajax blocks would be to make two different forms-field-styling.xsl (one with Javascript and/or Ajax, the other without Javascript), loaded conditionally on ajax=true by forms-samples-styling.xsl. That would be quite difficult because there is no easy way to conditionally load XSL templates. Gee... yes, that's one of the things XSLT is not supposed to do. What about making inclusion of JS libraries in generated HTML forms conditional? It would only require tweaking existing templates. Dropping libraries is easy, what's not so easy is the dropping of the Javascript code poping up here and there. Another solution would be to make every template dual: xsl:template match=fi:validation-message xsl:choose xsl:when test=$ajax-mode='true' span dojoType=forms:infopopup ... /span /xsl:when xsl:otherwise span style=display:none ... /span /xsl:otherwise /xsl:choose /xsl:template Come to think of it, there should be three modes, not teo: ajax, javascript, no-javascript. Hence, ajax='true' should be changed too, maybe to client='static|dynamic|ajax'... hmm... the matter is getting hairy. Regards, Luca Morandini www.lucamorandini.it
Re: [2.2] Forms dependency on Ajax block
Luca Morandini pisze: Grzegorz Kossakowski wrote: Luca Morandini pisze: I presume that a way to disentangle forms and ajax blocks would be to make two different forms-field-styling.xsl (one with Javascript and/or Ajax, the other without Javascript), loaded conditionally on ajax=true by forms-samples-styling.xsl. That would be quite difficult because there is no easy way to conditionally load XSL templates. Gee... yes, that's one of the things XSLT is not supposed to do. What about making inclusion of JS libraries in generated HTML forms conditional? It would only require tweaking existing templates. Dropping libraries is easy, what's not so easy is the dropping of the Javascript code poping up here and there. Another solution would be to make every template dual: xsl:template match=fi:validation-message xsl:choose xsl:when test=$ajax-mode='true' span dojoType=forms:infopopup ... /span /xsl:when xsl:otherwise span style=display:none ... /span /xsl:otherwise /xsl:choose /xsl:template Come to think of it, there should be three modes, not teo: ajax, javascript, no-javascript. Hence, ajax='true' should be changed too, maybe to client='static|dynamic|ajax'... hmm... the matter is getting hairy. Ah, right. Not sure what's the best solution for this. Have you done some research on how others avoid using JS for things like pop-up windows? I hope you can come up with something general that won't increase complexity of existing XSLT templates. If it's not possible I would recommend creation of your own forms-customized block that will inherit from original Cocoon block and override necessary templates. Thanks to SSF capabilities there are very clean ways to customize such things. -- Grzegorz Kossakowski
Re: Micro-Cocoon ... Corona
Hi guys, I guess its about time to write something myself... As a colleague of Reinhard I participated in the Micro-Cocoon effort in February. Just as Reinhard wrote, at the end of those 3 days, there was the idea of doing a rewrite. The number of use cases and the appr. 5500 lines of code indicated by Cobertura made this idea seem like an attainable goal. Nonetheless this is/will be a challenging task - and I am attracted to challenges. ;-) We believed that a working sitemap interpreter (without any components) could be created in about two days time. So I simply attempted to do so and so far things are developing as we envisioned. Very soon we decided to go back to the community and talk about our intention. Of course we anticipated questions or even mild resistance, but this all very natural. So here we go... Hi Reinhard, Reinhard Poetz pisze: snip/ That was the time when the idea of a rewrite was born. (And as I know it is important for Grzegorz I want to say that he wasn't involved into this rewrite in any ways.) I know, rewrites are a difficult topic especially in the context of open source projects but it was just too tempting. Our time budget was that we wanted to invest another three days (since it is Steven, a colleague at Indoqa and I, which is 6 days in total) into a rewrite and find out how far it will take us and to get another time estimation. So far we have invested about 4.5 days of those 6 days and the results are promising. First of all I would like to say that it wasn't me who opted for rewrite option. My idea of Micro Cocoon has been to have something derived from Cocoon 2.2 with *continuous* history. For me it was quite important to have basic contracts preserved. To be honest, I'm not feeling fine with the progress of events because I'm feeling like an outcast a little bit. I feel like I was really involved in pushing Cocoon forward and now, when there is Corona my opinion doesn't matter because development is isolated in Vienna's office. That I would not call a rewarding experience. That's the reason we're doing this as early as possible. Our intention is not to come up with something we developed for month and present a completed product. Actually not much has happened yet. All we did was to build the minimum, just to convince ourselves our approach is actually working. We believe it doesn't make much sense to come up with some grand idea without having anything that indicates this could work. This rewrite that we gave the name Corona consists of . a pipeline API (that isn't limited to XML pipelines but would also support connecting of any types of pipes) I second question of Reinhard. If not XML, then what? What's the use-case? Maybe I'm getting this wrong, but as far as I understood there are already components that do not produce XML content, like the Reader. I believe it's not that far fetched to think about transforming the output of that. The use cases proposed by Bruce all seem reasonable to me. . a sitemap interpreter that interprets the sitemap language of 2.1/2.2 (pipeline, match, generate, transform, serialize, redirect, read, handle-errors, act) . the pipeline API and the sitemap interpreter are useable from within *plain Java code* (- no dependency on the Servlet API) -- if it is used outside of a web container, the user has to make sure that there is no component that uses the servlet API Interesting but not sure if much practical. . component lookups are hidden behind an own interface so that any component container can be used - as you might guess, our current implementation currently uses Spring but writing e.g. an OSGi component provider would be simple . some basic components (resource reader, file generator, XML serializer, etc.) . expression language support in sitemaps . thanks to the servlet-service framework, it should work with . a demo servlet that uses the sitemap interpreter Corona is inspired by Cocoon 2.x but doesn't use any of its interfaces. The only exception will be the JNet source resolver[5] that we will integrate very soon. What's the advantage of JNet compared to CocoonSourceResolver? Is there any description available? Apart from that we will also integrate the Include-Transformer, the XSLTTransformer, provide support for controller implementations, provide components to use servlet-services from within pipelines and support pipeline caching. Then we should be able to run the tests cases[3] of Micro Cocoon which is enough if it is only pipeline processing that you need. Hmmm. I presume that Corona won't support any of existing components of Cocoon 2.2? That are *very* bad news IMO. So far Corona has been developed mostly by Steven (~ 90 % by him, 10 % by me) behind closed doors but we would like to change that, if this community is interested in adopting it in this or that way. Is there any interest and
Re: [2.2] Forms dependency on Ajax block
Grzegorz Kossakowski wrote:
Luca Morandini pisze:
Come to think of it, there should be three modes, not teo: ajax,
javascript, no-javascript.
Hence, ajax='true' should be changed too, maybe to
client='static|dynamic|ajax'... hmm... the matter is getting hairy.
Ah, right. Not sure what's the best solution for this. Have you done some
research on how others
avoid using JS for things like pop-up windows? I hope you can come up with
something general that
won't increase complexity of existing XSLT templates.
Well, you can use hidden DIVs, to be displayed when an on hover event
is triggered.
Off the top of my head:
...
style type=text/css
.errmsg div {
display:none;
}
.errmsg:hover div {
display:block;
position:absolute;
top:inherit;
left:inherit;
z-index:10;
width:50%;
background-color:red;
color:white;
font-size:1.3em;
}
/style
...
div class=errmsg
Error
div
img
src=http://cocoon.apache.org/2.2/blocks/forms/1.0/images/errors.gif/
This is a rather annoying error message
/div
/div
I'm sure a web designer coudl come up with something better.
If it's not possible I would recommend creation of your own forms-customized
block that will inherit
from original Cocoon block and override necessary templates. Thanks to SSF
capabilities there are
very clean ways to customize such things.
That's absolutely true: I'm starting to appreciate what SSF can do.
Regards,
Luca Morandini
www.lucamorandini.it
Re: [2.2] Forms dependency on Ajax block
Luca Morandini pisze:
Well, you can use hidden DIVs, to be displayed when an on hover event
is triggered.
Off the top of my head:
...
style type=text/css
.errmsg div {
display:none;
}
.errmsg:hover div {
display:block;
position:absolute;
top:inherit;
left:inherit;
z-index:10;
width:50%;
background-color:red;
color:white;
font-size:1.3em;
}
/style
...
div class=errmsg
Error
div
img
src=http://cocoon.apache.org/2.2/blocks/forms/1.0/images/errors.gif/
This is a rather annoying error message
/div
/div
I'm sure a web designer coudl come up with something better.
Ah, right. Is this technique considered as accessible?
If it's not possible I would recommend creation of your own
forms-customized block that will inherit
from original Cocoon block and override necessary templates. Thanks to
SSF capabilities there are
very clean ways to customize such things.
That's absolutely true: I'm starting to appreciate what SSF can do.
Good to hear that!
However, I have in mind some techniques that I have never spoken about up to
date so let me know
when you start to play with Forms customization. I'll be happy to do some
brainstorming.
--
Grzegorz Kossakowski
Re: Maintenance Release 2.1.12
Carsten Ziegeler pisze: Hi, I had the thought of doing 2 or 3 maintenance releases of 2.1.x (if there are changes) per year. Following this spirit I would like to cut a 2.1.12 sometime during April. +1 Will help with testing and with updating our site if needed. -- Grzegorz Kossakowski
Re: [2.2] Forms dependency on Ajax block
Grzegorz Kossakowski wrote: Luca Morandini pisze: Well, you can use hidden DIVs, to be displayed when an on hover event is triggered. ... Ah, right. Is this technique considered as accessible? Yep: it doesn't use Javascript and it dosn't break the linearity of the page. Regards, Luca Morandini www.lucamorandini.it
