[jira] Commented: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
[ https://issues.apache.org/jira/browse/COCOON-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570496#action_12570496 ] Olivier Billard commented on COCOON-1898: - Hi there, This issue is quite old, and I also have the need of patching cocoon.xconf file in a mavenized Cocoon 2.1.x application. I have several jar artefacts corresponding to different possible configurations (a base core, and customers-oriented/specific functionalities). Is there any chance this would be managed ? Thanks ! > [PATCH] XPatch support for maven-cocoon-deployer-plugin > --- > > Key: COCOON-1898 > URL: https://issues.apache.org/jira/browse/COCOON-1898 > Project: Cocoon > Issue Type: Improvement > Components: - Build System: Maven >Affects Versions: 2.2-dev (Current SVN) >Reporter: Lars Trieloff > Attachments: maven-cocoon-deployer-plugin-with-xpatch-support.patch > > > The cocoon-deployer-plugin has currently no support for XPatch, which makes > it difficult to modify the web.xml when developing cocoon blocks. For example > the cocoon-xmldb-impl block should add, when deployed, a servlet for xindice > and a servlet mapping for the xindice servlet. This was possible in 2.1 using > the XConfToolTask, but is no longer possible with the current state of the > deployer-plugin. > My patch adds support for patching the web.xml file using *.xweb files in the > /conf directory of a block by filtering the block's jar file during > deployment for conf/*.xweb files, caching the patch document temporarily and > applying them (using code from the orgiginal XConfToolTask in 2.1) to the > web.xml. The patch has currently no support for other files than conf/*.xweb > files and does not support any property expansion. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: New Cocoon 2.1.10 live site: www.derecho.com
Grek, I hope you, as Apache Cocoon commiters, took an insurance for this event: too much precious brains in one place ! ;) -- Olivier Billard Grzegorz Kossakowski wrote: Nacho (Derecho.com) pisze: Hola a todos: The past day 03/09/2007 we've put a Cocoon 2.1.10 only live site online, with big success, we all want to share our success with all of the developers of Cocoon, and give a big big thanks to all of you.. We are extensively and intensively using Flow ( thanks god we have flow :), SQL Transformer, aggregator, definitely almost anything of the Cocoon standard blocks dist, and if not using it, for sure we have plans to use it in short.. The old site was done in an ancient cocoon 1.8.2 for 1997-99, backed by a tomcat 3.3.. So we are proud to say that we are using cocoon for about 10 years now ;) The new site need some work to have all the bell and twistles working, but we think is by now a great example on wath can be done with cocoon.. Another time thanks to all, including ancient cocoon Heros ;).. Thank you for reporting! Although I don't understand much of your site it looks really nice. And for the work, where can we found a brief description of 2.2? the build process, the new features, etc. It changed a lot and in most cases you will not have to build Cocoon on your own. We are shipping binaries, again! To get started take a look at this site: http://cocoon.zones.apache.org/dev-docs/ (I hope that it will be officially published soon) We need to have a peek at the next cocoon version as we want to stay with cocoon for next ten years ;).. But until now didnt found any relevant infos about it.. Apart from the maillist, where the infos are a little scattered and distributed all over the days and months.. Have you considered attending to Cocoon GetTogether[1]? Spain is really close to Italy and it's the only chance in whole year to meet so many Cocoon hackers in one place. :)
Re: FYI: Expression language Daisy site created
Please forget this post :) [1] http://www.mail-archive.com/dev@cocoon.apache.org/msg46726.html -- Olivier Billard Olivier Billard wrote: Hi, Made me read this document, and found a typo mistake : "In Daisy, create a New Document and choose type Book Definition." Shouldn't it be "In Daisy, create a New Document and choose type *Navigation document*." ? -- Olivier Billard Grzegorz Kossakowski wrote: Hi, I wanted let you know that I have created Daisy site for cocoon-expression-language module. It was very easy because everything is explained here: http://cocoon.zones.apache.org/daisy/cdocs/g3/1223.html I must visit our Daisy more often; our documentation system is no less fun than coding. :-)
Re: FYI: Expression language Daisy site created
Hi, Made me read this document, and found a typo mistake : "In Daisy, create a New Document and choose type Book Definition." Shouldn't it be "In Daisy, create a New Document and choose type *Navigation document*." ? -- Olivier Billard Grzegorz Kossakowski wrote: Hi, I wanted let you know that I have created Daisy site for cocoon-expression-language module. It was very easy because everything is explained here: http://cocoon.zones.apache.org/daisy/cdocs/g3/1223.html I must visit our Daisy more often; our documentation system is no less fun than coding. :-)
Re: [Cocoon 2.2] Why use a shielding repository ?
Carsten Ziegeler wrote: Reinhard Poetz wrote: Olivier Billard wrote: Hi all, The Cocoon Maven plug-in can be configured given a "useShieldingRepository" configuration parameter. The effect is that all JARs / classes are moved from WEB-INF/lib and WEB-INF/classes respectively to WEB-INF/shielded/lib and WEB-INF/shielded/classes. The Cocoon documentation [1] does not explain what is the purpose of this configuration option. Can anyone tell me, please ? Thanks ! Hmm, I guess to make the change in the classloader hierarchy explicit. Yes, and to avoid that the app server picks up the classes as well for nothing. This is just an optimization parameter. Without it, the app server constructs a class path with all jars from the webapp and the shielding stuff constructs a child class loader with exactly the same class path. Carsten OK, thanks for your explanation, Carsten. (cross-posting this answer to the users list as this answers to my original question.) -- Olivier Billard
Re: Why has the PanaoidCocoonServlet disappear ?
Reinhard Poetz wrote: Olivier Billard wrote: Hi all, Still annoyed with that problem. Can anyone confirm or not ? Should I feed JIRA ? Yes, please do so. I'm sorry, but I can't help with the problem till the end of September when I'm back from my vacations. No problem Reinhard, you already help me a lot on other subjects. I must finish hot-boiling stuff for now but I'll try to write a clean (easy to reproduce with Cocoon sources) bug report for it ASAP. Good luck all for RC2 release :) -- Olivier Billard
Re: Why has the PanaoidCocoonServlet disappear ?
Hi all, Still annoyed with that problem. Can anyone confirm or not ? Should I feed JIRA ? Thanks ! -- Olivier Billard Olivier Billard wrote: Hi all, Getting further after my... hum... it seems now that the shielding classloader does not do its job, I now have the good old endorsed libs problem with Tomcat 5.0.30 (Java 6). Removing endorsed libs shipped with the Tomcat distrib, it works. Error : java.lang.NoSuchMethodError: javax.xml.transform.dom.DOMResult.getNextSibling()Lorg/w3c/dom/Node; web.xml snippet: shieled-classloader-use-repository false org.apache.cocoon.maven.deployer.servlet.ShieldingListener org.springframework.web.context.ContextLoaderListener,org.springframework.web.context.request.RequestContextListener Acegi Security Filter Acegi Security Filter Acegi Security Filter org.apache.cocoon.maven.deployer.servlet.ShieldingServletFilter targetClass org.acegisecurity.util.FilterChainProxy filter-class org.acegisecurity.util.FilterToBeanProxy org.apache.cocoon.maven.deployer.servlet.ShieldingListener Thanks -- Olivier Billard Olivier Billard wrote: Oh sorry, I may have misused the maven command line. I retested with a shorter, cleaner command and it now produces a cleaner web.xml. -- Olivier Billard Olivier Billard wrote: Hi Reinhard, Thanks for your reply. Info below. Reinhard Poetz wrote: Olivier Billard wrote: Hi Jean-Baptiste ! Thank you for your quick reply. Didn't you mention the 2.1 part of the SVN repo ? Maybe was it not clear in my post, but I am talking about Cocoon 2.2 :). Searching a bit, I found some information about the shielding servlet service, that seems to do that job, replacing the ParanoidCocoonServlet. Is it ? yes, right. See http://cocoon.zones.apache.org/dev-docs/2.2/maven-plugins/maven-plugin/1.0/1361_1_1.html. Nice skin :) The Cocoon deploy plugin offers a "deploy" goal which can be configured to use the shielding classloader. The goal rewrites the web.xml to bypass all servlet, filter and listener calls and uses a shielding classloader which reverses the classloader hierarchy the same way as the ParanoidCocoonServlet did for 2.1. It also adds the necessary classes to your webapp. In short, the shielding stuff is only a configuration option. The note, that the plugin hasn't been released yet isn't valid anymore. It is available at version 1.0.0-M1. If you try it out, please let me know if it works for you as expected. (I've only tested it in a very simple scenario so far ...) I tried, but the resulting patched web.xml is missing the 2 following Cocoon listener declarations: - org.springframework.web.context.ContextLoaderListener - org.springframework.web.context.request.RequestContextListener Those declaration seem to have been replaced by the ShieldingListener declaration, maybe instead of simply just add the ShieldingListener declaration? This causes a Tomcat error, that looks like an endless loop. Adding the "missing" declarations in the web.xml file makes Tomcat start fine. Is it a bug ? -- Olivier Billard
Re: Why has the PanaoidCocoonServlet disappear ?
Hi all, Getting further after my... hum... it seems now that the shielding classloader does not do its job, I now have the good old endorsed libs problem with Tomcat 5.0.30 (Java 6). Removing endorsed libs shipped with the Tomcat distrib, it works. Error : java.lang.NoSuchMethodError: javax.xml.transform.dom.DOMResult.getNextSibling()Lorg/w3c/dom/Node; web.xml snippet: shieled-classloader-use-repository false org.apache.cocoon.maven.deployer.servlet.ShieldingListener org.springframework.web.context.ContextLoaderListener,org.springframework.web.context.request.RequestContextListener Acegi Security Filter Acegi Security Filter Acegi Security Filter org.apache.cocoon.maven.deployer.servlet.ShieldingServletFilter targetClass org.acegisecurity.util.FilterChainProxy filter-class org.acegisecurity.util.FilterToBeanProxy org.apache.cocoon.maven.deployer.servlet.ShieldingListener Thanks -- Olivier Billard Olivier Billard wrote: Oh sorry, I may have misused the maven command line. I retested with a shorter, cleaner command and it now produces a cleaner web.xml. -- Olivier Billard Olivier Billard wrote: Hi Reinhard, Thanks for your reply. Info below. Reinhard Poetz wrote: Olivier Billard wrote: Hi Jean-Baptiste ! Thank you for your quick reply. Didn't you mention the 2.1 part of the SVN repo ? Maybe was it not clear in my post, but I am talking about Cocoon 2.2 :). Searching a bit, I found some information about the shielding servlet service, that seems to do that job, replacing the ParanoidCocoonServlet. Is it ? yes, right. See http://cocoon.zones.apache.org/dev-docs/2.2/maven-plugins/maven-plugin/1.0/1361_1_1.html. Nice skin :) The Cocoon deploy plugin offers a "deploy" goal which can be configured to use the shielding classloader. The goal rewrites the web.xml to bypass all servlet, filter and listener calls and uses a shielding classloader which reverses the classloader hierarchy the same way as the ParanoidCocoonServlet did for 2.1. It also adds the necessary classes to your webapp. In short, the shielding stuff is only a configuration option. The note, that the plugin hasn't been released yet isn't valid anymore. It is available at version 1.0.0-M1. If you try it out, please let me know if it works for you as expected. (I've only tested it in a very simple scenario so far ...) I tried, but the resulting patched web.xml is missing the 2 following Cocoon listener declarations: - org.springframework.web.context.ContextLoaderListener - org.springframework.web.context.request.RequestContextListener Those declaration seem to have been replaced by the ShieldingListener declaration, maybe instead of simply just add the ShieldingListener declaration? This causes a Tomcat error, that looks like an endless loop. Adding the "missing" declarations in the web.xml file makes Tomcat start fine. Is it a bug ? -- Olivier Billard
Re: Why has the PanaoidCocoonServlet disappear ?
Oh sorry, I may have misused the maven command line. I retested with a shorter, cleaner command and it now produces a cleaner web.xml. -- Olivier Billard Olivier Billard wrote: Hi Reinhard, Thanks for your reply. Info below. Reinhard Poetz wrote: Olivier Billard wrote: Hi Jean-Baptiste ! Thank you for your quick reply. Didn't you mention the 2.1 part of the SVN repo ? Maybe was it not clear in my post, but I am talking about Cocoon 2.2 :). Searching a bit, I found some information about the shielding servlet service, that seems to do that job, replacing the ParanoidCocoonServlet. Is it ? yes, right. See http://cocoon.zones.apache.org/dev-docs/2.2/maven-plugins/maven-plugin/1.0/1361_1_1.html. Nice skin :) The Cocoon deploy plugin offers a "deploy" goal which can be configured to use the shielding classloader. The goal rewrites the web.xml to bypass all servlet, filter and listener calls and uses a shielding classloader which reverses the classloader hierarchy the same way as the ParanoidCocoonServlet did for 2.1. It also adds the necessary classes to your webapp. In short, the shielding stuff is only a configuration option. The note, that the plugin hasn't been released yet isn't valid anymore. It is available at version 1.0.0-M1. If you try it out, please let me know if it works for you as expected. (I've only tested it in a very simple scenario so far ...) I tried, but the resulting patched web.xml is missing the 2 following Cocoon listener declarations: - org.springframework.web.context.ContextLoaderListener - org.springframework.web.context.request.RequestContextListener Those declaration seem to have been replaced by the ShieldingListener declaration, maybe instead of simply just add the ShieldingListener declaration? This causes a Tomcat error, that looks like an endless loop. Adding the "missing" declarations in the web.xml file makes Tomcat start fine. Is it a bug ? -- Olivier Billard
Re: Why has the PanaoidCocoonServlet disappear ?
Hi Reinhard, Thanks for your reply. Info below. Reinhard Poetz wrote: Olivier Billard wrote: Hi Jean-Baptiste ! Thank you for your quick reply. Didn't you mention the 2.1 part of the SVN repo ? Maybe was it not clear in my post, but I am talking about Cocoon 2.2 :). Searching a bit, I found some information about the shielding servlet service, that seems to do that job, replacing the ParanoidCocoonServlet. Is it ? yes, right. See http://cocoon.zones.apache.org/dev-docs/2.2/maven-plugins/maven-plugin/1.0/1361_1_1.html. Nice skin :) The Cocoon deploy plugin offers a "deploy" goal which can be configured to use the shielding classloader. The goal rewrites the web.xml to bypass all servlet, filter and listener calls and uses a shielding classloader which reverses the classloader hierarchy the same way as the ParanoidCocoonServlet did for 2.1. It also adds the necessary classes to your webapp. In short, the shielding stuff is only a configuration option. The note, that the plugin hasn't been released yet isn't valid anymore. It is available at version 1.0.0-M1. If you try it out, please let me know if it works for you as expected. (I've only tested it in a very simple scenario so far ...) I tried, but the resulting patched web.xml is missing the 2 following Cocoon listener declarations: - org.springframework.web.context.ContextLoaderListener - org.springframework.web.context.request.RequestContextListener Those declaration seem to have been replaced by the ShieldingListener declaration, maybe instead of simply just add the ShieldingListener declaration? This causes a Tomcat error, that looks like an endless loop. Adding the "missing" declarations in the web.xml file makes Tomcat start fine. Is it a bug ? -- Olivier Billard
Re: Why has the PanaoidCocoonServlet disappear ?
Hi Jean-Baptiste ! Thank you for your quick reply. Didn't you mention the 2.1 part of the SVN repo ? Maybe was it not clear in my post, but I am talking about Cocoon 2.2 :). Searching a bit, I found some information about the shielding servlet service, that seems to do that job, replacing the ParanoidCocoonServlet. Is it ? We experiment some trouble though, with Tomcat 5.0.30, could it be that the default deployer configuration does not use the shielding servlet, if it is the right way to go ? Thanks ! -- Olivier Jean-Baptiste Quenot wrote: * Olivier Billard: What is the reason why the useful paranoid class-loading mechanism has disappear from Cocoon 2.1 and Cocoon 2.2 ? Is it an 2.1->2.2 translation remaining ? Is is standard now, and in this case is there somewhere I could find some information about it ? For sure it's still there: http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/src/blocks/paranoid/java/org/apache/cocoon/servlet/ParanoidCocoonServlet.java
Why has the PanaoidCocoonServlet disappear ?
Hi Cocooners, What is the reason why the useful paranoid class-loading mechanism has disappear from Cocoon 2.1 and Cocoon 2.2 ? Is it an 2.1->2.2 translation remaining ? Is is standard now, and in this case is there somewhere I could find some information about it ? Thank you very much ! -- Olivier Billard
Re: XML to Excel template examples Required.
Siddhu, I recommend you to ask your question in the cocoon-users list. You will have a larger spectrum of people that would be happy to give you some hints. This list is for being informed / ask questions about the developments of Cocoon itself, not for developments "based on" Cocoon. Kind regards, -- Olivier Billard bloodredsaint saint wrote: Hi All, I am just beginner in cocoon. I have the following requirements: 1.I have input XML Ferrari Water Mercedes Air 2.I have a Excel template Which already has headers (Car Name & Car Type) Task for me is to use the XML as a source generater & serilize the output using the predefined template. I would appreciate if you could share any working example of such type. I visited XML.com article ( http://www.xml.com/lpt/a/1096) and they have no examples where we can take the input feed from XML and generate on a Template. All example includes SQL and due to some freak problem, I am still struggling to get the SQL part running. Thanks in advance, -Siddhu
Re: Cocoon Maven plugin - Merging deployer & rcl
Reinhard Poetz wrote: Olivier Billard wrote: Reinhard Poetz wrote: Olivier Billard wrote: Guys, Olivier, thanks for your investigations. Could you please file a Jira bug report? Thanks! Done.
[jira] Created: (COCOON-2084) "deploy-war" mojo does not trigger web.xml patch.
"deploy-war" mojo does not trigger web.xml patch. - Key: COCOON-2084 URL: https://issues.apache.org/jira/browse/COCOON-2084 Project: Cocoon Issue Type: Bug Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Olivier Billard Priority: Minor web.xml patch is not triggered when calling the cocoon:deploy-war mojo. cocoon:deploy mojo works. Steps to reproduce : 1 - Create a simple Cocoon block with a web.xml patch 2 - Create a Cocoon webapp and define a dependency on the first block 3 - A call to the cocoon:deploy mojo triggers a web.xml patching. A call to the cocoon:deploy-war mojo does not trigger it. Additional information : Calling the 2 mojos one after another does trigger web.xml patching for both mojos. Priority set to "Minor", since a patched webapp can still be created using the "cocoon:deploy" mojo, and creating then the war by hand. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Cocoon Maven plugin - Merging deployer & rcl
Reinhard Poetz wrote:
Olivier Billard wrote:
Guys,
I plug into your thread because I'm right into it : I checked-out the
Cocoon ACEGI sample, completed it and tested it, it's great.
But I've got trouble with the xweb file : using the block-only rcl
webapp, patch is correctly applied, but I would like to make my app
security with ACEGI a block (seems promising with ACEGI as a filter
and xweb), but such a block included into a webapp block does not
triggers web.xml patching when calling "mvn package".
Did I missed something ?
Yes, you have to use the deployer goal ('mvn cocoon:deploy') in order to
get your xweb patches applied. The package plugin isn't aware of
Cocoon's xweb patching mechanism.
Thank you for your answer Reinhard, I really missed this plugin part, sorry.
This could be continued in the users list if you think this is more suited.
Nevertheless, as this seems to be a bug in the dev version (not released yet),
I continue on the dev list for the moment.
This perfectly works with the "deploy" mojo, but not for the "deploy-war" one,
with exactly the same configuration.
I meet a strange phenomenon, that could possibly be a bug in the cocoon-maven-plugin ? web.xml patch is not applied with the "deploy-war", except
after a "deploy" mojo call :). Of course these mojos are not meant to be called one after the other, but this could be a clue for resolution: maybe a
context is not properly initialized when "deploy-war" mojo is called alone?
Maven outputs below.
--
Olivier Billard
--> This works:
[INFO]
[INFO] Building ACEGI Security Sample - Webapp
[INFO]task-segment: [clean, cocoon:deploy]
[INFO]
[INFO] [clean:clean]
[INFO] [cocoon:deploy]
[INFO] Exploding webapp...
[INFO] Assembling webapp webapp in \webapp\target\webapp-1.0-SNAPSHOT
[INFO] Copy webapp webResources to \webapp\target\webapp-1.0-SNAPSHOT
[INFO] Copy webapp webResources to \webapp\target\webapp-1.0-SNAPSHOT
[INFO] Applying patches to: WEB-INF/web.xml
[INFO]
[INFO] BUILD SUCCESSFUL
--> This does not work:
[INFO]
[INFO] Building ACEGI Security Sample - Webapp
[INFO]task-segment: [clean, cocoon:deploy-war]
[INFO]
[INFO] [clean:clean]
[INFO] [cocoon:deploy-war]
[INFO] Exploding webapp...
[INFO] Assembling webapp webapp in \webapp\target\webapp-1.0-SNAPSHOT
[INFO] Copy webapp webResources to \webapp\target\webapp-1.0-SNAPSHOT
[INFO] Copy webapp webResources to \webapp\target\webapp-1.0-SNAPSHOT
[INFO] No patches to apply<-- *oops*
[INFO] Generating war
E:\Dev\soprano-ng\sources\sandbox\example-apps\acegi-example\webapp\target\webapp-1.0-SNAPSHOT.war
[INFO] Building war:
E:\Dev\soprano-ng\sources\sandbox\example-apps\acegi-example\webapp\target\webapp-1.0-SNAPSHOT.war
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
--> This works, but hum...
[INFO]
[INFO] Building ACEGI Security Sample - Webapp
[INFO]task-segment: [clean, cocoon:deploy, cocoon:deploy-war]
[INFO]
[INFO] [clean:clean]
[INFO] [cocoon:deploy]
[INFO] Exploding webapp...
[INFO] Assembling webapp webapp in
E:\Dev\soprano-ng\sources\sandbox\example-apps\acegi-example\webapp\target\webapp-1.0-SNAPSHOT
[INFO] Copy webapp webResources to
E:\Dev\soprano-ng\sources\sandbox\example-apps\acegi-example\webapp\target\webapp-1.0-SNAPSHOT
[INFO] Copy webapp webResources to
E:\Dev\soprano-ng\sources\sandbox\example-apps\acegi-example\webapp\target\webapp-1.0-SNAPSHOT
[INFO] Applying patches to: WEB-INF/web.xml <-- *patch applied 1 time ...*
[INFO] [cocoon:deploy-war]
[INFO] Exploding webapp...
[INFO] Assembling webapp webapp in
E:\Dev\soprano-ng\sources\sandbox\example-apps\acegi-example\webapp\target\webapp-1.0-SNAPSHOT
[INFO] Copy webapp webResources to
E:\Dev\soprano-ng\sources\sandbox\example-apps\acegi-example\webapp\target\webapp-1.0-SNAPSHOT
[INFO] Copy webapp webResources to
E:\Dev\soprano-ng\sources\sandbox\example-apps\acegi-example\webapp\target\webapp-1.0-SNAPSHOT
[INFO] Applying patches to: WEB-INF/web.xml <-- *and again a second time.
Here deploy-war mojo applies the patch*
[INFO] Generating war
E:\Dev\soprano-ng\sources\sandbox\example-apps\acegi-example\webapp\target\webapp-1.0-SNAPSHOT.war
[INFO] Buildi
Re: Cocoon Maven plugin - Merging deployer & rcl
Guys, I plug into your thread because I'm right into it : I checked-out the Cocoon ACEGI sample, completed it and tested it, it's great. But I've got trouble with the xweb file : using the block-only rcl webapp, patch is correctly applied, but I would like to make my app security with ACEGI a block (seems promising with ACEGI as a filter and xweb), but such a block included into a webapp block does not triggers web.xml patching when calling "mvn package". Did I missed something ? Thanks a lot for your answers ! -- Olivier Billard Giacomo Pati wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Reinhard Poetz wrote: The second one allows "patching" the web.xml by adding snippets from META-INF/cocoon/xpatch to it. It also supports a feature that reverses the classloader hierarchy in a web application by using a shielding classloader. But can only be used if packaging of the project is war! I ported the patching functionality to cocoon:rcl too. In order to be consistent with our other directory names, the plugins search for patch files in /COB-INF/cocoon/xpatch/*.xweb. What was the reason to change the path from /META-INF/cocoon/xpatch/*.xweb to /COB-INF/cocoon/xpatch/*.xweb? It's confusing to me to change that. But I have to admit that I only tested it very basically because I don't really use it myself. That's why I'm trying and asking ;-) Ciao and thanks - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (GNU/Linux) iD4DBQFGOFm8LNdJvZjjVZARAiVmAJQLqqVe+SGxOigcyUzRmFze33veAKDtsGR5 4sA6xjYRM6ZIrTzsvLbgOg== =16x4 -END PGP SIGNATURE-
Re: trunk broken?
Antonio, (all,) FYI, we won the fight, we'll be using 6.0. Yes-s-s :). I still presume that I was not the only one, however there is one less now ! -- Oliv_i_er Antonio Gallardo wrote: Oliver, I think we will stay at 1.4 Thank your for your feedback. :) Best Regards, Antonio Gallardo. Olivier Billard escribió: Hello there, This is my humble case :), but we are planning to use Cocoon 2.2, and cannot decide (customer does) on Java version, that is strongly likely to be Java 1.4... Because our Cocoon application will be embedded into a bigger existing software architecture based/tested/deployed on Java 1.4. They are some cases where you cannot do it in another way, unfortunately, Antonio :)... I personally think (in a Cocoon user POV) that this should be planned, announced far before doing this, so users like me can plan for it and decide knowing the consequences.
Re: HSSFSerializer
Hi Chan,
This question should be asked in the cocoon-users mailing list.
Regards,
-- Olivier Billard
Chan Mei Theng wrote:
Hi,
Kindly advise.
I am facing compilation error.
public void convert(InputStream in, OutputStream out)
throws Exception
{
throw new Error("Unresolved compilation problems:
\n\tHSSFSerializer cannot be resolved to a type" + "\n\tHSSFSerializer
cannot be resolved to a type\n"
);
Jars Used
cocoon-poi-2.1.9.jar
serializer.jar
xalan.jar
xercesImpl.jar
xml-apis.jar
xsltc.jar
Below is the java source code.
/*
* Created on Sep 1, 2005
*/
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
// import net.sourceforge.poi.serialization.HSSFSerializer;
import org.apache.cocoon.serialization.HSSFSerializer;
import java.io.*;
import javax.xml.parsers.*;
import org.xml.sax.*;
import org.xml.sax.*;
import org.w3c.dom.*;
import org.apache.xalan.xslt.*;
/**
* converts an xml stream into an xls stream
* @author wohlgemuth
*
*/
public class XML2XLSConverter {
/**
* converts an input XML file to an xls file
*
* @throws Exception
*
* @see
edu.ucdavis.genomics.metabolomics.binbase.meta.converter.AbstractConverter#convert(java.io.InputStream,
* java.io.OutputStream)
*/
public void convert(InputStream in, OutputStream out) throws Exception {
org.apache.cocoon.serialization.HSSFSerializer
hssfSerializer = new org.apache.cocoon.serialization.HSSFSerializer();
hssfSerializer.setOutputStream (new
FileOutputStream ("result.xls"));
XMLReader reader =
SAXParserFactory.newInstance().newSAXParser().getXMLReader();
reader.setContentHandler (hssfSerializer);
reader.parse (new InputSource (new
FileInputStream ("gnumeric.xml")));
}
/**
*
*/
public XML2XLSConverter() {
super();
}
public static void main(String[] args) throws FileNotFoundException,
Exception {
new XML2XLSConverter().convert(new FileInputStream(args[0]),new
FileOutputStream(args[1]));
}
}
Thanks & Regards
**Chan Mei ***Theng*
/Technical Developer/
**m: +6012 488 4484**
t: +603 2163 7233
f: +603 2163 8233
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
www.pocketgroup.co.uk <http://www.pocketgroup.co.uk/>
skype ID: mtchan48
*Experts in mobile content and services ***
Re: trunk broken?
Hello there, This is my humble case :), but we are planning to use Cocoon 2.2, and cannot decide (customer does) on Java version, that is strongly likely to be Java 1.4... Because our Cocoon application will be embedded into a bigger existing software architecture based/tested/deployed on Java 1.4. They are some cases where you cannot do it in another way, unfortunately, Antonio :)... I personally think (in a Cocoon user POV) that this should be planned, announced far before doing this, so users like me can plan for it and decide knowing the consequences. -- Olivier Billard Andrew Stevens wrote: From: [EMAIL PROTECTED] Date: Fri, 8 Jun 2007 17:16:27 +0100 Hi, (thanks for the reminder, Daniel - yes, I'd forgotten about the vote) On 8 Jun 2007, at 00:57, Andrew Stevens wrote: Well, for what it's worth (which isn't much) I for one am glad Cocoon 2.2 still supports JDK 1.4. It's finally looking like our US datacentre is getting their act together so my team can plan to migrate our sites off Websphere 5.0 (JDK 1.3, and end-of-life'd about 9 months ago!) onto a more recent version. However, the new version that they are willing to support is 6.0, which uses... JDK 1.4 Useful feedback indeed Andrew, it's always helpful for us to know what the issues are out there in the real world. Are you using c2.1 or c2.2 at the moment? Currently 2.1, and a couple of versions behind at that. We'll probably be moving to a more recent version in the near future, but whether that's the latest 2.1.x or 2.2 will depend on how stable 2.2 is by that point, and how much effort it is to update our application and existing customised components (including the fins charting components, which I modified a while back to work in Cocoon 2.1.7 & JDK 1.3). Andrew.
Re: Cocoon 2.2 status for a new project
Reinhard Poetz wrote: Olivier Billard wrote: Hi all, I plan to use Cocoon for a project on the starting blocks. But I need to know if Cocoon 2.2 is ready for a new (big, critical) project (stable enough in terms of APIs for example), to make the good choice :). Recently, some work has been done on the CForms, for example. Can someone please give me a status on this branch ? As Grek pointed out, trunk can be considered as stable, except the recently added servlet-services (aka postable sources) which are currently under development. If there aren't any unforeseeable showstoppers we can release Cocoon 2.2RC1 + the most important blocks: ajax, apples, auth, batik, catpcha, databases, flowscript, fop, forms, html, mail, template. The most prominent missing blocks are javaflow, portal, lucene and serializers. If you don't need them, I'd say use 2.2RC1. Thank you for your answer, Reinhard. Since I am not planning to use the last blocks you mentioned, I will go for Cocoon 2.2, so. And good luck for your release ! -- Olivier Billard
Re: Cocoon 2.2 status for a new project
Glad to hear (read, in fact) that, thanks for the info, Grzegorz ! I am impatiently waiting for this release. Thank you for your work, Reinhard. -- Olivier Billard Grzegorz Kossakowski wrote: Olivier Billard pisze: Hi all, I plan to use Cocoon for a project on the starting blocks. But I need to know if Cocoon 2.2 is ready for a new (big, critical) project (stable enough in terms of APIs for example), to make the good choice :). We consider most of Cocoon 2.2 parts as API stable. The only module that I can think of that is likely to be changed is servlet-service-fw because it's under active development, now. Core is considered as API stable and quite well tested and Reinhard is just in between of RC release process of core-related modules. I think that we are quite close to the final release and it is safe to start development of a new application relying on it. Recently, some work has been done on the CForms, for example. I consider most of this work finished and even if there are any new changes they shouldn't break back-compatibility until final (1.0.0) release of Forms that should happen really soon. At least I would like to see it soon. :-) Given the fact that some people already rely on C2.2, it's safe to recommend C2.2 for you too. See this thread (the most recent one) discussing releases: http://thread.gmane.org/gmane.text.xml.cocoon.devel/72730
Cocoon 2.2 status for a new project
Hi all, I plan to use Cocoon for a project on the starting blocks. But I need to know if Cocoon 2.2 is ready for a new (big, critical) project (stable enough in terms of APIs for example), to make the good choice :). Recently, some work has been done on the CForms, for example. Can someone please give me a status on this branch ? Thank you very much! -- Olivier Billard
Re: [CLI] Problem with XSP compilation
Many thanks Simon,
Good to see there's a workaround !
I'll note this solution for the future, but as I wrote sooner, I got it by patching the CocoonBean with XSP-specific code remove
from 2.1.4 to 2.1.5. But your solution is cleaner.
Thanks again !
--
Olivier
Simon Mieth wrote:
On Wed, 12 Jan 2005 15:47:34 +0100
Olivier Billard <[EMAIL PROTECTED]> wrote:
Thanks for the answer, Simon.
Unfortunatly, this doesn't work for me, because I'm using Windows, and
the environment vars max length isn't that long, to store
all cocoon needed jars... And your solution requires to use the
CLASSPATH env var...
But this could have helped me :)
--
Olivier
Hi Olivier,
Ant can do the job too. Here is a simple build-file.
fork="yes">
Put this ('precompile.xml') to the cocoon-root folder of your
cocoon-distribution and you can use the bundled ant from cocoon by:
java -cp tools/lib/ant.jar;tools/lib/ant-launcher.jar
org.apache.tools.ant.Main -f precompile.xml
will generate all to the work-directory (cocoon.work-property).
Best Regards,
Simon
Re: [CLI] Problem with XSP compilation
Sylvain Wallez wrote: Olivier Billard wrote: Hi Cocooners, First, I wish you a great year and may all your projects (professionnal but also personal) be accomplished ! Then, I would like to explain my pb. I developped a small app that creates a cli.xconf file with all XSP of a webapp. Then when I launch the Cocoon CLI, it stops without an error or a warning, and no XSP is compiled. Here is a snippet of the xconf file, maybe something will shock you : Some time ago, a post suggested to put the servlet.jar in the webapp/WEB-INF/lib, but no success with this tip. I tried with the 20050110111331 snapshot and the 2.1.6 release... Many many thanks in advance, 'cause I'm turning mad. I had a quick look at the CocoonBean and associated classes, and it turns out that precompile-only has been violently deleted when XSP was moved to its own block. Was it on purpose or just because of lazyness ? I can't remember a discussion about this, and the precompile-only is still available but silently ignored... Thanks for your answer, Sylvain. I temporarily went back to the precompile-specific code, to re-insert this code on a patched version of the 2.1.6. My Cocoon-core knowledge is not very good, and my time is more than counted, so I can't help on this "re-integration", maybe later, if someone more skilled doesn't have done it :). Thanks again for the care ! -- Olivier
Re: [CLI] Problem with XSP compilation
Simon Mieth wrote: Hi, some weeks ago I collect all the removed stuff into a single XSPPrecompileWrapper. The wrapper is located in the XSP-block and it is only available by including the block. Maybe a poor solution, but leaves the CocoonBean independent from blocks. The patch is in Bugzilla: http://issues.apache.org/bugzilla/show_bug.cgi?id=29360 Thanks for the answer, Simon. Unfortunatly, this doesn't work for me, because I'm using Windows, and the environment vars max length isn't that long, to store all cocoon needed jars... And your solution requires to use the CLASSPATH env var... But this could have helped me :) -- Olivier
[CLI] Problem with XSP compilation
Hi Cocooners, First, I wish you a great year and may all your projects (professionnal but also personal) be accomplished ! Then, I would like to explain my pb. I developped a small app that creates a cli.xconf file with all XSP of a webapp. Then when I launch the Cocoon CLI, it stops without an error or a warning, and no XSP is compiled. Here is a snippet of the xconf file, maybe something will shock you : E:\Dev\Soprano\Soprano\defaultroot E:\Dev\Soprano\Soprano\defaultroot\WEB-INF\cocoon.xconf E:\Dev\Soprano\Soprano\defaultroot\work E:\Dev\Soprano\Soprano\defaultroot\dest index.html */* Some time ago, a post suggested to put the servlet.jar in the webapp/WEB-INF/lib, but no success with this tip. I tried with the 20050110111331 snapshot and the 2.1.6 release... Many many thanks in advance, 'cause I'm turning mad. -- Olivier Billard
Re: GT2004 was brilliant
Thanks a lot all of you for this event ! This was my first GT and I found marvellous to be able to talk with everyone involved in Cocoon (special thanks to Christian, Sylvain and Bertrand :)). The presentations were all very interesting, and I regret I hadn't those infos when I started Cocoon 2 years ago, and I recognized all of my mistakes in the show of Jeremy (great pres' !). Continue this great work that made Cocoon such a kickass framework (even if "framework" is now very restrictive :)). -- Olivier Billard Arje Cahn wrote: Hi everyone, One big thanks to everyone involved in organizing another brilliant G(h)e(n)tTogether. I had great fun talking to everyone and hearing all about the latest Cocoon news, and I'm definitely looking forward to see you all next year. Diner was great, beers were great, the talks were great, well just about everything actually.. Apart for the headache yesterdaymorning ([EMAIL PROTECTED] you English), I hope to do it all over again next year, hopefully in Ghent again! Thanks! Kind regards, Arjé Cahn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl --
Re: Test
Siesta time :) Sylvain Wallez wrote: Just a test, wondering why the list is so silent lately. Is everyone busy? Sylvain
Re: [Authentication-fw] Per-user unique authentication
Thanks for you answer, Carsten ! Details below : Carsten Ziegeler wrote: Olivier Billard wrote: Hi cocooners ! For a project, I must have a unique authentication per user. If I have well understood, currently, the auth-fw is based on session existency to check if a user is authenticated. But it doesn't prevent users to use several browsers (and/or browser windows) on different locations to authenticate twice. I had a discussion with Sylvain (many thanks to him !), that proposed to use the org.apache.cocoon.environment.Context to store a map of authenticated users, as a reference to check for extra authentication. It would be very interesting if it could be embeded into, maybe a org.apache.cocoon.webapps.authentication.components.Authentica tor, to fit the actual auth-fw. And in addition the "user authentication context" stored in the context map should be aware of session invalidation, to clear itself from the map, and maybe deal with some other cleaning (two asses kicked with one foot ;)). Is this the right way to go ? Is there another better way ? Good questions :) From your description I guess that when a user uses a second browser the user has to authenticate again. Yes. It is not possible to know that this user is the same one than someone else who has already logged in. Or do I oversee something? No you're right, and that exactly the problem :) You can write your own Authenticator to test if this user is already logged in - for example by storing the information in the context. But of course this user gets his own session and there his own session context where data might be stored. If you want that this two users (who are actually the same :) ) share the same data you have to do this yourself and store/retrieve the data from the appropriate places. Since I don't want any user to try to login without disabling previous session, no problem here :) I think you can handle the invalidation using a session listener. Thanks for confirming the idea ! I'll go this way ! -- Olivier
[Authentication-fw] Per-user unique authentication
Hi cocooners ! For a project, I must have a unique authentication per user. If I have well understood, currently, the auth-fw is based on session existency to check if a user is authenticated. But it doesn't prevent users to use several browsers (and/or browser windows) on different locations to authenticate twice. I had a discussion with Sylvain (many thanks to him !), that proposed to use the org.apache.cocoon.environment.Context to store a map of authenticated users, as a reference to check for extra authentication. It would be very interesting if it could be embeded into, maybe a org.apache.cocoon.webapps.authentication.components.Authenticator, to fit the actual auth-fw. And in addition the "user authentication context" stored in the context map should be aware of session invalidation, to clear itself from the map, and maybe deal with some other cleaning (two asses kicked with one foot ;)). Is this the right way to go ? Is there another better way ? Many thanks ! -- Olivier Billard
Re: Learning Cocoon
Hi Dickson; I began to understand the cocoon core well by debugging with Eclipse... You will find find more info here : http://wiki.cocoondev.org/Wiki.jsp?page=HowTos And more precisely here : http://wiki.cocoondev.org/Wiki.jsp?page=DebuggingCocoon -- Olivier Billard Dickson Tam wrote: I'd like understand how Cocoon and CForms works internally, so can make some modifications to CForms that I badly need. Can someone tell me what is the best way to understand how Cocoon works internally? Dickson Tam
Datasource bug or javadoc error ?
Hi Cocooners, It may more suit for the avalon list, but since the most of the use is in cocoon (I guess), maybe you experimented my pb. In the ResourceLimitingJdbcDataSource, used by default as DataSourceComponent in Cocoon, it is said for the auto-commit conf : "The auto-commit attribute is used to determine the default auto-commit mode for the Connections returned by this DataSource." So for me, when I get a connection via datasource.getConnection(), if I set auto-commit="true" in the datasource conf, the connection that I get has the autocommit to "true". "Eh bé non !" (damned) The autocommit is only set when a new instance is created by the connection factory, and never later... So if you get a first connection, its autocommit is set to the value you put in the datasource conf, but if a connection having an autocommit to "false" returns to the pool, the next connection you'll get will have a "false" autocommit, and not the value you set in the datasource conf... Is there a thing that misunderstood, or is this a bug ? -- Olivier Billard
[XSP] Bug in the XSLT processor cache ?
Hi cocooners ! I have a really annoying problem with the cache of the XSLT processors, and someone also [1], with the 2.1.4. When the use-store option is set to "true" for XSLT processors, an XSP compilation error, occurs when trying to access the XSP many times during the compilation. The problem occurs when the XSP has many dependencies over some logicsheets, these logicsheets having also dependencies over others (no cycle). For me the request logicsheet is not processed, and xsp-request tags are present in the Java code, causing the compilation error. Apparently (I cannot reproduce it systematically, so I didn't manage to successfully do it), switching the use-store to "false" resolves the pb (see [1]). Is this a known bug ? Is there any patch available ? Thanks for any hint ! [1] http://marc.theaimsgroup.com/?t=108246918200008&r=1&w=2 -- Olivier Billard
Re: [Portal] Why don't cocoon errors appear in a coplet ?
On 03/03/2004 11:47, Carsten Ziegeler wrote: Olivier Billard wrote: For some of our pipelines, we don't use the cocoon protocol, but just a serverpages generator. Renaming a variable in the XSP to cause a "Language Exception" page, I still have the content of the coplet empty (but as before the decoration remains : My title). And I still have the "correct" error display when calling directly the coplet pipeline. I added error-uri xsi:type="java:java.lang.String" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>cocoon:/ erreur-coplet in the profiles/copletdata/portal.xml in my coplet and added a match in the sitemap, in the very beginning to avoid */**-like matchings : but I have the same result : the content of the coplet is void, and it seems that this pipeline is never called. You can't use the "notifying" generator there as this is a new pipeline call (internally). So you can e.g. use the file generator reading a standard error.xml or something like that. ok. I changed the pipeline : but no progress... But it's right that the portal uses the cocoon protocol to aggregate the various coplet contents. But why doesn't it detect map:handle-errors branchings ? That's how the cocoon: protocol was designed :) (So, again has nothing to do with the portal). Now, I'm not sure, but it might be possible to change the code of the portal coplet adapter, so that it passes the exception into the error pipeline so that you can use the "notifying" generator. Might be possible. woutchou ;) ! That very much work for this handling, don't you think ;) ? Didn't you experiment such a behaviour, using the portal ? If you cause an error (resource not found, language exception, ...) in a coplet, you have a wide-screen cocoon error ? Or your "error-uri" attribute pipeline is called for all types of errors ? When I rename the src of the XSP, the error don't display in the portal, but displays well when calling the coplet pipeline directly... Thanks again for your answers, Carsten ! -- Olivier BILLARD
Re: [Portal] Why don't cocoon errors appear in a coplet ?
Hi Carsten, Thanks for your answer. For some of our pipelines, we don't use the cocoon protocol, but just a serverpages generator. Renaming a variable in the XSP to cause a "Language Exception" page, I still have the content of the coplet empty (but as before the decoration remains : My title). And I still have the "correct" error display when calling directly the coplet pipeline. I added error-uri http://www.w3.org/2001/XMLSchema-instance";>cocoon:/erreur-coplet in the profiles/copletdata/portal.xml in my coplet and added a match in the sitemap, in the very beginning to avoid */**-like matchings : but I have the same result : the content of the coplet is void, and it seems that this pipeline is never called. But it's right that the portal uses the cocoon protocol to aggregate the various coplet contents. But why doesn't it detect map:handle-errors branchings ? On 03/03/2004 09:44, Carsten Ziegeler wrote: Hi, the answer isn't related to the portal but to the Cocoon sitemap engine: The portal uses internal pipeline calls (cocoon: protocol). Whenever Cocoon uses an internal pipeline call, the error handler of that pipeline is never invoked, so if you do a and there is an error in your "my-pipeline", the error handler of "my-pipeline" is never invoked. In the case above the error handler of the pipeline containing the map:generate is invoked. In the case of the portal, the error is "ignored". You can specify for each coplet an alternative pipeline that is invoked if the real content pipeline throws an error. Have a look at the configuration of the coplet showing my weblog. That coplet shows the "real" content from the net if you have a network connection, if not a static (old) xml file is read. HTH Carsten -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Olivier Billard Sent: Tuesday, March 02, 2004 6:25 PM To: [EMAIL PROTECTED] Subject: [Portal] Why don't cocoon errors appear in a coplet ? Hi cocooners ! I posted in the users' but maybe some sitemap gurus can show me the light ;). I use the portal for a project and i'm not able to display errors in a (main) coplet. I always have a blank content, as if when rendering the content of the coplet, the error content is not put in the whole portal page. I tried xml-serializing, html-serializing errors : ---> (map:otherwise is choosen, i tried renaming the transformer src attribute) But no way : I have no content in the coplet... I can right display the error when calling the coplet pipe, but it' empty in the portal page... It seems to work like standard/error output : when an error occurs, the standard sitemap output is empty, and the sitemap error output contains the error catched in the map:handle-errors. Thanks in advance for your answers ! -- Olivier BILLARD
[Portal] Why don't cocoon errors appear in a coplet ?
Hi cocooners ! I posted in the users' but maybe some sitemap gurus can show me the light ;). I use the portal for a project and i'm not able to display errors in a (main) coplet. I always have a blank content, as if when rendering the content of the coplet, the error content is not put in the whole portal page. I tried xml-serializing, html-serializing errors : ---> (map:otherwise is choosen, i tried renaming the transformer src attribute) But no way : I have no content in the coplet... I can right display the error when calling the coplet pipe, but it' empty in the portal page... It seems to work like standard/error output : when an error occurs, the standard sitemap output is empty, and the sitemap error output contains the error catched in the map:handle-errors. Thanks in advance for your answers ! -- Olivier BILLARD
Re: State/size of pools ?
On 04/02/2004 12:37, Vadim Gritsenko wrote: Olivier Billard wrote: Hi cocooners ! (again) Is there a way to show the content at time t of objects pools ? By debug traces ? a special-secret-powerfull-tool ;) ? There is some secret super-powerful tool... Name is excalibur-instrument-manager, and when instrumentation enabled, you can launch some GUI app to see what's happening. I've not used it yet; archives should have mentionings of it. Vadim Oh oh :) ! Seems really a great super-secret-powerfull tool ! Thanks a lot Vadim ! I've heard of "instruments" in a training course of Mr Wallez ;). I'll check into this... Thanks again -- Olivier BILLARD
Re: Pools and max-objects
Ok great that's what I was wondering. Thanks a lot Geoff ! -- Olivier On 03/02/2004 14:09, Geoff Howard wrote: Olivier Billard wrote: Hi Geoff, Thanks for your answer. But what's the use of this transient store, then ? For cacheable pipeline content ? Yes, and some other components are using it for cacheable by-products I think, but not for component instances which the pool settings are about. Geoff On 03/02/2004 13:26, Geoff Howard wrote: Olivier Billard wrote: Hi cocooners ! Interaction between max-objects defined in cocoon.xconf and the pool-max of poolable components is not very clear for me. Thanks for bringing me the light :). Is max-objects the great max of object instances that can live in cocoon, ignoring the pool-max defined for each object ? In that case for exemple, if I have 5 poolable objects with pool-max set to 32 and max-objects set to 100, will I never fill all the pools to max ? If 100 instances of my objects are created, i'll never get others ? I've read in the wiki [1] that the max-objects must be set from 4000 to 8000 in production, that i think well, is more correct than the 100 defaut... But with a minimal build (datasource, portal and 1 or 2 more blocks), there is at least 5 poolable objects with pool-max set to 32, that could (on heavy load i agree) create up to 160 objects, but with max-objects set to 100, that could never happen, no ? Thanks for your answers ! [1] : http://wiki.cocoondev.org/Wiki.jsp?page=CocoonPerformance From that page: "Make sure you set the "maxobjects" (cocoon.xconf) of the transient-store...". Transient store is totally unrelated to the component instance pools, so there is no interaction between the numbers. Geoff
Re: Pools and max-objects
Hi Geoff, Thanks for your answer. But what's the use of this transient store, then ? For cacheable pipeline content ? On 03/02/2004 13:26, Geoff Howard wrote: Olivier Billard wrote: Hi cocooners ! Interaction between max-objects defined in cocoon.xconf and the pool-max of poolable components is not very clear for me. Thanks for bringing me the light :). Is max-objects the great max of object instances that can live in cocoon, ignoring the pool-max defined for each object ? In that case for exemple, if I have 5 poolable objects with pool-max set to 32 and max-objects set to 100, will I never fill all the pools to max ? If 100 instances of my objects are created, i'll never get others ? I've read in the wiki [1] that the max-objects must be set from 4000 to 8000 in production, that i think well, is more correct than the 100 defaut... But with a minimal build (datasource, portal and 1 or 2 more blocks), there is at least 5 poolable objects with pool-max set to 32, that could (on heavy load i agree) create up to 160 objects, but with max-objects set to 100, that could never happen, no ? Thanks for your answers ! [1] : http://wiki.cocoondev.org/Wiki.jsp?page=CocoonPerformance From that page: "Make sure you set the "maxobjects" (cocoon.xconf) of the transient-store...". Transient store is totally unrelated to the component instance pools, so there is no interaction between the numbers. Geoff
State/size of pools ?
Hi cocooners ! (again) Is there a way to show the content at time t of objects pools ? By debug traces ? a special-secret-powerfull-tool ;) ? Thanks for your answers ! -- Olivier BILLARD
Pools and max-objects
Hi cocooners ! Interaction between max-objects defined in cocoon.xconf and the pool-max of poolable components is not very clear for me. Thanks for bringing me the light :). Is max-objects the great max of object instances that can live in cocoon, ignoring the pool-max defined for each object ? In that case for exemple, if I have 5 poolable objects with pool-max set to 32 and max-objects set to 100, will I never fill all the pools to max ? If 100 instances of my objects are created, i'll never get others ? I've read in the wiki [1] that the max-objects must be set from 4000 to 8000 in production, that i think well, is more correct than the 100 defaut... But with a minimal build (datasource, portal and 1 or 2 more blocks), there is at least 5 poolable objects with pool-max set to 32, that could (on heavy load i agree) create up to 160 objects, but with max-objects set to 100, that could never happen, no ? Thanks for your answers ! [1] : http://wiki.cocoondev.org/Wiki.jsp?page=CocoonPerformance -- Olivier BILLARD
Re: [ESQL] bug when retrieving a null CLOB ?
Thanks for your answer, Christian. I'll do it as soon as possible. -- Olivier On 08/01/2004 08:32, Christian Haul wrote: Olivier Billard wrote: Hi Cocooners ! In the EsqlHelper class / getAscii method, no test is done against the null value when getting a CLOB : ... Clob dbClob = set.getClob(column); int length = (int) dbClob.length(); ... So when using to retrieve a possible value, a CascadingRuntimeException is thrown, even if a @null attribute is set... Do I miss something or do you want a patch ? A patch would be great. Thanks for spotting this. Chris.
Re: [cforms] Optionally required fields
Hi all, Hi Antonio,
In the 2.1.2 version of Cocoon, a call to form.getWidget().isValid() always returns false,
even if the form seems to be valid...
Is it the right behaviour ?
For me, this call would be far more practical than testing the null value of all required
widgets... or do I miss something ?
function myValidator(form) {
if (!form.getWidget().isValid())
return false;
...my business code...
}
Furthermore, according to woody.js :
var finished = this.form.process(formContext);
var evt = formContext.getActionEvent();
if (evt != null) {
this.submitId = String(evt.getActionCommand());
} else {
this.submitId = undefined;
}
// If either validation was successfull or there was an event, call the
validator
if ((finished ||this.submitId != null) && this.validator != undefined) {
finished = this.validator(this);
}
if (finished) {
break;
}
The validator seems to call the flow validator _only if_ the form processed correctly (ie
is valid) (cf Form.java). But is it really the case ? It appears that we need to test null
values of required fields in the validator, and that isValid() returns false in the flow
validator...
--
Olivier
On 07/01/2004 23:55, Antonio Gallardo wrote:
Sylvain Wallez dijo:
Hi all,
I encountered a problem today: I have a form where a field is required
or not depending on the value of another field. I wanted to control this
using the validation (with a ) but couldn't as the validators
aren't called if the value is null.
True, but you can "attach" your own validator in javascript. We are doing
this and work fine. Example:
function createform(form) {
form.validator = ValidateCreatePlan;
form.showForm("create-form-display");
cocoon.sendPage("success");
}
function ValidarCrearPlan(form) {
var result = true;
if (form.getWidget("recall").booleanValue() != null) {
if (form.getWidget("number of recalls").value() == null) {
addMessage("Please add the number of recalls");
resultado = false;
}
}
return result;
}
To allow this, I wanted to propose that, when a field isn't explicitely
marked as required, validators be called even if the value is null.
No a good idea. This was througly discussed before. In fact that was the
"old" approach and after a long discussion, we settled to let it as is
now:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106148623116701&w=2
(please follow the thread).
But then comes another problem, since most validators expect a non-null
value and will break on NPE if no value is given.
So what about the following changes:
- when a field isn't marked as required, validators are called even if
the value is null,
- validators that need a value to do their job (e.g. regexp, range,
email, etc) will return "true" (valid) for a null value
Hmm. We are breaking conventions.
- other validators (such as assert) will behave according to their
semantics with null values.
Re: How to validate (range, min, max) a field depending on another (boolean) field value ? Was: [cforms] Optionally required fields
Thanks for your answer Sylvain, A boolean condition on the assert validator instead of a range validator suits me well, but to play the devil's advocate ;), what about more complex validations, such email ? No way for the moment ? It would be very interesting ! -- Olivier PS : also about woody, I had another question about validation on users' ;) : http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=107340459803769&w=2 On 07/01/2004 18:26, Sylvain Wallez wrote: Olivier Billard wrote: Hi all, Hi Sylvain, Hi Olivier! Your post makes me wonder if it is possible to do validation of a field (any type of validation) depending of another field value, or "conditionize" the requirement of a field depending on another field value : Exemple : - boolean field "recall" : true/false - field "number of recalls" : required if recall is true and ranges from 1 to n is it possible to do so ? What about using the "assert" validator? Of course, you'll have to write a boolean condition rather than just using the attributes provided by the "range" validator. For the moment,I set "number of recalls" field required with a default value of 1, but display the field only if recall is true (hidden otherwise)... and deal with its requirement later in business code... but if woody could do this, it would be cool. Well, seems it already does it ;-) Sylvain
How to validate (range, min, max) a field depending on another (boolean) field value ? Was: [cforms] Optionally required fields
Hi all, Hi Sylvain, Your post makes me wonder if it is possible to do validation of a field (any type of validation) depending of another field value, or "conditionize" the requirement of a field depending on another field value : Exemple : - boolean field "recall" : true/false - field "number of recalls" : required if recall is true and ranges from 1 to n is it possible to do so ? For the moment,I set "number of recalls" field required with a default value of 1, but display the field only if recall is true (hidden otherwise)... and deal with its requirement later in business code... but if woody could do this, it would be cool. -- Olivier On 07/01/2004 17:58, Sylvain Wallez wrote: Hi all, I encountered a problem today: I have a form where a field is required or not depending on the value of another field. I wanted to control this using the validation (with a ) but couldn't as the validators aren't called if the value is null. To allow this, I wanted to propose that, when a field isn't explicitely marked as required, validators be called even if the value is null. But then comes another problem, since most validators expect a non-null value and will break on NPE if no value is given. So what about the following changes: - when a field isn't marked as required, validators are called even if the value is null, - validators that need a value to do their job (e.g. regexp, range, email, etc) will return "true" (valid) for a null value - other validators (such as assert) will behave according to their semantics with null values. What do you think?
[ESQL] bug when retrieving a null CLOB ?
Hi Cocooners ! In the EsqlHelper class / getAscii method, no test is done against the null value when getting a CLOB : ... Clob dbClob = set.getClob(column); int length = (int) dbClob.length(); ... So when using to retrieve a possible value, a CascadingRuntimeException is thrown, even if a @null attribute is set... Do I miss something or do you want a patch ? Thanks, -- Olivier BILLARD
Woody : javascript version ?
Hi all, I would like to know what is the version of javascript used in woody (sorry CocoonForms) in the def file, inside tags ? is it the same as the one used by the flow ? I'm having troubles with the split() fonction, that works well in the flow but not in the CocoonForms def file. Thanks, -- Olivier BILLARD
Re: Portal : access to request parameters in CompositeContentAspect ?
I tried and it works fine. I'm now able to switch the selected tab with a request param. Thanks again, Casten ! -- Olivier On 10/11/2003 17:32, Carsten Ziegeler wrote: Sorry, not much time to answer :) You can access the request parameters in any component via the objectModel (See ObjectModelHelper). And you get the objectModel using the Contextualizable Interface and the ContextHelper class. HTH Carsten -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Olivier Billard Sent: Monday, November 10, 2003 2:30 PM To: [EMAIL PROTECTED] Subject: Portal : access to request parameters in CompositeContentAspect ? Hi all, How can I have access to the request parameters in a CompositeContentAspect ? I would like to write a TabContentAspect "tab-selectable" from the URL.. Is it possible ? -- Olivier BILLARD
Re: Portal : access to request parameters in CompositeContentAspect ?
Cool, I began to despair ;)... Thanks very much Carsten, I'll try this. -- Olivier On 10/11/2003 17:32, Carsten Ziegeler wrote: Sorry, not much time to answer :) You can access the request parameters in any component via the objectModel (See ObjectModelHelper). And you get the objectModel using the Contextualizable Interface and the ContextHelper class. HTH Carsten -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Olivier Billard Sent: Monday, November 10, 2003 2:30 PM To: [EMAIL PROTECTED] Subject: Portal : access to request parameters in CompositeContentAspect ? Hi all, How can I have access to the request parameters in a CompositeContentAspect ? I would like to write a TabContentAspect "tab-selectable" from the URL.. Is it possible ? -- Olivier BILLARD
Portal : access to request parameters in CompositeContentAspect ?
Hi all, How can I have access to the request parameters in a CompositeContentAspect ? I would like to write a TabContentAspect "tab-selectable" from the URL.. Is it possible ? -- Olivier BILLARD
Re: Why not JDOM, why DOM ?
Thanks Jeff, it is in fact very interesting. -- Olivier On 17/10/2003 00:09, Jeff Ramsdale wrote: Here's some info you might find useful concerning XML parsing performance: http://www.sosnoski.com/opensrc/xmlbench/index.html Note it's a little out of date, but probably still somewhat relevant. Jeff
Re: Why not JDOM, why DOM ?
Thanks for your answer Carsten, but I think I didn't explain well my issue... For some components dealing with XML file (for configuration for exemple, or persistence) or XML documents (DOM or JDOM objects speaking), Cocoon offers some convenient tools to use for the W3C DOM model : for exemple, the XPathProcessor component takes org.w3c.dom.Node objects to parse, and in general excalibur, for evident standards issues, deals with W3C DOM model objects. My question is : If, for dev time performance, readability of the code ;), I would like to use JDOM, is there some warnings about using this lib ? : - performance of this lib compared the W3C Model - cost of bridging the format to use the Excalibur components (bad) - performance of other tools to do the same job (jaxen ?) I hope I'm clear :) -- Olivier On 15/10/2003 14:49, Carsten Ziegeler wrote: Nothing is prohibited in Cocoon, you can of course use whatever you want. Now, Cocoon is SAX based, not DOM. For your own code, you can either use SAX as well, or DOM, or JDOM, dom4j etc. Carsten -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Olivier Billard Sent: Wednesday, October 15, 2003 11:19 AM To: [EMAIL PROTECTED] Subject: Why not JDOM, why DOM ? Hi all? I hope my question(s) will not set this list on fire, I know there's some "pro-" and "against-" it outside... But I would like to know if the use of JDOM in Cocoon is prohibited, or if it could well be used. I think performances, of course. Thanks in advance ! -- Olivier BILLARD
Why not JDOM, why DOM ?
Hi all? I hope my question(s) will not set this list on fire, I know there's some "pro-" and "against-" it outside... But I would like to know if the use of JDOM in Cocoon is prohibited, or if it could well be used. I think performances, of course. Thanks in advance ! -- Olivier BILLARD
Re: Use of a connection in an avalon component
On 09/10/2003 15:10, Sylvain Wallez wrote: Olivier Billard wrote: Hi all ! I wonder how to use a DataSourceComponent and its connection in a custom cocoon avalon component, that is ThreadSafe, to use all performance and connection pool used in Cocoon. Should I : - get a connection via datasource.getConnection() and close() it for each public method call, - get a connection in the initialize() method from the interface Initializable, close() it on the dispose() method from Disposable interface, and only create a Statement for each public method call ? - implement another avalon interface, like Runnable, to get/relase the Connection ? I looked for exemples in the databases block, but the helpers are not Components. If your component is ThreadSafe, a single instance of it will exist in the whole system. JDBC connections being non thread safe, you *must* get and close them at each call. Don't be afraid to call close(): the connection you get is a wrapper managed by the DataSourceComponent which puts back the real request in the pool for later reuse when close() is called on the wrapper. by later reuse, do you mean datasource.getConnection() ? -- Olivier
Use of a connection in an avalon component
Hi all ! I wonder how to use a DataSourceComponent and its connection in a custom cocoon avalon component, that is ThreadSafe, to use all performance and connection pool used in Cocoon. Should I : - get a connection via datasource.getConnection() and close() it for each public method call, - get a connection in the initialize() method from the interface Initializable, close() it on the dispose() method from Disposable interface, and only create a Statement for each public method call ? - implement another avalon interface, like Runnable, to get/relase the Connection ? I looked for exemples in the databases block, but the helpers are not Components. Thank you, -- Olivier BILLARD
Re: [Portal] how to load a coplet before an other ?
Are they some samples dealing with events, or a way to find some doc ? On 26/09/2003 15:26, Olivier Billard wrote: Thanks very much for your answer Carsten, We're using the new portal block, so it could be possible to use the events... I'll check into this... Thanks again and have a nice we ! -- Olivier PS : is the use of events in the portal already wikified ?
Re: [Portal] how to load a coplet before an other ?
Thanks very much for your answer Carsten, We're using the new portal block, so it could be possible to use the events... I'll check into this... Thanks again and have a nice we ! -- Olivier PS : is the use of events in the portal already wikified ?
[Portal] how to load a coplet before an other ?
Hi all, My question would suit also the dev-list, so I repost it. Sorry if it's noise for you... My app is composed mainly of a left menu and a main page. Each of it is a coplet. Using flowscript, the main page modifies a file, which is parsed to render the left menu. Is it possible to prioriterize (a new word ?) the load of the coplets ? In final words I want to load the main page, _then_ the left menu... But the structure of the portal layout (menu definition, then main page) seems to control the rendering order... Thanks in advance -- Olivier BILLARD
Test - Please ignore
Test -- Olivier
Re: Dynamic XSL generation with "cocoon:" : excalibur Source or cocoonSource bug ?
Hi Sylvain ! How is the "back-to-the-work" ? I note this for the future, but I solved this pb with the use of "xalan" instead of "xslt". But maybe an error like the one you mentionned could make XSLTC go crazy... -- Olivier Sylvain Wallez wrote: Olivier Billard wrote: Hi all, I have some troubles with a dynamic generated xsl. Here is the sitemap snippet : And I've got the following stack trace (long... but maybe usefull for info) : To isolate the problem, you should also try to use a static snapshot of the XSL. This will tell if "cocoon:" is the culprit. Now I vaguely remember something about this EmptyStackException... do you have that comes after a child element of the one on which the attribute is to be added ? E.g : value If yes, you should move after Sylvain
Re: Dynamic XSL generation with "cocoon:" : excalibur Source or cocoonSource bug ?
Ah ok ! I also have a lot of steps using xsltc in my sitemap, working fine except those mentionned. I'll investigate when I will have time ;) ! Thanks a lot, Vadim ! -- Olivier Vadim Gritsenko wrote: Olivier Billard wrote: What do you mean about "Just added transform to xsl-dynamic-source" ? Meaning: I've just added a transformation step to the xsl-dynamic-source matcher to more closely reproduce your scenario and samples/sources/sitemap.xmap now reads: And content of test.xsl I sent in previous email and all is working just fine with xsltc. Vadim
Re: Dynamic XSL generation with "cocoon:" : excalibur Source or cocoonSource bug ?
What do you mean about "Just added transform to xsl-dynamic-source" ? Vadim Gritsenko wrote: Olivier Billard wrote: Hi Vadim ! Relatively to recent mails of the thread, you think it could work with xsltc, if some offendering xsl were removed ? Yes. Just added transform to xsl-dynamic-source: http://www.w3.org/1999/XSL/Transform"; xmlns:xsp="http://apache.org/xsp"; xmlns:xsp-request="http://apache.org/xsp/request/2.0";> Hey there!!! And it still works ok with default xslt transformer - which is xsltc. When/if you find a bug in xsltc please report it to xalan-dev or bugzilla. Vadim
Re: Dynamic XSL generation with "cocoon:" : excalibur Source or cocoonSource bug ?
Hi Vadim ! Relatively to recent mails of the thread, you think it could work with xsltc, if some offendering xsl were removed ? Thanks again -- Olivier Vadim Gritsenko wrote: Olivier Billard wrote: Hi all, I have some troubles with a dynamic generated xsl. Here is the sitemap snippet : And I've got the following stack trace (long... but maybe usefull for info) : but when I replace by http://localhost:/picto-filter.xsl";> all works well... But I don't want to externalize the xsl pipeline to the users !... Any idea ? Is this a problem in the pool of sources ? Start with working sample, and slowly grow from there: http://localhost:/samples/sources/xsl-dynamic When it stops working, then there is a bug in the last change you made. May be you have a problem in a way you generate SAX events of your xsl. Vadim
Re: [Half-solved] Dynamic XSL generation with "cocoon:" : excaliburSource or cocoon Source bug ?
Ok sorry :) ! I just wanted to keep the original mail... Joerg Heinicke wrote: But please cut at least the stack trace when responsing to such a long mail like your original one - again 59 KB. Joerg Olivier Billard wrote: I changed the default transformer from "xsltc" to "xalan" and it works... What's wrong with the xsltc ? That's not the first time I see things working with "xalan" and not "xsltc"... -- Olivier
Re: [Half-solved] Dynamic XSL generation with "cocoon:" : excaliburSource or cocoon Source bug ?
To be more precise, I changed the first transformer from default to "xalan" Olivier Billard wrote: I changed the default transformer from "xsltc" to "xalan" and it works... What's wrong with the xsltc ? That's not the first time I see things working with "xalan" and not "xsltc"... -- Olivier
[Half-solved] Dynamic XSL generation with "cocoon:" : excalibur Sourceor cocoon Source bug ?
I changed the default transformer from "xsltc" to "xalan" and it works... What's wrong with the xsltc ? That's not the first time I see things working with "xalan" and not "xsltc"... -- Olivier Olivier Billard wrote: Hi all, I have some troubles with a dynamic generated xsl. Here is the sitemap snippet : And I've got the following stack trace (long... but maybe usefull for info) : Original Exception: org.apache.excalibur.xml.xslt.XSLTProcessorException: Exception in creating Transform Handler at org.apache.excalibur.xml.xslt.XSLTProcessorImpl.getTransformerHandlerAndValidity(XSLTProcessorImpl.java:375) at org.apache.cocoon.transformation.TraxTransformer.setup(TraxTransformer.java:302) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline(AbstractProcessingPipeline.java:391) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.setupPipeline(AbstractCachingProcessingPipeline.java:671) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipeline(AbstractProcessingPipeline.java:505) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:467) at org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:150) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:84) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:164) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:162) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:162) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:325) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:307) at org.apache.cocoon.Cocoon.process(Cocoon.java:626) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1154) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:360) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:558) at org.mortbay.http.HttpContext.handle(HttpContext.java:1714) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:507) at org.mortbay.http.HttpContext.handle(HttpContext.java:1664) at org.mortbay.http.HttpServer.service(HttpServer.java:863) at org.mortbay.http.HttpConnection.service(HttpConnection.java:775) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:939) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:792) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:201) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:289) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:455) Caused by: org.apache.cocoon.ProcessingException: Could not read resource file:/E:/Dev/IKA/DocHelp/webapp-dochelp/resources/workflow.xconf: javax.xml.transform.TransformerException: java.util.EmptyStackException at org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java:151) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:262) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:679) at org.apache.cocoon.components.source.impl.SitemapSource.toSAX(SitemapSource.java:415) at org.apache.excalibur.xml.xslt.XSLTProcessorImpl.sourceToSAX(XSLTProcessorImpl.java:389) at org.apache.excalibur.xml.xslt.XSLTProcessorImpl.getTransformerHandlerAndValidity(XSLTProcessorImpl.java:311) ... 30 more Caused by: javax.xml.transform.TransformerException: java.util.EmptyStackException at org.apache.xalan.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:664) at org.apache.xalan.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:298) at org.apache.xalan.xsltc.trax.TransformerHandlerImpl.endDocument(TransformerHandlerImpl.java:265) at org.apache.cocoon.xml.Abstr
Dynamic XSL generation with "cocoon:" : excalibur Source or cocoonSource bug ?
Hi all, I have some troubles with a dynamic generated xsl. Here is the sitemap snippet : And I've got the following stack trace (long... but maybe usefull for info) : Original Exception: org.apache.excalibur.xml.xslt.XSLTProcessorException: Exception in creating Transform Handler at org.apache.excalibur.xml.xslt.XSLTProcessorImpl.getTransformerHandlerAndValidity(XSLTProcessorImpl.java:375) at org.apache.cocoon.transformation.TraxTransformer.setup(TraxTransformer.java:302) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline(AbstractProcessingPipeline.java:391) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.setupPipeline(AbstractCachingProcessingPipeline.java:671) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipeline(AbstractProcessingPipeline.java:505) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:467) at org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:150) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:84) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:164) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:162) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:162) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:325) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:307) at org.apache.cocoon.Cocoon.process(Cocoon.java:626) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1154) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:360) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:558) at org.mortbay.http.HttpContext.handle(HttpContext.java:1714) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:507) at org.mortbay.http.HttpContext.handle(HttpContext.java:1664) at org.mortbay.http.HttpServer.service(HttpServer.java:863) at org.mortbay.http.HttpConnection.service(HttpConnection.java:775) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:939) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:792) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:201) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:289) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:455) Caused by: org.apache.cocoon.ProcessingException: Could not read resource file:/E:/Dev/IKA/DocHelp/webapp-dochelp/resources/workflow.xconf: javax.xml.transform.TransformerException: java.util.EmptyStackException at org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java:151) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:262) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:679) at org.apache.cocoon.components.source.impl.SitemapSource.toSAX(SitemapSource.java:415) at org.apache.excalibur.xml.xslt.XSLTProcessorImpl.sourceToSAX(XSLTProcessorImpl.java:389) at org.apache.excalibur.xml.xslt.XSLTProcessorImpl.getTransformerHandlerAndValidity(XSLTProcessorImpl.java:311) ... 30 more Caused by: javax.xml.transform.TransformerException: java.util.EmptyStackException at org.apache.xalan.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:664) at org.apache.xalan.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:298) at org.apache.xalan.xsltc.trax.TransformerHandlerImpl.endDocument(TransformerHandlerImpl.java:265) at org.apache.cocoon.xml.AbstractXMLPipe.endDocument(AbstractXMLPipe.java:91) at org.apache.cocoon.transformation.TraxTransformer.endDocument(TraxTransformer.java:529) at org.apache.xerces.parsers.AbstractSAXParser.endDocument(Unknown Source) at org.apache.xerces.impl.XMLDocumentScannerImpl.endEntity(Unknown Source) at org.apache.
in
Hi all ! I've having some trouble with the esql taglib. I read that Antonio Gallardo had also this trouble : http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=103607342313325&w=4 but is this solved ? Is there some cases where It definitly won't work ? Here is the error I met (in french for the style ;)) : java.sql.SQLException: Opération non valide sur un ensemble de résultats de type forward-only : first java.sql.SQLException: Opération non valide sur un ensemble de résultats de type forward-only : first at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134) at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:179) at oracle.jdbc.driver.BaseResultSet.first(BaseResultSet.java:84) at org.apache.cocoon.components.language.markup.xsp.AbstractEsqlQuery.getRowCount(AbstractEsqlQuery.java:204) at org.apache.cocoon.www.resources.resultats_xsp.generate(org.apache.cocoon.www.resources.resultats_xsp:645) at org.apache.cocoon.generation.ServerPagesGenerator.generate(ServerPagesGenerator.java:260) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:531) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:229) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:681) at org.apache.cocoon.components.source.impl.SitemapSource.toSAX(SitemapSource.java:433) at org.apache.cocoon.components.source.SourceUtil.parse(SourceUtil.java:193) at org.apache.cocoon.sitemap.ContentAggregator.generate(ContentAggregator.java:160) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:547) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:229) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:491) at org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:150) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108) at org.apache.cocoon.components.treeprocessor.ContainerNode.invoke(ContainerNode.java:66) at org.apache.cocoon.components.treeprocessor.sitemap.CallNode.invoke(CallNode.java:128) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:84) at org.apache.cocoon.components.treeprocessor.sitemap.ActTypeNode.invoke(ActTypeNode.java:158) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:84) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:164) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:164) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:161) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:325) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:307) at org.apache.cocoon.Cocoon.process(Cocoon.java:621) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1088) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:360) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:558) at org.mortbay.http.HttpContext.handle(HttpContext.java:1714) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:507) at org.mortbay.http.HttpContext.handle(HttpContext.java:1664) at org.mortbay.http.HttpServer.service(HttpServer.java:863) at org.mortbay.http.HttpConnection.service(HttpConnection.java:775) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:939) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:792) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:201) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:289) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:455) I'm just using a select query Thanks in advance -- Olivier BILLARD
Re: Blob protocol... missing BlobSource logger declaration
Sylvain Wallez wrote: Olivier Billard wrote: Hi all ! I'm trying to use the blob protocol. It uses the BlobSourceFactory, defined in the cocoon.xconf. The factory uses BlobSource class, which is AbstractLogEnabled. But where is the logger defined for this component ? The BlobSource isn't defined anywhere ?!? So when I use the blob protocol, BlobSource throws a NullPointerException, because it doesn't find the logger via getLogger(). Any tip ? Fixed : setupLogger(blob) was missing in BlobSourceFactory.getSource(). Thanks for reporting, please cross-check ! Sylvain Good for me ! -- Olivier
Re: [Build failure] : scratchpad
Works fine ! Thank you and have a nice week end ! -- Olivier Carsten Ziegeler wrote: Olivier Billard wrote: Hi all, I got the new fresh Cocoon CVS. I've set "exclude.webapp.samples=true" in my local.build.properties, but the scratchpad-samples target still executes Yes, you're right. Is there something I've missed ? No, the build system is not correct... I just checked in a fix for it, could you please test if it works for you now? Thanks Carsten
[Build failure] : scratchpad
Hi all, I got the new fresh Cocoon CVS. I've set "exclude.webapp.samples=true" in my local.build.properties, but the scratchpad-samples target still executes Is there something I've missed ? Thanks in advance ! -- Olivier BILLARD
Re: Using built-in stylesheets tags in other built-in stylesheets
Thanks Steven, I didn't have to split those templates. It works fine for me... May it come from the xerces version ? -- Olivier Steven Cummings wrote: Just an FYI: I've sometimes gotten a NullPointer exception when trying to where the current node wasn't an element. As a result, I split my "pass-through" templates into two templates: I might have seen this done elsewhere when I first encountered the problem but I don't remember exactly. /S --- Olivier Billard <[EMAIL PROTECTED]> wrote: Hi Adrian, I didn't saw that the missed the ... (damned) Thank a lot ! -- Olivier Billard [EMAIL PROTECTED] wrote: Hi Oliver, For a logicsheet to work properly, you must a) provide a default transformation for elements not handled by your XSL eg. select="@*|*|text()|processing-instruction()"/> and b) you must have a root handler, to kick the whole thing off: Then, all you need to do is call in the spots in your logic where you want the nested logic-tags to be evaluated. HTH /Adrian -Original Message- From: Olivier Billard [mailto:[EMAIL PROTECTED] Sent: Thursday 17 July 2003 17:03 To: [EMAIL PROTECTED] Subject: Re: Using built-in stylesheets tags in other built-in stylesheets Hi Tim, Thanks for your answer. I've tried xsp < esql < mystylesheet and xsp < mystylesheet < esql and none worked... It seems that order in namespace declaration is no longer taken into consideration... Any other idea ? -- Olivier BILLARD Tim Myers wrote: The stylesheets get chained together in a pipeline one after the other. The only issue of one stylesheet using another is order in the pipeline. Your xsp must be transformed by any logicsheet that uses another logicsheet before it is transformed by that other logicsheet. xsp.xsl is the least dependent, most depended logicsheet. esql uses it. Here's the part i'm not sure about: Which ever order they are declared in cocoon.xconf is the order you should declare your logicsheet in: yourlogicsheet > esql > xsp or xsp < esql < yourlogicsheet. There was once a time when processing order was determined by the order the namespaces appear on the root element. I don't think that is any longer the case. Tim On Thu, Jul 17, 2003 at 04:23:38PM +0200, Olivier Billard wrote: Hi all ! I've already asked this question on the users list, but the dev-ers may be more able to answer... :) I would like to know if there is any issue in using tablibs from built-in stylesheets (like esql) in user-custom built-in stylesheets. For me, no Java code is generated... Isn't it possible ? How does Cocoon deal with all these built-in stylesheets ? A global stylesheet with "xsl:import" or "xsl:include" ? Is there a requiered order of declaration in cocoon.xconf to be able to cross-use taglibs ? Thanks in advance ! -- Olivier BILLARD Any e-mail message from the European Central Bank (ECB) is sent in good faith but shall neither be binding nor construed as constituting a commitment by the ECB except where provided for in a written agreement. This e-mail is intended only for the use of the recipient(s) named above. Any unauthorised disclosure, use or dissemination, either in whole or in part, is prohibited. If you have received this e-mail in error, please notify the sender immediately via e-mail and delete this e-mail from your system. __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com -- Olivier BILLARD Société Jouve Tel : 33 2 99 86 93 55 Mail : [EMAIL PROTECTED] Le présent mail ainsi que toutes les informations qu'il contient ne peuvent en aucun cas être considérés comme un engagement juridique de quelque nature que ce soit de JOUVE. Tout accord devra être formulé par écrit papier ultérieur signé par un représentant légal de JOUVE. Par ailleurs, si vous recevez ce mail par erreur, merci de nous le signaler et de le détruire ainsi que l'intégralité du document qui pourrait y être joint. The present email and all information included therein do not constitute a legal agreement accorded by Jouve. All legal agreements must be formulated in writing on paper by a legal representative of JOUVE. If you have received this email by mistake, please inform us of that fact and destroy the email and any documents it might contain. Thank you for your cooperation.
Blob protocol... missing BlobSource logger declaration
Hi all ! I'm trying to use the blob protocol. It uses the BlobSourceFactory, defined in the cocoon.xconf. The factory uses BlobSource class, which is AbstractLogEnabled. But where is the logger defined for this component ? The BlobSource isn't defined anywhere ?!? So when I use the blob protocol, BlobSource throws a NullPointerException, because it doesn't find the logger via getLogger(). Any tip ? -- Olivier BILLARD
Re: Using built-in stylesheets tags in other built-in stylesheets
Hi Adrian, I didn't saw that the missed the ... (damned) Thank a lot ! -- Olivier Billard [EMAIL PROTECTED] wrote: Hi Oliver, For a logicsheet to work properly, you must a) provide a default transformation for elements not handled by your XSL eg. and b) you must have a root handler, to kick the whole thing off: Then, all you need to do is call in the spots in your logic where you want the nested logic-tags to be evaluated. HTH /Adrian -Original Message- From: Olivier Billard [mailto:[EMAIL PROTECTED] Sent: Thursday 17 July 2003 17:03 To: [EMAIL PROTECTED] Subject: Re: Using built-in stylesheets tags in other built-in stylesheets Hi Tim, Thanks for your answer. I've tried xsp < esql < mystylesheet and xsp < mystylesheet < esql and none worked... It seems that order in namespace declaration is no longer taken into consideration... Any other idea ? -- Olivier BILLARD Tim Myers wrote: The stylesheets get chained together in a pipeline one after the other. The only issue of one stylesheet using another is order in the pipeline. Your xsp must be transformed by any logicsheet that uses another logicsheet before it is transformed by that other logicsheet. xsp.xsl is the least dependent, most depended logicsheet. esql uses it. Here's the part i'm not sure about: Which ever order they are declared in cocoon.xconf is the order you should declare your logicsheet in: yourlogicsheet > esql > xsp or xsp < esql < yourlogicsheet. There was once a time when processing order was determined by the order the namespaces appear on the root element. I don't think that is any longer the case. Tim On Thu, Jul 17, 2003 at 04:23:38PM +0200, Olivier Billard wrote: Hi all ! I've already asked this question on the users list, but the dev-ers may be more able to answer... :) I would like to know if there is any issue in using tablibs from built-in stylesheets (like esql) in user-custom built-in stylesheets. For me, no Java code is generated... Isn't it possible ? How does Cocoon deal with all these built-in stylesheets ? A global stylesheet with "xsl:import" or "xsl:include" ? Is there a requiered order of declaration in cocoon.xconf to be able to cross-use taglibs ? Thanks in advance ! -- Olivier BILLARD Any e-mail message from the European Central Bank (ECB) is sent in good faith but shall neither be binding nor construed as constituting a commitment by the ECB except where provided for in a written agreement. This e-mail is intended only for the use of the recipient(s) named above. Any unauthorised disclosure, use or dissemination, either in whole or in part, is prohibited. If you have received this e-mail in error, please notify the sender immediately via e-mail and delete this e-mail from your system.
Re: Using built-in stylesheets tags in other built-in stylesheets
Hi Tim, Thanks for your answer. I've tried xsp < esql < mystylesheet and xsp < mystylesheet < esql and none worked... It seems that order in namespace declaration is no longer taken into consideration... Any other idea ? -- Olivier BILLARD Tim Myers wrote: The stylesheets get chained together in a pipeline one after the other. The only issue of one stylesheet using another is order in the pipeline. Your xsp must be transformed by any logicsheet that uses another logicsheet before it is transformed by that other logicsheet. xsp.xsl is the least dependent, most depended logicsheet. esql uses it. Here's the part i'm not sure about: Which ever order they are declared in cocoon.xconf is the order you should declare your logicsheet in: yourlogicsheet > esql > xsp or xsp < esql < yourlogicsheet. There was once a time when processing order was determined by the order the namespaces appear on the root element. I don't think that is any longer the case. Tim On Thu, Jul 17, 2003 at 04:23:38PM +0200, Olivier Billard wrote: Hi all ! I've already asked this question on the users list, but the dev-ers may be more able to answer... :) I would like to know if there is any issue in using tablibs from built-in stylesheets (like esql) in user-custom built-in stylesheets. For me, no Java code is generated... Isn't it possible ? How does Cocoon deal with all these built-in stylesheets ? A global stylesheet with "xsl:import" or "xsl:include" ? Is there a requiered order of declaration in cocoon.xconf to be able to cross-use taglibs ? Thanks in advance ! -- Olivier BILLARD
Using built-in stylesheets tags in other built-in stylesheets
Hi all ! I've already asked this question on the users list, but the dev-ers may be more able to answer... :) I would like to know if there is any issue in using tablibs from built-in stylesheets (like esql) in user-custom built-in stylesheets. For me, no Java code is generated... Isn't it possible ? How does Cocoon deal with all these built-in stylesheets ? A global stylesheet with "xsl:import" or "xsl:include" ? Is there a requiered order of declaration in cocoon.xconf to be able to cross-use taglibs ? Thanks in advance ! -- Olivier BILLARD
Re: Tomcat 4.1.24 + Cocoon 2.1M3 : yet another endorsed lib issue...
Ok. My issue is still present with the option 2 of your wiki. If it doesn't work with this solution, there is no doubt that it will fail with the ParanoidServlet, no ? Sylvain Wallez wrote: Olivier Billard wrote: Thanks again ! I'll try it. From my previous mail, is there other differences between the paranoid servlet and the "too cool" one ? Absolutely no difference except the "shielding" classloader. Actually, ParanoidCocoonServlet is just a wrapper around any servlet with this special classloader. So it just delegates method calls. Sylvain -- Olivier BILLARD Société Jouve Tel : 33 2 99 86 93 55 Mail : [EMAIL PROTECTED] -- Le présent mail ainsi que toutes les informations qu'il contient ne peuvent en aucun cas être considérés comme un engagement juridique de quelque nature que ce soit de JOUVE. Tout accord devra être formulé par écrit papier ultérieur signé par un représentant légal de JOUVE. Par ailleurs, si vous recevez ce mail par erreur, merci de nous le signaler et de le détruire ainsi que l'intégralité du document qui pourrait y être joint. The present email and all information included therein do not constitute a legal agreement accorded by Jouve. All legal agreements must be formulated in writing on paper by a legal representative of JOUVE. If you have received this email by mistake, please inform us of that fact and destroy the email and any documents it might contain. Thank you for your cooperation. --
Re: Tomcat 4.1.24 + Cocoon 2.1M3 : yet another endorsed lib issue...
Thanks again ! I'll try it. From my previous mail, is there other differences between the paranoid servlet and the "too cool" one ? -- Olivier Sylvain Wallez wrote: Olivier Billard wrote: Thanks for your answer... ... but your wiki says why to use the ParanoidServlet, but not how to use it ... Erhm... edit your web.xml and change the servlet class name from org.apache.cocoon.servlet.CocoonServlet to org.apache.cocoon.servlet.ParanoidCocoonServlet ! It's as easy as that ;-) Is this already in use with a cocoon older than 6th June ? No, because the code before this date was buggy. But you can extract ParanoidCocoonServlet and ParanoidClassLoader from after june 6th and put it in an older Cocoon (of course removing the old classes). Sylvain
Re: Tomcat 4.1.24 + Cocoon 2.1M3 : yet another endorsed lib issue...
Thanks Joerg, In fact, I just tested with my own local tomcat and it works... Seems like the admin is gonna hear from me ;) Is the paranoid different from the "hippie" one just from that classloader order, or is there any other differences ? -- Olivier Billard Joerg Heinicke wrote: Besides the ParanoidCocoonServlet option 2 should work (copying endorsed jars to $TOMCAT/common/endorsed (I have the same Tomcat version in use and working). Joerg Olivier Billard wrote: Hi all, Could you tell me what is the current receipe to get Cocoon M3 work with Tomcat 4.1.24 ? - Copy JARs from lib/endorsed to JDK endorsed folder (didn't try - copy endorsed jars to $TOMCAT/common/endorsed (doesn't work for me) - leave $TOMCAT/common/endorsed empty (doesn't work for me) Wikies only tell about older tomcat versions... Thanks in advance !
Re: Tomcat 4.1.24 + Cocoon 2.1M3 : yet another endorsed lib issue...
Sorry, I meant younger than... Olivier Billard wrote: Thanks for your answer... ... but your wiki says why to use the ParanoidServlet, but not how to use it ... Is this already in use with a cocoon older than 6th June ? Sylvain Wallez wrote: Olivier Billard wrote: Hi all, Could you tell me what is the current receipe to get Cocoon M3 work with Tomcat 4.1.24 ? - Copy JARs from lib/endorsed to JDK endorsed folder (didn't try - copy endorsed jars to $TOMCAT/common/endorsed (doesn't work for me) - leave $TOMCAT/common/endorsed empty (doesn't work for me) Wikies only tell about older tomcat versions... Thanks in advance ! Use the ParanoidCocoonServlet, and your endorsed lib problems should vanish instantly ;-) http://wiki.cocoondev.org/Wiki.jsp?page=EndorsedLibsProblem Cheers, Sylvain -- Olivier BILLARD Société Jouve Tel : 33 2 99 86 93 55 Mail : [EMAIL PROTECTED] -- Le présent mail ainsi que toutes les informations qu'il contient ne peuvent en aucun cas être considérés comme un engagement juridique de quelque nature que ce soit de JOUVE. Tout accord devra être formulé par écrit papier ultérieur signé par un représentant légal de JOUVE. Par ailleurs, si vous recevez ce mail par erreur, merci de nous le signaler et de le détruire ainsi que l'intégralité du document qui pourrait y être joint. The present email and all information included therein do not constitute a legal agreement accorded by Jouve. All legal agreements must be formulated in writing on paper by a legal representative of JOUVE. If you have received this email by mistake, please inform us of that fact and destroy the email and any documents it might contain. Thank you for your cooperation. --
Re: Tomcat 4.1.24 + Cocoon 2.1M3 : yet another endorsed lib issue...
Thanks for your answer... ... but your wiki says why to use the ParanoidServlet, but not how to use it ... Is this already in use with a cocoon older than 6th June ? Sylvain Wallez wrote: Olivier Billard wrote: Hi all, Could you tell me what is the current receipe to get Cocoon M3 work with Tomcat 4.1.24 ? - Copy JARs from lib/endorsed to JDK endorsed folder (didn't try - copy endorsed jars to $TOMCAT/common/endorsed (doesn't work for me) - leave $TOMCAT/common/endorsed empty (doesn't work for me) Wikies only tell about older tomcat versions... Thanks in advance ! Use the ParanoidCocoonServlet, and your endorsed lib problems should vanish instantly ;-) http://wiki.cocoondev.org/Wiki.jsp?page=EndorsedLibsProblem Cheers, Sylvain -- Olivier BILLARD Société Jouve Tel : 33 2 99 86 93 55 Mail : [EMAIL PROTECTED] -- Le présent mail ainsi que toutes les informations qu'il contient ne peuvent en aucun cas être considérés comme un engagement juridique de quelque nature que ce soit de JOUVE. Tout accord devra être formulé par écrit papier ultérieur signé par un représentant légal de JOUVE. Par ailleurs, si vous recevez ce mail par erreur, merci de nous le signaler et de le détruire ainsi que l'intégralité du document qui pourrait y être joint. The present email and all information included therein do not constitute a legal agreement accorded by Jouve. All legal agreements must be formulated in writing on paper by a legal representative of JOUVE. If you have received this email by mistake, please inform us of that fact and destroy the email and any documents it might contain. Thank you for your cooperation. --
Tomcat 4.1.24 + Cocoon 2.1M3 : yet another endorsed lib issue...
Hi all, Could you tell me what is the current receipe to get Cocoon M3 work with Tomcat 4.1.24 ? - Copy JARs from lib/endorsed to JDK endorsed folder (didn't try - copy endorsed jars to $TOMCAT/common/endorsed (doesn't work for me) - leave $TOMCAT/common/endorsed empty (doesn't work for me) Wikies only tell about older tomcat versions... Thanks in advance ! -- Olivier BILLARD Société Jouve
Re: Use of generated stylesheets
Done. Tell me if it is correct, or if I must add complementary info... -- Olivier Upayavira wrote: Oliver, I always assumed that the Wiki page that I referred you to used the cocoon: protocol. I see now that it doesn't. If you've got it working with the cocoon: protocol, would you be willing to update the Wiki page? 'Cos that's what that Wiki page _should_ say (I mean, do you really want to expose your stylesheets to the public, which you're doing if you use HTTP?!?!? ) Regards, Upayavira On 1 Jul 2003 at 17:41, Olivier Billard wrote: Thanks (again :) !) Sylvain ! It seems that you're right... The effect is still not what I meant, but now the cocoon: works... -- Olivier Sylvain Wallez wrote: Olivier Billard wrote: Hi all ! I posted my question on "Users", but it seems more appropriate to ask it here. I want to use a generated stylesheet with an XSL transformer, using the cocoon protocol. But I get this error : org.apache.cocoon.ProcessingException: Unable to get transformer handler for cocoon://picto-filter.xsl: org.apache.excalibur.xml.xslt.XSLTProcessorException: Exception in creating Transform Handler This exception often occurs when the stylesheet is not correct. You should have more details about what goes wrong either in some chained exception, or in the log files (Xalan often logs the error before raising the exception). Sylvain
