maven's new central repo
http://blogs.maven.org/jvanzyl/2006/10/05/1160062688005.html Jorg
[jira] Commented: (COCOON-831) XSLTC doesn't work with nodeset functions
[ http://issues.apache.org/jira/browse/COCOON-831?page=comments#action_12440371 ] Léon Tebbens commented on COCOON-831: - We found out that in our case the bug is caused bij Xalan issue 1640 (http://issues.apache.org/jira/browse/XALANJ-1640). We resolved it by upgrading to Xalan 2.7. Léon XSLTC doesn't work with nodeset functions - Key: COCOON-831 URL: http://issues.apache.org/jira/browse/COCOON-831 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.1, 2.1.8 Environment: Operating System: other Platform: Other Reporter: Peter Broschwitz Assigned To: Cocoon Developers Team Priority: Critical we are using cocoon 2.1 with xsltc (version 1.4, xalan 2.5.0) as default transformer. Now we want to use the xalan or exslt nodeset function, but this is only possible with xalan xslt. For testing purposes we tried a simple nodeset transformation from the command line. We did that with the same libraries as cocoon, like: $java -Djava.endorsed.dirs=path/to/endorsed/directory org.apache.xalan.xsltc.cmdline.Transform -x node-set-test.xml node_set_test That way, the transformation succeeds. (Compilation before suceeded also, of course.) Trying to process this stylesheet within the cocoon pipeline throws a null pointer exception without any entries in the cocoon-log-files. Changing to xalan-xslt the transformation works without any problems. The stylesheet we used is from the xsltc-documentation: == xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:xsltc-extension=http://xml.apache.org/xalan/xsltc; xmlns:xalan=http://xml.apache.org/xalan; xmlns:exslt=http://exslt.org/common; version=1.0 xsl:template match=/ xsl:variable name=rtf docelem elem1elem1 gefunden!/elem1 elem2elem2 gefunden!/elem2 /docelem /xsl:variable !-- Use nodeset as an XSLTC extension function -- xsl:value-of select=xsltc-extension:nodeset($rtf)/docelem/elem1/ !-- Use nodeset as a Xalan-Java extension function -- xsl:value-of select=xalan:nodeset($rtf)/docelem/elem1/ !-- Use nodeset as an EXSLT extension function -- xsl:value-of select=exslt:node-set($rtf)/docelem/elem1/ !-- Use nodeset as standard function -- xsl:value-of select=nodeset($rtf)/docelem/elem1/ /xsl:template /xsl:stylesheet == I should add, that none of these nodeset-functions worked, i tested every one of his one and commented out the others. I posted this message already to the cocoon-user-list, and this behaviour could be reproduced by others. Peter -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r453409 - in /cocoon/branches/BRANCH_2_1_X: src/java/org/apache/cocoon/components/flow/FlowHelper.java src/java/org/apache/cocoon/components/flow/util/PipelineUtil.java status.xml
Joerg Heinicke skrev: On 06.10.2006 00:57, Antonio Gallardo wrote: Why actually? What has unwrap to do with pipeline processing? If it is because it is only used there then it makes only sense to move it there if you also make it private. Otherwise it is a public method and it should be seen in a more API-POV, i.e. where it makes sense in the bigger picture. Nobody will find unwrap in PipelineUtil as nobody will search there I fear. I tend agree with you. I just back ported the code from cocoon 2.2 to make sure forms block works on cocoon 2.1. I just followed recommended instructions, since I am not aware of the impact of this change in the trunk. I suspect it is because the rhino dependency was moved out from core to the flowscript block or so. Perhaps Daniel can tell you more about the decision. Ah, ok, didn't know that original cause. But my point still stands. I wonder if you need the FlowHelper at all when not using flow script, i.e. why it is in core? On the other hand javaflow block needs flowscript block. Everything kind of strange, isn't it? The FlowHelper is used in a number of places in cocoon-core and doesn't (after the removal of unwrap) contain anything flowscript specific so it made sense to keep it in core. For the JavaFlow the Abstract.Contunable.processPipelineTo uses PipelineUtil.processToStream, it might be a good idea to copy the code to JavaFlow to get rid of the dependency on Floscript. The PipelineUtil in its current form depends on Rhino. Mabe the non Rhino dependent code could be moved to the core, but I don't know if it would be worthwhile. The main point with the move of PipelineUtil and the unwrap method, was that I wanted to get rid of the dependency on Rhino in core. /Daniel
[2.2] Spring 2.0 final and property handling
Yesterday I updated Cocoon 2.2 to Spring 2.0 final - and the big plus is
that the maven repository contains correct poms for this version :)
Apart from that the new property override configuration mechanism is now
in place as well. This means by default the spring application context
we add a processor to the application context as described here:
http://static.springframework.org/spring/docs/2.0.x/reference/beans.html#beans-factory-overrideconfigurer
which reads all properties files from the spring directory (both
WEB-INF/cocoon/spring and {sitemap-directory}/config/spring} and
applies the configuration information found there. The propery file
should use the following format:
{bean-name}/{property-name}={value}
Please note that currently this is only working for real spring beans
and not for the Avalon style components. The code for that is in place
but not activated or tested yet.
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [2.2] Spring 2.0 final and property handling
Carsten Ziegeler wrote:
Yesterday I updated Cocoon 2.2 to Spring 2.0 final - and the big plus is
that the maven repository contains correct poms for this version :)
Apart from that the new property override configuration mechanism is now
in place as well. This means by default the spring application context
we add a processor to the application context as described here:
http://static.springframework.org/spring/docs/2.0.x/reference/beans.html#beans-factory-overrideconfigurer
which reads all properties files from the spring directory (both
WEB-INF/cocoon/spring and {sitemap-directory}/config/spring} and
applies the configuration information found there. The propery file
should use the following format:
{bean-name}/{property-name}={value}
hmm, why do we have another mechanism for setting properties now?. can't we put
in all properties into WEB-INF/cocoon/properties?
--
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
Re: [2.2] Spring 2.0 final and property handling
Reinhard Poetz wrote: hmm, why do we have another mechanism for setting properties now?. can't we put in all properties into WEB-INF/cocoon/properties? This was actually my first implementation, but I think there is a difference between properties which you might want to use for anything and a mechanism for overriding the configuration of your beans. The latter is also just for spring (and Avalon). So we have: WEB-INF/cocoon/properties - with any properties :) WEB-INF/cocoon/spring/*.xml Spring bean definitions WEB-INF/cocoon/spring/*.properties Spring bean configurations The difference might be subtle but I think we should keep this separate. But of course this is not carved in stone yet, so we can change it in every way we can agree on. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Spring 2.0 final and property handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Carsten Ziegeler schrieb: Reinhard Poetz wrote: hmm, why do we have another mechanism for setting properties now?. can't we put in all properties into WEB-INF/cocoon/properties? This was actually my first implementation, but I think there is a difference between properties which you might want to use for anything and a mechanism for overriding the configuration of your beans. The latter is also just for spring (and Avalon). So we have: WEB-INF/cocoon/properties - with any properties :) WEB-INF/cocoon/spring/*.xml Spring bean definitions WEB-INF/cocoon/spring/*.properties Spring bean configurations How about the different environments (prod/dev/test) for spring bean configuration? WIll they go to ../cocoon/properties directory or do we need a ../cocoon/spring/properties directory as well? Felix The difference might be subtle but I think we should keep this separate. But of course this is not carved in stone yet, so we can change it in every way we can agree on. Carsten -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFJiui2lZVCB08qHERAuz0AKDpbOvRW9RITxi3Vp8trhWzIEnXWQCeL0Kq +nbwfFU7aM47Y/IJAHMdNwY= =6R13 -END PGP SIGNATURE-
Re: [2.2] Spring 2.0 final and property handling
Carsten Ziegeler schrieb: Reinhard Poetz wrote: hmm, why do we have another mechanism for setting properties now?. can't we put in all properties into WEB-INF/cocoon/properties? This was actually my first implementation, but I think there is a difference between properties which you might want to use for anything and a mechanism for overriding the configuration of your beans. The latter is also just for spring (and Avalon). So we have: WEB-INF/cocoon/properties - with any properties :) WEB-INF/cocoon/spring/*.xml Spring bean definitions WEB-INF/cocoon/spring/*.properties Spring bean configurations Just one addition, the spring bean configurations is just using the properties format, but actually these are not properties. Carsten The difference might be subtle but I think we should keep this separate. But of course this is not carved in stone yet, so we can change it in every way we can agree on. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Spring 2.0 final and property handling
Felix Knecht wrote:
How about the different environments (prod/dev/test) for spring bean
configuration? WIll they go to ../cocoon/properties directory or do we
need a ../cocoon/spring/properties directory as well?
It's not implemented yet, but I thought about reading them from
cocoon/spring/{running-mode}/*.properties
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [2.2] Spring 2.0 final and property handling
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
hmm, why do we have another mechanism for setting properties now?. can't we put
in all properties into WEB-INF/cocoon/properties?
This was actually my first implementation, but I think there is a
difference between properties which you might want to use for anything
and a mechanism for overriding the configuration of your beans. The
latter is also just for spring (and Avalon).
So we have:
WEB-INF/cocoon/properties - with any properties :)
WEB-INF/cocoon/spring/*.xml Spring bean definitions
WEB-INF/cocoon/spring/*.properties Spring bean configurations
The difference might be subtle but I think we should keep this separate.
But of course this is not carved in stone yet, so we can change it in
every way we can agree on.
I was asking because this doesn't support the different running modes, does it?
--
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
Re: [VOTE] Lars Trieloff as a new Cocoon committer
my +1 Welcome Lars !! regards Jeremy On 3 Oct 2006, at 15:01, Jean-Baptiste Quenot wrote: Dear Community, I think time has come for Lars Trieloff to become a Cocoon committer, so he'll be able to commit his numerous patches himself, including the last hair-pulling cocoon-core tests fixes today ;-) I know Lars since nearly 5 years as we were both contributing to the Docbook stuff. He is very professionnal and works in IT since the age of 20. He also wrote the online Docbook tool which allows to post a Docbook document and get the PDF in return, and he is the author of a Docbook book in German! And his current involvement into Cocoon 2.2 shows that he is already kind of committed to Cocoon, and since a few months he submitted very valuable patches. So please cast your votes! -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/ smime.p7s Description: S/MIME cryptographic signature
Re: [2.2] Spring 2.0 final and property handling
Reinhard Poetz wrote: Carsten Ziegeler wrote: Reinhard Poetz wrote: hmm, why do we have another mechanism for setting properties now?. can't we put in all properties into WEB-INF/cocoon/properties? This was actually my first implementation, but I think there is a difference between properties which you might want to use for anything and a mechanism for overriding the configuration of your beans. The latter is also just for spring (and Avalon). So we have: WEB-INF/cocoon/properties - with any properties :) WEB-INF/cocoon/spring/*.xml Spring bean definitions WEB-INF/cocoon/spring/*.properties Spring bean configurations The difference might be subtle but I think we should keep this separate. But of course this is not carved in stone yet, so we can change it in every way we can agree on. I was asking because this doesn't support the different running modes, does it? No, but it will soon :) Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Spring 2.0 final and property handling
Carsten Ziegeler wrote: Reinhard Poetz wrote: Carsten Ziegeler wrote: Reinhard Poetz wrote: hmm, why do we have another mechanism for setting properties now?. can't we put in all properties into WEB-INF/cocoon/properties? This was actually my first implementation, but I think there is a difference between properties which you might want to use for anything and a mechanism for overriding the configuration of your beans. The latter is also just for spring (and Avalon). So we have: WEB-INF/cocoon/properties - with any properties :) WEB-INF/cocoon/spring/*.xml Spring bean definitions WEB-INF/cocoon/spring/*.properties Spring bean configurations The difference might be subtle but I think we should keep this separate. But of course this is not carved in stone yet, so we can change it in every way we can agree on. I was asking because this doesn't support the different running modes, does it? No, but it will soon :) can we make a block out of cocoon's way of doing property handling so one could use it in non cocoon projects? -- Leszek Gawron, IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: svn commit: r453534 - /cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
Leszek Gawron wrote: [EMAIL PROTECTED] wrote: Author: cziegeler Date: Fri Oct 6 02:06:31 2006 New Revision: 453534 URL: http://svn.apache.org/viewvc?view=revrev=453534 Log: Deployer plugin will run automatically Modified: cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml Modified: cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml URL: http://svn.apache.org/viewvc/cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml?view=diffrev=453534r1=453533r2=453534 == --- cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml (original) +++ cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml Fri Oct 6 02:06:31 2006 @@ -37,6 +37,14 @@ groupIdorg.apache.cocoon/groupId artifactIdcocoon-deployer-plugin/artifactId version1.0.0-M2-SNAPSHOT/version +executions + execution +phasepackage/phase +goals + goaldeploy/goal +/goals + /execution +/executions /plugin plugin groupIdorg.mortbay.jetty/groupId This does not as expected. Probably because you are not able to specify the order of goals to be executed. So the order is: war:war cocoon:deploy cocoon:deploy (again .. have no idea where that comes from) my bad .. I had cocoon:deploy plugin defined at parent pom so it ran twice (still seems like a maven bug to me). other problems still apply -- Leszek Gawron, IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [2.2] Spring 2.0 final and property handling
Leszek Gawron wrote: can we make a block out of cocoon's way of doing property handling so one could use it in non cocoon projects? Hmm, yes this should be possible. Currently it's tied to some Cocoon stuff, but it should be possible to separate this. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: svn commit: r453534 - /cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
Leszek Gawron wrote: my bad .. I had cocoon:deploy plugin defined at parent pom so it ran twice (still seems like a maven bug to me). other problems still apply Hmm, that's bad - I don't see a solution for this now. But we discussed at the GT an alternative handling of our blocks which would make the cocoon:deploy plugin obsolete. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: svn commit: r453534 - /cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
Carsten Ziegeler wrote: Leszek Gawron wrote: my bad .. I had cocoon:deploy plugin defined at parent pom so it ran twice (still seems like a maven bug to me). other problems still apply Hmm, that's bad - I don't see a solution for this now. But we discussed at the GT an alternative handling of our blocks which would make the cocoon:deploy plugin obsolete. which is ? -- Leszek Gawron, IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: svn commit: r453534 - /cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
Leszek Gawron wrote: Hmm, that's bad - I don't see a solution for this now. But we discussed at the GT an alternative handling of our blocks which would make the cocoon:deploy plugin obsolete. which is ? :) Currently the deployer extracts the files from COB-INF and META-INF into the file system (into the web application). We talked about skipping this step and adding a mechanism to the core of Cocoon which allows to access the information from within the jar without extracting it. This should be doable by using the class loader and some detection mechanism and avoids the deployer plugin. And more important it means that adding a block is just dropping a jar file into the WEB-INF/lib directory which makes using Cocoon even easier - especially if you don't want to use Maven (I can't imagine that someone does not want to use maven but anyway...). Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Releasing M2?
We have done a lot of changes since M1 - we have a new Spring bridge, updated to Spring 2.0 final, the dispatcher servlet etc. I think it makes sense to release this stuff as M2. WDYT? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Spring 2.0 final and property handling
On Fri, Oct 06, 2006 at 11:44:46AM +0200, Carsten Ziegeler wrote: Yesterday I updated Cocoon 2.2 to Spring 2.0 final - and the big plus is that the maven repository contains correct poms for this version :) Hello Carsten, Today I updated the sources from svn and tried a rebuild. Now I'm getting this error, which seems related to this update to Spring 2.0 final. Here's the output: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.springframework:spring-web:jar:2.0 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.springframework -DartifactId=spring-web \ -Dversion=2.0 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-M2-SNAPSHOT 2) org.springframework:spring-web:jar:2.0 -- 1 required artifact is missing. for artifact: org.apache.cocoon:cocoon-core:jar:2.2.0-M2-SNAPSHOT from the specified remote repositories: central (http://ibiblio.org/maven2), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache.snapshot (http://svn.apache.org/maven-snapshot-repository), apache-cvs (http://svn.apache.org/repository) Or is there something wrong with my configuration? Yesterday I did two successful builds. Thanks, Fred
Re: [2.2] Spring 2.0 final and property handling
Fred Vos wrote: On Fri, Oct 06, 2006 at 11:44:46AM +0200, Carsten Ziegeler wrote: Yesterday I updated Cocoon 2.2 to Spring 2.0 final - and the big plus is that the maven repository contains correct poms for this version :) Hello Carsten, Today I updated the sources from svn and tried a rebuild. Now I'm getting this error, which seems related to this update to Spring 2.0 final. Here's the output: Hmm, strange - spring 2.0 final is available from Ibiblio and most mirrors, so to be honest I have no clue what's going wrong - anyone else? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
RFC: CForms + Dojo: the way forward
Hi All We had an informal group discussion on Tuesday at the Hackathon about CForms. The purpose of the discussion was to find a consensus on the direction to take CForms, so that everybody who would like to work on it is hopefully going to take it in the same general direction. These are some of the points that were raised and some of the tentative conclusions we reached. 1. Too much javascript gets loaded unconditionally when a cform is used. Conclusion: we should rely as much as possible on dojo lazy-loading, but we could also take a parallel approach of an extra transformation step on templates in xslt to discover which libraries are actually being used, then only add those script tags. 2. Dojo's lazy-loading capabilities are not being taken full advantage of. (this follows on from above) Conclusion: ideally a cforms page should only have script tags to load the dojo and cocoon-forms bootstrap, all other loading should come from the use of dojo.require if possible. The dojo.require statements can either be in the Widget code or in script tags in the CForms Widgets, but not put unconditionally into the head/script. 3. We have two templating systems, there are incompatibilities between them and different capabilities, can we deprecate one? Conclusion: the JXMacro generation technique seems to be more popular and capable. We should if possible deprecate the use of the FormsTransformer, adding any missing functionality to the JXMacro lib. Before we decide this, we need an accurate idea of all compatibility and any performance differences between the two. We need to write some docs explaining the migration path. 4. Can we replace some of the legacy libs with similar functionality in Dojo? Conclusion: Everyone seemed happy to replace legacy javascript libs with their equivalent in Dojo. However, it should be done in a way to allow the usage of eg. HtmlArea editor as it could have capabilities that certain projects need that are not offered by Dojo rich text editor. Some legacy libs do not have equivalent Dojo implementations, these need to be written as Cocoon namespaced Dojo Widgets and/or could be contributed to Dojo. 5. It would be worth upgrading our current custom Dojo widgets to the latest widget APIs, this will make it easier to upgrade to the next version of Dojo when it is released. Conclusion: where possible, existing Cocoon namespaced Dojo widgets should be adjusted to use the newer API : dojo.widget.defineWidget 6. Dojo has an ant build script which uses Rhino to compile and compress all needed dojo code into a single file. This speeds up the client *significantly*. How can we use this better from within Cocoon? Conclusion: It would be of great advantage to have this dojo compressor build, better integrated into Cocoon, so that an optimised production environment can be used. The compressor does 2 things: aggregate and compress all of the required dojo packages, aggregate all of the html template and css snippets required by the widgets you actually need. This functionality is already in place (src/blocks/ ajax/dojo/), it is just not obvious or automatable. Currently you would create a listing of the required dojo libs by hand, then run the build script. Can and should we find a way to automate this? 7. Fallback in the case of no javascript Conclusion: wherever possible, our Dojo Widgets should be designed to place simple workable fields in forms, that get embellished if Dojo is available, so if Javascript is turned off, at least some functionality is available. This is normal dojo practise i.e. textarea class=dojo-Editor name=editorContentsome content/ textarea : you get a normal textarea if dojo is not available, but a wysiwyg editor if it is. I think we have and need to retain these 3 usecases : javascript is available + developer wants Ajax behaviours javascript is available + developer does not want Ajax behaviours javascript is not available Before each or any of the changes above are made, it will obviously need a fuller discussion about the details of each change. Your feedback and efforts at implementing these changes would be gratefully accepted. regards Jeremy smime.p7s Description: S/MIME cryptographic signature
[jira] Commented: (COCOON-831) XSLTC doesn't work with nodeset functions
[
http://issues.apache.org/jira/browse/COCOON-831?page=comments#action_12440484 ]
Henry Zongaro commented on COCOON-831:
--
Looking at the code in org.apache.cocoon.generation.ProfilerGenerator.generate,
which appears in Nils's traceback, I think it would help me if somebody could
try serializing the SAX events that are sent into this.contentHandler by that
code. For example, change the following code:
} else {
// Start the document and set the PROFILER_NS.
this.contentHandler.startDocument();
this.contentHandler.startPrefixMapping(PREFIX, PROFILER_NS);
generateProfilerInfo();
// End the document.
this.contentHandler.endPrefixMapping(PREFIX);
this.contentHandler.endDocument();
}
to the following, which will write the SAX events serialized as XML to
System.err
} else {
org.xml.sax.ContentHandler oldHandler = this.contentHandler;
try {
this.contentHandler =
((javax.xml.transform.sax.SAXTransformerFactory)
javax.xml.transform.TransformerFactory.newInstance())
.newTransformerHandler();
} catch (javax.xml.transform.TransformerConfigurationException tce)
{
throw new SAXException(tce.toString());
}
java.io.StringWriter sw = new java.io.StringWriter();
((javax.xml.transform.sax.TransformerHandler) this.contentHandler)
.setResult(new StreamResult(sw));
// Start the document and set the PROFILER_NS.
this.contentHandler.startDocument();
this.contentHandler.startPrefixMapping(PREFIX, PROFILER_NS);
generateProfilerInfo();
// End the document.
this.contentHandler.endPrefixMapping(PREFIX);
this.contentHandler.endDocument();
String result = sw.toString();
System.err.println(result);
this.contentHandler = oldHandler;
org.xml.sax.XMLReader rdr =
org.xml.sax.helpers.XMLReaderFactory.createXMLReader();
rdr.setContentHandler(oldHandler);
try {
rdr.parse(new org.xml.sax.InputSource(new
java.io.StringReader(result)));
} catch (java.io.IOException ioe) {
throw new SAXException(ioe.toString());
}
}
XSLTC doesn't work with nodeset functions
-
Key: COCOON-831
URL: http://issues.apache.org/jira/browse/COCOON-831
Project: Cocoon
Issue Type: Bug
Components: - Components: Sitemap
Affects Versions: 2.1, 2.1.8
Environment: Operating System: other
Platform: Other
Reporter: Peter Broschwitz
Assigned To: Cocoon Developers Team
Priority: Critical
we are using cocoon 2.1 with xsltc (version 1.4, xalan 2.5.0) as default
transformer. Now we want to use the xalan or exslt nodeset function, but
this is only possible with xalan xslt.
For testing purposes we tried a simple nodeset transformation from the
command line. We did that with the same libraries as cocoon, like:
$java -Djava.endorsed.dirs=path/to/endorsed/directory
org.apache.xalan.xsltc.cmdline.Transform -x node-set-test.xml node_set_test
That way, the transformation succeeds. (Compilation before suceeded also, of
course.)
Trying to process this stylesheet within the cocoon pipeline throws a null
pointer exception without any entries in the cocoon-log-files. Changing to
xalan-xslt the transformation works without any problems.
The stylesheet we used is from the xsltc-documentation:
==
xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xmlns:xsltc-extension=http://xml.apache.org/xalan/xsltc;
xmlns:xalan=http://xml.apache.org/xalan;
xmlns:exslt=http://exslt.org/common;
version=1.0
xsl:template match=/
xsl:variable name=rtf
docelem
elem1elem1 gefunden!/elem1
elem2elem2 gefunden!/elem2
/docelem
/xsl:variable
!-- Use nodeset as an XSLTC extension function --
xsl:value-of select=xsltc-extension:nodeset($rtf)/docelem/elem1/
!-- Use nodeset as a Xalan-Java extension function --
xsl:value-of select=xalan:nodeset($rtf)/docelem/elem1/
!-- Use nodeset as an EXSLT extension function --
xsl:value-of select=exslt:node-set($rtf)/docelem/elem1/
!-- Use nodeset as standard function --
xsl:value-of select=nodeset($rtf)/docelem/elem1/
/xsl:template
/xsl:stylesheet
==
I should add, that none of these nodeset-functions worked, i tested every one
of his one and commented out the others.
I
Re: [2.2] Spring 2.0 final and property handling
On 06 Oct 2006, at 16:02, Fred Vos wrote: Today I updated the sources from svn and tried a rebuild. Now I'm getting this error, which seems related to this update to Spring 2.0 final. Here's the output: Are you using a settings.xml with a different mirror perhaps? I know for a fact that mirrors.dotsrc.org didn't have the files yet yesterday evening because i got the same error. Just switch to another mirror or go directly do repo1.maven.org HTH Jorg
Re: Releasing M2?
Carsten Ziegeler wrote: We have done a lot of changes since M1 - we have a new Spring bridge, updated to Spring 2.0 final, the dispatcher servlet etc. I think it makes sense to release this stuff as M2. +1 I am using this cocoon in production quite long now. -- Leszek Gawron [EMAIL PROTECTED]
Re: svn commit: r453534 - /cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
Carsten Ziegeler wrote: Leszek Gawron wrote: Hmm, that's bad - I don't see a solution for this now. But we discussed at the GT an alternative handling of our blocks which would make the cocoon:deploy plugin obsolete. which is ? :) Currently the deployer extracts the files from COB-INF and META-INF into the file system (into the web application). We talked about skipping this step and adding a mechanism to the core of Cocoon which allows to access the information from within the jar without extracting it. This should be doable by using the class loader and some detection mechanism and avoids the deployer plugin. And more important it means Seems like cocoon solutions are always a step ahead my comprehension. Is this really feasible? -- Leszek Gawron [EMAIL PROTECTED]
Re: RFC: CForms + Dojo: the way forward
Jeremy Quinn said the following on 6/10/06 16:42: Hi All We had an informal group discussion on Tuesday at the Hackathon about CForms. The purpose of the discussion was to find a consensus on the direction to take CForms, so that everybody who would like to work on it is hopefully going to take it in the same general direction. These are some of the points that were raised and some of the tentative conclusions we reached. All these sound very good. I'm not sure if I can help out, but I'll contribute to the discussion if necessary. There is one issue I had/have with dojo that I would love to see addressed: dojo cannot be used in XHTML because it relies on dojotype attributes in various HTML tags. When I asked the dojo team they waived the issue with switch to HTML. I don't think that is a valid argument in a Cocoon environment. It would be great if you/we could find a solution that solves this issue. Bye, Helma
Re: RFC: CForms + Dojo: the way forward
Hi Jeremy, I see the following ways to solve this: - create a DojoReader that will dynamically compress and aggregate Javascript on the fly. - create a Maven Mojo that does the same job as Dojo's ant task, but this needs to be configured at build time. The first option needs no build time configuration and it allows to generate a minimal javascript library file on the fly that needs to be loaded only once for every configuration of dojo.require statements. The most important question here is: How do we find out, what dojo packages are actually required. Lars Am 06.10.2006 um 16:42 schrieb Jeremy Quinn: 6. Dojo has an ant build script which uses Rhino to compile and compress all needed dojo code into a single file. This speeds up the client *significantly*. How can we use this better from within Cocoon? Conclusion: It would be of great advantage to have this dojo compressor build, better integrated into Cocoon, so that an optimised production environment can be used. The compressor does 2 things: aggregate and compress all of the required dojo packages, aggregate all of the html template and css snippets required by the widgets you actually need. This functionality is already in place (src/blocks/ajax/dojo/), it is just not obvious or automatable. Currently you would create a listing of the required dojo libs by hand, then run the build script. Can and should we find a way to automate this?
[jira] Created: (COCOON-1929) [PATCH] Reloading classloader in Cocoon 2.2
[PATCH] Reloading classloader in Cocoon 2.2 --- Key: COCOON-1929 URL: http://issues.apache.org/jira/browse/COCOON-1929 Project: Cocoon Issue Type: Task Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Maurizio Pillitu The attached patch provides a first implementation to enable reloading classloader configuration into the sitemap, using the sitemap syntax used in blocks/cocoon-core-sample/cocoon-core-main-sample/src/main/resources/COB-INF/sitemap.xmap. Referring to CocoonGT 2005 Torsten's code, I moved all the JCI listener configuration into the ReloadingClassLoaderFactory class, that is in charge to parse the classloader configuration (filled by AvalonUtils class) and instanciate all the JCI listeners. The TreeProcessor component is subscribed to the JCI listeners, in order to reload the component definitions when a file change event is triggered. The patch provides also a sample : http://localhost:/blocks/cocoon-core-main-sample/reloading/ Try to change MyGenerator.java and compile it into blocks/cocoon-core-sample/cocoon-core-main-sample/target/classes (default eclipse location); if you need to change the location of the .class folder, edit the cocoon-core-main-sample sitemap.xmap. core. Obviously there are many parts of the code that can be optimized. The patch has been applied on revision 453682. NOTE! 1. I decided to provide the reloading class functionality only for dev mode, so, in order to get it working, you need to run the cocoon application with -Dorg.apache.cocoon.mode=dev 2. The patch depends on a bugfix on Commons JCI (https://issues.apache.org/jira/browse/SANDBOX-174), so it's necessary to build jci-core from trunk; the patch will update the cocoon-bootstrap dependency to jci. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1929) [PATCH] Reloading classloader in Cocoon 2.2
[ http://issues.apache.org/jira/browse/COCOON-1929?page=all ] Maurizio Pillitu updated COCOON-1929: - Attachment: cocoon.diff Apply to cocoon 2.2 trunk folder [PATCH] Reloading classloader in Cocoon 2.2 --- Key: COCOON-1929 URL: http://issues.apache.org/jira/browse/COCOON-1929 Project: Cocoon Issue Type: Task Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Maurizio Pillitu Attachments: cocoon.diff The attached patch provides a first implementation to enable reloading classloader configuration into the sitemap, using the sitemap syntax used in blocks/cocoon-core-sample/cocoon-core-main-sample/src/main/resources/COB-INF/sitemap.xmap. Referring to CocoonGT 2005 Torsten's code, I moved all the JCI listener configuration into the ReloadingClassLoaderFactory class, that is in charge to parse the classloader configuration (filled by AvalonUtils class) and instanciate all the JCI listeners. The TreeProcessor component is subscribed to the JCI listeners, in order to reload the component definitions when a file change event is triggered. The patch provides also a sample : http://localhost:/blocks/cocoon-core-main-sample/reloading/ Try to change MyGenerator.java and compile it into blocks/cocoon-core-sample/cocoon-core-main-sample/target/classes (default eclipse location); if you need to change the location of the .class folder, edit the cocoon-core-main-sample sitemap.xmap. core. Obviously there are many parts of the code that can be optimized. The patch has been applied on revision 453682. NOTE! 1. I decided to provide the reloading class functionality only for dev mode, so, in order to get it working, you need to run the cocoon application with -Dorg.apache.cocoon.mode=dev 2. The patch depends on a bugfix on Commons JCI (https://issues.apache.org/jira/browse/SANDBOX-174), so it's necessary to build jci-core from trunk; the patch will update the cocoon-bootstrap dependency to jci. -- 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: Releasing M2?
On 10/6/06, Carsten Ziegeler [EMAIL PROTECTED] wrote: ...I think it makes sense to release this stuff as M2... +0.9 (meaning I cannot help but go for it) -Bertrand
Re: RFC: CForms + Dojo: the way forward
Hi Lars On 6 Oct 2006, at 18:49, Lars Trieloff wrote: Hi Jeremy, I see the following ways to solve this: - create a DojoReader that will dynamically compress and aggregate Javascript on the fly. Amazing idea !! :) - create a Maven Mojo that does the same job as Dojo's ant task, but this needs to be configured at build time. Yup It might be more useful to run this on a running Cocoon. Users might want to use pipelines to produce the static html templates etc., for their custom widgets, these would also want 'baking in'. The first option needs no build time configuration and it allows to generate a minimal javascript library file on the fly that needs to be loaded only once for every configuration of dojo.require statements. The most important question here is: How do we find out, what dojo packages are actually required. Exactly However, while we work out the best way of doing that, we could document the existing build system; it should be easy to run a hand- made profile. For now users can get the list of loaded packages by turning on debug in dojo, or looking at the server logs but it would be excellent to have an automated solution. regards Jeremy Am 06.10.2006 um 16:42 schrieb Jeremy Quinn: 6. Dojo has an ant build script which uses Rhino to compile and compress all needed dojo code into a single file. This speeds up the client *significantly*. How can we use this better from within Cocoon? Conclusion: It would be of great advantage to have this dojo compressor build, better integrated into Cocoon, so that an optimised production environment can be used. The compressor does 2 things: aggregate and compress all of the required dojo packages, aggregate all of the html template and css snippets required by the widgets you actually need. This functionality is already in place (src/blocks/ajax/dojo/), it is just not obvious or automatable. Currently you would create a listing of the required dojo libs by hand, then run the build script. Can and should we find a way to automate this? smime.p7s Description: S/MIME cryptographic signature
[jira] Closed: (COCOON-1706) Allow TeeTransformer to run a system command for debugging purposes
[ http://issues.apache.org/jira/browse/COCOON-1706?page=all ] Jean-Baptiste Quenot closed COCOON-1706. Fix Version/s: 2.2-dev (Current SVN) Resolution: Fixed Committed revision 453749 with some modifications. Thanks for your nice contribution! Allow TeeTransformer to run a system command for debugging purposes --- Key: COCOON-1706 URL: http://issues.apache.org/jira/browse/COCOON-1706 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Reporter: Jean-Baptiste Quenot Assigned To: Jean-Baptiste Quenot Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: 20051212-naming-TeeTransformer Hello, The TeeTransformer is great, but it would be still greater if it could run a system command every time it is invoked, to ease debugging of a Cocoon application. The system command can be eg vi, emacs, put your favorite editor here, so that every time the pipeline is executed, your editor pops up. Credit goes to Philippe Gassmann [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: RFC: CForms + Dojo: the way forward
Hello Jeremy, This is a nice CForms roadmap indeed. See my comment below: * Jeremy Quinn: 3. We have two templating systems, there are incompatibilities between them and different capabilities, can we deprecate one? Conclusion: the JXMacro generation technique seems to be more popular and capable. We should if possible deprecate the use of the FormsTransformer, adding any missing functionality to the JXMacro lib. Before we decide this, we need an accurate idea of all compatibility and any performance differences between the two. We need to write some docs explaining the migration path. The old JXTemplateGenerator is the cause of performance problems when using the CForms's JX macros. So deprecating CForms transformer also means switching from the old JXTG to the new one. -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
site module pom
Hi, The root pom is currently declaring modulesite/cocoon-maven-site- skin/module directly. This is giving problems in continuum: Cannot build maven project from /home/maven/continuum-1.0.3/temp/ continuum/repos/asf/cocoon/trunk/site/cocoon-maven-site-skin/pom.xml (Cannot find parent: org.apache.cocoon:site for project: null:cocoon- maven-site-skin:jar:1.0.0-SNAPSHOT). I guess this is caused by maven-site-skin referencing a parent pom that is not part of the main build. I have changed this for now so that it references the root pom as parent. The layout of the site module pom seemed a bit weird anyway, it was including other blocks causing cyclic refs. I'm assuming this still needs a cleanup. Jorg
