[jira] Commented: (COCOON3-35) Support access to URLs that require authentication.
[ https://issues.apache.org/jira/browse/COCOON3-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704771#action_12704771 ] Vadim Gritsenko commented on COCOON3-35: Reply to comment # ... ummm ... comment above. Yep, I found the code "responsible" for the "just works" behavior, it's in the URLSource: http://svn.apache.org/repos/asf/excalibur/trunk/components/sourceresolve/impl/src/main/java/org/apache/excalibur/source/factories/URLSource.java > Support access to URLs that require authentication. > --- > > Key: COCOON3-35 > URL: https://issues.apache.org/jira/browse/COCOON3-35 > Project: Cocoon 3 > Issue Type: New Feature > Components: cocoon-sax, cocoon-stax, cocoon-stringtemplate >Affects Versions: 3.0.0-alpha-1 >Reporter: Steven Dolg >Assignee: Cocoon Developers Team >Priority: Minor > Fix For: 3.0.0-alpha-2 > > Attachments: authentication.patch > > > Currently our pipeline components cannot access URLs that require > authentication. > While it is possible to create specialized versions of each component and add > authentication there, it shouldn't be too difficult to support this feature > in every pipeline component we currently have. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON3-35) Support access to URLs that require authentication.
[ https://issues.apache.org/jira/browse/COCOON3-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704233#action_12704233 ] Vadim Gritsenko commented on COCOON3-35: Did you try embedding username/password into the resource URL? I have not tried it myself but I would expect it to "just work". E.g. http://user:passw...@host:port/path/to/some.xslt > Support access to URLs that require authentication. > --- > > Key: COCOON3-35 > URL: https://issues.apache.org/jira/browse/COCOON3-35 > Project: Cocoon 3 > Issue Type: New Feature > Components: cocoon-sax, cocoon-stax, cocoon-stringtemplate >Affects Versions: 3.0.0-alpha-1 >Reporter: Steven Dolg >Assignee: Cocoon Developers Team >Priority: Minor > Fix For: 3.0.0-alpha-2 > > > Currently our pipeline components cannot access URLs that require > authentication. > While it is possible to create specialized versions of each component and add > authentication there, it shouldn't be too difficult to support this feature > in every pipeline component we currently have. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (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?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592066#action_12592066
]
Vadim Gritsenko commented on COCOON-2063:
-
I'm not sure why generator needs to know encoding... Can it be simply always
set to UTF-8?
> NekoHTMLTransformer needs to set the default-encoding of the current system
> to work properly with UTF-8
> ---
>
> Key: COCOON-2063
> URL: https://issues.apache.org/jira/browse/COCOON-2063
> Project: Cocoon
> Issue Type: Bug
> Components: Blocks: HTML
>Affects Versions: 2.1.11, 2.2
>Reporter: Alexander Klimetschek
>Assignee: Jörg Heinicke
>Priority: Minor
> Attachments: NekoHTMLGenerator_BRANCH2_1_X.patch,
> nekohtmltransformer-encoding.patch
>
>
> The NekoHTMLTransformer uses the cyberneko HTMLConfiguration for tidying
> html. Unfortunately it does not use the system's current encoding as default,
> instead you have to set a property to set your encoding. But this varies from
> one OS to another, so the best solution is to set this property automatically
> in the NekoHTMLTransformer depending on what Java uses as defaultCharset:
>
> config.setProperty("http://cyberneko.org/html/properties/default-encoding";,
> Charset.defaultCharset().name());
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2173) AbstractCachingProcessingPipeline: Two requests can deadlock each other
[ https://issues.apache.org/jira/browse/COCOON-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582102#action_12582102 ] Vadim Gritsenko commented on COCOON-2173: - Patched branch and trunk: (1) Wait is now limited to 7 seconds by default (or specify timeout with 'locking-timeout' parameter) (2) Locking is optional, turned on by default but can be disabled by setting 'locking' parameter to false. I agree that ideally synchronization should be re-designed to include deadlock detection. I'll leave this for the next time - or somebody can provide a patch. I don't like short wait (250ms)-and-abort you are suggesting. It will be way to easy not to notice that something wrong is going on with your pipelines if wait is just 250ms. So I used higher limit - 7s - so you notice that there is a problem and there is an option of either configuring lower limit, or switching locking off completely for deadlocking pipelines. In your scenario, I would suggest moving deadlocking pipelines into separate with locking disabled. Or, if you have time, implementing a deadlock detection :-) > AbstractCachingProcessingPipeline: Two requests can deadlock each other > --- > > Key: COCOON-2173 > URL: https://issues.apache.org/jira/browse/COCOON-2173 > Project: Cocoon > Issue Type: Bug > Components: - Components: Sitemap >Affects Versions: 2.1.9, 2.1.10, 2.1.11, 2.2-dev (Current SVN) >Reporter: Alexander Daniel > Attachments: patchFor2.1.11.txt, reproduceMultipleThreads.tar.gz, > reproduceMultipleThreads2.2RC3-SNAPSHOT.tar.gz > > > Two requests can deadlock each other when they depend on the same resources > which they acquire in a different order. I can reproduce that in Cocoon > 2.1.11 and Cocoon 2.2-RC3-SNAPSHOT: > * 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: > > > > label="b"> > > > > > > > > > > > > > > > > > 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/reproduceM
[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-tabpanel&focusedCommentId=12582098#action_12582098 ] Vadim Gritsenko commented on COCOON-1985: - Both trunk and branch are patched for 'BIG SCARY UN-SYNCHRONIZED GAP' and pipeline locking is made optional (use 'locking' parameter), and with non-infinite wait time (use 'locking-timeout' parameter) defaulting to 7 seconds. Please test and if there are no more issues with it, I'll close this bug report. > 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.1.12-dev (Current SVN), 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-2178) Array-based constructors of TreeSelectionEvent used.
[ https://issues.apache.org/jira/browse/COCOON-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580376#action_12580376 ] Vadim Gritsenko commented on COCOON-2178: - Harald, this should help you get started: http://cocoon.apache.org/2.1/howto/howto-patch.html > Array-based constructors of TreeSelectionEvent used. > > > Key: COCOON-2178 > URL: https://issues.apache.org/jira/browse/COCOON-2178 > Project: Cocoon > Issue Type: Improvement > Components: Blocks: Forms >Affects Versions: 2.1.11, 2.2-dev (Current SVN) >Reporter: Harald Entner >Priority: Minor > Fix For: 2.1.11, 2.2-dev (Current SVN) > > > I'm facing a serious problem using the cforms tree. > We added a new functionality: when a user doubleclicks an item, all subitems > are selected as well. The result is that for every selected subitem an event > is thrown. The problem, as mentioned in the source code, is that the array > based constructor of the TreeSelectionEvent is not used. (Besides some other > minor changes). > I have adapted the org.apache.cocoon.forms.formmodel.tree.Tree class and it > works fine. But we'll face a problem after updating, so please tell me how i > could contribute my code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[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 ] Vadim Gritsenko updated COCOON-1985: Fix Version/s: 2.1.12-dev (Current SVN) Fix backported to 2.1 branch. > 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.1.12-dev (Current SVN), 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-tabpanel&focusedCommentId=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.
[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-tabpanel&focusedCommentId=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.
[jira] Commented: (COCOON-2166) Enable caching of IncludeTransformer if not all includes could be resolved
[
https://issues.apache.org/jira/browse/COCOON-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566900#action_12566900
]
Vadim Gritsenko commented on COCOON-2166:
-
You should differentiate the case when source exists but not cacheable, and
when source does not exist. Otherwise you will be caching what must not be
cached.
> Enable caching of IncludeTransformer if not all includes could be resolved
> --
>
> Key: COCOON-2166
> URL: https://issues.apache.org/jira/browse/COCOON-2166
> Project: Cocoon
> Issue Type: Improvement
> Components: * Cocoon Core
>Affects Versions: 2.1.12-dev (Current SVN)
>Reporter: Andreas Hartmann
> Attachments: patch-issue2166.txt
>
>
> About the context: In Lenya, we have a couple of modules, which are basically
> directories. A module directory can include an optional menu.xml file. The
> Lenya GUI menubar is an aggregation of all these menu.xml files, with some
> postprocessing. The same mechanism is used for the i18n catalogue - modules
> can provide i18n catalogues for their GUIs.
> We use the IncludeTransformer to assemble the menu XML, ignoring the
> non-existing menus using . It looks basically like this:
>
>
>
>
>
> This is extremely fast if all modules contain menu.xml files, because the
> aggregated XML is cached. But if some of the includes can't be resolved,
> nothing is cached. This causes up to 50% more request processing time, so it
> has quite a big impact on the Lenya GUI performance :)
> I tracked the source of the behaviour down to the MultiSourceValidity class.
> As soon as one of the sources has no validity (IIUC this happens if a
> FileSource doesn't exist), the whole MultiSourceValidity becomes invalid:
> public void addSource(Source src) {
> if (this.uris != null) {
> SourceValidity validity = src.getValidity();
> if (validity == null) {
> /* The source has no validity: this will be
> always be invalid. */
> this.uris = null;
> From my POV it would be better to ignore the non-existing sources, and check
> their existence when the validity is computed the next time. I.e.
> MultiSourceValidity.isValid() would return UNKNOWN, and isValid(newValidity)
> -> computeStatus() would check if newValidity provides a validity for the
> formerly missing source.
> Do you think this behaviour would be reasonable? If yes, I'd try to implement
> it, preferrably with test cases to avoid regressions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2165) PROCESSING BUG when using COCOON-PROTOCOL for TRANSFORMATION SRC and XSL:INCLUDE
[ https://issues.apache.org/jira/browse/COCOON-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566115#action_12566115 ] Vadim Gritsenko commented on COCOON-2165: - context: protocol can be used here, which does not need complete file path like file: protocol. > PROCESSING BUG when using COCOON-PROTOCOL for TRANSFORMATION SRC and > XSL:INCLUDE > > > Key: COCOON-2165 > URL: https://issues.apache.org/jira/browse/COCOON-2165 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.1.11 >Reporter: Robert Hoffmann >Priority: Critical > > Hi cocoon developers, > I found the following problem when using the cocoon-protocol in the src of > map:transform, BUT ONLY if there is an xsl:include in the transforming xsl. > 1)the sitemap > > > > > > > > > > > > > > > > > > > > > > > > 2) Exception: > org.apache.cocoon.ProcessingException: Unable to get transformer handler for > cocoon://test/testB.html?pipelinehash=2533989387103728471 > at [TransformerException] - > file:///Users/hoffmann/local/tomcat__11080/webapps/ROOT/app/foo/test/test_transform.xhtml:11:38 > at - > file:///Users/hoffmann/local/tomcat__11080/webapps/ROOT/app/foo/test/fooTest.xmap:27:33 > at - > file:///Users/hoffmann/local/tomcat__11080/webapps/ROOT/app/foo/test/fooTest.xmap:26:46 > at - > file:///Users/hoffmann/local/tomcat__11080/webapps/ROOT/app/foo/test/fooTest.xmap:25:45 > at - > file:///Users/hoffmann/local/tomcat__11080/webapps/ROOT/fooRootSitemap.xmap:77:92 > Complete exception stack: > http://cbio.mskcc.org/~hoffmann//pub/cocoon/a/cocoon_bug_report/error.txt > 3) I provide links to all the mentioned files at: > a) Individual files: > http://cbio.mskcc.org/~hoffmann//pub/cocoon/a/cocoon_bug_report/ > b) One archive: > http://cbio.mskcc.org/~hoffmann//pub/cocoon/a/cocoon_bug_report.zip > I hope this detailed test case will be helpful to one of the cocoon gurus... > Many thanks!!! > Robert > PS: Cocoon really rocks! > -- > Have you tried iHOP yet? http://www.ihop-net.org/UniPub/iHOP/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2162) [PATCH] Fix for Paginator when accessing out of bounds Pagination page
[ https://issues.apache.org/jira/browse/COCOON-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559988#action_12559988 ] Vadim Gritsenko commented on COCOON-2162: - One thing I would change in patch though - it would be better to throw PageNotFoundException which would extend ResourceNotFoundException, this would allow error hander to distinguish missing file vs missing page. > [PATCH] Fix for Paginator when accessing out of bounds Pagination page > -- > > Key: COCOON-2162 > URL: https://issues.apache.org/jira/browse/COCOON-2162 > Project: Cocoon > Issue Type: Improvement > Components: Blocks: (Undefined) >Affects Versions: 2.1.10, 2.1.11 >Reporter: Drew Buschhorn >Priority: Minor > Attachments: paginator.diff, screenshot-1.jpg > > > The Paginator transformer for apache cocoon will allow out of page-range > requests. > I've added the below logic-test into my own copy of cocoon, and that seems to > fix the problem. > Please let me know if you think 1. this is valid and 2. that it should be > placed into svn for the 2.1.x version of cocoon. > Example: > http://localhost/samples/paginator/text(5) > will return a valid empty file before patch (despite there being only 4 pages > worth of data to paginate) > after patch, returns ResourceNotFound/404. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2162) [PATCH] Fix for Paginator when accessing out of bounds Pagination page
[ https://issues.apache.org/jira/browse/COCOON-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559984#action_12559984 ] Vadim Gritsenko commented on COCOON-2162: - I think 404 is appropriate for this case. Requested resource is indeed does not exist, and it should be up to the component user to handle it however he likes it. > [PATCH] Fix for Paginator when accessing out of bounds Pagination page > -- > > Key: COCOON-2162 > URL: https://issues.apache.org/jira/browse/COCOON-2162 > Project: Cocoon > Issue Type: Improvement > Components: Blocks: (Undefined) >Affects Versions: 2.1.10, 2.1.11 >Reporter: Drew Buschhorn >Priority: Minor > Attachments: paginator.diff, screenshot-1.jpg > > > The Paginator transformer for apache cocoon will allow out of page-range > requests. > I've added the below logic-test into my own copy of cocoon, and that seems to > fix the problem. > Please let me know if you think 1. this is valid and 2. that it should be > placed into svn for the 2.1.x version of cocoon. > Example: > http://localhost/samples/paginator/text(5) > will return a valid empty file before patch (despite there being only 4 pages > worth of data to paginate) > after patch, returns ResourceNotFound/404. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2158) XMLByteStreamCompiler hard-coded limits of 0xffff Strings prevents large XML documents from being handled in Cocoon
[
https://issues.apache.org/jira/browse/COCOON-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12555932#action_12555932
]
Vadim Gritsenko commented on COCOON-2158:
-
I'd like to point out that attached patch introduces new limit (which is more
likely to occur): text size is now limited to 65k bytes (32k characters or less
of UTF-8).
Another two issues with the patch are:
* It does not take into account that this code was refactored in trunk
* It does not recognize CXML10, introduces CXML11 as replacement.
IMHO It would be easier - and will be compatible - to extend handling of the
large index instead of applying patch as is.
> XMLByteStreamCompiler hard-coded limits of 0x Strings prevents large XML
> documents from being handled in Cocoon
> ---
>
> Key: COCOON-2158
> URL: https://issues.apache.org/jira/browse/COCOON-2158
> Project: Cocoon
> Issue Type: Bug
> Components: * Cocoon Core
>Affects Versions: 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.1.12-dev
> (Current SVN)
>Reporter: Eric Meyer
>Assignee: Antonio Gallardo
>Priority: Critical
> Attachments: cocoon-xmlbytestream.patch
>
>
> The hard-coded limits in XMLByteStreamCompiler prevent Cocoon from handling
> large XML documents.
> See the methods writeString and writeAttributes for the hard coded arbitrary
> maximums:
> if (i > 0x) throw new SAXException("Index too large");
> if (attributes > 0x) throw new SAXException("Too many attributes");
> Additionally, the hand-coded bit manipulation is pretty difficult to change
> in order to work around this.
> I am attaching a patch for 2.1.11 that updates the existing JUnit test case
> to reproduce the problem, as well as a fix to the problem that uses the
> DataInputStream and DataOutputStream for the low-level bit manipulation.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1990) Redirect bug WITHIN sub sitemap WHEN using uri-prefix in map:mount
[ https://issues.apache.org/jira/browse/COCOON-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549634 ] Vadim Gritsenko commented on COCOON-1990: - Alfred, do you mean to say that with this fix, sitemap and root sitemap no longer can be in the same directory? > Redirect bug WITHIN sub sitemap WHEN using uri-prefix in map:mount > -- > > Key: COCOON-1990 > URL: https://issues.apache.org/jira/browse/COCOON-1990 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.1.10 >Reporter: Robert Hoffmann >Assignee: Alfred Nathaniel > Fix For: 2.1.11-dev (Current SVN) > > > Hi cocoon developers, > I found the following problem with redirects within sub-sitemaps WHEN using > the uri-prefix in map:mount... > Test case: > 1) Sitemaps: > Root sitemap >> > ... > > > > > > ...<< > Sub sitemap >> > ... > > > > > http://www.google.com"/> > > ...<< > 2) NOW: When you request "http://testserver/cocoon/test/A.html";... > you should get redirected to B.html WITHIN the sub sitemap (that's why we use > 'cocoon:/B.html' and not 'cocoon://B.html')... > BUT the redirect does NOT work correctly, hence we will not get the > google-site which would be the correct result. > 3) The cocoon.log says: http-11080-Processor23/CocoonServlet: No pipeline > matched request: test/B.html !!! > [So it seems to me that the uri-prefix from the sub-sitemap mount is added in > the this redirect, which might be why it does not match then within the > sub-sitemap.] > 3) Important: This only goes wrong when using the uri-prefix[-remove] > attribute in map:mount > I hope this detailed test case will be helpful to one of the cocoon gurus... > I really would hate if I had to use redirects to the ROOT sitemap (that's not > the idea of sub sitemaps). > Many thanks!!! > Robert > PS: Cocoon really rocks! > -- > Have you tried iHOP yet? http://www.ihop-net.org/UniPub/iHOP/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[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 ] Vadim Gritsenko updated COCOON-1985: Affects version (Component): Parent values: Cocoon Core(10151). Level 1 values: 2.2.0-RC2(10309). Fix version (Component): Parent values: Cocoon Core(10227). Level 1 values: 2.2.0-RC3-dev(10304). Fix Version/s: (was: 2.1.11-dev (Current SVN)) (was: 2.1.10) (was: 2.1.9) Fixed in 2.2 (trunk) > 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-dev (Current SVN), 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, > 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] Closed: (COCOON-2129) MailMessageSender does not allow setting of mail body by URL
[ https://issues.apache.org/jira/browse/COCOON-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vadim Gritsenko closed COCOON-2129. --- Resolution: Fixed Fix Version/s: 2.1.11-dev (Current SVN) Applied to 2.1.x branch too. > MailMessageSender does not allow setting of mail body by URL > > > Key: COCOON-2129 > URL: https://issues.apache.org/jira/browse/COCOON-2129 > Project: Cocoon > Issue Type: Bug > Components: Blocks: Mail >Affects Versions: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) >Reporter: Robin Wyles >Priority: Minor > Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) > > Attachments: MailMessageSender.patch > > > A simple null check on the wrong property prevents MailMessageSender working > when setting the email body content from a URL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2129) MailMessageSender does not allow setting of mail body by URL
[ https://issues.apache.org/jira/browse/COCOON-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vadim Gritsenko updated COCOON-2129: Affects version (Component): Parent values: Blocks: Mail(10170). Level 1 values: 1.0.0-M1(10194). Fix version (Component): Parent values: Blocks: Mail(10242). Level 1 values: 1.0.0-RC1(10267). Fix Version/s: 2.2-dev (Current SVN) Applied to Cocoon trunk > MailMessageSender does not allow setting of mail body by URL > > > Key: COCOON-2129 > URL: https://issues.apache.org/jira/browse/COCOON-2129 > Project: Cocoon > Issue Type: Bug > Components: Blocks: Mail >Affects Versions: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) >Reporter: Robin Wyles >Priority: Minor > Fix For: 2.2-dev (Current SVN) > > Attachments: MailMessageSender.patch > > > A simple null check on the wrong property prevents MailMessageSender working > when setting the email body content from a URL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2138) Unable to mount sitemap from Source
Unable to mount sitemap from Source --- Key: COCOON-2138 URL: https://issues.apache.org/jira/browse/COCOON-2138 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Vadim Gritsenko Priority: Blocker Currently it is possible to mount/load sitemaps only when they are residing on a file system (or in classpath). But if sitemap location is a Source (any source supported by Cocoon, such as xmldb:), sitemap location will be incorrectly resolved by Spring and it will fail with exception. Reproduced by: http://localhost:/cocoon-xmldb-sample/xmount/ Exception: Caused by: java.io.FileNotFoundException: ServletContext resource [/xmldb:xindice-embed:///db/cocoon/sitemap] cannot be resolved to URL because it does not exist at org.springframework.web.context.support.ServletContextResource.getURL(ServletContextResource.java:112) at org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.convertSitemap(ConfigurationReader.java:222) at org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.readSitemap(ConfigurationReader.java:100) at org.apache.cocoon.core.container.spring.avalon.SitemapElementParser.readConfiguration(SitemapElementParser.java:67) at org.apache.cocoon.core.container.spring.avalon.BridgeElementParser.parse(BridgeElementParser.java:74) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2110) Evaluate expressions defined in cocooon-expression-language-api in Sitemap engine
[
https://issues.apache.org/jira/browse/COCOON-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519191
]
Vadim Gritsenko commented on COCOON-2110:
-
I'm not sure I can recall this decision - to change the start char. First, it
is backward incompatible change, which means it can't be done in 2.2 - only in
2.3, if ever. And second, at this moment, in cforms samples alone, there are 56
#{foo} expressions or so. Dropping support for that would note be wise.
> Evaluate expressions defined in cocooon-expression-language-api in Sitemap
> engine
> -
>
> Key: COCOON-2110
> URL: https://issues.apache.org/jira/browse/COCOON-2110
> Project: Cocoon
> Issue Type: New Feature
> Components: - Components: Sitemap, - Expression language
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Grzegorz Kossakowski
>Assignee: Grzegorz Kossakowski
> Fix For: 2.2-dev (Current SVN)
>
>
> Description of the task is relatively simple; all I want to achieve is to
> make possible following construct in sitemap:
>
>
>
> assuming that JXPath (used above) is default EL of choice. Of course one
> would be able to use following construct:
>
>value="${jexl:cocoon.request.some_param}"/>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2110) Evaluate expressions defined in cocooon-expression-language-api in Sitemap engine
[
https://issues.apache.org/jira/browse/COCOON-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519184
]
Vadim Gritsenko commented on COCOON-2110:
-
Don't we have a history of using #{foo} for jxpath and ${foo} for jexl? Doing
it differently would just result in more confusion. I'd rather have it more
uniform throughout.
> Evaluate expressions defined in cocooon-expression-language-api in Sitemap
> engine
> -
>
> Key: COCOON-2110
> URL: https://issues.apache.org/jira/browse/COCOON-2110
> Project: Cocoon
> Issue Type: New Feature
> Components: - Components: Sitemap, - Expression language
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Grzegorz Kossakowski
>Assignee: Grzegorz Kossakowski
> Fix For: 2.2-dev (Current SVN)
>
>
> Description of the task is relatively simple; all I want to achieve is to
> make possible following construct in sitemap:
>
>
>
> assuming that JXPath (used above) is default EL of choice. Of course one
> would be able to use following construct:
>
>value="${jexl:cocoon.request.some_param}"/>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2109) Incorrent cleanup of expired continuations
[ https://issues.apache.org/jira/browse/COCOON-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519018 ] Vadim Gritsenko commented on COCOON-2109: - Jorg - sort is happening on insert. Miguel - what I meant is to do set.remove(w); w.setLastAccessTime(); set.add(w); Of course if somebody calls setLastAccessTime from outside, this code would have to be refactored if implementing approach above. > Incorrent cleanup of expired continuations > -- > > Key: COCOON-2109 > URL: https://issues.apache.org/jira/browse/COCOON-2109 > Project: Cocoon > Issue Type: Bug > Components: - Flowscript >Affects Versions: 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11-dev (Current > SVN) >Reporter: Miguel Cuervo > Attachments: ContinuationsManagerImpl.java.patch > > > The class ContinuationsManagerImpl is in charge of cleaning up expired > continuations. It does so in the method expireContinuations. In this method > there is a loop using an iterator over a SortedSet of continuations > (WebContinuation). The loop is expecting that the continuations are ordered > from oldest to newest. The loop stops in the first continuation that is not > expired. The logic is correct since all the newer continuations could not be > expired. > However, the problem comes from the ordering of the continuations. To have > the continuations ordered by lastAccessTime the program uses a TreeSet as a > container of the continuations. The continuations implement the compareTo > interface using the lastAccessTime and when a continuation is inserted in the > container, it gets correctly ordered. But after the insertion, the > continuation can change its lastAccessTime using the method > WebContinuation.updateLastAccessTime() called from > WebContinuation.getContinuation(). The ordering of the TreeSet is not updated > with the change and when the program iterates over it, it does not get the > continuations in the order expected. > The result of this bug is that under hevy load many expired continuations may > be around before the loop actually clean them up, eating memory resources and > causing OutOfMemory. > To fix it, a patch is provided that uses a HashSet for the continuations > container and loops over all the continuations to check if they have expired. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2109) Incorrent cleanup of expired continuations
[ https://issues.apache.org/jira/browse/COCOON-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519019 ] Vadim Gritsenko commented on COCOON-2109: - PS Yes I agree that re-creating the set *is not* a solution. In this case iteration over complete set is acceptable. > Incorrent cleanup of expired continuations > -- > > Key: COCOON-2109 > URL: https://issues.apache.org/jira/browse/COCOON-2109 > Project: Cocoon > Issue Type: Bug > Components: - Flowscript >Affects Versions: 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11-dev (Current > SVN) >Reporter: Miguel Cuervo > Attachments: ContinuationsManagerImpl.java.patch > > > The class ContinuationsManagerImpl is in charge of cleaning up expired > continuations. It does so in the method expireContinuations. In this method > there is a loop using an iterator over a SortedSet of continuations > (WebContinuation). The loop is expecting that the continuations are ordered > from oldest to newest. The loop stops in the first continuation that is not > expired. The logic is correct since all the newer continuations could not be > expired. > However, the problem comes from the ordering of the continuations. To have > the continuations ordered by lastAccessTime the program uses a TreeSet as a > container of the continuations. The continuations implement the compareTo > interface using the lastAccessTime and when a continuation is inserted in the > container, it gets correctly ordered. But after the insertion, the > continuation can change its lastAccessTime using the method > WebContinuation.updateLastAccessTime() called from > WebContinuation.getContinuation(). The ordering of the TreeSet is not updated > with the change and when the program iterates over it, it does not get the > continuations in the order expected. > The result of this bug is that under hevy load many expired continuations may > be around before the loop actually clean them up, eating memory resources and > causing OutOfMemory. > To fix it, a patch is provided that uses a HashSet for the continuations > container and loops over all the continuations to check if they have expired. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2109) Incorrent cleanup of expired continuations
[ https://issues.apache.org/jira/browse/COCOON-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519002 ] Vadim Gritsenko commented on COCOON-2109: - It would be easier to fix tree set ordering, don't you think? > Incorrent cleanup of expired continuations > -- > > Key: COCOON-2109 > URL: https://issues.apache.org/jira/browse/COCOON-2109 > Project: Cocoon > Issue Type: Bug > Components: - Flowscript >Affects Versions: 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11-dev (Current > SVN) >Reporter: Miguel Cuervo > Attachments: ContinuationsManagerImpl.java.patch > > > The class ContinuationsManagerImpl is in charge of cleaning up expired > continuations. It does so in the method expireContinuations. In this method > there is a loop using an iterator over a SortedSet of continuations > (WebContinuation). The loop is expecting that the continuations are ordered > from oldest to newest. The loop stops in the first continuation that is not > expired. The logic is correct since all the newer continuations could not be > expired. > However, the problem comes from the ordering of the continuations. To have > the continuations ordered by lastAccessTime the program uses a TreeSet as a > container of the continuations. The continuations implement the compareTo > interface using the lastAccessTime and when a continuation is inserted in the > container, it gets correctly ordered. But after the insertion, the > continuation can change its lastAccessTime using the method > WebContinuation.updateLastAccessTime() called from > WebContinuation.getContinuation(). The ordering of the TreeSet is not updated > with the change and when the program iterates over it, it does not get the > continuations in the order expected. > The result of this bug is that under hevy load many expired continuations may > be around before the loop actually clean them up, eating memory resources and > causing OutOfMemory. > To fix it, a patch is provided that uses a HashSet for the continuations > container and loops over all the continuations to check if they have expired. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-1956) Project site "Changes" page should be split up by release
[ http://issues.apache.org/jira/browse/COCOON-1956?page=all ] Vadim Gritsenko closed COCOON-1956. --- Fix Version/s: 2.2-dev (Current SVN) Resolution: Fixed > Project site "Changes" page should be split up by release > - > > Key: COCOON-1956 > URL: http://issues.apache.org/jira/browse/COCOON-1956 > Project: Cocoon > Issue Type: Improvement > Components: - Documentation >Affects Versions: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) >Reporter: Mark Lundquist >Priority: Minor > Fix For: 2.2-dev (Current SVN) > > > The "Changes" page (http://cocoon.apache.org/2.1/changes.html) is getting > really long. I think we should split this material up, with a separate page > for each release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1956) Project site "Changes" page should be split up by release
[ http://issues.apache.org/jira/browse/COCOON-1956?page=comments#action_12451385 ] Vadim Gritsenko commented on COCOON-1956: - Changes for 2.2 will be a separate page, so Changes for 2.1 won't be growing anymore (after 2.1.10 release). Changes list for 2.2 is already split into multiple pages, one page per block. So, should I just close this issue? > Project site "Changes" page should be split up by release > - > > Key: COCOON-1956 > URL: http://issues.apache.org/jira/browse/COCOON-1956 > Project: Cocoon > Issue Type: Improvement > Components: - Documentation >Affects Versions: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) >Reporter: Mark Lundquist >Priority: Minor > > The "Changes" page (http://cocoon.apache.org/2.1/changes.html) is getting > really long. I think we should split this material up, with a separate page > for each release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1928) Add the ability to pass the doctype in parameter for Serializer
[
http://issues.apache.org/jira/browse/COCOON-1928?page=comments#action_12441449
]
Vadim Gritsenko commented on COCOON-1928:
-
To Joerg:
Doctype is configurable right now, see Cocoon samples:
-//W3C//DTD HTML 4.01 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd
What Cyriaque is suggesting is syntax change, which I am against since it does
not give anything, and introduces inconsistent syntax.
To Cyriaque:
You are mistaken, syntax change will not help you. Variable substitution in
component configuration has to happen manually. Sitemap variable susbstitution
in parameter values is happening only within section, not within
section.
Another mistake is to confuse properties substitution in cocoon 2.2 (using ${}
syntax) with sitemap variable substitution (using {} syntax).
Vadim
> Add the ability to pass the doctype in parameter for Serializer
> ---
>
> Key: COCOON-1928
> URL: http://issues.apache.org/jira/browse/COCOON-1928
> Project: Cocoon
> Issue Type: New Feature
> Components: * Cocoon Core
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Cyriaque Dupoirieux
>Priority: Minor
> Attachments: AbstractTextSerializer.diff
>
>
> I need - with forrest - to get the doctype-system and doctype-public in a
> parameter like following :
> name="xhtml" pool-grow="2" pool-max="64" pool-min="2"
> src="org.apache.cocoon.serialization.XMLSerializer">
>
> value="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"; />
> UTF-8
> yes
> no
>
> here is a patch which apply to the AbstractTextSerializer.
> in case the doctype is also found in the childs, child have priority.
> Regards,
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-574) [PATCH] fixed redirect under JRun 3.1
[ http://issues.apache.org/jira/browse/COCOON-574?page=all ] Vadim Gritsenko updated COCOON-574: --- Bugzilla Id: (was: 16537) Affects Version/s: 2.1.10-dev (current SVN) > [PATCH] fixed redirect under JRun 3.1 > - > > Key: COCOON-574 > URL: http://issues.apache.org/jira/browse/COCOON-574 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.0.5-dev (Current CVS), 2.1.10-dev (current SVN) > Environment: Operating System: All > Platform: All >Reporter: Michal Durdina > Assigned To: Cocoon Developers Team > Attachments: HttpEnvironment.java.diff, release_2_1_5_1.patch_3.txt > > > Proposed WebSphere 4.0/4.0.1 response.encodeRedirectURL() bug fix (by VG) > doesn't work for JRun 3.1. It produces double base path fragment on the > resulting URL, when it mistakenly assumes WS bug. > I.e. for redirect to "../myfile.html" at "http://host/webapp/mydir/main.html"; > the result is "http://host/webapp/mydir/webapp/mydir/../myfile.html"; on JRun. > The patch adds additional check for output from encodeRedirectURL() and ONLY > IF > it actually does not contain expected base path, it adds one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1462) NullPointerException in SQLTransformer
[ http://issues.apache.org/jira/browse/COCOON-1462?page=all ] Vadim Gritsenko closed COCOON-1462. --- Fix Version/s: 2.2-dev (Current SVN) 2.1.10-dev (current SVN) Resolution: Fixed incorporated into current code > NullPointerException in SQLTransformer > -- > > Key: COCOON-1462 > URL: http://issues.apache.org/jira/browse/COCOON-1462 > Project: Cocoon > Issue Type: Bug > Components: Blocks: Databases >Affects Versions: 2.1.8 > Environment: Operating System: All > Platform: All >Reporter: Brad > Assigned To: Vadim Gritsenko > Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) > > Attachments: cocoon.patch, cocoon_patch > > > In > src/blocks/databases/java/org/apache/cocoon/transformation/SQLTransformer.java > around line 1134 are the lines > Clob clob = rs.getClob(i); > InputStream inputStream = clob.getAsciiStream(); > which cause a NPE when getClob() returns null. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1462) NullPointerException in SQLTransformer
[ http://issues.apache.org/jira/browse/COCOON-1462?page=all ] Vadim Gritsenko reassigned COCOON-1462: --- Assignee: Vadim Gritsenko (was: Cocoon Developers Team) > NullPointerException in SQLTransformer > -- > > Key: COCOON-1462 > URL: http://issues.apache.org/jira/browse/COCOON-1462 > Project: Cocoon > Issue Type: Bug > Components: Blocks: Databases >Affects Versions: 2.1.8 > Environment: Operating System: All > Platform: All >Reporter: Brad > Assigned To: Vadim Gritsenko > Attachments: cocoon.patch, cocoon_patch > > > In > src/blocks/databases/java/org/apache/cocoon/transformation/SQLTransformer.java > around line 1134 are the lines > Clob clob = rs.getClob(i); > InputStream inputStream = clob.getAsciiStream(); > which cause a NPE when getClob() returns null. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1441) [Patch] Resource leak in DatabaseReader
[ http://issues.apache.org/jira/browse/COCOON-1441?page=all ] Vadim Gritsenko closed COCOON-1441. --- Fix Version/s: 2.2-dev (Current SVN) 2.1.10-dev (current SVN) Resolution: Fixed provided version removes conditional retrieval of the database resource (based on last-modified), so can not be incorporated. Some other suggestions, such as caching database resource component, are incorporated. if setup() is still called twice per cocoon invocation, this is a bug in the core which has to be fixed. > [Patch] Resource leak in DatabaseReader > --- > > Key: COCOON-1441 > URL: http://issues.apache.org/jira/browse/COCOON-1441 > Project: Cocoon > Issue Type: Bug > Components: - Components: Sitemap >Affects Versions: 2.1.8 > Environment: Operating System: Windows XP > Platform: PC >Reporter: Gregor J. Rothfuss > Assigned To: Cocoon Developers Team > Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) > > Attachments: FrugalDatabaseReader.java > > > The DatabaseReader does not close the database connection in all cases, which > leads to a leak over time. The attached patch addresses this by being much > more > frugal. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1049) encoding in Content-Type header is not set by serializers
[ http://issues.apache.org/jira/browse/COCOON-1049?page=all ]
Vadim Gritsenko closed COCOON-1049.
---
Fix Version/s: 2.2-dev (Current SVN)
2.1.10-dev (current SVN)
Resolution: Fixed
RFC calls this value "media type". Added comments to getMimeType.
> encoding in Content-Type header is not set by serializers
> -
>
> Key: COCOON-1049
> URL: http://issues.apache.org/jira/browse/COCOON-1049
> Project: Cocoon
> Issue Type: Bug
> Components: * Cocoon Core
>Affects Versions: 2.1.4
> Environment: Operating System: All
> Platform: PC
>Reporter: Stefan Burkard
> Assigned To: Cocoon Developers Team
>Priority: Critical
> Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN)
>
> Attachments: MimeType.patch.txt
>
>
> The Cocoon Serializer does not set the encoding in the HTTP-Header, it just
> sets
> the mime-type in the header. additionally, it writes a meta-tag with mime-type
> and encoding in the html.
> if now any component (for example apache webserver) sets a (wrong) default
> encoding in the header, most browsers use this header-encoding and ignore the
> meta-tag-encoding.
> --
> here is an answer from jan uyttenhove from the cocoon-users-group to my
> question
> regarding this issue. i think this could help the developer:
> ATM, Cocoon set the meta content-type tag with the mime-type and the encoding
> of
> the serializer. Furthermore, response.setContentType *is* called, which is one
> of the ways to set the http encoding header. But it is called with argument
> mime-type only, e.g. response.setContentType("text/html"), and we should be
> able
> to do response.setContentType("text/html; charset=utf-8").
> We should be able to set the full content-type (with charset) in
> HttpEnvironment
> or in AbstractProcessingPipeline. I guess that involves changing at least the
> setSerializer(...) in AbstractProcessingPipeline and passing the encoding.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1922) [PATCH] cocoon-core-sample should be part of the default build, because it is required by the default example webapp
[ http://issues.apache.org/jira/browse/COCOON-1922?page=all ] Vadim Gritsenko closed COCOON-1922. --- Fix Version/s: 2.2-dev (Current SVN) Resolution: Fixed i see it's already there > [PATCH] cocoon-core-sample should be part of the default build, because it is > required by the default example webapp > > > Key: COCOON-1922 > URL: http://issues.apache.org/jira/browse/COCOON-1922 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.2-dev (Current SVN) >Reporter: Lars Trieloff > Fix For: 2.2-dev (Current SVN) > > Attachments: cocoon-core-samples-in-default-build.patch > > > The cocoon-webapp depends on cocoon-core-sample, but this is not part of the > default build, causing a mvn install in trunk to fail. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1873) WildcardURIMatcher returns wrong results for **/*.html
[ http://issues.apache.org/jira/browse/COCOON-1873?page=all ]
Vadim Gritsenko closed COCOON-1873.
---
Fix Version/s: 2.2-dev (Current SVN)
2.1.10-dev (current SVN)
Resolution: Fixed
test executes successfully now.
> WildcardURIMatcher returns wrong results for **/*.html
> --
>
> Key: COCOON-1873
> URL: http://issues.apache.org/jira/browse/COCOON-1873
> Project: Cocoon
> Issue Type: Bug
> Components: * Cocoon Core
>Reporter: Andreas Hartmann
> Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN)
>
>
> URI: foo/bar/baz.html
> Pattern: **/*.html
> {1} is replaced with foo
> {2} is replaced with bar/baz
> Here's a patch for the test case:
> Index: src/test/org/apache/cocoon/matching/WildcardURIMatcherTestCase.java
> ===
> --- src/test/org/apache/cocoon/matching/WildcardURIMatcherTestCase.java
> (revision 417475)
> +++ src/test/org/apache/cocoon/matching/WildcardURIMatcherTestCase.java
> (working copy)
> @@ -57,4 +57,16 @@
> assertEquals("Test for */*.xml", "test", result.get("1"));
> assertEquals("Test for */*.xml", "something.xmlbla",
> result.get("2"));
> }
> +
> +public void testWildcardURIMatchMultiSinglePattern() throws Exception {
> +getRequest().setRequestURI("foo/bar/baz.html");
> +
> +final Parameters parameters = new Parameters();
> +
> +Map result = match("wildcard-uri", "**/*.html", parameters);
> +assertNotNull("Test if resource exists", result);
> +assertEquals("Test for {1} in **/*.html", "foo/bar",
> result.get("1"));
> +assertEquals("Test for {2} in **/*.html", "baz", result.get("2"));
> +}
> +
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1643) cocoon 2.2.0 dev svn checkout doesn't work with tomcat
[ http://issues.apache.org/jira/browse/COCOON-1643?page=all ] Vadim Gritsenko closed COCOON-1643. --- Fix Version/s: 2.2-dev (Current SVN) Resolution: Fixed There is no build.sh anymore, but if you to follow README.txt, resulting webapp works just fine under Tomcat 5.0 > cocoon 2.2.0 dev svn checkout doesn't work with tomcat > -- > > Key: COCOON-1643 > URL: http://issues.apache.org/jira/browse/COCOON-1643 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.2-dev (Current SVN) > Environment: Operating System: Windows XP > Platform: PC >Reporter: Philipp Schmidt > Assigned To: Cocoon Developers Team > Fix For: 2.2-dev (Current SVN) > > > When you do a ./build.sh war and copy the cocoon.war over to the tomcat > webapps > directoy cocoon won't start with the following exception in the tomcat log > file: > 2005-10-12 16:17:09 StandardContext[/cocoon]Errors during initializing Apache > Cocoon 2.2.0-dev : Illegal character in path at index 25: > file:/C:/Programme/Apache Software > Foundation/jakarta-tomcat-5.0.28/webapps/cocoon/ > java.net.URISyntaxException: Illegal character in path at index 25: > file:/C:/Programme/Apache Software > Foundation/jakarta-tomcat-5.0.28/webapps/cocoon/ > at java.net.URI$Parser.fail(URI.java:2752) > at java.net.URI$Parser.checkChars(URI.java:2925) > at java.net.URI$Parser.parseHierarchical(URI.java:3009) > at java.net.URI$Parser.parse(URI.java:2957) > at java.net.URI.(URI.java:574) > at > org.apache.cocoon.components.blocks.BlockContext.getContextURL(BlockContext.java:184) > at > org.apache.cocoon.components.blocks.BlockManager.initialize(BlockManager.java:103) > at > org.apache.cocoon.components.LifecycleHelper.setupComponent(LifecycleHelper.java:165) > at > org.apache.cocoon.components.LifecycleHelper.setupComponent(LifecycleHelper.java:124) > at > org.apache.cocoon.components.blocks.BlocksManager.initialize(BlocksManager.java:143) > at > org.apache.avalon.framework.container.ContainerUtil.initialize(ContainerUtil.java:244) > at > org.apache.cocoon.core.container.ComponentFactory.setupInstance(ComponentFactory.java:166) > at > org.apache.cocoon.core.container.ComponentFactory.newInstance(ComponentFactory.java:139) > at > org.apache.cocoon.core.container.handler.ThreadSafeComponentHandler.doInitialize(ThreadSafeComponentHandler.java:53) > at > org.apache.cocoon.core.container.handler.AbstractComponentHandler.initialize(AbstractComponentHandler.java:273) > at > org.apache.cocoon.core.container.CoreServiceManager.initialize(CoreServiceManager.java:227) > at > org.apache.cocoon.components.container.CocoonServiceManager.initialize(CocoonServiceManager.java:81) > at > org.apache.avalon.framework.container.ContainerUtil.initialize(ContainerUtil.java:244) > at org.apache.cocoon.Cocoon.initialize(Cocoon.java:255) > at > org.apache.avalon.framework.container.ContainerUtil.initialize(ContainerUtil.java:244) > at org.apache.cocoon.core.CoreUtil.createCocoon(CoreUtil.java:667) > at org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:223) > at > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1029) > at > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:862) > at > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4013) > at > org.apache.catalina.core.StandardContext.start(StandardContext.java:4357) > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:823) > at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807) > at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:595) > at > org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeployer.java:277) > at org.apache.catalina.core.StandardHost.install(StandardHost.java:832) > at > org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:922) > at > org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:652) > at > org.apache.catalina.manager.ManagerServlet.doPut(ManagerServlet.java:400) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:712) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) > at > org.apache.catalina.core.StandardValveContext.invokeNext(Standard
[jira] Closed: (COCOON-1456) SourceWritingTransformer write only the first node
[ http://issues.apache.org/jira/browse/COCOON-1456?page=all ] Vadim Gritsenko closed COCOON-1456. --- Fix Version/s: 2.1.8 Resolution: Fixed this problem was fixed in 2.1.8. added a sample. > SourceWritingTransformer write only the first node > -- > > Key: COCOON-1456 > URL: http://issues.apache.org/jira/browse/COCOON-1456 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.1.6 > Environment: Operating System: Linux > Platform: PC >Reporter: Aurélien DEHAY > Assigned To: Cocoon Developers Team > Fix For: 2.1.8 > > Attachments: SourceWritingTransformer.patch, > SourceWritingTransformer.patch > > > The following xml : > > file > > > > > > > > writes the following thing on disk: > > > The following nodes are not writed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1519) [PATCH] TeeTransformer refactoring
[ http://issues.apache.org/jira/browse/COCOON-1519?page=all ] Vadim Gritsenko reassigned COCOON-1519: --- Assignee: Jorg Heymans (was: Cocoon Developers Team) Ok, it's not final anymore. > [PATCH] TeeTransformer refactoring > -- > > Key: COCOON-1519 > URL: http://issues.apache.org/jira/browse/COCOON-1519 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.1.8 > Environment: Operating System: other > Platform: Other >Reporter: Jorg Heymans > Assigned To: Jorg Heymans > Attachments: refactored.diff > > > - delegate to XMLTeePipe now > - variable cleanup and recycle() fixes -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1906) [PATCH] simple-xml binding does not work with non file sources
[ http://issues.apache.org/jira/browse/COCOON-1906?page=all ] Vadim Gritsenko closed COCOON-1906. --- Fix Version/s: 2.2-dev (Current SVN) 2.1.10-dev (current SVN) Resolution: Fixed Assignee: Vadim Gritsenko Patch applied. > [PATCH] simple-xml binding does not work with non file sources > -- > > Key: COCOON-1906 > URL: http://issues.apache.org/jira/browse/COCOON-1906 > Project: Cocoon > Issue Type: Bug > Components: Blocks: Forms, * Cocoon Core >Affects Versions: 2.2-dev (Current SVN) >Reporter: Lars Trieloff > Assigned To: Vadim Gritsenko > Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) > > Attachments: cocoon-forms-javascript-disambiguation.patch, > cocoon-formsbinding-sample.patch, cocoon-formsbinding-sourceutil.patch > > > The cocoon forms flowscript API comes with a helper method form.loadXML, that > retrieves data from an xml document. The current implementation however does > not work with documents that are referenced not as files, but as > SitemapSources, e.g. via the cocoon:/ or xmldb:// pseudo-protocol. In this > case the Rhino engine is unable to resolve the ambiguity between two method > signatures: > org.mozilla.javascript.EvaluatorException: > "resource://org/apache/cocoon/forms/flow/javascript/Form.js", line 287: The > choice of Java constructor toSAX matching JavaScript argument types > (org.apache.cocoon.components.source.impl.SitemapSource,org.apache.cocoon.forms.util.XMLAdapter) > is ambiguous; candidate constructors are: > void toSAX(org.apache.excalibur.xml.sax.XMLizable,org.xml.sax.ContentHandler) > void toSAX(org.apache.excalibur.source.Source,org.xml.sax.ContentHandler) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1906) [PATCH] simple-xml binding does not work with non file sources
[ http://issues.apache.org/jira/browse/COCOON-1906?page=comments#action_12437932 ] Vadim Gritsenko commented on COCOON-1906: - See: http://www.mozilla.org/js/liveconnect/lc3_method_overloading.html (chapter 4). Form.js can be modified to pick the right method. I think this is the same issue: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112777115419222 > [PATCH] simple-xml binding does not work with non file sources > -- > > Key: COCOON-1906 > URL: http://issues.apache.org/jira/browse/COCOON-1906 > Project: Cocoon > Issue Type: Bug > Components: Blocks: Forms, * Cocoon Core >Affects Versions: 2.2-dev (Current SVN) >Reporter: Lars Trieloff > Attachments: cocoon-formsbinding-sample.patch, > cocoon-formsbinding-sourceutil.patch > > > The cocoon forms flowscript API comes with a helper method form.loadXML, that > retrieves data from an xml document. The current implementation however does > not work with documents that are referenced not as files, but as > SitemapSources, e.g. via the cocoon:/ or xmldb:// pseudo-protocol. In this > case the Rhino engine is unable to resolve the ambiguity between two method > signatures: > org.mozilla.javascript.EvaluatorException: > "resource://org/apache/cocoon/forms/flow/javascript/Form.js", line 287: The > choice of Java constructor toSAX matching JavaScript argument types > (org.apache.cocoon.components.source.impl.SitemapSource,org.apache.cocoon.forms.util.XMLAdapter) > is ambiguous; candidate constructors are: > void toSAX(org.apache.excalibur.xml.sax.XMLizable,org.xml.sax.ContentHandler) > void toSAX(org.apache.excalibur.source.Source,org.xml.sax.ContentHandler) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1552) NullPointerException from SQLTransformer
[ http://issues.apache.org/jira/browse/COCOON-1552?page=all ] Vadim Gritsenko closed COCOON-1552: --- Fix Version: 2.2-dev (Current SVN) 2.1.10-dev (current SVN) Resolution: Fixed fixed > NullPointerException from SQLTransformer > > > Key: COCOON-1552 > URL: http://issues.apache.org/jira/browse/COCOON-1552 > Project: Cocoon > Type: Bug > Components: Blocks: Databases > Versions: 2.1.7 > Environment: Operating System: Windows NT > Platform: PC > Reporter: Andrew Stevens > Assignee: Cocoon Developers Team > Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) > > I have a pipeline which consists of a file generator, the SQL transformer, and > an XML serializer. Unfortunately, I forgot to add the database driver to the > load-classes init param, so the DriverManager was unable to find anything to > handle my serverURL and hence the SQL transformer was unable to get a > connection. > I expected to get an error, however, I didn't expect it to be a > NullPointerException (stack trace below). Looks like the transformer needs to > be more careful about what it passes into Xalan? At least in the Xalan 2.6.0 > sources, ensurePrefixIsDeclared method has a check for null namespaces, but > not > for a null rawName...? > java.lang.NullPointerException > at > org.apache.xml.serializer.ToStream.ensurePrefixIsDeclared(ToStream.java:2634) > at org.apache.xml.serializer.ToStream.startElement(ToStream.java:1736) > at > org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1020) > at > org.apache.cocoon.xml.AbstractXMLPipe.startElement(AbstractXMLPipe.java:94) > at > org.apache.cocoon.xml.AbstractXMLPipe.startElement(AbstractXMLPipe.java:94) > at > org.apache.cocoon.transformation.AbstractSAXTransformer.startTransformingElement(AbstractSAXTransformer.java:658) > at > org.apache.cocoon.transformation.SQLTransformer.start(SQLTransformer.java:765) > at > org.apache.cocoon.transformation.SQLTransformer.executeQuery(SQLTransformer.java:323) > at > org.apache.cocoon.transformation.SQLTransformer.endExecuteQueryElement(SQLTransformer.java:476) > at > org.apache.cocoon.transformation.SQLTransformer.endTransformingElement(SQLTransformer.java:738) > at > org.apache.cocoon.transformation.AbstractSAXTransformer.endElement(AbstractSAXTransformer.java:336) > at > org.apache.cocoon.components.sax.XMLTeePipe.endElement(XMLTeePipe.java:89) > at > org.apache.cocoon.components.sax.XMLByteStreamInterpreter.parse(XMLByteStreamInterpreter.java:100) > at > org.apache.cocoon.components.sax.XMLByteStreamInterpreter.deserialize(XMLByteStreamInterpreter.java:73) > at > org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:267) > at > org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:483) > at > org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:120) > at > org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46) > at > org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java(Compiled > Code)) > at > org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java(Compiled > Code)) > at > org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:138) > at > org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java(Compiled > Code)) > at > org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92) > at > org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234) > at > org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176) > at > org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:243) > at > org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:117) > at > org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46) > at > org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNod -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1247) Multiple results not processed by SQLTransformer
[ http://issues.apache.org/jira/browse/COCOON-1247?page=all ]
Vadim Gritsenko closed COCOON-1247:
---
Fix Version: 2.2-dev (Current SVN)
2.1.10-dev (current SVN)
Resolution: Fixed
added support for multiple results - please try it out
> Multiple results not processed by SQLTransformer
>
>
> Key: COCOON-1247
> URL: http://issues.apache.org/jira/browse/COCOON-1247
> Project: Cocoon
> Type: Bug
> Components: Blocks: Databases
> Versions: 2.1.5
> Environment: Operating System: All
> Platform: PC
> Reporter: Andrew Stevens
> Assignee: Cocoon Developers Team
> Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN)
>
> I have a stored procedure which has four results; two update counts, a result
> set (which is what I'm wanting to use in my stylesheet), and another update
> count. Asides from my problem in #30894, this wouldn't work anyway as the
> SQLTransformer only appears to handle the first result. Query.execute() has
> boolean result = pst.execute();
> if ( result ) {
> rs = pst.getResultSet();
> md = rs.getMetaData();
> } else {
> rv = pst.getUpdateCount();
> }
> which sets the variables according to "the form of the *first* result" (to
> quote
> PreparedStatement's javadocs, my emphasis). However, "Some prepared
> statements
> return multiple results" (again, from the javadocs) yet there's nothing in
> SQLTransformer to handle this; Query.next() finishes as soon as it finds an
> update count or the end of the current result set, and getMoreResults() never
> gets called. Obviously, this means it would stop after my stored proc's first
> update count ("1 row inserted" into an audit table) and never get to the real
> data that I'm interested in.
> Even forgetting SPs, you can see the same effect with SQL queries by using two
> SELECTs in a single . If I run e.g.
> select distinct Permission_Code from USER_PERMISSIONS
> select distinct Sys_User_Code from USER_PERMISSIONS
> go
> in ISQL, I get two result sets returned in the output as expected. If I use
>
> select distinct Permission_Code from USER_PERMISSIONS
> select distinct Sys_User_Code from USER_PERMISSIONS
>
> with the SQLTransformer, I only get the first set of values returned. If all
> the results were processed for a query (e.g. a rowset for each result
> containing
> either the row data or a returncode as appropriate, maybe?) then I'd stand
> more
> chance of being able to get my SP working.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1839) exception2html.xslt causes IE display problem
[ http://issues.apache.org/jira/browse/COCOON-1839?page=comments#action_12376532 ] Vadim Gritsenko commented on COCOON-1839: - PS Serializers from org.apache.cocoon.serialization package are "standard", core" Cocoon serializers. Those from org.apache.cocoon..components.serializers package are part of the optional serialization block, and are "optional", "advanced" serializers. > exception2html.xslt causes IE display problem > > > Key: COCOON-1839 > URL: http://issues.apache.org/jira/browse/COCOON-1839 > Project: Cocoon > Type: Bug > Components: * Cocoon Core > Versions: 2.1.9 > Reporter: Eric Meyer > Priority: Minor > Attachments: exception2xhtml-patch.txt > > The IE rendering engine will show a blank page if the document contains a > minimal (self-closing) tag. > By putting in an nbsp ( ) or a new line, the XSLT produces > , which then allows IE to properly display the page. > The attached page (license granted to asf) adds a non-breaking space to keep > the tag from being collapsed. > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1839) exception2html.xslt causes IE display problem
[ http://issues.apache.org/jira/browse/COCOON-1839?page=comments#action_12376530 ] Vadim Gritsenko commented on COCOON-1839: - Eric, Above serializer declaration (oacs-xhtml11) is not valid, even if it works. It is not either HTML nor XHTML. For XHTML, you have to use XMLSerializer, since XHTML is an XML, and you have to use correct XHTML mime type [1]. For HTML, you have to use HTML's document type, not XHTML's. Vadim [1] http://www.w3.org/TR/xhtml-media-types/ > exception2html.xslt causes IE display problem > > > Key: COCOON-1839 > URL: http://issues.apache.org/jira/browse/COCOON-1839 > Project: Cocoon > Type: Bug > Components: * Cocoon Core > Versions: 2.1.9 > Reporter: Eric Meyer > Priority: Minor > Attachments: exception2xhtml-patch.txt > > The IE rendering engine will show a blank page if the document contains a > minimal (self-closing) tag. > By putting in an nbsp ( ) or a new line, the XSLT produces > , which then allows IE to properly display the page. > The attached page (license granted to asf) adds a non-breaking space to keep > the tag from being collapsed. > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1520) Database / avalon problems
[ http://issues.apache.org/jira/browse/COCOON-1520?page=all ] Vadim Gritsenko closed COCOON-1520: --- Resolution: Won't Fix > Database / avalon problems > -- > > Key: COCOON-1520 > URL: http://issues.apache.org/jira/browse/COCOON-1520 > Project: Cocoon > Type: Bug > Components: Blocks: (Undefined) > Versions: 2.1.7 > Environment: Operating System: other > Platform: PC > Reporter: Hugo Marcelino > Assignee: Cocoon Developers Team > Fix For: 2.1.9-dev (current SVN) > > Hi developers. > My name is Hugo Marcelino, and i come across with this bug. > If you setup a connection pool to a database in cocoon.xconf and the > connection > is not available, you will get the web page working and never terminating, > just > like it is waiting for an answer. (no timeout). > this situation happens if you refresh (ctrl + f5) your page about three times, > and at the third time you'll see this happening, but at the first two , it > works > ok(just doesn't return anything, witch is ok!). > This was made with cocoon-2.1.7 and j2sdk1.4.2_08 and with mysql connector > For a better cocoon... > Hugo Marcelino > 31-05-2005 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (COCOON-1520) Database / avalon problems
[ http://issues.apache.org/jira/browse/COCOON-1520?page=all ] Vadim Gritsenko reopened COCOON-1520: - changing resolution > Database / avalon problems > -- > > Key: COCOON-1520 > URL: http://issues.apache.org/jira/browse/COCOON-1520 > Project: Cocoon > Type: Bug > Components: Blocks: (Undefined) > Versions: 2.1.7 > Environment: Operating System: other > Platform: PC > Reporter: Hugo Marcelino > Assignee: Cocoon Developers Team > Fix For: 2.1.9-dev (current SVN) > > Hi developers. > My name is Hugo Marcelino, and i come across with this bug. > If you setup a connection pool to a database in cocoon.xconf and the > connection > is not available, you will get the web page working and never terminating, > just > like it is waiting for an answer. (no timeout). > this situation happens if you refresh (ctrl + f5) your page about three times, > and at the third time you'll see this happening, but at the first two , it > works > ok(just doesn't return anything, witch is ok!). > This was made with cocoon-2.1.7 and j2sdk1.4.2_08 and with mysql connector > For a better cocoon... > Hugo Marcelino > 31-05-2005 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1520) Database / avalon problems
[ http://issues.apache.org/jira/browse/COCOON-1520?page=all ] Vadim Gritsenko closed COCOON-1520: --- Fix Version: 2.1.9-dev (current SVN) Resolution: Fixed The issue is caused by database pool configuration. You should not be using blocking pool without specifying any timeout -- if you want your xsp page execution to finish in this millenium. Please take a look at excalibur docs for pool config, or check out latest src/blocks/databases/conf/datasources.xconf file. > Database / avalon problems > -- > > Key: COCOON-1520 > URL: http://issues.apache.org/jira/browse/COCOON-1520 > Project: Cocoon > Type: Bug > Components: Blocks: (Undefined) > Versions: 2.1.7 > Environment: Operating System: other > Platform: PC > Reporter: Hugo Marcelino > Assignee: Cocoon Developers Team > Fix For: 2.1.9-dev (current SVN) > > Hi developers. > My name is Hugo Marcelino, and i come across with this bug. > If you setup a connection pool to a database in cocoon.xconf and the > connection > is not available, you will get the web page working and never terminating, > just > like it is waiting for an answer. (no timeout). > this situation happens if you refresh (ctrl + f5) your page about three times, > and at the third time you'll see this happening, but at the first two , it > works > ok(just doesn't return anything, witch is ok!). > This was made with cocoon-2.1.7 and j2sdk1.4.2_08 and with mysql connector > For a better cocoon... > Hugo Marcelino > 31-05-2005 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1363) [Scratchpad] bugs in CookieCreatorAction
[ http://issues.apache.org/jira/browse/COCOON-1363?page=all ] Vadim Gritsenko closed COCOON-1363: --- Fix Version: 2.2-dev (Current SVN) Resolution: Fixed fixed > [Scratchpad] bugs in CookieCreatorAction > > > Key: COCOON-1363 > URL: http://issues.apache.org/jira/browse/COCOON-1363 > Project: Cocoon > Type: Bug > Components: Blocks: (Undefined) > Versions: 2.2-dev (Current SVN) > Environment: Operating System: Windows XP > Platform: PC > Reporter: Dean Cording > Assignee: Cocoon Developers Team > Fix For: 2.2-dev (Current SVN) > > The documentation regarding cookie maxage parameter is incorrect. > maxage shold be set to -1 define a session cookie or to 0 to delete the > cookie. > The action also returns a null map, which result in anything contained in the > action never being run as null is considered an action failure. Should > return > an empty Map object instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1350) XUpdate bug
[ http://issues.apache.org/jira/browse/COCOON-1350?page=all ] Vadim Gritsenko updated COCOON-1350: Bugzilla Id: (was: 32274) Component: Blocks: XML-DB (was: Blocks: (Undefined)) Description: XUpdate does not remove the temporary tree it creates while updating a resource. Please, see http://marc.theaimsgroup.com/?l=xindice-users&m=109949860123580&w=2 was: XUpdate does not remove the temporary tree it creates while updating a resource. Please, see http://marc.theaimsgroup.com/?l=xindice-users&m=109949860123580&w=2 > XUpdate bug > --- > > Key: COCOON-1350 > URL: http://issues.apache.org/jira/browse/COCOON-1350 > Project: Cocoon > Type: Bug > Components: Blocks: XML-DB > Versions: 2.1.5 > Environment: Operating System: Windows 2000 > Platform: PC > Reporter: Timur Izhbulatov > Assignee: Cocoon Developers Team > > XUpdate does not remove the temporary tree it creates while updating a > resource. > Please, see > http://marc.theaimsgroup.com/?l=xindice-users&m=109949860123580&w=2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-529) XSPUtil.relativeFilename() returns differents results for different containers
[ http://issues.apache.org/jira/browse/COCOON-529?page=all ] Vadim Gritsenko updated COCOON-529: --- Bugzilla Id: (was: 15302) Component: Blocks: XSP (was: - Components: Avalon) Description: XSPUtil.relativeFilename throws an NPE when the file being passed as parameter does not exist. Stacktrace: Original exception : java.lang.NullPointerException at org.apache.cocoon.components.language.markup.xsp.XSPUtil.relativeFilename(XSPUtil.java:142) at org.apache.cocoon.www.test_xsp.generate(/home/mb/daten/nobak/builds/tomcat/work/Standalone/localhost/cocoon/cocoon-files/org/apache/cocoon/www/test_xsp.java:118) at org.apache.cocoon.generation.ServerPagesGenerator.generate(ServerPagesGenerator.java:258) at org.apache.cocoon.components.pipeline.CachingEventPipeline.process(CachingEventPipeline.java:250) at org.apache.cocoon.components.pipeline.CachingStreamPipeline.process(CachingStreamPipeline.java:395) at org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:154) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:85) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:166) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:109) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:151) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:109) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:145) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:332) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:293) at org.apache.cocoon.Cocoon.process(Cocoon.java:579) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1043) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:471) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2396) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:405) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:380) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:508) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:533) at java.lang.Thread.run(Thread.java:536) was: XSPUtil.relativeFilename throws an NPE when the file being passed as parameter does not exist. Stacktrace: Origi
[jira] Updated: (COCOON-892) jsp block functionality broken, running on resin 3.0.x
[ http://issues.apache.org/jira/browse/COCOON-892?page=all ] Vadim Gritsenko updated COCOON-892: --- Bugzilla Id: (was: 24871) Component: Blocks: Java Server Pages (was: - Components: Avalon) Description: compiled and installed cocoon 2.1.2, running on the resin 3.0.4 application server. everything seems to be working just fine, though when trying to run jsp within cocoon i get a java null pointer exception. this bug was also confirmed by joerg heinicki on the users@cocoon.apache.org mailing list, see emails <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, and <[EMAIL PROTECTED]>. the error we get is Original Exception: java.lang.NullPointerException at com.caucho.jsp.BufferedJspWriter.flushBuffer(BufferedJspWriter.java:424) at com.caucho.jsp.BufferedJspWriter.privateClose(BufferedJspWriter.java:372) at com.caucho.jsp.PageContextImpl.release(PageContextImpl.java:1014) at com.caucho.jsp.QJspFactory.freePageContext(QJspFactory.java:115) at _samples._jsp._welcome__jsp._jspService(_welcome__jsp.java:37) at com.caucho.jsp.JavaPage.service(JavaPage.java:75) at com.caucho.jsp.QServlet.service(QServlet.java:164) at org.apache.cocoon.components.jsp.JSPEngineImpl.executeJSP(JSPEngineImpl.java:122) at org.apache.cocoon.generation.JspGenerator.generate(JspGenerator.java:114) works every time :) was: compiled and installed cocoon 2.1.2, running on the resin 3.0.4 application server. everything seems to be working just fine, though when trying to run jsp within cocoon i get a java null pointer exception. this bug was also confirmed by joerg heinicki on the users@cocoon.apache.org mailing list, see emails <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, and <[EMAIL PROTECTED]>. the error we get is Original Exception: java.lang.NullPointerException at com.caucho.jsp.BufferedJspWriter.flushBuffer(BufferedJspWriter.java:424) at com.caucho.jsp.BufferedJspWriter.privateClose(BufferedJspWriter.java:372) at com.caucho.jsp.PageContextImpl.release(PageContextImpl.java:1014) at com.caucho.jsp.QJspFactory.freePageContext(QJspFactory.java:115) at _samples._jsp._welcome__jsp._jspService(_welcome__jsp.java:37) at com.caucho.jsp.JavaPage.service(JavaPage.java:75) at com.caucho.jsp.QServlet.service(QServlet.java:164) at org.apache.cocoon.components.jsp.JSPEngineImpl.executeJSP(JSPEngineImpl.java:122) at org.apache.cocoon.generation.JspGenerator.generate(JspGenerator.java:114) works every time :) > jsp block functionality broken, running on resin 3.0.x > -- > > Key: COCOON-892 > URL: http://issues.apache.org/jira/browse/COCOON-892 > Project: Cocoon > Type: Bug > Components: Blocks: Java Server Pages > Versions: 2.1.2 > Environment: Operating System: All > Platform: All > Reporter: Robert Andersson > Assignee: Cocoon Developers Team > > compiled and installed cocoon 2.1.2, running on the resin 3.0.4 application > server. everything seems to be working just fine, though when trying to run > jsp > within cocoon i get a java null pointer exception. this bug was also confirmed > by joerg heinicki on the users@cocoon.apache.org mailing list, see emails > <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, > and <[EMAIL PROTECTED]>. > the error we get is > Original Exception: java.lang.NullPointerException > at > com.caucho.jsp.BufferedJspWriter.flushBuffer(BufferedJspWriter.java:424) > at > com.caucho.jsp.BufferedJspWriter.privateClose(BufferedJspWriter.java:372) > at com.caucho.jsp.PageContextImpl.release(PageContextImpl.java:1014) > at com.caucho.jsp.QJspFactory.freePageContext(QJspFactory.java:115) > at _samples._jsp._welcome__jsp._jspService(_welcome__jsp.java:37) > at com.caucho.jsp.JavaPage.service(JavaPage.java:75) > at com.caucho.jsp.QServlet.service(QServlet.java:164) > at > org.apache.cocoon.components.jsp.JSPEngineImpl.executeJSP(JSPEngineImpl.java:122) > at > org.apache.cocoon.generation.JspGenerator.generate(JspGenerator.java:114) > works every time :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1170) [PATCH] precompile xsp's without starting URI
[ http://issues.apache.org/jira/browse/COCOON-1170?page=all ] Vadim Gritsenko updated COCOON-1170: Bugzilla Id: (was: 29360) Component: Blocks: XSP (was: - Components: Avalon) > [PATCH] precompile xsp's without starting URI > - > > Key: COCOON-1170 > URL: http://issues.apache.org/jira/browse/COCOON-1170 > Project: Cocoon > Type: Bug > Components: Blocks: XSP > Versions: 2.1.5 > Environment: Operating System: All > Platform: PC > Reporter: Andrea Poeschel > Assignee: Cocoon Developers Team > Attachments: precompile-xsp.zip, xsp-precompile-patch > > I want precompile my xsp's with the Command line Interface using by ant. > snipped from build.xml: > > in Cocoon 2.1.4 works this fine, but not Cocoon 2.1.5 > Error: Please, specify at least one starting URI. > Snipped from your documentation: > "If no URIs are specified, it will scan all directories within the context > directory looking for XSP files, each of which will be compiled." > Only we can use this variant. The variant with the starting URI functioned > not > with ant without application server, datebase, ours license service etc. > Greetings from > Andrea Pöschel > Knowledge Engine Development -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1232) [PATCH] NEW--ModuleDB Action for ORACLE( auto. increment )
[ http://issues.apache.org/jira/browse/COCOON-1232?page=all ] Vadim Gritsenko updated COCOON-1232: Bugzilla Id: (was: 30490) Component: - Components: Sitemap (was: - Components: Avalon) Description: 2 impl. of autoincrement modules for ORACLE. Usage details are included in the source and will be available thru javadoc. was: 2 impl. of autoincrement modules for ORACLE. Usage details are included in the source and will be available thru javadoc. > [PATCH] NEW--ModuleDB Action for ORACLE( auto. increment ) > -- > > Key: COCOON-1232 > URL: http://issues.apache.org/jira/browse/COCOON-1232 > Project: Cocoon > Type: Bug > Components: - Components: Sitemap > Versions: 2.1.8 > Environment: Operating System: All > Platform: All > Reporter: T.C. Yu > Assignee: Cocoon Developers Team > Attachments: oraAutoInc.zip > > 2 impl. of autoincrement modules for ORACLE. > Usage details are included in the source and will be available thru javadoc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-910) [PATCH] sitemap parameters support for SVGSerializer
[ http://issues.apache.org/jira/browse/COCOON-910?page=all ] Vadim Gritsenko updated COCOON-910: --- Bugzilla Id: (was: 25100) Component: - Components: Sitemap (was: - Components: Avalon) Description: This patch aims to add support for sitemap parameters allowing a user to override the default configuration of the serializer with sitemap parameters. The main changes come with the implementation of the SitemapModelComponent interface and the use of a new inner class to keep information about the batik trancoding hints. was: This patch aims to add support for sitemap parameters allowing a user to override the default configuration of the serializer with sitemap parameters. The main changes come with the implementation of the SitemapModelComponent interface and the use of a new inner class to keep information about the batik trancoding hints. > [PATCH] sitemap parameters support for SVGSerializer > > > Key: COCOON-910 > URL: http://issues.apache.org/jira/browse/COCOON-910 > Project: Cocoon > Type: Bug > Components: - Components: Sitemap > Versions: 2.1.8 > Environment: Operating System: All > Platform: All > Reporter: Charles Borges > Assignee: Cocoon Developers Team > Attachments: SVGSerializer-patch.zip > > This patch aims to add support for sitemap parameters > allowing a user to override the default configuration of > the serializer with sitemap parameters. > The main changes come with the implementation of the SitemapModelComponent > interface > and the use of a new inner class to keep information about the batik > trancoding > hints. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1441) [Patch] Resource leak in DatabaseReader
[ http://issues.apache.org/jira/browse/COCOON-1441?page=all ] Vadim Gritsenko updated COCOON-1441: Bugzilla Id: (was: 33523) Component: - Components: Sitemap (was: - Components: Avalon) Description: The DatabaseReader does not close the database connection in all cases, which leads to a leak over time. The attached patch addresses this by being much more frugal. was: The DatabaseReader does not close the database connection in all cases, which leads to a leak over time. The attached patch addresses this by being much more frugal. > [Patch] Resource leak in DatabaseReader > --- > > Key: COCOON-1441 > URL: http://issues.apache.org/jira/browse/COCOON-1441 > Project: Cocoon > Type: Bug > Components: - Components: Sitemap > Versions: 2.1.8 > Environment: Operating System: Windows XP > Platform: PC > Reporter: Gregor J. Rothfuss > Assignee: Cocoon Developers Team > Attachments: FrugalDatabaseReader.java > > The DatabaseReader does not close the database connection in all cases, which > leads to a leak over time. The attached patch addresses this by being much > more > frugal. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1529) I18ntranformation output xmlns:i18n in the first element
[ http://issues.apache.org/jira/browse/COCOON-1529?page=all ] Vadim Gritsenko updated COCOON-1529: Bugzilla Id: (was: 35348) Component: - Components: Sitemap (was: - Components: Avalon) Description: This is a strage bug. on http://localhost:/samples/i18n/simple.xml around line 183: http://apache.org/cocoon/i18n/2.1";> This produces wrong xml output (extra xmlns:i18n attribute). now if you commented out the annotation element then the xmlns:i18n attribute goes to the next element: http://apache.org/cocoon/i18n/2.1";> It looks like it goes to the parent element always. I wish that I could have more information about how to resolve this. was: This is a strage bug. on http://localhost:/samples/i18n/simple.xml around line 183: http://apache.org/cocoon/i18n/2.1";> This produces wrong xml output (extra xmlns:i18n attribute). now if you commented out the annotation element then the xmlns:i18n attribute goes to the next element: http://apache.org/cocoon/i18n/2.1";> It looks like it goes to the parent element always. I wish that I could have more information about how to resolve this. > I18ntranformation output xmlns:i18n in the first element > - > > Key: COCOON-1529 > URL: http://issues.apache.org/jira/browse/COCOON-1529 > Project: Cocoon > Type: Bug > Components: - Components: Sitemap > Versions: 2.2-dev (Current SVN) > Environment: Operating System: other > Platform: Other > Reporter: Juan Jose Pablos > Assignee: Cocoon Developers Team > > This is a strage bug. > on http://localhost:/samples/i18n/simple.xml around line 183: > http://apache.org/cocoon/i18n/2.1";> > This produces wrong xml output (extra xmlns:i18n attribute). > now if you commented out the annotation element then the xmlns:i18n attribute > goes to the next element: > http://apache.org/cocoon/i18n/2.1";> > It looks like it goes to the parent element always. > I wish that I could have more information about how to resolve this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1576) Cocoon 2.1.7 does not compile - in mysterious circumstances
[ http://issues.apache.org/jira/browse/COCOON-1576?page=all ]
Vadim Gritsenko closed COCOON-1576:
---
Fix Version: 2.1.8
Resolution: Invalid
Cocoon requires version of jakarta-regexp which is a bit newer than 4 years, 8
months old. That's when RESyntaxException has been changed to uncheked one.
Find and remove old regexp library in order to build Cocoon.
> Cocoon 2.1.7 does not compile - in mysterious circumstances
> ---
>
> Key: COCOON-1576
> URL: http://issues.apache.org/jira/browse/COCOON-1576
> Project: Cocoon
> Type: Bug
> Components: - Components: Avalon
> Versions: 2.1.7
> Environment: Operating System: Windows 2000
> Platform: PC
> Reporter: Christian Sy
> Assignee: Cocoon Developers Team
> Fix For: 2.1.8
>
> Hello,
> I unzipped Cocoon 2.1.7 and then called the build.bat. My JAVA_ROOT pointed to
> JDK 1.4.1_01.
> Compiling with JDK 1.4.1_01 gave following error (had to compile with 1.3.1,
> and
> later tried 1.4.2, works also, so the problem is not very important probably)
> Microsoft Windows 2000 [Version 5.00.2195]
> (C) Copyright 1985-2000 Microsoft Corp.
> C:\prg\dev\cocoon>build
> Buildfile: build.xml
> init-tasks:
> Created dir: C:\prg\dev\cocoon\tools\anttasks
> Compiling 5 source files to C:\prg\dev\cocoon\tools\anttasks
> Created dir: C:\prg\dev\cocoon\tools\loader
> Compiling 1 source file to C:\prg\dev\cocoon\tools\loader
> prepare:
> ==
> Apache Cocoon 2.1.7 [1999-2005]
> ==
> Building with Apache Ant version 1.6.2 compiled on July 16 2004
> --
> Using build file C:\prg\dev\cocoon\build.xml
> --
> Compiler options:
>- debug . [on]
>- optimize .. [on]
>- deprecation ... [off]
> ==
> Created dir: C:\prg\dev\cocoon\build\cocoon-2.1.7
> compile-mocks:
> Created dir: C:\prg\dev\cocoon\build\cocoon-2.1.7\mocks
> Compiling 5 source files to C:\prg\dev\cocoon\build\cocoon-2.1.7\mocks
> compile-core:
> Copying 18 files to C:\prg\dev\cocoon\build\cocoon-2.1.7\classes
> Copied 60 empty directories to 37 empty directories under
> C:\prg\dev\cocoon\buil
> d\cocoon-2.1.7\classes
> Compiling 547 source files to C:\prg\dev\cocoon\build\cocoon-2.1.7\classes
> C:\prg\dev\cocoon\src\java\org\apache\cocoon\components\flow\javascript\fom\FOM_
> JavaScriptInterpreter.java:668: unreported exception
> org.apache.regexp.RESyntaxE
> xception; must be caught or declared to be thrown
> REProgram encodingRE = new
> RECompiler().compile("^.*encoding\\s*=\\s*([^\\s]
> *)");
>^
> 1 error
> BUILD FAILED
> C:\prg\dev\cocoon\tools\targets\compile-build.xml:61: Compile failed; see the
> co
> mpiler error output for details.
> Regards,
> Christian Sy
> Magicon Systems GmbH
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1680) New design/ layout proposal for Cocoon documentation
[ http://issues.apache.org/jira/browse/COCOON-1680?page=comments#action_12357191 ] Vadim Gritsenko commented on COCOON-1680: - IIRC ASF has newer version of the feather - the one which was used on AC2004 hackaton tshirts - I think it should be better then current one. Probably PRC should have it... > New design/ layout proposal for Cocoon documentation > > > Key: COCOON-1680 > URL: http://issues.apache.org/jira/browse/COCOON-1680 > Project: Cocoon > Type: Improvement > Components: - Documentation > Reporter: Milan Andrejevic > Priority: Minor > Attachments: asf20051107.zip, asf20051108.zip, screenshot.gif, screenshot.gif > > I made new design/ layout proposal for Cocoon documentation. Just one html > and screen css. I understand you need to "modernize" site (see Upayavira > comment for COCOON-1679). This is my try, I hope you like it. > There are two layouts user can choose. Layout info is stored in cookie > "_asfstyle" for 30 days. > Added access keys on top menu. > Navigation on right contains only sub-section selected form top menu > Minimal resolution set to 800px. > Starting design is done in Macromedia Fireworks (_src/cocoon.png) were you > can find all picture slices. > I have checked this design in: > Windows: > Firefox 1.0.7 > Internet Explorer 6.0 > Opera 8.5 > Linux: > Firefox 1.0.7 > Konqueror 3.3.2 > Mozilla 1.7.5 > Netscape 7.2 > Lynx -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1658) Somewhere output is held...
[ http://issues.apache.org/jira/browse/COCOON-1658?page=comments#action_12355965 ] Vadim Gritsenko commented on COCOON-1658: - (where is reply button in jira?) > So, my question is why is the buffer right now set to "unlimited"? > Is there any specific caveat for this? If you are using caching pipeline then complete response will have to be buffered in any case. For non caching pipelines, complete response will have to be buffered if serializer requires content length to be set. For all other cases... I think this outputBuffer is not really needed. > Somewhere output is held... > --- > > Key: COCOON-1658 > URL: http://issues.apache.org/jira/browse/COCOON-1658 > Project: Cocoon > Type: Bug > Components: * Cocoon Core > Versions: 2.1.8-dev (Current SVN) > Reporter: Pier Fumagalli > Priority: Critical > > Cocoon standard, as of right now, built without any blocks. > I modify the default sitemap adding one simple entry: > > > > > The file "bigtest.xml" is a 100Mb XML file that I simply want to generate and > serialize (minimal test, no transformers that can do anything weird). > I then open my terminal and do a "curl http://localhost:/bigtest > > /dev/null", to have an idea of the thrughput for this file. > Apparently, the output is held for roughly 25 seconds, nothing comes out, no > bytes are serialized. All of a sudden, the entire 100 megabytes are > serialized in one big lump (and it takes 5 seconds to do so). > This happens if the pipeline is configured as being "caching" or "noncaching" > (nothing changes). > In the first 25 seconds, the JVM running Cocoon uses 100% of my processor > (so, it's doing something), and the TOP shows something _really_ strange. > My JVM grows of roughly 200 megabytes in size (note, I start Cocoon, post the > big request, close cocoon). > This is a trace from my TOP: > PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE > - > 12498 java 0.1% 0:03.01 19 357 240 25.1M 28.7M 25.4M 735M > 12498 java87.2% 0:06.22 19 403 242 54.2M+ 28.7M 55.1M+ 735M- > 12498 java75.7% 0:10.88 19 403 242 78.3M 28.7M 79.2M 735M > 12498 java80.2% 0:14.78 19 403 242 129M 28.7M 130M 735M > 12498 java84.3% 0:19.77 19 403 242 168M+ 28.7M 169M+ 735M > 12498 java77.4% 0:23.67 19 403 242 231M 28.7M 232M 735M > 12498 java40.7% 0:27.92 19 403 242 231M+ 28.7M 232M+ 735M+ > 12498 java 0.1% 0:28.18 20 408 245 231M 28.7M 232M 735M > Something tells me that we are indeed caching all the content in a big char[] > (100 megabytes of US-ASCII text are 200 megabytes when stored in a char[]). > Any clue on where this can happen? It's impairing our ability to serve bigger > feeds (aka, 2 gigs! :-P) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
