[jira] Commented: (COCOON-1931) Provide more information when compiling a Flowscript fails
[ http://issues.apache.org/jira/browse/COCOON-1931?page=comments#action_12441935 ] Georg Hüttenegger commented on COCOON-1931: --- Not sure if fixing the NullPointerException is going to be easy. It would definitely be great to get the line number of an erronous flowscript in the second case (missing '}'). The NullPointerException when a flowscript is missing: [13.10.06 08:17:49:613 CEST] 0028 SystemOut O 08:17:49,613 ERROR [tainer : 2][ap.handled-errors] []: Could not read resource cocoon://webapp/flowcall-loginWithPassword org.apache.cocoon.ProcessingException: Could not read resource cocoon://webapp/flowcall-loginWithPassword: java.lang.NullPointerException at org.apache.cocoon.components.source.SourceUtil.handleSAXException(SourceUtil.java:446) at org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java:117) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:575) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:483) at org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:120) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.SelectNode.invoke(SelectNode.java:102) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.ContainerNode.invoke(ContainerNode.java:31) at org.apache.cocoon.components.treeprocessor.sitemap.CallNode.invoke(CallNode.java:93) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.ActTypeNode.invoke(ActTypeNode.java:138) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:138) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:243) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:117) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:138) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:243) at org.apache.cocoon.Cocoon.process(Cocoon.java:608) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1123) at at.rsf4j.cocoon.servlet.RSFCocoonServlet.service(RSFCocoonServlet.java:186) at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1282) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:673) at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:2965) at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:221) at com.ibm.ws.webcontainer.VirtualHost.handleRequest(VirtualHost.java:210) at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:1931) at
[jira] Commented: (COCOON-1931) Provide more information when compiling a Flowscript fails
[ http://issues.apache.org/jira/browse/COCOON-1931?page=comments#action_12441936 ] Georg Hüttenegger commented on COCOON-1931: --- One more thing: The stack traces are from cocoon 2.1.7 (with a slightly modified FOM_JavaScriptInterpreter). Georg Provide more information when compiling a Flowscript fails -- Key: COCOON-1931 URL: http://issues.apache.org/jira/browse/COCOON-1931 Project: Cocoon Issue Type: Improvement Components: - Flowscript Affects Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9, 2.1.10-dev (current SVN) Reporter: Georg Hüttenegger Priority: Minor Attachments: FOM_JavaScriptInterpreter.java.MoreErrorInfoPatch When a flowscript defined in the sitemap cannot be loaded a NullPointerException is thrown without telling the developer the real cause of the issue. The same is true for certain Javascript coding errors (at least missing closing bracket of a for loop). The provided patch throws a CascadingRuntimeException with the name of the flowscript instead of just a simple NullPointerException. In that way the developer is lead directly to the cause of the problem instead of wondering what the real issue might be. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] 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_12441939 ] Jörg Heinicke commented on COCOON-1928: --- Cyriaque, have you tried declaring the serializer in your project's sitemap.xmap file? I am not sure which one takes precedence. Sitemap precedence would probably be better, if possible. I don't know how a Forrest plugin works, but in standard Cocoon sitemaps work as sub-containers and redeclared components are only usable in this sitemap and its childs (if not redeclared again). So if the plugin's sitemap is actually a super-sitemap (or part of it) of the project's sitemap and if it also contains the pipeline where this component is used, it will use the original component, not the redeclared one. Probably should create a FOR Jira issue and leave this one for your original suggestion. I don't think that this proposal will make it into Cocoon. You can ask on the developers list, but I guess this one will get a WONTFIX (to speak in bugzilla resolvings). 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
Re: [VOTE] Lars Trieloff as a new Cocoon committer
On 10/6/06, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: Congratulations Lars, you are elected with 21 +1s Are you following up to get Lars' account created? I see that his CLA has been recorded already, but I don't remember seing the account request. -Bertrand
[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_12441964 ] Alexander Klimetschek commented on COCOON-1933: --- Why don't use Excalibur Sources for retrieving the contents? [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-556) incorrect script tags in xhtml (and missing newlines)
[ http://issues.apache.org/jira/browse/COCOON-556?page=all ] Jörn Nettingsmeier updated COCOON-556: -- Attachment: cforms-avoid_empty_script_tags.diff please consider this for inclusion. btw, this issue still applies to cocoon-2.1.x (svn trunk), but i could not figure how to edit that information. incorrect script tags in xhtml (and missing newlines) - Key: COCOON-556 URL: http://issues.apache.org/jira/browse/COCOON-556 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.0.5-dev (Current CVS) Environment: Operating System: other Platform: Other Reporter: Ralf Hauser Assigned To: Cocoon Developers Team Attachments: cforms-avoid_empty_script_tags.diff When viewing the forrest myprojects sample site with xhtml, but Mozilla (Build 2003010808) and MSIE 6 are unable to render it properly. The reason appears to be script src=skin/breadcrumbs.js language=JavaScript type=text/javascript / where both browsers mentioned thereafter no longer parse all subsequent code until the next /script is encountered (unfortunately this is only at the very end of the page afer the LastModified script.). When serializing it as html, proper /script end tags are used even if the script is empty like the above breadcrumb. A further little nuisance is that the xhtml serializers do not add newlines while the regular html serializer does. The effect is that view source of browsers is almost unreadable and also in emacs, such source is very hard to look at when basically all in one line wrapped dozens of times. This, however doesn't seem to have impacted the rendering by the browsers. -- 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: Cocoon 2.2 build errors for cocoon-dist-samples
Fred Vos wrote: 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 I can't reproduce this. What does your maven commandline look like? Jorg
Re: various cforms issues
Marc Portier wrote: 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. +1 snip union/ 4/ field should not turn to 'null' when the matching parameterName was not present in the request. I'm not convinced we should change this. I suppose you need it only because 1/ does not work. Given the way browsers work I believe that BooleanField is the only exception to this. (html-checkboxes will not be present in the Multi-value field also will not have a parameter in the request if nothing was chosen. Vadim
[jira] Closed: (COCOON-556) incorrect script tags in xhtml (and missing newlines)
[ http://issues.apache.org/jira/browse/COCOON-556?page=all ] Jörg Heinicke closed COCOON-556. Resolution: Won't Fix Hmm, I want to re-close this issue immediately. Sorry, but I don't want to fix buggy browser behavior. There was a thread about this topic on the users list lately: http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=116064735010872w=4. So are you talking about *real* XHTML or anything that looks like XHTML or HTML 4? I think Cocoon behaves absolutely correct and you should not fix it in the source document or stylesheet at all. If you want to influence it, adapt the *serializer*. I know both the standard XMLSerializer and HTMLSerializer don't provide many possibilities to adapt their behaviour. But there are alternatives in the serializer block. Another possibility is to add a further transformation step (xslt) and to add a non-breaking space to each empty script element. This would also prevent other sources of empty script elements breaking your site. Jörg incorrect script tags in xhtml (and missing newlines) - Key: COCOON-556 URL: http://issues.apache.org/jira/browse/COCOON-556 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.0.5-dev (Current CVS) Environment: Operating System: other Platform: Other Reporter: Ralf Hauser Assigned To: Cocoon Developers Team Attachments: cforms-avoid_empty_script_tags.diff When viewing the forrest myprojects sample site with xhtml, but Mozilla (Build 2003010808) and MSIE 6 are unable to render it properly. The reason appears to be script src=skin/breadcrumbs.js language=JavaScript type=text/javascript / where both browsers mentioned thereafter no longer parse all subsequent code until the next /script is encountered (unfortunately this is only at the very end of the page afer the LastModified script.). When serializing it as html, proper /script end tags are used even if the script is empty like the above breadcrumb. A further little nuisance is that the xhtml serializers do not add newlines while the regular html serializer does. The effect is that view source of browsers is almost unreadable and also in emacs, such source is very hard to look at when basically all in one line wrapped dozens of times. This, however doesn't seem to have impacted the rendering by the browsers. -- 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
[GT2006] Missing Presentations
Hi, Many presentations are already uploaded to the wiki [1], but some are missing. Any chance of getting them all up? Jeremy, last slide of your presentation on [1] seems to be not finished. Do you have a complete version? :) Gianugo, can you upload your presentation as well? With audio? If not text will do as well :) Thanks, Vadim [1] http://wiki.apache.org/cocoon/GT2006Notes
[jira] Commented: (COCOON-556) incorrect script tags in xhtml (and missing newlines)
[ http://issues.apache.org/jira/browse/COCOON-556?page=comments#action_12442014 ] Jörn Nettingsmeier commented on COCOON-556: --- ok. in order to serve xhtml that also uses the correct xhtml namespace, one needs to apply post-processing anyways, since iiuc the cforms sheets produce tags without a ns. incorrect script tags in xhtml (and missing newlines) - Key: COCOON-556 URL: http://issues.apache.org/jira/browse/COCOON-556 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.0.5-dev (Current CVS) Environment: Operating System: other Platform: Other Reporter: Ralf Hauser Assigned To: Cocoon Developers Team Attachments: cforms-avoid_empty_script_tags.diff When viewing the forrest myprojects sample site with xhtml, but Mozilla (Build 2003010808) and MSIE 6 are unable to render it properly. The reason appears to be script src=skin/breadcrumbs.js language=JavaScript type=text/javascript / where both browsers mentioned thereafter no longer parse all subsequent code until the next /script is encountered (unfortunately this is only at the very end of the page afer the LastModified script.). When serializing it as html, proper /script end tags are used even if the script is empty like the above breadcrumb. A further little nuisance is that the xhtml serializers do not add newlines while the regular html serializer does. The effect is that view source of browsers is almost unreadable and also in emacs, such source is very hard to look at when basically all in one line wrapped dozens of times. This, however doesn't seem to have impacted the rendering by the browsers. -- 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: various cforms issues
Vadim Gritsenko wrote:
Marc Portier wrote:
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.
+1
I still think the fix should be applied, but given the current
widget-states I guess the same can be achieved through a proper 'field'
snip union/
since you skipped issue 2/ and 3/, the ones concerning union, I'm
compelled to attracd again some attention to it: those are the real
important bugs IMHO
4/ field should not turn to 'null' when the matching parameterName was
not present in the request.
I'm not convinced we should change this. I suppose you need it only
because 1/ does not work.
nope, this has nothing to do with initial-values on read-only widgets,
if you handle them with 'fd:field' then it will ignore reading the
request when it's not in an enabled state
from Field.java:
public void readFromRequest(FormContext formContext) {
if (!getCombinedState().isAcceptingInputs()) {
return;
}
and if you'ld handle it through output, and use flow to set the value
there is no request reading at all:
from Output.java:
public void readFromRequest(FormContext formContext) {
// do nothing
}
actually I noticed this because of the union issues (2/ and 3/)
currently a 'fd:field' that is added through a selected case-group will
first properly initialize (and get its initial-value), and then gets
instructed to read-from-request (making no sense IMHO)
since that request couldn't be holding any value for this newly added
widget, the field changes its value back to null (cool he :-))
Given the way browsers work I believe that BooleanField is the only
exception to this. (html-checkboxes will not be present in the
Multi-value field also will not have a parameter in the request if
nothing was chosen.
ah, didn't know, thx for clarifying...
anyway, this 'multivalue' (like the 'boolean') aspect is something the
field would now, and could thus properly react upon, no?
I'm still compelled to ensure we're correctly interpreting missing
request-parameters, assuming it means 'setValue(null)' by default seems
a bit weird. By default I think it should mean 'no change'.
(in fact that is precisely what is happening when those widgets are not
on the form because they're in a parallel union-case-group)
-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]
Re: various cforms issues
Marc Portier wrote:
Vadim Gritsenko wrote:
Marc Portier wrote:
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.
+1
I still think the fix should be applied, but given the current
widget-states I guess the same can be achieved through a proper 'field'
That's what I said: +1, meaning I agree, Yes, it should be fixed.. Even if
you could hack field to act as output, output itself should function correctly.
snip union/
since you skipped issue 2/ and 3/, the ones concerning union, I'm
compelled to attracd again some attention to it: those are the real
important bugs IMHO
I skipped union just 'cause I've not used it and hence have no opinion on it.
4/ field should not turn to 'null' when the matching parameterName was
not present in the request.
I'm not convinced we should change this. I suppose you need it only
because 1/ does not work.
nope, this has nothing to do with initial-values on read-only widgets,
if you handle them with 'fd:field' then it will ignore reading the
request when it's not in an enabled state
from Field.java:
public void readFromRequest(FormContext formContext) {
if (!getCombinedState().isAcceptingInputs()) {
return;
}
and if you'ld handle it through output, and use flow to set the value
there is no request reading at all:
from Output.java:
public void readFromRequest(FormContext formContext) {
// do nothing
}
actually I noticed this because of the union issues (2/ and 3/)
currently a 'fd:field' that is added through a selected case-group will
first properly initialize (and get its initial-value), and then gets
instructed to read-from-request (making no sense IMHO)
since that request couldn't be holding any value for this newly added
widget, the field changes its value back to null (cool he :-))
Given the way browsers work I believe that BooleanField is the only
exception to this. (html-checkboxes will not be present in the
Multi-value field also will not have a parameter in the request if
nothing was chosen.
ah, didn't know, thx for clarifying...
anyway, this 'multivalue' (like the 'boolean') aspect is something the
field would now, and could thus properly react upon, no?
I'm still compelled to ensure we're correctly interpreting missing
request-parameters, assuming it means 'setValue(null)' by default seems
a bit weird. By default I think it should mean 'no change'.
(in fact that is precisely what is happening when those widgets are not
on the form because they're in a parallel union-case-group)
You are probably right, but I'm not sure. I think there were some discussion
about skipping reading of fields missing on the template, which sounds related
to what you are talking about.
Vadim
[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_12442085 ] Carsten Ziegeler commented on COCOON-1933: -- I think this wouldn't help us in this case as even the Excalibur source resolver can't tell if a resource is a directory or a file in the case of an unexpanded war. I checked in a fix yesterday which should solve most of the problems when running unexpanded, but the file/directory detection is still an issue. I guess we could use getFile() first and if that fails use getInputStream() for testing? [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-1815) CopySourceAction generate NPE
[
http://issues.apache.org/jira/browse/COCOON-1815?page=comments#action_12442125
]
Frédéric Glorieux commented on COCOON-1815:
---
[[ Old comment, sent by email on Mon, 29 May 2006 11:00:54 +0200 ]]
Thanks for others, but for testing, sorry, I can't find time for now,
I'm on other projects (in PHP :o( )
--
FrC)dC)ric Glorieux (AJLSM, http://ajlsm.com)
CopySourceAction generate NPE
-
Key: COCOON-1815
URL: http://issues.apache.org/jira/browse/COCOON-1815
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Affects Versions: 2.1.8
Reporter: Frédéric Glorieux
Assigned To: Antonio Gallardo
Priority: Minor
Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN)
http://www.mail-archive.com/users-fr@cocoon.apache.org/msg01586.html
In some circumstances, with internal sources (cocoon:/),
org/apache/cocoon/acting/copySource.java
http://svn.apache.org/viewcvs.cgi/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/acting/CopySourceAction.java?rev=30932view=markup
copy-source action generate NPE in Console (nothing seems broken)
Source objects needs to be released
Code may be shorter with usage of excalibur SourceUtil to copy sources
try {
org.apache.excalibur.source.SourceUtil.SourceUtil.copy(src, dest);
} finally {
resolver.release(src);
resolver.release(dest);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1876) XMLDBTransformer blows up Saxon
[ http://issues.apache.org/jira/browse/COCOON-1876?page=comments#action_12442172 ] Don Grodecki commented on COCOON-1876: -- [[ Old comment, sent by email on Tue, 11 Jul 2006 07:42:25 -0500 ]] Thank you! - Don XMLDBTransformer blows up Saxon --- Key: COCOON-1876 URL: http://issues.apache.org/jira/browse/COCOON-1876 Project: Cocoon Issue Type: Bug Components: Blocks: XML-DB Affects Versions: 2.1.9 Reporter: Don Grodecki Assigned To: Antonio Gallardo Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) The XMLDBTransformer blows up Saxon, which does not like null URIs. The following fix seems to work, replacing null in the first parameter to addAttribute with . // Report result AttributesImpl attrs = new AttributesImpl(); attrs.addAttribute(, XMLDB_QUERY_OID_ATTRIBUTE, XMLDB_QUERY_OID_ATTRIBUTE, CDATA, this.key); attrs.addAttribute(, XMLDB_QUERY_TYPE_ATTRIBUTE, XMLDB_QUERY_TYPE_ATTRIBUTE, CDATA, this.operation); attrs.addAttribute(, XMLDB_QUERY_RESULT_ATTRIBUTE, XMLDB_QUERY_RESULT_ATTRIBUTE, CDATA, result); The API being called is the SAX org.xml.sax.ContentHandler.createElement(). From the Interface definition at http://www.saxproject.org/apidoc/index.html: Parameters: uri - the Namespace URI, or the empty string if the element has no Namespace URI or if Namespace processing is not being performed ... Note that a null value is not specified as one of the options: Both the versions that I have, which are saxon8 (jar contents dated 4/7/2005) and saxonB-8.7.3 (the latest), blow out with a NullPointerException. I have used Saxon quite a bit, for XSLT 2.0, and the only calls to Saxon with null URIs have been from the XMLDBTransformer. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1894) Added support for the SQL;XML tag in SQLTransformer
[ http://issues.apache.org/jira/browse/COCOON-1894?page=comments#action_12442204 ] Geurt Wisselink commented on COCOON-1894: - [[ Old comment, sent by email on Wed, 23 Aug 2006 20:54:45 +0200 ]] I added it as patch in Jira. But here it is via email. Regards Geurt Added support for the SQL;XML tag in SQLTransformer --- Key: COCOON-1894 URL: http://issues.apache.org/jira/browse/COCOON-1894 Project: Cocoon Issue Type: Improvement Components: Blocks: Databases Affects Versions: 2.2-dev (Current SVN) Reporter: Geurt Wisselink Attachments: SQLTransformer.java, SQLTransformer.java.patch It adds support for the SQL:XML tag, this makes it possible to write XML inside a SQL database. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1894) Added support for the SQL;XML tag in SQLTransformer
[ http://issues.apache.org/jira/browse/COCOON-1894?page=comments#action_12442205 ] Geurt Wisselink commented on COCOON-1894: - [[ Old comment, sent by email on Sun, 27 Aug 2006 20:02:15 +0200 ]] Antonio, Is there anything I need to do before it can be changed in cocoon 2.2? Regards Geurt Added support for the SQL;XML tag in SQLTransformer --- Key: COCOON-1894 URL: http://issues.apache.org/jira/browse/COCOON-1894 Project: Cocoon Issue Type: Improvement Components: Blocks: Databases Affects Versions: 2.2-dev (Current SVN) Reporter: Geurt Wisselink Attachments: SQLTransformer.java, SQLTransformer.java.patch It adds support for the SQL:XML tag, this makes it possible to write XML inside a SQL database. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1894) Added support for the SQL;XML tag in SQLTransformer
[ http://issues.apache.org/jira/browse/COCOON-1894?page=all ] Antonio Gallardo reassigned COCOON-1894: Assignee: Antonio Gallardo Added support for the SQL;XML tag in SQLTransformer --- Key: COCOON-1894 URL: http://issues.apache.org/jira/browse/COCOON-1894 Project: Cocoon Issue Type: Improvement Components: Blocks: Databases Affects Versions: 2.2-dev (Current SVN) Reporter: Geurt Wisselink Assigned To: Antonio Gallardo Attachments: SQLTransformer.java, SQLTransformer.java.patch It adds support for the SQL:XML tag, this makes it possible to write XML inside a SQL database. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1894) Added support for the SQL:XML tag in SQLTransformer
[ http://issues.apache.org/jira/browse/COCOON-1894?page=all ] Antonio Gallardo updated COCOON-1894: - Summary: Added support for the SQL:XML tag in SQLTransformer (was: Added support for the SQL;XML tag in SQLTransformer) Fix a typo on the summary. Added support for the SQL:XML tag in SQLTransformer --- Key: COCOON-1894 URL: http://issues.apache.org/jira/browse/COCOON-1894 Project: Cocoon Issue Type: Improvement Components: Blocks: Databases Affects Versions: 2.2-dev (Current SVN) Reporter: Geurt Wisselink Assigned To: Antonio Gallardo Attachments: SQLTransformer.java, SQLTransformer.java.patch It adds support for the SQL:XML tag, this makes it possible to write XML inside a SQL database. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1894) Added support for the SQL:XML tag in SQLTransformer
[ http://issues.apache.org/jira/browse/COCOON-1894?page=all ] Antonio Gallardo updated COCOON-1894: - Thanks for the patch. Added support for the SQL:XML tag in SQLTransformer --- Key: COCOON-1894 URL: http://issues.apache.org/jira/browse/COCOON-1894 Project: Cocoon Issue Type: Improvement Components: Blocks: Databases Affects Versions: 2.2-dev (Current SVN) Reporter: Geurt Wisselink Assigned To: Antonio Gallardo Attachments: SQLTransformer.java, SQLTransformer.java.patch It adds support for the SQL:XML tag, this makes it possible to write XML inside a SQL database. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1825) Ajax errror when an active state widget become invisible state widget
[
http://issues.apache.org/jira/browse/COCOON-1825?page=comments#action_12442267
]
Antonio Gallardo commented on COCOON-1825:
--
IN the first part of the patch, there is:
+ span id={$id}
+ table id={$id} cellpadding=0 cellspacing=0 border=0
title={fi:hint}
I don't think it is a good idea to have the same id in 2 different elements. It
seems like it might blow somewhere else.
how we can fix this?
Ajax errror when an active state widget become invisible state widget
-
Key: COCOON-1825
URL: http://issues.apache.org/jira/browse/COCOON-1825
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.1.9
Reporter: vincent Demay
Assigned To: Antonio Gallardo
Some widget (field with selection-list and styling=radio, group, etc...) can
not be hidden (state=invisible)in ajax mode.
I declare some widgets without state attribute in the form definition, my
form is in ajax mode, when I set the widget state to INVISIBLE, the ajax
response can not be applied to the form because span
id=widget-name.../span is not available in source code.
I think about 2 patches :
*putting a span/span in forms-field-styling.xsl where is not set
*or modifing abstractWidgetDefinition.java in ordre to generate a placeholder
around each widget (but patch seems to need a lot of modification in
forms-field-styling.xsl too)
Here is the patch for first
--- forms-field-styling.orig 2006-04-13 15:37:06.590221200 +0200
+++ forms-field-styling.xsl 2006-04-13 15:38:22.525291200 +0200
@@ -198,8 +198,9 @@
xsl:variable name=value select=fi:value/
xsl:variable name=vertical
select=string(fi:styling/@list-orientation) != 'horizontal'/
xsl:choose
- xsl:when test=$vertical
-table id={$id} cellpadding=0 cellspacing=0 border=0
title={fi:hint}
+ xsl:when test=$vertical
+ span id={$id}
+ table id={$id} cellpadding=0 cellspacing=0 border=0
title={fi:hint}
xsl:for-each select=fi:selection-list/fi:item
xsl:variable name=item-id select=concat($id, ':',
position())/
tr
@@ -224,6 +225,7 @@
/tr
/xsl:for-each
/table
+/span
/xsl:when
xsl:otherwise
span id={$id} title={fi:hint}
@@ -682,22 +684,24 @@
| know where to insert the widget if it becomes visible
+--
xsl:template match=fi:placeholder
-span id=[EMAIL PROTECTED]/
+span id=[EMAIL PROTECTED]xsl:apply-templates//span
/xsl:template
!--+
| fi:struct - has no visual representation by default
+--
xsl:template match=fi:struct
-xsl:apply-templates/
+ span id=[EMAIL PROTECTED]xsl:apply-templates//span
/xsl:template
!--+
| fi:group - has no visual representation by default
+--
xsl:template match=fi:group
-xsl:apply-templates/
+span id=[EMAIL PROTECTED]xsl:apply-templates//span
/xsl:template
+
+
xsl:template match=@*|node() priority=-1
xsl:copy
Here for the second
--- AbstractWidget.orig 2006-04-13 15:31:07.851701200 +0200
+++ AbstractWidget.java 2006-04-13 15:30:31.446616200 +0200
@@ -483,6 +483,10 @@
public void generateSaxFragment(ContentHandler contentHandler, Locale
locale)
throws SAXException {
+ AttributesImpl placeHolderAttrs = new AttributesImpl();
+ placeHolderAttrs.addCDATAAttribute(id, getRequestParameterName());
+contentHandler.startElement(FormsConstants.INSTANCE_NS,
placeholder, FormsConstants.INSTANCE_PREFIX_COLON + placeholder,
placeHolderAttrs);
+
if (getCombinedState().isDisplayingValues()) {
// FIXME: we may want to strip out completely widgets that
aren't updated when in AJAX mode
String element = this.getXMLElementName();
@@ -497,15 +501,9 @@
generateItemSaxFragment(contentHandler, locale);
-contentHandler.endElement(FormsConstants.INSTANCE_NS, element,
FormsConstants.INSTANCE_PREFIX_COLON + element);
-
-} else {
-// Generate a placeholder that can be used later by AJAX updates
-AttributesImpl attrs = new AttributesImpl();
-attrs.addCDATAAttribute(id, getRequestParameterName());
-contentHandler.startElement(FormsConstants.INSTANCE_NS,
placeholder, FormsConstants.INSTANCE_PREFIX_COLON + placeholder, attrs);
-contentHandler.endElement(FormsConstants.INSTANCE_NS,
placeholder, FormsConstants.INSTANCE_PREFIX_COLON + placeholder);
+contentHandler.endElement(FormsConstants.INSTANCE_NS, element,
FormsConstants.INSTANCE_PREFIX_COLON + element);
}
+
[jira] Reopened: (COCOON-1682) Custom headers for Sendmail Action/Logicsheet/Transformer needed
[ http://issues.apache.org/jira/browse/COCOON-1682?page=all ] Antonio Gallardo reopened COCOON-1682: -- Assignee: Cocoon Developers Team It is a user wish. We should not close it. Custom headers for Sendmail Action/Logicsheet/Transformer needed Key: COCOON-1682 URL: http://issues.apache.org/jira/browse/COCOON-1682 Project: Cocoon Issue Type: Wish Components: Blocks: Mail Affects Versions: 2.1.7 Reporter: Lauri Pitkänen Assigned To: Cocoon Developers Team Priority: Minor Possibility to add multiple custom headers to messages from Sendmail Action/Logicsheet/Transformer would eliminate the need for adding missing fixed optional headers like ReplyTo one by one. This is something that is already available in the AxKit XSP tag library:: http://search.cpan.org/~kjetilk/AxKit-XSP-Sendmail/Sendmail.pm#%3Csendmail:header%3E Configuration example: sendmail:header name=Precedencebulk/sendmail:header sendmail:header name=X-My-HeaderSomething/sendmail:header Headers in the message: Precedence: bulk X-My-Header: Something -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
