JSP generator and Websphere 6
Hi, Does anyone know how to call the JSP engine in Websphere 6? In 5.0 5.1 I've been using the JSPEngineImplNamedDispatcherInclude JSPEngine implementation to look up the JSP 1.2 Processor servlet. However, in Websphere 6 the JSP engine is no longer a servlet, it's a container extension processor, so changing the configuration to look up JSP 2.0 Processor instead doesn't work. Is it possible to access the new mechanism using one of the existing JSPEngine implementation classes? If not, how would I go about calling it myself from a new custom implementation? Andrew. _ The next generation of MSN Hotmail has arrived - Windows Live Hotmail http://www.newhotmail.co.uk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: XML serializer returns wrong mime-type with JSP Generator
Thank you, I've worked around the problem by dynamically setting the mime-type within the source JSP's. Wouter -Oorspronkelijk bericht- Van: Joerg Heinicke [mailto:[EMAIL PROTECTED] Verzonden: woensdag 23 juni 2004 23:31 Aan: [EMAIL PROTECTED] Onderwerp: Re: XML serializer returns wrong mime-type with JSP Generator On 23.06.2004 18:00, Wouter Westendorp wrote: This works fine, except for the returned mime-type. Instead of returning the 'text/xml' mime-type (as expected by the XML serializer that does have the 'mime-type=text/xml' attribute), Cocoon returns a 'text/html' mime-type. I think this 'text/html' mime-type comes from the JSP Generator, although I'm not for sure. Does anybody know how I can overwrite the returned mime-type within Cocoon? Unfortunately this is a known bug in Cocoon's JSP handling: http://issues.apache.org/bugzilla/show_bug.cgi?id=27957. But I saw you already voted for the bug, so I guess you found it yourself :) Just added the answer for the archive. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
XML serializer returns wrong mime-type with JSP Generator
Hi all,
I use the following sitemap fragment to retrieve xml formatted contents
from a JSP page, transform it and return it to the client as XML:
map:match pattern=**.ext
map:generate type=jsp src={1}.jsp/
map:transform src=stylesheets/page2ext.xslt
map:parameter name=contextPath
value={request:contextPath}/
map:parameter name=use-request-parameters value=true/
/map:transform
map:serialize type=xml/
/map:match
This works fine, except for the returned mime-type. Instead of returning
the 'text/xml' mime-type (as expected by the XML serializer that does
have the 'mime-type=text/xml' attribute), Cocoon returns a 'text/html'
mime-type.
I think this 'text/html' mime-type comes from the JSP Generator,
although I'm not for sure. Does anybody know how I can overwrite the
returned mime-type within Cocoon?
Thanking you in advance,
Wouter Westendorp
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML serializer returns wrong mime-type with JSP Generator
On 23.06.2004 18:00, Wouter Westendorp wrote: This works fine, except for the returned mime-type. Instead of returning the 'text/xml' mime-type (as expected by the XML serializer that does have the 'mime-type=text/xml' attribute), Cocoon returns a 'text/html' mime-type. I think this 'text/html' mime-type comes from the JSP Generator, although I'm not for sure. Does anybody know how I can overwrite the returned mime-type within Cocoon? Unfortunately this is a known bug in Cocoon's JSP handling: http://issues.apache.org/bugzilla/show_bug.cgi?id=27957. But I saw you already voted for the bug, so I guess you found it yourself :) Just added the answer for the archive. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE : JSP Generator question, once again
On 03.05.2004 09:35, zze-e-photo FRAS E ext FTRD/DMI/REN wrote: After more investigation, the use case is the following : To improve performance in Tomcat, it is possible to disable the checking system for JSP file modification. I would like to do exactly the same with the JSPGenerator (and also the JSPReader) in Cocoon. So, I don't know if I really need to cache the result of the generator or if there is better way to just avoid Cocoon checking if the JSP file has been changed. Cocoon's caching caches the *result* of the generator, so Jasper is not asked at all for new content if the cache is still valid. What I suggested (using NOPValidity) is so probably the wrong way, as the result of the first access would be always valid and used. Something like a check for file modification is not applicable for the JSPGenerator as it only resolves the path to the JSP file and gives this path to Jasper. I guess then Tomcat's check for file modification comes into play - or not if deactivated. So it should just work as it is. It seems that Tomcat configuration about check for file modification is ignored by Jasper but I guess this is normal. The JSP Generator uses the JSPEngineImpl to compile the jsp and this engine calls the Jasper servlet in its own context (servlet.init() and servlet.service()). What I tried to do is to have my own JSPEngineImpl calling the Jasper Servlet and make the servlet initialisation with my own JSPEngineServletConfig to add parameters recognized by the servlet (development = false and reloading=false). Unfortunately, that did not work and I don't understand why. Eddy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE : JSP Generator question, once again
On 06.05.2004 09:30, zze-e-photo FRAS E ext FTRD/DMI/REN wrote: It seems that Tomcat configuration about check for file modification is ignored by Jasper but I guess this is normal. The JSP Generator uses the JSPEngineImpl to compile the jsp and this engine calls the Jasper servlet in its own context (servlet.init() and servlet.service()). What I tried to do is to have my own JSPEngineImpl calling the Jasper Servlet and make the servlet initialisation with my own JSPEngineServletConfig to add parameters recognized by the servlet (development = false and reloading=false). Unfortunately, that did not work and I don't understand why. Unfortunately that's out of my space ... here I can't help anymore. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP Generator question, once again
On 03.05.2004 09:35, zze-e-photo FRAS E ext FTRD/DMI/REN wrote: After more investigation, the use case is the following : To improve performance in Tomcat, it is possible to disable the checking system for JSP file modification. I would like to do exactly the same with the JSPGenerator (and also the JSPReader) in Cocoon. So, I don't know if I really need to cache the result of the generator or if there is better way to just avoid Cocoon checking if the JSP file has been changed. Cocoon's caching caches the *result* of the generator, so Jasper is not asked at all for new content if the cache is still valid. What I suggested (using NOPValidity) is so probably the wrong way, as the result of the first access would be always valid and used. Something like a check for file modification is not applicable for the JSPGenerator as it only resolves the path to the JSP file and gives this path to Jasper. I guess then Tomcat's check for file modification comes into play - or not if deactivated. So it should just work as it is. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Question about JSP generator
Title: Question about JSP generator Hi, As far as I understand, the JSPGenerator calls the Jasper JSPServlet to compile a JSP file. The Jasper servlet has some init parameters that I would like to set when used inside Cocoon. Is it possible to set these parameters in the web.xml file of the webapp ? Thanks, Eddy
JSP Generator question, once again
Title: JSP Generator question, once again Hi, Is it possible to avoid a JSP page to be reloaded and recompiled using the JSPGenerator in Cocoon when the file has been changed on filesystem ? Don't you mean until the file has been changed on filesystem? No, I'd like to completely avoid having the JSPGenerator checking if the jsp file has changed. So, even if the file has been changed on filesystem, I would like to have the jsp not recompiled. Hmm, ok, but what exactly is the use case? After more investigation, the use case is the following : To improve performance in Tomcat, it is possible to disable the checking system for JSP file modification. I would like to do exactly the same with the JSPGenerator (and also the JSPReader) in Cocoon. So, I don't know if I really need to cache the result of the generator or if there is better way to just avoid Cocoon checking if the JSP file has been changed. Thanks, Eddy So I could write my own JSPGenerator, just adding the CacheableProcessingComponent interface implementation and that would be enough ? Yes, just extend the existing one. But unlike the FileGenerator in getValidity() you must not return the validity of the inputsource (which is normally the lastmodified value), but the always valid validity: http://cvs.apache.org/viewcvs.cgi/avalon-excalibur/sourceresolve/src/java/org/apache/excalibur/source/impl/validity/NOPValidity.java
JSP Generator question
Hi, Is it possible to avoid a JSP page to be reloaded and recompiled using the JSPGenerator in Cocoon when the file has been changed on filesystem ? The Tomcat settings seem to be ignored but perhaps it is normal because the JSPEngine object is created by Cocoon. Any ideas ? Thanks a lot, Eddy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP Generator question
On 29.04.2004 19:50, Eddy Fras wrote: Is it possible to avoid a JSP page to be reloaded and recompiled using the JSPGenerator in Cocoon when the file has been changed on filesystem ? Don't you mean until the file has been changed on filesystem? The Tomcat settings seem to be ignored but perhaps it is normal because the JSPEngine object is created by Cocoon. Any ideas ? Both the JSPGenerator and JSPReader could implement CacheableProcessingComponent, what they don't do at the moment. It would be the same as in the FileGenerator. Is it what you want? Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP Generator question
On 29.04.2004 19:50, Eddy Fras wrote: Is it possible to avoid a JSP page to be reloaded and recompiled using the JSPGenerator in Cocoon when the file has been changed on filesystem ? Don't you mean until the file has been changed on filesystem? No, I'd like to completely avoid having the JSPGenerator checking if the jsp file has changed. So, even if the file has been changed on filesystem, I would like to have the jsp not recompiled. The Tomcat settings seem to be ignored but perhaps it is normal because the JSPEngine object is created by Cocoon. Any ideas ? Both the JSPGenerator and JSPReader could implement CacheableProcessingComponent, what they don't do at the moment. It would be the same as in the FileGenerator. So I could write my own JSPGenerator, just adding the CacheableProcessingComponent interface implementation and that would be enough ? Thanks Joerg, Eddy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP Generator question
On 29.04.2004 21:29, Eddy Fras wrote: Is it possible to avoid a JSP page to be reloaded and recompiled using the JSPGenerator in Cocoon when the file has been changed on filesystem ? Don't you mean until the file has been changed on filesystem? No, I'd like to completely avoid having the JSPGenerator checking if the jsp file has changed. So, even if the file has been changed on filesystem, I would like to have the jsp not recompiled. Hmm, ok, but what exactly is the use case? So I could write my own JSPGenerator, just adding the CacheableProcessingComponent interface implementation and that would be enough ? Yes, just extend the existing one. But unlike the FileGenerator in getValidity() you must not return the validity of the inputsource (which is normally the lastmodified value), but the always valid validity: http://cvs.apache.org/viewcvs.cgi/avalon-excalibur/sourceresolve/src/java/org/apache/excalibur/source/impl/validity/NOPValidity.java Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP Generator question
On 29.04.2004 21:29, Eddy Fras wrote: Is it possible to avoid a JSP page to be reloaded and recompiled using the JSPGenerator in Cocoon when the file has been changed on filesystem ? Don't you mean until the file has been changed on filesystem? No, I'd like to completely avoid having the JSPGenerator checking if the jsp file has changed. So, even if the file has been changed on filesystem, I would like to have the jsp not recompiled. Hmm, ok, but what exactly is the use case? I realize it is quite strange but it is in a performance test environment and we don't want to take jsp file modifications into account. So I could write my own JSPGenerator, just adding the CacheableProcessingComponent interface implementation and that would be enough ? Yes, just extend the existing one. But unlike the FileGenerator in getValidity() you must not return the validity of the inputsource (which is normally the lastmodified value), but the always valid validity: http://cvs.apache.org/viewcvs.cgi/avalon-excalibur/sourceresolve/src/java/org/apache/excalibur/source/impl/validity/NOPValidity.java I'll try that, thanks a lot, Eddy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: + Jsp Generator +
The stacktrace below points to an error in your JSP, so that's not a problem
with Cocoon or the JSPGenerator, but with your JSP or Jasper.
Another problem and really a problem of Cocoon is the usage of jsp:include
or jsp:forward, which both don't work. For more information please read at
http://marc.theaimsgroup.com/?t=10596731923r=1w=2.
If you don't have an existing JSP site I can only suggest you not to use
JSP, but e.g. XSP or another Cocoon technic.
Joerg
pagop Serge wrote:
Hi all,
+ first I like to know if cocoon 2.0.4 support all tags of jsp
(jsp:include and the jsp:forward),
because I like to generate PDF-File of jsp-site and I do not know
how can really do that :
problem Explain:
1) the jsp-site takes data in the database
2) what I want to do is to generate a XML-File for this JSP-Site
and then with this XML-File I generate a corresponding PDF-File
When someboby have any ideas please mail
I try something but with some misapprehensions. I use this
map-Definition to have a xml document of my jsp:
!-- for the transformation of jsp-site to xml-site --
!-- Use this to debug your JSPs --
map:match pattern=*.xml
map:generate type=jsp src={1}.jsp/
map:serialize type=xml/
/map:match
But the xml-Document is not save localy, for this reason I don' t
have any ideas how I can do to solve this task
+ second, wenn I do something like this:
It works without problems
para
%
String s[]={
Sisi,
Emiel,
Emmanuel
};
for(int i = 0; i s.length; i++){
%
%= s[i] %br/
%
}
%
/para
but this other version with java.util.Vector doesn' t work and I do not
understand why
para
%
java.util.Vector buffer = new java.util.Vector();
buffer.addElement(Serge);
Enumeration iter = buffer.elements();
while(iter.hasMoreElements()){
String s = (String)nextElement();
%
%= s %br/
%
}
%
/para
and then I receive some errors:
Cocoon stack-trace
---
uninteresting part of stacktrace snipped
and compiled failed:
---
Compile failed; see the compiler error output for details.
at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:844)
at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:682)
at
org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:317)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:370)
at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:473)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:190)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.cocoon.components.jsp.JSPEngineImpl.executeJSP(JSPEngineImpl.java:122)
--
System Development
VIRBUS AG
Fon +49(0)341-979-7419
Fax +49(0)341-979-7409
[EMAIL PROTECTED]
www.virbus.de
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
