[jira] Commented: (COCOON-2285) Strange behavior of multfieldvalue
[ https://issues.apache.org/jira/browse/COCOON-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12861859#action_12861859 ] Antonio Gallardo commented on COCOON-2285: -- Would you post a sample of the issue? Strange behavior of multfieldvalue -- Key: COCOON-2285 URL: https://issues.apache.org/jira/browse/COCOON-2285 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.2 Reporter: Vasily E. Moskaljov Incorrect encoding of Russian characters in fd: multivaluefield if the form fails validation. In addition getValue ().length returns the javascript source of length function instead of the length of the array. Environment: Ubuntu 8.04 LTS, java version 1.6.0_17 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2249) XHTMLSerializer uses entity references quot; and apos; which cause JavaScript parse errors
[ https://issues.apache.org/jira/browse/COCOON-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666254#action_12666254 ] Antonio Gallardo commented on COCOON-2249: -- In the patch MinimalXMLEncoder.java is missing. Would you post it? XHTMLSerializer uses entity references quot; and apos; which cause JavaScript parse errors Key: COCOON-2249 URL: https://issues.apache.org/jira/browse/COCOON-2249 Project: Cocoon Issue Type: Improvement Components: Blocks: Serializers Affects Versions: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Andreas Hartmann Attachments: COCOON-2249-2009-01-21-1601.txt The XHTMLSerializer, or, more specifically, the XHMLEncoder, from the serializers block in Cocoon 2.1.x escapes all characters with a corresponding HTML 4.0 character entity reference into this entity reference. This causes issues with inline JavaScript, since e.g. the double quotes are transformed to quot; which causes a JavaScript parsing error. Another minor negative effect is the increased document size. If I understand the W3C correctly, see e.g. [2], the recommended approach is to use the character set of the encoding as far as possible, and use escapes only in exceptional circumstances. I didn't find a reason why the XHTMLSerializer uses escapes, but I suspect that it is related to browser compatibility issues. Maybe we could make this behaviour configurable, e.g. use-entity-referencestrue|false/use-entity-references [1] http://www.nabble.com/Problem-with-XHTMLSerializers-to1311360.html#a1311360 [2] http://www.w3.org/International/tutorials/tutorial-char-enc/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-1822) MultiValueField list-type=double-listbox does not work correctly in ajax enabled forms
[ https://issues.apache.org/jira/browse/COCOON-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo reassigned COCOON-1822: Assignee: Antonio Gallardo MultiValueField list-type=double-listbox does not work correctly in ajax enabled forms Key: COCOON-1822 URL: https://issues.apache.org/jira/browse/COCOON-1822 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.9 Reporter: Simone Gianni Assignee: Antonio Gallardo Priority: Critical Attachments: dojo-doublelist_patch.tar.gz The multi value field with fi:styling list-type=double-listbox relies on forms_onsubmitHandlers to select all items in the right selection list before submitting. In an ajax form, it seems like forms_onsubmit is not installed on the form, so handlers are not called; in forms-field-styling.xsl this is clearly stated : xsl:choose xsl:when test=@ajax = 'true' xsl:attribute name=dojoTypeCFormsForm/xsl:attribute xsl:if test=@ajax = 'true' script type=text/javascriptcocoon.forms.ajax = true;/script /xsl:if /xsl:when xsl:otherwise xsl:attribute name=onsubmitforms_onsubmit(); xsl:value-of select=@onsubmit//xsl:attribute /xsl:otherwise /xsl:choose I don't think installing forms_onsubmit() also on ajax forma is a wise solution, but maybe we should call it from inside the ajax code, or at least check and execute onsubmit_handlers. If not, also the free-form multivalue field editor will not work correctly. What's the best way to fix this issue? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1822) MultiValueField list-type=double-listbox does not work correctly in ajax enabled forms
[ https://issues.apache.org/jira/browse/COCOON-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12612678#action_12612678 ] Antonio Gallardo commented on COCOON-1822: -- Patch applied to 2.1.12-dev. MultiValueField list-type=double-listbox does not work correctly in ajax enabled forms Key: COCOON-1822 URL: https://issues.apache.org/jira/browse/COCOON-1822 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.9 Reporter: Simone Gianni Assignee: Antonio Gallardo Priority: Critical Attachments: dojo-doublelist_patch.tar.gz The multi value field with fi:styling list-type=double-listbox relies on forms_onsubmitHandlers to select all items in the right selection list before submitting. In an ajax form, it seems like forms_onsubmit is not installed on the form, so handlers are not called; in forms-field-styling.xsl this is clearly stated : xsl:choose xsl:when test=@ajax = 'true' xsl:attribute name=dojoTypeCFormsForm/xsl:attribute xsl:if test=@ajax = 'true' script type=text/javascriptcocoon.forms.ajax = true;/script /xsl:if /xsl:when xsl:otherwise xsl:attribute name=onsubmitforms_onsubmit(); xsl:value-of select=@onsubmit//xsl:attribute /xsl:otherwise /xsl:choose I don't think installing forms_onsubmit() also on ajax forma is a wise solution, but maybe we should call it from inside the ajax code, or at least check and execute onsubmit_handlers. If not, also the free-form multivalue field editor will not work correctly. What's the best way to fix this issue? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2209) POI: formatted style regions stop creating style at 2000 rows.
[ https://issues.apache.org/jira/browse/COCOON-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo reassigned COCOON-2209: Assignee: Antonio Gallardo POI: formatted style regions stop creating style at 2000 rows. -- Key: COCOON-2209 URL: https://issues.apache.org/jira/browse/COCOON-2209 Project: Cocoon Issue Type: Improvement Components: Blocks: POI Affects Versions: 2.1.9, 2.1.10, 2.1.11, 2.1.12-dev (Current SVN), 2.2, 2.2-dev (Current SVN) Reporter: Reynaldo Porras Assignee: Antonio Gallardo Attachments: EPStyleRegion_patch.txt See: http://markmail.org/message/knyapjhi362tlln7 Recurrently, people asks about this issue on cocoon dev or user mail list and there has not been answer so far. Attached is the proposed patch to raise the max cell region from 2k to 65k. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2209) POI: formatted style regions stop creating style at 2000 rows.
[ https://issues.apache.org/jira/browse/COCOON-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo closed COCOON-2209. Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN) 2.1.12-dev (Current SVN) Thanks for the patch. It was applied in cocoon 2.1 branch and 2.2. POI: formatted style regions stop creating style at 2000 rows. -- Key: COCOON-2209 URL: https://issues.apache.org/jira/browse/COCOON-2209 Project: Cocoon Issue Type: Improvement Components: Blocks: POI Affects Versions: 2.1.9, 2.1.10, 2.1.11, 2.1.12-dev (Current SVN), 2.2, 2.2-dev (Current SVN) Reporter: Reynaldo Porras Assignee: Antonio Gallardo Fix For: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Attachments: EPStyleRegion_patch.txt See: http://markmail.org/message/knyapjhi362tlln7 Recurrently, people asks about this issue on cocoon dev or user mail list and there has not been answer so far. Attached is the proposed patch to raise the max cell region from 2k to 65k. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2208) Race condition in AbstractCachingProcessingPipeline causes threads to hang.
[
https://issues.apache.org/jira/browse/COCOON-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12603216#action_12603216
]
Antonio Gallardo commented on COCOON-2208:
--
Is not the same as: https://issues.apache.org/jira/browse/COCOON-1985 ?
Race condition in AbstractCachingProcessingPipeline causes threads to hang.
---
Key: COCOON-2208
URL: https://issues.apache.org/jira/browse/COCOON-2208
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Affects Versions: 2.1.11
Reporter: Sylvain Wallez
Priority: Blocker
There's a race condition in AbstractCachingProcessingPipeline.waitForLock() :
if lock is not null, there is a possibility that the thread that created
the lock releases it before the current thread starts waiting on it (see
below). When this happens, the thread waits forever since no thread will ever
call notify() on the lock.
The very bad effect is that this progressively blocks the entire thread pool
of the servlet engine, which ends up rejecting new incoming connections.
And BTW, calling containsKey() just before get() unneedingly doubles the
number of lookups.
{noformat}
protected boolean waitForLock(Object key) {
if(transientStore != null) {
Object lock = null;
synchronized(transientStore) {
String lockKey = PIPELOCK_PREFIX+key;
if(transientStore.containsKey(lockKey)) {
// cache content is currently being generated, wait for
other thread
lock = transientStore.get(lockKey);
}
}
// START OF RACE CONDITION ZONE
if(lock != null) {
try {
// become owner of monitor
synchronized(lock) {
// END OF RACE CONDITION ZONE
lock.wait();
}
} catch (InterruptedException e) {
if(getLogger().isDebugEnabled()) {
getLogger().debug(Got interrupted
waiting for other pipeline to finish processing, retrying...,e);
}
return false;
}
if(getLogger().isDebugEnabled()) {
getLogger().debug(Other pipeline finished
processing, retrying to get cached response.);
}
return false;
}
}
return true;
}
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-1703) A patch for caching fonts (fixes GDI issues), vertical text orientation, color code fix, prefered unit for margins and measure unit converter
[ https://issues.apache.org/jira/browse/COCOON-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo updated COCOON-1703: - Status: On Hold (was: Open) Another issue of the provided patch is an unaceptable header in PrintUnitsUtils.java: /* * Copyright (c) 2004 Poznan Supercomputing and Networking Center * 10 Noskowskiego Street, Poznan, Wielkopolska 61-704, Poland * All rights reserved. * * This software is the confidential and proprietary information of * Poznan Supercomputing and Networking Center (Confidential Information). * You shall not disclose such Confidential Information and shall use it only * in accordance with the terms of the license agreement you entered into * with PSNC. */ Would you send a fixed patch with an Aapache License version 2.0? A patch for caching fonts (fixes GDI issues), vertical text orientation, color code fix, prefered unit for margins and measure unit converter - Key: COCOON-1703 URL: https://issues.apache.org/jira/browse/COCOON-1703 Project: Cocoon Issue Type: Bug Components: Blocks: POI Reporter: Krystian Nowak Attachments: psnc-v3.1.patch, psnc-v3.patch A patch for caching fonts (fixes GDI issues), vertical text orientation, color code fix, prefered unit for margins and measure unit converter - in attachment -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2186) Suggest list .. initial value not being displayed
[ https://issues.apache.org/jira/browse/COCOON-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo reassigned COCOON-2186: Assignee: Antonio Gallardo Suggest list .. initial value not being displayed -- Key: COCOON-2186 URL: https://issues.apache.org/jira/browse/COCOON-2186 Project: Cocoon Issue Type: Bug Components: Blocks: Ajax, Blocks: Forms Affects Versions: 2.1.11 Reporter: imran pariyani Assignee: Antonio Gallardo Priority: Minor For the forms field of type suggest with a suggestion list the initial value is not being displayed ... this dint happen for version 2.1.10 .. but when i upgraded to version 2.1.11 it no longer sets the initial value .. this bug is also present for the sample http://cocoon.zones.apache.org/demos/release/samples/blocks/forms/do-suggest.flow Initial value of the widget is 16, the widget must show Bruno Dumon. fd:datatype base=integer/ fd:initial-value16/fd:initial-value fd:suggestion-list type=javascript after debugging i found out that the widgets value is being set but it isnt passed on to DOJO as initial value when the DOJO widget is created .. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2186) Suggest list .. initial value not being displayed
[ https://issues.apache.org/jira/browse/COCOON-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo closed COCOON-2186. Resolution: Fixed Fix Version/s: 2.1.12-dev (Current SVN) Suggest list .. initial value not being displayed -- Key: COCOON-2186 URL: https://issues.apache.org/jira/browse/COCOON-2186 Project: Cocoon Issue Type: Bug Components: Blocks: Ajax, Blocks: Forms Affects Versions: 2.1.11 Reporter: imran pariyani Assignee: Antonio Gallardo Priority: Minor Fix For: 2.1.12-dev (Current SVN) For the forms field of type suggest with a suggestion list the initial value is not being displayed ... this dint happen for version 2.1.10 .. but when i upgraded to version 2.1.11 it no longer sets the initial value .. this bug is also present for the sample http://cocoon.zones.apache.org/demos/release/samples/blocks/forms/do-suggest.flow Initial value of the widget is 16, the widget must show Bruno Dumon. fd:datatype base=integer/ fd:initial-value16/fd:initial-value fd:suggestion-list type=javascript after debugging i found out that the widgets value is being set but it isnt passed on to DOJO as initial value when the DOJO widget is created .. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2163) Widget Label is not Show/Hide when we change the widget state in ajax mode
[ https://issues.apache.org/jira/browse/COCOON-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581012#action_12581012 ] Antonio Gallardo commented on COCOON-2163: -- Patch applied with minor fixes in 2.1.12-dev Widget Label is not Show/Hide when we change the widget state in ajax mode -- Key: COCOON-2163 URL: https://issues.apache.org/jira/browse/COCOON-2163 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Carlos Chávez Assignee: Antonio Gallardo Priority: Minor Attachments: widget_states_patch.txt There is an issue when we change the state of the widget. if initially the widget is active and we change the state to invisible the label of the widget is not hided if initially the widget is invisible and we change the state to active the label of the widget is not showed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2020) CAPTCHA input element should have autocomplete=off
[
https://issues.apache.org/jira/browse/COCOON-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Gallardo reassigned COCOON-2020:
Assignee: Antonio Gallardo
CAPTCHA input element should have autocomplete=off
---
Key: COCOON-2020
URL: https://issues.apache.org/jira/browse/COCOON-2020
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.2-dev
(Current SVN)
Reporter: Mark Lundquist
Assignee: Antonio Gallardo
Priority: Trivial
The bug summary says it all, and this isn't even enough to bother making a
patch, all it takes is the following lines added to forms-field-styling.xsl
(the diff is from my 2.1.8 vendor branch, but this fix will work in all
Cocoon versions):
forms-field-styling.xsl(working copy)
@@ -55,6 +55,9 @@
/xsl:if
!-- @id:input is what labels point to --
input name=[EMAIL PROTECTED] id=[EMAIL PROTECTED]:input
value={fi:value} title={fi:hint} type=text
+xsl:if test=fi:captcha-image
+ xsl:attribute name=autocomplete select='off'/
+/xsl:if
xsl:apply-templates select=. mode=styling/
/input
xsl:apply-templates select=. mode=common/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2020) CAPTCHA input element should have autocomplete=off
[
https://issues.apache.org/jira/browse/COCOON-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Gallardo closed COCOON-2020.
Resolution: Fixed
Fix Version/s: 2.2-dev (Current SVN)
2.1.12-dev (Current SVN)
Thanks for the patch. :)
CAPTCHA input element should have autocomplete=off
---
Key: COCOON-2020
URL: https://issues.apache.org/jira/browse/COCOON-2020
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.2-dev
(Current SVN)
Reporter: Mark Lundquist
Assignee: Antonio Gallardo
Priority: Trivial
Fix For: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN)
The bug summary says it all, and this isn't even enough to bother making a
patch, all it takes is the following lines added to forms-field-styling.xsl
(the diff is from my 2.1.8 vendor branch, but this fix will work in all
Cocoon versions):
forms-field-styling.xsl(working copy)
@@ -55,6 +55,9 @@
/xsl:if
!-- @id:input is what labels point to --
input name=[EMAIL PROTECTED] id=[EMAIL PROTECTED]:input
value={fi:value} title={fi:hint} type=text
+xsl:if test=fi:captcha-image
+ xsl:attribute name=autocomplete select='off'/
+/xsl:if
xsl:apply-templates select=. mode=styling/
/input
xsl:apply-templates select=. mode=common/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2158) XMLByteStreamCompiler hard-coded limits of 0xffff Strings prevents large XML documents from being handled in Cocoon
[ https://issues.apache.org/jira/browse/COCOON-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo closed COCOON-2158. Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN) 2.1.12-dev (Current SVN) 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 Fix For: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Attachments: cocoon-xmlbytestream-bigstrings.patch, 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] Assigned: (COCOON-2163) Widget Label is not Show/Hide when we change the widget state in ajax mode
[ https://issues.apache.org/jira/browse/COCOON-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo reassigned COCOON-2163: Assignee: Antonio Gallardo Widget Label is not Show/Hide when we change the widget state in ajax mode -- Key: COCOON-2163 URL: https://issues.apache.org/jira/browse/COCOON-2163 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Carlos Chávez Assignee: Antonio Gallardo Priority: Minor Attachments: widget_states_patch.txt There is an issue when we change the state of the widget. if initially the widget is active and we change the state to invisible the label of the widget is not hided if initially the widget is invisible and we change the state to active the label of the widget is not showed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2163) Widget Label is not Show/Hide when we change the widget state in ajax mode
[ https://issues.apache.org/jira/browse/COCOON-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo updated COCOON-2163: - Fix Version/s: (was: 2.1.12-dev (Current SVN)) Summary: Widget Label is not Show/Hide when we change the widget state in ajax mode (was: Widget Label is not Show/Hide when we change the widget state) Widget Label is not Show/Hide when we change the widget state in ajax mode -- Key: COCOON-2163 URL: https://issues.apache.org/jira/browse/COCOON-2163 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Carlos Chávez Priority: Minor Attachments: widget_states_patch.txt There is an issue when we change the state of the widget. if initially the widget is active and we change the state to invisible the label of the widget is not hided if initially the widget is invisible and we change the state to active the label of the widget is not showed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2158) XMLByteStreamCompiler hard-coded limits of 0xffff Strings prevents large XML documents from being handled in Cocoon
[ https://issues.apache.org/jira/browse/COCOON-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556039#action_12556039 ] Antonio Gallardo commented on COCOON-2158: -- Code from 2.2 is already backported. Also the testcase was extended to show this issue (in AbstractXMLTestCase.java replace line 59 with 58 - currently commented). 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-bigstrings.patch, 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-2052) Allow Ajax submission of forms with empty upload field
[ https://issues.apache.org/jira/browse/COCOON-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551921 ] Antonio Gallardo commented on COCOON-2052: -- Thanks for the patch. I applied it to 2.1.11-dev. To close the issue, please apply it to 2.2-dev. Allow Ajax submission of forms with empty upload field -- Key: COCOON-2052 URL: https://issues.apache.org/jira/browse/COCOON-2052 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms Affects Versions: 2.1.11-dev (Current SVN) Reporter: Robin Wyles Priority: Minor Fix For: 2.1.11-dev (Current SVN) Attachments: AjaxForm-upload-patch.txt Currently AjaxForm.js disables Ajax if the form contains an active upload field regardless of whether it contains a value or not. This simple patch only disables Ajax if the upload field is active and has a value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2032) [PATCH] Sort order in paginated repeater
[ https://issues.apache.org/jira/browse/COCOON-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547311 ] Antonio Gallardo commented on COCOON-2032: -- Would you provide a sample for the cocoon demo? [PATCH] Sort order in paginated repeater Key: COCOON-2032 URL: https://issues.apache.org/jira/browse/COCOON-2032 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN) Reporter: Gustavo N. Fernandes Attachments: sort_repeater.patch Little improvement to the sort-by paginated repeater command. With this patch the command will togle between sorting ascending, descending and unsorted. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-1251) XSP compile failure when using Java 1.5 features
[
https://issues.apache.org/jira/browse/COCOON-1251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Gallardo closed COCOON-1251.
Resolution: Fixed
Fix Version/s: 2.1.11-dev (Current SVN)
Fixed by Alfrad Nathaniel in:
http://svn.apache.org/viewvc?view=revrevision=555089
XSP compile failure when using Java 1.5 features
Key: COCOON-1251
URL: https://issues.apache.org/jira/browse/COCOON-1251
Project: Cocoon
Issue Type: Bug
Components: Blocks: XSP
Affects Versions: 2.1.5
Environment: Operating System: Linux
Platform: PC
Reporter: Thomas Zehetbauer
Assignee: Antonio Gallardo
Fix For: 2.1.11-dev (Current SVN)
I am trying to use the new JDK1.5 foreach loop in XSP, basically:
List entries = new ArrayList();
for (Map entry: entries) {
...
}
which causes the following error with the default EclipseJavaCompiler:
// start error (lines 1003-1003) Syntax error on token :, ;
expected
for (Map entry: entries)
{
// end error
or even with the Javac compiler:
/home/tomcat/work/Default/beta.hostmaster.org/_/cocoon-
files/org/apache/cocoon/www/Dictionary_xsp.java:1003: ';' expected.
for (Map entry: entries)
{
Cocoon is running under Tomcat 5.0.28 on j2sdk-1.5.0-beta2-b51.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-1440) [poi] color string normalization
[ https://issues.apache.org/jira/browse/COCOON-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo reassigned COCOON-1440: Assignee: Antonio Gallardo (was: Cocoon Developers Team) [poi] color string normalization Key: COCOON-1440 URL: https://issues.apache.org/jira/browse/COCOON-1440 Project: Cocoon Issue Type: Improvement Components: Blocks: POI Affects Versions: 2.1.6 Environment: Operating System: All Platform: PC Reporter: Krystian Nowak Assignee: Antonio Gallardo Priority: Minor Attachments: COCOON-1440.patch, COCOON-1440.patch, ColorCodeTest.java In a constructor of ColorCode (org.apache.cocoon.components.elementprocessor.impl.poi.hssf.elements) there could be a normalization check to ensure that even if the color string is in form :: it will be normalized to org.apache.poi.hssf.util.HSSFColor's form which is :0:0. I've spend a lot on debugging to get what's going on... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-1440) [poi] color string normalization
[ https://issues.apache.org/jira/browse/COCOON-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo closed COCOON-1440. Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN) 2.1.11-dev (Current SVN) Thanks for the patch. It was applied with minor changes. Feel free to reopen if needed. [poi] color string normalization Key: COCOON-1440 URL: https://issues.apache.org/jira/browse/COCOON-1440 Project: Cocoon Issue Type: Improvement Components: Blocks: POI Affects Versions: 2.1.6 Environment: Operating System: All Platform: PC Reporter: Krystian Nowak Assignee: Antonio Gallardo Priority: Minor Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Attachments: COCOON-1440.patch, COCOON-1440.patch, ColorCodeTest.java In a constructor of ColorCode (org.apache.cocoon.components.elementprocessor.impl.poi.hssf.elements) there could be a normalization check to ensure that even if the color string is in form :: it will be normalized to org.apache.poi.hssf.util.HSSFColor's form which is :0:0. I've spend a lot on debugging to get what's going on... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-1958) Some Errors by serializing with the HSSFGenerator generated Excel-Sheet with style-informations (no Problems without)
[ https://issues.apache.org/jira/browse/COCOON-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo updated COCOON-1958: - Status: On Hold (was: Open) Would you provide a patch? or the lines numbers you are refering for? Many thanks in advance. Some Errors by serializing with the HSSFGenerator generated Excel-Sheet with style-informations (no Problems without) - Key: COCOON-1958 URL: https://issues.apache.org/jira/browse/COCOON-1958 Project: Cocoon Issue Type: Bug Components: Blocks: POI Affects Versions: 2.1.9 Reporter: Rolf Metternich For building an Excel-Sheet, I have to generate an Excel-Sheet by HSSFGenerator, manulpulate the values by a transformer and serialize as an Excel-Sheet. The first test are: generating an Excel-Sheet and serialize direct. Then, in the optimal case, the Excel-Sheet looks like the original. But there raised some error for which I made a workaround. First there was a NPE for fore- and background-colors by generation. I made a try-catch and set 'new HSSFColor.BLACK().getHexString()' for the foreground-color and 'new HSSFColor.WHITE().getHexString()' for the background when an error occures. This error occures only in cells, where the fore- and background-settings in Excel are automatic and none. patternColor (error on serializing) I set to 'attribute(PatternColor, new HSSFColor.WHITE().getHexString())'; Bold (error on serializing) I set the attribute from 'Short.toString(font.getBoldweight())' to ((font.getBoldweight()=font.BOLDWEIGHT_BOLD ) ? 1:0). With this workaround, the generation-serialization of the Excel-Sheet work, but no images are imported, like a logo-jpg. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2097) Old excalibur-sourcereolve is still in lib directory after r557984
[ https://issues.apache.org/jira/browse/COCOON-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo closed COCOON-2097. Resolution: Fixed Assignee: Antonio Gallardo Fixed. See: http://svn.apache.org/viewvc?view=revrevision=560052 Old excalibur-sourcereolve is still in lib directory after r557984 -- Key: COCOON-2097 URL: https://issues.apache.org/jira/browse/COCOON-2097 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11-dev (Current SVN) Reporter: Richard Frovarp Assignee: Antonio Gallardo Fix For: 2.1.11-dev (Current SVN) The old exaclibur-sourcereolve jar is still present, but no longer referenced in jars.xml. Several people using Lenya have had issues building due to this. Removing the offending jar fixes the issue. I see in r557984 the license was removed for the old version, and cocoon/branches/BRANCH_2_1_X/lib/core/excalibur-sourceresolve-2.1.jar was modified. It would appear that it should have been deleted instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2058) Ambiguous rule match for fi:styling/@submit-on-change
[
https://issues.apache.org/jira/browse/COCOON-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Gallardo updated COCOON-2058:
-
Component/s: (was: * Cocoon Core)
Blocks: Forms
This issue is a cforms issue.
Ambiguous rule match for fi:styling/@submit-on-change
---
Key: COCOON-2058
URL: https://issues.apache.org/jira/browse/COCOON-2058
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Reporter: Ralph Collett
Priority: Minor
Ambiguous rule match for fi:styling/@submit-on-change between
fi:styling/@submit-on-change and fi:styling/@* in forms-field-styling.xsl
rules when using Saxon. Priority of fi:styling/@submit-on-change should be
set to 1 (as in the fi:styling/@type rule).
--- Starting at line 151 of forms-field-styling.xsl ---
xsl:template match=fi:styling/@* mode=styling
xsl:copy-of select=./
/xsl:template
xsl:template match=fi:styling/@submit-on-change mode=styling
xsl:if test=. = 'true'
xsl:attribute name=onchangeforms_submitForm(this)/xsl:attribute
/xsl:if
/xsl:template
xsl:template match=fi:styling/@list-type | fi:styling/@list-orientation |
fi:styling/@listbox-size | fi:styling/@format |
fi:styling/@layout
mode=styling
!--+
| Ignore marker attributes so they don't go into the resuling HTML.
+--
/xsl:template
xsl:template match=fi:styling/@type mode=styling priority=1
!--+
| Do we have a duplicate semantic usage of @type?
| @type is only a marker for the stylesheet in general, but some of
the
| types must/should be in the HTML output too.
+--
xsl:variable name=validHTMLTypes
select='text hidden checkbox radio password image reset
submit'/
xsl:if test=normalize-space(.) and
contains(concat(' ', $validHTMLTypes, ' '), concat(' ', .,
' '))
xsl:copy-of select=./
/xsl:if
/xsl:template
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2073) Upgrade to dojo 0.4.3 (security fixes!)
[ https://issues.apache.org/jira/browse/COCOON-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515928 ] Antonio Gallardo commented on COCOON-2073: -- Updated in 2.1, see: http://svn.apache.org/viewvc?view=revrevision=560056 Upgrade to dojo 0.4.3 (security fixes!) --- Key: COCOON-2073 URL: https://issues.apache.org/jira/browse/COCOON-2073 Project: Cocoon Issue Type: Improvement Components: Blocks: Ajax Affects Versions: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Alexander Klimetschek Assignee: Grzegorz Kossakowski Current ajax block includes dojo 0.4.1. The current release of dojo is 0.4.3 - in 0.4.2 minor improvements were made but 0.4.3 includes security fixes for cross-site scripting attacks and the guys at dojo strongly recommend upgrading. As far as I can see, there should be no compatibility issues with Cocoon's dojo widgets. http://dojotoolkit.org/releaseNotes/0.4.3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2027) [PATCH] Handling of empty responses in AJAX Forms with IFrame transport
[ https://issues.apache.org/jira/browse/COCOON-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo closed COCOON-2027. Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN) 2.1.11-dev (Current SVN) Thanks for the patch. It was applied in both branches (2.1.11-dev and 2.2). Feel free to reopen the issue if needed. [PATCH] Handling of empty responses in AJAX Forms with IFrame transport --- Key: COCOON-2027 URL: https://issues.apache.org/jira/browse/COCOON-2027 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Jan Oberst Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Attachments: cocoon-iframe-continue.patch We are experiencing problems with Cocoon Forms under following circumstances: - Using an AJAX-form - with file-upload (using the IFRAME Dojo transport accordingly) - using MSIE 6 or 7 - pressing the cancel button In this case, an empty response is send. Because of browser limitations, an empty response is emulated using the bu:continue browser-update construct. Microsoft Internet Explorer expects always HTML response when dealing with the IFrame transport, so it cannot handle the XML-response (bu:continute) generated by Cocoon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2031) Language Exception at Runtime by the attempt to compile a random XSP
[
https://issues.apache.org/jira/browse/COCOON-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Gallardo updated COCOON-2031:
-
Component/s: (was: * Cocoon Core)
Blocks: XSP
This is a XSP block issue.
Language Exception at Runtime by the attempt to compile a random XSP
Key: COCOON-2031
URL: https://issues.apache.org/jira/browse/COCOON-2031
Project: Cocoon
Issue Type: Bug
Components: Blocks: XSP
Affects Versions: 2.1.7
Reporter: Sebastian Wenzky
Priority: Critical
Hi there,
at my topic you have a first imagination about my current (very hard) problem.
But at fist, my enumeration of my software components:
- Cocoon 2.18
- JBoss (Version 4) - Tomcat.
Indeed, i have no explanation, for my confuse problem and i don´t know, what
kind of state occures that. Normally, when cocoon starts at first time there
are no problems. I can go, visit different pages (which will be correctly
compiled) and so on... But sometimes later the error occurs suddenly, without
any real worthwhile exception message to me.
But the tracer in cocoon said to me following text(an excerpt):
ERROR (2007-03-10) 07:44.24:308 [sitemap.handled-errors]
(/jobapp3/content/fhj/user.xsp$user-search$meta-html)
TP-Processor8/ErrorHandlerHelper: Language Exception
org.apache.cocoon.ProcessingException: Language Exception:
org.apache.cocoon.components.language.LanguageException: Error compiling
user_xsp:
ERROR 1 (org/apache/cocoon/www/docs/content/user_xsp.java):
...
name,
name,
CDATA,
pst_id
// start error (lines 1044-1044) Syntax error, insert ) to complete
Expression
);
// end error
this.contentHandler.startElement(
http://apache.org/xsp/request/2.0;;,
...
ERROR 2 (org/apache/cocoon/www/docs/content/user_xsp.java):
...
get-parameter,
xsp-request:get-parameter
);
// start error (lines 1063-1063) Syntax error on token ), delete this
token
);
// end error
if ( pstID != null )
{
...
Line 1044, column 0: Syntax error, insert ) to complete Expression
Line 1063, column 0: Syntax error on token ), delete this token
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.loadProgram(ProgramGeneratorImpl.java:409)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:280)
at
org.apache.cocoon.generation.ServerPagesGenerator.setup(ServerPagesGenerator.java:170)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline(AbstractProcessingPipeline.java:385)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.setupPipeline(AbstractCachingProcessingPipeline.java:620)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipeline(AbstractProcessingPipeline.java:503)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:455)
at
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:120)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
at
org.apache.cocoon.components.treeprocessor.sitemap.SwitchSelectNode.invoke(SwitchSelectNode.java:103)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:138)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
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.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
at
[jira] Updated: (COCOON-2031) Language Exception at Runtime by the attempt to compile a random XSP
[
https://issues.apache.org/jira/browse/COCOON-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Gallardo updated COCOON-2031:
-
Status: On Hold (was: Open)
Hi Sebastian,
The issue seems to be a race condition that was fixed in 2.1.10: (taken from
http://cocoon.apache.org/2.1/changes.html )
XSP block: Fix regression introduced in 2.1.8 that under specific
circumstances logicsheets were not applied, leading to compilation errors. This
manifested itself only if a) two XSPs referred to the same custom logicsheet by
a relative location path, b) the custom logicsheet used another logicsheet, and
c) the built-in logicsheet's namespace was not mentioned in xsp:page. The
compilation errors occurred always when calling the second XSP for the first
time. Fix also race condition which could lead to similar XSP compilation
errors under high load when accessing the same logicsheet for the first time.
Committed by AN.
Let us know if just moving to cocon 2.1.10 fix the issue.
Language Exception at Runtime by the attempt to compile a random XSP
Key: COCOON-2031
URL: https://issues.apache.org/jira/browse/COCOON-2031
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Affects Versions: 2.1.7
Reporter: Sebastian Wenzky
Priority: Critical
Hi there,
at my topic you have a first imagination about my current (very hard) problem.
But at fist, my enumeration of my software components:
- Cocoon 2.18
- JBoss (Version 4) - Tomcat.
Indeed, i have no explanation, for my confuse problem and i don´t know, what
kind of state occures that. Normally, when cocoon starts at first time there
are no problems. I can go, visit different pages (which will be correctly
compiled) and so on... But sometimes later the error occurs suddenly, without
any real worthwhile exception message to me.
But the tracer in cocoon said to me following text(an excerpt):
ERROR (2007-03-10) 07:44.24:308 [sitemap.handled-errors]
(/jobapp3/content/fhj/user.xsp$user-search$meta-html)
TP-Processor8/ErrorHandlerHelper: Language Exception
org.apache.cocoon.ProcessingException: Language Exception:
org.apache.cocoon.components.language.LanguageException: Error compiling
user_xsp:
ERROR 1 (org/apache/cocoon/www/docs/content/user_xsp.java):
...
name,
name,
CDATA,
pst_id
// start error (lines 1044-1044) Syntax error, insert ) to complete
Expression
);
// end error
this.contentHandler.startElement(
http://apache.org/xsp/request/2.0;;,
...
ERROR 2 (org/apache/cocoon/www/docs/content/user_xsp.java):
...
get-parameter,
xsp-request:get-parameter
);
// start error (lines 1063-1063) Syntax error on token ), delete this
token
);
// end error
if ( pstID != null )
{
...
Line 1044, column 0: Syntax error, insert ) to complete Expression
Line 1063, column 0: Syntax error on token ), delete this token
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.loadProgram(ProgramGeneratorImpl.java:409)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:280)
at
org.apache.cocoon.generation.ServerPagesGenerator.setup(ServerPagesGenerator.java:170)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline(AbstractProcessingPipeline.java:385)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.setupPipeline(AbstractCachingProcessingPipeline.java:620)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipeline(AbstractProcessingPipeline.java:503)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:455)
at
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:120)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
at
org.apache.cocoon.components.treeprocessor.sitemap.SwitchSelectNode.invoke(SwitchSelectNode.java:103)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:138)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
at
[jira] Reopened: (COCOON-2065) huge performance increase of LuceneIndexTransformer on large Lucene indexes
[ https://issues.apache.org/jira/browse/COCOON-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo reopened COCOON-2065: -- Patch was not applied in cocon 2.1.11-dev. huge performance increase of LuceneIndexTransformer on large Lucene indexes --- Key: COCOON-2065 URL: https://issues.apache.org/jira/browse/COCOON-2065 Project: Cocoon Issue Type: Improvement Components: Blocks: Lucene Affects Versions: 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Dominique De Munck Assignee: Felix Knecht Priority: Minor Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Attachments: LuceneIndexTransformer.patch PROBLEM: The LuceneIndexTransformer optimizes the Lucene index every time you add an entry to the index. This slows down enormously the indexing with a large index ! If upon every checkin of a document eg, you use it to update the entry, it will slow down. Eg. I have a Pentium IV 2.4 Ghz, Lucene index contains 10 000 doc. Where the index update only takes say 60ms, the optimize that get's called, can take 7 seconds! SOLUTION: I've created a patch that introduces an option optimize-frequency to determine the frequency of the optimize call. It defaults to 1 (current behaviour), when a user sets it to 50, only once every 50 updates the index will be optimized etc If no optimization is wanted, you can set it to 0. This is compliant to the Lucene documentation (fragment of Lucene FAQ): The IndexWriter class supports an optimize() method that compacts the index database and speedup queries. You may want to use this method after performing a complete indexing of your document set or after incremental updates of the index. If your incremental update adds documents frequently, you want to perform the optimization only once in a while to avoid the extra overhead of the optimization. PATCH INFO: added configuration option + a function needToOptimize() which is called before optimizing. needToOptimize() uses a random function generator, to keep code simple. - when the option is not set, CODE WILL BE EXECUTED AS BEFORE - tested one 2.1.11 SVN branch, but no differences in the main trunk thus can be applied there also. - Updated API docs - if patch accepted, I will also update the Wiki: http://wiki.apache.org/cocoon/LuceneIndexTransformer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2058) Ambiguous rule match for fi:styling/@submit-on-change
[
https://issues.apache.org/jira/browse/COCOON-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514223
]
Antonio Gallardo commented on COCOON-2058:
--
I am wondering if is a good idea to add priorities to xslt rules for the
default cform rendering. I am thinking for the users that overwrote this rules.
wdyt?
Ambiguous rule match for fi:styling/@submit-on-change
---
Key: COCOON-2058
URL: https://issues.apache.org/jira/browse/COCOON-2058
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Reporter: Ralph Collett
Priority: Minor
Ambiguous rule match for fi:styling/@submit-on-change between
fi:styling/@submit-on-change and fi:styling/@* in forms-field-styling.xsl
rules when using Saxon. Priority of fi:styling/@submit-on-change should be
set to 1 (as in the fi:styling/@type rule).
--- Starting at line 151 of forms-field-styling.xsl ---
xsl:template match=fi:styling/@* mode=styling
xsl:copy-of select=./
/xsl:template
xsl:template match=fi:styling/@submit-on-change mode=styling
xsl:if test=. = 'true'
xsl:attribute name=onchangeforms_submitForm(this)/xsl:attribute
/xsl:if
/xsl:template
xsl:template match=fi:styling/@list-type | fi:styling/@list-orientation |
fi:styling/@listbox-size | fi:styling/@format |
fi:styling/@layout
mode=styling
!--+
| Ignore marker attributes so they don't go into the resuling HTML.
+--
/xsl:template
xsl:template match=fi:styling/@type mode=styling priority=1
!--+
| Do we have a duplicate semantic usage of @type?
| @type is only a marker for the stylesheet in general, but some of
the
| types must/should be in the HTML output too.
+--
xsl:variable name=validHTMLTypes
select='text hidden checkbox radio password image reset
submit'/
xsl:if test=normalize-space(.) and
contains(concat(' ', $validHTMLTypes, ' '), concat(' ', .,
' '))
xsl:copy-of select=./
/xsl:if
/xsl:template
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (COCOON-2073) Upgrade to dojo 0.4.3 (security fixes!)
[ https://issues.apache.org/jira/browse/COCOON-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo reopened COCOON-2073: -- At least in 2.1.11-dev this seems to not being fixed (for Linux?). Add the next line to a any page with dojo and it sends back 0.4.1: dojo.debug(The current version of dojo is: , dojo.version.toString()); Upgrade to dojo 0.4.3 (security fixes!) --- Key: COCOON-2073 URL: https://issues.apache.org/jira/browse/COCOON-2073 Project: Cocoon Issue Type: Improvement Components: Blocks: Ajax Affects Versions: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Alexander Klimetschek Assignee: Grzegorz Kossakowski Current ajax block includes dojo 0.4.1. The current release of dojo is 0.4.3 - in 0.4.2 minor improvements were made but 0.4.3 includes security fixes for cross-site scripting attacks and the guys at dojo strongly recommend upgrading. As far as I can see, there should be no compatibility issues with Cocoon's dojo widgets. http://dojotoolkit.org/releaseNotes/0.4.3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (COCOON-2059) ajax/common.js makes use of deprecated dojo.animation.Timer
[
https://issues.apache.org/jira/browse/COCOON-2059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Gallardo reopened COCOON-2059:
--
ajax/common.js makes use of deprecated dojo.animation.Timer
---
Key: COCOON-2059
URL: https://issues.apache.org/jira/browse/COCOON-2059
Project: Cocoon
Issue Type: Bug
Components: Blocks: Ajax
Affects Versions: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN)
Reporter: Alexander Klimetschek
Assignee: Grzegorz Kossakowski
Following code uses deprecated stuff from dojo 0.4.1:
periodicalUpdate: function(delay, href, target, insertion) {
dojo.require(dojo.animation.Timer);
var timer = new dojo.animation.Timer(delay);
timer.onTick = function() {
Dojo in debug mode says: DEPRECATED: dojo.animation.Timer is now
dojo.lang.timing.Timer 0.5
To fix that, one should simply use:
periodicalUpdate: function(delay, href, target, insertion) {
dojo.require(dojo.lang.timing.Timer);
var timer = new dojo.lang.timing.Timer(delay);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2059) ajax/common.js makes use of deprecated dojo.animation.Timer
[
https://issues.apache.org/jira/browse/COCOON-2059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Gallardo closed COCOON-2059.
Resolution: Fixed
Fix Version/s: 2.1.11-dev (Current SVN)
ajax/common.js makes use of deprecated dojo.animation.Timer
---
Key: COCOON-2059
URL: https://issues.apache.org/jira/browse/COCOON-2059
Project: Cocoon
Issue Type: Bug
Components: Blocks: Ajax
Affects Versions: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN)
Reporter: Alexander Klimetschek
Assignee: Grzegorz Kossakowski
Fix For: 2.1.11-dev (Current SVN)
Following code uses deprecated stuff from dojo 0.4.1:
periodicalUpdate: function(delay, href, target, insertion) {
dojo.require(dojo.animation.Timer);
var timer = new dojo.animation.Timer(delay);
timer.onTick = function() {
Dojo in debug mode says: DEPRECATED: dojo.animation.Timer is now
dojo.lang.timing.Timer 0.5
To fix that, one should simply use:
periodicalUpdate: function(delay, href, target, insertion) {
dojo.require(dojo.lang.timing.Timer);
var timer = new dojo.lang.timing.Timer(delay);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2058) Ambiguous rule match for fi:styling/@submit-on-change
[
https://issues.apache.org/jira/browse/COCOON-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Gallardo updated COCOON-2058:
-
Status: On Hold (was: Open)
Would you post saxon error message?
Ambiguous rule match for fi:styling/@submit-on-change
---
Key: COCOON-2058
URL: https://issues.apache.org/jira/browse/COCOON-2058
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Reporter: Ralph Collett
Priority: Minor
Ambiguous rule match for fi:styling/@submit-on-change between
fi:styling/@submit-on-change and fi:styling/@* in forms-field-styling.xsl
rules when using Saxon. Priority of fi:styling/@submit-on-change should be
set to 1 (as in the fi:styling/@type rule).
--- Starting at line 151 of forms-field-styling.xsl ---
xsl:template match=fi:styling/@* mode=styling
xsl:copy-of select=./
/xsl:template
xsl:template match=fi:styling/@submit-on-change mode=styling
xsl:if test=. = 'true'
xsl:attribute name=onchangeforms_submitForm(this)/xsl:attribute
/xsl:if
/xsl:template
xsl:template match=fi:styling/@list-type | fi:styling/@list-orientation |
fi:styling/@listbox-size | fi:styling/@format |
fi:styling/@layout
mode=styling
!--+
| Ignore marker attributes so they don't go into the resuling HTML.
+--
/xsl:template
xsl:template match=fi:styling/@type mode=styling priority=1
!--+
| Do we have a duplicate semantic usage of @type?
| @type is only a marker for the stylesheet in general, but some of
the
| types must/should be in the HTML output too.
+--
xsl:variable name=validHTMLTypes
select='text hidden checkbox radio password image reset
submit'/
xsl:if test=normalize-space(.) and
contains(concat(' ', $validHTMLTypes, ' '), concat(' ', .,
' '))
xsl:copy-of select=./
/xsl:if
/xsl:template
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2040) Union widget does not work with booleanfield set as case widget
[ https://issues.apache.org/jira/browse/COCOON-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487434 ] Antonio Gallardo commented on COCOON-2040: -- Is not possible to resume the whole patch to this change in JXMacrosHelper.java: from: String value = (String)unionWidget.getValue(); to: String value = unionWidget.getValue(); Is there a test case to check it? Union widget does not work with booleanfield set as case widget --- Key: COCOON-2040 URL: https://issues.apache.org/jira/browse/COCOON-2040 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: cocoon-forms-impl-union.patch Union widget compares values without performing conversion. Booleanfield returns Boolean object, so result of comparison is always false. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-1579) Continuation, sendPage and Rhino 1.6r1
[ https://issues.apache.org/jira/browse/COCOON-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo updated COCOON-1579: - Affects Version/s: 2.1.9 2.1.10 Continuation, sendPage and Rhino 1.6r1 -- Key: COCOON-1579 URL: https://issues.apache.org/jira/browse/COCOON-1579 Project: Cocoon Issue Type: Bug Components: - Flowscript Affects Versions: 2.1.8, 2.1.9, 2.1.10 Environment: Operating System: Linux Platform: PC Reporter: Philippe Gassmann Attachments: bug.tar I use Rhino 1.6r1 (from trunk svn) in my cocoon. I get a NullPointerException in that case : I first call a flow function to display a jx template using a continuation. Then I post the form (and the continuation) to a pipeline calling a flow function that does a cocoon.sendPage to a pipeline calling the continuation. Then, I does some things in the flow and I display the jx template again. The first time I post the form : OK it's working. The second time I post the form : A NullPointerException is thrown ! Here is the full java stacktrace : java.lang.NullPointerException at org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.jsGet_continuation(FOM_Cocoon.java:252) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:174) at org.mozilla.javascript.ScriptableObject.getByGetter(ScriptableObject.java:1617) at org.mozilla.javascript.ScriptableObject.get(ScriptableObject.java:177) at org.mozilla.javascript.ScriptableObject.getProperty(ScriptableObject.java:1263) at org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1332) at org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1321) at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2744) at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2164) at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:140) at org.mozilla.javascript.Context.call(Context.java:497) at org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java:1496) at org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java:1466) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.handleContinuation(FOM_JavaScriptInterpreter.java:861) at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:123) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.SelectNode.invoke(SelectNode.java:102) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:142) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) 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.handleCocoonRedirect(ConcreteTreeProcessor.java:298) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.access$000(ConcreteTreeProcessor.java:47) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor$TreeProcessorRedirector.cocoonRedirect(ConcreteTreeProcessor.java:339) at org.apache.cocoon.environment.ForwardRedirector.redirect(ForwardRedirector.java:59) at org.apache.cocoon.components.flow.AbstractInterpreter.forwardTo(AbstractInterpreter.java:209) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.forwardTo(FOM_JavaScriptInterpreter.java:914) at org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.forwardTo(FOM_Cocoon.java:698) at
[jira] Commented: (COCOON-1579) Continuation, sendPage and Rhino 1.6r1
[ https://issues.apache.org/jira/browse/COCOON-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481372 ] Antonio Gallardo commented on COCOON-1579: -- wiki page describing a workaround for this issue: http://wiki.apache.org/cocoon/WorkaroundForCOCOON-1579 Continuation, sendPage and Rhino 1.6r1 -- Key: COCOON-1579 URL: https://issues.apache.org/jira/browse/COCOON-1579 Project: Cocoon Issue Type: Bug Components: - Flowscript Affects Versions: 2.1.8, 2.1.9, 2.1.10 Environment: Operating System: Linux Platform: PC Reporter: Philippe Gassmann Attachments: bug.tar I use Rhino 1.6r1 (from trunk svn) in my cocoon. I get a NullPointerException in that case : I first call a flow function to display a jx template using a continuation. Then I post the form (and the continuation) to a pipeline calling a flow function that does a cocoon.sendPage to a pipeline calling the continuation. Then, I does some things in the flow and I display the jx template again. The first time I post the form : OK it's working. The second time I post the form : A NullPointerException is thrown ! Here is the full java stacktrace : java.lang.NullPointerException at org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.jsGet_continuation(FOM_Cocoon.java:252) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:174) at org.mozilla.javascript.ScriptableObject.getByGetter(ScriptableObject.java:1617) at org.mozilla.javascript.ScriptableObject.get(ScriptableObject.java:177) at org.mozilla.javascript.ScriptableObject.getProperty(ScriptableObject.java:1263) at org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1332) at org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1321) at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2744) at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2164) at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:140) at org.mozilla.javascript.Context.call(Context.java:497) at org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java:1496) at org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java:1466) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.handleContinuation(FOM_JavaScriptInterpreter.java:861) at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:123) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.SelectNode.invoke(SelectNode.java:102) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:142) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) 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.handleCocoonRedirect(ConcreteTreeProcessor.java:298) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.access$000(ConcreteTreeProcessor.java:47) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor$TreeProcessorRedirector.cocoonRedirect(ConcreteTreeProcessor.java:339) at org.apache.cocoon.environment.ForwardRedirector.redirect(ForwardRedirector.java:59) at org.apache.cocoon.components.flow.AbstractInterpreter.forwardTo(AbstractInterpreter.java:209) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.forwardTo(FOM_JavaScriptInterpreter.java:914) at org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.forwardTo(FOM_Cocoon.java:698) at
[jira] Assigned: (COCOON-2023) MultivalueEditorWihtSuggestion doesn't add values to the listbox on Internet Explorer
[ https://issues.apache.org/jira/browse/COCOON-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo reassigned COCOON-2023: Assignee: Antonio Gallardo MultivalueEditorWihtSuggestion doesn't add values to the listbox on Internet Explorer - Key: COCOON-2023 URL: https://issues.apache.org/jira/browse/COCOON-2023 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.11-dev (Current SVN) Reporter: Larry Ruiz Assigned To: Antonio Gallardo Attachments: ie7compatability_patch.txt It seems that onkeypress event listener isn't called on Internet Explorer. The workaround is to attach a listener on method _handleKeyEvents of combobox widget. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2023) MultivalueEditorWihtSuggestion doesn't add values to the listbox on Internet Explorer
[ https://issues.apache.org/jira/browse/COCOON-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo closed COCOON-2023. Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN) 2.1.11-dev (Current SVN) Thanks for the patch. Please cross check and feel free to reopen if needed. MultivalueEditorWihtSuggestion doesn't add values to the listbox on Internet Explorer - Key: COCOON-2023 URL: https://issues.apache.org/jira/browse/COCOON-2023 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.11-dev (Current SVN) Reporter: Larry Ruiz Assigned To: Antonio Gallardo Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Attachments: ie7compatability_patch.txt It seems that onkeypress event listener isn't called on Internet Explorer. The workaround is to attach a listener on method _handleKeyEvents of combobox widget. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2013) MultivalueEditorWithSuggestion, extended multivalueeditor widget with suggestion
[ https://issues.apache.org/jira/browse/COCOON-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo updated COCOON-2013: - The small issue found in the code is a sample issue. It is fixed in the sample. MultivalueEditorWithSuggestion, extended multivalueeditor widget with suggestion Key: COCOON-2013 URL: https://issues.apache.org/jira/browse/COCOON-2013 Project: Cocoon Issue Type: Improvement Components: Blocks: Ajax, Blocks: Forms Affects Versions: 2.1.10 Reporter: Larry Ruiz Assigned To: Antonio Gallardo Priority: Minor Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Attachments: multivalueeditor_with_suggestion_patch.txt, multivalueeditor_with_suggestion_patch_sample_patch.txt Enhance multivalueeditor with suggestion in definition: fd:multivaluefield id=contacts fd:labelContacts/fd:label fd:hintSelect the contacts/fd:hint fd:datatype base=long / /fd:multivaluefield in template: ft:widget id=contacts fi:styling type=MultiValueEditorWithSuggestion dataUrl=_cocoon/forms/suggest/contacts/ /ft:widget then it need a matcher that return data in json format for this url _cocoon/forms/suggest/contacts default dataUrl got it from _cocoon/forms/suggest/ + widgetId, at least that one is specified. the patches include widget implementation code and samples. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2013) MultivalueEditorWithSuggestion, extended multivalueeditor widget with suggestion
[ https://issues.apache.org/jira/browse/COCOON-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo closed COCOON-2013. Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN) 2.1.11-dev (Current SVN) Patch applied with minor changes. Please cross check and reopen the issue if needed. Many thanks for the patch. MultivalueEditorWithSuggestion, extended multivalueeditor widget with suggestion Key: COCOON-2013 URL: https://issues.apache.org/jira/browse/COCOON-2013 Project: Cocoon Issue Type: Improvement Components: Blocks: Ajax, Blocks: Forms Affects Versions: 2.1.10 Reporter: Larry Ruiz Assigned To: Antonio Gallardo Priority: Minor Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Attachments: multivalueeditor_with_suggestion_patch.txt, multivalueeditor_with_suggestion_patch_sample_patch.txt Enhance multivalueeditor with suggestion in definition: fd:multivaluefield id=contacts fd:labelContacts/fd:label fd:hintSelect the contacts/fd:hint fd:datatype base=long / /fd:multivaluefield in template: ft:widget id=contacts fi:styling type=MultiValueEditorWithSuggestion dataUrl=_cocoon/forms/suggest/contacts/ /ft:widget then it need a matcher that return data in json format for this url _cocoon/forms/suggest/contacts default dataUrl got it from _cocoon/forms/suggest/ + widgetId, at least that one is specified. the patches include widget implementation code and samples. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-1994) Make Forms resources loaded directly
[ https://issues.apache.org/jira/browse/COCOON-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo closed COCOON-1994. Resolution: Duplicate Make Forms resources loaded directly Key: COCOON-1994 URL: https://issues.apache.org/jira/browse/COCOON-1994 Project: Cocoon Issue Type: Sub-task Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Fix For: 2.2-dev (Current SVN) Steps required to achieve this goal are the same as in https://issues.apache.org/jira/browse/COCOON-1992 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2013) MultivalueEditorWithSuggestion, extended multivalueeditor widget with suggestion
[ https://issues.apache.org/jira/browse/COCOON-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo reassigned COCOON-2013: Assignee: Antonio Gallardo MultivalueEditorWithSuggestion, extended multivalueeditor widget with suggestion Key: COCOON-2013 URL: https://issues.apache.org/jira/browse/COCOON-2013 Project: Cocoon Issue Type: Improvement Components: Blocks: Ajax, Blocks: Forms Affects Versions: 2.1.10 Reporter: Larry Ruiz Assigned To: Antonio Gallardo Priority: Minor Attachments: multivalueeditor_with_suggestion_patch.txt, multivalueeditor_with_suggestion_patch_sample_patch.txt Enhance multivalueeditor with suggestion in definition: fd:multivaluefield id=contacts fd:labelContacts/fd:label fd:hintSelect the contacts/fd:hint fd:datatype base=long / /fd:multivaluefield in template: ft:widget id=contacts fi:styling type=MultiValueEditorWithSuggestion dataUrl=_cocoon/forms/suggest/contacts/ /ft:widget then it need a matcher that return data in json format for this url _cocoon/forms/suggest/contacts default dataUrl got it from _cocoon/forms/suggest/ + widgetId, at least that one is specified. the patches include widget implementation code and samples. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2013) MultivalueEditorWithSuggestion, extended multivalueeditor widget with suggestion
[ https://issues.apache.org/jira/browse/COCOON-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo updated COCOON-2013: - Great work! It is an amazing widget! However, I found a small issue, the suggestion list shows up Donald Ball only if the user press the uppper case D and not if the user press a lower case d. wdyt? MultivalueEditorWithSuggestion, extended multivalueeditor widget with suggestion Key: COCOON-2013 URL: https://issues.apache.org/jira/browse/COCOON-2013 Project: Cocoon Issue Type: Improvement Components: Blocks: Ajax, Blocks: Forms Affects Versions: 2.1.10 Reporter: Larry Ruiz Assigned To: Antonio Gallardo Priority: Minor Attachments: multivalueeditor_with_suggestion_patch.txt, multivalueeditor_with_suggestion_patch_sample_patch.txt Enhance multivalueeditor with suggestion in definition: fd:multivaluefield id=contacts fd:labelContacts/fd:label fd:hintSelect the contacts/fd:hint fd:datatype base=long / /fd:multivaluefield in template: ft:widget id=contacts fi:styling type=MultiValueEditorWithSuggestion dataUrl=_cocoon/forms/suggest/contacts/ /ft:widget then it need a matcher that return data in json format for this url _cocoon/forms/suggest/contacts default dataUrl got it from _cocoon/forms/suggest/ + widgetId, at least that one is specified. the patches include widget implementation code and samples. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2011) [improvement and patch] CFormsSuggest widget does not implement the on value changed event available for most cocoon form widgets
[
https://issues.apache.org/jira/browse/COCOON-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Gallardo reassigned COCOON-2011:
Assignee: Antonio Gallardo
[improvement and patch] CFormsSuggest widget does not implement the on value
changed event available for most cocoon form widgets
-
Key: COCOON-2011
URL: https://issues.apache.org/jira/browse/COCOON-2011
Project: Cocoon
Issue Type: Improvement
Components: Blocks: Ajax, Blocks: Forms
Affects Versions: 2.1.10
Reporter: Paul Friedman
Assigned To: Antonio Gallardo
Priority: Minor
Fix For: 2.1.11-dev (Current SVN)
Attachments: CFormsSuggest_patch
CFormsSuggest widget does not handle the on value changed event.
in definition:
fd:field id=xxx
fd:labelxxx/fd:label
fd:datatype base=long/
fd:suggestion-list type=javascript
return xxx(filter);
/fd:suggestion-list
fd:on-value-changed
fd:javascript
xxx_onValueChanged(event.source.getForm());
/fd:javascript
/fd:on-value-changed
/fd:field
in template:
ft:widget id=xxx type=suggest/
the patch for CFormsSuggest.js adds the onValueChanged function
onValueChanged: function(/*String*/ value){
if(this.onchange == cocoon.forms.submitForm(this)) {
cocoon.forms.submitForm(this.domNode, this.name);
}
},
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2011) [improvement and patch] CFormsSuggest widget does not implement the on value changed event available for most cocoon form widgets
[
https://issues.apache.org/jira/browse/COCOON-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Gallardo closed COCOON-2011.
Resolution: Fixed
Fix Version/s: 2.2-dev (Current SVN)
Thanks for the patch. Feel free to reopen the issue if needed.
[improvement and patch] CFormsSuggest widget does not implement the on value
changed event available for most cocoon form widgets
-
Key: COCOON-2011
URL: https://issues.apache.org/jira/browse/COCOON-2011
Project: Cocoon
Issue Type: Improvement
Components: Blocks: Ajax, Blocks: Forms
Affects Versions: 2.1.10
Reporter: Paul Friedman
Assigned To: Antonio Gallardo
Priority: Minor
Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN)
Attachments: CFormsSuggest_patch
CFormsSuggest widget does not handle the on value changed event.
in definition:
fd:field id=xxx
fd:labelxxx/fd:label
fd:datatype base=long/
fd:suggestion-list type=javascript
return xxx(filter);
/fd:suggestion-list
fd:on-value-changed
fd:javascript
xxx_onValueChanged(event.source.getForm());
/fd:javascript
/fd:on-value-changed
/fd:field
in template:
ft:widget id=xxx type=suggest/
the patch for CFormsSuggest.js adds the onValueChanged function
onValueChanged: function(/*String*/ value){
if(this.onchange == cocoon.forms.submitForm(this)) {
cocoon.forms.submitForm(this.domNode, this.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-1579) Continuation, sendPage and Rhino 1.6r1
[ https://issues.apache.org/jira/browse/COCOON-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465672 ] Antonio Gallardo commented on COCOON-1579: -- The attached test case still shows the error. Also the Sylvain comment is still valid. Looking into rhino, there are 2 interesting issues that seems to be close to this one: https://bugzilla.mozilla.org/show_bug.cgi?id=347154 https://bugzilla.mozilla.org/show_bug.cgi?id=366550 This is also another interesting link that may help to understand how rhino 1.6 is different that rhino 1.5 (our older forked version): http://www.mozilla.org/rhino/scopes.html Continuation, sendPage and Rhino 1.6r1 -- Key: COCOON-1579 URL: https://issues.apache.org/jira/browse/COCOON-1579 Project: Cocoon Issue Type: Bug Components: - Flowscript Affects Versions: 2.1.8 Environment: Operating System: Linux Platform: PC Reporter: Philippe Gassmann Attachments: bug.tar I use Rhino 1.6r1 (from trunk svn) in my cocoon. I get a NullPointerException in that case : I first call a flow function to display a jx template using a continuation. Then I post the form (and the continuation) to a pipeline calling a flow function that does a cocoon.sendPage to a pipeline calling the continuation. Then, I does some things in the flow and I display the jx template again. The first time I post the form : OK it's working. The second time I post the form : A NullPointerException is thrown ! Here is the full java stacktrace : java.lang.NullPointerException at org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.jsGet_continuation(FOM_Cocoon.java:252) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:174) at org.mozilla.javascript.ScriptableObject.getByGetter(ScriptableObject.java:1617) at org.mozilla.javascript.ScriptableObject.get(ScriptableObject.java:177) at org.mozilla.javascript.ScriptableObject.getProperty(ScriptableObject.java:1263) at org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1332) at org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1321) at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2744) at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2164) at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:140) at org.mozilla.javascript.Context.call(Context.java:497) at org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java:1496) at org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java:1466) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.handleContinuation(FOM_JavaScriptInterpreter.java:861) at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:123) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.SelectNode.invoke(SelectNode.java:102) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:142) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) 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.handleCocoonRedirect(ConcreteTreeProcessor.java:298) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.access$000(ConcreteTreeProcessor.java:47) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor$TreeProcessorRedirector.cocoonRedirect(ConcreteTreeProcessor.java:339) at org.apache.cocoon.environment.ForwardRedirector.redirect(ForwardRedirector.java:59) at
[jira] Updated: (COCOON-1962) Numeric based suggestion list should initialzate to the corresponding suggested text.
[ http://issues.apache.org/jira/browse/COCOON-1962?page=all ] Antonio Gallardo updated COCOON-1962: - Summary: Numeric based suggestion list should initialzate to the corresponding suggested text. (was: Suggestion List initialization improvement) Description: Hello, If we have a list with a numeric value and a suggested string text, when the form load at the first time is showing the numeric value instead the corresponding text. This patch improve the suggestion list to retrieve the corresponding suggested text from the server when we have the numeric value when we load the form. was: Hello, If we have a list with a numeric value and a suggested string text, when the form load at the first time is showing the numeric value instead the corresponding text. This patch improve the suggestion list to retrieve the corresponding suggested text from the server when we have the numeric value when we load the form. Numeric based suggestion list should initialzate to the corresponding suggested text. - Key: COCOON-1962 URL: http://issues.apache.org/jira/browse/COCOON-1962 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms Affects Versions: 2.1.10-dev (current SVN) Reporter: carlos chávez Assigned To: Antonio Gallardo Attachments: CFormsSuggest.txt, CFormsSuggestSample.txt Hello, If we have a list with a numeric value and a suggested string text, when the form load at the first time is showing the numeric value instead the corresponding text. This patch improve the suggestion list to retrieve the corresponding suggested text from the server when we have the numeric value when we load the form. -- 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-1962) Numeric based suggestion list should initialzate to the corresponding suggested text.
[ http://issues.apache.org/jira/browse/COCOON-1962?page=all ] Antonio Gallardo closed COCOON-1962. Fix Version/s: 2.1.10-dev (current SVN) Resolution: Fixed Thanks for the patch. Feel free to reopen the issue if needed. Numeric based suggestion list should initialzate to the corresponding suggested text. - Key: COCOON-1962 URL: http://issues.apache.org/jira/browse/COCOON-1962 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms Affects Versions: 2.1.10-dev (current SVN) Reporter: carlos chávez Assigned To: Antonio Gallardo Fix For: 2.1.10-dev (current SVN) Attachments: CFormsSuggest.txt, CFormsSuggestSample.txt Hello, If we have a list with a numeric value and a suggested string text, when the form load at the first time is showing the numeric value instead the corresponding text. This patch improve the suggestion list to retrieve the corresponding suggested text from the server when we have the numeric value when we load the form. -- 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-1962) Suggestion List initialization improvement
[ http://issues.apache.org/jira/browse/COCOON-1962?page=all ] Antonio Gallardo reassigned COCOON-1962: Assignee: Antonio Gallardo Suggestion List initialization improvement -- Key: COCOON-1962 URL: http://issues.apache.org/jira/browse/COCOON-1962 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms Affects Versions: 2.1.10-dev (current SVN) Reporter: carlos chávez Assigned To: Antonio Gallardo Attachments: CFormsSuggest.txt, CFormsSuggestSample.txt Hello, If we have a list with a numeric value and a suggested string text, when the form load at the first time is showing the numeric value instead the corresponding text. This patch improve the suggestion list to retrieve the corresponding suggested text from the server when we have the numeric value when we load the form. -- 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-1894) Added support for the SQL:XML tag in SQLTransformer
[ http://issues.apache.org/jira/browse/COCOON-1894?page=comments#action_12442617 ] Antonio Gallardo commented on COCOON-1894: -- Sure. Added support for the SQL:XML tag in SQLTransformer --- Key: COCOON-1894 URL: http://issues.apache.org/jira/browse/COCOON-1894 Project: Cocoon Issue Type: Improvement Components: Blocks: Databases Affects Versions: 2.2-dev (Current SVN) Reporter: Geurt Wisselink Assigned To: Antonio Gallardo Attachments: SQLTransformer.java, SQLTransformer.java, SQLTransformer.java.patch, SQLTransformer.java.patch It adds support for the SQL:XML tag, this makes it possible to write XML inside a SQL database. -- 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-1825) [PATCH] Ajax error when an active state widget become invisible state widget
[ http://issues.apache.org/jira/browse/COCOON-1825?page=all ]
Antonio Gallardo updated COCOON-1825:
-
Would you provide a full patch? The latest looks like a partial patch without
the initial patch.
[PATCH] Ajax error when an active state widget become invisible state widget
Key: COCOON-1825
URL: http://issues.apache.org/jira/browse/COCOON-1825
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.1.9
Reporter: vincent Demay
Assigned To: Antonio Gallardo
Some widget (field with selection-list and styling=radio, group, etc...) can
not be hidden (state=invisible)in ajax mode.
I declare some widgets without state attribute in the form definition, my
form is in ajax mode, when I set the widget state to INVISIBLE, the ajax
response can not be applied to the form because span
id=widget-name.../span is not available in source code.
I think about 2 patches :
*putting a span/span in forms-field-styling.xsl where is not set
*or modifing abstractWidgetDefinition.java in ordre to generate a placeholder
around each widget (but patch seems to need a lot of modification in
forms-field-styling.xsl too)
Here is the patch for first
--- forms-field-styling.orig 2006-04-13 15:37:06.590221200 +0200
+++ forms-field-styling.xsl 2006-04-13 15:38:22.525291200 +0200
@@ -198,8 +198,9 @@
xsl:variable name=value select=fi:value/
xsl:variable name=vertical
select=string(fi:styling/@list-orientation) != 'horizontal'/
xsl:choose
- xsl:when test=$vertical
-table id={$id} cellpadding=0 cellspacing=0 border=0
title={fi:hint}
+ xsl:when test=$vertical
+ span id={$id}
+ table id={$id} cellpadding=0 cellspacing=0 border=0
title={fi:hint}
xsl:for-each select=fi:selection-list/fi:item
xsl:variable name=item-id select=concat($id, ':',
position())/
tr
@@ -224,6 +225,7 @@
/tr
/xsl:for-each
/table
+/span
/xsl:when
xsl:otherwise
span id={$id} title={fi:hint}
@@ -682,22 +684,24 @@
| know where to insert the widget if it becomes visible
+--
xsl:template match=fi:placeholder
-span id=[EMAIL PROTECTED]/
+span id=[EMAIL PROTECTED]xsl:apply-templates//span
/xsl:template
!--+
| fi:struct - has no visual representation by default
+--
xsl:template match=fi:struct
-xsl:apply-templates/
+ span id=[EMAIL PROTECTED]xsl:apply-templates//span
/xsl:template
!--+
| fi:group - has no visual representation by default
+--
xsl:template match=fi:group
-xsl:apply-templates/
+span id=[EMAIL PROTECTED]xsl:apply-templates//span
/xsl:template
+
+
xsl:template match=@*|node() priority=-1
xsl:copy
Here for the second
--- AbstractWidget.orig 2006-04-13 15:31:07.851701200 +0200
+++ AbstractWidget.java 2006-04-13 15:30:31.446616200 +0200
@@ -483,6 +483,10 @@
public void generateSaxFragment(ContentHandler contentHandler, Locale
locale)
throws SAXException {
+ AttributesImpl placeHolderAttrs = new AttributesImpl();
+ placeHolderAttrs.addCDATAAttribute(id, getRequestParameterName());
+contentHandler.startElement(FormsConstants.INSTANCE_NS,
placeholder, FormsConstants.INSTANCE_PREFIX_COLON + placeholder,
placeHolderAttrs);
+
if (getCombinedState().isDisplayingValues()) {
// FIXME: we may want to strip out completely widgets that
aren't updated when in AJAX mode
String element = this.getXMLElementName();
@@ -497,15 +501,9 @@
generateItemSaxFragment(contentHandler, locale);
-contentHandler.endElement(FormsConstants.INSTANCE_NS, element,
FormsConstants.INSTANCE_PREFIX_COLON + element);
-
-} else {
-// Generate a placeholder that can be used later by AJAX updates
-AttributesImpl attrs = new AttributesImpl();
-attrs.addCDATAAttribute(id, getRequestParameterName());
-contentHandler.startElement(FormsConstants.INSTANCE_NS,
placeholder, FormsConstants.INSTANCE_PREFIX_COLON + placeholder, attrs);
-contentHandler.endElement(FormsConstants.INSTANCE_NS,
placeholder, FormsConstants.INSTANCE_PREFIX_COLON + placeholder);
+contentHandler.endElement(FormsConstants.INSTANCE_NS, element,
FormsConstants.INSTANCE_PREFIX_COLON + element);
}
+contentHandler.endElement(FormsConstants.INSTANCE_NS, placeholder,
FormsConstants.INSTANCE_PREFIX_COLON + placeholder);
}
public Object getAttribute(String name) {
--
This message is automatically generated
[jira] Commented: (COCOON-1931) Provide more information when compiling a Flowscript fails
[ http://issues.apache.org/jira/browse/COCOON-1931?page=comments#action_12442465 ] Antonio Gallardo commented on COCOON-1931: -- Would you test the 2.1.10 branch on subversion. I think it was fixed just few days ago. I tried to reproduce the issue using the calculator flow sample: http://cocoon.zones.apache.org/demos/21branch/samples/flow/ Here is what I did: 1. When I removed the file, I got: java.io.FileNotFoundException: /home/agallardo/svn/cocoon-2.1/build/webapp/samples/flow/jxcalc/calc.js (No such file or directory) 2. When I remove a closing ) for a funtion call I got: Missing ) etc. Would you try the newest version and try to provide an NPE? If you are not able, please let us know to close this issue. Many thanks in advance. Provide more information when compiling a Flowscript fails -- Key: COCOON-1931 URL: http://issues.apache.org/jira/browse/COCOON-1931 Project: Cocoon Issue Type: Improvement Components: - Flowscript Affects Versions: 2.1.8, 2.1.9, 2.2-dev (Current SVN), 2.1.10-dev (current SVN) Reporter: Georg Hüttenegger Priority: Minor Attachments: FOM_JavaScriptInterpreter.java.MoreErrorInfoPatch When a flowscript defined in the sitemap cannot be loaded a NullPointerException is thrown without telling the developer the real cause of the issue. The same is true for certain Javascript coding errors (at least missing closing bracket of a for loop). The provided patch throws a CascadingRuntimeException with the name of the flowscript instead of just a simple NullPointerException. In that way the developer is lead directly to the cause of the problem instead of wondering what the real issue might be. -- 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-1894) Added support for the SQL:XML tag in SQLTransformer
[ http://issues.apache.org/jira/browse/COCOON-1894?page=all ] Antonio Gallardo updated COCOON-1894: - Hi, Thanks for the feedbak. I had plans to apply the patch today. I have 2 questions: 1. The previous patch (4 kB) is still valid for cocoon 2.1? 2. Related to the most recent attachment, it is for cocoon 2.2? Would you provide a patch? BTW, My name is Antonio, not Antonia. :-) Added support for the SQL:XML tag in SQLTransformer --- Key: COCOON-1894 URL: http://issues.apache.org/jira/browse/COCOON-1894 Project: Cocoon Issue Type: Improvement Components: Blocks: Databases Affects Versions: 2.2-dev (Current SVN) Reporter: Geurt Wisselink Assigned To: Antonio Gallardo Attachments: SQLTransformer.java, SQLTransformer.java, SQLTransformer.java.patch It adds support for the SQL:XML tag, this makes it possible to write XML inside a SQL database. -- 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-1825) [PATCH] Ajax error when an active state widget become invisible state widget
[
http://issues.apache.org/jira/browse/COCOON-1825?page=comments#action_12442322
]
Antonio Gallardo commented on COCOON-1825:
--
I asked about the duplicated id just to be sure, but I believe it is a typo.
I agree it is better to use div instead of span.
Sure feel free to send a patch. I will be glad to apply it. :-)
[PATCH] Ajax error when an active state widget become invisible state widget
Key: COCOON-1825
URL: http://issues.apache.org/jira/browse/COCOON-1825
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.1.9
Reporter: vincent Demay
Assigned To: Antonio Gallardo
Some widget (field with selection-list and styling=radio, group, etc...) can
not be hidden (state=invisible)in ajax mode.
I declare some widgets without state attribute in the form definition, my
form is in ajax mode, when I set the widget state to INVISIBLE, the ajax
response can not be applied to the form because span
id=widget-name.../span is not available in source code.
I think about 2 patches :
*putting a span/span in forms-field-styling.xsl where is not set
*or modifing abstractWidgetDefinition.java in ordre to generate a placeholder
around each widget (but patch seems to need a lot of modification in
forms-field-styling.xsl too)
Here is the patch for first
--- forms-field-styling.orig 2006-04-13 15:37:06.590221200 +0200
+++ forms-field-styling.xsl 2006-04-13 15:38:22.525291200 +0200
@@ -198,8 +198,9 @@
xsl:variable name=value select=fi:value/
xsl:variable name=vertical
select=string(fi:styling/@list-orientation) != 'horizontal'/
xsl:choose
- xsl:when test=$vertical
-table id={$id} cellpadding=0 cellspacing=0 border=0
title={fi:hint}
+ xsl:when test=$vertical
+ span id={$id}
+ table id={$id} cellpadding=0 cellspacing=0 border=0
title={fi:hint}
xsl:for-each select=fi:selection-list/fi:item
xsl:variable name=item-id select=concat($id, ':',
position())/
tr
@@ -224,6 +225,7 @@
/tr
/xsl:for-each
/table
+/span
/xsl:when
xsl:otherwise
span id={$id} title={fi:hint}
@@ -682,22 +684,24 @@
| know where to insert the widget if it becomes visible
+--
xsl:template match=fi:placeholder
-span id=[EMAIL PROTECTED]/
+span id=[EMAIL PROTECTED]xsl:apply-templates//span
/xsl:template
!--+
| fi:struct - has no visual representation by default
+--
xsl:template match=fi:struct
-xsl:apply-templates/
+ span id=[EMAIL PROTECTED]xsl:apply-templates//span
/xsl:template
!--+
| fi:group - has no visual representation by default
+--
xsl:template match=fi:group
-xsl:apply-templates/
+span id=[EMAIL PROTECTED]xsl:apply-templates//span
/xsl:template
+
+
xsl:template match=@*|node() priority=-1
xsl:copy
Here for the second
--- AbstractWidget.orig 2006-04-13 15:31:07.851701200 +0200
+++ AbstractWidget.java 2006-04-13 15:30:31.446616200 +0200
@@ -483,6 +483,10 @@
public void generateSaxFragment(ContentHandler contentHandler, Locale
locale)
throws SAXException {
+ AttributesImpl placeHolderAttrs = new AttributesImpl();
+ placeHolderAttrs.addCDATAAttribute(id, getRequestParameterName());
+contentHandler.startElement(FormsConstants.INSTANCE_NS,
placeholder, FormsConstants.INSTANCE_PREFIX_COLON + placeholder,
placeHolderAttrs);
+
if (getCombinedState().isDisplayingValues()) {
// FIXME: we may want to strip out completely widgets that
aren't updated when in AJAX mode
String element = this.getXMLElementName();
@@ -497,15 +501,9 @@
generateItemSaxFragment(contentHandler, locale);
-contentHandler.endElement(FormsConstants.INSTANCE_NS, element,
FormsConstants.INSTANCE_PREFIX_COLON + element);
-
-} else {
-// Generate a placeholder that can be used later by AJAX updates
-AttributesImpl attrs = new AttributesImpl();
-attrs.addCDATAAttribute(id, getRequestParameterName());
-contentHandler.startElement(FormsConstants.INSTANCE_NS,
placeholder, FormsConstants.INSTANCE_PREFIX_COLON + placeholder, attrs);
-contentHandler.endElement(FormsConstants.INSTANCE_NS,
placeholder, FormsConstants.INSTANCE_PREFIX_COLON + placeholder);
+contentHandler.endElement(FormsConstants.INSTANCE_NS, element,
FormsConstants.INSTANCE_PREFIX_COLON + element);
}
+contentHandler.endElement(FormsConstants.INSTANCE_NS, placeholder,
[jira] Commented: (COCOON-1894) Added support for the SQL:XML tag in SQLTransformer
[ http://issues.apache.org/jira/browse/COCOON-1894?page=comments#action_12442338 ] Antonio Gallardo commented on COCOON-1894: -- If it is the same code, 1 patch is enough. :) Added support for the SQL:XML tag in SQLTransformer --- Key: COCOON-1894 URL: http://issues.apache.org/jira/browse/COCOON-1894 Project: Cocoon Issue Type: Improvement Components: Blocks: Databases Affects Versions: 2.2-dev (Current SVN) Reporter: Geurt Wisselink Assigned To: Antonio Gallardo Attachments: SQLTransformer.java, SQLTransformer.java, SQLTransformer.java.patch It adds support for the SQL:XML tag, this makes it possible to write XML inside a SQL database. -- 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-1894) Added support for the SQL;XML tag in SQLTransformer
[ http://issues.apache.org/jira/browse/COCOON-1894?page=all ] Antonio Gallardo reassigned COCOON-1894: Assignee: Antonio Gallardo Added support for the SQL;XML tag in SQLTransformer --- Key: COCOON-1894 URL: http://issues.apache.org/jira/browse/COCOON-1894 Project: Cocoon Issue Type: Improvement Components: Blocks: Databases Affects Versions: 2.2-dev (Current SVN) Reporter: Geurt Wisselink Assigned To: Antonio Gallardo Attachments: SQLTransformer.java, SQLTransformer.java.patch It adds support for the SQL:XML tag, this makes it possible to write XML inside a SQL database. -- 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-1894) Added support for the SQL:XML tag in SQLTransformer
[ http://issues.apache.org/jira/browse/COCOON-1894?page=all ] Antonio Gallardo updated COCOON-1894: - Summary: Added support for the SQL:XML tag in SQLTransformer (was: Added support for the SQL;XML tag in SQLTransformer) Fix a typo on the summary. Added support for the SQL:XML tag in SQLTransformer --- Key: COCOON-1894 URL: http://issues.apache.org/jira/browse/COCOON-1894 Project: Cocoon Issue Type: Improvement Components: Blocks: Databases Affects Versions: 2.2-dev (Current SVN) Reporter: Geurt Wisselink Assigned To: Antonio Gallardo Attachments: SQLTransformer.java, SQLTransformer.java.patch It adds support for the SQL:XML tag, this makes it possible to write XML inside a SQL database. -- 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-1894) Added support for the SQL:XML tag in SQLTransformer
[ http://issues.apache.org/jira/browse/COCOON-1894?page=all ] Antonio Gallardo updated COCOON-1894: - Thanks for the patch. Added support for the SQL:XML tag in SQLTransformer --- Key: COCOON-1894 URL: http://issues.apache.org/jira/browse/COCOON-1894 Project: Cocoon Issue Type: Improvement Components: Blocks: Databases Affects Versions: 2.2-dev (Current SVN) Reporter: Geurt Wisselink Assigned To: Antonio Gallardo Attachments: SQLTransformer.java, SQLTransformer.java.patch It adds support for the SQL:XML tag, this makes it possible to write XML inside a SQL database. -- 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-1825) Ajax errror when an active state widget become invisible state widget
[
http://issues.apache.org/jira/browse/COCOON-1825?page=comments#action_12442267
]
Antonio Gallardo commented on COCOON-1825:
--
IN the first part of the patch, there is:
+ span id={$id}
+ table id={$id} cellpadding=0 cellspacing=0 border=0
title={fi:hint}
I don't think it is a good idea to have the same id in 2 different elements. It
seems like it might blow somewhere else.
how we can fix this?
Ajax errror when an active state widget become invisible state widget
-
Key: COCOON-1825
URL: http://issues.apache.org/jira/browse/COCOON-1825
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.1.9
Reporter: vincent Demay
Assigned To: Antonio Gallardo
Some widget (field with selection-list and styling=radio, group, etc...) can
not be hidden (state=invisible)in ajax mode.
I declare some widgets without state attribute in the form definition, my
form is in ajax mode, when I set the widget state to INVISIBLE, the ajax
response can not be applied to the form because span
id=widget-name.../span is not available in source code.
I think about 2 patches :
*putting a span/span in forms-field-styling.xsl where is not set
*or modifing abstractWidgetDefinition.java in ordre to generate a placeholder
around each widget (but patch seems to need a lot of modification in
forms-field-styling.xsl too)
Here is the patch for first
--- forms-field-styling.orig 2006-04-13 15:37:06.590221200 +0200
+++ forms-field-styling.xsl 2006-04-13 15:38:22.525291200 +0200
@@ -198,8 +198,9 @@
xsl:variable name=value select=fi:value/
xsl:variable name=vertical
select=string(fi:styling/@list-orientation) != 'horizontal'/
xsl:choose
- xsl:when test=$vertical
-table id={$id} cellpadding=0 cellspacing=0 border=0
title={fi:hint}
+ xsl:when test=$vertical
+ span id={$id}
+ table id={$id} cellpadding=0 cellspacing=0 border=0
title={fi:hint}
xsl:for-each select=fi:selection-list/fi:item
xsl:variable name=item-id select=concat($id, ':',
position())/
tr
@@ -224,6 +225,7 @@
/tr
/xsl:for-each
/table
+/span
/xsl:when
xsl:otherwise
span id={$id} title={fi:hint}
@@ -682,22 +684,24 @@
| know where to insert the widget if it becomes visible
+--
xsl:template match=fi:placeholder
-span id=[EMAIL PROTECTED]/
+span id=[EMAIL PROTECTED]xsl:apply-templates//span
/xsl:template
!--+
| fi:struct - has no visual representation by default
+--
xsl:template match=fi:struct
-xsl:apply-templates/
+ span id=[EMAIL PROTECTED]xsl:apply-templates//span
/xsl:template
!--+
| fi:group - has no visual representation by default
+--
xsl:template match=fi:group
-xsl:apply-templates/
+span id=[EMAIL PROTECTED]xsl:apply-templates//span
/xsl:template
+
+
xsl:template match=@*|node() priority=-1
xsl:copy
Here for the second
--- AbstractWidget.orig 2006-04-13 15:31:07.851701200 +0200
+++ AbstractWidget.java 2006-04-13 15:30:31.446616200 +0200
@@ -483,6 +483,10 @@
public void generateSaxFragment(ContentHandler contentHandler, Locale
locale)
throws SAXException {
+ AttributesImpl placeHolderAttrs = new AttributesImpl();
+ placeHolderAttrs.addCDATAAttribute(id, getRequestParameterName());
+contentHandler.startElement(FormsConstants.INSTANCE_NS,
placeholder, FormsConstants.INSTANCE_PREFIX_COLON + placeholder,
placeHolderAttrs);
+
if (getCombinedState().isDisplayingValues()) {
// FIXME: we may want to strip out completely widgets that
aren't updated when in AJAX mode
String element = this.getXMLElementName();
@@ -497,15 +501,9 @@
generateItemSaxFragment(contentHandler, locale);
-contentHandler.endElement(FormsConstants.INSTANCE_NS, element,
FormsConstants.INSTANCE_PREFIX_COLON + element);
-
-} else {
-// Generate a placeholder that can be used later by AJAX updates
-AttributesImpl attrs = new AttributesImpl();
-attrs.addCDATAAttribute(id, getRequestParameterName());
-contentHandler.startElement(FormsConstants.INSTANCE_NS,
placeholder, FormsConstants.INSTANCE_PREFIX_COLON + placeholder, attrs);
-contentHandler.endElement(FormsConstants.INSTANCE_NS,
placeholder, FormsConstants.INSTANCE_PREFIX_COLON + placeholder);
+contentHandler.endElement(FormsConstants.INSTANCE_NS, element,
FormsConstants.INSTANCE_PREFIX_COLON + element);
}
+
[jira] Reopened: (COCOON-1682) Custom headers for Sendmail Action/Logicsheet/Transformer needed
[ http://issues.apache.org/jira/browse/COCOON-1682?page=all ] Antonio Gallardo reopened COCOON-1682: -- Assignee: Cocoon Developers Team It is a user wish. We should not close it. Custom headers for Sendmail Action/Logicsheet/Transformer needed Key: COCOON-1682 URL: http://issues.apache.org/jira/browse/COCOON-1682 Project: Cocoon Issue Type: Wish Components: Blocks: Mail Affects Versions: 2.1.7 Reporter: Lauri Pitkänen Assigned To: Cocoon Developers Team Priority: Minor Possibility to add multiple custom headers to messages from Sendmail Action/Logicsheet/Transformer would eliminate the need for adding missing fixed optional headers like ReplyTo one by one. This is something that is already available in the AxKit XSP tag library:: http://search.cpan.org/~kjetilk/AxKit-XSP-Sendmail/Sendmail.pm#%3Csendmail:header%3E Configuration example: sendmail:header name=Precedencebulk/sendmail:header sendmail:header name=X-My-HeaderSomething/sendmail:header Headers in the message: Precedence: bulk X-My-Header: Something -- 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-1692) [PATCH] Tree widget not handling on-selection-change events correctly.
[ http://issues.apache.org/jira/browse/COCOON-1692?page=all ] Antonio Gallardo closed COCOON-1692. Fix Version/s: 2.1.10-dev (current SVN) Resolution: Fixed Thanks for the patch. It was applied, feel free to reopen if needed. [PATCH] Tree widget not handling on-selection-change events correctly. -- Key: COCOON-1692 URL: http://issues.apache.org/jira/browse/COCOON-1692 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.9, 2.1.8 Reporter: Suzan Foster Assigned To: Antonio Gallardo Fix For: 2.1.10-dev (current SVN) Attachments: Tree.java.patch In the current implementation field widgets that have their value changed from an on-selection-changed handler do not propagate these changes to the client. The patch, applied to current SVN, resolves this issue. -- 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-1928) Add the ability to pass the doctype in parameter for Serializer
[ http://issues.apache.org/jira/browse/COCOON-1928?page=all ] Antonio Gallardo updated COCOON-1928: - Would you provide an use case? I am asking because I wonder why this is needed. 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] Updated: (COCOON-1606) [BUG+PATCH] FormattingDecimalConvertor.java does not parse in BigDecimal mode
[ http://issues.apache.org/jira/browse/COCOON-1606?page=all ] Antonio Gallardo updated COCOON-1606: - Unfortunately, the cforms code should be compatible with java 1.3, the method decimalFormat.setParseBigDecimal(true) was introduced in java .1.5. Do you have another idea to fix this issue? [BUG+PATCH] FormattingDecimalConvertor.java does not parse in BigDecimal mode - Key: COCOON-1606 URL: http://issues.apache.org/jira/browse/COCOON-1606 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.8 Environment: Operating System: other Platform: All Reporter: Thomas Lutz Assigned To: Cocoon Developers Team Attachments: FormattingDecimalConvertor.java.tar.gz This patch enables BigDecimal parsing in FormattingDecimalConvertor. Basically if you have a widget with datatype decimal and enter a very large number, something like 1919191 and submit the form you'll get someting like a rounded value in technical notation. same thing with datatype long, to be seen in the samples at http://cocoon.zones.apache.org/demos/release/samples/blocks/forms/form1 click NumberFields to change tab and enter 1919191 into Enter another number, larger than the other number: submit, then you get as value for the same field: 9,223,372,036,854,775,807 which is quite the same, though its no BigDecimal problem. at least some kind of validation error should occur... but a webapp changing user submitted values without a hint is a rather hot thing :-). -- 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-1867) BeanConvertor uses a WeakHashMap in the wrong way.
[ http://issues.apache.org/jira/browse/COCOON-1867?page=all ] Antonio Gallardo reassigned COCOON-1867: Assignee: Antonio Gallardo (was: Simone Gianni) BeanConvertor uses a WeakHashMap in the wrong way. -- Key: COCOON-1867 URL: http://issues.apache.org/jira/browse/COCOON-1867 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.9, 2.1.10-dev (current SVN) Reporter: Simone Gianni Assigned To: Antonio Gallardo Priority: Critical Attachments: BeanConvertor-1867.diff In the BeanConvertor, when a bean is converted to a string, the bean is stored in a WeakHashMap this way : m_objects.put(idValue, value); Actually idValue is a string representing the bean (toString or evalued on id_path) while the value is the bean. WeakHashMap DOES NOT remove a mapping when the bean is garbage collected, but actually removes it when the KEY is garbage collected. This means that since the string is serialized to XML in the form instance and then dropped, the mapping could be removed even while the user is filling the form, with the conseguence that the convertor stops working, see a null value, reports a validation error, even if the user correctly filled the form. This is even worse when you are using a selection list of beans, because in that case the bean has no chanches to enter the m_objects map anymore, since the selection list has been generated and stored st the beginning of the form (maybe thru flow, or on-create) and is not asking the convertor to convert the beans anymore. A better solution (and IMMO what the author intended to do) is to remove the mapping (so that the map does not hold references for everything) when the BEAN gets garbage collected. In this case I'm experimenting with apache commons ReferenceMap, which actually can remove mappings when the value (bean) is garbage collected. -- 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-1867) BeanConvertor uses a WeakHashMap in the wrong way.
[ http://issues.apache.org/jira/browse/COCOON-1867?page=all ] Antonio Gallardo closed COCOON-1867. Fix Version/s: 2.1.10-dev (current SVN) Resolution: Fixed Thanks for the patch. Feel free to reopen the issue if needed. BeanConvertor uses a WeakHashMap in the wrong way. -- Key: COCOON-1867 URL: http://issues.apache.org/jira/browse/COCOON-1867 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.9, 2.1.10-dev (current SVN) Reporter: Simone Gianni Assigned To: Antonio Gallardo Priority: Critical Fix For: 2.1.10-dev (current SVN) Attachments: BeanConvertor-1867.diff In the BeanConvertor, when a bean is converted to a string, the bean is stored in a WeakHashMap this way : m_objects.put(idValue, value); Actually idValue is a string representing the bean (toString or evalued on id_path) while the value is the bean. WeakHashMap DOES NOT remove a mapping when the bean is garbage collected, but actually removes it when the KEY is garbage collected. This means that since the string is serialized to XML in the form instance and then dropped, the mapping could be removed even while the user is filling the form, with the conseguence that the convertor stops working, see a null value, reports a validation error, even if the user correctly filled the form. This is even worse when you are using a selection list of beans, because in that case the bean has no chanches to enter the m_objects map anymore, since the selection list has been generated and stored st the beginning of the form (maybe thru flow, or on-create) and is not asking the convertor to convert the beans anymore. A better solution (and IMMO what the author intended to do) is to remove the mapping (so that the map does not hold references for everything) when the BEAN gets garbage collected. In this case I'm experimenting with apache commons ReferenceMap, which actually can remove mappings when the value (bean) is garbage collected. -- 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-1714) repeater min-size does not prevent removal of rows below minium size
[ http://issues.apache.org/jira/browse/COCOON-1714?page=all ] Antonio Gallardo reopened COCOON-1714: -- I am reopening, because. This is an issue that should work as advertised on our docs. repeater min-size does not prevent removal of rows below minium size Key: COCOON-1714 URL: http://issues.apache.org/jira/browse/COCOON-1714 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN) Reporter: Eric Meyer repeater min-size does not prevent removal of rows below minium size e.g. fd:repeater id=industryStructure initial-size=1 min-size=1 I can remove all the rows and submit. Shouldn't min-size keep it from ever having fewer than those rows, or does this only cause a validation error. If the latter, then how is this error displayed? Regards, Eric -- 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-1692) [PATCH] Tree widget not handling on-selection-change events correctly.
[ http://issues.apache.org/jira/browse/COCOON-1692?page=all ]
Antonio Gallardo updated COCOON-1692:
-
In the privided patch, I guess there is a typo in:
@@ -259,9 +260,8 @@
if (this.expandSelectedPath) {
expandPath(path);
}
-if (this.selectionListener != null) {
-this.selectionListener.selectionChanged(new
TreeSelectionEvent(this, path, true));
-}
+
+this.getForm().addWidgetEvent(new TreeSelectionEvent(this, path,
false));
}
}
I suspect it should be:
+this.getForm().addWidgetEvent(new TreeSelectionEvent(this, path,
true));
(I just changed te last paramter to true).
Would you confirm if this is correct?
[PATCH] Tree widget not handling on-selection-change events correctly.
--
Key: COCOON-1692
URL: http://issues.apache.org/jira/browse/COCOON-1692
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.1.9, 2.1.8
Reporter: Suzan Foster
Assigned To: Antonio Gallardo
Attachments: Tree.java.patch
In the current implementation field widgets that have their value changed
from an on-selection-changed handler do not propagate these changes to the
client. The patch, applied to current SVN, resolves this issue.
--
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-1692) [PATCH] Tree widget not handling on-selection-change events correctly.
[ http://issues.apache.org/jira/browse/COCOON-1692?page=all ] Antonio Gallardo reassigned COCOON-1692: Assignee: Antonio Gallardo [PATCH] Tree widget not handling on-selection-change events correctly. -- Key: COCOON-1692 URL: http://issues.apache.org/jira/browse/COCOON-1692 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.9, 2.1.8 Reporter: Suzan Foster Assigned To: Antonio Gallardo Attachments: Tree.java.patch In the current implementation field widgets that have their value changed from an on-selection-changed handler do not propagate these changes to the client. The patch, applied to current SVN, resolves this issue. -- 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-1897) i18n transformer: catch date parsing exceptions silently
[ http://issues.apache.org/jira/browse/COCOON-1897?page=all ] Antonio Gallardo updated COCOON-1897: - Would you provide a use case where is important to hide the exception? i18n transformer: catch date parsing exceptions silently Key: COCOON-1897 URL: http://issues.apache.org/jira/browse/COCOON-1897 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.1.8, 2.1.9, 2.1.10-dev (current SVN) Reporter: DennisDam Attachments: I18nTransformer.java.patch When an empty/incorrect date value is specified, the i18n transformer throws an exception, breaking the whole page. This exception needs to be caught and handled silently. The patch logs a warning message and returns an empty result when date parsing fails. -- 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-1894) Added support for the SQL;XML tag in SQLTransformer
[ http://issues.apache.org/jira/browse/COCOON-1894?page=all ] Antonio Gallardo updated COCOON-1894: - Would you provide a diff of the file? Added support for the SQL;XML tag in SQLTransformer --- Key: COCOON-1894 URL: http://issues.apache.org/jira/browse/COCOON-1894 Project: Cocoon Issue Type: Improvement Components: Blocks: Databases Affects Versions: 2.2-dev (Current SVN) Reporter: Geurt Wisselink Attachments: SQLTransformer.java It adds support for the SQL:XML tag, this makes it possible to write XML inside a SQL database. -- 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-1815) CopySourceAction generate NPE
[ http://issues.apache.org/jira/browse/COCOON-1815?page=all ]
Antonio Gallardo closed COCOON-1815.
Resolution: Fixed
Thanks for raising the issue. Patch applied. Please feel free to reopen agai if
needed.
CopySourceAction generate NPE
-
Key: COCOON-1815
URL: http://issues.apache.org/jira/browse/COCOON-1815
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Affects Versions: 2.1.8
Reporter: Frédéric Glorieux
Assigned To: Antonio Gallardo
Priority: Minor
Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN)
http://www.mail-archive.com/users-fr@cocoon.apache.org/msg01586.html
In some circumstances, with internal sources (cocoon:/),
org/apache/cocoon/acting/copySource.java
http://svn.apache.org/viewcvs.cgi/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/acting/CopySourceAction.java?rev=30932view=markup
copy-source action generate NPE in Console (nothing seems broken)
Source objects needs to be released
Code may be shorter with usage of excalibur SourceUtil to copy sources
try {
org.apache.excalibur.source.SourceUtil.SourceUtil.copy(src, dest);
} finally {
resolver.release(src);
resolver.release(dest);
}
--
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-1858) [PATCH]on-value-change does not work on suggestion list
[
http://issues.apache.org/jira/browse/COCOON-1858?page=comments#action_12427257
]
Antonio Gallardo commented on COCOON-1858:
--
Sure. The styling part is a separated issue. Even without patch is improve the
code.
[PATCH]on-value-change does not work on suggestion list
---
Key: COCOON-1858
URL: http://issues.apache.org/jira/browse/COCOON-1858
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.1.9
Reporter: vincent Demay
Attachments: ComboBox.js, ComboBox.js
on-value-change does not work on suggestion list : there are to issues :
1 - submit on change is not setted on the widget in
form-advanced-field-styling.xsl :
Here is the patch :
--- sample/forms-advanced-field-styling.xsl 2006-06-07 14:51:27.809216500
+0
200
+++ sample/forms-advanced-field-styling.new.xsl 2006-06-07 14:52:04.293358000
+0
200
@@ -272,6 +272,7 @@
xsl:template match=fi:field[fi:styling/@type='suggest' and
@state='active']
span id=[EMAIL PROTECTED]
input name=[EMAIL PROTECTED] id=[EMAIL PROTECTED]:input
value={fi:value} dojoType=CFormsSuggest
+xsl:apply-templates select=. mode=styling/
xsl:if test=fi:suggestion
xsl:attribute name=suggestionxsl:value-of
select=fi:suggestion//xsl:attribute
/xsl:if
2 - dojo Widget does not support onchange (see bug :
http://trac.dojotoolkit.org/ticket/897)
So I change the dojo file src/widget/html/ComboBox.js
The new file is in Attachement (and patch in dojo tracker)
--
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-1758) Form locale never used in JXMacros
[
http://issues.apache.org/jira/browse/COCOON-1758?page=comments#action_12427267
]
Antonio Gallardo commented on COCOON-1758:
--
Thanks for the feedback Simone. You are fully right. I reviewed the Carlos
patch against the repository and is not the same. I recall I did some tests
before committing to checking if this is working as expected. After testing,
for some reason I forgot to revert my test changes. In short:
I bad commit was:
cocoon.parameters.getParameter('locale')
and patch reads:
cocoon.parameters.getParameter('locale','')
(please note the empty string as default value.
I am going to commit the fix to the fix, right now. :-)
Thanks again for spotting the issue.
Form locale never used in JXMacros
--
Key: COCOON-1758
URL: http://issues.apache.org/jira/browse/COCOON-1758
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9
Reporter: Philippe Gassmann
Assigned To: Antonio Gallardo
Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN)
Attachments: 20060201-cocoon-forms-1758, patch.txt, patch1.txt
The JXMacroHelper is created with : jx:set var=cformsHelper
value=#{org.apache.cocoon.forms.generation.JXMacrosHelper.createHelper($cocoon/consumer,$cocoon/request,$cocoon/parameters/locale)}/
So the locale is get from sitemap parameters.
the locale attribute of the form is then never used.
I will provide a patch as soon as possible
--
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-1758) Form locale never used in JXMacros
[
http://issues.apache.org/jira/browse/COCOON-1758?page=comments#action_12427268
]
Antonio Gallardo commented on COCOON-1758:
--
The fix is now on the repository. Please cross check if this works. Thanks
again for spotting the error.
Form locale never used in JXMacros
--
Key: COCOON-1758
URL: http://issues.apache.org/jira/browse/COCOON-1758
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9
Reporter: Philippe Gassmann
Assigned To: Antonio Gallardo
Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN)
Attachments: 20060201-cocoon-forms-1758, patch.txt, patch1.txt
The JXMacroHelper is created with : jx:set var=cformsHelper
value=#{org.apache.cocoon.forms.generation.JXMacrosHelper.createHelper($cocoon/consumer,$cocoon/request,$cocoon/parameters/locale)}/
So the locale is get from sitemap parameters.
the locale attribute of the form is then never used.
I will provide a patch as soon as possible
--
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-1858) [PATCH]on-value-change does not work on suggestion list
[
http://issues.apache.org/jira/browse/COCOON-1858?page=comments#action_12427413
]
Antonio Gallardo commented on COCOON-1858:
--
1st patch applied.
[PATCH]on-value-change does not work on suggestion list
---
Key: COCOON-1858
URL: http://issues.apache.org/jira/browse/COCOON-1858
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.1.9
Reporter: vincent Demay
Attachments: ComboBox.js, ComboBox.js
on-value-change does not work on suggestion list : there are to issues :
1 - submit on change is not setted on the widget in
form-advanced-field-styling.xsl :
Here is the patch :
--- sample/forms-advanced-field-styling.xsl 2006-06-07 14:51:27.809216500
+0
200
+++ sample/forms-advanced-field-styling.new.xsl 2006-06-07 14:52:04.293358000
+0
200
@@ -272,6 +272,7 @@
xsl:template match=fi:field[fi:styling/@type='suggest' and
@state='active']
span id=[EMAIL PROTECTED]
input name=[EMAIL PROTECTED] id=[EMAIL PROTECTED]:input
value={fi:value} dojoType=CFormsSuggest
+xsl:apply-templates select=. mode=styling/
xsl:if test=fi:suggestion
xsl:attribute name=suggestionxsl:value-of
select=fi:suggestion//xsl:attribute
/xsl:if
2 - dojo Widget does not support onchange (see bug :
http://trac.dojotoolkit.org/ticket/897)
So I change the dojo file src/widget/html/ComboBox.js
The new file is in Attachement (and patch in dojo tracker)
--
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-1732) Ajax and IE empty textarea bugfix
[ http://issues.apache.org/jira/browse/COCOON-1732?page=all ] Antonio Gallardo closed COCOON-1732. Fix Version/s: 2.2-dev (Current SVN) 2.1.10-dev (current SVN) Resolution: Fixed I am closing, because the patch is already on the repository. Feel free to reopen the issue if needed. Ajax and IE empty textarea bugfix - Key: COCOON-1732 URL: http://issues.apache.org/jira/browse/COCOON-1732 Project: Cocoon Issue Type: Bug Components: Blocks: Ajax Affects Versions: 2.1.8 Reporter: Fabrizio Sitzia Priority: Minor Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) Attachments: empty_textarea_ie.txt, ie_empty_textarea.gif, insertion.js.patch Empty textareas in a repeater are displayed incorrectly by Internet Explorer after a round-trip to the server (for example after adding/deleting a row, or when a validation error occurs!) Instead of being empty, the textareas display a garbled mix of text and html-tags occurring in the html document. Submission of the form usually won't work afterwards... (See attachment for my post to the cocoon dev list, which contains the steps for reproducing the bug, and a possible fix for it) -- 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-1849) debug logging left in AggregateFieldDefinitionBuilder.java
[ http://issues.apache.org/jira/browse/COCOON-1849?page=all ] Antonio Gallardo reassigned COCOON-1849: Assignee: Antonio Gallardo debug logging left in AggregateFieldDefinitionBuilder.java -- Key: COCOON-1849 URL: http://issues.apache.org/jira/browse/COCOON-1849 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9 Reporter: Mark Lundquist Assigned To: Antonio Gallardo Priority: Trivial This code in OAC/forms/formmodel/AggregateFieldDefinitionBuilder.java (line 81 in rev 326838): System.out.println(Aggregate: addSplitMapping(+group+,+field+)); should be removed. -- 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-1849) debug logging left in AggregateFieldDefinitionBuilder.java
[ http://issues.apache.org/jira/browse/COCOON-1849?page=all ] Antonio Gallardo closed COCOON-1849. Fix Version/s: 2.2-dev (Current SVN) 2.1.10-dev (current SVN) Resolution: Fixed Thanks for the patch. It was applied. Feel free to reopen the issue if needed. debug logging left in AggregateFieldDefinitionBuilder.java -- Key: COCOON-1849 URL: http://issues.apache.org/jira/browse/COCOON-1849 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.8, 2.1.9, 2.2-dev (Current SVN) Reporter: Mark Lundquist Assigned To: Antonio Gallardo Priority: Trivial Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) This code in OAC/forms/formmodel/AggregateFieldDefinitionBuilder.java (line 81 in rev 326838): System.out.println(Aggregate: addSplitMapping(+group+,+field+)); should be removed. -- 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-1815) CopySourceAction generate NPE
[ http://issues.apache.org/jira/browse/COCOON-1815?page=all ]
Antonio Gallardo reassigned COCOON-1815:
Assignee: Antonio Gallardo
CopySourceAction generate NPE
-
Key: COCOON-1815
URL: http://issues.apache.org/jira/browse/COCOON-1815
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Affects Versions: 2.1.8
Reporter: Frédéric Glorieux
Assigned To: Antonio Gallardo
Priority: Minor
http://www.mail-archive.com/users-fr@cocoon.apache.org/msg01586.html
In some circumstances, with internal sources (cocoon:/),
org/apache/cocoon/acting/copySource.java
http://svn.apache.org/viewcvs.cgi/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/acting/CopySourceAction.java?rev=30932view=markup
copy-source action generate NPE in Console (nothing seems broken)
Source objects needs to be released
Code may be shorter with usage of excalibur SourceUtil to copy sources
try {
org.apache.excalibur.source.SourceUtil.SourceUtil.copy(src, dest);
} finally {
resolver.release(src);
resolver.release(dest);
}
--
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-1815) CopySourceAction generate NPE
[ http://issues.apache.org/jira/browse/COCOON-1815?page=all ]
Antonio Gallardo closed COCOON-1815.
Fix Version/s: 2.2-dev (Current SVN)
2.1.10-dev (current SVN)
Resolution: Fixed
The patch was applied and no feedback. I assume the issue is fixed. Feel free
to reopen if needed.
CopySourceAction generate NPE
-
Key: COCOON-1815
URL: http://issues.apache.org/jira/browse/COCOON-1815
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Affects Versions: 2.1.8
Reporter: Frédéric Glorieux
Assigned To: Antonio Gallardo
Priority: Minor
Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN)
http://www.mail-archive.com/users-fr@cocoon.apache.org/msg01586.html
In some circumstances, with internal sources (cocoon:/),
org/apache/cocoon/acting/copySource.java
http://svn.apache.org/viewcvs.cgi/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/acting/CopySourceAction.java?rev=30932view=markup
copy-source action generate NPE in Console (nothing seems broken)
Source objects needs to be released
Code may be shorter with usage of excalibur SourceUtil to copy sources
try {
org.apache.excalibur.source.SourceUtil.SourceUtil.copy(src, dest);
} finally {
resolver.release(src);
resolver.release(dest);
}
--
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-1440) [poi] color string normalization
[ http://issues.apache.org/jira/browse/COCOON-1440?page=all ] Antonio Gallardo updated COCOON-1440: - Would you provide a patch? [poi] color string normalization Key: COCOON-1440 URL: http://issues.apache.org/jira/browse/COCOON-1440 Project: Cocoon Issue Type: Improvement Components: Blocks: POI Affects Versions: 2.1.6 Environment: Operating System: All Platform: PC Reporter: Krystian Nowak Assigned To: Cocoon Developers Team Priority: Minor In a constructor of ColorCode (org.apache.cocoon.components.elementprocessor.impl.poi.hssf.elements) there could be a normalization check to ensure that even if the color string is in form :: it will be normalized to org.apache.poi.hssf.util.HSSFColor's form which is :0:0. I've spend a lot on debugging to get what's going on... -- 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-1732) Ajax and IE empty textarea bugfix
[ http://issues.apache.org/jira/browse/COCOON-1732?page=all ] Antonio Gallardo updated COCOON-1732: - Thanks for the patch. However I found there was already applied a patch in the trunk: http://svn.apache.org/viewvc?view=revrevision=406636 Would you kindly review if the applied patch works for you? Ajax and IE empty textarea bugfix - Key: COCOON-1732 URL: http://issues.apache.org/jira/browse/COCOON-1732 Project: Cocoon Issue Type: Bug Components: Blocks: Ajax Affects Versions: 2.1.8 Reporter: Fabrizio Sitzia Priority: Minor Attachments: empty_textarea_ie.txt, ie_empty_textarea.gif, insertion.js.patch Empty textareas in a repeater are displayed incorrectly by Internet Explorer after a round-trip to the server (for example after adding/deleting a row, or when a validation error occurs!) Instead of being empty, the textareas display a garbled mix of text and html-tags occurring in the html document. Submission of the form usually won't work afterwards... (See attachment for my post to the cocoon dev list, which contains the steps for reproducing the bug, and a possible fix for it) -- 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-1735) Update Jtidy
[ http://issues.apache.org/jira/browse/COCOON-1735?page=comments#action_12426608 ] Antonio Gallardo commented on COCOON-1735: -- Thanks for the feedback Jean-Baptiste, hence we should not deprecate Jtidy, because we don't have a repleacement for it. Update Jtidy Key: COCOON-1735 URL: http://issues.apache.org/jira/browse/COCOON-1735 Project: Cocoon Issue Type: Bug Components: Blocks: HTML Affects Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9 Reporter: Jean-Baptiste Quenot Assigned To: Jean-Baptiste Quenot FYI we had to update jtidy in our project to see an HTML parsing bug fixed. We used this: http://jtidy.sourceforge.net/nightly/jtidy-r8-SNAPSHOT.zip This version was last updated in september 2004. -- 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-1889) [PATCH] Tiny typo in JavaScriptJXPathBinding
[ http://issues.apache.org/jira/browse/COCOON-1889?page=all ] Antonio Gallardo closed COCOON-1889. Fix Version/s: 2.2-dev (Current SVN) 2.1.10-dev (current SVN) Resolution: Fixed Thanks for the patch. Feel free to reopen the issue if needed. [PATCH] Tiny typo in JavaScriptJXPathBinding Key: COCOON-1889 URL: http://issues.apache.org/jira/browse/COCOON-1889 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN) Reporter: Jeroen Goubert Assigned To: Antonio Gallardo Priority: Trivial Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) Attachments: JavaScriptJXPathBinding.java.diff Small typo: 'avaliable' is used instead of 'available' in log messages. -- 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-1889) [PATCH] Tiny typo in JavaScriptJXPathBinding
[ http://issues.apache.org/jira/browse/COCOON-1889?page=all ] Antonio Gallardo reassigned COCOON-1889: Assignee: Antonio Gallardo [PATCH] Tiny typo in JavaScriptJXPathBinding Key: COCOON-1889 URL: http://issues.apache.org/jira/browse/COCOON-1889 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN) Reporter: Jeroen Goubert Assigned To: Antonio Gallardo Priority: Trivial Attachments: JavaScriptJXPathBinding.java.diff Small typo: 'avaliable' is used instead of 'available' in log messages. -- 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-1732) Ajax and IE empty textarea bugfix
[ http://issues.apache.org/jira/browse/COCOON-1732?page=all ] Antonio Gallardo updated COCOON-1732: - The ajax implementation shipped in cocoon 2.1.8 was dropped in favor of dojo [1] in cocon 2.1.9. Since there is no file called cocoon-ajax.jsin the trunk, we cannot apply the patch. :-( [1] http://dojotoolkit.org/ Ajax and IE empty textarea bugfix - Key: COCOON-1732 URL: http://issues.apache.org/jira/browse/COCOON-1732 Project: Cocoon Issue Type: Bug Components: Blocks: Ajax Affects Versions: 2.1.8 Reporter: Fabrizio Sitzia Priority: Minor Attachments: empty_textarea_ie.txt, ie_empty_textarea.gif Empty textareas in a repeater are displayed incorrectly by Internet Explorer after a round-trip to the server (for example after adding/deleting a row, or when a validation error occurs!) Instead of being empty, the textareas display a garbled mix of text and html-tags occurring in the html document. Submission of the form usually won't work afterwards... (See attachment for my post to the cocoon dev list, which contains the steps for reproducing the bug, and a possible fix for it) -- 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-1888) [PATCH] forms-samples-styling.xsl should place script elements from source document last in head
[ http://issues.apache.org/jira/browse/COCOON-1888?page=all ] Antonio Gallardo updated COCOON-1888: - It's not enough to change the code to: xsl:template match=head head xsl:apply-templates select=. mode=forms-page/ xsl:apply-templates select=. mode=forms-field/ xsl:apply-templates/ /head /xsl:template wdyt? [PATCH] forms-samples-styling.xsl should place script elements from source document last in head Key: COCOON-1888 URL: http://issues.apache.org/jira/browse/COCOON-1888 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9, 2.1.10-dev (current SVN) Reporter: Mark Lundquist Priority: Minor Attachments: COCOON-1888.patch The current forms-samples-styling.xsl head matching template passes through all the child elements of head in the source before appending its own from forms-page and forms-field. This breaks source documents that need to have script elements that depend on JS libs added by the Forms block, e.g. pushing handlers for onload or onsubmit. The script elements added by this stylesheet need to come before and script elements from the source document -- 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-1888) [PATCH] forms-samples-styling.xsl should place script elements from source document last in head
[ http://issues.apache.org/jira/browse/COCOON-1888?page=comments#action_12425097 ] Antonio Gallardo commented on COCOON-1888: -- Forgot to say: The above snippet is how it is implemented in current cforms trunk. [PATCH] forms-samples-styling.xsl should place script elements from source document last in head Key: COCOON-1888 URL: http://issues.apache.org/jira/browse/COCOON-1888 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9, 2.1.10-dev (current SVN) Reporter: Mark Lundquist Priority: Minor Attachments: COCOON-1888.patch The current forms-samples-styling.xsl head matching template passes through all the child elements of head in the source before appending its own from forms-page and forms-field. This breaks source documents that need to have script elements that depend on JS libs added by the Forms block, e.g. pushing handlers for onload or onsubmit. The script elements added by this stylesheet need to come before and script elements from the source document -- 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-1888) [PATCH] forms-samples-styling.xsl should place script elements from source document last in head
[ http://issues.apache.org/jira/browse/COCOON-1888?page=all ] Antonio Gallardo updated COCOON-1888: - Thanks in for reporting. If the fix in the repository is ok, you should close the bug. ;-) [PATCH] forms-samples-styling.xsl should place script elements from source document last in head Key: COCOON-1888 URL: http://issues.apache.org/jira/browse/COCOON-1888 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9, 2.1.10-dev (current SVN) Reporter: Mark Lundquist Priority: Minor Attachments: COCOON-1888.patch The current forms-samples-styling.xsl head matching template passes through all the child elements of head in the source before appending its own from forms-page and forms-field. This breaks source documents that need to have script elements that depend on JS libs added by the Forms block, e.g. pushing handlers for onload or onsubmit. The script elements added by this stylesheet need to come before and script elements from the source document -- 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-1758) Form locale never used in JXMacros
[ http://issues.apache.org/jira/browse/COCOON-1758?page=all ]
Antonio Gallardo reassigned COCOON-1758:
Assignee: Antonio Gallardo
Form locale never used in JXMacros
--
Key: COCOON-1758
URL: http://issues.apache.org/jira/browse/COCOON-1758
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9
Reporter: Philippe Gassmann
Assigned To: Antonio Gallardo
Attachments: 20060201-cocoon-forms-1758, patch.txt, patch1.txt
The JXMacroHelper is created with : jx:set var=cformsHelper
value=#{org.apache.cocoon.forms.generation.JXMacrosHelper.createHelper($cocoon/consumer,$cocoon/request,$cocoon/parameters/locale)}/
So the locale is get from sitemap parameters.
the locale attribute of the form is then never used.
I will provide a patch as soon as possible
--
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-1758) Form locale never used in JXMacros
[ http://issues.apache.org/jira/browse/COCOON-1758?page=all ]
Antonio Gallardo closed COCOON-1758.
Fix Version/s: 2.2-dev (Current SVN)
2.1.10-dev (current SVN)
Resolution: Fixed
Hi Carlos, I am glad to see you contributing back to the cocoon community!
Thanks for the patch. It was applied with minor changes. Please feel free to
reopen the issue if needed.
Form locale never used in JXMacros
--
Key: COCOON-1758
URL: http://issues.apache.org/jira/browse/COCOON-1758
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9
Reporter: Philippe Gassmann
Assigned To: Antonio Gallardo
Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN)
Attachments: 20060201-cocoon-forms-1758, patch.txt, patch1.txt
The JXMacroHelper is created with : jx:set var=cformsHelper
value=#{org.apache.cocoon.forms.generation.JXMacrosHelper.createHelper($cocoon/consumer,$cocoon/request,$cocoon/parameters/locale)}/
So the locale is get from sitemap parameters.
the locale attribute of the form is then never used.
I will provide a patch as soon as possible
--
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-1678) HTMLArea unable to set target and title to a link
[ http://issues.apache.org/jira/browse/COCOON-1678?page=all ] Antonio Gallardo reassigned COCOON-1678: Assignee: Antonio Gallardo (was: Cocoon Developers Team) HTMLArea unable to set target and title to a link --- Key: COCOON-1678 URL: http://issues.apache.org/jira/browse/COCOON-1678 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.8 Reporter: Philippe Gassmann Assigned To: Antonio Gallardo Priority: Minor Attachments: HTMLCleanerConfiguration.xml.patch I do the following test on http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/htmlarea : Type some text in the in a table HTMLArea. Select a portion of the text, click on the link button. Type the address : http://www.google.com Type a title : test Select a target. Submit, The result is : result data1br //data1 data2 html body p a a href=http://www.google.fr;new/a test /p /body /html /data2 /result -- 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-1678) HTMLArea unable to set target and title to a link
[ http://issues.apache.org/jira/browse/COCOON-1678?page=all ] Antonio Gallardo closed COCOON-1678. Fix Version/s: 2.2-dev (Current SVN) 2.1.10-dev (current SVN) Resolution: Fixed Thanks for the patch. It was applied. Feel free to reopen the issue if needed. HTMLArea unable to set target and title to a link --- Key: COCOON-1678 URL: http://issues.apache.org/jira/browse/COCOON-1678 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.8 Reporter: Philippe Gassmann Assigned To: Antonio Gallardo Priority: Minor Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) Attachments: HTMLCleanerConfiguration.xml.patch I do the following test on http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/htmlarea : Type some text in the in a table HTMLArea. Select a portion of the text, click on the link button. Type the address : http://www.google.com Type a title : test Select a target. Submit, The result is : result data1br //data1 data2 html body p a a href=http://www.google.fr;new/a test /p /body /html /data2 /result -- 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-1886) NPE when attempting to access cocoon.request from within a nested JS function
[ http://issues.apache.org/jira/browse/COCOON-1886?page=all ]
Antonio Gallardo updated COCOON-1886:
-
Would you provide a test case?
NPE when attempting to access cocoon.request from within a nested JS function
-
Key: COCOON-1886
URL: http://issues.apache.org/jira/browse/COCOON-1886
Project: Cocoon
Issue Type: Bug
Components: - Flowscript
Affects Versions: 2.1.8
Reporter: Mark Lundquist
Priority: Minor
? Confirmed in 2.1.8; probably affects subsequent versions as well
? Prioritized as minor because it can be worked around in most cases
This causes an NPE:
function outer() {
function inner() {
var x = cocoon.request;
}
}
java.lang.NullPointerException
at
org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.jsGet_request(FOM_Cocoon.java:574)
at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.mozilla.javascript.ScriptableObject.getByGetter(ScriptableObject.java:200)
etc...
--
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-1885) The EHDefaultStore returns in the size() method the wrong number of keys
[ http://issues.apache.org/jira/browse/COCOON-1885?page=all ] Antonio Gallardo closed COCOON-1885. Fix Version/s: 2.2-dev (Current SVN) 2.1.10-dev (current SVN) Resolution: Fixed Thanks for the patch. It was applied with minor changes. Feel free to reopen the issue if needed. The EHDefaultStore returns in the size() method the wrong number of keys Key: COCOON-1885 URL: http://issues.apache.org/jira/browse/COCOON-1885 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.9 Reporter: Ard Schrijvers Assigned To: Antonio Gallardo Priority: Critical Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) Attachments: EHDefaultStore.patch The excalibut store interface defines a size() method for a store: /** * Returns count of the objects in the store, or -1 if could not be * obtained. */ int size(); What it not explicitely says, is that it is the number of keys in memoryStore (so not the diskStore) is needed. The StoreJanitor uses this size() to free some memory from cache when the JVM is low on memory. Since the current EHDefaultStore returns with size() ALL cachekeys (memoryStoreSize + diskStoreSize), it is quite likely when having a large cache that the StoreJanitor removes all cachekeys in memoryStore. Simply changing the size() method of EHDefaultStore to return the number of keys in memoryStore is sufficient. The JCSDefaultStore did implement it correctly already (though I do not see it in the cocoon trunk anymore..?) -- 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-1854) [PATCH] Browser selector should have Opera before MSIE
[ http://issues.apache.org/jira/browse/COCOON-1854?page=all ] Antonio Gallardo reassigned COCOON-1854: Assignee: Antonio Gallardo [PATCH] Browser selector should have Opera before MSIE -- Key: COCOON-1854 URL: http://issues.apache.org/jira/browse/COCOON-1854 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.1.9 Reporter: Laurens Holst Assigned To: Antonio Gallardo Priority: Minor Attachments: patch.diff Hi, In current versions, Opera identifies itself in the UA string as MSIE by default. Nevertheless it can be identified because the string also contains 'Opera'. This however only works if browser checks check for Opera *before* they check for MSIE. To properly detect Opera the browser selector should thus be modified, from: map:selectors default=browser map:selector logger=sitemap.selector.browser name=browser src=org.apache.cocoon.selection.BrowserSelector browser name=explorer useragent=MSIE/ browser name=pocketexplorer useragent=MSPIE/ browser name=handweb useragent=HandHTTP/ browser name=avantgo useragent=AvantGo/ browser name=imode useragent=DoCoMo/ browser name=opera useragent=Opera/ browser name=lynx useragent=Lynx/ browser name=java useragent=Java/ browser name=wap useragent=Nokia/ browser name=wap useragent=UP/ browser name=wap useragent=Wapalizer/ browser name=mozilla5 useragent=Mozilla/5/ browser name=mozilla5 useragent=Netscape6// browser name=netscape useragent=Mozilla/ /map:selector into: map:selectors default=browser map:selector logger=sitemap.selector.browser name=browser src=org.apache.cocoon.selection.BrowserSelector browser name=opera useragent=Opera/ browser name=explorer useragent=MSIE/ browser name=pocketexplorer useragent=MSPIE/ browser name=handweb useragent=HandHTTP/ browser name=avantgo useragent=AvantGo/ browser name=imode useragent=DoCoMo/ browser name=lynx useragent=Lynx/ browser name=java useragent=Java/ browser name=wap useragent=Nokia/ browser name=wap useragent=UP/ browser name=wap useragent=Wapalizer/ browser name=mozilla5 useragent=Mozilla/5/ browser name=mozilla5 useragent=Netscape6// browser name=netscape useragent=Mozilla/ /map:selector i.e. Opera is moved five notches up to be tested before MSIE is. -- 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-1854) [PATCH] Browser selector should have Opera before MSIE
[ http://issues.apache.org/jira/browse/COCOON-1854?page=all ] Antonio Gallardo closed COCOON-1854. Fix Version/s: 2.2-dev (Current SVN) 2.1.10-dev (current SVN) Resolution: Fixed Thanks for the patch. It was applied in 2.1 branch and 2.2-dev. Feel free to reopen the issue if needed. [PATCH] Browser selector should have Opera before MSIE -- Key: COCOON-1854 URL: http://issues.apache.org/jira/browse/COCOON-1854 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.1.9 Reporter: Laurens Holst Assigned To: Antonio Gallardo Priority: Minor Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) Attachments: patch.diff Hi, In current versions, Opera identifies itself in the UA string as MSIE by default. Nevertheless it can be identified because the string also contains 'Opera'. This however only works if browser checks check for Opera *before* they check for MSIE. To properly detect Opera the browser selector should thus be modified, from: map:selectors default=browser map:selector logger=sitemap.selector.browser name=browser src=org.apache.cocoon.selection.BrowserSelector browser name=explorer useragent=MSIE/ browser name=pocketexplorer useragent=MSPIE/ browser name=handweb useragent=HandHTTP/ browser name=avantgo useragent=AvantGo/ browser name=imode useragent=DoCoMo/ browser name=opera useragent=Opera/ browser name=lynx useragent=Lynx/ browser name=java useragent=Java/ browser name=wap useragent=Nokia/ browser name=wap useragent=UP/ browser name=wap useragent=Wapalizer/ browser name=mozilla5 useragent=Mozilla/5/ browser name=mozilla5 useragent=Netscape6// browser name=netscape useragent=Mozilla/ /map:selector into: map:selectors default=browser map:selector logger=sitemap.selector.browser name=browser src=org.apache.cocoon.selection.BrowserSelector browser name=opera useragent=Opera/ browser name=explorer useragent=MSIE/ browser name=pocketexplorer useragent=MSPIE/ browser name=handweb useragent=HandHTTP/ browser name=avantgo useragent=AvantGo/ browser name=imode useragent=DoCoMo/ browser name=lynx useragent=Lynx/ browser name=java useragent=Java/ browser name=wap useragent=Nokia/ browser name=wap useragent=UP/ browser name=wap useragent=Wapalizer/ browser name=mozilla5 useragent=Mozilla/5/ browser name=mozilla5 useragent=Netscape6// browser name=netscape useragent=Mozilla/ /map:selector i.e. Opera is moved five notches up to be tested before MSIE is. -- 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-1882) ZipArchiveSerializer causes Too many open files exception
[ http://issues.apache.org/jira/browse/COCOON-1882?page=all ] Antonio Gallardo reassigned COCOON-1882: Assignee: Antonio Gallardo ZipArchiveSerializer causes Too many open files exception --- Key: COCOON-1882 URL: http://issues.apache.org/jira/browse/COCOON-1882 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.8, 2.1.9, 2.1.10-dev (current SVN) Reporter: Holger Wahlen Assigned To: Antonio Gallardo Attachments: ZipArchiveSerializer.diff When ZipArchiveSerializer is used to zip a big number of files, the OS-/Java-dependent limit for open file descriptors can be exceeded, resulting in a corrupt zip file and a Too many open files exception in the log. Apparenty the reason for this is that the InputStreams created in the addEntry method aren't cleaned up properly. If I add a call sourceInput.close(); after the output has been written, the problem doesn't occur any more. (I've had to do this in the 2.1.7 we're working with, hence no patch file.) -- 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
