Re: bulding trunk (again)
Ralph Goers schrieb: I'm trying to build trunk. Every build fails with a timeout but the artifact varies. I recall others having this problem but I don't recall a resolution other than to keep trying. Ralph Try setting a mirror for the repository - i don't have a pointer at hand, but look at the m2 website. This solved those problems for me. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [VOTE] Release 2.1.9
Il giorno 20/feb/06, alle ore 22:11, Ralph Goers ha scritto: The forms block is now marked stable. I believe legal has given the OK for us to use the JCR api. To the best of my recollection I believe those were the only two items standing in the way of a 2.1.9 release. So please vote. +1 Ugo -- Ugo Cei Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Evil or Not?: http://evilornot.info/ Company: http://www.sourcesense.com/
HTMLSerializer problem
Hi, I didn't get any feedback on the user list for this one... I updated my local copy of cocoon 2.1.x and now I'm getting an exception when I serialize with the HTMLSerializer (serializer block), see the relevant part of the stacktrace: [...] Caused by: java.lang.NullPointerException: Required System ID is NULL at org.apache.cocoon.components.serializers.util.DocType.init(DocType.java:76) at org.apache.cocoon.components.serializers.HTMLSerializer.body(HTMLSerializer.java:158) at org.apache.cocoon.components.serializers.EncodingSerializer.startElement(EncodingSerializer.java:459) at org.apache.xml.serializer.ToXMLSAXHandler.closeStartTag(ToXMLSAXHandler.java:204) at org.apache.xml.serializer.ToSAXHandler.flushPending(ToSAXHandler.java:277) at org.apache.xml.serializer.ToXMLSAXHandler.startPrefixMapping(ToXMLSAXHandler.java:348) at org.apache.xalan.templates.ElemElement.constructNode(ElemElement.java:328) at org.apache.xalan.templates.ElemElement.execute(ElemElement.java:288) at org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:393) at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:176) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411) ... 101 more I didn't configure a default doctype for the serializer, so it uses the following one (defined in HTMLSerializer.java): public static final DocType HTML401_DOCTYPE_COMPATIBLE = new SGMLDocType( HTML, -//W3C//DTD HTML 4.01 Transitional//EN, null); The system ID is null, which causes the mentioned problem when the following code is executed (around line 158 in HTMLSerializer.java): this.doctype = new DocType(this.doctype.getName().toUpperCase(), this.doctype.getPublicId(), this.doctype.getSystemId()); When I change new DocType(...) to new SGMLDoctype(...) it works. Here is my configuration of the serializer: map:serializer logger=sitemap.serializer.html mime-type=text/html; charset=utf-8 name=html pool-grow=4 pool-max=32 pool-min=4 src=org.apache.cocoon.components.serializers.HTMLSerializer encodingUTF-8/encoding /map:serializer Is there something wrong with my configuration or is this a bug? Anybody else having this problem? Josias
[jira] Created: (COCOON-1783) Forbid the use of cocoon:// in redirect-to tag in authentication handler configuration
Forbid the use of cocoon:// in redirect-to tag in authentication handler configuration Key: COCOON-1783 URL: http://issues.apache.org/jira/browse/COCOON-1783 Project: Cocoon Type: Improvement Components: Blocks: Authentication Framework Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9-dev (current SVN) Reporter: Philippe Gassmann When cocoon:// is used in the redirect-to tag, the redirect uri then used is computed at the first request using the request.getContextPath() method. (HandlerConfiguration.java line 99) If the first request comes from a PipelineCronJob, the contextPath is null, and until the server is restarted, the authentication framwork can't be used (it redirects to a wrong URI). So, I think that using cocoon:// should be forbidden in that purpose, or it should be used as a real cocoon:// : without a external redirection. -- 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
Re: HTMLSerializer problem
On 21 Feb 2006, at 09:41, Josias Thoeny wrote: Hi, I didn't get any feedback on the user list for this one... I updated my local copy of cocoon 2.1.x and now I'm getting an exception when I serialize with the HTMLSerializer (serializer block), see the relevant part of the stacktrace: [...] Caused by: java.lang.NullPointerException: Required System ID is NULL at org.apache.cocoon.components.serializers.util.DocType.init (DocType.java:76) at org.apache.cocoon.components.serializers.HTMLSerializer.body (HTMLSerializer.java:158) at org.apache.cocoon.components.serializers.EncodingSerializer.startEleme nt(EncodingSerializer.java:459) at org.apache.xml.serializer.ToXMLSAXHandler.closeStartTag (ToXMLSAXHandler.java:204) at org.apache.xml.serializer.ToSAXHandler.flushPending (ToSAXHandler.java:277) at org.apache.xml.serializer.ToXMLSAXHandler.startPrefixMapping (ToXMLSAXHandler.java:348) at org.apache.xalan.templates.ElemElement.constructNode (ElemElement.java:328) at org.apache.xalan.templates.ElemElement.execute(ElemElement.java:288) at org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes (ElemApplyTemplates.java:393) at org.apache.xalan.templates.ElemApplyTemplates.execute (ElemApplyTemplates.java:176) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates (TransformerImpl.java:2411) ... 101 more I didn't configure a default doctype for the serializer, so it uses the following one (defined in HTMLSerializer.java): public static final DocType HTML401_DOCTYPE_COMPATIBLE = new SGMLDocType( HTML, -//W3C//DTD HTML 4.01 Transitional//EN, null); The system ID is null, which causes the mentioned problem when the following code is executed (around line 158 in HTMLSerializer.java): this.doctype = new DocType(this.doctype.getName().toUpperCase(), this.doctype.getPublicId(), this.doctype.getSystemId()); When I change new DocType(...) to new SGMLDoctype(...) it works. Here is my configuration of the serializer: map:serializer logger=sitemap.serializer.html mime-type=text/html; charset=utf-8 name=html pool-grow=4 pool-max=32 pool-min=4 src=org.apache.cocoon.components.serializers.HTMLSerializer encodingUTF-8/encoding /map:serializer Is there something wrong with my configuration or is this a bug? Anybody else having this problem? Ah... That might be something I committed last week, as I was working exactly on doctype behavior... That said, it works on my local host here, so, I'll try to replicate your error... Pier smime.p7s Description: S/MIME cryptographic signature
[jira] Created: (COCOON-1784) Incorrect behavior when using a Tree's on-selection-changed event listener to add and populate new rows in a repeater
Incorrect behavior when using a Tree's on-selection-changed event listener to add and populate new rows in a repeater - Key: COCOON-1784 URL: http://issues.apache.org/jira/browse/COCOON-1784 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.9-dev (current SVN) Reporter: Robin Wyles Attachments: testtree_model.xml, testtree_template.xml, tree_test.js When trying to add and populate new rows in a repeater from a Tree's on-selection-changed event, fields in the new row with a state of 'active' do not reflect their updated values on the form. Attached is a model, template and flow snippet that demonstrates the problem. The template/model can be placed in webapp/samples/blocks/forms/forms and the flow snippet added to forms_flow_example.js. -- 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
Re: questions on store usage
On 2/20/06, David Crossley [EMAIL PROTECTED] wrote: I am answering so as to keep the thread alive, not because i know anything about stores. Would someone who does know, please help Tim. Being a Forrest committer, when we get him over the learning hump, he might be able to help fix various Cocoon issues. Tim Williams wrote: In forrest we've got an input module that currently has it's own simple hashmap-caching. The assumption is that the right thing to do is move away from our homegrown-cache to use the cocoon store (TRANSIENT_STORE). I presume that you are referring to the Locationmap. The Cocoon LinkRewriterTransformer has a similar issue http://issues.apache.org/jira/browse/COCOON-1574 Memory Leak with XMLFileModule It has comments about needing to use the Cocoon cache. Perhaps Ralph and Jörg can help. In doing this, I've got some potentially dumb questions. Nothing is dumb. Is the store somehow magically isolated or is it a global environment thing? In other words do I need to prefix my keys with the input module name to attempt to attain uniqueness? See a Cocoon status page and the Key id for various keys in the current caches. Yes it needs to be unique. http://cocoon.zones.apache.org/demos/release/samples/ There are docs at CacheableProcessingComponent Contracts http://cocoon.zones.apache.org/daisy/documentation/writing/corecontracts/675.html Performance Tips http://cocoon.apache.org/2.1/performancetips.html ... has some about the keys. Do I need to do anything on dispose() to explicitly clean out my stored items or assume it'll push them out if it needs to? The store mechanism will take care of itself according to our configuration. At Forrest we ae just using the default config provided by Cocoon. Perhaps we need to tweak that. Here is a reading list, in case you had missed some :-) Not sure how up-to-date any of it is. Also Forrest is using Cocoon-2.2 (prior to Mavenisation) so will be different. Writing Cache Efficient Components http://cocoon.zones.apache.org/daisy/documentation/writing/690.html Cocoon Source Resolving - Store Components http://cocoon.apache.org/2.1/developing/stores.html Caching http://cocoon.apache.org/2.1/userdocs/concepts/caching.html StoreJanitor http://cocoon.apache.org/2.1/userdocs/concepts/storejanitor.html -David Thanks David, After getting a little further, I have come to understand that the default transient store (MRUMemoryStore) can't handle null values[1] which we need for caching locationmap entries. The only answer so far (thanks Ralph) has been to create our own store. Since all our input module needs to cache is simple strings, I don't, at this point, think it's worth creating a custom store for forrest. --tim [1] - http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113995314926899w=2
[jira] Commented: (COCOON-1758) Form locale never used in JXMacros
[
http://issues.apache.org/jira/browse/COCOON-1758?page=comments#action_12367199
]
Philippe Gassmann commented on COCOON-1758:
---
Your patch does not solve the problem ; I think the management of locale in
forms has to be deeply refactored
Form locale never used in JXMacros
--
Key: COCOON-1758
URL: http://issues.apache.org/jira/browse/COCOON-1758
Project: Cocoon
Type: Bug
Components: Blocks: Forms
Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9-dev (current SVN)
Reporter: Philippe Gassmann
Assignee: Jean-Baptiste Quenot
Attachments: 20060201-cocoon-forms-1758
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_12367201
]
Philippe Gassmann commented on COCOON-1758:
---
I will try to provide a patch ASAP.
Form locale never used in JXMacros
--
Key: COCOON-1758
URL: http://issues.apache.org/jira/browse/COCOON-1758
Project: Cocoon
Type: Bug
Components: Blocks: Forms
Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9-dev (current SVN)
Reporter: Philippe Gassmann
Assignee: Jean-Baptiste Quenot
Attachments: 20060201-cocoon-forms-1758
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-1659) Finish the sitemap internals document in Daisy
[ http://issues.apache.org/jira/browse/COCOON-1659?page=comments#action_12367215 ] Helma van der Linden commented on COCOON-1659: -- Text is adjusted and images are redrawn. Feedback of the experts is wanted! Finish the sitemap internals document in Daisy -- Key: COCOON-1659 URL: http://issues.apache.org/jira/browse/COCOON-1659 Project: Cocoon Type: Task Components: - Documentation Versions: 2.2-dev (Current SVN) Reporter: Helma van der Linden Assignee: Helma van der Linden Priority: Minor Text and images of the description of the sitemap processing should be enhanced and reviewed. http://cocoon.zones.apache.org/daisy/documentation/732.html - integrate related wiki pages: http://wiki.apache.org/cocoon/InterpretedSitemapInternals http://wiki.apache.org/cocoon/GT2005HackatonDay1Notes - Review of the content by sitemap experts (Sylvain?) - Create better images (see also pages on wiki page) - add links to appropriate classes into apidocs -- 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-1780) [PATCH] Upload Widget : Can not change selected file
[
http://issues.apache.org/jira/browse/COCOON-1780?page=comments#action_12367218
]
Bruno Dumon commented on COCOON-1780:
-
Hmm,
I have exactly the same problem and the patch suggested above, changing button
to submit, solves it.
How is the provided link to
http://svn.apache.org/viewcvs.cgi?rev=376238view=rev related?
[PATCH] Upload Widget : Can not change selected file
Key: COCOON-1780
URL: http://issues.apache.org/jira/browse/COCOON-1780
Project: Cocoon
Type: Bug
Components: Blocks: Forms
Versions: 2.2-dev (Current SVN), 2.1.9-dev (current SVN)
Reporter: vincent Demay
Assignee: Jean-Baptiste Quenot
When a file is selected with the upload widget and a on-value-change event is
fired, the value of the widget can not be changed by user.
here is the patch
Index:
/cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
===
---
/cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
(revision 377974)
+++
/cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
(working copy)
@@ -486,7 +486,7 @@
xsl:text[/xsl:text
xsl:value-of select=fi:value/
xsl:text] /xsl:text
-input type=button id=[EMAIL PROTECTED]:input name=[EMAIL
PROTECTED] value=... onclick=forms_submitForm(this)/
+ input type=submit id=[EMAIL PROTECTED]:input name=[EMAIL
PROTECTED] value=... onclick=forms_submitForm(this)/
/xsl:when
xsl:otherwise
input type=file id=[EMAIL PROTECTED]:input name=[EMAIL
PROTECTED] title={fi:hint} accept=[EMAIL PROTECTED]
--
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-1780) [PATCH] Upload Widget : Can not change selected file
[
http://issues.apache.org/jira/browse/COCOON-1780?page=comments#action_12367248
]
Bruno Dumon commented on COCOON-1780:
-
I just committed a patch.
The cause of the problem is that the submitWidget is now assigned after the
readFromRequest processing. Fixed it in the same way as for the other widgets
(such as Action).
[PATCH] Upload Widget : Can not change selected file
Key: COCOON-1780
URL: http://issues.apache.org/jira/browse/COCOON-1780
Project: Cocoon
Type: Bug
Components: Blocks: Forms
Versions: 2.2-dev (Current SVN), 2.1.9-dev (current SVN)
Reporter: vincent Demay
Assignee: Jean-Baptiste Quenot
When a file is selected with the upload widget and a on-value-change event is
fired, the value of the widget can not be changed by user.
here is the patch
Index:
/cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
===
---
/cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
(revision 377974)
+++
/cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
(working copy)
@@ -486,7 +486,7 @@
xsl:text[/xsl:text
xsl:value-of select=fi:value/
xsl:text] /xsl:text
-input type=button id=[EMAIL PROTECTED]:input name=[EMAIL
PROTECTED] value=... onclick=forms_submitForm(this)/
+ input type=submit id=[EMAIL PROTECTED]:input name=[EMAIL
PROTECTED] value=... onclick=forms_submitForm(this)/
/xsl:when
xsl:otherwise
input type=file id=[EMAIL PROTECTED]:input name=[EMAIL
PROTECTED] title={fi:hint} accept=[EMAIL PROTECTED]
--
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-1780) [PATCH] Upload Widget : Can not change selected file
[ http://issues.apache.org/jira/browse/COCOON-1780?page=all ]
Bruno Dumon closed COCOON-1780:
---
Fix Version: 2.1.9-dev (current SVN)
Resolution: Fixed
[PATCH] Upload Widget : Can not change selected file
Key: COCOON-1780
URL: http://issues.apache.org/jira/browse/COCOON-1780
Project: Cocoon
Type: Bug
Components: Blocks: Forms
Versions: 2.2-dev (Current SVN), 2.1.9-dev (current SVN)
Reporter: vincent Demay
Assignee: Jean-Baptiste Quenot
Fix For: 2.1.9-dev (current SVN)
When a file is selected with the upload widget and a on-value-change event is
fired, the value of the widget can not be changed by user.
here is the patch
Index:
/cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
===
---
/cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
(revision 377974)
+++
/cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
(working copy)
@@ -486,7 +486,7 @@
xsl:text[/xsl:text
xsl:value-of select=fi:value/
xsl:text] /xsl:text
-input type=button id=[EMAIL PROTECTED]:input name=[EMAIL
PROTECTED] value=... onclick=forms_submitForm(this)/
+ input type=submit id=[EMAIL PROTECTED]:input name=[EMAIL
PROTECTED] value=... onclick=forms_submitForm(this)/
/xsl:when
xsl:otherwise
input type=file id=[EMAIL PROTECTED]:input name=[EMAIL
PROTECTED] title={fi:hint} accept=[EMAIL PROTECTED]
--
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
Re: svn commit: r379568 - in /cocoon/trunk/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/binding: JXPathBindingBase.java JXPathBindingBuilderBase.java
On 21.02.2006 21:08, [EMAIL PROTECTED] wrote: Author: bruno Date: Tue Feb 21 12:08:20 2006 New Revision: 379568 URL: http://svn.apache.org/viewcvs?rev=379568view=rev Log: Thought I committed this two weeks ago, must not have paid enough attention :-/ Nobody paid enough attention to your commit: http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=113956765013652w=4 See the list of committed files ;) Jörg
Re: [VOTE] Release 2.1.9
The Form Block now in trunk seems has problems because the change of ajax block. And does the new jxtemplate generator implement? If Form block works fine ,+1 Roy Huang
