[jira] Commented: (COCOON-1928) Add the ability to pass the doctype in parameter for Serializer
[ http://issues.apache.org/jira/browse/COCOON-1928?page=comments#action_12441642 ] Cyriaque Dupoirieux commented on COCOON-1928: - David, I am going to try the solution of Jörg with entities. I think it can be the solution and it's really pretty nice. When my test is good, I will close the problem. 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-1881) Xinclude transformer has changed behaviour with Saxon 8.7.1
[ http://issues.apache.org/jira/browse/COCOON-1881?page=all ] Jörg Heinicke updated COCOON-1881: -- Component/s: - Components: Sitemap (was: Blocks: (Undefined)) Xinclude transformer has changed behaviour with Saxon 8.7.1 --- Key: COCOON-1881 URL: http://issues.apache.org/jira/browse/COCOON-1881 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.1.8, 2.1.10-dev (current SVN) Reporter: Philip Fennell Attachments: xinclude.tar.gz With Windows XP sp2, Cocoon 2.1.8, Tomcat 5.5 and Saxon 8.6.1 or 8.7 configured as the default XSLT transformer I was able to embed xi:include instructions within source documents and have Cocoon's Xinclude processor resolve the URL (relative to the source document) correctly. e.g. xi:include href=../../content/resources/site/login.xml xi:fallbacklogin.xml not included./xi:fallback /xi:include However, when I moved to Saxon 8.7.1 (and also with 8.7.3) the xinclude fails to locate the referenced file unless I change the href attribute so that the url is relative to the current Cocoon context. e.g. xi:include href=content/resources/site/login.xml xi:fallbacklogin.xml not included./xi:fallback /xi:include Important Note: === It is important to understand that I am 'NOT' using Cocoon to process the requested document but rather to process the request (by using Cocoon's request generator) information itself, which includes a refernece to the original requested document. The request info is transformed into an 'envelope' containing the request parameters, HTTP header info and an interface definition file that may contain xi:include instructions that reference additional static content. It is these xi:include instructions that are at the centre of the problem. The example is in: xinclude/interface/config/login.xml The Cocoon pipeline match that does all the work can be found starting at line 182 of sitemap.xmap. During the processing, the requested content and referenced content merged and transformed into XHTML within the main rendering transform: xinclude/interface/transforms/xhtml/screen.xsl === To run the test webapp that I have attached you will need to set-up Cocoon as follows: 1) Add the following lines to cocoon/WEB-INF/cocoon.xconf: component logger=core.xslt-processor role=org.apache.excalibur.xml.xslt.XSLTProcessor/saxon class=org.apache.excalibur.xml.xslt.XSLTProcessorImpl parameter name=use-store value=true/ parameter name=incremental-processing value=false/ parameter name=transformer-factory value=net.sf.saxon.TransformerFactoryImpl/ /component after the Xalan component declaration. 2) Get Saxon 8.7 and 8.7.3 from http://www.saxonica.com/ and place the following jars in cocoon/WEB-INF/lib saxon8.jar saxon8-dom.jar saxon8-xpath.jar 3) Unpack the attached ZIP file (xinclude.zip) in your cocoon directory 4) Use the following link to access the test page: http://localhost:8080/cocoon/xinclude/interface/config/login.html (Depending on host and port number etc you may need to tweak this url.) -- 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-1345) [PATCH] Extract convertors into their own block
[ http://issues.apache.org/jira/browse/COCOON-1345?page=all ] Jörg Heinicke updated COCOON-1345: -- Bugzilla Id: (was: 32223) Component/s: Blocks: Forms (was: Blocks: (Undefined)) Summary: [PATCH] Extract convertors into their own block (was: [PATCH] Suggestion for a conversion block) Description: This patch is an attempt at creating a conversion block similar to what Daniel Fagerström has discussed (http://www.mail-archive.com/dev@cocoon.apache.org/msg24163.html) The conversion block can live by itself but the patch also includes changes to CForm so that it can use the convertors from the conversion block. Currently there are only two convertors implemented (DefaultDateConvertor and CustomDateConvertor). To test it out apply both patches start your servlet and then surf to: http://localhost:/samples/blocks/forms/conversion/ was: This patch is an attempt at creating a conversion block similar to what Daniel Fagerström has discussed (http://www.mail-archive.com/dev@cocoon.apache.org/msg24163.html) The conversion block can live by itself but the patch also includes changes to CForm so that it can use the convertors from the conversion block. Currently there are only two convertors implemented (DefaultDateConvertor and CustomDateConvertor). To test it out apply both patches start your servlet and then surf to: http://localhost:/samples/blocks/forms/conversion/ [PATCH] Extract convertors into their own block --- Key: COCOON-1345 URL: http://issues.apache.org/jira/browse/COCOON-1345 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Jonas Ekstedt Assigned To: Cocoon Developers Team Priority: Minor Attachments: conversion-block.patch This patch is an attempt at creating a conversion block similar to what Daniel Fagerström has discussed (http://www.mail-archive.com/dev@cocoon.apache.org/msg24163.html) The conversion block can live by itself but the patch also includes changes to CForm so that it can use the convertors from the conversion block. Currently there are only two convertors implemented (DefaultDateConvertor and CustomDateConvertor). To test it out apply both patches start your servlet and then surf to: http://localhost:/samples/blocks/forms/conversion/ -- 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) Ajax errror when an active state widget become invisible state widget
[ http://issues.apache.org/jira/browse/COCOON-1825?page=all ]
Jörg Heinicke updated COCOON-1825:
--
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);
}
+contentHandler.endElement(FormsConstants.INSTANCE_NS, placeholder,
FormsConstants.INSTANCE_PREFIX_COLON + placeholder);
}
public Object getAttribute(String name) {
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
[jira] Updated: (COCOON-1664) Jaas based Authenticator
[ http://issues.apache.org/jira/browse/COCOON-1664?page=all ] Jörg Heinicke updated COCOON-1664: -- Jaas based Authenticator Key: COCOON-1664 URL: http://issues.apache.org/jira/browse/COCOON-1664 Project: Cocoon Issue Type: Improvement Components: Blocks: Authentication Framework Reporter: Ryan Slack Assigned To: Cocoon Developers Team Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: JaasAuthenticator.java It was not particularly hard, but I wrote, and have somewhat tested, a Jaas implmentation of Authenticator. It should also be possable to utilize Java's security as an alternate to the current authentication Actions. This implementation has the CallbackHandler in the same class as the Authenticator, however that isn't really required. Also, I will be looking at using the Cocoon configuration system, instead of the default jaas config 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
[jira] Closed: (COCOON-1664) Jaas based Authenticator
[ http://issues.apache.org/jira/browse/COCOON-1664?page=all ] Jörg Heinicke closed COCOON-1664. - Fix Version/s: 2.2-dev (Current SVN) Resolution: Won't Fix As explained by Carsten JAAS is already integrated in 2.2 auth-fw block. Jaas based Authenticator Key: COCOON-1664 URL: http://issues.apache.org/jira/browse/COCOON-1664 Project: Cocoon Issue Type: Improvement Components: Blocks: Authentication Framework Reporter: Ryan Slack Assigned To: Cocoon Developers Team Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: JaasAuthenticator.java It was not particularly hard, but I wrote, and have somewhat tested, a Jaas implmentation of Authenticator. It should also be possable to utilize Java's security as an alternate to the current authentication Actions. This implementation has the CallbackHandler in the same class as the Authenticator, however that isn't really required. Also, I will be looking at using the Cocoon configuration system, instead of the default jaas config 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
[jira] Updated: (COCOON-1655) JavaFlow/CForm/select-list crash
[ http://issues.apache.org/jira/browse/COCOON-1655?page=all ]
Jörg Heinicke updated COCOON-1655:
--
JavaFlow/CForm/select-list crash
Key: COCOON-1655
URL: http://issues.apache.org/jira/browse/COCOON-1655
Project: Cocoon
Issue Type: Bug
Components: Blocks: Java Flow
Affects Versions: 2.1.7
Environment: Operating System: other
Platform: Other
Reporter: Benoit Deshaies
Assigned To: Cocoon Developers Team
Attachments: javaflow-continuationstack.diff
I get an error whenever I include an fd:selection-list src=cocoon:/XYZ
where
both the form and the XYZ pipeline use JavaFlow. The error is:
No continuation is running
cause: java.lang.IllegalStateException: No continuation is running
java.lang.IllegalStateException: No continuation is running
at
org.apache.cocoon.components.flow.java.Continuation.suspend(Continuation.java:79)
at
org.apache.cocoon.components.flow.java.AbstractContinuable.sendPageAndWait(AbstractContinuable.java:75)
at
org.apache.cocoon.forms.flow.java.FormInstance.show(FormInstance.java:181)
The reason is that when cocoon:/XYZ runs, a continuation is created for the
same
thread as the form continuation. The continuationsmap in Continuation class
gets
overwritten. When cocoon:/XYZ returns, the map is cleared for the thread,
leaving no continuation for the form.
Here's a bit of code from the app to help explain.
The form contains a selection list defined as:
fd:field id=user
fd:datatype base=string/
fd:selection-list src=cocoon:/UserSelectList dynamic=true/
/fd:field
The sitemap contains:
map:match pattern=UserSelectList
map:call function=generateUserList/
/map:match
Then I have the following JavaFlow
public void doGenerateUserList() throws Exception {
Collection userList = databaseManager.getUserList();
sendPage(user_list, new VarMap().add(list, userList) );
}
--
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-1570) fi:validation-errors styling element does not work in AJAX mode
[ http://issues.apache.org/jira/browse/COCOON-1570?page=all ] Jörg Heinicke updated COCOON-1570: -- fi:validation-errors styling element does not work in AJAX mode --- Key: COCOON-1570 URL: http://issues.apache.org/jira/browse/COCOON-1570 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: Jason Johnston The fi:validation-errors/ styling element does not work in AJAX mode, because it is not generated by a template element and therefore has no way to signal whether or not it needs to be updated. An equivalent template ft: element should be created to replace the current fi: element, which creates its own instance representation with the optional bu:replace wrapper when necessary. See the following threads for discussion: http://marc.theaimsgroup.com/?t=11229292151r=1w=2 http://marc.theaimsgroup.com/?t=11229747071r=1w=2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1564) [html block] HTMLGenerator doesn't copy POST parameters
[ http://issues.apache.org/jira/browse/COCOON-1564?page=all ] Jörg Heinicke updated COCOON-1564: -- [html block] HTMLGenerator doesn't copy POST parameters --- Key: COCOON-1564 URL: http://issues.apache.org/jira/browse/COCOON-1564 Project: Cocoon Issue Type: Bug Components: Blocks: HTML Affects Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: Andreas Hartmann Assigned To: Cocoon Developers Team On a POST request, request parameters are not copied. -- 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-1549) [PATCH] Batik Rhino support incompatible with Cocoon's
[ http://issues.apache.org/jira/browse/COCOON-1549?page=all ] Jörg Heinicke updated COCOON-1549: -- [PATCH] Batik Rhino support incompatible with Cocoon's -- Key: COCOON-1549 URL: http://issues.apache.org/jira/browse/COCOON-1549 Project: Cocoon Issue Type: Bug Components: Blocks: Batik Affects Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: Jean-Baptiste Quenot Attachments: bbox.xml, patch-rhinointerpreter A bug has been filed at Batik, but nobody has replied yet: http://issues.apache.org/bugzilla/show_bug.cgi?id=35233 The need is to use Batik's Rhino support for adding JavaScript to SVG. The problem is that Batik's RhinoInterpreter sets a custom security domain incompatible with Rhino context from Cocoon's FlowScript which doesn't set one. The idea is to remove Batik's Rhino security controller to ensure proper interoperability between Cocoon and Batik. -- 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: Re: new avalon/excalibur test release
Joerg Heinicke wrote: Yes, that should be the way to go. Furthermore (if it is possible) you should add a dependency on the xmlutil issue to the Cocoon issue, so that we get informed when xmlutil is fixed. Yes that sounds about right to me. Create the ticket and I'll see to it that it gets applied. OTOH, if you feel confident enough about the patch you can commit it directly yourself, all Cocoon committers have write access to excalibur/avalon svn. I am pretty confindent about the patch, but I have some problems getting my password resetted (long story..), so I cannot write yet...Anyway, I will create the issue in excalibur, try to set a dependency on the Cocoon issue, add a patch and hopefully see it ending up in cocoon. Regards Ard Cheers Jorg
[jira] Closed: (COCOON-1372) [PATCH] SmbAuthAction
[ http://issues.apache.org/jira/browse/COCOON-1372?page=all ] Jörg Heinicke closed COCOON-1372. - Resolution: Won't Fix As Antonio explained it has an incompatible license. [PATCH] SmbAuthAction - Key: COCOON-1372 URL: http://issues.apache.org/jira/browse/COCOON-1372 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Environment: Operating System: Windows XP Platform: PC Reporter: Eric Jacob Assigned To: Cocoon Developers Team Priority: Minor Attachments: SmbAuthAction.java Authenticates arbitrary user credentials against an NT domain based on the a href=http://jcifs.samba.org/;The Java CIFS Client Library (jCIFS)/a project. -- 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-1194) FormsTransformer causes NPE
[ http://issues.apache.org/jira/browse/COCOON-1194?page=all ] Jörg Heinicke closed COCOON-1194. - Resolution: Cannot Reproduce Assignee: (was: Colin Adams) No reaction since 2 years, so closing the issue. Feel free to reopen it if it still applies. FormsTransformer causes NPE --- Key: COCOON-1194 URL: http://issues.apache.org/jira/browse/COCOON-1194 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.5 Environment: Operating System: Linux Platform: PC Reporter: Colin Adams Attachments: edit-events-template.xml, edit-events-template.xml, event-binding.xml, event-form.xml Trying to transform a form cause a message org.apache.cocoon.ProcessingException: Failed to execute pipeline.: java.lang.NullPointerException The message occurs when attempting to porcess the SAX stream coming out of the FormsTransformer - for instance, with the serializer. Inserting a LogTransformer between the FormsTransformer and the serializer (XHTML 1.1) reveals that the last SAX event was: [startPrefixMapping] prefix=null,uri=null -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1918) [PATCH] Strip out spurious whitespace or block characters in browser tooltips/help bubbles
[ http://issues.apache.org/jira/browse/COCOON-1918?page=all ] Jean-Baptiste Quenot updated COCOON-1918: - Summary: [PATCH] Strip out spurious whitespace or block characters in browser tooltips/help bubbles (was: unwanted whitespace or block characters in browser tooltips/help bubbles) [PATCH] Strip out spurious whitespace or block characters in browser tooltips/help bubbles Key: COCOON-1918 URL: http://issues.apache.org/jira/browse/COCOON-1918 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: Guillaume Déflache Priority: Minor Attachments: AbstractWidgetDefinitionBuilder.java.patch Problem : almost all tooltips contain extra characters around the text provided in the fd:hint element : with IE, they are always rendered as whitespace, with Firefox, some (tabs IIRC) appear as block characters. These originate from the whitespace used for formatting the form definition files. -- 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-1909) Cache validity of XSLT stylesheets does not reflect included or imported stylesheets.
[ http://issues.apache.org/jira/browse/COCOON-1909?page=comments#action_12441677 ] Ard Schrijvers commented on COCOON-1909: The bug is in XSLTProcessorImpl in public javax.xml.transform.Source resolve( String href, String base ), at List includes = (List)m_includesMap.get( base );. The problem lies in the base, because the base is related to the stylesheet calling the import, so, if it is an import calling an import, the base is different from the main stylesheet, therefor not adding its validity to the main stylesheet aggregated validity. I added a global m_id of the main stylesheet that is now used in XSLTProcessorImpl, and replace base in List includes = (List)m_includesMap.get( base ) by List includes = (List)m_includesMap.get( m_id );. This solves the invalidation of main stylesheets. The bug is solved when a new xmlutil jar is included in cocoon Cache validity of XSLT stylesheets does not reflect included or imported stylesheets. - Key: COCOON-1909 URL: http://issues.apache.org/jira/browse/COCOON-1909 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.1.9 Reporter: Conal Tuohy XSLT stylesheets which either import or include other stylesheets are cached too aggressively: if you change an imported or included stylesheet the change does not take effect until you update the main stylesheet. This bug is supposed to have been fixed years ago, but it still doesn't work for us. -- 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: Closing JIRA issues
On 10/11/06, Antonio Gallardo [EMAIL PROTECTED] wrote: ...IMHO, we should leave open this bug, because the fixi is not finished yet until we update excalibur... Same here. If update excalibur is a Jira or bugzilla issue somewhere, I'd make a link or a dependency to it to indicate what's happening. I am still a bit confused: I now have http://issues.apache.org/jira/browse/COCOON-1909, and added comment that it has been fixed, and needs a excalibur-xmlutil update. In excalibur-components, I created http://issues.apache.org/jira/browse/EXLBR-31 and added the patch file. Can I create some sort of dependency between the to, or do I need to make a cocoon JIRA issue that says update excalibur jars, and somehow relate http://issues.apache.org/jira/browse/COCOON-1909 to it (in principal, then when the update jira issue is closed, the 1909 should also be closed) Sry for the perhaps trivial questions, but I am just not (yet) familiar enough about the methodolies Ard -Bertrand
[jira] Updated: (COCOON-1932) [PATCH] correct styling of disabled suggestion lists
[ http://issues.apache.org/jira/browse/COCOON-1932?page=all ] Guillaume Déflache updated COCOON-1932: --- Attachment: forms-advanced-field-styling_disabled_suggestion_list.patch Patch against Cocoon 2.1.9's forms-advanced-field-styling.xsl: should apply to HEAD version as is (sorry, could not check...) [PATCH] correct styling of disabled suggestion lists Key: COCOON-1932 URL: http://issues.apache.org/jira/browse/COCOON-1932 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: Guillaume Déflache Attachments: forms-advanced-field-styling_disabled_suggestion_list.patch Styling of disabled suggestion lists is currently incorrect: sorry, I cannot remember the exact rendering issues (I corrected that long ago), but as it motivated a change on our project, I guess it is at least ugly, at most non functional. Feel free to change the issue type to enhancement if appropriate. However the following patch styles suggestion lists as HTML select elements with only one option element corresponding to the widget value. This was tested against Cocoon 2.1.9 release (with many other pending patches...). -- 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: environment abstraction in Cocoon 2.2
Carsten Ziegeler wrote: Vadim Gritsenko wrote ... we can, though, introduce new behavior for new cocoon: scoped attributes. (Similarly, there is special processing going on for cocoon: prefixed request parameters). You mean adding special handling for example for all request attributes using org.apache.cocoon. as the prefix for their name? Yep Vadim
Re: Closing JIRA issues
Ard Schrijvers a.schrijvers at hippo.nl writes: Can I create some sort of dependency between the to, or do I need to make a cocoon JIRA issue that says update excalibur jars, and somehow relate http://issues.apache.org/jira/browse/COCOON-1909 to it (in principal, then when the update jira issue is closed, the 1909 should also be closed) COCOON-1909 should be directly linked to EXLBR-31 (I already did it). It should be available in the list of possible actions (menu on the left), otherwise you do not have the appropriate rights. Jörg
Re: Closing JIRA issues
Bertrand Delacretaz wrote: On 10/12/06, David Crossley [EMAIL PROTECTED] wrote: ...Closing issues prematurely is disrespectful... Agreed, with prematurely as the key aspect. I must admit I haven't looked at the particular issue being discussed, I was thinking in general terms: if an issue has been sitting here for several years, we've asked for feedback or additional info and nothing comes, I think it's fair to set it to won't fix. Only if feedback means stacktrace or any other essential information original submitter failed to furnish, then yes, such issue can be closed. But if feedback means please send in a patch... That's a different story. Not everybody can do a decent patch. Vadim
Re: Closing JIRA issues
On 10/12/06, Vadim Gritsenko [EMAIL PROTECTED] wrote: ...Only if feedback means stacktrace or any other essential information original submitter failed to furnish, then yes, such issue can be closed... But if feedback means please send in a patch... That's a different story. Not everybody can do a decent patch... 100% agreed! -Bertrand
[jira] Created: (COCOON-1933) [Patch] Automatic loading of flow scripts in flow/ must not load directories
[Patch] Automatic loading of flow scripts in flow/ must not load directories -- Key: COCOON-1933 URL: http://issues.apache.org/jira/browse/COCOON-1933 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Alexander Klimetschek Attachments: cocoon-flow-only-files.patch The automatic loading of everything inside flow/ also tries to load directories, which cannot be compiled like files. Happens typically when you have a subversion directory (.svn) or other version-control directory inside. The stacktrace for the problem: Caused by: org.apache.excalibur.source.SourceNotFoundException: file:/Users/alex/Mindquarry/hack/mindquarry-teamspace-web/mindquarry-teamspace-block/src/main/resources/COB-INF/flow/.svn/ doesn't exist. at org.apache.excalibur.source.impl.FileSource.getInputStream(FileSource.java:150) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.compileScript(FOM_JavaScriptInterpreter.java:502) at org.apache.cocoon.components.flow.CompilingInterpreter$ScriptSourceEntry.getScript(CompilingInterpreter.java:112) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.setupContext(FOM_JavaScriptInterpreter.java:453) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.callFunction(FOM_JavaScriptInterpreter.java:572) at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:109) ... 43 more Caused by: java.io.FileNotFoundException: /Users/alex/Mindquarry/hack/mindquarry-teamspace-web/mindquarry-teamspace-block/src/main/resources/COB-INF/flow/.svn (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:106) at org.apache.excalibur.source.impl.FileSource.getInputStream(FileSource.java:146) ... 48 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-1933) [Patch] Automatic loading of flow scripts in flow/ must not load directories
[ http://issues.apache.org/jira/browse/COCOON-1933?page=all ] Alexander Klimetschek updated COCOON-1933: -- Attachment: cocoon-flow-only-files.patch This patches makes the FlowNodeBuilder only load files directly under flow/. [Patch] Automatic loading of flow scripts in flow/ must not load directories -- Key: COCOON-1933 URL: http://issues.apache.org/jira/browse/COCOON-1933 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Alexander Klimetschek Attachments: cocoon-flow-only-files.patch The automatic loading of everything inside flow/ also tries to load directories, which cannot be compiled like files. Happens typically when you have a subversion directory (.svn) or other version-control directory inside. The stacktrace for the problem: Caused by: org.apache.excalibur.source.SourceNotFoundException: file:/Users/alex/Mindquarry/hack/mindquarry-teamspace-web/mindquarry-teamspace-block/src/main/resources/COB-INF/flow/.svn/ doesn't exist. at org.apache.excalibur.source.impl.FileSource.getInputStream(FileSource.java:150) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.compileScript(FOM_JavaScriptInterpreter.java:502) at org.apache.cocoon.components.flow.CompilingInterpreter$ScriptSourceEntry.getScript(CompilingInterpreter.java:112) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.setupContext(FOM_JavaScriptInterpreter.java:453) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.callFunction(FOM_JavaScriptInterpreter.java:572) at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:109) ... 43 more Caused by: java.io.FileNotFoundException: /Users/alex/Mindquarry/hack/mindquarry-teamspace-web/mindquarry-teamspace-block/src/main/resources/COB-INF/flow/.svn (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:106) at org.apache.excalibur.source.impl.FileSource.getInputStream(FileSource.java:146) ... 48 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
Re: [RT] Simplify flow usage
Created a jira issue including a patch that only takes files directly under flow/ into account. http://issues.apache.org/jira/browse/COCOON-1933 Alex Alexander Klimetschek schrieb: I just run into a problem with the automatic loading of all files inside flow/: if there is a subversion directory (.svn) inside, it will try to call getInputStream() on it, which will fail on a directory. So the problem is very general: you probably want to traverse sub-directories in order to let users structure their flow-directory. But how do you know that you have one of those hidden directories of a version control system (.svn, CVS,). The . for hidden dirs is not an exclusion criteria, because CVS doesn't use it. IMHO the conclusion is that there are two cases: a) skip traversing of sub-directories (simple) b) write some magic code that is able to skip any special/hidden directory I could quickly provide a patch for a). So what do you think? Alexander Klimetschek (Mindquarry) The stacktrace: Caused by: org.apache.excalibur.source.SourceNotFoundException: file:/Users/alex/Mindquarry/hack/mindquarry-teamspace-web/mindquarry-teamspace-block/src/main/resources/COB-INF/flow/.svn/ doesn't exist. at org.apache.excalibur.source.impl.FileSource.getInputStream(FileSource.java:150) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.compileScript(FOM_JavaScriptInterpreter.java:502) at org.apache.cocoon.components.flow.CompilingInterpreter$ScriptSourceEntry.getScript(CompilingInterpreter.java:112) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.setupContext(FOM_JavaScriptInterpreter.java:453) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.callFunction(FOM_JavaScriptInterpreter.java:572) at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:109) ... 43 more Caused by: java.io.FileNotFoundException: /Users/alex/Mindquarry/hack/mindquarry-teamspace-web/mindquarry-teamspace-block/src/main/resources/COB-INF/flow/.svn (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:106) at org.apache.excalibur.source.impl.FileSource.getInputStream(FileSource.java:146) ... 48 more Carsten Ziegeler wrote: I now implemented this convention stuff - all files located in the flow directory relative to the current sitemap are added to the flow interpreter - regardless of the file name suffix and the used interpreter (javascript, javaflow etc). The directory is of course optional. By this we show a best practice of how to use flow - if for any reason the user wants to use a different location, it's possible by specifying the location attribute on the flow node. I think we should leave the other convention directories for spring and avalon configurations and the properties inside the config directory for now. Carsten
[jira] Commented: (COCOON-1933) [Patch] Automatic loading of flow scripts in flow/ must not load directories
[ http://issues.apache.org/jira/browse/COCOON-1933?page=comments#action_12441768 ] Alexander Klimetschek commented on COCOON-1933: --- Good question. I don' t know the spring Resource abstraction apart from looking at the interface methods. The problem is also that the available resources are fetched via Spring, but the input stream is finally resolved via the Excalibur SourceResolver. AFAIK they don't match. That's why an ugly solution like calling Resource.getInputStream() and catching exceptions won't work because the real input stream is fetched from the Source in the end. And that would probably use too much resources at the early read-in phase!? What kind of resources must be supported apart from file systems, jars or wars? Will directories under flow/ be deployed into a war? [Patch] Automatic loading of flow scripts in flow/ must not load directories -- Key: COCOON-1933 URL: http://issues.apache.org/jira/browse/COCOON-1933 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Alexander Klimetschek Attachments: cocoon-flow-only-files.patch The automatic loading of everything inside flow/ also tries to load directories, which cannot be compiled like files. Happens typically when you have a subversion directory (.svn) or other version-control directory inside. The stacktrace for the problem: Caused by: org.apache.excalibur.source.SourceNotFoundException: file:/Users/alex/Mindquarry/hack/mindquarry-teamspace-web/mindquarry-teamspace-block/src/main/resources/COB-INF/flow/.svn/ doesn't exist. at org.apache.excalibur.source.impl.FileSource.getInputStream(FileSource.java:150) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.compileScript(FOM_JavaScriptInterpreter.java:502) at org.apache.cocoon.components.flow.CompilingInterpreter$ScriptSourceEntry.getScript(CompilingInterpreter.java:112) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.setupContext(FOM_JavaScriptInterpreter.java:453) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.callFunction(FOM_JavaScriptInterpreter.java:572) at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:109) ... 43 more Caused by: java.io.FileNotFoundException: /Users/alex/Mindquarry/hack/mindquarry-teamspace-web/mindquarry-teamspace-block/src/main/resources/COB-INF/flow/.svn (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:106) at org.apache.excalibur.source.impl.FileSource.getInputStream(FileSource.java:146) ... 48 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] Commented: (COCOON-1933) [Patch] Automatic loading of flow scripts in flow/ must not load directories
[ http://issues.apache.org/jira/browse/COCOON-1933?page=comments#action_12441770 ] Carsten Ziegeler commented on COCOON-1933: -- All the contents of a block or an application can be served directly from within a jar or war. So we have to support at least the file system, jar/war and classpath. I just looked into the spring code and getFile() is only support if the resource is really a file. A simple solution could be if we would just include all files according to a pattern like *.js etc. But of course the file ending whould depend on the used interpreter and it is no guarantee that there isn't a directory hello.js in the flow directory. So I think we have to find another solution :( [Patch] Automatic loading of flow scripts in flow/ must not load directories -- Key: COCOON-1933 URL: http://issues.apache.org/jira/browse/COCOON-1933 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Alexander Klimetschek Attachments: cocoon-flow-only-files.patch The automatic loading of everything inside flow/ also tries to load directories, which cannot be compiled like files. Happens typically when you have a subversion directory (.svn) or other version-control directory inside. The stacktrace for the problem: Caused by: org.apache.excalibur.source.SourceNotFoundException: file:/Users/alex/Mindquarry/hack/mindquarry-teamspace-web/mindquarry-teamspace-block/src/main/resources/COB-INF/flow/.svn/ doesn't exist. at org.apache.excalibur.source.impl.FileSource.getInputStream(FileSource.java:150) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.compileScript(FOM_JavaScriptInterpreter.java:502) at org.apache.cocoon.components.flow.CompilingInterpreter$ScriptSourceEntry.getScript(CompilingInterpreter.java:112) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.setupContext(FOM_JavaScriptInterpreter.java:453) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.callFunction(FOM_JavaScriptInterpreter.java:572) at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:109) ... 43 more Caused by: java.io.FileNotFoundException: /Users/alex/Mindquarry/hack/mindquarry-teamspace-web/mindquarry-teamspace-block/src/main/resources/COB-INF/flow/.svn (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:106) at org.apache.excalibur.source.impl.FileSource.getInputStream(FileSource.java:146) ... 48 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
various cforms issues
Hi there, In a small cforms demo I'm trying out today I've been hitting quite a number of issues. Each of these are (some even important) bugs IMHO, I still need to perform a full scan of jira and svn history to see if some of these are known and/or understand how we got here... this upfront message is a poll for checking if I'm making sense at all here, possibly tapping from your combined memory to be corrected on these. 1/ fd:output is ignoring fd:initial-value this one is quite obvious I think: anybody adding a fd:initial-value to a fd:output can wait for eternity for it to ever get applied. Proposed fix: initialize() should do it like Field.java does. 2/ union.readfromrequest should stick to the contract of the method: reading 'own values' from the request and passing it down to active children that might get new values set from the request it is currently not doing so, in stead, it is: -a- causing the bound 'case-widget' to readfromrequest (which in fact doubles the call on that instance: their common parent-widget, and only he, should be driving that already! Please note: the order of things should not effect us: the union widget is listening in on value-change-events on the selector-widget, so there is no need to force the case-widget to read from the request...) -b- and then using this new value to activate the new case-child and letting that read its values from the request I find this awkward for 2 reasons: 1 duplicating call again: the union should just be waiting for the value-changed-event and react on that, 2 and more importantly, it doesn't seem to make sense: how could there be values in the request params for these newly activated widget-group (these are matching the new case, so they weren't shown on the form yet) (I've found cocoon-1195 to be related, don't really get what is happening here yet, anyone?) Proposed fix: bring readfromrequest back to an essential form where it just delegates to the current case-widget-group (or the 'previous' if you like, since that new request-submit might be changing the case all together) 3/ union currently waits for getChild(anyId) to initialize the newly needed case-group. However the getChild(newCaseValue) is currently not called from the valueChangeListener on the caseWidget one serious side-effect I've seen from this is that in certain cases (a nested union in a new/class construct) the getChild will not be called until the generation-pipeline is at work! At that moment however child-group initialization is causing a load of new events to be happening (value-changed caused by initial-values, as wel as create-events). Conceptually: it is my believe that all these events should have been fired/handled during form.process, not during the publishing (suppose publishing doesn't visit them, the server side 'state' of the form-model is not as it should be) Technically: having these occur during the publishing-pipeline also causes the attached javascript event-handlers to be operating in a context lacking the flow-scope (cocoon undefined, functions in the flow not available, etc etc) 4/ field should not turn to 'null' when the matching parameterName was not present in the request. Given the way browsers work I believe that BooleanField is the only exception to this. (html-checkboxes will not be present in the To be honest: I'm currently only having a practical issue with this because of the combination of above issues being around, but conceptually I think we need to check before interpreting the lack of any new value as a motivated change of the value to null ? any comments welcome, I'm currently planning to investigate deeper into these in the nearby future regards, -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
[jira] Commented: (COCOON-1933) [Patch] Automatic loading of flow scripts in flow/ must not load directories
[ http://issues.apache.org/jira/browse/COCOON-1933?page=comments#action_12441773 ] Carsten Ziegeler commented on COCOON-1933: -- Looking into the Spring code, I think Spring doesn't support unpacked war files at all. This would mean that we are currently only able to run expanded as the path matcher we use in other places is not working unexpanded. [Patch] Automatic loading of flow scripts in flow/ must not load directories -- Key: COCOON-1933 URL: http://issues.apache.org/jira/browse/COCOON-1933 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Alexander Klimetschek Attachments: cocoon-flow-only-files.patch The automatic loading of everything inside flow/ also tries to load directories, which cannot be compiled like files. Happens typically when you have a subversion directory (.svn) or other version-control directory inside. The stacktrace for the problem: Caused by: org.apache.excalibur.source.SourceNotFoundException: file:/Users/alex/Mindquarry/hack/mindquarry-teamspace-web/mindquarry-teamspace-block/src/main/resources/COB-INF/flow/.svn/ doesn't exist. at org.apache.excalibur.source.impl.FileSource.getInputStream(FileSource.java:150) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.compileScript(FOM_JavaScriptInterpreter.java:502) at org.apache.cocoon.components.flow.CompilingInterpreter$ScriptSourceEntry.getScript(CompilingInterpreter.java:112) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.setupContext(FOM_JavaScriptInterpreter.java:453) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.callFunction(FOM_JavaScriptInterpreter.java:572) at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:109) ... 43 more Caused by: java.io.FileNotFoundException: /Users/alex/Mindquarry/hack/mindquarry-teamspace-web/mindquarry-teamspace-block/src/main/resources/COB-INF/flow/.svn (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:106) at org.apache.excalibur.source.impl.FileSource.getInputStream(FileSource.java:146) ... 48 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
Cocoon 2.2 build errors for cocoon-dist-samples
Dear developers, This afternoon I did a fresh download of the Cocoon 2.2 trunk and tried to build it. Unfortunately I'm getting build errors. Here's the output from maven. I replaced the actual path to the trunk with '/path/to/cocoon/trunk': [INFO] Generating war /path/to/cocoon/trunk/dists/cocoon-dist-samples/target/cocoon-samples.war [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error assembling WAR Embedded error: Deployment descriptor: /path/to/cocoon/trunk/dists/cocoon-dist-samples/target/cocoon-samples/WEB-INF/web.xml does not exist. This cocoon-dist-samples also couses troubles on another machine where I've tried to build cocoon earlier. After an update to the same revision as in the previous example and a build attempt, I get the following errors: [INFO] Assembling webapp cocoon-dist-samples in /path/to/cocoon/trunk/dists/cocoon-dist-samples/target/cocoon-samples [INFO] [ERROR] BUILD ERROR [INFO] [INFO] There are at least two artifacts with the ID 'xmlParserAPIs': xerces:xmlParserAPIs:jar:2.6.2:compile org.apache.cocoon:cocoon-dist-samples:war:2-SNAPSHOT org.apache.cocoon:cocoon-batik-sample:jar:1.0.0-SNAPSHOT org.apache.cocoon:cocoon-batik-impl:jar:1.0.0-SNAPSHOT batik:batik-ext:jar:1.6-1 xml-apis:xmlParserAPIs:jar:2.0.2 xerces:xmlParserAPIs:jar:2.6.2:compile org.apache.cocoon:cocoon-dist-samples:war:2-SNAPSHOT org.apache.cocoon:cocoon-forms-sample:jar:1.0.0-SNAPSHOT org.apache.cocoon:cocoon-forms-impl:jar:1.0.0-M2-SNAPSHOT xom:xom:jar:1.1 xerces:xmlParserAPIs:jar:2.6.2 I removed both directories ~/.m2/repository/xerces and ~/.m2/repository/xml-apis from my local repository, since these both contain this artifact called 'xmlParserAPIs', hoping one of these was related to another project. But after a rebuild, both directories are restored again and the problem reappears. Do you have any clues? Thanks for your attention, Fred
[jira] Commented: (COCOON-1928) Add the ability to pass the doctype in parameter for Serializer
[ http://issues.apache.org/jira/browse/COCOON-1928?page=comments#action_12441895 ] David Crossley commented on COCOON-1928: Sitemap precedence would probably be better, if possible. Another technique that i wonder about: Let the project or plugin declare a separate map:serializer with different name attribute. Then make the name be configurable for deciding which serializer to use later in the map:pipelines. I gather that the Cocoon properties system will enable such configuration (FOR-917). The entities technique should work (being an xml framework). The biggest trouble that i have found is getting the entity resolver to work in all three situations: local jetty, command-line CLI, and webapp war. Forrest entity resolver is able to be used at core, plugin, and project levels. Here is one technique that might help you: http://forrest.apache.org/docs/dev/faq.html#xml-entities Probably should create a FOR Jira issue and leave this one for your original suggestion. 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
