RE: spring webflow
I'm not sure if Cocoon should be used for writing web applications at all. If you want to write a simple application, you need to write (and learn) the sitemap, flowscript and probably JXTemplate. If you want to use cforms, you need to know how to write form definitions, form templates and maybe even form bindings. If you want to apply some styling you need to know about XSLT as well. And it even makes it more difficult if you want to reuse some of these parts (try to extend or override parts in cforms, jxtemplate or flow - it wasn't designed for this). I've switched to use Wicket for the new application that we've been creating here. I think it's much easier to create web applications with wicket (because one of the things that make it easier to use is that it takes the request/response cycles away). It's back to basic html (or xhtml) with Java. And onf of the best things is that you can reuse and extend your components (including reuse of markup). Cocoon's SoC made writing web applications better because of the strong separation of logic, content and styling. And javaflow improved it because it took some request/response details away. I think Wicket has achieved the same goal, but I think it's more productive to use than Cocoon is these days. Maybe Cocoon should focus on XML transformation stuff again, and not trying to integrate yet anohter product... Just my 2 cents. -Oorspronkelijk bericht- Van: Carsten Ziegeler [mailto:[EMAIL PROTECTED] To be honest I'm not sure if javascript is better than xml :) Though I don't like both of them when it comes to describing a flow, Spring Webflow as imho to big plus points: a visual editor and it's well known outside of Cocoon. This doesn't imply that it's really better or better usable.
Small bug (typo) in cocoon-sitemap-1.0.xsd
Hi, I think there is a typo in cocoon-sitemap-1.0.xsd (in core/cocoon-sitemap/cocoon-sitemap-impl/src/main/resources/org/apache/co coon/sitemap/schema). At line 334, 'xs:ID' should be changed to 'xsd:ID'. See the patch below. Do I need to create a JIRA issue for this? Thanks, Bart. Index: cocoon-sitemap-1.0.xsd === --- cocoon-sitemap-1.0.xsd (revision 522437) +++ cocoon-sitemap-1.0.xsd (working copy) @@ -331,7 +331,7 @@ xsd:group ref=pipeline-content/ xsd:element ref=handle-errors minOccurs=0 maxOccurs=1/ /xsd:sequence - xsd:attribute name=id type=xs:ID use=optional/ + xsd:attribute name=id type=xsd:ID use=optional/ xsd:attribute name=type type=xsd:string use=optional/ xsd:attribute name=internal-only type=xsd:string use=optional/ /xsd:complexType
RE: Status of javaflow block in 2.2
Hi, Can someone tell me how to get the Javaflow block working? For example, how to get the javaflow samples working? What patches do I need to apply? (the mail below says that these are commented out, but where? I can't find anything commented out in the code) I have build commons-javaflow and commons-jci myself (svn checkouts), so I have builds of the latest versions of those in my local repo. Bart. -Oorspronkelijk bericht- Van: Torsten Curdt [mailto:[EMAIL PROTECTED] Verzonden: dinsdag 13 februari 2007 0:59 Aan: dev@cocoon.apache.org Onderwerp: Re: Status of javaflow block in 2.2 On 31.01.2007, at 03:20, Simone Gianni wrote: Hi Bart, I haven't been much active recently, but me and Maurizio worked a lot to have Javaflow working in 2.2 last summer. The 2.2 javaflow block is based on the new common javaflow made by Torsten Curdt (http://jakarta.apache.org/commons/sandbox/javaflow/ ). This uses JCI to load classes and instrument them at runtime, while there is an ant task to instrument them at build time. The problem, back in september, was that Torsten didn't have time to release a new version of JCI, so the patch applied to have javaflow working was commented out waiting for a new release with JCI patches. I still have a rather old version of 2.2 with all patches applied, a patched version of JCI, and javaflow, with real time reloading and re-instrumenting of classes, mostly working on it. Torsten, any news? :D Was on vacation but working on the jci release right now. A few changes are coming up. Some to the API (mostly renaming and nitpicking), some code restructuring and testcase organization etc. But I want to call a RC in 1-2 weeks from now. cheers -- Torsten
Wrong version in commons-sandbox parent pom?
Hi, Can anyone here update the version number of the parent pom in the following file: http://svn.apache.org/repos/asf/jakarta/commons/trunks-sandbox/pom.xml I think the parent pom's version should be 3-SNAPSHOT (it is 2-SNAPSHOT now). Can anyone here fix this, or do I need to contact people on the commons-dev list myself? Another question: it looks like all commons-sandbox projects should have org.apache.commons:commons-sandbox:pom as their parent pom. But commons-jci has org.apache.commons:commons-parent:2 as a parent. Shouldn't the parent be org.apache.commons:commons-sandbox:pom? (commons-jci builds corrently, and all tests pass btw). Thanks, Bart.
Can't build trunk
Hi, I just did an 'svn up' and now I'm having problems building trunk. It looks like something with rcl. [INFO] Building Cocoon Reloading ClassLoader - Webapp Wrapper [INFO]task-segment: [install] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] Compiling 4 source files to C:\Projects\cocoon\cocoon-trunk\tools\cocoon-rcl\cocoon-rcl-webapp-wrapp er\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\Projects\cocoon\cocoon-trunk\tools\cocoon-rcl\cocoon-rcl-webapp-wrapp er\src\main\java\org\apache\cocoon\servlet\CocoonReloadingListener.java: [32,8] cann ot resolve symbol symbol : constructor ReloadingListener () location: class org.apache.commons.jci.listeners.ReloadingListener C:\Projects\cocoon\cocoon-trunk\tools\cocoon-rcl\cocoon-rcl-webapp-wrapp er\src\main\java\org\apache\cocoon\servlet\CocoonReloadingListener.java: [36,13] can not resolve symbol symbol : method onFileChange (java.io.File) location: class org.apache.commons.jci.listeners.ReloadingListener C:\Projects\cocoon\cocoon-trunk\tools\cocoon-rcl\cocoon-rcl-webapp-wrapp er\src\main\java\org\apache\cocoon\servlet\CocoonReloadingListener.java: [41,13] can not resolve symbol symbol : method onFileDelete (java.io.File) location: class org.apache.commons.jci.listeners.ReloadingListener C:\Projects\cocoon\cocoon-trunk\tools\cocoon-rcl\cocoon-rcl-webapp-wrapp er\src\main\java\org\apache\cocoon\servlet\CocoonReloadingListener.java: [46,13] can not resolve symbol symbol : method onFileCreate (java.io.File) location: class org.apache.commons.jci.listeners.ReloadingListener C:\Projects\cocoon\cocoon-trunk\tools\cocoon-rcl\cocoon-rcl-webapp-wrapp er\src\main\java\org\apache\cocoon\servlet\ReloadingClassloaderManager.j ava:[72,18] cannot resolve symbol symbol : method addReloadNotificationListener (org.apache.commons.jci.ReloadingClassLoader) location: class org.apache.commons.jci.listeners.ReloadingListener C:\Projects\cocoon\cocoon-trunk\tools\cocoon-rcl\cocoon-rcl-webapp-wrapp er\src\main\java\org\apache\cocoon\servlet\ReloadingClassloaderManager.j ava:[73,19] addListener(org.apache.commons.jci.monitor.FilesystemAlterationListener) in org.apache.commons.jci.monitor.FilesystemAlterationMonitor cannot be applied t o (java.io.File,org.apache.commons.jci.listeners.ReloadingListener) Anyone any idea? Thanks, Bart.
[2.2] Can't build with empty local repository
Hi, I've tried to build Cocoon with an empty local repository, block Cocoon Samples Style Default Block has a dependency on cocoon-deployer-plugin version 1.0.0-M2-SNAPSHOT which can't be found on any snapshot server. This aftifact was available in my local repository. Is the version in the pom incorrect? Thanks, Bart.
Re: [ajax] Could not locate widget implementation for replace in bu.widget registered to namespace bu
Hi Rice, Does your pipeline that handles the ajax request use the BrowserUpdateTransformer, and are the partial updates styled with the cforms XSL stylesheets? I've been using CForms and Ajax with Cocoon 2.1 and 2.2 without any problems. HTH, Bart. Rice Yeh wrote: By playing around the samples in http://cocoon.zones.apache.org/demos/21branch, I observed all samples in branch 21 do not have bu:replace rendered in the result html and the ajax works. But for my case, the bu:place is rendered around a tree widget when ajax=true. By studying the JXMacrosHelper, bu:replace should also be rendered when ajax=true. So when is bu:repalce be rendered in the html. Or just bu:replace is outdated? Rice On 2/27/07, *Rice Yeh* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, There are 2 files (manifest.js and bu.js) not found when i set ajax=true in cforms with the following portions of information: Caused by: org.apache.excalibur.source.SourceNotFoundException: resource://org/a pache/cocoon/bu/resources/manifest.js 2007-02-27 17:49:29.892::WARN: /xs/party/resources/bu.js org.apache.cocoon.ResourceNotFoundException: Resource not found. On the client side, the browser has the message dojo.js (line 764) DEPRECATED: dojo.widget.Manager.getImplementationName Could not locate widget implementation for replace in bu.widget registered to namespace bu. Developers must specify correct namespaces for all non-Dojo widgets -- will be removed in version: 0.5dojo.js (line 140) dojo.widget.Parse: error: Error: Could not locate widget implementation for replace in bu.widget registered to namespace budojo.js (line 140) Does anyone have any clue? Rice
CForms: dojo drag-and-drop repeater sample not working in IE
Hi, The dojo drag-and-drop repeater isn't working with IE (checked with IE 6 and IE 7). Both Cocoon 2.1 and 2.2 have the same problem (as expected...) Somehow Dojo isn't capable of drag-and-drop, where tr elements are used. The problem was reported, and I also found a sulution here [1]. However, this solution didn't work for me. Changing from a table to a list did work. Is there anybody using this repeater with IE, and making use of tables? Bart. A sidenote for anyone working with IE7: you have to clean your cache, otherwise changes in JavaScript won't be loaded. This has to be done with a command line option, because cleaning your temporary internet files trough IE won't remove .js files... See [2]. [1]http://dojotoolkit.org/pipermail/dojo-interest/2006-July/011700.html [2]http://drnicwilliams.com/2006/11/22/debugging-javascript-in-ie7-how-to-clear-your-javascript-cache/
CForms: how to find widget by it's full id?
Hi, There's probably a very easy answer to my question: how can I find a widget by it's full id? I have an id, like boxes.1.contacts1 (it's a repeater inside an repeater), and now I want to find the repeater object (I have a reference to the Form instance). getChild(id) gives me a direct child member (as far as I can see), and lookupWidget(path) requires me to translate all the dots into slashes (boxes/1/contacts1 finds the correct widget). So I can solve it with lookupWidget(), but I was wondering if there is a method of direct accessing a deeper child widget without having to modify the ID string. Something like 'findWidget()'. I can submit a patch if such a method may be useful. Thanks, Bart.
[jira] Created: (COCOON-2003) Block cocoon-batik-impl builds against wrong version of batik
Block cocoon-batik-impl builds against wrong version of batik - Key: COCOON-2003 URL: https://issues.apache.org/jira/browse/COCOON-2003 Project: Cocoon Issue Type: Bug Components: - Build System: Maven, Blocks: Batik Affects Versions: 2.2-dev (Current SVN) Reporter: Bart Molenkamp Fix For: 2.2-dev (Current SVN) Block cocoon-batik-impl builds against a wrong version of Batik. Version 1.6-1 is the version of Batik that is used, but during compile time version 1.5 is also included (the artifact has a different name). Dependency batik-transcoder depends on batik-1.5-fop, and this version of batik isn't compatible with 1.6-1 (e.g. the signature of the method org.apache.batik.dom.util.HashTableStack.put has changed). Excluding the batik-1.5-fop dependency seems to solve the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2003) Block cocoon-batik-impl builds against wrong version of batik
[ https://issues.apache.org/jira/browse/COCOON-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470150 ] Bart Molenkamp commented on COCOON-2003: Problem has been reported earlier, see: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=116643223811811w=2 Also see: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=117043039821709w=2 Block cocoon-batik-impl builds against wrong version of batik - Key: COCOON-2003 URL: https://issues.apache.org/jira/browse/COCOON-2003 Project: Cocoon Issue Type: Bug Components: - Build System: Maven, Blocks: Batik Affects Versions: 2.2-dev (Current SVN) Reporter: Bart Molenkamp Fix For: 2.2-dev (Current SVN) Block cocoon-batik-impl builds against a wrong version of Batik. Version 1.6-1 is the version of Batik that is used, but during compile time version 1.5 is also included (the artifact has a different name). Dependency batik-transcoder depends on batik-1.5-fop, and this version of batik isn't compatible with 1.6-1 (e.g. the signature of the method org.apache.batik.dom.util.HashTableStack.put has changed). Excluding the batik-1.5-fop dependency seems to solve the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: [2.2] cocoon-batik-impl block compiles against parts of batik 1.5 (again), should be 1.6-1
I submitted a patch: https://issues.apache.org/jira/browse/COCOON-2003 Bart. -Oorspronkelijk bericht- Van: Bart Molenkamp Verzonden: vrijdag 2 februari 2007 16:19 Aan: dev@cocoon.apache.org Onderwerp: [2.2] cocoon-batik-impl block compiles against parts of batik 1.5 (again), should be 1.6-1 Hi, I reported this problem earlier, spotted the error in the pom and a fix was applied to it. Now I found the same problem again. The block cocoon-batik-impl compiles sources against batik-1.5-fop 0.20.5, while the rest of batik is version 1.6-1. This breaks the block, because the signature of HashTableStack.put has changed (and isn't compatible anymore). See [1]. Now, the dependency batik-transcoder includes the (wrong) batik-1.5-fop as well. Could someone add the same exclusion that is added to the batik-squiggle dependency to the batik-transcoder dependency as well? The exclusion is needed in both the batik-transcoder as in batik-squiggle (which requires the transcoder). I can provide a patch, but maybe it's simpler for someone with write access to copy-paste the exclusion snippet. If I need to provide a patch, please let me now. Thanks, Bart. [1] http://www.mail-archive.com/dev@cocoon.apache.org/msg48624.html
[jira] Updated: (COCOON-2003) Block cocoon-batik-impl builds against wrong version of batik
[ https://issues.apache.org/jira/browse/COCOON-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bart Molenkamp updated COCOON-2003: --- Attachment: cocoon-batik-impl-pom.xml.patch Block cocoon-batik-impl builds against wrong version of batik - Key: COCOON-2003 URL: https://issues.apache.org/jira/browse/COCOON-2003 Project: Cocoon Issue Type: Bug Components: - Build System: Maven, Blocks: Batik Affects Versions: 2.2-dev (Current SVN) Reporter: Bart Molenkamp Fix For: 2.2-dev (Current SVN) Attachments: cocoon-batik-impl-pom.xml.patch Block cocoon-batik-impl builds against a wrong version of Batik. Version 1.6-1 is the version of Batik that is used, but during compile time version 1.5 is also included (the artifact has a different name). Dependency batik-transcoder depends on batik-1.5-fop, and this version of batik isn't compatible with 1.6-1 (e.g. the signature of the method org.apache.batik.dom.util.HashTableStack.put has changed). Excluding the batik-1.5-fop dependency seems to solve the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Releasing from trunk
Reinhard Poetz wrote: As scheduled some weeks ago I want to ask for opinions about a next series of module releases. Here my proposal: - release cocoon-configuration-api and cocoon-spring-configuratur as 1.0 - release cocoon-core (+ all submodules) as RC1 - release the archetypes as RC1 - release cocoon-servlet-service as M1 - release cocoon-template and cocoon-forms as RC1 Maybe you can release the batik block as M1? I've been using it for some time, and it seems to work properly (besides a small problem in the build, I already submitted a patch). Bart.
[2.2] cocoon-batik-impl block compiles against parts of batik 1.5 (again), should be 1.6-1
Hi, I reported this problem earlier, spotted the error in the pom and a fix was applied to it. Now I found the same problem again. The block cocoon-batik-impl compiles sources against batik-1.5-fop 0.20.5, while the rest of batik is version 1.6-1. This breaks the block, because the signature of HashTableStack.put has changed (and isn't compatible anymore). See [1]. Now, the dependency batik-transcoder includes the (wrong) batik-1.5-fop as well. Could someone add the same exclusion that is added to the batik-squiggle dependency to the batik-transcoder dependency as well? The exclusion is needed in both the batik-transcoder as in batik-squiggle (which requires the transcoder). I can provide a patch, but maybe it's simpler for someone with write access to copy-paste the exclusion snippet. If I need to provide a patch, please let me now. Thanks, Bart. [1] http://www.mail-archive.com/dev@cocoon.apache.org/msg48624.html
Re: [2.2] can't mount sitemap using resource:// (spring configurator doesn't use SourceResolver?)
Carsten Ziegeler wrote: Bart Molenkamp wrote: As said, the sitemap is loaded with map:mount src=resource://test.xmap .../. And the file is available on the classpath. How about using other sources, like the slide:// or xmldb:// to load sitemaps? Are they supported now? Hi, no, currently only spring supported protocols work (file, http). Actually this is a bug in the new avalon sitemap support/avalon bridge; this is not a problem of the spring configurator. Why does this configurator run anyways when loading a sitemap? Sitemaps shouldn't contain component configurations anymore, right? In my case, there are no configurations in the sitemap, I moved them to a separate file in the META-INF/cocoon/avalon directory. If configuration is disabled for sitemaps, we don't need the source resolver for that. I agree that we should/use support the source resolver in these cases. Could you please file a bug report? Sure. Bart.
[jira] Created: (COCOON-1995) Can't mount sitemap from using resource:// - cocoon-spring-configurator/avalon bridge doesn't support SourceResolver sources
Can't mount sitemap from using resource:// - cocoon-spring-configurator/avalon bridge doesn't support SourceResolver sources Key: COCOON-1995 URL: https://issues.apache.org/jira/browse/COCOON-1995 Project: Cocoon Issue Type: Bug Components: * Cocoon Core, - Components: Avalon Affects Versions: 2.2-dev (Current SVN) Reporter: Bart Molenkamp Fix For: 2.2-dev (Current SVN) It isn't possible to just mount sitemaps from locations other than file:// and http://, because the cocoon-spring-configurator/avalon bridge doesn't support loading resources from the SourceResolver. Mounting a sitemap using resource:// protocol throws the following exception (trying to mount the sitemap resource://test.xmap): org.apache.cocoon.ProcessingException: Sitemap: error when calling sub-sitemap at map:mount - file:/C:/Projects/gripcard/gripcard-trunk/gripcard/gripcard-card-editor/target/classes/COB-INF/sitemap.xmap:12:83 at map:match - file:/C:/Projects/gripcard/gripcard-trunk/gripcard/gripcard-card-editor/target/classes/COB-INF/sitemap.xmap:11:33 at map:mount - file:/C:/Projects/gripcard/gripcard-trunk/style/content-styling/target/classes/COB-INF/mount.xmap:17:80 at map:match - file:/C:/Projects/gripcard/gripcard-trunk/style/content-styling/target/classes/COB-INF/mount.xmap:16:31 at map:match - file:/C:/Projects/gripcard/gripcard-trunk/style/content-styling/target/classes/COB-INF/mount.xmap:6:30 at map:mount - file:/C:/Projects/gripcard/gripcard-trunk/style/content-styling/target/classes/COB-INF/content.xmap:164:67 at map:match - file:/C:/Projects/gripcard/gripcard-trunk/style/content-styling/target/classes/COB-INF/content.xmap:163:28 at org.apache.cocoon.ProcessingException.throwLocated(ProcessingException.java:111) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:118) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55) at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:87) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:151) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:240) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:171) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:233) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:115) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55) at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:87) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55) at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:87) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:151) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:240) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:171) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:233) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:115) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55) at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:87) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes
Re: [2.2] can't mount sitemap using resource:// (spring configurator doesn't use SourceResolver?)
I filed the bug report: https://issues.apache.org/jira/browse/COCOON-1995 I can see if I can fix it and provide a patch - can you tell me where I should start looking? I guess ChildXmlWebApplicationContext isn't the only location where the SourceResolver is required? Bart. Carsten Ziegeler wrote: Bart Molenkamp wrote: Carsten Ziegeler wrote: Bart Molenkamp wrote: As said, the sitemap is loaded with map:mount src=resource://test.xmap .../. And the file is available on the classpath. How about using other sources, like the slide:// or xmldb:// to load sitemaps? Are they supported now? Hi, no, currently only spring supported protocols work (file, http). Actually this is a bug in the new avalon sitemap support/avalon bridge; this is not a problem of the spring configurator. Why does this configurator run anyways when loading a sitemap? Sitemaps shouldn't contain component configurations anymore, right? In my case, there are no configurations in the sitemap, I moved them to a separate file in the META-INF/cocoon/avalon directory. Component configurations are still allowed in the sitemap for compatibility reasons. In addition we added the possibility to have per sitemap component configurations which are read automatically from a sub directory next to the sitemap. Therefore we create a sub application context which tests all these possibilities and eventually adds the component definitions. Carsten
[2.2] can't mount sitemap using resource:// (spring configurator doesn't use SourceResolver?)
Hi, I'm trying to mount a sitemap which is loaded from a resource. The spring configurator seems to have problems with this, because I'm getting a FileNotFoundException. Some parent of ChildXmlWebApplicationContext tries to load the file '/resource://test.xmap' (and I try to load the sitemap 'resource://test.xmap' of course). The code goes trough ChildXmlWebApplicationContext.getResourceByPath(String path), but fails on line 101 (creating a new URL object that starts with the resource:// scheme). Then it captures the error, and delegates the loading to a super class, which tries to load '/resource://test.xmap'. Should the ChildXmlWebApplicationContext use the SourceResolver, instead?? Thanks, Bart.
Re: [2.2] can't mount sitemap using resource:// (spring configurator doesn't use SourceResolver?)
) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) at java.lang.Thread.run(Thread.java:595) Carsten Ziegeler wrote: Bart Molenkamp wrote: Hi, I'm trying to mount a sitemap which is loaded from a resource. The spring configurator seems to have problems with this, because I'm getting a FileNotFoundException. Some parent of ChildXmlWebApplicationContext tries to load the file '/resource://test.xmap' (and I try to load the sitemap 'resource://test.xmap' of course). The code goes trough ChildXmlWebApplicationContext.getResourceByPath(String path), but fails on line 101 (creating a new URL object that starts with the resource:// scheme). Then it captures the error, and delegates the loading to a super class, which tries to load '/resource://test.xmap'. Should the ChildXmlWebApplicationContext use the SourceResolver, instead?? The configurator should be independent and therefore just use plain spring. Can you add a stack trace please? Carsten
Status of javaflow block in 2.2
Hi all, Can someone tell me what the status is of the javaflow block in Cocoon 2.2? I'm trying to use it, but I'm getting an exception (I tried to run the sample): Caused by: org.apache.commons.javaflow.bytecode.EmptyStackException: pop reference at org.apache.commons.javaflow.bytecode.Stack.popReference(Stack.java:163) at org.apache.cocoon.samples.flow.java.CalculatorFlow.getNumber(CalculatorF low.java) at org.apache.cocoon.samples.flow.java.CalculatorFlow.calculator(Calculator Flow.java:27) ... 94 more Does this sample work for others, or is the current implementation simply broken? Thanks, Bart.
applicationContext.xml not valid according to schema?
Hi, I can't start Cocoon 2.2, because the file WEB-INF/applicationContext.xml isn't valid. I get the following exception: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 30 in XML document from ServletContext resource [/WEB-INF/applicationContext.xml] is invalid; nested exception is org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'cocoon:settings'. Caused by: org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'cocoon:settings'. I really don't understand why this error occurs. The file is created by cocoon's webapp archetype, and I was able to run my application before today. If I open the file in Eclipse (using WTP's XML editor, it also notices the errors). Does anybody have any clue (I'm using spring 2.0.2, cocoon 2.2.0-M3-SNAPSHOT)? Thanks, Bart.
RE: applicationContext.xml not valid according to schema?
Thanks, I just found out myself while looking at the resources in the archetype... Thanks! Bart. -Oorspronkelijk bericht- Van: Leszek Gawron [mailto:[EMAIL PROTECTED] Verzonden: donderdag 25 januari 2007 16:29 Aan: dev@cocoon.apache.org Onderwerp: Re: applicationContext.xml not valid according to schema? Bart Molenkamp wrote: Hi, I can't start Cocoon 2.2, because the file WEB-INF/applicationContext.xml isn't valid. I get the following exception: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 30 in XML document from ServletContext resource [/WEB-INF/applicationContext.xml] is invalid; nested exception is org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'cocoon:settings'. Caused by: org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'cocoon:settings'. I really don't understand why this error occurs. The file is created by cocoon's webapp archetype, and I was able to run my application before today. If I open the file in Eclipse (using WTP's XML editor, it also notices the errors). Does anybody have any clue (I'm using spring 2.0.2, cocoon 2.2.0-M3-SNAPSHOT)? The syntax you're using is outdated (I also have hard time to keep up lately). Your applicationContext.xml should state: beans xmlns=http://www.springframework.org/schema/beans; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:util=http://www.springframework.org/schema/util; xmlns:configurator=http://cocoon.apache.org/schema/configurator; xmlns:avalon=http://cocoon.apache.org/schema/avalon; xsi:schemaLocation=http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-2.0.xsd http://cocoon.apache.org/schema/configurator http://cocoon.apache.org/schema/configurator/cocoon-configurator-1.0.xsd http://cocoon.apache.org/schema/avalon http://cocoon.apache.org/schema/avalon/cocoon-avalon-1.0.xsd; !-- Activate Cocoon Spring Configurator -- configurator:settings/ !-- Configure Log4j -- bean name=org.apache.cocoon.spring.configurator.log4j class=org.apache.cocoon.spring.configurator.log4j.Log4JConfigurator scope=singleton property name=settings ref=org.apache.cocoon.configuration.Settings/ property name=resource value=/WEB-INF/cocoon/log4j.xml/ /bean !-- Activate Avalon Bridge -- avalon:bridge/ /beans no cocoon:settings/ anymore... -- Leszek
RE: Bug in cocoon-22-archetype-webapp? (was: applicationContext.xml not valid according to schema?)
I just hit the send button too early, sorry... I was looking at the archetype source, and saw that the configuration for log4j pointed to the file: /WEB-INF/cocoon/log4j.xml But the file isn't in /WEB-INF/cocoon, but just in /WEB-INF. This seems to cause an exception when starting the webapp... So, I think the file should be moved to the cocoon/ directory, or the applicationContext.xml should be updated. Bart. -Oorspronkelijk bericht- Van: Bart Molenkamp Verzonden: donderdag 25 januari 2007 16:39 Aan: dev@cocoon.apache.org Onderwerp: Bug in cocoon-22-archetype-webapp? (was: applicationContext.xml not valid according to schema?) Looking at the archetype, I see the configuration: -Oorspronkelijk bericht- Van: Bart Molenkamp Verzonden: donderdag 25 januari 2007 16:32 Aan: dev@cocoon.apache.org Onderwerp: RE: applicationContext.xml not valid according to schema? Thanks, I just found out myself while looking at the resources in the archetype... Thanks! Bart. -Oorspronkelijk bericht- Van: Leszek Gawron [mailto:[EMAIL PROTECTED] Verzonden: donderdag 25 januari 2007 16:29 Aan: dev@cocoon.apache.org Onderwerp: Re: applicationContext.xml not valid according to schema? Bart Molenkamp wrote: Hi, I can't start Cocoon 2.2, because the file WEB-INF/applicationContext.xml isn't valid. I get the following exception: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 30 in XML document from ServletContext resource [/WEB-INF/applicationContext.xml] is invalid; nested exception is org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'cocoon:settings'. Caused by: org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'cocoon:settings'. I really don't understand why this error occurs. The file is created by cocoon's webapp archetype, and I was able to run my application before today. If I open the file in Eclipse (using WTP's XML editor, it also notices the errors). Does anybody have any clue (I'm using spring 2.0.2, cocoon 2.2.0-M3-SNAPSHOT)? The syntax you're using is outdated (I also have hard time to keep up lately). Your applicationContext.xml should state: beans xmlns=http://www.springframework.org/schema/beans; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:util=http://www.springframework.org/schema/util; xmlns:configurator=http://cocoon.apache.org/schema/configurator; xmlns:avalon=http://cocoon.apache.org/schema/avalon; xsi:schemaLocation=http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-2.0.xsd http://cocoon.apache.org/schema/configurator http://cocoon.apache.org/schema/configurator/cocoon-configurator-1.0.xsd http://cocoon.apache.org/schema/avalon http://cocoon.apache.org/schema/avalon/cocoon-avalon-1.0.xsd; !-- Activate Cocoon Spring Configurator -- configurator:settings/ !-- Configure Log4j -- bean name=org.apache.cocoon.spring.configurator.log4j class=org.apache.cocoon.spring.configurator.log4j.Log4JConfigurator scope=singleton property name=settings ref=org.apache.cocoon.configuration.Settings/ property name=resource value=/WEB-INF/cocoon/log4j.xml/ /bean !-- Activate Avalon Bridge -- avalon:bridge/ /beans no cocoon:settings/ anymore... -- Leszek
Bug in cocoon-22-archetype-webapp? (was: applicationContext.xml not valid according to schema?)
Looking at the archetype, I see the configuration: -Oorspronkelijk bericht- Van: Bart Molenkamp Verzonden: donderdag 25 januari 2007 16:32 Aan: dev@cocoon.apache.org Onderwerp: RE: applicationContext.xml not valid according to schema? Thanks, I just found out myself while looking at the resources in the archetype... Thanks! Bart. -Oorspronkelijk bericht- Van: Leszek Gawron [mailto:[EMAIL PROTECTED] Verzonden: donderdag 25 januari 2007 16:29 Aan: dev@cocoon.apache.org Onderwerp: Re: applicationContext.xml not valid according to schema? Bart Molenkamp wrote: Hi, I can't start Cocoon 2.2, because the file WEB-INF/applicationContext.xml isn't valid. I get the following exception: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 30 in XML document from ServletContext resource [/WEB-INF/applicationContext.xml] is invalid; nested exception is org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'cocoon:settings'. Caused by: org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'cocoon:settings'. I really don't understand why this error occurs. The file is created by cocoon's webapp archetype, and I was able to run my application before today. If I open the file in Eclipse (using WTP's XML editor, it also notices the errors). Does anybody have any clue (I'm using spring 2.0.2, cocoon 2.2.0-M3-SNAPSHOT)? The syntax you're using is outdated (I also have hard time to keep up lately). Your applicationContext.xml should state: beans xmlns=http://www.springframework.org/schema/beans; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:util=http://www.springframework.org/schema/util; xmlns:configurator=http://cocoon.apache.org/schema/configurator; xmlns:avalon=http://cocoon.apache.org/schema/avalon; xsi:schemaLocation=http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-2.0.xsd http://cocoon.apache.org/schema/configurator http://cocoon.apache.org/schema/configurator/cocoon-configurator-1.0.xsd http://cocoon.apache.org/schema/avalon http://cocoon.apache.org/schema/avalon/cocoon-avalon-1.0.xsd; !-- Activate Cocoon Spring Configurator -- configurator:settings/ !-- Configure Log4j -- bean name=org.apache.cocoon.spring.configurator.log4j class=org.apache.cocoon.spring.configurator.log4j.Log4JConfigurator scope=singleton property name=settings ref=org.apache.cocoon.configuration.Settings/ property name=resource value=/WEB-INF/cocoon/log4j.xml/ /bean !-- Activate Avalon Bridge -- avalon:bridge/ /beans no cocoon:settings/ anymore... -- Leszek
RE: [2.2] block cocoon-fop excluded from build
Great! Thanks! -Oorspronkelijk bericht- Van: Jason Johnston [mailto:[EMAIL PROTECTED] Verzonden: zaterdag 20 januari 2007 17:01 Aan: dev@cocoon.apache.org Onderwerp: Re: [2.2] block cocoon-fop excluded from build Bart Molenkamp wrote: Hi, It looks like the block cocoon-fop is excluded from the build. The sub module cocoon-fop-ng-impl can't be build because the dependency fop 0.92beta is missing (there's only fop:fop:0.20.5 in the repository). Is anybody here at cocoon allowed to publish the dependency to maven-central, or to publish it anywhere else so that we can enable the fop block in the build again? Besides that, it looks like fop 0.93 is released. There is a jdk1.3 and a jdk1.4 version available. Maybe we can update to that version right away. There's a recent thread on the FOP mailing list about getting 0.93 into the maven repo: http://www.nabble.com/Apache-FOP-0.93-Released-t2941798.html#a8244361 I volunteer to follow up on this with the FOP folks. If it isn't possible to publish the new fop jars to some repository, I think we should enable the cocoon-fop-impl block again, and exclude only the cocoon-fop-ng-impl block. I don't see any reason not to include cocoon-fop-impl in the build. Agreed. I've just committed this change.
[2.2] block cocoon-fop excluded from build
Hi, It looks like the block cocoon-fop is excluded from the build. The sub module cocoon-fop-ng-impl can't be build because the dependency fop 0.92beta is missing (there's only fop:fop:0.20.5 in the repository). Is anybody here at cocoon allowed to publish the dependency to maven-central, or to publish it anywhere else so that we can enable the fop block in the build again? Besides that, it looks like fop 0.93 is released. There is a jdk1.3 and a jdk1.4 version available. Maybe we can update to that version right away. If it isn't possible to publish the new fop jars to some repository, I think we should enable the cocoon-fop-impl block again, and exclude only the cocoon-fop-ng-impl block. I don't see any reason not to include cocoon-fop-impl in the build. Thanks, Bart.
[2.2] block cocoon-javaflow-sample has wrong dependency on cocoon-template-impl-1.0.0-M2-SNAPSHOT
Hi, The block cocoon-javaflow-sample has a dependency to cocoon-template-impl version 1.0.0-M2-SNAPSHOT. This should be version 1.0.0-M2 (released) or 1.0.0-M3-SNAPSHOT. Not having this 1.0.0-M2-SNAPSHOT dependency in your local maven repo breaks the build... Can anybody fix this? Thanks, Bart.
Can't build trunk with a clean maven repository
Hi, Cocoon doesn't seem to build when I clean my local maven repository. I get the following error: Missing: -- 1) org.apache.cocoon:cocoon-pipeline-impl:test-jar:tests:1.0.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.cocoon -DartifactId=cocoon-pipeline-impl \ -Dversion=1.0.0-SNAPSHOT -Dpackaging=test-jar -Dfile=/path/to/file Path to dependency: 1) org.apache.cocoon:cocoon-pipeline-components:jar:1.0.0-SNAPSHOT 2) org.apache.cocoon:cocoon-pipeline-impl:test-jar:tests:1.0.0-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.cocoon:cocoon-pipeline-components:jar:1.0.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache.snapshot (http://people.apache.org/repo/m2-snapshot-repository), apache-cvs (http://people.apache.org/repo/m1-snapshot-repository) I found this page [1] to report a similair error. It says that this is because of failing tests, but passing -Dmaven.test.skip=true doesn't make any difference. Anybody any idea? Bart. [1] http://mail-archives.apache.org/mod_mbox/cocoon-dev/200605.mbox/%3Ce34i0 [EMAIL PROTECTED]
Can't compile HSQLDB block
Hi, Trunk doesn't compile anymore with the -Dallblocks setting. When compiling the cocoon-hsqldb-impl block, it's complaining that the javax.servlet package doesn't exist. On 02-01-2007, Carsten removed dependencies to avalon and cocoon core (and thus removing the transitive dependency to the servlet api??) Is this change correct? Do we need to add the servlet spec dependency to the pom? Thanks, Bart.
RE: Can't compile HSQLDB block
-Oorspronkelijk bericht- Van: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Verzonden: vrijdag 5 januari 2007 11:40 Aan: dev@cocoon.apache.org Onderwerp: Re: Can't compile HSQLDB block Bart Molenkamp schrieb: Hi, Trunk doesn't compile anymore with the -Dallblocks setting. When compiling the cocoon-hsqldb-impl block, it's complaining that the javax.servlet package doesn't exist. On 02-01-2007, Carsten removed dependencies to avalon and cocoon core (and thus removing the transitive dependency to the servlet api??) Is this change correct? Do we need to add the servlet spec dependency to the pom? No, the change was a mistake - it's fixed now. Thanks! Sorry for that. No problem :) Bart.
[2.2] cocoon-ajax-impl block: no sitemapcomponents.xconf file?
Hi, The Ajax block has no sitemapcomponents.xconf file (or any other xconf file that declares the ajax components) to define sitemap components such as the BrowserUpdateTransformer and the AjaxRequestSelector/Matcher. Is there any reason why this isn't done, or is it just forgotten? I can provide a file containing the configuration, if it was forgotten. Thanks, Bart.
[2.2] NPE when using block: protocol, caused by a ResourceNotFoundException
Hi, While using the block: protocol, I got NullPointerExceptions because a resource could not be found in the target block. This was due to a ResourceNotFoundException, and when Cocoon tries to report the exception, the NPE occurs. It seems that the outputStream member is null. Has anybody any idea where this should be set? The exception is quite confusing, because I can't see the original ResourceNotFoundException. Here is the stacktrace: java.lang.NullPointerException at org.apache.cocoon.blocks.util.BlockCallHttpServletResponse$1.write(Block CallHttpServletResponse.java:158) at java.io.OutputStream.write(OutputStream.java:99) at java.io.OutputStream.write(OutputStream.java:58) at org.apache.cocoon.components.notification.Notifier.notifyHTML(Notifier.j ava:104) at org.apache.cocoon.components.notification.Notifier.notify(Notifier.java: 49) at org.apache.cocoon.servlet.RequestProcessor.manageException(RequestProces sor.java:306) at org.apache.cocoon.servlet.RequestProcessor.service(RequestProcessor.java :176) at org.apache.cocoon.sitemap.SitemapServlet.service(SitemapServlet.java:61) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at org.apache.cocoon.blocks.BlockContext$PathDispatcher.forward(BlockContex t.java:461) at org.apache.cocoon.blocks.BlockContext$NamedDispatcher.forward(BlockConte xt.java:404) at org.apache.cocoon.blocks.BlockConnection.getInputStream(BlockConnection. java:115) at org.apache.cocoon.blocks.components.BlockSource.getInputStream(BlockSour ce.java:51) at org.apache.cocoon.reading.ResourceReader.generate(ResourceReader.java:32 7) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.cocoon.core.container.spring.avalon.PoolableFactoryBean$Proxy Handler.invoke(PoolableFactoryBean.java:349) at $Proxy4.generate(Unknown Source) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipe line.processReader(AbstractCachingProcessingPipeline.java:878) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process (AbstractProcessingPipeline.java:429) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.cocoon.core.container.spring.avalon.PoolableFactoryBean$Proxy Handler.invoke(PoolableFactoryBean.java:349) at $Proxy3.process(Unknown Source) at org.apache.cocoon.components.treeprocessor.sitemap.ReadNode.invoke(ReadN ode.java:94) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:55) at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(Matc hNode.java:87) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:77) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P ipelineNode.java:152) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:77) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( PipelinesNode.java:93) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process (ConcreteTreeProcessor.java:239) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process (ConcreteTreeProcessor.java:170) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro cessor.java:233) at org.apache.cocoon.servlet.RequestProcessor.process(RequestProcessor.java :377) at org.apache.cocoon.servlet.RequestProcessor.service(RequestProcessor.java :155) at org.apache.cocoon.sitemap.SitemapServlet.service(SitemapServlet.java:61) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at org.apache.cocoon.blocks.BlockContext$PathDispatcher.forward(BlockContex t.java:461) at org.apache.cocoon.blocks.BlockContext$PathDispatcher.forward(BlockContex t.java:443) at org.apache.cocoon.blocks.BlockServlet.service(BlockServlet.java:123) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at org.apache.cocoon.blocks.DispatcherServlet.service(DispatcherServlet.jav a:128) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at
RE: How to install source code's jar to local repository during building also?
Hi, The source:jar goal does this. Try: mvn clean source:jar install -Dmaven.test.skip=true HTH, Bart. Van: Rice Yeh [mailto:[EMAIL PROTECTED] Verzonden: woensdag 20 december 2006 10:54 Aan: dev@cocoon.apache.org Onderwerp: How to install source code's jar to local repository during building also? Hi, Â I use 'maven clean install' to build cocoon. Is there also a way to install source code's jar to local repository during building without changing present pom.xml? Rice
RE: [2.2] Duplicate (and different) versions of batik on classpath
It seems to work. Thanks for that. However, I think I found another problem related to Eclipse. Batik has a dependency to rhino:js:1.5R4.1, but cocoon-core has a dependency to rhino:js:1.6R5. When I build my block, or when I build from the root pom, Maven builds against 1.6R5 (it removes 1.5R4.1 from the classpath). This is correct. But when I build the Eclipse descriptors, it adds rhino:js:1.5R4.1 to the classpath. That is wrong, IMO. It should add the dependency to rhino:js:1.6R5 (transitively trough cocoon-core's dependencies). You can see it for yourself by creating all the eclipse descriptors for trunk, and then opening the block cocoon-batik-impl (you'll see the wrong version of rhino:js on the classpath). Is this a known problem, or better, does anybody know how to solve this? Thanks, Bart. -Oorspronkelijk bericht- Van: Daniel Fagerstrom [mailto:[EMAIL PROTECTED] Verzonden: dinsdag 19 december 2006 9:51 Aan: dev@cocoon.apache.org Onderwerp: Re: [2.2] Duplicate (and different) versions of batik on classpath I removed the dependency on batik-1.5-fop, thanks for spotting the problem. I haven't done much testing yet, please report if there are any problems. /Daniel Bart Molenkamp skrev: Hi, I found a problem with the cocoon-batik-impl block. When I add a dependency to this block, I end up with two different versions of Batik on my classpath. The first (and correct) one is batik-1.6-1. But due to a dependency to fop 0.20.5, batik-1.5-fop gets included (which is not compatible with batik-1.6-1). See the snippet below that I got when running maven with the -X option: batik:batik-squiggle:jar:1.6-1:compile (selected for compile) batik:batik-swing:jar:1.6-1:compile (selected for compile) batik:batik-transcoder:jar:1.6-1:compile (selected for compile) fop:fop:jar:0.20.5:compile (selected for compile) xml-apis:xml-apis:jar:1.0.b2:compile (removed - nearer found: 1.3.02) xerces:xercesImpl:jar:2.2.1:compile (removed - nearer found: 2.8.0) batik:batik-1.5-fop:jar:0.20-5:compile (selected for compile) When I run the webapp from the commandline, using the maven jetty plugin, everything seems to work fine. But when I run it in Eclipse (using the Jetty launcher plugin), I get classpath errors. First conflict I found was that of o.a.batik.dom.AbstractDocument.init (constructor signature changed in 1.6-1). After removing batik-1.5-fop jar from my classpath, I ran into another classpath problem. org.apache.cocoon.xml.dom.SVGBuilder accesses the protected member 'namespaces', which is of type org.apache.batik.dom.util.HashTableStack. The signature method 'put' has changed from 'put(String, Object)' to 'put(String, String)'. It looks like the cocoon-batik-impl block is built against batik-1.5-fop, and not batik-1.6-fop. When I exclude batik-1.5-fop as a dependency, everything seems to work fine (but I don't know what functionality of batik requires batik-1.5-fop). It worked either by excluding the dependency from cocoon-batik-impl's pom.xml (but I had to declare the exclusion several times), or when I exclude it from fop-0.20.5.pom (from my local repository). How can this problem be resolved? Anybody interested in the changed pom? Thanks, Bart.
RE: [2.2] Duplicate (and different) versions of batik on classpath
Ok, I found http://jira.codehaus.org/browse/MECLIPSE-122. Seems to be fixed, but not yet released... (looking at http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-eclipse-plu gin/ Bart. -Oorspronkelijk bericht- Van: Bart Molenkamp Verzonden: dinsdag 19 december 2006 11:19 Aan: dev@cocoon.apache.org Onderwerp: RE: [2.2] Duplicate (and different) versions of batik on classpath It seems to work. Thanks for that. However, I think I found another problem related to Eclipse. Batik has a dependency to rhino:js:1.5R4.1, but cocoon-core has a dependency to rhino:js:1.6R5. When I build my block, or when I build from the root pom, Maven builds against 1.6R5 (it removes 1.5R4.1 from the classpath). This is correct. But when I build the Eclipse descriptors, it adds rhino:js:1.5R4.1 to the classpath. That is wrong, IMO. It should add the dependency to rhino:js:1.6R5 (transitively trough cocoon-core's dependencies). You can see it for yourself by creating all the eclipse descriptors for trunk, and then opening the block cocoon-batik-impl (you'll see the wrong version of rhino:js on the classpath). Is this a known problem, or better, does anybody know how to solve this? Thanks, Bart. -Oorspronkelijk bericht- Van: Daniel Fagerstrom [mailto:[EMAIL PROTECTED] Verzonden: dinsdag 19 december 2006 9:51 Aan: dev@cocoon.apache.org Onderwerp: Re: [2.2] Duplicate (and different) versions of batik on classpath I removed the dependency on batik-1.5-fop, thanks for spotting the problem. I haven't done much testing yet, please report if there are any problems. /Daniel Bart Molenkamp skrev: Hi, I found a problem with the cocoon-batik-impl block. When I add a dependency to this block, I end up with two different versions of Batik on my classpath. The first (and correct) one is batik-1.6-1. But due to a dependency to fop 0.20.5, batik-1.5-fop gets included (which is not compatible with batik-1.6-1). See the snippet below that I got when running maven with the -X option: batik:batik-squiggle:jar:1.6-1:compile (selected for compile) batik:batik-swing:jar:1.6-1:compile (selected for compile) batik:batik-transcoder:jar:1.6-1:compile (selected for compile) fop:fop:jar:0.20.5:compile (selected for compile) xml-apis:xml-apis:jar:1.0.b2:compile (removed - nearer found: 1.3.02) xerces:xercesImpl:jar:2.2.1:compile (removed - nearer found: 2.8.0) batik:batik-1.5-fop:jar:0.20-5:compile (selected for compile) When I run the webapp from the commandline, using the maven jetty plugin, everything seems to work fine. But when I run it in Eclipse (using the Jetty launcher plugin), I get classpath errors. First conflict I found was that of o.a.batik.dom.AbstractDocument.init (constructor signature changed in 1.6-1). After removing batik-1.5-fop jar from my classpath, I ran into another classpath problem. org.apache.cocoon.xml.dom.SVGBuilder accesses the protected member 'namespaces', which is of type org.apache.batik.dom.util.HashTableStack. The signature method 'put' has changed from 'put(String, Object)' to 'put(String, String)'. It looks like the cocoon-batik-impl block is built against batik-1.5-fop, and not batik-1.6-fop. When I exclude batik-1.5-fop as a dependency, everything seems to work fine (but I don't know what functionality of batik requires batik-1.5-fop). It worked either by excluding the dependency from cocoon-batik-impl's pom.xml (but I had to declare the exclusion several times), or when I exclude it from fop-0.20.5.pom (from my local repository). How can this problem be resolved? Anybody interested in the changed pom? Thanks, Bart.
RE: [2.2] Duplicate (and different) versions of batik on classpath
Yes, that works! Thanks!
Bart.
-Oorspronkelijk bericht-
Van: Reinhard Poetz [mailto:[EMAIL PROTECTED]
Verzonden: dinsdag 19 december 2006 11:26
Aan: dev@cocoon.apache.org
Onderwerp: Re: [2.2] Duplicate (and different) versions of batik on
classpath
Bart Molenkamp wrote:
It seems to work. Thanks for that.
However, I think I found another problem related to Eclipse. Batik has a
dependency to rhino:js:1.5R4.1, but cocoon-core has a dependency to
rhino:js:1.6R5. When I build my block, or when I build from the root
pom, Maven builds against 1.6R5 (it removes 1.5R4.1 from the classpath).
This is correct.
But when I build the Eclipse descriptors, it adds rhino:js:1.5R4.1 to
the classpath. That is wrong, IMO. It should add the dependency to
rhino:js:1.6R5 (transitively trough cocoon-core's dependencies).
You can see it for yourself by creating all the eclipse descriptors for
trunk, and then opening the block cocoon-batik-impl (you'll see the
wrong version of rhino:js on the classpath). Is this a known problem, or
better, does anybody know how to solve this?
Try to exclude the dependeny on rhino:js:1.5R4.1 from the batik library
and add
explicitly add the dependency on rhino:js:1.6R5. I haven't tried it myself
but I
guess it could work.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail:
http://mail.yahoo.de
[2.2] Duplicate (and different) versions of batik on classpath
Hi, I found a problem with the cocoon-batik-impl block. When I add a dependency to this block, I end up with two different versions of Batik on my classpath. The first (and correct) one is batik-1.6-1. But due to a dependency to fop 0.20.5, batik-1.5-fop gets included (which is not compatible with batik-1.6-1). See the snippet below that I got when running maven with the -X option: batik:batik-squiggle:jar:1.6-1:compile (selected for compile) batik:batik-swing:jar:1.6-1:compile (selected for compile) batik:batik-transcoder:jar:1.6-1:compile (selected for compile) fop:fop:jar:0.20.5:compile (selected for compile) xml-apis:xml-apis:jar:1.0.b2:compile (removed - nearer found: 1.3.02) xerces:xercesImpl:jar:2.2.1:compile (removed - nearer found: 2.8.0) batik:batik-1.5-fop:jar:0.20-5:compile (selected for compile) When I run the webapp from the commandline, using the maven jetty plugin, everything seems to work fine. But when I run it in Eclipse (using the Jetty launcher plugin), I get classpath errors. First conflict I found was that of o.a.batik.dom.AbstractDocument.init (constructor signature changed in 1.6-1). After removing batik-1.5-fop jar from my classpath, I ran into another classpath problem. org.apache.cocoon.xml.dom.SVGBuilder accesses the protected member 'namespaces', which is of type org.apache.batik.dom.util.HashTableStack. The signature method 'put' has changed from 'put(String, Object)' to 'put(String, String)'. It looks like the cocoon-batik-impl block is built against batik-1.5-fop, and not batik-1.6-fop. When I exclude batik-1.5-fop as a dependency, everything seems to work fine (but I don't know what functionality of batik requires batik-1.5-fop). It worked either by excluding the dependency from cocoon-batik-impl's pom.xml (but I had to declare the exclusion several times), or when I exclude it from fop-0.20.5.pom (from my local repository). How can this problem be resolved? Anybody interested in the changed pom? Thanks, Bart.
RE: [2.2] Debugging and inplace editing
Hi Daniel, This seems to be what I was looking for. Thanks! Bart. -Oorspronkelijk bericht- Van: Daniel Fagerstrom [mailto:[EMAIL PROTECTED] Verzonden: woensdag 13 december 2006 17:30 Aan: dev@cocoon.apache.org Onderwerp: Re: [2.2] Debugging and inplace editing Bart Molenkamp skrev: ... I'm also wondering if there is a way for the jetty plugin to work on the webapp source directory directly (src/main/resources/COB-INF) instead of copying stuff to target/my-block-1.0.0-SNAPSHOT/. For me, it's not really an option to stop/rebuild/start for every sitemap change, flowscript change, etc. Changing sources under target/my-block-1.0.0-SNAPSHOT and copying them back to the source directory isn't really an option for me either. Does someone have a good idea about how to do this? If you use the trunk in Eclipse with the Eclipse-Jetty plugin, it already works in the way you ask for. To make it work you need to ensure that the main webapp has a project dependency on the my-block in Eclipse (e.g. by running mvn eclipse:eclipse from a top level pom). If it has Eclipse will have put the contents of my-block/src/main/resources/ on the classpath used in the main webapp. And the deployer part of Cocoon that is executed during startup will read the COB-INFs directly from classpath in the case where there is a file protocol at the classpath. Only jars are unpacked. See http://marc.theaimsgroup.com/?l=xml-cocoon-devm=116326232408386w=2 for details about the implementation. /Daniel
[2.2] Debugging and inplace editing
Hi, I found three tutorials on the internet about how to debug Maven web applications in Eclipse. All three seem to work to debug Cocoon 2.2 in Eclipse as well (first very basic tests). Here are the links, maybe it's worth linking to them from the Cocoon 2.2 documentation. http://docs.codehaus.org/display/JETTY/Debugging+with+the+Maven+Jetty+Pl ugin+inside+Eclipse http://docs.codehaus.org/display/MAVENUSER/Dealing+with+Eclipse-based+ID E http://mahertb.blogspot.com/2006/08/debugging-maven-web-application-with .html I'm also wondering if there is a way for the jetty plugin to work on the webapp source directory directly (src/main/resources/COB-INF) instead of copying stuff to target/my-block-1.0.0-SNAPSHOT/. For me, it's not really an option to stop/rebuild/start for every sitemap change, flowscript change, etc. Changing sources under target/my-block-1.0.0-SNAPSHOT and copying them back to the source directory isn't really an option for me either. Does someone have a good idea about how to do this? Thanks, Bart.
RE: getComponent with JavaFlow 2.1.9
I've had problems with JavaFlow and classes compiled with debug information (in
Eclipse). You could try to compile without debug information, and see if it
works.
Bart.
-Oorspronkelijk bericht-
Van: Nicolas BOUSSUGE [mailto:[EMAIL PROTECTED]
Verzonden: woensdag 13 december 2006 10:00
Aan: dev@cocoon.apache.org
Onderwerp: getComponent with JavaFlow 2.1.9
Hello,
The users list was maybe not the appropriate list to post my message.
This seems to be a known bug of JavaFlow, according to the TODO.txt I
saw in the javaflow source.
Have the mentionned patches been applied to the jakarta-bcel project in
the 2.1.10 upcoming release ?
Is there a trick to get it to work with the current version ?
Thanks a lot
Best Regards,
Nicolas
Nicolas BOUSSUGE a écrit :
Hello,
I got the following problem in JavaFlow (Cocoon 2.1.9) when trying to
lookup a custom component :
Instruction GETSTATIC constraint violated: Class
'com.test.service.ManagementService' is referenced, but cannot be
loaded and resolved: 'VERIFIED_REJECTED Number of LocalVariableTable
attributes of Code attribute 'CODE' (method 'static void
clinit()') exceeds number of local variable slots '0' ('There may be
no more than one LocalVariableTable attribute per local variable in
the Code attribute.'). '. InstructionHandle: 1: getstatic[178](3) 15
Execution Frame: Local Variables: 0: com.test.flow.java.AdminFlow 1:
unknown object 2: unknown object 3: unknown object 4: unknown
object OperandStack: Slots used: 1 MaxStack: 4.
com.test.flow.java.AdminFlow (Size: 1) Execution flow: 0: aload_0
[InstructionContext] 1: getstatic 15 [InstructionContext]
Then I replaced the lookup as suggested by Torsten in a message on the
mailing list (use a literal String instead of the ROLE), which results
in the following exception :
Instruction CHECKCAST constraint violated: Class
'com.test.service.ManagementService' is referenced, but cannot be
loaded and resolved: 'VERIFIED_REJECTED Number of LocalVariableTable
attributes of Code attribute 'CODE' (method 'static void
clinit()') exceeds number of local variable slots '0' ('There may be
no more than one LocalVariableTable attribute per local variable in
the Code attribute.'). '. InstructionHandle: 6: checkcast[192](3) 21
Execution Frame: Local Variables: 0: com.test.flow.java.AdminFlow 1:
unknown object 2: unknown object 3: unknown object 4: unknown
object OperandStack: Slots used: 1 MaxStack: 4. java.lang.Object
(Size: 1) Execution flow: 0: aload_0 [InstructionContext] 1: ldc 15
[InstructionContext] 3: invokevirtual 17 [InstructionContext] 6:
checkcast 21 [InstructionContext]
Is that a known bug of JavaFlow ? Or did I do something wrong ?
My webapp is running under Tomcat 5.5.20.
Thanks a lot.
Regards,
Nicolas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[2.2] cocoon-batik-impl not working?
Hi, I'm trying to experiment with Cocoon 2.2 and the batik block. But I'm getting an exception: 2006-12-11 13:08:03.375::WARN: Nested in org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from Se rvletContext resource [/WEB-INF/applicationContext.xml]; nested exception is java.lang.NoSuchMethodError: org.apache.avalon.framework.configuration.Default ConfigurationBuilder.build(Ljava/io/InputStream;Ljava/lang/String;)Lorg/ apache/avalon/framework/configuration/Configuration;: java.lang.NoSuchMethodError: org.apache.avalon.framework.configuration.DefaultConfigurationBuilder.bu ild(Ljava/io/InputStream;Ljava/lang/String;)Lorg/apach e/avalon/framework/configuration/Configuration; at org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.loadU RI(ConfigurationReader.java:506) at org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.handl eInclude(ConfigurationReader.java:458) at ... I guess it is the same error like this [1]. Anybody any hint on how to solve this? Thanks, Bart. [1] http://www.mail-archive.com/users@cocoon.apache.org/msg36299.html
RE: [2.2] cocoon-batik-impl not working?
The problem is in fop 0.20.5, which has a dependency to avalon-framework 4.0, ... batik:batik-transcoder:jar:1.6-1:compile (selected for compile) fop:fop:jar:0.20.5:compile (selected for compile) xml-apis:xml-apis:jar:1.0.b2:compile (removed - nearer found: 1.3.02) xerces:xercesImpl:jar:2.2.1:compile (removed - nearer found: 2.8.0) batik:batik-1.5-fop:jar:0.20-5:compile (selected for compile) avalon-framework:avalon-framework:jar:4.0:compile (selected for compile) ... When including the batik block, you can exclude the dependency like you said: dependency groupIdorg.apache.cocoon/groupId artifactIdcocoon-batik-impl/artifactId version1.0.0-SNAPSHOT/version exclusions exclusion groupIdavalon-framework/groupId artifactIdavalon-framework/artifactId /exclusion /exclusions /dependency This works fine, the avalon-framework-4.0.jar is not included with the webapp or block anymore. But I'm wondering, isn't there any global setting that will exclude the jars, no matter from which dependency path they come? Or do I have to declare this for every dependency that includes avalon-framework-4.0.jar? Thanks, Bart. -Oorspronkelijk bericht- Van: Daniel Fagerstrom [mailto:[EMAIL PROTECTED] Verzonden: maandag 11 december 2006 14:15 Aan: dev@cocoon.apache.org Onderwerp: Re: [2.2] cocoon-batik-impl not working? I have had the same problem. What happens is that some of the batik libraries has a transitive dependency on some obsolete version of avalon-framework. Normally, if there are dependencies of several different versions of the same library, the latest of the depended versions will be chosen by Maven. But in this case the old version of avalon is called something like avalon-framework wile the later ones are spit into an api and an implementation part. The also have different group ids. In the end the obsolete Avalon framework versions happens to be earlier in alphabetic order and by consequence before in search order in the classpath. You can test if the above is the problem by look if you have to many Avalon framework libraries in your WEB-INF/lib, and if this is the case remove it and restart. To solve the situation one need to analyze how the obsolete avalon-framework is included in the build. This can be done by building with the -X switch. Then one can use exclude directives in the pom to turn of the inclusion of the jar. /Daniel Bart Molenkamp skrev: Hi, I'm trying to experiment with Cocoon 2.2 and the batik block. But I'm getting an exception: 2006-12-11 13:08:03.375::WARN: Nested in org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from Se rvletContext resource [/WEB-INF/applicationContext.xml]; nested exception is java.lang.NoSuchMethodError: org.apache.avalon.framework.configuration.Default ConfigurationBuilder.build(Ljava/io/InputStream;Ljava/lang/String;)Lorg/ apache/avalon/framework/configuration/Configuration;: java.lang.NoSuchMethodError: org.apache.avalon.framework.configuration.DefaultConfigurationBuilder.bu ild(Ljava/io/InputStream;Ljava/lang/String;)Lorg/apach e/avalon/framework/configuration/Configuration; at org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.loadU RI(ConfigurationReader.java:506) at org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.handl eInclude(ConfigurationReader.java:458) at ... I guess it is the same error like this [1]. Anybody any hint on how to solve this? Thanks, Bart. [1] http://www.mail-archive.com/users@cocoon.apache.org/msg36299.html
RE: [2.2] cocoon-batik-impl not working?
Yes, that solves it. It had an (old) avalon-framework-4.0.jar in the classpath, after removing it, the batik block seems to work fine (from first tests). I'll try to figure out where avalon-framework-4.0.jar is defined. Thanks! Bart. -Oorspronkelijk bericht- Van: Daniel Fagerstrom [mailto:[EMAIL PROTECTED] Verzonden: maandag 11 december 2006 14:15 Aan: dev@cocoon.apache.org Onderwerp: Re: [2.2] cocoon-batik-impl not working? I have had the same problem. What happens is that some of the batik libraries has a transitive dependency on some obsolete version of avalon-framework. Normally, if there are dependencies of several different versions of the same library, the latest of the depended versions will be chosen by Maven. But in this case the old version of avalon is called something like avalon-framework wile the later ones are spit into an api and an implementation part. The also have different group ids. In the end the obsolete Avalon framework versions happens to be earlier in alphabetic order and by consequence before in search order in the classpath. You can test if the above is the problem by look if you have to many Avalon framework libraries in your WEB-INF/lib, and if this is the case remove it and restart. To solve the situation one need to analyze how the obsolete avalon-framework is included in the build. This can be done by building with the -X switch. Then one can use exclude directives in the pom to turn of the inclusion of the jar. /Daniel Bart Molenkamp skrev: Hi, I'm trying to experiment with Cocoon 2.2 and the batik block. But I'm getting an exception: 2006-12-11 13:08:03.375::WARN: Nested in org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from Se rvletContext resource [/WEB-INF/applicationContext.xml]; nested exception is java.lang.NoSuchMethodError: org.apache.avalon.framework.configuration.Default ConfigurationBuilder.build(Ljava/io/InputStream;Ljava/lang/String;)Lorg/ apache/avalon/framework/configuration/Configuration;: java.lang.NoSuchMethodError: org.apache.avalon.framework.configuration.DefaultConfigurationBuilder.bu ild(Ljava/io/InputStream;Ljava/lang/String;)Lorg/apach e/avalon/framework/configuration/Configuration; at org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.loadU RI(ConfigurationReader.java:506) at org.apache.cocoon.core.container.spring.avalon.ConfigurationReader.handl eInclude(ConfigurationReader.java:458) at ... I guess it is the same error like this [1]. Anybody any hint on how to solve this? Thanks, Bart. [1] http://www.mail-archive.com/users@cocoon.apache.org/msg36299.html
[2.2] Where are the samples?
Hi, I want to experiment with Cocoon 2.2. I build Cocoon, and I'm able to start Cocoon by using 'jetty:run' in 'core/cocoon-webapp'. But when I click on the samples page, an empty page shows up (no links to any samples). Did I do something wrong, or aren't there any samples for 2.2 yet? Thanks, Bart.
WidgetValidator can't access upload's value if it was invalid on previous submit
Hi, Why does Upload.getValue() first check if it's valid, and if not, simply returns null? This is a problem for validators that want to access the uploaded file (the Part instance). If I have a required upload field, then submit the form (without uploading any file), the upload widget is invalid (which is correct). Then, when I select a file and submit again (the file will be uploaded) I can't access the part in my validator, as the Upload widget is still invalid. Should there be an alternative method for accessing the part, that doesn't check if the upload widget is valid? This isValid() check before returning the Part is introduced after 2.1.5. Thanks, Bart.
Error on widget state documentation
Hi, I think I just found a small error on the widget state documentation on the Cocoon site: http://cocoon.apache.org/2.1/userdocs/widgetconcepts/widgetstates.html It's contents seems to be duplicated. In Daisy however, things look fine (by following the link at the bottom of the page: http://cocoon.zones.apache.org/daisy/legacydocs/733). Bart.
Can't submit form in Ajax mode
Hi, I'm trying to submit my form in Ajax mode, but I'm getting an exception: java.lang.IllegalStateException: getWriter() has already been called for this response org.apache.coyote.tomcat5.CoyoteResponse.getOutputStream(CoyoteResponse. java:568) org.apache.coyote.tomcat5.CoyoteResponseFacade.getOutputStream(CoyoteRes ponseFacade.java:148) org.apache.cocoon.servlet.CocoonServlet.manageException(CocoonServlet.ja va:1316) org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1202) javax.servlet.http.HttpServlet.service(HttpServlet.java:853) I'm using Cocoon 2.1.9, Tomcat 5.0.27. When I use Jetty (the one bundled with Cocoon) I'm not having this problem. For example, take the example 'samples/blocks/forms/do-sampleTree.flow' (an ajax enabled form with a submit widget). It seems that the submit widget also produces an Ajax request, but I don't think that this is correct. Is there any possibility to disable ajax behaviour on the submit button? Or is there some other problem? Thanks, Bart.
RE: Questions re using SVG in Cocoon
-Oorspronkelijk bericht- Van: hepabolu [mailto:[EMAIL PROTECTED] Anyway it doesn't work and I have no clue how I can include a generated image (i.e. what's its name and location?). Any ideas? If you want to include a generated image in your HTML page by using an img/ tag, you should probably serialize the image to PNG or JPEG. There are serializers for this (batik block). I don't think that you can include an SVG image with an img/ tag (maybe with Firefox 1.5, but certainly not with any version of IE). Otherwise, you can use the embed/ tag, and use a SVG viewer plugin. Should look something like embed height=100% width=300% src=relative/path/to/my/image.svg type=image/svg+xml pluginspage=http://www.adobe.com/svg/viewer/install// (this uses the plugin from adobe). And instead of using a cocoon:// URL, you should just use my-svg-pipeline?parameters=x. Bart.
[jira] Commented: (COCOON-1238) Improvements for CustomJXPathBinding
[ http://issues.apache.org/jira/browse/COCOON-1238?page=comments#action_12364955 ] Bart Molenkamp commented on COCOON-1238: The patch looks good to me. If I look at the files that I have here, they don't look the same as those that I uploaded. I guess I uploaded the wrong files, sorry. Your patch looks pretty much to what I have here, most important is that the statement 'jxpc.getRelativeContext(jxpc.getPointer(this.xpath))' is gone, and is left to the custom binding (this was causing crashes at the time). I do think that this patch breaks backward compatibility, I don't know if that's a big problem. Improvements for CustomJXPathBinding Key: COCOON-1238 URL: http://issues.apache.org/jira/browse/COCOON-1238 Project: Cocoon Type: Improvement Components: Blocks: Forms Versions: 2.1.5 Environment: Operating System: All Platform: All Reporter: Bart Molenkamp Assignee: Jean-Baptiste Quenot Priority: Minor Attachments: 20060201-cocoon-forms-1238, AbstractCustomBinding.java.patch, CustomJXPathBinding.java.patch, CustomJXPathBindingBuilder.java, CustomJXPathBindingBuilder.java.patch 2 improvements: 1. Custom bindings get a service manager when they implement Serviceable. 2. Relative JXPath context is not created. Instead, the current context, and the xpath query are passed to the custom binding. This allows bindings to set values for objects that are null (whereas a getRelativeContext() will throw an exception). Custom bindings now can do a context.createPathAndSetValue(getXpath(), ...) to set a value that was null before setting it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1238) Improvements for CustomJXPathBinding
[ http://issues.apache.org/jira/browse/COCOON-1238?page=comments#action_12365050 ] Bart Molenkamp commented on COCOON-1238: I agree with your point, I don't mind breaking backward compatibility either. But I thought it was worth mentioning it. Improvements for CustomJXPathBinding Key: COCOON-1238 URL: http://issues.apache.org/jira/browse/COCOON-1238 Project: Cocoon Type: Improvement Components: Blocks: Forms Versions: 2.1.5 Environment: Operating System: All Platform: All Reporter: Bart Molenkamp Assignee: Jean-Baptiste Quenot Priority: Minor Attachments: 20060201-cocoon-forms-1238, AbstractCustomBinding.java.patch, CustomJXPathBinding.java.patch, CustomJXPathBindingBuilder.java, CustomJXPathBindingBuilder.java.patch 2 improvements: 1. Custom bindings get a service manager when they implement Serviceable. 2. Relative JXPath context is not created. Instead, the current context, and the xpath query are passed to the custom binding. This allows bindings to set values for objects that are null (whereas a getRelativeContext() will throw an exception). Custom bindings now can do a context.createPathAndSetValue(getXpath(), ...) to set a value that was null before setting it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: Java objects in JX templates
java.lang.ClassNotFoundException:
com/bizzdesign/risks/assessment/UploadedEvidence
org.apache.cocoon.ProcessingException: Failed to execute pipeline.:
file:/app/was/installedApps/riskmanager/riskmanager.ear/riskmanager-1.1.
0.132.war/content/secure/reports/templates/ineffective-controls.xml:104:
93:org.mozilla.javascript.JavaScriptException:
java.lang.ClassNotFoundException:
com/bizzdesign/risks/assessment/UploadedEvidence
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process
XMLPipeline(AbstractProcessingPipeline.java:582)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipe
line.processXMLPipeline(AbstractCachingProcessingPipeline.java:183)
...
Similair exceptions were thrown everywhere, saying that lots of classes
couldn't be found anymore (UploadedEvidence class was only one of them).
The application needed a reboot to get rid of this exception. Seems like
the expression, after being evaluated for several times, messes up the
class loader somehow...
Bart.
-Oorspronkelijk bericht-
Van: Ralph Goers [mailto:[EMAIL PROTECTED]
Verzonden: dinsdag 31 januari 2006 14:48
Aan: dev@cocoon.apache.org
Onderwerp: Re: Java objects in JX templates
Not without a stack trace.
Bart Molenkamp wrote:
I've had problems with the following expression:
jx:when test=${java.lang.Class.forName( \
'com.bizzdesign.risks.assessment.UploadedEvidence'). \
isAssignableFrom(evidence.getClass())}
(the expression is one line).
This expression works, but somehow after calling the page a few
times,
the application hangs. Took me a long time to figure it out. (I've
already solved it, simply by having a method
evidence.isUploadableEvidence() with the expression written in
Java).
Does anybody know what might be going wrong? (I'm just curious)
Bart.
RE: Identifier used in FragmentExtractorTransformer
-Oorspronkelijk bericht- Van: Joerg Heinicke [mailto:[EMAIL PROTECTED] On 25.10.2005 09:06, Bart Molenkamp wrote: ... Besides that I think that caching is done at the pipeline level: if the generator, transformers and the serializer indicate that the cache is valid, then the cached content will be returned and in that content of course the link to the extracted fragment - but the fragment isn't extracted again. FragmentExtractorTransformer and FragmentExtractorGenerator are sitemap components, so where is the problem? So I think that it is just as simple as to generate an unique ID. Maybe some UUID, maybe something with a SecureRandom (like how continuation IDs are generated). Also, I suggested to move this ID generation to a protected method, so that users can override that method in the transformer and implement their own method to generate an ID (won't break the current way that the extractor is working). UUIDs won't solve the problem as they remove any caching as described above or in the bug report. Sorry, but I still don't understand why this breaks caching. The UUID (or whatever ID) generated for the fragment is IMO independent from the cache key. When the pipeline indicates that it's valid, then the cached content (with the generated UUID in it) will be returned, and the UUID won't change, and the same fragment will be looked up from the transient store. But, I also believe that the cache key can solve the problem, and I can see if I can fix this bug using the cache key. Do you need the key from the generator generating the XML in this case? How can this be looked up? And is there a possibility that this key is already used in the store? The protected method can solve the problem, but IMO it should be possible to solve it once for all use cases, not individually by every user. Well, in that case one can always overwrite the method if needed (so I think that this will be a good idea), but I also think that most users (if not all) shouldn't have to worry about this. Bart.
RE: Identifier used in FragmentExtractorTransformer
-Oorspronkelijk bericht- Van: Ralph Goers [mailto:[EMAIL PROTECTED] Breaking caching by generating unique ids doesn't seem like much of a solution. I have pipelines that operate in the same manner that you are describing. The src parameter is the same for every client. I solved it by implementing my own source resolver. It adds something unique about the client to the url that is returned on the get URI call causing each client to have their own copy cached. Ralph You're right, and I don't want to break caching. But I believe the simple solution I proposed doesn't break caching. Bart.
RE: Identifier used in FragmentExtractorTransformer
Hi, -Oorspronkelijk bericht- Van: Joerg Heinicke [mailto:[EMAIL PROTECTED] So what is your solution? I can't find it in the mail archive... They are added as comments to the bug which can now be found at Jira: http://issues.apache.org/jira/browse/COCOON-1148 Jörg (Can it be discussed here, or do I need to add them as comments to the issue too?) I don't totally agree with your latest comment. The CacheValidity won't solve the problem, IMO it's a problem with the ID being generated that is not unique. In my case, the URI for a report is always the same, but the contents of that report is based on who is calling it. Multiple users can call the same URI, each resulting in different content. Suppose: 1. User A requests the report, fragment A is extracted. 2. User B requests the report, fragment B is extracted, and overwrites A because it has the same ID. 3. User A requests the fragment, but gets fragment from user B. 4. User B requests the fragment, and gets his fragment B. A cache validity won't solve this, there is just a need to store multiple fragments in the same store. With a CacheValidity, the following could still happen: User A can request the report, fragment A extracted User B can request the report, report B doesn't have the same validity as report A, so the fragment is replaced. User A requests fragment A, but gets fragment B. User B requests fragment B, and gets fragment B. Besides that I think that caching is done at the pipeline level: if the generator, transformers and the serializer indicate that the cache is valid, then the cached content will be returned and in that content of course the link to the extracted fragment - but the fragment isn't extracted again. So I think that it is just as simple as to generate an unique ID. Maybe some UUID, maybe something with a SecureRandom (like how continuation IDs are generated). Also, I suggested to move this ID generation to a protected method, so that users can override that method in the transformer and implement their own method to generate an ID (won't break the current way that the extractor is working). Am I correct on this? Thanks, Bart.
RE: Identifier used in FragmentExtractorTransformer
So what is your solution? I can't find it in the mail archive... -Oorspronkelijk bericht- Van: Joerg Heinicke [mailto:[EMAIL PROTECTED] Verzonden: vrijdag 21 oktober 2005 23:14 Aan: dev@cocoon.apache.org Onderwerp: Re: Identifier used in FragmentExtractorTransformer On 21.10.2005 08:54, Bart Molenkamp wrote: How is this problem related to caching? It is not that hard for me to provide a patch which just generates a new identifier, but I'm wondering if it breaks caching... It is related to caching as the cache key is only based on the request uri and the fragment id. So with always the same uri and id you will always get the same content from the cache. Unfortunately nobody ever responded to my proposals about fixing it. Jörg Van: Joerg Heinicke Verzonden: donderdag 20 oktober 2005 20:35 My problem is that the id is based on the request uri (and the number of fragments that it extracts during a single transformation). http://issues.apache.org/bugzilla/show_bug.cgi?id=28724
RE: Identifier used in FragmentExtractorTransformer
Hi, How is this problem related to caching? It is not that hard for me to provide a patch which just generates a new identifier, but I'm wondering if it breaks caching... Bart. -Oorspronkelijk bericht- Van: Joerg Heinicke [mailto:[EMAIL PROTECTED] Verzonden: donderdag 20 oktober 2005 20:35 Aan: dev@cocoon.apache.org Onderwerp: Re: Identifier used in FragmentExtractorTransformer On 20.10.2005 15:15, Bart Molenkamp wrote: My problem is that the id is based on the request uri (and the number of fragments that it extracts during a single transformation). The problem is that the contents of an XML document, and the content of the SVG image in that document (some chart generated from a database query) is different for each user calling that page. But the request uri is always the same, thus the ID for each extracted fragment is also always the same, resulting in each extracted fragment being overwritten in the transient store. This has some nasty side-effects, e.g. when using the browser's back button, or even the possibility to have charts displayed from other users. Therefore, I think it is good to change the way that id's are generated. I was thinking to move the current ID generating code into a protected method, and those who want other ID generation can extend the transformer and overwrite the method. Is this a good idea, and if so, shall I provide a patch? Can it be applied before the 2.1.8 release? http://issues.apache.org/bugzilla/show_bug.cgi?id=28724 Jörg
Identifier used in FragmentExtractorTransformer
Hi all, I have a little problem with the FragmentExtractorTransformer. This transformer extracts XML parts (by default SVG), stores it in the transient store and replaces the XML parts with id's. My problem is that the id is based on the request uri (and the number of fragments that it extracts during a single transformation). The problem is that the contents of an XML document, and the content of the SVG image in that document (some chart generated from a database query) is different for each user calling that page. But the request uri is always the same, thus the ID for each extracted fragment is also always the same, resulting in each extracted fragment being overwritten in the transient store. This has some nasty side-effects, e.g. when using the browser's back button, or even the possibility to have charts displayed from other users. Therefore, I think it is good to change the way that id's are generated. I was thinking to move the current ID generating code into a protected method, and those who want other ID generation can extend the transformer and overwrite the method. Is this a good idea, and if so, shall I provide a patch? Can it be applied before the 2.1.8 release? Thanks, Bart.
RE: Startable components
-Oorspronkelijk bericht- Van: Sylvain Wallez [mailto:[EMAIL PROTECTED] Verzonden: maandag 17 oktober 2005 18:30 Aan: dev@cocoon.apache.org Onderwerp: Startable components Hi all, I changed the lazy loading so that preload=true is no more needed for components that *must* be loaded at startup time. Why are marker interfaces preferred over this configuration style? These interfaces introduce another dependency on Avalon. I think it is better to not have these code dependencies, but to use configuration. This makes it easier to host those components in other containers as well, such as Spring. Same for the ThreadSafe marker interface, the Initializable and the Disposable interfaces (configure a method to do initialization/disposing of the object instead of implementing an interface). And I thought that people here rather move away from Avalon's interfaces. Then why introduce another dependency on it, when configuration can do the same? Just curious. Bart.
RE: Startable components
-Oorspronkelijk bericht- Van: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Bart Molenkamp wrote: Why are marker interfaces preferred over this configuration style? These interfaces introduce another dependency on Avalon. I think it is better to not have these code dependencies, but to use configuration. This makes it easier to host those components in other containers as well, such as Spring. Same for the ThreadSafe marker interface, the Initializable and the Disposable interfaces (configure a method to do initialization/disposing of the object instead of implementing an interface). And I thought that people here rather move away from Avalon's interfaces. Then why introduce another dependency on it, when configuration can do the same? Yes, I tend to agree with you. So let's forget about the new interface and use the preload flag. With 2.2 you can configure an init method, a dispose method, the type of the component (thread safe, poolable) in the cocoon.xconf and you don't have to use the interfaces anymore. Upto now we are just not using it. Carsten Ah, that sound great! I didn't knew that, thanks. Bart.
RE: Startable components
-Oorspronkelijk bericht- Van: Sylvain Wallez [mailto:[EMAIL PROTECTED] Verzonden: dinsdag 18 oktober 2005 10:18 Aan: dev@cocoon.apache.org Onderwerp: Re: Startable components Carsten Ziegeler wrote: Bart Molenkamp wrote: Why are marker interfaces preferred over this configuration style? These interfaces introduce another dependency on Avalon. I think it is better to not have these code dependencies, but to use configuration. This makes it easier to host those components in other containers as well, such as Spring. Same for the ThreadSafe marker interface, the Initializable and the Disposable interfaces (configure a method to do initialization/disposing of the object instead of implementing an interface). And I thought that people here rather move away from Avalon's interfaces. Then why introduce another dependency on it, when configuration can do the same? Yes, I tend to agree with you. So let's forget about the new interface and use the preload flag. With 2.2 you can configure an init method, a dispose method, the type of the component (thread safe, poolable) in the cocoon.xconf and you don't have to use the interfaces anymore. Upto now we are just not using it. And I don't think we should be using it. As said in my previous post, Avalon has always used interfaces to specify the lifecycle. Moving this information in the configuration brings the responsibility of defining the lifestyle to configuration writers that up to now never had to care about it. Also, most of them don't understand all the details or implications of these settings. That's the exact reason that led us to support automatic preloading with maker interfaces. Other containers such as Spring chose another way by requiring everything to be specified in the configuration file (autowiring not the default and its use is not really encouraged [1]). These containers bring a lot of interesting features which is why we integrate them in Cocoon, but require configuration writers to know a lot more about the details of components. Considering that many or our users aren't J2EE developers, my opinion is that by default, system-level Cocoon components should be as simple to configure as possible, i.e. people should only have to care about settings, but not lifecycle or wiring. Sylvain I understand that both the configuration and the marker interface options are working, great. But I'm still not satisfied by your answer, sorry. My points: 1. I don't see that much difference between a developer and a configuration writer. Knowing the configuration settings of a component can also require (deep) knowledge about the implementation. And, configuration writers don't need to write the configuration from scratch, the already configured defaults are sufficient. 2. To configure a component, knowledge about it is required anyways. Looking at the configuration of CForms for example, there is quite some configuration, but not much for a regular user to change (all those builders etc - which I think is great that it is configurable). For regular Cocoon users, I think the default configuration that comes with a Cocoon build is sufficient in many, many cases (again, I don't think users write configuration files from scratch). 3. There is a dependency on Avalon, a project that is closed, and this project wanting to move away from it (at least that is my impression). This doesn't encourage me to use the Avalon interfaces, it rather scares me to use them. Configuration gives me much more feeling that I'm not tied in to Avalon, and can migrate to another container with less effort. 4. The way I learned to write components is by looking at the sources of Cocoon. So shouldn't the code show how it is supposed to be (for new and/or recently updated components), instead of how it always was? Thanks, Bart.
RE: [RT] Are svn externals a good idea?
I think svn:external is used correctly in this case, when used without specifying a revision number. I think the revision number should be set only when creating a tag for a specific version (e.g. when creating a tag for Cocoon 2.1.8). Or, maybe it works when copying the forms block into the tagged version, when creating a tag. E.g. something like: $ svn copy http://.../branches/2_1_X http://.../tags/2.1.8 $ svn copy http://.../blocks/forms/trunk \ http://.../tags/2.1.8/src/blocks/forms Maybe a simple script could do this. Bart. -Oorspronkelijk bericht- Van: Sylvain Wallez [mailto:[EMAIL PROTECTED] Verzonden: woensdag 28 september 2005 10:20 Aan: dev@cocoon.apache.org Onderwerp: Re: [RT] Are svn externals a good idea? Niclas Hedhman wrote: On Tuesday 27 September 2005 22:14, Sylvain Wallez wrote: I don't know however what happens if we commit changes to a svn:external with a sticky tag. Does it create a branch? If yes, then that may be a problem. Neither sticky tags nor branches exists in Subversion. I think you guys are using the wrong tool for what you are trying to achieve. Ok. So do you have something better, or another way to organize the svn repository that would avoid to maintain parallel branches [1] of blocks. Sylvain [1] http://svnbook.red-bean.com/en/1.1/ch04s02.html -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
ClassNotFoundExceptions after using FOPSerializer
Hi, I've run into a very weird problem. After generating a PDF page, our web application breaks, and reports ClassNotFoundExceptions. The exceptions look like: java.lang.ClassNotFoundException: com/bizzdesign/risks/assessment/UploadedEvidence It looks like somewhere before, during or after the PDF serialization, the classloader changes and can't find any classes in WEB-INF/lib anymore. When this problem happens, I need to restart the web application, otherwise it keeps reporting these errors. This error only happens on AIX/Websphere 5.1. Serializing to PDF works correctly on Windows XP/Tomcat and Windows XP/Websphere 5.1. Anyone seen this error before using FOP? Thanks, Bart.
RE: [2.1.8-dev] Real exception is not logged anymore
-Oorspronkelijk bericht- Van: Sylvain Wallez [mailto:[EMAIL PROTECTED] HEY PEOPLE, can someone else check this also? Using JDK 1.4.2_05-b04. The exception seems to be logged correctly in cocoon.log: ERROR (2005-09-23) 11:05.22:363 [sitemap.handled-errors] (/samples/blocks/portal/portal?cocoon-portal-event=7) PoolThread-4/ErrorHandlerHelper: Failed to process pipeline at map:serialize type=html-include - file:/C:/Documents%20and%20Settings/b.molenkamp/Mijn%20documenten/test/c ocoon-2.1.8-dev/build/webapp/samples/blocks/portal/sitemap.xmap:220:47 at map:transform type=encodeURL - file:/C:/Documents%20and%20Settings/b.molenkamp/Mijn%20documenten/test/c ocoon-2.1.8-dev/build/webapp/samples/blocks/portal/sitemap.xmap:215:44 at map:transform type=portal-new-eventlink - file:/C:/Documents%20and%20Settings/b.molenkamp/Mijn%20documenten/test/c ocoon-2.1.8-dev/build/webapp/samples/blocks/portal/sitemap.xmap:214:55 at map:transform type=portal-coplet - file:/C:/Documents%20and%20Settings/b.molenkamp/Mijn%20documenten/test/c ocoon-2.1.8-dev/build/webapp/samples/blocks/portal/sitemap.xmap:213:48 at map:transform type=cinclude - file:/C:/Documents%20and%20Settings/b.molenkamp/Mijn%20documenten/test/c ocoon-2.1.8-dev/build/webapp/samples/blocks/portal/sitemap.xmap:212:43 at map:transform - file:/C:/Documents%20and%20Settings/b.molenkamp/Mijn%20documenten/test/c ocoon-2.1.8-dev/build/webapp/samples/blocks/portal/sitemap.xmap:207:83 at map:generate type=portal - file:/C:/Documents%20and%20Settings/b.molenkamp/Mijn%20documenten/test/c ocoon-2.1.8-dev/build/webapp/samples/blocks/portal/sitemap.xmap:206:56 at map:mount - file:/C:/Documents%20and%20Settings/b.molenkamp/Mijn%20documenten/test/c ocoon-2.1.8-dev/build/webapp/samples/blocks/sitemap.xmap:66:68 at map:mount - file:/C:/Documents%20and%20Settings/b.molenkamp/Mijn%20documenten/test/c ocoon-2.1.8-dev/build/webapp/samples/sitemap.xmap:190:65 at map:mount - file:/C:/Documents%20and%20Settings/b.molenkamp/Mijn%20documenten/test/c ocoon-2.1.8-dev/build/webapp/sitemap.xmap:894:66 org.apache.avalon.framework.configuration.ConfigurationException: Type 'xslt2' is not defined for 'transform' at file:/C:/Documents%20and%20Settings/b.molenkamp/Mijn%20documenten/test/c ocoon-2.1.8-dev/build/webapp/samples/blocks/portal/coplets/gallery/sitem ap.xmap:36:55 at org.apache.cocoon.components.treeprocessor.DefaultTreeBuilder.getTypeFor Statement(DefaultTreeBuilder.java:572) at org.apache.cocoon.components.treeprocessor.sitemap.TransformNodeBuilder. buildNode(TransformNodeBuilder.java:44) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeB uilder.buildChildNodesList(AbstractParentProcessingNodeBuilder.java:121) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeB uilder.buildChildNodes(AbstractParentProcessingNodeBuilder.java:136) at org.apache.cocoon.components.treeprocessor.sitemap.MatchNodeBuilder.buil dNode(MatchNodeBuilder.java:77) .
RE: [RT] Are svn externals a good idea?
You can specify a revision within the svn:external property. Something like (got this sample from the svn book): -Oorspronkelijk bericht- Van: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Verzonden: vrijdag 23 september 2005 11:49 Aan: Cocoon-Dev Onderwerp: [RT] Are svn externals a good idea? I'm just wondering if svn externals are a good idea wrt to versioning. I just had to checkout an older version of 2.1.8-dev and checked out that particular revision. Now unfortunately, the jcr block (and now the forms block) is linked into the tree using a svn external. And although I checked out an old version of the cocoon tree, I get the latest version from the jcr block. So it's not that easy to get the exact version of the whole tree. Or is there an easy way? And what does this mean wrt to tagging a release (which is a copy of the source tree)? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
RE: [RT] Are svn externals a good idea?
Sorry, hit the send button too early... You can specify a revision within the svn:external property. Something like (got this sample from the svn book): third-party/skins/toolkit -r21 http://svn.red-bean.com/repos/skin-maker So I think, when you've labelled cocoon 2.1.8, you should change the svn:externals property in that tag one more time an let it point to the CForms block with the same revision number as the revision that committed the tagging of version 2.1.8, right? Bart. -Oorspronkelijk bericht- Van: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Verzonden: vrijdag 23 september 2005 11:49 Aan: Cocoon-Dev Onderwerp: [RT] Are svn externals a good idea? I'm just wondering if svn externals are a good idea wrt to versioning. I just had to checkout an older version of 2.1.8-dev and checked out that particular revision. Now unfortunately, the jcr block (and now the forms block) is linked into the tree using a svn external. And although I checked out an old version of the cocoon tree, I get the latest version from the jcr block. So it's not that easy to get the exact version of the whole tree. Or is there an easy way? And what does this mean wrt to tagging a release (which is a copy of the source tree)? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
RE: [2.1.8-dev] Real exception is not logged anymore
Ok, I just did an SVN update, and the behaviour changed... First, there was a change in the web interface. Previously, I just saw the cocoon stacktrace, reporting that the sitemap could not be built because of the 'xslt2' that is unknown. Now, the portal page gets rendered, and I just see The coplet Gallery-Petstore is currently not available.. Has this something to do with it? Also, the exception is not logged in cocoon.log anymore, but something is logged in portal.log. Not the original exception, but just a processing exception: WARN(2005-09-23) 11:48.35:275 [portal] (/samples/blocks/portal/portal) PoolThread-4/AbstractCopletAdapter: Unable to get content of coplet: Gallery-Petstore org.apache.cocoon.ProcessingException: Failed to load sitemap from file:/C:/Documents and Settings/b.molenkamp/Mijn documenten/test/cocoon-2.1.8-dev/build/webapp/samples/blocks/portal/copl ets/gallery/sitemap.xmap at [ConfigurationException] - file:/C:/Documents%20and%20Settings/b.molenkamp/Mijn%20documenten/test/c ocoon-2.1.8-dev/build/webapp/samples/blocks/portal/coplets/gallery/sitem ap.xmap:39:55 at map:mount - file:/C:/Documents%20and%20Settings/b.molenkamp/Mijn%20documenten/test/c ocoon-2.1.8-dev/build/webapp/samples/blocks/portal/coplets/sitemap.xmap: 27:65 at map:mount - file:/C:/Documents%20and%20Settings/b.molenkamp/Mijn%20documenten/test/c ocoon-2.1.8-dev/build/webapp/samples/blocks/portal/sitemap.xmap:181:76 at org.apache.cocoon.portal.coplet.adapter.impl.URICopletAdapter.streamCont ent(URICopletAdapter.java:134) at org.apache.cocoon.portal.coplet.adapter.impl.CachingURICopletAdapter.str eamContent(CachingURICopletAdapter.java:165) at org.apache.cocoon.portal.coplet.adapter.impl.CachingURICopletAdapter.str eamContent(CachingURICopletAdapter.java:120) at org.apache.cocoon.portal.coplet.adapter.impl.AbstractCopletAdapter.toSAX (AbstractCopletAdapter.java:162) at org.apache.cocoon.portal.source.CopletSource.toSAX(CopletSource.java:169 ) Hope this helps, Bart. -Oorspronkelijk bericht- Van: Bart Molenkamp Verzonden: vrijdag 23 september 2005 11:39 Aan: dev@cocoon.apache.org Onderwerp: RE: [2.1.8-dev] Real exception is not logged anymore -Oorspronkelijk bericht- Van: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Are you build all blocks or are you excluding some? I'm using the default config. Carsten The default configuration. Just a clean checkout from SVN, and build it without changing anything. Bart.
Dependency injection in Cocoon 2.1
Hi, I want to get rid of the Avalon interfaces in my code. Is there something like dependency injection (e.g. setter injection or constructor injection - similar to Spring framework) possible using ECM? (ECM is the component engine of Cocoon, right?) I couldn't find anything, so I started a little experiment on my own. I wrote a class ComponentHandlerImpl. This class implements all the Avalon lifecycle interfaces. For each component, I define this class as my default class: role name=com.bizzdesign.components.Hello shorthand=hello default-class=com.bizzdesign.components.ComponentHandlerImpl/ role name=com.bizzdesign.components.World shorthand=world default-class=com.bizzdesign.components.ComponentHandlerImpl/ The ComponentManagerImpl class also implements Configurable, and uses that configuration to get the name of the target class. It creates a new instance of that class, and uses the configuration too set dependencies. Something like: hello target-class=com.bizzdesign.components.HelloImpl property name=world ref=com.bizzdesign.components.World/ /hello world target-class=com.bizzdesign.components.WorldImpl /world These are used to set dependences. The ComponentHandlerImpl will lookup the source resolver (using the regular service manager), then invoke setWorld() on the HelloImpl instance with the resolved World instance as an argument (just an example). I could easily add similair methods to replace Initializable, Disposable, Contextualizable, ... Positives: - cleaner code, not dependent on any Avalon interfaces. Thus reusable in other environments, probably in the 2.2 environment too. - allows for (unit) testing. - user interception for components is possible (e.g. one could introduce an AOP framework or something similair). - Avalon is still working Negatives: - When resolving the Hello component, we get an instance of ComponentHandlerImpl. I have to call getTarget() to get the actual component. Is something (which is not much in code) worthy to add to Cocoon? Or did I overlook some feature that already handles this? Bart.
[CForms] Plain convertor for Enum datatype is null, throws NPE for MultiValueFields
Hi,
I have a multi-value field widget, with datatype enum (so that users can
select 0 or more values from an enum). But, when I load my object model
in the form (setting the enum values from my model into the formmodel),
then show the form, I get a NullPointerException in
MultiValueField.generateItemSaxFragment, line 135.
It tries to use the plain convertor from the Enum datatype. But this
plain convertor is null, because in the EnumTypeBuilder, line 80, it
tries to build the plain convertor:
plainConvertor = plainConvertorBuilder.build(null);
The builder is an EnumConvertorBuilder, which always returns null,
because the argument to build is always null:
public Convertor build(Element configElement) throws Exception {
if (configElement == null) {
return null;
}
...
Is this correct, or is it a bug?
I think that the multi-value widget shouldn't use the plain convertor,
but the convertor defined in the datatype definition of the widget. That
contains the correct convertor widget. It could fall-back to the plain
convertor if the datatype's convertor is null.
Thanks,
Bart
RE: CForms stabilization tasks (was Re: Marking cforms stable in 2.1.8)
-Oorspronkelijk bericht- Van: Leszek Gawron [mailto:[EMAIL PROTECTED] 5 - flatten the configuration to allow for easier extension with the xconf include mechanism in 2.2 I could give it a shot but I have no deeper knowledge of cocoon.xconf syntax in this case. Do we have to make every widget a component? That doesn't feel right. Every widget is created from a WidgetDefinition, and every WidgetDefinition is build by a WidgetDefinitionBuilder. These builders are setup as components, and from there it's the builders, and the definitions that determine how a specific widget should be setup. So not every widget will be a component. I think sylvain means that users can easily add their builders etc (not just for widgets, but also for bindings, or maybe datatypes, or convertors, or...) to the forms configuration. Bart.
RE: Weird multithreading bug in Cron block
A little bit off-toptic, but some time ago I used the pipeline machinery to generate mail-content for users, somewhere at night by a CRON job. For each user, the pipeline was called and the results were sent to that user. Processing such a pipeline from CRON took about 2 seconds for each mail, while calling that pipeline (trough the CocoonServlet), processing was done in less than 0.5 seconds. And after processing that pipeline 100 times (for 100 users), an OutOfMemoryError was thrown. Any idea if this is related to your environment problems (CRON has it's own environment, right?) Bart. -Oorspronkelijk bericht- Van: Sylvain Wallez [mailto:[EMAIL PROTECTED] Verzonden: dinsdag 7 juni 2005 19:03 Aan: dev@cocoon.apache.org Onderwerp: Weird multithreading bug in Cron block Hi all, I'm currently working on a publication application with complex database queries where we want to prefetch some of the pages linked to by the page currently being produced, in order to speed up response time on pages that are likely to be asked for by users. To achieve this, we have a PrefetchTransformer that grabs elements having a prefetch=true attribute and starts a background job to load the corresponding src or href URL using a cocoon:. At first I used JobScheduler.fireJob() to schedule for immediate execution, but went into *weird* bugs with strange NPEs all around in pipeline components. After analysis, it appeared that while the scheduler thread was processing the pipeline, the http thread was recycling the *background environment*, thus nulling the object model and other class attributes used by pipeline components. I spent the *whole day* trying to find the cause for this, without success (how frustrating). Then I decided to try another approach and use JobScheduler.fireJobAt(new Date()), meaning schedule the job for later execution... now!. And it worked! Weird, weird, weird! Anybody having a hint about why fireJob() is doing this environment mixture? Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
RE: ValidationAware forms
-Oorspronkelijk bericht-
Van: Reinhard Poetz [mailto:[EMAIL PROTECTED]
Verzonden: vrijdag 3 juni 2005 9:46
Aan: dev@cocoon.apache.org
Onderwerp: ValidationAware forms
AFAICS the widget Form doesn't implement ValidationAware. Is there a
special
reason why this feature hasn't been added yet?
I'm not sure, but I think it is because a form doesn't have a visual
representation in HTML, where other widgets do have a visual representation.
Where should CForms place the error marker (the red !) for a form?
I agree that it will be helpful to have this feature. And I think that
repeaters are a similar case (aren't ValidationErrorAware either, but I have
cases here where I want it to hold an error instead of creating a messages
widget).
I was asked this in some of my trainings and IIRC there have been some
questions
on [EMAIL PROTECTED] My usual answer is adding an error widget that can
contain
the error. Is this our 'official' recommendation or are there better ways
to
achieve this?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
RE: ValidationAware forms
Van: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Bart Molenkamp wrote:
I'm not sure, but I think it is because a form doesn't have a visual
representation in HTML, where other widgets do have a visual
representation. Where should CForms place the error marker (the red
!)
for a form?
That's exactly the reason: only widgets who have a visual
representation
can be made validation-aware, as otherwise we don't know how/where to
display the error.
I agree that it will be helpful to have this feature. And I think
that
repeaters are a similar case (aren't ValidationErrorAware either, but
I
have cases here where I want it to hold an error instead of creating a
messages widget).
The form1 sample has a validator on the contacts repeater, which
checks uniqueness of {firstName,lastName} on the various rows. If a
duplicate is found, the error is set on the offending row as its the
most precise location indicating to the user where the problem is.
Attaching the error to the repeater itself would make finding the
problem more difficult.
It would be nice to set an error on the repeater if it has no rows, and
at
least one row is required.
The same reasoning can be applied to the form object. Since an error
means the user has to change something, then we'd better indicate
precisely what should be changed. Now in some cases the error can be
of
type either change this _or_ change that and that's where the
message
widget is usefull.
Hmm...
Now there's also the little-known ft:validation-error template
instruction that outputs the validation error or any given widget.
This
can be a good replacement of the message widget, and would allow
non-visual widgets to be ValidationAware.
WDYT?
So, then all widgets can implement ValidationErrorAware. For most
widgets, the forms-styling.xsl knows how to display the error. For the
other, special
cases we could use ft:validation-error to display the error. Am I
correct
on this?
If so, it seems like a good solution to me.
Bart.
RE: [CForms] Field definitions aren't contextualizable
Why isn't the org.apache.cocoon.components.LifecycleHelper used? That should hide all those details. -Oorspronkelijk bericht- Van: Sylvain Wallez [mailto:[EMAIL PROTECTED] Verzonden: maandag 16 mei 2005 18:22 Aan: dev@cocoon.apache.org Onderwerp: Re: [CForms] Field definitions aren't contextualizable Ugo Cei wrote: In trying to implement a CAPTCHA validator for CForms, I found out that I needed to to store an attribute in the session from a field definition builder and I discovered that even if my class extending AbstractDatatypeWidgetDefinitionBuilder implemented Contextualizable, its contextualize method was never called. After a little debugging, I discovered that the DefaultFormManager instantiates a SimpleComponentSelector directly but does not contextualize it. So, the SimpleComponentSelector cannot contextualize the widget builders that it creates in turn. OK, to make it short, I locally did a quick fix (against 2.1.8-dev): Index: src/blocks/forms/java/org/apache/cocoon/forms/DefaultFormManager.java === --- src/blocks/forms/java/org/apache/cocoon/forms/DefaultFormManager.java (revision 170351) +++ src/blocks/forms/java/org/apache/cocoon/forms/DefaultFormManager.java (working copy) @@ -104,6 +104,7 @@ manager.release(service); } }); + widgetDefinitionBuilderSelector.contextualize(avalonContext); widgetDefinitionBuilderSelector.configure(configuration.getChild(widget s )); } I'm not sure this is the right thing to do. Would someone who is more knowledgeable of CForms internals please review this, so that I can apply it? Looks ok, except that contextualize() comes before service() in the Avalon lifecycle. Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
RE: [CForms] having more control over showing/processing a form
Ok, thanks!
Bart.
-Oorspronkelijk bericht-
Van: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Verzonden: donderdag 12 mei 2005 19:04
Aan: dev@cocoon.apache.org
Onderwerp: Re: [CForms] having more control over showing/processing a
form
Bart Molenkamp wrote:
Well, I still have a little problem. Your solution works fine, as
long
as I add submit widgets to the form definition. This works fine for
many
case for me, but I still have a case where this isn't a solution.
I have a form, and on that form there are two date fields, and an
update
action. Every time the user clicks on the update button, a query
occurs
in the database and each result is presented as a hyperlink. Clicking
on
that link will show all the details for that database record. I can't
make submit widgets for every record available, so the solution you
proposed won't work in this case.
You can use a single fd:submit id=show-details validate=false/
and
an additional non-widget detail-id request parameter.
The links should be
(submit-url)?form_submit_id=show-detailsdetail-id=1234
And the flowscript:
form.showForm(pipeline);
if (form.submitId == show-details) {
showDetails(cocoon.request.getParameter(detail-id));
}
Sylvain
--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research Technology Director
RE: [CForms] having more control over showing/processing a form
Does it answer your need? Yes it does, thank you! Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director Bart.
RE: [CForms] having more control over showing/processing a form
Well, I still have a little problem. Your solution works fine, as long as I add submit widgets to the form definition. This works fine for many case for me, but I still have a case where this isn't a solution. I have a form, and on that form there are two date fields, and an update action. Every time the user clicks on the update button, a query occurs in the database and each result is presented as a hyperlink. Clicking on that link will show all the details for that database record. I can't make submit widgets for every record available, so the solution you proposed won't work in this case. Does this case make sense to add the two functions? Thanks, Bart. -Oorspronkelijk bericht- Van: Bart Molenkamp Verzonden: donderdag 12 mei 2005 11:26 Aan: dev@cocoon.apache.org Onderwerp: RE: [CForms] having more control over showing/processing a form Does it answer your need? Yes it does, thank you! Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director Bart.
[CForms] having more control over showing/processing a form
Hi all,
Currently, in flowscript, you display a form by calling
form.showForm(uri). This function loops until the form is successfully
processed. There is, as far as I can see, no way to get between there.
I wonder if it would be useful to define two more functions in Form.js,
that allow me to have better control over displaying/processing a form.
E.g. something like:
var form = new Form(form.xml);
...
var finished = false;
do {
form.showPage(form-template.xml);// show the form only once.
if (user clicked some link) {
...
// dome something else
} else {
finished = form.process(); // process the form only once.
}
} while (!finished);
In this case, I do the looping that is otherwise done in the
form.showForm() function. But now I have more control over the form
flow. And, form.showForm() still exists and can be built using the above
two new methods.
I can make this change. Would it be valuable addition for CForms, or
not?
Thanks,
Bart.
RE: Fork Xalan?
Can you tell when this error occurs? Or what to do to avoid it? Bart. -Original Message- From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] Sent: Thursday, April 14, 2005 3:17 PM To: Cocoon Developers Subject: Fork Xalan? Hey guys, Here is controversial thought: may be we should fork Xalan? I'm tired of this java.lang.RuntimeException: java.lang.NullPointerException at org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:34 18 ) crap... Vadim
Mock for org.apache.ojb.odmg.OJB required?
Hi all, The OJB block contains a mock for org.apache.ojb.odmg.OJB. Is this one needed, as db-ojb.jar is in lib/optional and that library contains the real class? Thanks, Bart.
RE: [FYI] How IE handles PDFs
Hi, -Original Message- From: depub2 [mailto:[EMAIL PROTECTED] ... Give IEx the opportunity to cache. In particular, ensure the server does not set any headers causing IEx not to cache the content. This may be a real problem if the document is sent over HTTPS, because most IEx installations will by default not cache any content retrieved over HTTPS. Setting the Expires header entry may help in this case: response.setDateHeader(Expires, System.currentTimeMillis() + cacheExpiringDuration * 1000); Consult your server manual and the relevant RFCs for further details on HTTP headers and caching. We had to set two HTTP headers explicitly to be able to download anything (binary data) that couldn't be handled natively by IE. It was indeed a problem with the cache. IE downloads the file, removes it and then tries to open it (or some similair care). This is a known problem in IE, but doesn't seem to be such a big problem to fix it... I wrapped the cocoon servlet, and overwrite the headers. But maybe it's better to do this in a filter. Here are the headers (I don't know which and how you can change these headers; once they worked for me, I was scared to change them ;) Pragma: public Cache-control: max-age=0 Hope this can help anyone! Bart. Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
RE: AbstractResourceReader?
Hi, First, sorry for my late reply, and for my horrible planning (adding this just before a release ;-). I've created the StreamReader (discussed here [1]). I've copied the ResourceReader, and made modifications where required: where the ResourceReader uses a source, I use (configurable) JXPath expressions to look up the information required: * the input stream * the mime type * the content length. The implementation can be found here [2]. The rest of the code is copied from the ResourceReader implementation, and could thus be shared in an abstract class. For example, an AbstractResourceReader class which has three methods: getInputStream() getContentLength() getMimeType() - already required by a Reader, right? The current resource reader can implement these methods with the source it looks up. The StreamReader can implement these methods and return values found by Xpath expressions. I can make the change, if it is a good idea of course (other ideas are also welcome). Please let me know what others think. Thanks, Bart. [1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110872385503566w=2 [2] http://issues.apache.org/bugzilla/attachment.cgi?id=14534action=edit -Original Message- From: Alfred Nathaniel [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 02, 2005 5:30 PM To: dev@cocoon.apache.org Subject: Re: AbstractResourceReader? On Wed, 2005-03-02 at 15:38, Bart Molenkamp wrote: Hi, A while ago I was discussing how to build a reader that could get it's input stream from the context object using JXPath. It gets the following information from the context object using configurable Xpath expressions: - the content stream - the mime type - the content length I've created the reader by simply copying the existing ResourceReader and replaced all the code where a Source was used to use the content input stream, the content length and the content type that are passed in the context object. The reader is working this way, but I was wondering if it makes sense to create another abstract reader that handles things that are common to the ReasourceReader and the StreamReader (the reader I've created). It concers many HTTP specific code such as byte range, content expiration, etc. I've used all that code (only difference is that my reader isn't cacheable, don't know how to generate a key yet). Can someone tell me what code would be common (as I don't have specific knowledge about these http byte range, expiration etc things), or if it doesn't make sense at all. Bart. I think it would be more elegant to wrap your input stream in a Source object (StreamSource extends o.a.excalibur.source.impl.AbstractSource). Then your StreamReader can extend ResourceReader and just needs to override the setup method. However, ResourceReader.setup must be refactored to move the inputSource resolving into a separate method which a derived class can override. Otherwise StreamReader.setup cannot call super.setup. This is necessary not only to avoid duplicating the parameter decoding in ResourceReader.setup but also because you would need to call super.super.setup which is not allowed in Java. Cheers, Alfred.
RE: cocoon:// protocol and map:mount
Maybe you're using a file://... source in one of the generator/transformer components behind the pipeline? And maybe a little bit off-topic, but from a CRON job (CRON thread), the cocoon:// source resolving is extremely slow and causes OutOfMemory errors (in my use-case, I used the cocoon:/ source for generating personal mails for each individual user in our system). Bart. -Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Sent: Monday, March 21, 2005 4:04 PM To: dev@cocoon.apache.org Subject: Re: cocoon:// protocol and map:mount Gianugo Rabellino wrote: Actually no, I used cocoon:/. However, changing it with cocoon:// causes a SourceNotFoundException, with Cocoon seemingly using a file:// URL to resolve the inputstream, which is even weirder... does it rely on SourceResolver at all? Yes, it does :( - hmm, so this is really a bug. Can you file it to bugzilla, so it doesn't get lost? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
AbstractResourceReader?
Hi, A while ago I was discussing how to build a reader that could get it's input stream from the context object using JXPath. It gets the following information from the context object using configurable Xpath expressions: - the content stream - the mime type - the content length I've created the reader by simply copying the existing ResourceReader and replaced all the code where a Source was used to use the content input stream, the content length and the content type that are passed in the context object. The reader is working this way, but I was wondering if it makes sense to create another abstract reader that handles things that are common to the ReasourceReader and the StreamReader (the reader I've created). It concers many HTTP specific code such as byte range, content expiration, etc. I've used all that code (only difference is that my reader isn't cacheable, don't know how to generate a key yet). Can someone tell me what code would be common (as I don't have specific knowledge about these http byte range, expiration etc things), or if it doesn't make sense at all. Bart.
RE: JX generates weird NameSpace???
Hi Tibor, I had the same problems, also with the combination JX template/Cforms. I couldn't figure out where these namespaces were generated, but I suspected it was somewhere in the Xalan transformer. I used Saxon and these namespaces where gone. HTH, Bart. -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of oceatoon Sent: Friday, February 25, 2005 6:43 PM To: dev@cocoon.apache.org Subject: JX generates weird NameSpace??? Hi everyone Is anybody aware of such a thing as JX generating a weirds namespaces?? head xmlns:[EMAIL PROTECTED]@#=[EMAIL PROTECTED]@# weird !! and blocking...g This seems to happen only on a cforms / jx mixed page, I tested simple jx is ok. Offcourse this is blocking all following transformations I'd really appreciate any info on this coz this busts my forms ;-) Best Regards Tibor
RE: Write binary data to output stream from flow
-Original Message-
From: Upayavira [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 17, 2005 5:19 PM
To: dev@cocoon.apache.org
Subject: Re: Write binary data to output stream from flow
Bart Molenkamp wrote:
Hi,
Is it possible to write binary data to the HTTP response directly
from
the flow? I have an InputStream available in my flow, and I want to
serve data from that stream directly to the HTTP response. E.g.
cocoon.sendBinaryData(inputStream, application/octet-stream);
Or something similar.
I solved it now by creating a SourceFactory and Source
implementation,
so that I can use a plain reader, but this feels a bit like
overkill.
The SourceFactory has to lookup the data from the database (that is
where the data is for the input stream), and the URL contains the
primary key to get the data from the database.
To my knowledge there isn't a way to do this directly. But you could
place the inputstream into a request attribute or some such, and pick
that up from your source, rather than reading the database again.
Am I understanding your question right?
Regards, Upayavira
Hi Upayavira,
I don't know if I understood your answer. Maybe I'm not clear enough
about my question, so I'll try again.
In my flowscript, I get a java.io.InputStream instance, and the content
that I read from it can be sent to the user directly. The user thinks
that it is downloading a file (which he is) but the source comes from a
database (but the database is transparent due to OJB). In my case, I
have a review object which can hold 0 or more downloaded files (files
are evidence that support the result of the review):
...
review = ...; // get review from database trough OJB
cocoon.sendPageAndWait(list-evidence.xml,
{evidence: review.getEvidence()});
...
evidenceId = cocoon.request.get(evidenceId);
evidence = review.getEvidenceById(evidenceId);
evidenceDataStream = evidence.getInputStream();
mimeType = evidence.getMimeType();
// now I want to serve the input stream to the user
// e.g. something like
cocoon.sendBinaryData(evidenceDataStream, mimeType);
How can I now read this input stream, and pass it's data to the output
stream of a pipeline, in a simple way. Currently, I have an evidence
source that I can lookup. The URL contains the ID of the review, and the
ID of the evidence. Something like evidence://reviewid/evidenceid.txt
Hope this clarifies my question a little bit more.
RE: Write binary data to output stream from flow
Yes, it makes even better sense.
Would such a more generic, JXPath oriented stream reader be a valuable
contribution to Cocoon?
Bart.
-Original Message-
From: Upayavira [mailto:[EMAIL PROTECTED]
Sent: Friday, February 18, 2005 11:06 AM
To: dev@cocoon.apache.org
Subject: Re: Write binary data to output stream from flow
Bart Molenkamp wrote:
Ok, sorry, I didn't understand you but now it makes perfect sense.
Thanks for your advise!
Well, I had a chance to express myself more clearly, and think it
through a bit more.
Basically, what you're doing is implementing another way to connect
the
controller to the view, when the view is pretty simple.
I would tend to implement this as a custom reader, actually, with code
like:
map:components
map:readers
map:reader name=stream class=.
stream-name/stream/stream-name
mime-type-name/mimeType/mime-type-name
/map:reader
/map:readers
/map:components
map:match pattern=my-stream-uri
map:read type=stream/
/map:match
That way, you're configuring the reader to know where in the flow
business objects to get the stream and the mime type. As the context
object from flow comes back as just an Object (presumably could be
some
kind of javascript object as well), you would do well to use JXPath to
get at the values, hence specifying the names of these values as XPath
expressions.
You end up with something more generic component that way that isn't
specifically targetted at your problem.
Make sense?
Regards, Upayavira
-Original Message-
From: Upayavira [mailto:[EMAIL PROTECTED]
Sent: Friday, February 18, 2005 10:37 AM
To: dev@cocoon.apache.org
Subject: Re: Write binary data to output stream from flow
Bart Molenkamp wrote:
-Original Message-
From: Upayavira [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 17, 2005 5:19 PM
To: dev@cocoon.apache.org
Subject: Re: Write binary data to output stream from flow
Bart Molenkamp wrote:
Hi,
Is it possible to write binary data to the HTTP response directly
from
the flow? I have an InputStream available in my flow, and I want
to
serve data from that stream directly to the HTTP response. E.g.
cocoon.sendBinaryData(inputStream, application/octet-stream);
Or something similar.
I solved it now by creating a SourceFactory and Source
implementation,
so that I can use a plain reader, but this feels a bit like
overkill.
The SourceFactory has to lookup the data from the database (that
is
where the data is for the input stream), and the URL contains the
primary key to get the data from the database.
To my knowledge there isn't a way to do this directly. But you
could
place the inputstream into a request attribute or some such, and
pick
that up from your source, rather than reading the database again.
Am I understanding your question right?
Regards, Upayavira
Hi Upayavira,
I don't know if I understood your answer. Maybe I'm not clear
enough
about my question, so I'll try again.
In my flowscript, I get a java.io.InputStream instance, and the
content
that I read from it can be sent to the user directly. The user
thinks
that it is downloading a file (which he is) but the source comes
from a
database (but the database is transparent due to OJB). In my case,
I
have a review object which can hold 0 or more downloaded files
(files
are evidence that support the result of the review):
...
review = ...; // get review from database trough OJB
cocoon.sendPageAndWait(list-evidence.xml,
{evidence: review.getEvidence()});
...
evidenceId = cocoon.request.get(evidenceId);
evidence = review.getEvidenceById(evidenceId);
evidenceDataStream = evidence.getInputStream();
mimeType = evidence.getMimeType();
// now I want to serve the input stream to the user
// e.g. something like
cocoon.sendBinaryData(evidenceDataStream, mimeType);
How can I now read this input stream, and pass it's data to the
output
stream of a pipeline, in a simple way. Currently, I have an
evidence
source that I can lookup. The URL contains the ID of the review,
and
the
ID of the evidence. Something like
evidence://reviewid/evidenceid.txt
That is exactly what I took from what you were saying. And, as it
currently stands, there is no way to send data other than via a
pipeline. So, what I would say is:
cocoon.sendPage(my-binary-url, {stream: evidenceDataStream,
mimeType: mimeType});
map:match pattern=my-binary-url
map:read src=evidence:/
/map:match
Then, in your source, you can use o.a.c.components.flow.FlowHelper
to
get the stream and mimetype business objects, and have your source
use
them. I'm not up on this enough to give you exact details, but if I
were
to try to achieve this, this is probably how I would go about it.
Am I making sense now?
Regards, Upayavira
RE: Write binary data to output stream from flow
-Original Message- From: Upayavira [mailto:[EMAIL PROTECTED] Sent: Friday, February 18, 2005 11:20 AM To: dev@cocoon.apache.org Subject: Re: Write binary data to output stream from flow Bart Molenkamp wrote: Yes, it makes even better sense. Would such a more generic, JXPath oriented stream reader be a valuable contribution to Cocoon? To me it would. Anyone else think so, or have some reasons against? In fact, the object you pass to the reader (via the XPath string), should not be the input stream, but some object that has a getInputStream method. That would make better sense. If the object in the context is a bean, the path ./inputStream will make JXPath invoke getInputStream(), right? And the same for mimeType of course. So this leaves the user to make the decision if he passes an object which has a getInputStream() method, or if he passes the stream directly. And the reader could check to see if the object has a getMimeType() method, and if so, get the mime type from that. It should also be possible to configure the mime type in the component definition or via the map:read mime-type=xxx approach, or however the ResourceReader currently works. Regards, Upayavira Bart.
RE: Write binary data to output stream from flow
Maybe it is even better to have a source that can lookup mimeType, contentLength, inputStream from the context using JXPath expressions? Then one could use the ResourceReader to serve the content, and use the source in other places as well. The only difficult thing would be to configure the Xpath expressions... Would that be a good idea? -Original Message- From: Upayavira [mailto:[EMAIL PROTECTED] Sent: Friday, February 18, 2005 11:47 AM To: dev@cocoon.apache.org Subject: Re: Write binary data to output stream from flow Bart Molenkamp wrote: -Original Message- From: Upayavira [mailto:[EMAIL PROTECTED] Sent: Friday, February 18, 2005 11:20 AM To: dev@cocoon.apache.org Subject: Re: Write binary data to output stream from flow Bart Molenkamp wrote: Yes, it makes even better sense. Would such a more generic, JXPath oriented stream reader be a valuable contribution to Cocoon? To me it would. Anyone else think so, or have some reasons against? In fact, the object you pass to the reader (via the XPath string), should not be the input stream, but some object that has a getInputStream method. That would make better sense. If the object in the context is a bean, the path ./inputStream will make JXPath invoke getInputStream(), right? And the same for mimeType of course. So this leaves the user to make the decision if he passes an object which has a getInputStream() method, or if he passes the stream directly. Guess so, yes. But it must be possible to configure the mime type manually via the sitemap as well as having it provided by the flowscript. Regards, Upayavira
Write binary data to output stream from flow
Hi, Is it possible to write binary data to the HTTP response directly from the flow? I have an InputStream available in my flow, and I want to serve data from that stream directly to the HTTP response. E.g. cocoon.sendBinaryData(inputStream, application/octet-stream); Or something similar. I solved it now by creating a SourceFactory and Source implementation, so that I can use a plain reader, but this feels a bit like overkill. The SourceFactory has to lookup the data from the database (that is where the data is for the input stream), and the URL contains the primary key to get the data from the database. Anyone any idea? Bart.
RE: [RT] How scripting made me hate java
Niclas Hedhman wrote: On Wednesday 16 February 2005 07:06, Sylvain Wallez wrote: Something that doesn't help also is the fact that our foundations are maintained and documented (or not) elsewhere, at Excalibur. This includes the Avalon framework interfaces and SourceResolver, Store, XML utils, etc. Only the framework API is available online. So, should we copy the javadoc of Excalibur component frameworks we use in our own repo to make this information more accessible? Why not use SVN's more exotic features of external linking, and plainly include the Excalibur codebase (source that is) as part of Cocoon? You all have commit access to it, and it is not likely that the Excalibur community will make any big changes in the future, and unlikely to object to any changes made from Cocoon committers. Are you referring to the svn:external property? Would it be a problem that we have to include using https and not http? Anyway, if we can make this work, this would be a great idea! Maybe completely off-topic, but here is my idea: Maybe it is even better to just copy it into the Cocoon codebase. Both codebases are in the same physical SVN repo, right? Then a copy won't take much space, and you're independent from changes to Excalibur. When changes to excalibur are required, you can make them in the Cocoon codebase, and when the Excalibur community makes changes to their codebase that is required in Cocoon, it should be possible to merge those changes into the Cocoon code base (merge with the changes you've made). It's a bit like a vendor branch, I guess... [1] Bart. [1] http://svnbook.red-bean.com/en/1.0/ch07s04.html
RE: [RT] How scripting made me hate java
-Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 16, 2005 3:14 PM To: dev@cocoon.apache.org Subject: Re: [RT] How scripting made me hate java Big -1 Not knowing where the code is is bad, having to versions that claim to be the same things in different parts of the repository is way worse. Again, maybe completely off-topic, but could you explain why you give a -1? Yes, when making a copy you see a version of the codebase in two places in the repository, but it also allows committers to change the codebase for the Cocoon specific needs, without interfering with the original codebase. And new versions of the original codebase can be merged into the copied codebase without losing (if people know what they're doing) their changes. I am just curious, because I use vendor branches myself for managing my changes to the Cocoon codebase (very small changes). Bart.
[FIX] WebSphere 5.1, Cocoon 2.1, JCL
Hi all, I've managed to get Cocoon 2.1 working on WebSphere 5.1. That's not very special, as many threads in mail-archives specify how to realize this, and the page on the Wiki [1] also tells me how to do this. Only one problem remained for me. Because class-loading mode is set to PARENT_LAST, classes are loaded from the webapplication before classes are loaded from the container. Cocoon uses JCL (Jakarta Commons Logging), but WebSphere does too. And that gives a problem, because WebSphere configures a LogFactory (TrLogFactory) which is in conflict with the JCL shipped with Cocoon. I guess it is because of two incompatible versions of JCL? I don't know actually, as I can't see what the version of JCL shipped with WebSphere is. This can be very easily solved by re-setting JCL's log factory. This is explained here [2]. I've just created a file in WEB-INF/classes, called commons-logging.properties and added the following property to it: org.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.Lo gFactoryImpl Now everything (seems to) work fine. I only have a few questions remaining: 1. Is it useful to add this file to the classpath, so that JCL always finds the correct log factory? 2. I guess it would be good to document it. Can I add it to the wiki page myself (I guess so, but just asking to be sure)? 3. I'm not familiar with Cocoon's logging system. When and where is JCL used? Where does it try to load a LogFactory class? And is the class org.apache.commons.logging.impl.LogFactoryImpl correct? Thanks, Bart. [1] http://wiki.apache.org/cocoon/WebSphereV5_2e0Deployment [2] http://www-1.ibm.com/support/docview.wss?uid=swg27004610
RE: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
http://c2.com/cgi/wiki?YouArentGonnaNeedIt -Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 08, 2004 4:53 PM To: [EMAIL PROTECTED] Subject: Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF Leszek Gawron wrote: about 2nd: YAGNI (thanks Stefano for new cool phrase :)) I guess it was Sylvain that introduced me to it, so thank him :-) -- Stefano.
RE: Stripping the Cocoon source tree
Hi Jorg, Thanks for your reply. Ok, so maven helps downloading the correct version of Cocoon a specific version of your application. That solves a part of the problem. But what if you need to make a change to some Cocoon classes, or apply a patch (and for some reason you are forced to maintain it in your repository e.g. because there is a chance that the patch won't be applied in the Cocoon SVN repository before you release your project)? Bart. -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Jorg Heymans Sent: Wednesday, December 01, 2004 10:46 AM To: [EMAIL PROTECTED] Subject: Re: Stripping the Cocoon source tree Bart Molenkamp wrote: Hi all, I'm also very curious how other people include Cocoon in their repositories for their Cocoon-based applications (just a guess that many of you guys use Cocoon for other projects). The entire source tree, or just the build (binary), or not at all? We use maven and define the cocoon version to be used in the projectdefinition. When a new release comes out, we build the cocoon jars with all blocks, rename them to adhere to maven conventions and upload them to our local maven proxy. HTH Jorg
RE: i18n and CForms
Hi Jeremy, I also had that problem. My guess was that is has something to do with the I18n transformer, which gives a problem if more than one catalogue is configured. If you have only one catalogue, and add the contents of FormsMessages.xml to it, it should work. Bart. -Original Message- From: Jeremy Quinn [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 3:08 PM To: [EMAIL PROTECTED] Subject: i18n and CForms Hi All I am finding that the default FormsMessages that come with CForms do not appear to be working in 2.1.7-dev. My default browser locale (I tried both Safari and Firefox) is 'en_US', so should be using context://samples/blocks/forms/messages/FormsMessages.xml. This is not happening, either in my own usage or in the samples for CForms. So for instance, instead of getting the message This field is required. I get general.field-required indicating that the lookup failed. Interestingly, even after I copied FormsMessages.xml to FormsMessages_en_US.xml and restarted Cocoon, it still did not work. I also tried setting Firefox to say my locale was 'fr', it still did not work. The i18n Samples work fine. Any ideas anyone? Can anyone else reproduce this? regards Jeremy If email from this address is not signed IT IS NOT FROM ME Always check the label, folks !
RE: i18n and CForms
Hmm that does work for me. I'm using Cocoon 2.1.6-dev (from August 8th, if I'm correct) for that. I thought it was a configuration error on my side when I wanted to use two catalogues (like you, use the forms catalogue to stay up to date), but it didn't work so I simply copied the contents to my own catalogue. Another thing about my configuration: my I18n transformer is declared almost in the root sitemap, so that my whole application is using that configured transformer (so I have to define the catalogue locations only once). I don't think it should make any difference anyway. Hi Bart, This is a problem, as I always use more than one catalogue :) I like to rely on the built-in catalogue for generic validation messages, so that I am always up to date with changes to CForms, and my own catalogue for form-specific labels, hints, help, titles etc. Anyway, I tried copying the contents of FormsMessages.xml to my own catalogue and it still did not work. regards Jeremy
OutOfMemoryError using cocoon:/ protocol
Hi all, Small description of my use-case: I have a cron job that runs once every night to send emails to users of my application. The content of the mail is generated from a cocoon:/ source (which uses some flowscript and the JXTemplate generator to generate the content). Content is different for every user, so there is a loop, and for every user, content is generated by resolving a cocoon:/ source. But everytime a cocoon:/ source is resolved, memory on my machine increases but doesn't decrease (I do use resolver.release()). In the end, it results in an OutOfMemoryError. Besides that, it is slow (which is also a problem of my flowscript), could this be a cause too? Thanks, Bart.
fd:output with enum datatype does not surround the enum value with i18n:text tags
Hi all, I have a fd:output widget, with an enum as datatype. When showing the widget, it doesn't place i18n:text tags around the enum value. When I change the fd:output to fd:field, and add fi:styling type=hidden/ it does surround the enum values with the i18n:text tags. Is this a short-coming in CForms? I suppose it needs to be added to the CForms transformer if so. Bart.
RE: 2.1.6 is broken
You're right, it is broken. I found that the cocoon-ojb-block.jar is 1 k in size; it only contains 2 files in meta-inf/ I'm not familiar with Cocoon's build system, but the OJB block has a build.xml file in the root of the block, could this break the building of OJB? I've tried to remove it, then rebuild Cocoon, but it has no effect. Why is the jar empty? Bart. -Original Message- From: Butler, Mark H (Labs Bristol) [mailto:[EMAIL PROTECTED] Sent: Monday, November 08, 2004 6:33 PM To: [EMAIL PROTECTED] Subject: 2.1.6 is broken Hi team I've been trying to build 2.1.6 for most of today, to try to identify the problem Antonio found when applying the DELI patch. Cocoon builds ok, but it doesn't work, it just throws a stack trace as shown below: Is anyone else experiencing this? I'd like to get this sorted so I can get the latest DELI patch in version 2.1.6? thanks, Mark Initialization Problem Message: org.apache.cocoon.ojb.odmg.components.OdmgImplementationImpl Description: org.apache.avalon.framework.configuration.ConfigurationException: Could not get class Sender: org.apache.cocoon.servlet.CocoonServlet Source: Cocoon Servlet cause java.lang.ClassNotFoundException: org.apache.cocoon.ojb.odmg.components.OdmgImplementationImpl request-uri / full exception chain stacktrace org.apache.avalon.framework.configuration.ConfigurationException: Could not get class at org.apache.avalon.excalibur.component.ExcaliburComponentManager.configur e(ExcaliburComponentManager.java:456) at org.apache.avalon.framework.container.ContainerUtil.configure(ContainerU til.java:240) at org.apache.cocoon.Cocoon.configure(Cocoon.java:447) at org.apache.cocoon.Cocoon.initialize(Cocoon.java:304) at org.apache.avalon.framework.container.ContainerUtil.initialize(Container Util.java:283) at org.apache.cocoon.servlet.CocoonServlet.createCocoon(CocoonServlet.java: 1382) at org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:480) at org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:220) at org.mortbay.jetty.servlet.ServletHandler.initializeServlets(ServletHandl er.java:445) at org.mortbay.jetty.servlet.WebApplicationHandler.initializeServlets(WebAp plicationHandler.java:150) at org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationCont ext.java:458) at org.mortbay.http.HttpServer.start(HttpServer.java:663) at org.mortbay.jetty.Server.main(Server.java:429) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at Loader.invokeMain(Unknown Source) at Loader.run(Unknown Source) at Loader.main(Unknown Source) Caused by: java.lang.ClassNotFoundException: org.apache.cocoon.ojb.odmg.components.OdmgImplementationImpl at java.net.URLClassLoader$1.run(URLClassLoader.java:199) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.mortbay.http.ContextLoader.loadClass(ContextLoader.java:207) at org.mortbay.http.ContextLoader.loadClass(ContextLoader.java:171) at org.apache.avalon.excalibur.component.ExcaliburComponentManager.configur e(ExcaliburComponentManager.java:442) ... 19 more stacktrace java.lang.ClassNotFoundException: org.apache.cocoon.ojb.odmg.components.OdmgImplementationImpl at java.net.URLClassLoader$1.run(URLClassLoader.java:199) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.mortbay.http.ContextLoader.loadClass(ContextLoader.java:207) at org.mortbay.http.ContextLoader.loadClass(ContextLoader.java:171) at org.apache.avalon.excalibur.component.ExcaliburComponentManager.configur e(ExcaliburComponentManager.java:442) at org.apache.avalon.framework.container.ContainerUtil.configure(ContainerU til.java:240) at org.apache.cocoon.Cocoon.configure(Cocoon.java:447) at org.apache.cocoon.Cocoon.initialize(Cocoon.java:304) at org.apache.avalon.framework.container.ContainerUtil.initialize(Container Util.java:283) at org.apache.cocoon.servlet.CocoonServlet.createCocoon(CocoonServlet.java: 1382) at org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:480) at
