[jira] Commented: (COCOON-2289) [2.1] Backport FOPNGSerializer
[ https://issues.apache.org/jira/browse/COCOON-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1285#action_1285 ] Sylvain Wallez commented on COCOON-2289: There are still a huge number of projects using Cocoon 2.1, and products (this is Cédric's case) based on 2.1 where migrating to 2.2 would be a significant effort without much benefits. So a backport seems ok to me if some people need it, and even more if they actually have code ready and already running in production systems. [2.1] Backport FOPNGSerializer -- Key: COCOON-2289 URL: https://issues.apache.org/jira/browse/COCOON-2289 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Reporter: Cédric Damioli Fix For: 2.1.12-dev (Current SVN) Cocoon 2.1 still don't have official support for FOP 0.9x, while Cocoon 2.2 does This compatibility is only a matter of FOPSerializer (called FOPNGSerializer in the Cocoon 2.2 fop-ng block) I won't put a patch here because it would only be a copy of the FOPNGSerializer.java from Cocoon-2.2, but it would be great if someone could backport the fop-ng block -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2286) Application does not start when the context path contains spaces
[ https://issues.apache.org/jira/browse/COCOON-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Wallez closed COCOON-2286. -- Resolution: Fixed Fix Version/s: 2.1.12-dev (Current SVN) Patch applied, with one minor modification: use specify the UTF-8 charset rather than relying on the JVM's default encoding Application does not start when the context path contains spaces Key: COCOON-2286 URL: https://issues.apache.org/jira/browse/COCOON-2286 Project: Cocoon Issue Type: Bug Components: Blocks: Serializers Affects Versions: 2.1.11 Reporter: Cédric Damioli Fix For: 2.1.12-dev (Current SVN) Attachments: CharsetFactory.java.patch When the CharsetFactory loads charsets from jar, the file path constructed from the jar URL may contains %20 or other encoded special characters. An exception is thrown when the jar file is being accessed : Root cause: java.io.FileNotFoundException: D:\cocoon%20build\WEB-INF\lib\cocoon-serializers-charsets-2.1.11.jar (Le chemin d'accès spécifié est introuvable) at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.init(ZipFile.java:114) at java.util.zip.ZipFile.init(ZipFile.java:75) at org.apache.cocoon.components.serializers.encoding.CharsetFactory.loadCharsetsFromJar(CharsetFactory.java:130) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2286) Application does not start when the context path contains spaces
[ https://issues.apache.org/jira/browse/COCOON-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1285#action_1285 ] Sylvain Wallez commented on COCOON-2286: Very good point! Now the top line in changes.xml says Starting with 2.1.12 the minimum required Java version will be 1.4.2, so I guess we can safely use this method. Application does not start when the context path contains spaces Key: COCOON-2286 URL: https://issues.apache.org/jira/browse/COCOON-2286 Project: Cocoon Issue Type: Bug Components: Blocks: Serializers Affects Versions: 2.1.11 Reporter: Cédric Damioli Fix For: 2.1.12-dev (Current SVN) Attachments: CharsetFactory.java.patch When the CharsetFactory loads charsets from jar, the file path constructed from the jar URL may contains %20 or other encoded special characters. An exception is thrown when the jar file is being accessed : Root cause: java.io.FileNotFoundException: D:\cocoon%20build\WEB-INF\lib\cocoon-serializers-charsets-2.1.11.jar (Le chemin d'accès spécifié est introuvable) at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.init(ZipFile.java:114) at java.util.zip.ZipFile.init(ZipFile.java:75) at org.apache.cocoon.components.serializers.encoding.CharsetFactory.loadCharsetsFromJar(CharsetFactory.java:130) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON3-54) LinkRewriterTransformer
[ https://issues.apache.org/jira/browse/COCOON3-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12847808#action_12847808 ] Sylvain Wallez commented on COCOON3-54: --- The configuration of the rewriter needs to take into account element namespaces, so that you can deal with mixed namespace documents, e.g. xhtml and xlink or xinclude LinkRewriterTransformer --- Key: COCOON3-54 URL: https://issues.apache.org/jira/browse/COCOON3-54 Project: Cocoon 3 Issue Type: New Feature Components: cocoon-sax Reporter: Francesco Chicchiriccò Assignee: Simone Tripodi Attachments: LinkRewriter.java, LinkRewriterTransformer.java, LinkRewritingException.java A LinkRewriterTransformer (like as the old one for Cocoon 2.1, see [1]) could be a very nice addendum to Cocoon 3. It could may even by an idea to have a LinkRewriterTransformerT, where T is the class performing the actual transformation on links. [1] http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/transformation/LinkRewriterTransformer.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON3-6) The org.apache.cocoon.pipeline.component.sax.XSLTTransformer can be optimized
[ https://issues.apache.org/jira/browse/COCOON3-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12642190#action_12642190 ] Sylvain Wallez commented on COCOON3-6: -- Have a look at http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-components/src/main/java/org/apache/cocoon/transformation/XSLTTransformer.java and all its dependencies. The org.apache.cocoon.pipeline.component.sax.XSLTTransformer can be optimized - Key: COCOON3-6 URL: https://issues.apache.org/jira/browse/COCOON3-6 Project: Cocoon 3 Issue Type: New Feature Components: cocoon-pipeline Affects Versions: 3.0.0-alpha-2 Reporter: Simone Tripodi Assignee: Cocoon Developers Team Priority: Minor Fix For: 3.0.0-alpha-2 Attachments: XSLTTransformerOptimization.patch Every time the XSLTTransformer#setXMLConsumer method is called, the XSLT is parsed reading the URL source and used to create the javax.xml.transform.sax.TransformerHandler: to be more clear [...] XSLTTransformer xsltTransformer = new XSLTTransformer(getClass().getResource(myXSLT.xsl)); Pipeline pipeline1 = new NonCachingPipeline(); pipeline1.addComponent(new StringGenerator(xy//x)); pipeline1.addComponent(xsltTransformer); pipeline1.addComponent(new XMLSerializer()); pipeline1.setup(System.out); pipeline1.execute(); Pipeline pipeline2 = new NonCachingPipeline(); pipeline2.addComponent(new StringGenerator(zw//z)); pipeline2.addComponent(xsltTransformer); == the URL pointed by getClass().getResource(myXSLT.xsl) will be parsed again!!! pipeline2.addComponent(new XMLSerializer()); pipeline2.setup(System.out); pipeline2.execute(); As a quick solution we can store the Template to build the transformer handler objects in a static hashmap, but in the future we should introduce stores. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON3-6) The org.apache.cocoon.pipeline.component.sax.XSLTTransformer can be optimized
[ https://issues.apache.org/jira/browse/COCOON3-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12641831#action_12641831 ] Sylvain Wallez commented on COCOON3-6: -- This feature has been available in Cocoon for ages, storing Template objects in a LRU cache, and reloading stylesheets as needed when they have changed. Writing a new Cocoon is fine, but it should learn from the old one and reuse some of it. The org.apache.cocoon.pipeline.component.sax.XSLTTransformer can be optimized - Key: COCOON3-6 URL: https://issues.apache.org/jira/browse/COCOON3-6 Project: Cocoon 3 Issue Type: New Feature Components: cocoon-pipeline Affects Versions: 3.0.0-alpha-2 Reporter: Simone Tripodi Assignee: Cocoon Developers Team Priority: Minor Fix For: 3.0.0-alpha-2 Attachments: XSLTTransformerOptimization.patch Every time the XSLTTransformer#setXMLConsumer method is called, the XSLT is parsed reading the URL source and used to create the javax.xml.transform.sax.TransformerHandler: to be more clear [...] XSLTTransformer xsltTransformer = new XSLTTransformer(getClass().getResource(myXSLT.xsl)); Pipeline pipeline1 = new NonCachingPipeline(); pipeline1.addComponent(new StringGenerator(xy//x)); pipeline1.addComponent(xsltTransformer); pipeline1.addComponent(new XMLSerializer()); pipeline1.setup(System.out); pipeline1.execute(); Pipeline pipeline2 = new NonCachingPipeline(); pipeline2.addComponent(new StringGenerator(zw//z)); pipeline2.addComponent(xsltTransformer); == the URL pointed by getClass().getResource(myXSLT.xsl) will be parsed again!!! pipeline2.addComponent(new XMLSerializer()); pipeline2.setup(System.out); pipeline2.execute(); As a quick solution we can store the Template to build the transformer handler objects in a static hashmap, but in the future we should introduce stores. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (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:all-tabpanel
]
Sylvain Wallez closed COCOON-2208.
--
Resolution: Duplicate
Yes, it's the same as COCOON-1985. Sorry for the noise...
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] Created: (COCOON-2208) Race condition in AbstractCachingProcessingPipeline causes threads to hang.
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] Commented: (COCOON-2126) CForms-Ajax-Update sends span instead of td
[ https://issues.apache.org/jira/browse/COCOON-2126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554366 ] Sylvain Wallez commented on COCOON-2126: A bit of warning: widgets are not block-level components, and are allowed in places where HTML would forbid a div. For example, it is perfectly legal to include a fd:label in a b tag where a div is not allowed. So replacing the span with a div can actually do more harm than good as a general solution. So we must have a special behavior for replacements in a tr that inserts a td rather than a span. Handling this server-side in jx-macros.xml (or JXMacrosHelper) seems quite complicated since we can't grab what is sent to the cocoonConsumer by the JXTemplateGenerator. The easiest way is most probably to handle this special case in BUHandler.js, in the handlers.replace function: if oldElement is a td and firstChild is an empty span, then replace firstChild with an empty td *with the proper id attribute* (so that it can be replaced again later). CForms-Ajax-Update sends span instead of td --- Key: COCOON-2126 URL: https://issues.apache.org/jira/browse/COCOON-2126 Project: Cocoon Issue Type: Bug Components: Blocks: Ajax, Blocks: Forms Affects Versions: 2.1.10 Reporter: Florian Weitling Assignee: Grzegorz Kossakowski Attachments: screenshot-1.jpg, screenshot-2.jpg, screenshot-3.jpg, showQuestion.bind.xml, showQuestion.def.xml, showQuestion.js, showQuestion.tmpl.xml, sitemap-excerpt.xmap In a table the cells' entries are delivered by a repeater. When hiding a cell programmatically via WidgetState.INVISIBLE the bu:update contains a span instead of a tr or another hint to hide away the cell. This results in weird optics 'cause span is not allowed as child of a tr. My current workaround: Using divs with table* styles. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-1303) Small API change to access sitemap data structure
[ https://issues.apache.org/jira/browse/COCOON-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Wallez reassigned COCOON-1303: -- Assignee: (was: Sylvain Wallez) Small API change to access sitemap data structure - Key: COCOON-1303 URL: https://issues.apache.org/jira/browse/COCOON-1303 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.1.5 Environment: Operating System: other Platform: All Reporter: Sandor Spruit Priority: Minor I'd like a method that I can call to recursively walk through the sitemap data structure - probably some sort of finite state automaton stuff. At the Cocoon GetTogether, Sylvain suggested that this might actually be quite easy. I'd like to see whether I can visualize the sitemap of a running server, i.e. not just some small fraction of it, not process sitemap.xmap using XSLT. Perhaps try to visualize it using hyperbolic trees of some sort. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[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_12413991
]
Sylvain Wallez commented on COCOON-1825:
I don't see how surrounding the table with a span changes something. Or...
I remember of a bug in IE that doesn't like tables to be replaced in JavaScript
or something related.
Adding an element for fi:group and fi:struct is good, but I'm wondering if
this should be a div rather than a span.
fi:placeholder are used to mark the place of hidden widgets and should be
kept empty.
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
Type: Bug
Components: Blocks: Forms
Versions: 2.1.9
Reporter: vincent Demay
Assignee: 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] Commented: (COCOON-1685) Additional ProcessingPhase.READ_FROM_REQUEST_VALUE event sent
[ http://issues.apache.org/jira/browse/COCOON-1685?page=comments#action_12366913 ] Sylvain Wallez commented on COCOON-1685: I think the 3rd solution makes most sense, as it allows listeners to be triggered both before and after the request has been added. And if some actions have to be taken at form creation time, there's the on-create listener, which is called before binding Additional ProcessingPhase.READ_FROM_REQUEST_VALUE event sent - Key: COCOON-1685 URL: http://issues.apache.org/jira/browse/COCOON-1685 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8 Reporter: Simone Gianni In the Form.process() method, there is a listener.phaseEnded on line 296 which sends a LOAD_MODEL_VALUE the first time the form is executed, and a READ_FROM_REQUEST_VALUE all the other times. If a ProcessingPhaseListener is registered it will receive a READ_FROM_REQUEST_VALUE before the request has been processed, and another one after. IMMO there are the following possible solutions : - remove this event broadcast. - send this event only if phase is LOAD_MODEL_VALUE, so that this event takes his chance to get broadcasted, while the spurious one doesn't. - add a PROCESS_INITIALIZED phase event and send this one at this point. I can produce the patch if needed, but don't know which solution is the best one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1774) Fine Tuning Ajax Handling in CForms
[ http://issues.apache.org/jira/browse/COCOON-1774?page=comments#action_12365995 ] Sylvain Wallez commented on COCOON-1774: Can you elaborate on the need for widget-level ajax=false? Also the submit handlers cannot be kept after an Ajax submit, as some of the handlers can be registered by widgets that are replaced by the Ajax response Fine Tuning Ajax Handling in CForms --- Key: COCOON-1774 URL: http://issues.apache.org/jira/browse/COCOON-1774 Project: Cocoon Type: Improvement Components: Blocks: Forms, Blocks: Ajax Versions: 2.1.8 Reporter: Eric Meyer Assignee: Antonio Gallardo Attachments: fi-styling-ajax-false.patch.txt Currently, it's all or nothing when it comes to using AJAX on a form. With this enhancement, form widgets can be marked with fi:styling ajax='false' /, and they will trigger a non-ajax form submission. This was particularly useful on the main submit buttons on a form inconjunction with the fi:validation-messages element (see http://issues.apache.org/jira/browse/COCOON-1570 for why fi:validation-messages doesn't work with AJAX). Regardless, I believe it is useful to give the developer control over which widgets use AJAX and which do not. Note that the patch files also include a fix to a separate AJAX issue. forms_onsubmitHandlers = null Causes problems when in AJAX mode - submit handlers are only called the first time an ajax submit is called. Thereafter, the array of handlers is null, and none are called. -- 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-1689) Cannot save a cform containing a multivalued field with more than 9 values !
[
http://issues.apache.org/jira/browse/COCOON-1689?page=comments#action_12358249
]
Sylvain Wallez commented on COCOON-1689:
We have no indication of the JXPath problem that led to avoiding the use of
jxpathContext.removePath(). Giacomo, as the author of this change, can you give
us more indications on what motivated it ?
Cannot save a cform containing a multivalued field with more than 9 values !
Key: COCOON-1689
URL: http://issues.apache.org/jira/browse/COCOON-1689
Project: Cocoon
Type: Bug
Components: Blocks: Forms
Versions: 2.1.8, 2.1.9-dev (current SVN), 2.2-dev (Current SVN)
Reporter: Philippe Gassmann
Priority: Minor
An UnsupportedOperationException occurs when trying to save a form containing
a multivalued field with more that 9 values. Here is the explanation :
here is the incriminated code in MultiValueJXPathBinding.java:doSave():
Iterator rowPointers = multiValueContext.iteratePointers(this.rowPath);
List l = new ArrayList();
while( rowPointers.hasNext() )
{
Pointer p = (Pointer)rowPointers.next();
l.add(p.asPath());
}
Collections.sort(l);
for( int i = l.size()-1; i = 0; i-- )
{
multiValueContext.removePath((String)l.get(i));
}
This code is wrong :
The p.asPath returns something like /doc/node[x]
if the iterator contains more than 9 values x will be written in TWO
characters so, the result of Collections.sort(l) return for 10 values :
/doc/node[10]
/doc/node[1]
/doc/node[2]
/doc/node[3]
/doc/node[4]
/doc/node[5]
/doc/node[6]
/doc/node[7]
/doc/node[8]
/doc/node[9]
so the first node to be deleted is 9. the last is 10. but when trying to
delete the 10th node it does not exist anymore !
A UnsupportedOperationException is thrown.
--
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-889) NPE in AbstractEnvironment class
[ http://issues.apache.org/jira/browse/COCOON-889?page=all ] Sylvain Wallez closed COCOON-889: - Resolution: Fixed Assign To: (was: Ivan Kurmanov) There were some nasty multi-threading bugs fixed that were causing NPEs in pipelines called from cron jobs. So this should be fixed in 2.1.8. Reopen it *only* if it still breaks with the latest revision. NPE in AbstractEnvironment class Key: COCOON-889 URL: http://issues.apache.org/jira/browse/COCOON-889 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.2 Environment: Operating System: Linux Platform: PC Reporter: Ivan Kurmanov java.lang.NullPointerException at org.apache.cocoon.environment.AbstractEnvironment.release(AbstractEnvironment.java:521) at org.apache.cocoon.environment.wrapper.MutableEnvironmentFacade.release(MutableEnvironmentFacade.java:332) at org.apache.cocoon.generation.FileGenerator.recycle(FileGenerator.java:89) at org.apache.avalon.excalibur.pool.ResourceLimitingPool.put(ResourceLimitingPool.java:438) at org.apache.avalon.excalibur.component.PoolableComponentHandler.doPut(PoolableComponentHandler.java:245) at org.apache.avalon.excalibur.component.ComponentHandler.put(ComponentHandler.java:452) at org.apache.avalon.excalibur.component.ExcaliburComponentSelector.release(ExcaliburComponentSelector.java:336) at org.apache.cocoon.components.ExtendedComponentSelector.release(ExtendedComponentSelector.java:326) at org.apache.cocoon.components.ExtendedComponentSelector.release(ExtendedComponentSelector.java:323) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.recycle(AbstractProcessingPipeline.java:641) at org.apache.cocoon.components.pipeline.impl.BaseCachingProcessingPipeline.recycle(BaseCachingProcessingPipeline.java:112) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.recycle(AbstractCachingProcessingPipeline.java:961) at org.apache.avalon.excalibur.pool.ResourceLimitingPool.put(ResourceLimitingPool.java:438) at org.apache.avalon.excalibur.component.PoolableComponentHandler.doPut(PoolableComponentHandler.java:245) at org.apache.avalon.excalibur.component.ComponentHandler.put(ComponentHandler.java:452) at org.apache.avalon.excalibur.component.ExcaliburComponentSelector.release(ExcaliburComponentSelector.java:336) at org.apache.cocoon.components.ExtendedComponentSelector.release(ExtendedComponentSelector.java:326) at org.apache.cocoon.components.EnvironmentDescription.release(CocoonComponentManager.java:602) at org.apache.cocoon.components.CocoonComponentManager.endProcessing(CocoonComponentManager.java:212) at org.apache.cocoon.Cocoon.process(Cocoon.java:660) at org.apache.cocoon.bean.CocoonWrapper.getPage(CocoonWrapper.java:535) at org.apache.cocoon.bean.CocoonBean.processTarget(CocoonBean.java:521) at org.apache.cocoon.bean.CocoonBean.process(CocoonBean.java:372) at org.apache.cocoon.Main.main(Main.java:388) The same exception repeated three times for a single request/file, although it is generated through three different calling classes. The general picture: I use Forrest, which got me 2.1.2-dev version of Cocoon. I edited the sitemap.xmap to remove unnecesary things, like PDF generation (FO processing) and alike. Didn't change pool-* settings. In site.xml I have an item with href='/'. This item is referenced in one of the pages. This quite well might be a Forrest bug, but maybe Cocoon also need to be more careful about null pointers in this case. -- 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-1679) New cocoon logo proposal
[ http://issues.apache.org/jira/browse/COCOON-1679?page=comments#action_12356763 ] Sylvain Wallez commented on COCOON-1679: We value you efforts, but honestly this logo is all but readable... New cocoon logo proposal Key: COCOON-1679 URL: http://issues.apache.org/jira/browse/COCOON-1679 Project: Cocoon Type: Improvement Reporter: Milan Andrejevic Priority: Trivial Attachments: cocoon.png, cocoon.svg This is just an idea of new cocoon logo. See attachment. Spent some hours to create. -- 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-1672) Help popup broken in CForms samples
[ http://issues.apache.org/jira/browse/COCOON-1672?page=all ] Sylvain Wallez closed COCOON-1672: -- Resolution: Fixed Fixed by revisions r330513 and r330514 Help popup broken in CForms samples --- Key: COCOON-1672 URL: http://issues.apache.org/jira/browse/COCOON-1672 Project: Cocoon Type: Bug Components: Blocks: Forms, - Samples Versions: 2.1.8-dev (Current SVN) Reporter: Andreas Hochsteger Assignee: Sylvain Wallez If you open the multiform (ajax) sample (http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/do-multipage.flow) and click on the help popup for the email addres, it is working. But if you click on next, then it is not working any more. I get the following JavaScript error: Error: helpWinN10010 has no properties It seems to me, that the help window is not referenced correctly after the first submit. Perhaps it's AJAX-related, because it is working for non-ajax samples: http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/form1 http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/captcha/ Similar problems can be found on the following samples with the help popup and calendar popup, where the images are missing too: http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/library/form1.flow http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/library/form2.flow http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/library/hotel.flow I tested it locally with a fresh svn checkout (r330107) and on cocoon.zones.apache.org with Firefox 1.5beta2 and IE 6 (Win XP Pro, SP2), Sun JDK 1.5.0_04. -- 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-1668) o.a.c.forms.formmodel.GroupTestCase fails
[ http://issues.apache.org/jira/browse/COCOON-1668?page=comments#action_12356488 ] Sylvain Wallez commented on COCOON-1668: Fixed in the 2.1 branch. However, we have a problem as there's no implementation of ServiceSelector that is common to both branches. Maybe we should reintroduce ExtendedComponentSelector in 2.2 (and make it extend o.a.c.core.container.StandaloneServiceSelector) so that we can have multi-branch configurations? o.a.c.forms.formmodel.GroupTestCase fails - Key: COCOON-1668 URL: http://issues.apache.org/jira/browse/COCOON-1668 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8-dev (Current SVN) Reporter: Bertrand Delacretaz Assignee: Cocoon Developers Team Priority: Minor Fix For: 2.1.8-dev (Current SVN) In revision 329128, org.apache.cocoon.forms.formmodel.GroupTestCase fails on my macosx/JDK 1.4.2-38 system, the core problem seems to be class org.apache.cocoon.core.container.DefaultServiceSelector not found. testInheritance: Could not get class org.apache.avalon.framework.configuration.ConfigurationException: Could not get class at org.apache.avalon.excalibur.component.ExcaliburComponentManager.configure(ExcaliburComponentManager.java:458) at org.apache.cocoon.core.container.ContainerTestCase.setupManagers(ContainerTestCase.java:267) at org.apache.cocoon.core.container.ContainerTestCase.prepare(ContainerTestCase.java:190) at org.apache.cocoon.core.container.ContainerTestCase.prepare(ContainerTestCase.java:162) at org.apache.cocoon.core.container.ContainerTestCase.setUp(ContainerTestCase.java:146)Caused by: java.lang.ClassNotFoundException: org.apache.cocoon.core.container.DefaultServiceSelector at java.net.URLClassLoader$1.run(URLClassLoader.java:199) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.avalon.excalibur.component.ExcaliburComponentManager.configure(ExcaliburComponentManager.java:444) ... 14 more -- 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-1669) o.a.c.jcr.source.JCRSourceTestCase fails
[ http://issues.apache.org/jira/browse/COCOON-1669?page=all ] Sylvain Wallez closed COCOON-1669: -- Resolution: Fixed Updated repository.xml (format has changed in newer jackrabbit) and guarded against a NPE as there's no request in the object model when running in a testcase o.a.c.jcr.source.JCRSourceTestCase fails Key: COCOON-1669 URL: http://issues.apache.org/jira/browse/COCOON-1669 Project: Cocoon Type: Bug Components: Blocks: JCR Versions: 2.1.8-dev (Current SVN) Reporter: Bertrand Delacretaz Assignee: Cocoon Developers Team Priority: Minor Fix For: 2.1.8-dev (Current SVN) All tests fail with Cannot access configuration information at null:36:21 on my macosx/JDK 1.4.2-38 system. Details: Cannot access configuration information at null:36:21 org.apache.avalon.framework.configuration.ConfigurationException: Cannot access configuration information at null:36:21 at org.apache.cocoon.jcr.JackrabbitRepository.configure(JackrabbitRepository.java:98) at org.apache.avalon.framework.container.ContainerUtil.configure(ContainerUtil.java:201) at org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:289) at org.apache.avalon.excalibur.component.ThreadSafeComponentHandler. -- 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-1668) o.a.c.forms.formmodel.GroupTestCase fails
[ http://issues.apache.org/jira/browse/COCOON-1668?page=all ] Sylvain Wallez updated COCOON-1668: --- Version: 2.2-dev (Current SVN) (was: 2.1.8-dev (Current SVN)) Changing to version 2.2 as it's where it breaks now o.a.c.forms.formmodel.GroupTestCase fails - Key: COCOON-1668 URL: http://issues.apache.org/jira/browse/COCOON-1668 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.2-dev (Current SVN) Reporter: Bertrand Delacretaz Assignee: Cocoon Developers Team Priority: Minor Fix For: 2.1.8-dev (Current SVN) In revision 329128, org.apache.cocoon.forms.formmodel.GroupTestCase fails on my macosx/JDK 1.4.2-38 system, the core problem seems to be class org.apache.cocoon.core.container.DefaultServiceSelector not found. testInheritance: Could not get class org.apache.avalon.framework.configuration.ConfigurationException: Could not get class at org.apache.avalon.excalibur.component.ExcaliburComponentManager.configure(ExcaliburComponentManager.java:458) at org.apache.cocoon.core.container.ContainerTestCase.setupManagers(ContainerTestCase.java:267) at org.apache.cocoon.core.container.ContainerTestCase.prepare(ContainerTestCase.java:190) at org.apache.cocoon.core.container.ContainerTestCase.prepare(ContainerTestCase.java:162) at org.apache.cocoon.core.container.ContainerTestCase.setUp(ContainerTestCase.java:146)Caused by: java.lang.ClassNotFoundException: org.apache.cocoon.core.container.DefaultServiceSelector at java.net.URLClassLoader$1.run(URLClassLoader.java:199) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.avalon.excalibur.component.ExcaliburComponentManager.configure(ExcaliburComponentManager.java:444) ... 14 more -- 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-1668) o.a.c.forms.formmodel.GroupTestCase fails
[ http://issues.apache.org/jira/browse/COCOON-1668?page=all ] Sylvain Wallez updated COCOON-1668: --- Fix Version: 2.2-dev (Current SVN) (was: 2.1.8-dev (Current SVN)) Need to get used to JIRA classifiers... o.a.c.forms.formmodel.GroupTestCase fails - Key: COCOON-1668 URL: http://issues.apache.org/jira/browse/COCOON-1668 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.2-dev (Current SVN) Reporter: Bertrand Delacretaz Assignee: Cocoon Developers Team Priority: Minor Fix For: 2.2-dev (Current SVN) In revision 329128, org.apache.cocoon.forms.formmodel.GroupTestCase fails on my macosx/JDK 1.4.2-38 system, the core problem seems to be class org.apache.cocoon.core.container.DefaultServiceSelector not found. testInheritance: Could not get class org.apache.avalon.framework.configuration.ConfigurationException: Could not get class at org.apache.avalon.excalibur.component.ExcaliburComponentManager.configure(ExcaliburComponentManager.java:458) at org.apache.cocoon.core.container.ContainerTestCase.setupManagers(ContainerTestCase.java:267) at org.apache.cocoon.core.container.ContainerTestCase.prepare(ContainerTestCase.java:190) at org.apache.cocoon.core.container.ContainerTestCase.prepare(ContainerTestCase.java:162) at org.apache.cocoon.core.container.ContainerTestCase.setUp(ContainerTestCase.java:146)Caused by: java.lang.ClassNotFoundException: org.apache.cocoon.core.container.DefaultServiceSelector at java.net.URLClassLoader$1.run(URLClassLoader.java:199) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.avalon.excalibur.component.ExcaliburComponentManager.configure(ExcaliburComponentManager.java:444) ... 14 more -- 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-1615) [CFORMS] Widgets set to INVISIBLE not are removed in AJAX
[ http://issues.apache.org/jira/browse/COCOON-1615?page=all ] Sylvain Wallez closed COCOON-1615: -- Resolution: Fixed Fixed. [CFORMS] Widgets set to INVISIBLE not are removed in AJAX - Key: COCOON-1615 URL: http://issues.apache.org/jira/browse/COCOON-1615 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Jason Johnston Assignee: Cocoon Developers Team Since the CForms JXMacros refactoring, a widget which is programatically set to WidgetState.INVISIBLE is not removed from the display during AJAX requests, because no BrowserUpdate wrapper is created for it. See JXMacrosHelper.pushWidget(), around line 186 (svn rev 291471). -- 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-1629) No default value in forms binding
[ http://issues.apache.org/jira/browse/COCOON-1629?page=all ]
Sylvain Wallez updated COCOON-1629:
---
Bugzilla Id: (was: 36993)
Description:
When wishing to have a default value for the binding of a form widget, it is
required to make use of a hack like this:
for (var iter = form.form.getChildren() ;
iter.hasNext() ;) {
var child = iter.next();
if
(child.getClass().getName().equals(org.apache.cocoon.forms.formmodel.Field)
child.getDatatype().getTypeClass().getName().equals(java.lang.Long)
child.getValue() == null) {
child.setValue(new java.lang.Long(-1));
}
}
It would be great to add an attribute on fd:datatype, for example:
fd:datatype base=long default=-1 to have a default value that could be
used in the binding.
was:
When wishing to have a default value for the binding of a form widget, it is
required to make use of a hack like this:
for (var iter = form.form.getChildren() ;
iter.hasNext() ;) {
var child = iter.next();
if
(child.getClass().getName().equals(org.apache.cocoon.forms.formmodel.Field)
child.getDatatype().getTypeClass().getName().equals(java.lang.Long)
child.getValue() == null) {
child.setValue(new java.lang.Long(-1));
}
}
It would be great to add an attribute on fd:datatype, for example:
fd:datatype base=long default=-1 to have a default value that could be
used in the binding.
Doesn't the initial value in form definition solve your problem?
fd:field id=foo initial-value=-1
No default value in forms binding
-
Key: COCOON-1629
URL: http://issues.apache.org/jira/browse/COCOON-1629
Project: Cocoon
Type: Improvement
Components: Blocks: Forms
Versions: 2.1.8-dev (Current SVN)
Environment: Operating System: other
Platform: Other
Reporter: Jean-Baptiste Quenot
Assignee: Cocoon Developers Team
Priority: Minor
When wishing to have a default value for the binding of a form widget, it is
required to make use of a hack like this:
for (var iter = form.form.getChildren() ;
iter.hasNext() ;) {
var child = iter.next();
if
(child.getClass().getName().equals(org.apache.cocoon.forms.formmodel.Field)
child.getDatatype().getTypeClass().getName().equals(java.lang.Long)
child.getValue() == null) {
child.setValue(new java.lang.Long(-1));
}
}
It would be great to add an attribute on fd:datatype, for example:
fd:datatype base=long default=-1 to have a default value that could be
used in the binding.
--
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-1607) Patch for forms-calender-styling.xsl
[ http://issues.apache.org/jira/browse/COCOON-1607?page=all ] Sylvain Wallez closed COCOON-1607: -- Resolution: Fixed Fixed in revision 307413 Patch for forms-calender-styling.xsl Key: COCOON-1607 URL: http://issues.apache.org/jira/browse/COCOON-1607 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8-dev (Current SVN) Environment: Operating System: All Platform: Other Reporter: Christoph Hermann Assignee: Cocoon Developers Team Priority: Trivial Attachments: forms-calender-styleing.xsl-patch Hello, i modified the id attribute of the input in forms-calender-styling.xsl (from svn) to make the generated html valid. The id tag should contain -input (as all other inputs) for the label-reference. See attached patch. Christoph -- 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-1672) Help popup broken in CForms samples
[ http://issues.apache.org/jira/browse/COCOON-1672?page=all ] Sylvain Wallez reassigned COCOON-1672: -- Assign To: Sylvain Wallez Help popup broken in CForms samples --- Key: COCOON-1672 URL: http://issues.apache.org/jira/browse/COCOON-1672 Project: Cocoon Type: Bug Components: Blocks: Forms, - Samples Versions: 2.1.8-dev (Current SVN) Reporter: Andreas Hochsteger Assignee: Sylvain Wallez If you open the multiform (ajax) sample (http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/do-multipage.flow) and click on the help popup for the email addres, it is working. But if you click on next, then it is not working any more. I get the following JavaScript error: Error: helpWinN10010 has no properties It seems to me, that the help window is not referenced correctly after the first submit. Perhaps it's AJAX-related, because it is working for non-ajax samples: http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/form1 http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/captcha/ Similar problems can be found on the following samples with the help popup and calendar popup, where the images are missing too: http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/library/form1.flow http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/library/form2.flow http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/library/hotel.flow I tested it locally with a fresh svn checkout (r330107) and on cocoon.zones.apache.org with Firefox 1.5beta2 and IE 6 (Win XP Pro, SP2), Sun JDK 1.5.0_04. -- 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-1672) Help popup broken in CForms samples
[ http://issues.apache.org/jira/browse/COCOON-1672?page=comments#action_12356541 ] Sylvain Wallez commented on COCOON-1672: I'm currently working on a fix. The problem is twofold: - use of generate-id() which should be avoided in an Ajax environment where several requests participate to a single page - script tags in Ajax responses which aren't evaluated Help popup broken in CForms samples --- Key: COCOON-1672 URL: http://issues.apache.org/jira/browse/COCOON-1672 Project: Cocoon Type: Bug Components: Blocks: Forms, - Samples Versions: 2.1.8-dev (Current SVN) Reporter: Andreas Hochsteger Assignee: Sylvain Wallez If you open the multiform (ajax) sample (http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/do-multipage.flow) and click on the help popup for the email addres, it is working. But if you click on next, then it is not working any more. I get the following JavaScript error: Error: helpWinN10010 has no properties It seems to me, that the help window is not referenced correctly after the first submit. Perhaps it's AJAX-related, because it is working for non-ajax samples: http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/form1 http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/captcha/ Similar problems can be found on the following samples with the help popup and calendar popup, where the images are missing too: http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/library/form1.flow http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/library/form2.flow http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/library/hotel.flow I tested it locally with a fresh svn checkout (r330107) and on cocoon.zones.apache.org with Firefox 1.5beta2 and IE 6 (Win XP Pro, SP2), Sun JDK 1.5.0_04. -- 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-1661) Portal Sample broken : SQLException
[ http://issues.apache.org/jira/browse/COCOON-1661?page=all ] Sylvain Wallez closed COCOON-1661: -- Resolution: Fixed The problem was because the 3 Cocoon versions running on the zone where using the same port number for the hsqldb server. This is now fixed, and each instance uses a different port number Portal Sample broken : SQLException --- Key: COCOON-1661 URL: http://issues.apache.org/jira/browse/COCOON-1661 Project: Cocoon Type: Bug Components: Blocks: Portal Versions: 2.1.8-dev (Current SVN) Reporter: Philippe Gassmann Priority: Blocker An exception occurs when trying to load the portal sample : java.sql.SQLException: Connection is broken: Transfer corrupted at org.hsqldb.jdbc.Util.sqlException(Unknown Source) at org.hsqldb.jdbc.jdbcConnection.getAutoCommit(Unknown Source) 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.apache.avalon.excalibur.datasource.AbstractJdbcConnection.invoke(AbstractJdbcConnection.java:397) at $Proxy22.getAutoCommit(Unknown Source) at org.apache.avalon.excalibur.datasource.JdbcConnectionFactory.newInstance(JdbcConnectionFactory.java:223) at org.apache.avalon.excalibur.pool.InstrumentedResourceLimitingPool.newPoolable(InstrumentedResourceLimitingPool.java:655) at org.apache.avalon.excalibur.pool.ValidatedResourceLimitingPool.newPoolable(ValidatedResourceLimitingPool.java:145) at org.apache.avalon.excalibur.datasource.ResourceLimitingJdbcConnectionPool.newPoolable(ResourceLimitingJdbcConnectionPool.java:91) at org.apache.avalon.excalibur.pool.InstrumentedResourceLimitingPool.get(InstrumentedResourceLimitingPool.java:371) at org.apache.avalon.excalibur.pool.ValidatedResourceLimitingPool.get(ValidatedResourceLimitingPool.java:97) at org.apache.avalon.excalibur.datasource.ResourceLimitingJdbcDataSource.getConnection(ResourceLimitingJdbcDataSource.java:188) at org.apache.cocoon.ojb.components.ConnectionFactoryImpl.lookupConnection(ConnectionFactoryImpl.java:129) at org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.getConnection(Unknown Source) at org.apache.ojb.broker.accesslayer.StatementManager.getPreparedStatement(Unknown Source) at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(Unknown Source) at org.apache.ojb.broker.accesslayer.RsQueryObject.performQuery(Unknown Source) at org.apache.ojb.broker.accesslayer.RsIterator.init(Unknown Source) at org.apache.ojb.broker.core.RsIteratorFactoryImpl.createRsIterator(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getRsIteratorFromQuery(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getIteratorFromQuery(Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(Unknown Source) at org.apache.cocoon.portal.security.DBSecurityHandler.login(DBSecurityHandler.java:50) 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.apache.avalon.excalibur.component.ComponentProxyGenerator$ComponentInvocationHandler.invoke(ComponentProxyGenerator.java:143) at $Proxy18.login(Unknown Source) at org.osoco.cowarp.impl.StandardApplicationManager.login(StandardApplicationManager.java:193) 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.apache.avalon.excalibur.component.ComponentProxyGenerator$ComponentInvocationHandler.invoke(ComponentProxyGenerator.java:143) at
[jira] Commented: (COCOON-1661) Portal Sample broken : SQLException
[ http://issues.apache.org/jira/browse/COCOON-1661?page=comments#action_12355959 ] Sylvain Wallez commented on COCOON-1661: Sorry, by reading Bertrand's comment, I thought it was about the zone, which is now fixed. No it happens that you had the same exact problem on your PC :-) (Philppe is sitting about 10 meters away from me) Portal Sample broken : SQLException --- Key: COCOON-1661 URL: http://issues.apache.org/jira/browse/COCOON-1661 Project: Cocoon Type: Bug Components: Blocks: Portal Versions: 2.1.8-dev (Current SVN) Reporter: Philippe Gassmann Priority: Blocker An exception occurs when trying to load the portal sample : java.sql.SQLException: Connection is broken: Transfer corrupted at org.hsqldb.jdbc.Util.sqlException(Unknown Source) at org.hsqldb.jdbc.jdbcConnection.getAutoCommit(Unknown Source) 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.apache.avalon.excalibur.datasource.AbstractJdbcConnection.invoke(AbstractJdbcConnection.java:397) at $Proxy22.getAutoCommit(Unknown Source) at org.apache.avalon.excalibur.datasource.JdbcConnectionFactory.newInstance(JdbcConnectionFactory.java:223) at org.apache.avalon.excalibur.pool.InstrumentedResourceLimitingPool.newPoolable(InstrumentedResourceLimitingPool.java:655) at org.apache.avalon.excalibur.pool.ValidatedResourceLimitingPool.newPoolable(ValidatedResourceLimitingPool.java:145) at org.apache.avalon.excalibur.datasource.ResourceLimitingJdbcConnectionPool.newPoolable(ResourceLimitingJdbcConnectionPool.java:91) at org.apache.avalon.excalibur.pool.InstrumentedResourceLimitingPool.get(InstrumentedResourceLimitingPool.java:371) at org.apache.avalon.excalibur.pool.ValidatedResourceLimitingPool.get(ValidatedResourceLimitingPool.java:97) at org.apache.avalon.excalibur.datasource.ResourceLimitingJdbcDataSource.getConnection(ResourceLimitingJdbcDataSource.java:188) at org.apache.cocoon.ojb.components.ConnectionFactoryImpl.lookupConnection(ConnectionFactoryImpl.java:129) at org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.getConnection(Unknown Source) at org.apache.ojb.broker.accesslayer.StatementManager.getPreparedStatement(Unknown Source) at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(Unknown Source) at org.apache.ojb.broker.accesslayer.RsQueryObject.performQuery(Unknown Source) at org.apache.ojb.broker.accesslayer.RsIterator.init(Unknown Source) at org.apache.ojb.broker.core.RsIteratorFactoryImpl.createRsIterator(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getRsIteratorFromQuery(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getIteratorFromQuery(Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(Unknown Source) at org.apache.cocoon.portal.security.DBSecurityHandler.login(DBSecurityHandler.java:50) 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.apache.avalon.excalibur.component.ComponentProxyGenerator$ComponentInvocationHandler.invoke(ComponentProxyGenerator.java:143) at $Proxy18.login(Unknown Source) at org.osoco.cowarp.impl.StandardApplicationManager.login(StandardApplicationManager.java:193) 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.apache.avalon.excalibur.component.ComponentProxyGenerator$ComponentInvocationHandler.invoke(ComponentProxyGenerator.java:143)
