Re: Simple XSL question
xsl:import and xsl:include are your friends when you start getting concerned about performance issues and want to do everything in one pass! Of course though, if you generate one form of content, and then transform it to another form of content (say, xml-docbook-html) you are SOL. :( Simone, Just for the record, I went on using this template. xsl:template match=@* | node() xsl:copy xsl:apply-templates select=@* | node()/ /xsl:copy /xsl:template I still wonder if it is not a bad design to generate a base xml at the begining of the pipeline, aggregate other generated xml data and then go into a number of transformations for each specific section of the base xml, transforming them with the other generated data, and copying all the unused data, in each transformation, for the rest of the pipeline, basically in terms of performance. By now, that's what I'm doing. Thanks, -Mensaje original- De: Simone Gianni [mailto:[EMAIL PROTECTED]] Enviado el: lunes, 28 de enero de 2002 12:50 Para: [EMAIL PROTECTED] Asunto: Re: Simple XSL question At 12.37 28/01/2002 -0300, you wrote: Hello, How can I make a XSLT transformation of just a couple of elements, leaving the rest untouched, without having to select everything and passing it through? You can create a catch all template with lower priority, for example : xsl:template match=something dosomething/do /xsl:template xsl:template match=*|node() priority=-10 xsl:copy-of select=./ /xsl:template This means that if something is found, it will be processed by the first template, if else is found it will be processed by the second template, which does a copy. The lower priority is an optional, since the XSLT processor should use the first template since it's more specific, but I've had some strange results, and forcing it is a good idea. I'm not sure about the xsl:copy-of .. ... it could cause some duplications, you could try a xsl:copy/ and see which one works better ... Ciao - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP-Generator-problem
One other thing...
I found that in order to get my JSPs working, I had to put a / at the
beginning of the src attribute.
For instance,
map:generate type=jsp src=jsp/{1}.jsp/
would have to become:
map:generate type=jsp src=/jsp/{1}.jsp/
in order to work for me. I only ever experienced this problem with JSP
files.
Bryan
I see. From your email:
map:match pattern=jsp/*
map:generate type=jsp src=bancotec/floxco/src/jsp/{1}.jsp/
map:transform src=stylesheets/page/simple-page2html.xsl/
map:serialize type=html/
/map:match
The Code is in
TOMCAT_HOME/webapps/cocoon/bancotec/floxco/src/View/menue.jsp
JSP files must be in the directory:
TOMCAT_HOME/webapps/cocoon/bancotec/floxco/src/jsp/
Sorry for missing that from the beginning.
Vadim
-Original Message-
From: Bucholdt, Christian [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 30, 2002 12:02 PM
To: '[EMAIL PROTECTED]'
Subject: AW: JSP-Generator-problem
Hi,
It's not the jsp:include ... Tag a problem. The same error is
without this
Tag.
Only the hello.jsp in cocoon/docs/samples/jsp/-Directory works fine.
It's perhaps a Directory-Problem?
gruss
christian
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: XSLTransformer questions!
shenoy, nitin wrote: Q1) How do I pass the result of XSL transformations to an Action? map:match pattern=ProcessOrder map:generate type=file src=input/message.xml/ map:transform src=input/identity.xsl/ map:act type=load-order / map:serialize/ /map:match In the above scenario, I want to be able to pass the result of transformation by identity.xsl to load-order action! Is that possible and if yes how? I think you have things mixed up a bit conceptually. Actions are pieces of code that are tied to the pipeline, not the XML document. You use an Action to modify the pipeline, not the XML stream. If you want to modify the XML stream, you have to create a Transformer. Q2) How do I handle a scenario where every xsl:for-each should fire an action inside a sitemap? I guess a related question also is whether Sitemap has any construct for loops? Please do help. Regards, Nitin Same thing, you need to write a Transformer (or a logic sheet). Your code can then perform any arbitrary code on the XML stream. If you need to modify the pipeline based on the results of your transformer code, you should can set some session variables and write a Selector and/or Action to tweak the pipeline based on those session variables. Bryan - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
question about failed actions
Let's use this as an example of a possible action: map:act name=session-validate .. do something .. /map:act Now, what do you do if you want to action fails, yet you still want to modify the pipeline based on that failed action? Well, of course, you could always write the action as a selector. But what if you want to reuse some code already written as an action? You could of course write a wrapper selector, but I don't see why that should be necessary. Why not something along these lines:: map:act name=session-validate map:act-successful .. do something .. /map:act-success map:act-failure .. do something else .. /map:act-failure /map:act Is there a good reason for not doing things this way that I am missing (or maybe a way of doing this that I have yet to discover)? I would assume you could do something similar for action sets. Thanks! Bryan - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Purpose of XSP
That's more or less how I view it. I tend to explain XSPs like this: XSPs are an EASIER way of creating functionality like Java Tag Libraries. Rather than exposing functionality through a set of difficult to use and very limited Java APIs, you program your logic into a more natural and more flexible Stylesheet representation. :) Bryan All, I have been trying to determine the purpose of XSP. I understand that the purpose of Cocoon is to provide a better way to separate content, logic, and presentation via XSL. However, the examples I have seen using XSP reveal that the content, logic, and presentation have not been separated but remain coupled together as they do in JSP. However, today I had a revelation! XSPs should not contain any presentation at all. They should only be used to transform content, specifically dynamic content. For example, suppose I want to present a list of products to a buyer. In JSP I would write a scriplet or tag that would transform the content for presentation to the buyer. I would then embed the scriplet or tag into a JSP page, which represented the presentation of the page. The problem here is that the scriplet or tag contains presentation logic that can not be separated out. For instance, if I used an HTML table the scriplet or tag might contain row and column tags or could produce the entire table. In Cocoon the step of embedding the logic (scriplet or tag) used to transform the content is not required. The XSP would simply transform the content into more content that would later be transformed into presentation via XSLT. Forgive me for being Captain Obvious here but it this the intent of XSP? Samer - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problems with XSP files and Cocoon 2.0 Release
Hey guys, Is there a reason why changes to XSP files aren't picked up when I have the application set to reloadable and pass the ?cocoon-reload=1 parameter to a page request? Changes to JSP, XML, and sitemap files are caught, but if I change an XSP file I get this error: WARN(2001-12-02) 06:04.05:941 [cocoon ] (/dev/main3) Thread-34/ServerPagesGenerator: ServerPagesGenerat or.generate() java.lang.IllegalStateException: You cannot select a Component from a disposed ComponentSelector at org.apache.avalon.excalibur.component.ExcaliburComponentSelector.select(Unknown Source) at org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java :208) at org.apache.cocoon.generation.ServerPagesGenerator.setup(ServerPagesGenerator.java:170) at org.apache.cocoon.components.pipeline.AbstractEventPipeline.setupPipeline(AbstractEventPipeline.jav a:142) at org.apache.cocoon.components.pipeline.CachingEventPipeline.setup(CachingEventPipeline.java:239) at org.apache.cocoon.components.pipeline.CachingEventPipeline.generateKey(CachingEventPipeline.java:99 ) at org.apache.cocoon.components.pipeline.CachingStreamPipeline.process(CachingStreamPipeline.java:277) at org.apache.cocoon.www.sitemap_xmap.wildcardMatchN400239(sitemap_xmap.java:2705) at org.apache.cocoon.www.sitemap_xmap.process(sitemap_xmap.java:2041) at org.apache.cocoon.www.sitemap_xmap.process(sitemap_xmap.java:1923) at org.apache.cocoon.sitemap.Handler.process(Handler.java:163) at org.apache.cocoon.sitemap.Manager.invoke(Manager.java:114) at org.apache.cocoon.Cocoon.process(Cocoon.java:514) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:647) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java) at org.apache.catalina.connector.warp.WarpRequestHandler.handle(WarpRequestHandler.java) at org.apache.catalina.connector.warp.WarpConnection.run(WarpConnection.java) at java.lang.Thread.run(Thread.java:484) So basically, any time I change an XSP file I have to restart Tomcat (even if I change the file back to it's original configuration Cocoon remains further broken with this current URL). I seem to have problems adding XSP files to the sitemap as well without restarting Tomcat. As I said above, I do not experience these problems when using JSPs or XML files. FYI: here is our configuration: Linux Mandrake 8.1 Tomcat 4.0.1 + Apache 1.3.19 via mod_webapp Cocoon 2.0 Release Binary Nothing else special about the configuration at all. Thanks! Bryan - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Internal server error
Comment out every entry in your sitemap.xmap file that contains 'svg' minus the quotes. sitemap.xmap is located in the webapps/cocoon directory. You might have to uncompress the war archive to modify it. Restart tomcat, and everything should work EXCEPT for the svg stuff. If you want to use the svg stuff, you're out of luck till somebody fixes that problem. Rajkumar, Joseph wrote: Hi Folks I am using latest Cocoon-2.0b1 with Tomcat-3.2.2 and following the instructions to the letter and this is what I get Regards Joseph Rajkumar Instructions followed: http://xml.apache.org/cocoon2/install.html PS: why is the sitemap hander's sitemap *NOT* available and how can I make it available == Cocoon 2 - Internal server error type internal-server-error message The sitemap handler's sitemap is not available. description org.apache.cocoon.ProcessingException: The sitemap handler's sitemap is not available. sender org.apache.cocoon.servlet.CocoonServlet source Cocoon servlet request-uri /cocoon/ exception org.apache.cocoon.ProcessingException: The sitemap handler's sitemap is not available. path-info stacktrace org.apache.cocoon.ProcessingException: The sitemap handler's sitemap is not available. at org.apache.cocoon.sitemap.Manager.setupProcessing(Manager.java:179) at org.apache.cocoon.sitemap.Manager.invoke(Manager.java:93) at org.apache.cocoon.Cocoon.process(Cocoon.java:293) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:471) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:405) at org.apache.tomcat.core.Handler.service(Handler.java:287) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:213) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501) at java.lang.Thread.run(Thread.java:484) Cocoon 2 - Internal server error *type* internal-server-error *message*_The sitemap handler's sitemap is not available._ *description*_org.apache.cocoon.ProcessingException: The sitemap handler's sitemap is not available._ *sender* org.apache.cocoon.servlet.CocoonServlet *source* Cocoon servlet *request-uri* /cocoon/ *exception* org.apache.cocoon.ProcessingException: The sitemap handler's sitemap is not available. *path-info* *stacktrace* org.apache.cocoon.ProcessingException: The sitemap handler's sitemap is not available. at org.apache.cocoon.sitemap.Manager.setupProcessing(Manager.java:179) at org.apache.cocoon.sitemap.Manager.invoke(Manager.java:93) at org.apache.cocoon.Cocoon.process(Cocoon.java:293) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:471) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:405) at org.apache.tomcat.core.Handler.service(Handler.java:287) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:213) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501) at java.lang.Thread.run(Thread.java:484) - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [c2] problem with latest cvs
BINGO! I've been struggling with this for awhile now myself. I was using Tomcat 3.3dev for a bit, and all the log files are completely different in that version, so I wasn't sure where to look. Anyway, I downgraded to 3.2.2 yesterday and spent some real time looking into the problem. If you look in webapps/cocoon/WEB-INF/logs/cocoon.log you'll see an Exception complaining about an undefined method for an SVG object. I modified my sitemap.xmap file, commenting out all entries relating to svg, restarted Tomcat and cocoon is working again. I'm not sure what's actually causing the problem yet, but at least doing this will let you guys toy around with the other Cocoon2 stuff. Bryan Hi, I get same exception with the newest C2 version. org.apache.cocoon.ProcessingException: The sitemap handler's sitemap is not available. I use Jetty 3.0.6 with the latest C2 cvs version (01.06.2001) The problem is that the sitemap will never compile. In the log files I get the following error message: 12:06:47.942 EVENT Cocoon2: init 12:06:48.007 EVENT DEBUG 17 [cocoon ] (SocketListener-0): Trying to load class: com.ibm.servlet.classloader.Handler + 12:06:48.046 EVENT WARN54 [cocoon ] (SocketListener-0): Could not force-load class: com.ibm.servlet.classloader.Handl er + java.lang.ClassNotFoundException: com.ibm.servlet.classloader.Handler + at java.net.URLClassLoader$1.run(URLClassLoader.java:200) + at java.security.AccessController.doPrivileged(Native Method) + at java.net.URLClassLoader.findClass(URLClassLoader.java:188) + at java.lang.ClassLoader.loadClass(ClassLoader.java:297) + at java.lang.ClassLoader.loadClass(ClassLoader.java:253) + at org.apache.cocoon.util.ClassUtils.loadClass(ClassUtils.java:46) + at org.apache.cocoon.servlet.CocoonServlet.forceLoad(CocoonServlet.java:399) + at org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:119) + at com.mortbay.HTTP.Handler.Servlet.ServletHolder.handle(ServletHolder.java:427 ) + at com.mortbay.HTTP.Handler.Servlet.ServletHandler.handle(ServletHandler.java:4 30) + at com.mortbay.HTTP.Handler.Servlet.ServletHandler.handle(ServletHandler.java:2 86) + at com.mortbay.HTTP.HandlerContext.handle(HandlerContext.java:1087) + at com.mortbay.HTTP.HttpServer.service(HttpServer.java:662) + at com.mortbay.HTTP.HttpConnection.service(HttpConnection.java:457) + at com.mortbay.HTTP.HttpConnection.handle(HttpConnection.java:317) + at com.mortbay.HTTP.SocketListener.handleConnection(SocketListener.java:99) + at com.mortbay.Util.ThreadedServer.handle(ThreadedServer.java:254) + at com.mortbay.Util.ThreadPool$PoolThreadRunnable.run(ThreadPool.java:601) + at java.lang.Thread.run(Thread.java:484) - Original Message - From: Donald Ball [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, May 31, 2001 8:48 PM Subject: [c2] problem with latest cvs heya. i just installed a fresh cvs copy of c2 on a fresh jakarta-tomcat-4.0b5 installation on fresh server. when i first request the cocoon home page, i get the infamous confusing exception: ERROR 6991[cocoon ] (HttpProcessor[8080][4]): Problem with servlet org.apache.cocoon.ProcessingException: The sitemap handler's sitemap is not available. at org.apache.cocoon.sitemap.Manager.setupProcessing(Manager.java:179) at org.apache.cocoon.sitemap.Manager.invoke(Manager.java:93) at org.apache.cocoon.Cocoon.process(Cocoon.java:293) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:471) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) however, after the sitemap finishes compiling, i can get in just fine. this didn't used to happen. what's up, any idea? - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
