Re: including multiple xml files into transformation
Mark Lundquist wrote:
The use of document() in Cocoon is discouraged, because it doesn't
play nice with cache validity. If the content supplied by the
included resource changes, Cocoon has no way of knowing it and will
serve stale content from the cache.
What if I only reference static files, as in document('data.xml'), and
not Cocoon urls? I just did a test and there doesn't seem to be any
cache problem, probably because the XSLT processor reads the file from
disk every time. Is this kind of usage discouraged/inefficient?
Tobia
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: including multiple xml files into transformation
Mark Lundquist wrote:
The use of document() in Cocoon is discouraged, because it doesn't
play nice with cache validity. If the content supplied by the
included resource changes, Cocoon has no way of knowing it and will
serve stale content from the cache.
What if I only reference static files, as in document('data.xml'), and
not Cocoon urls? I just did a test and there doesn't seem to be any
cache problem, probably because the XSLT processor reads the file from
disk every time.
You should have the same problem as Mark already described. My two cents about
your things, is that you aren't caching the result at all, therefor changing
the stylesheet does take affect (do you caching pipeline and are all used
components cacheable, at least all before the xsl transformation?)
Is this kind of usage discouraged/inefficient?
Well, if your file on disk never changes anymore after deployment, it is not
really a problem. Though, when your cocoon cache works, every change in this
file implies you have to empty the cache to have the change take effect. So
yes, IMO, I would discourage it very much. Inefficient, perhaps during
development because of clearing the cache, but not on pruduction
Ard
Tobia
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: including multiple xml files into transformation
Daniel Süpke wrote: xml1 is the generator with all the contents for the overall-structure of the page, being transformed by some xsl-file. The contents has various block with headings etc. Inside these blocks I want to parse external xml-files, which contain the actual data to be represented. I know of two easy ways to accomplish it. Maybe there are more. 1. Cocoon's CInclude transformer Use the Include transformer, it is much more efficient Ard You can use an xsl file to add cinclude tags to the relevant blocks in the first file, then pass it all through the cinclude transformer, then maybe through another xsl transformation, to prune unnecessary tags left over from the cinclude step. 2. XSLT's (actually XPath's) document() function The document() function allows you to access more than one xml source file from within a XSLT. See for example the styleless stylesheet approach (it was on some blog... I don't have the link handy right now) Toby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: including multiple xml files into transformation
2. XSLT's (actually XPath's) document() function The document() function allows you to access more than one xml source file from within a XSLT. See for example the styleless stylesheet approach (it was on some blog... I don't have the link handy right now) Hi guys, The use of document() in Cocoon is discouraged, because it doesn't play nice with cache validity. If the content supplied by the included resource changes, Cocoon has no way of knowing it and will serve stale content from the cache. At least, that was the case at one time, and as far as I know it still is. Yes it still is, and I do not see it changed in near future. There is no real solution for it at the moment. Ard best regards, —ml— - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Writing form data to an XML file
I'm passing the results of the form demo into some code in
registration_success.jx
to write the form data to an XML file. Having got it working,
I now need
to find
out how to get rid of the text which appears in the browser after the
success message:
success entire source overwritten write overwritten
file:/usr/local/apache-tomcat-5.5.12/webapps/ROOT/myformtest/a
bc.xml xml
Obviously it's a trace from somewhere...but where? My
registration_success.jx says:
You just need an xsl transformation after the writing of the source. You are
now just showing the result of the source writer
Ard
?xml version=1.0?
html
head
titleRegistration successful/title
/head
body
pRegistration was successful for ${username} on ${date}!/p
source:write xmlns:source=http://apache.org/cocoon/source/1.0;
source:sourcecontext://myformtest/${username}.xml/source:source
source:fragment
data
date -mm-dd=${date}/
/data
/source:fragment
/source:write
/body
/html
///Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Which one to use Cocoon 2.1 or 2.2?
Thanks everybody for your opinions. I think I am going to use 2.2 for my Proof-Of-Concept. Cocoon is really, really amazing; the more I read the greater it is perceived, now it just up to grasp all the different concepts and technologies. Thanks again! Mikael On 1/6/07, Carsten Ziegeler [EMAIL PROTECTED] wrote: Personally I've found 2.2 works just fine already, as long as you're not concerned about API/configuration stability. There will be a new milestone release of 2.2 very soon; we are very confident that this one is the last milestone release before a final 2.2 release which means that there should be no API changes anymore (or only minor ones). At least that's our hope :) Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem running the WebDAV sample block from Cocoon 2.2 TRUNK (2006-01-05 19:00 UTC)
On 1/6/07, Joerg Heinicke [EMAIL PROTECTED] wrote: On 05.01.2007 22:04, Mikael Olenfalk wrote: java.lang.ClassNotFoundException: org.apache.cocoon.generation.JXTemplateGenerator The correct class name is now org.apache.cocoon.template.JXTemplateGenerator. I have changed the following in /block/cocoon-webdav/cocoon-webdav-sample/../COB-INF/davmap: --- sitemap.xmap2007-01-06 00:02:28.643272000 +0100 +++ sitemap.xmap~ 2007-01-06 00:02:28.643272000 +0100 @@ -31,7 +31,7 @@ pool-max=16 / map:generator name=jx -src=org.apache.cocoon.template.JXTemplateGenerator +src=org.apache.cocoon.generation.JXTemplateGenerator logger=generator.jx pool-max=16 / Now I didn't really expect it to work at once (wouldn't that be too easy :) ) These are the new errors I am getting (what I think is the real error is marked by ). org.apache.cocoon.ProcessingException: Error calling function selectMethod at [script] - file:/home/mikael/Desktop/COCOON-2.2/cocoon-2.2-svn/trunk/core/cocoon-webapp/target/work/blocks/cocoon-webdav-sample/davmap/webdav.js:20 at map:call - file:/home/mikael/Desktop/COCOON-2.2/cocoon-2.2-svn/trunk/core/cocoon-webapp/target/work/blocks/cocoon-webdav-sample/davmap/sitemap.xmap:129:43 at map:match - file:/home/mikael/Desktop/COCOON-2.2/cocoon-2.2-svn/trunk/core/cocoon-webapp/target/work/blocks/cocoon-webdav-sample/davmap/sitemap.xmap:128:36 at map:mount - file:/home/mikael/Desktop/COCOON-2.2/cocoon-2.2-svn/trunk/core/cocoon-webapp/target/work/blocks/cocoon-webdav-sample/sitemap.xmap:46:49 at map:match - file:/home/mikael/Desktop/COCOON-2.2/cocoon-2.2-svn/trunk/core/cocoon-webapp/target/work/blocks/cocoon-webdav-sample/sitemap.xmap:45:33 at map:mount - file:/home/mikael/Desktop/COCOON-2.2/cocoon-2.2-svn/trunk/core/cocoon-webapp/target/cocoon-webapp/blocks/sitemap.xmap:22:63 at map:match - file:/home/mikael/Desktop/COCOON-2.2/cocoon-2.2-svn/trunk/core/cocoon-webapp/target/cocoon-webapp/blocks/sitemap.xmap:21:33 at map:mount - file:/home/mikael/Desktop/COCOON-2.2/cocoon-2.2-svn/trunk/core/cocoon-webapp/target/cocoon-webapp/sitemap.xmap:289:47 at map:match - file:/home/mikael/Desktop/COCOON-2.2/cocoon-2.2-svn/trunk/core/cocoon-webapp/target/cocoon-webapp/sitemap.xmap:288:31 at org.apache.cocoon.ProcessingException.throwLocated(ProcessingException.java:143) at org.apache.cocoon.components.flow.javascript.LocationTrackingDebugger.getException(LocationTrackingDebugger.java:111) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.callFunction(FOM_JavaScriptInterpreter.java:601) at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:109) 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: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
catalog resolution for xsl:import in cocoon transformer not working for me
Hello: I am just getting back into Cocoon after a long hiatus. I am using cocoon 2.1.10 on JDK 1.5 via Jetty server on Windows XP. I have an xslt file with the following import: txsl:import href=-//OASIS//XSL HTML DocBook V5.0//EN which I am trying to resolve using a catalog file: PUBLIC -//OASIS//XSL HTML DocBook V5.0//EN thirdparty/docbook-xsl.1.71.1/xhtml/docbook.xsl The xslt is invoked as part of a very simple pipeline: map:transform src=context://src/com/arielpartners/knowledgebase/xsl/paper-html.xsl I receive the following error message: java.io.FileNotFoundException: C:\ade\src\com\arielpartners\knowledgebase\xsl\-\OASIS\XSL HTML DocBook V5.0\EN (The system cannot find the path specified) So obviously the entity is not being resolved. I believe my situation is unique because I use Docbook specializations that are accomplished by overriding certain docbook XSLT rules (and therefore importing docbook). This technique works perfectly in Ant using the xmlcatalog type. Shouldn't this work in cocoon? Has anyone gotten something like this to work? I searched the archives and documentation and couldn't find any examples that matched my usage pattern. I guess my alternative would be to re-write my xslt as a preprocessor or postprocessor on the docbook xslt output and do it in a two stage pipeline...? Thanks in advance! --Craeg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Writing form data to an XML file
Ard Schrijvers wrote: Obviously it's a trace from somewhere...but where? My registration_success.jx says: You just need an xsl transformation after the writing of the source. You are now just showing the result of the source writer What markup format is returned by the writing of the source (ie what element types do I have to provide for in my transformation)? ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem running the WebDAV sample block from Cocoon 2.2 TRUNK (2006-01-05 19:00 UTC)
On 05.01.2007 22:04, Mikael Olenfalk wrote: java.lang.ClassNotFoundException: org.apache.cocoon.generation.JXTemplateGenerator The correct class name is now org.apache.cocoon.template.JXTemplateGenerator. Why did this move? Strangely enough, cocoon-2.1.10 does not complain about org.apache.cocoon.generation.JXTemplateGenerator, but the JXTemplateGenerator does not seem to work properly. org.apache.cocoon.template.JXTemplateGenerator does work. Ard Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Writing form data to an XML file
Just change your serializer to xml (or add a cocoon view) and see the xml output in your browser. Then, you know what kind of xsl you need to write (watch out for the namespaces probably) Ard Ard Schrijvers wrote: Obviously it's a trace from somewhere...but where? My registration_success.jx says: You just need an xsl transformation after the writing of the source. You are now just showing the result of the source writer What markup format is returned by the writing of the source (ie what element types do I have to provide for in my transformation)? ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: catalog resolution for xsl:import in cocoon transformer not working for me
Are you talking about an xsl:import? If so, sounds to me that the import simply cannot be found. But probably, I do not entirely grasp your problem Ard Hello: I am just getting back into Cocoon after a long hiatus. I am using cocoon 2.1.10 on JDK 1.5 via Jetty server on Windows XP. I have an xslt file with the following import: txsl:import href=-//OASIS//XSL HTML DocBook V5.0//EN which I am trying to resolve using a catalog file: PUBLIC -//OASIS//XSL HTML DocBook V5.0//EN thirdparty/docbook-xsl.1.71.1/xhtml/docbook.xsl The xslt is invoked as part of a very simple pipeline: map:transform src=context://src/com/arielpartners/knowledgebase/xsl/paper-html.xsl I receive the following error message: java.io.FileNotFoundException: C:\ade\src\com\arielpartners\knowledgebase\xsl\-\OASIS\XSL HTML DocBook V5.0\EN (The system cannot find the path specified) So obviously the entity is not being resolved. I believe my situation is unique because I use Docbook specializations that are accomplished by overriding certain docbook XSLT rules (and therefore importing docbook). This technique works perfectly in Ant using the xmlcatalog type. Shouldn't this work in cocoon? Has anyone gotten something like this to work? I searched the archives and documentation and couldn't find any examples that matched my usage pattern. I guess my alternative would be to re-write my xslt as a preprocessor or postprocessor on the docbook xslt output and do it in a two stage pipeline...? Thanks in advance! --Craeg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Writing form data to an XML file
Ard Schrijvers wrote: Just change your serializer to xml (or add a cocoon view) Duh. I knew this of course. Thanks...it's a Monday morning...:-( ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Running cocoon as tomcat user on port 80
I've been running Cocoon as root while testing but I clearly don't want to do this for an open production server which will be writing to the server disk. How do I allow running it as the tomcat user but still binding to port 80? ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Aggregate fields
I'd like to be able to present a single form field (HTML input) for the gathering of a user's full name, but be able to split it into forename and surname. The aggregatefield appears to be designed for this, but the documentation provides no details on templating it. fd:aggregatefield id=organiser required=true fd:widgets fd:field id=forename required=true fd:labelForename/fd:label fd:datatype base=string/ /fd:field fd:field id=surname required=true fd:labelSurname/fd:label fd:datatype base=string/ /fd:field /fd:widgets fd:split pattern=\([^\ ]*\)\ \([^\ ]*\) fd:map group=1 field=forename/ fd:map group=1 field=surname/ /fd:split fd:combine expression=forename surname/ /fd:aggregatefield However, in the form template, if I say tr tdft:widget-label id=organiser//td tdft:widget id=organiser//td /tr it understandably complains that there is no widget organiser. What have I misunderstood? ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Running cocoon as tomcat user on port 80
On 1/8/07, Peter Flynn [EMAIL PROTECTED] wrote: ... How do I allow running it as the tomcat user but still binding to port 80?.. Using an apache HTTPD server with mod_proxy as the front end brings a lot of advantages IMHO, see http://wiki.apache.org/cocoon/ApacheModProxy httpd would then listen on port 80 and catch requests coming from the outside, and your tomcat, running as a non-root user, on any port. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Running cocoon as tomcat user on port 80
On Jan 8, 2007, at 5:36 AM, Peter Flynn wrote: I've been running Cocoon as root while testing but I clearly don't want to do this for an open production server which will be writing to the server disk. How do I allow running it as the tomcat user but still binding to port 80? You don't :-). Bind it to some other port, and use Apache to reverse-proxy to Tomcat. This is desirable for other reasons as well (besides just being able to run on port 80). See http://wiki.apache.org/cocoon/SimpleModProxy for details. cheers, —ml— - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cforms: tabs in an aggregated page
Maybe someone of you could give me an example of an aggregated page where tabs in CForms work fine. I really need to solve this problem. Otherwise I cant proceed my project :-( kind regards, Niclas ZongoZongo wrote: Hi My page is aggregated of an aggregator. Now I wont to place a Form with tabs. Could somebody give me some hints how this might work? The probelm is, that I cant use the head/ tag in my template, because this is done finally by an xsl-file after the aggregation. I also tried to copy the script, that is placed by cocoon in the header, later inside the xsl-file manually. But it doesnt work. I just can see just the tab-labels and the content of the first group. kind regards, Niclas -- View this message in context: http://www.nabble.com/cforms%3A-tabs-in-an-aggregated-page-tf2918903.html#a8219945 Sent from the Cocoon - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cforms: tabs in an aggregated page
On Jan 8, 2007, at 7:29 AM, ZongoZongo wrote: I really need to solve this problem. Otherwise I cant proceed my project :-( What problem, exactly? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cforms: tabs in an aggregated page
The tabs are not shown. Just their labels are listed and the content of the first group. Mark Lundquist-2 wrote: On Jan 8, 2007, at 7:29 AM, ZongoZongo wrote: I really need to solve this problem. Otherwise I cant proceed my project :-( What problem, exactly? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/cforms%3A-tabs-in-an-aggregated-page-tf2918903.html#a8220293 Sent from the Cocoon - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem running the WebDAV sample block from Cocoon 2.2 TRUNK (2006-01-05 19:00 UTC)
On 08.01.2007 13:33, Ard Schrijvers wrote: java.lang.ClassNotFoundException: org.apache.cocoon.generation.JXTemplateGenerator The correct class name is now org.apache.cocoon.template.JXTemplateGenerator. Why did this move? Strangely enough, cocoon-2.1.10 does not complain about org.apache.cocoon.generation.JXTemplateGenerator, but the JXTemplateGenerator does not seem to work properly. org.apache.cocoon.template.JXTemplateGenerator does work. It's not a simple class renaming, but a complete refactoring of the JXTemplateGenerator with some incompatibilities. The old one (o.a.c.generation) was a 3.000 lines beast IIRC. The new one is modularized. So, in 2.1 both versions exist, in 2.2 only the new one. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: catalog resolution for xsl:import in cocoon transformer not working for me
On 08.01.2007 13:20, Craeg Strong wrote: I have an xslt file with the following import: txsl:import href=-//OASIS//XSL HTML DocBook V5.0//EN which I am trying to resolve using a catalog file: PUBLIC -//OASIS//XSL HTML DocBook V5.0//EN thirdparty/docbook-xsl.1.71.1/xhtml/docbook.xsl The xslt is invoked as part of a very simple pipeline: map:transform src=context://src/com/arielpartners/knowledgebase/xsl/paper-html.xsl I receive the following error message: java.io.FileNotFoundException: C:\ade\src\com\arielpartners\knowledgebase\xsl\-\OASIS\XSL HTML DocBook V5.0\EN (The system cannot find the path specified) So obviously the entity is not being resolved. I believe my situation is unique because I use Docbook specializations that are accomplished by overriding certain docbook XSLT rules (and therefore importing docbook). This technique works perfectly in Ant using the xmlcatalog type. Shouldn't this work in cocoon? Has anyone gotten something like this to work? I searched the archives and documentation and couldn't find any examples that matched my usage pattern. I guess my alternative would be to re-write my xslt as a preprocessor or postprocessor on the docbook xslt output and do it in a two stage pipeline...? I only remember having done this in Ant as well. But are you sure the catalogue is used? There are samples delivered with Cocoon. Do they actually work on your machine? http://cocoon.zones.apache.org/demos/21branch/samples/catalog/welcome Regards Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem running the WebDAV sample block from Cocoon 2.2 TRUNK (2006-01-05 19:00 UTC)
On 1/8/07, Joerg Heinicke [EMAIL PROTECTED] wrote: On 08.01.2007 13:33, Ard Schrijvers wrote: java.lang.ClassNotFoundException: org.apache.cocoon.generation.JXTemplateGenerator The correct class name is now org.apache.cocoon.template.JXTemplateGenerator. Why did this move? Strangely enough, cocoon-2.1.10 does not complain about org.apache.cocoon.generation.JXTemplateGenerator, but the JXTemplateGenerator does not seem to work properly. org.apache.cocoon.template.JXTemplateGenerator does work. It's not a simple class renaming, but a complete refactoring of the JXTemplateGenerator with some incompatibilities. The old one (o.a.c.generation) was a 3.000 lines beast IIRC. The new one is modularized. So, in 2.1 both versions exist, in 2.2 only the new one. Is there some porting guide somewhere? Maybe I could apply it on cocoon-webdav in 2.2 to make it work again... /Mikael Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem running the WebDAV sample block from Cocoon 2.2 TRUNK (2006-01-05 19:00 UTC)
On 08.01.2007 21:14, Mikael Olenfalk wrote: So, in 2.1 both versions exist, in 2.2 only the new one. Is there some porting guide somewhere? Maybe I could apply it on cocoon-webdav in 2.2 to make it work again... I don't know, but I didn't follow the development that closely in the last two years. Leszek and Daniel have mostly worked on the refactoring IIRC. Might be good to ask on the dev list or search the wiki/daisy. But the JXTG is for sure not related to your latest error. Will answer to that mail directly. Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem running the WebDAV sample block from Cocoon 2.2 TRUNK (2006-01-05 19:00 UTC)
On 08.01.2007 12:59, Mikael Olenfalk wrote: Caused by: org.apache.avalon.framework.service.ServiceException: Component with 'org.apache.cocoon.components.repository.SourceRepository' is not defined in this service manager. (Key='AvalonServiceManager') at org.apache.cocoon.core.container.spring.avalon.AvalonServiceManager.lookup(AvalonServiceManager.java:57) at org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.jsFunction_getComponent(FOM_Cocoon.java:325) Seems like an error in component setup. The SourceRepository comes from the repository block, which seems to be correctly specified as dependency of webdav block. Also can't see an obvious error in the conf files. For further help I'd opt for the dev list again. 2.2 is still too cutting edge for users list :) Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
