from:"Vadim Gritsenko \(JIRA\)"

[jira] Commented: (COCOON3-35) Support access to URLs that require authentication.

2009-04-30 Thread Vadim Gritsenko (JIRA)


[ 
https://issues.apache.org/jira/browse/COCOON3-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.

2009-04-29 Thread Vadim Gritsenko (JIRA)


[ 
https://issues.apache.org/jira/browse/COCOON3-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

2008-04-24 Thread Vadim Gritsenko (JIRA)


[ 
https://issues.apache.org/jira/browse/COCOON-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-1985) AbstractCachingProcessingPipeline locking with IncludeTransformer may hang pipeline

2008-03-25 Thread Vadim Gritsenko (JIRA)


[ 
https://issues.apache.org/jira/browse/COCOON-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-2173) AbstractCachingProcessingPipeline: Two requests can deadlock each other

2008-03-25 Thread Vadim Gritsenko (JIRA)


[ 
https://issues.apache.org/jira/browse/COCOON-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 map:pipeline 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: 
 map:pipeline type=caching 
   map:match pattern=productOfferForDevice*/*/ 
 map:generate src=cocoon:/exists/{2}.xml label=a/ 
 map:transform type=xsltc src=productOfferIncludeDevice.xsl 
 label=b 
 map:parameter name=noInc value={1}/ 
 /map:transform 
 map:transform type=include label=c/ 
 map:serialize type=xml/ 
 /map:match 
   map:match pattern=exists/** 
 map:act type=resource-exists 
 map:parameter name=url value={1} / 
 map:generate src={../1} / 
 map:serialize type=xml / 
 /map:act 
 !-- not found -- 
 map:generate src=dummy.xml / 
 map:serialize type=xml / 
   /map:match 
 /map:pipeline 
 After some seconds the deadlock occurs == 
 * Apache Bench requests run into a timeout 
 * I can see following pipe locks in the default transient store: 
 PIPELOCK:PK_G-file-cocoon://samples/reproduceMultipleThreads/exists/55933.xml?pipelinehash=-910770960103935149_T-xsltc-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/productOfferIncludeDevice.xsl;noInc=_T-include-I_S-xml-1
  (class: org.mortbay.util.ThreadPool$PoolThread) 
 PIPELOCK:PK_G-file-cocoon://samples/reproduceMultipleThreads/exists/58840.xml?pipelinehash=-499603111986478_T-xsltc-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/productOfferIncludeDevice.xsl;noInc=_T-include-I_S-xml-1
  (class: org.mortbay.util.ThreadPool$PoolThread) 
 PIPELOCK:PK_G-file-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/55933.xml
  (class: org.mortbay.util.ThreadPool$PoolThread) 
 PIPELOCK:PK_G-file-file:///Users/alex/dev/cocoon/cocoon-2.1.11/build/webapp/samples/reproduceMultipleThreads/58840.xml
  (class: org.mortbay.util.ThreadPool$PoolThread) 
 I added some logging to AbstractCachingProcessingPipeline.java which 
 reconfirms the explanations above: 
 INFO (2008-03-13) 13:50.16:072 [sitemap] 
 (/samples/reproduceMultipleThreads/productOfferForDevice/55933/) 
 PoolThread-47/AbstractCachingProcessingPipeline: generating lock

[jira] Commented: (COCOON-2178) Array-based constructors of TreeSelectionEvent used.

2008-03-19 Thread Vadim Gritsenko (JIRA)


[ 
https://issues.apache.org/jira/browse/COCOON-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

2008-03-18 Thread Vadim Gritsenko (JIRA)


 [ 
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

2008-03-13 Thread Vadim Gritsenko (JIRA)

[
https://issues.apache.org/jira/browse/COCOON-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578389#action_12578389
]

Vadim Gritsenko commented on COCOON-1985:
-

Alexander - if you take a look at the top of this page you will notice that
issue has been resolved in trunk (see: Fix version (Component): Cocoon Core -
2.2.0-RC3-dev). If you take a look at the trunk you can also see a test case
which was reproducing that issue.

The fix is, IIRC, is to synchronize on top level http request. I planned to fix
it on branch too but so far had no time to do it.

AbstractCachingProcessingPipeline locking with IncludeTransformer may hang
pipeline
---

Key: COCOON-1985
URL: https://issues.apache.org/jira/browse/COCOON-1985
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Affects Versions: 2.1.9, 2.1.10, 2.1.11, 2.2-dev (Current SVN)
Reporter: Ellis Pritchard
Priority: Critical
Fix For: 2.2-dev (Current SVN)

Attachments: caching-trials.patch, includer.xsl, patch.txt,
reproduceMultipleThreads.tar.gz, sitemap.xmap

Cocoon 2.1.9 introduced the concept of a lock in
AbstractCachingProcessingPipeline, an optimization to prevent two concurrent
requests from generating the same cached content. The first request adds the
pipeline key to the transient cache to 'lock' the cache entry for that
pipeline, subsequent concurrent requests wait for the first request to cache
the content (by Object.lock()ing the pipeline key entry) before proceeding,
and can then use the newly cached content.
However, this has introduced an incompatibility with the IncludeTransformer:
if the inclusions access the same yet-to-be-cached content as the root
pipeline, the whole assembly hangs, since a lock will be made on a lock
already held by the same thread, and which cannot be satisfied.
e.g.
i) Root pipeline generates using sub-pipeline cocoon:/foo.xml
ii) the cocoon:/foo.xml sub-pipeline adds it's pipeline key to the transient
store as a lock.
iii) subsequently in the root pipeline, the IncludeTransformer is run.
iv) one of the inclusions also generates with cocoon:/foo.xml, this
sub-pipeline locks in AbstractProcessingPipeline.waitForLock() because the
sub-pipeline key is already present.
v) deadlock.
I've found a (partial, see below) solution for this: instead of a plain
Object being added to the transient store as the lock object, the
Thread.currentThread() is added; when waitForLock() is called, if the lock
object exists, it checks that it is not the same thread before attempting to
lock it; if it is the same thread, then waitForLock() returns success, which
allows generation to proceed. You loose the efficiency of generating the
cache only once in this case, but at least it doesn't hang! With JDK1.5 this
can be made neater by using Thread#holdsLock() instead of adding the thread
object itself to the transient store.
See patch file.
However, even with this fix, parallel includes (when enabled) may still hang,
because they pass the not-the-same-thread test, but fail because the root
pipeline, which holds the initial lock, cannot complete (and therefore
statisfy the lock condition for the parallel threads), before the threads
themselves have completed, which then results in a deadlock again.
The complete solution is probably to avoid locking if the lock is held by the
same top-level Request, but that requires more knowledge of Cocoon's
processing than I (currently) have!
IMHO unless a complete solution is found to this, then this optimization
should be removed completely, or else made optional by configuration, since
it renders the IncludeTransformer dangerous.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (COCOON-1985) AbstractCachingProcessingPipeline locking with IncludeTransformer may hang pipeline

2008-03-13 Thread Vadim Gritsenko (JIRA)

[
https://issues.apache.org/jira/browse/COCOON-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578414#action_12578414
]

Vadim Gritsenko commented on COCOON-1985:
-

Interesting. It sounds that you are describing related, but still different
issue. If that's the case then it can be present in trunk too. It would be
appropriate to file a separate Jira issue for this.

AbstractCachingProcessingPipeline locking with IncludeTransformer may hang
pipeline
---

Attachments: caching-trials.patch, includer.xsl, patch.txt,
reproduceMultipleThreads.tar.gz, sitemap.xmap

--
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

2008-02-07 Thread Vadim Gritsenko (JIRA)


[ 
https://issues.apache.org/jira/browse/COCOON-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 i:fallback/. It looks basically like this:
   xsl:forEach select=lenya:module
 i:include src=cocoon:/menu-xml/module/[EMAIL PROTECTED]
   i:fallback/
 /i:include
   /xsl:forEach
 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

2008-02-06 Thread Vadim Gritsenko (JIRA)


[ 
https://issues.apache.org/jira/browse/COCOON-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
  
 map:pipeline
   !-- testA: simple transform test: WORKS --
   map:match pattern=testA.html
map:generate src=test_content.xhtml/
map:transform src=test_transform.xhtml/
map:serialize type=html/
   /map:match
   !-- testB: 'dynamic' resource for test_transform.xhtml: WORKS --
   !-- IMPORTANT: the include reference in 'test_transform.xhtml' causes the 
 error! --
   !-- IMPORTANT: Remove this include reference and it works --
   map:match pattern=testB.html
map:generate src=test_transform.xhtml/
map:serialize type=xml/
   /map:match
   !-- testC: transform using 'dynamic' resource as transformer: FAILS --
   !-- FAILS: but ONLY if there is a xsl:include reference in the 
 transforming xsl --
   map:match pattern=testC.html
map:generate src=test_content.xhtml/
map:transform src=cocoon:/testB.html/
map:serialize type=html/
   /map:match
 /map:pipeline
 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 map:serialize type=html - 
 file:///Users/hoffmann/local/tomcat__11080/webapps/ROOT/app/foo/test/fooTest.xmap:27:33
   at map:transform - 
 file:///Users/hoffmann/local/tomcat__11080/webapps/ROOT/app/foo/test/fooTest.xmap:26:46
   at map:generate - 
 file:///Users/hoffmann/local/tomcat__11080/webapps/ROOT/app/foo/test/fooTest.xmap:25:45
   at map:mount - 
 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

2008-01-17 Thread Vadim Gritsenko (JIRA)


[ 
https://issues.apache.org/jira/browse/COCOON-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

2008-01-17 Thread Vadim Gritsenko (JIRA)


[ 
https://issues.apache.org/jira/browse/COCOON-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

2008-01-04 Thread Vadim Gritsenko (JIRA)


[ 
https://issues.apache.org/jira/browse/COCOON-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

2007-12-07 Thread Vadim Gritsenko (JIRA)

[
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
...
map:pipeline
map:match pattern=test/**
map:mount check-reload=yes src=subsitemap.xmap uri-prefix=test /
/map:match
/map:pipeline
...
Sub sitemap
...
map:match pattern=A.html
map:redirect-to uri=cocoon:/B.html/
/map:match
map:match pattern=B.html
map:redirect-to uri=http://www.google.com/
/map:match
...
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

2007-12-06 Thread Vadim Gritsenko (JIRA)


 [ 
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

2007-10-25 Thread Vadim Gritsenko (JIRA)


 [ 
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

2007-10-23 Thread Vadim Gritsenko (JIRA)


 [ 
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

2007-10-04 Thread Vadim Gritsenko (JIRA)

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-2109) Incorrent cleanup of expired continuations

2007-08-10 Thread Vadim Gritsenko (JIRA)

[
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

2007-08-10 Thread Vadim Gritsenko (JIRA)

[
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
--

--
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

2007-08-10 Thread Vadim Gritsenko (JIRA)

[
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
--

--
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

2007-08-10 Thread Vadim Gritsenko (JIRA)


[ 
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:
 map:transform type=xslt
   map:parameter name=request_param value=${cocoon/request/some_param}/
 /map:transform
 assuming that JXPath (used above) is default EL of choice. Of course one 
 would be able to use following construct:
 map:transform type=xslt
   map:parameter name=request_param 
 value=${jexl:cocoon.request.some_param}/
 /map:transform

-- 
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

2007-08-10 Thread Vadim Gritsenko (JIRA)


[ 
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:
 map:transform type=xslt
   map:parameter name=request_param value=${cocoon/request/some_param}/
 /map:transform
 assuming that JXPath (used above) is default EL of choice. Of course one 
 would be able to use following construct:
 map:transform type=xslt
   map:parameter name=request_param 
 value=${jexl:cocoon.request.some_param}/
 /map:transform

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (COCOON-2079) Parser error when launching webapp with jetty

2007-08-08 Thread Vadim Gritsenko (JIRA)


[ 
https://issues.apache.org/jira/browse/COCOON-2079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518491
 ] 

Vadim Gritsenko commented on COCOON-2079:
-

With Grzegorz help, Cocoon trunk now *almost* builds, and webapp starts up - 
even if with errors, it does. So this particular bug can be closed now.

 Parser error when launching webapp with jetty
 -

 Key: COCOON-2079
 URL: https://issues.apache.org/jira/browse/COCOON-2079
 Project: Cocoon
  Issue Type: Bug
  Components: * Cocoon Core
Affects Versions: 2.2-dev (Current SVN)
Reporter: Gustavo N. Fernandes
Assignee: Jörg Heinicke
Priority: Blocker
 Fix For: 2.2-dev (Current SVN)

 Attachments: dependencies.html, dtd_patch.patch


 Erase local mvn repo on .m2
 svn update
 mvn clean
 mvn -Dmaven.test.skip=true -P allblocks install
 cd core/cocoon-webapp
 mvn jetty:run
 Gives the following error:
 Caused by: org.apache.avalon.framework.configuration.ConfigurationException: 
 Cannot load 
 'jar:file:/C:/projetos/cocoon/trunk/core/cocoon-webapp/target/cocoon-we
 bapp/WEB-INF/lib/cocoon-core-2.2.0-RC2-SNAPSHOT.jar!/org/apache/cocoon/cocoon.roles'
  at 
 jar:file:/C:/projetos/cocoon/trunk/core/cocoon-webapp/target/cocoon-webapp/WEB-INF/lib/cocoon-core-2.2.0-RC2-SNAPSHOT.jar!/org/apache/cocoon/cocoon.xconf:30:61
 at 
 org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.loadURI(ConfigurationReader.java:508)
 at 
 org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.handleInclude(ConfigurationReader.java:458)
 ... 62 more
 Caused by: org.gjt.xpp.XmlPullParserException: ![DOCTYPE declarations not 
 supported at line 32 and column 3 seen ...TA #REQUIRED\r\n   
 class CDATA  #REQUIRED\r\n\r\n]... (parser state UNKNONW_EVENT (-1))
 This happens on windows and linux os, both with java 5 and 6.  
 It seems core/cocoon-core/src/main/resources/org/apache/cocoon/cocoon.roles 
 is not valid according to the DTD that is declared in the header. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (COCOON-2079) Parser error when launching webapp with jetty

2007-08-08 Thread Vadim Gritsenko (JIRA)


 [ 
https://issues.apache.org/jira/browse/COCOON-2079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vadim Gritsenko closed COCOON-2079.
---

Resolution: Fixed

 Parser error when launching webapp with jetty
 -

 Key: COCOON-2079
 URL: https://issues.apache.org/jira/browse/COCOON-2079
 Project: Cocoon
  Issue Type: Bug
  Components: * Cocoon Core
Affects Versions: 2.2-dev (Current SVN)
Reporter: Gustavo N. Fernandes
Assignee: Jörg Heinicke
Priority: Blocker
 Fix For: 2.2-dev (Current SVN)

 Attachments: dependencies.html, dtd_patch.patch


 Erase local mvn repo on .m2
 svn update
 mvn clean
 mvn -Dmaven.test.skip=true -P allblocks install
 cd core/cocoon-webapp
 mvn jetty:run
 Gives the following error:
 Caused by: org.apache.avalon.framework.configuration.ConfigurationException: 
 Cannot load 
 'jar:file:/C:/projetos/cocoon/trunk/core/cocoon-webapp/target/cocoon-we
 bapp/WEB-INF/lib/cocoon-core-2.2.0-RC2-SNAPSHOT.jar!/org/apache/cocoon/cocoon.roles'
  at 
 jar:file:/C:/projetos/cocoon/trunk/core/cocoon-webapp/target/cocoon-webapp/WEB-INF/lib/cocoon-core-2.2.0-RC2-SNAPSHOT.jar!/org/apache/cocoon/cocoon.xconf:30:61
 at 
 org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.loadURI(ConfigurationReader.java:508)
 at 
 org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.handleInclude(ConfigurationReader.java:458)
 ... 62 more
 Caused by: org.gjt.xpp.XmlPullParserException: ![DOCTYPE declarations not 
 supported at line 32 and column 3 seen ...TA #REQUIRED\r\n   
 class CDATA  #REQUIRED\r\n\r\n]... (parser state UNKNONW_EVENT (-1))
 This happens on windows and linux os, both with java 5 and 6.  
 It seems core/cocoon-core/src/main/resources/org/apache/cocoon/cocoon.roles 
 is not valid according to the DTD that is declared in the header. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (COCOON-2079) Parser error when launching webapp with jetty

2007-08-04 Thread Vadim Gritsenko (JIRA)


[ 
https://issues.apache.org/jira/browse/COCOON-2079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517729
 ] 

Vadim Gritsenko commented on COCOON-2079:
-

I found these three jars in the 
.../core/cocoon-webapp/target/cocoon-webapp/WEB-INF/lib:
  xml-apis-1.3.02.jar
  xmlParserAPIs-2.0.2.jar
  xmlParserAPIs-2.6.2.jar

I wonder if that relates to this parsing error. Also, from reading error text, 
I don't think it means that cocoon.roles is invalid. Rather, I understand it as 
if parser does not support DOCTYPE declarations at all:

org.gjt.xpp.XmlPullParserException: ![DOCTYPE declarations not supported at 
line 33 and column 3

 Parser error when launching webapp with jetty
 -

 Key: COCOON-2079
 URL: https://issues.apache.org/jira/browse/COCOON-2079
 Project: Cocoon
  Issue Type: Bug
  Components: * Cocoon Core
Affects Versions: 2.2-dev (Current SVN)
Reporter: Gustavo N. Fernandes
Assignee: Jörg Heinicke
Priority: Blocker
 Fix For: 2.2-dev (Current SVN)

 Attachments: dtd_patch.patch


 Erase local mvn repo on .m2
 svn update
 mvn clean
 mvn -Dmaven.test.skip=true -P allblocks install
 cd core/cocoon-webapp
 mvn jetty:run
 Gives the following error:
 Caused by: org.apache.avalon.framework.configuration.ConfigurationException: 
 Cannot load 
 'jar:file:/C:/projetos/cocoon/trunk/core/cocoon-webapp/target/cocoon-we
 bapp/WEB-INF/lib/cocoon-core-2.2.0-RC2-SNAPSHOT.jar!/org/apache/cocoon/cocoon.roles'
  at 
 jar:file:/C:/projetos/cocoon/trunk/core/cocoon-webapp/target/cocoon-webapp/WEB-INF/lib/cocoon-core-2.2.0-RC2-SNAPSHOT.jar!/org/apache/cocoon/cocoon.xconf:30:61
 at 
 org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.loadURI(ConfigurationReader.java:508)
 at 
 org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.handleInclude(ConfigurationReader.java:458)
 ... 62 more
 Caused by: org.gjt.xpp.XmlPullParserException: ![DOCTYPE declarations not 
 supported at line 32 and column 3 seen ...TA #REQUIRED\r\n   
 class CDATA  #REQUIRED\r\n\r\n]... (parser state UNKNONW_EVENT (-1))
 This happens on windows and linux os, both with java 5 and 6.  
 It seems core/cocoon-core/src/main/resources/org/apache/cocoon/cocoon.roles 
 is not valid according to the DTD that is declared in the header. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (COCOON-2079) Parser error when launching webapp with jetty

2007-08-04 Thread Vadim Gritsenko (JIRA)


[ 
https://issues.apache.org/jira/browse/COCOON-2079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517730
 ] 

Vadim Gritsenko commented on COCOON-2079:
-

The culprit is the impotent pull-parser-2.jar which registers itself as general 
sax parser factory (see pull-parser-2.jar:/META-INF/services/) and then fails 
miserably trying to parse cocoon.roles with DOCTYPE declaration.

Beside yanking this jar out (not sure what requires this parser? what depends 
on it?), which I have not tried, other option to make Cocoon start is to 
override service declaration:

cd .../core/cocoon-webapp/target/cocoon-webapp/WEB-INF/classes
unzip 
.../core/cocoon-webapp/target/cocoon-webapp/WEB-INF/lib/xercesImpl-2.8.1.jar 
META-INF/services/javax.xml.parsers.SAXParserFactory

Ok, anybody got a clue what should next step be? :)

 Parser error when launching webapp with jetty
 -

 Key: COCOON-2079
 URL: https://issues.apache.org/jira/browse/COCOON-2079
 Project: Cocoon
  Issue Type: Bug
  Components: * Cocoon Core
Affects Versions: 2.2-dev (Current SVN)
Reporter: Gustavo N. Fernandes
Assignee: Jörg Heinicke
Priority: Blocker
 Fix For: 2.2-dev (Current SVN)

 Attachments: dtd_patch.patch


 Erase local mvn repo on .m2
 svn update
 mvn clean
 mvn -Dmaven.test.skip=true -P allblocks install
 cd core/cocoon-webapp
 mvn jetty:run
 Gives the following error:
 Caused by: org.apache.avalon.framework.configuration.ConfigurationException: 
 Cannot load 
 'jar:file:/C:/projetos/cocoon/trunk/core/cocoon-webapp/target/cocoon-we
 bapp/WEB-INF/lib/cocoon-core-2.2.0-RC2-SNAPSHOT.jar!/org/apache/cocoon/cocoon.roles'
  at 
 jar:file:/C:/projetos/cocoon/trunk/core/cocoon-webapp/target/cocoon-webapp/WEB-INF/lib/cocoon-core-2.2.0-RC2-SNAPSHOT.jar!/org/apache/cocoon/cocoon.xconf:30:61
 at 
 org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.loadURI(ConfigurationReader.java:508)
 at 
 org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.handleInclude(ConfigurationReader.java:458)
 ... 62 more
 Caused by: org.gjt.xpp.XmlPullParserException: ![DOCTYPE declarations not 
 supported at line 32 and column 3 seen ...TA #REQUIRED\r\n   
 class CDATA  #REQUIRED\r\n\r\n]... (parser state UNKNONW_EVENT (-1))
 This happens on windows and linux os, both with java 5 and 6.  
 It seems core/cocoon-core/src/main/resources/org/apache/cocoon/cocoon.roles 
 is not valid according to the DTD that is declared in the header. 

-- 
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

2006-11-28 Thread Vadim Gritsenko (JIRA)

 [ 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

2006-11-21 Thread Vadim Gritsenko (JIRA)

[ 
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

2006-10-11 Thread Vadim Gritsenko (JIRA)

[ 
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:
map:serializer logger=sitemap.serializer.html mime-type=text/html 
name=html pool-max=${html-serializer.pool-max} 
src=org.apache.cocoon.serialization.HTMLSerializer
  doctype-public-//W3C//DTD HTML 4.01 Transitional//EN/doctype-public
  doctype-systemhttp://www.w3.org/TR/html4/loose.dtd/doctype-system
/map:serializer

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 map:pipeline section, not within 
map:components 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 :
 map:serializer logger=sitemap.serializer.xhtml mime-type=text/html 
 name=xhtml pool-grow=2 pool-max=64 pool-min=2 
 src=org.apache.cocoon.serialization.XMLSerializer
 parameter name=doctype-public value=-//W3C//DTD XHTML 1.0 
 Transitional//EN /
 parameter name=doctype-system 
 value=http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; /
 encodingUTF-8/encoding
 indentyes/indent
   omit-xml-declarationno/omit-xml-declaration
 /map:serializer
 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] Assigned: (COCOON-1462) NullPointerException in SQLTransformer

2006-10-03 Thread Vadim Gritsenko (JIRA)

 [ 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-1462) NullPointerException in SQLTransformer

2006-10-03 Thread Vadim Gritsenko (JIRA)

 [ 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] Updated: (COCOON-574) [PATCH] fixed redirect under JRun 3.1

2006-10-03 Thread Vadim Gritsenko (JIRA)

 [ 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-1906) [PATCH] simple-xml binding does not work with non file sources

2006-10-02 Thread Vadim Gritsenko (JIRA)

 [ 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] Assigned: (COCOON-1519) [PATCH] TeeTransformer refactoring

2006-10-02 Thread Vadim Gritsenko (JIRA)

 [ 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-1456) SourceWritingTransformer write only the first node

2006-10-02 Thread Vadim Gritsenko (JIRA)

 [ 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 :
 source:write serializer=xml
   source:sourcefile/source:source
   source:fragment
 !-- annoying comment --
 node
   anothernode/
 /node
   /source:fragment
 /source:write
 writes the following thing on disk:
 ?xml version=1.0 encoding=utf-8?
 !-- annoying comment --
 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] Closed: (COCOON-1643) cocoon 2.2.0 dev svn checkout doesn't work with tomcat

2006-10-02 Thread Vadim Gritsenko (JIRA)

 [ 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.init(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(StandardValveContext.java:104)
   at

[jira] Closed: (COCOON-1873) WildcardURIMatcher returns wrong results for **/*.html

2006-10-02 Thread Vadim Gritsenko (JIRA)

 [ 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-1922) [PATCH] cocoon-core-sample should be part of the default build, because it is required by the default example webapp

2006-10-02 Thread Vadim Gritsenko (JIRA)

 [ 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-1049) encoding in Content-Type header is not set by serializers

2006-10-02 Thread Vadim Gritsenko (JIRA)

 [ 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-1441) [Patch] Resource leak in DatabaseReader

2006-10-02 Thread Vadim Gritsenko (JIRA)

 [ 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] Commented: (COCOON-1906) [PATCH] simple-xml binding does not work with non file sources

2006-09-26 Thread Vadim Gritsenko (JIRA)

[ 
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-devm=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-1247) Multiple results not processed by SQLTransformer

2006-06-13 Thread Vadim Gritsenko (JIRA)

 [ 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 query.  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
   query
 select distinct Permission_Code from USER_PERMISSIONS
 select distinct Sys_User_Code from USER_PERMISSIONS
   /query
 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] Closed: (COCOON-1552) NullPointerException from SQLTransformer

2006-06-13 Thread Vadim Gritsenko (JIRA)

 [ 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] Commented: (COCOON-1839) exception2html.xslt script / causes IE display problem

2006-04-26 Thread Vadim Gritsenko (JIRA)

[ 
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 script / 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) script / tag.
 By putting in an nbsp (#160;) or a new line, the XSLT produces script 
 /script, 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.
 script src={$contextPath}/scripts/main.js type=text/javascript
   #160;
 /script

-- 
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 script / causes IE display problem

2006-04-26 Thread Vadim Gritsenko (JIRA)

[ 
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 script / 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) script / tag.
 By putting in an nbsp (#160;) or a new line, the XSLT produces script 
 /script, 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.
 script src={$contextPath}/scripts/main.js type=text/javascript
   #160;
 /script

-- 
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

2005-11-23 Thread Vadim Gritsenko (JIRA)

 [ 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-usersm=109949860123580w=2

  was:
XUpdate does not remove the temporary tree it creates while updating a resource.

Please, see http://marc.theaimsgroup.com/?l=xindice-usersm=109949860123580w=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-usersm=109949860123580w=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-1363) [Scratchpad] bugs in CookieCreatorAction

2005-11-23 Thread Vadim Gritsenko (JIRA)

 [ 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] Closed: (COCOON-1520) Database / avalon problems

2005-11-23 Thread Vadim Gritsenko (JIRA)

 [ 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] Reopened: (COCOON-1520) Database / avalon problems

2005-11-23 Thread Vadim Gritsenko (JIRA)

 [ 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

2005-11-23 Thread Vadim Gritsenko (JIRA)

 [ 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] Closed: (COCOON-1576) Cocoon 2.1.7 does not compile - in mysterious circumstances

2005-11-18 Thread Vadim Gritsenko (JIRA)

 [ 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\cocoonbuild
 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] Updated: (COCOON-1529) I18ntranformation output xmlns:i18n in the first element

2005-11-18 Thread Vadim Gritsenko (JIRA)

 [ 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:
  annotation xmlns:i18n=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:
 content xmlns:i18n=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:
  annotation xmlns:i18n=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:
 content xmlns:i18n=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:
   annotation xmlns:i18n=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:
  content xmlns:i18n=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] Updated: (COCOON-1441) [Patch] Resource leak in DatabaseReader

2005-11-18 Thread Vadim Gritsenko (JIRA)

 [ 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-910) [PATCH] sitemap parameters support for SVGSerializer

2005-11-18 Thread Vadim Gritsenko (JIRA)

 [ 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-1232) [PATCH] NEW--ModuleDB Action for ORACLE( auto. increment )

2005-11-18 Thread Vadim Gritsenko (JIRA)

 [ 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-1170) [PATCH] precompile xsp's without starting URI

2005-11-18 Thread Vadim Gritsenko (JIRA)

 [ 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:
   arg line=-P true -C ${build.webapp.dir}/WEB-INF/cocoon.xconf -w 
 ${build.webapp.dir}/WEB-INF/work -u ERROR -k ../etc/logkit4cli.xconf -l cli 
 -c 
 ${build.webapp.dir}/
 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-892) jsp block functionality broken, running on resin 3.0.x

2005-11-18 Thread Vadim Gritsenko (JIRA)

 [ 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-529) XSPUtil.relativeFilename() returns differents results for different containers

2005-11-18 Thread Vadim Gritsenko (JIRA)

 [ 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:

[jira] Commented: (COCOON-1680) New design/ layout proposal for Cocoon documentation

2005-11-09 Thread Vadim Gritsenko (JIRA)

[ 
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...

2005-10-26 Thread Vadim Gritsenko (JIRA)

[ 
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:
 map:match pattern=bigtest
   map:generate src=bigtest.xml/
   map:serialize type=xml/
 /map:match
 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

62 matches

Mail list logo