Jasper 4.1.24 tag
Did jasper get a 4.1.24 tag when tomcat 4.1.24 got released, as I can see all the other 4.1.x tags but .24 Thanks, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs
Remy, I think it would be nice to have a pre-compilier like JspC used to be. The precompile part of the jsp spec is just not that handy when trying to do builds and having ant tasks pass or fail based on the jsp and compiling jsp pages into servelts is not an option for everyone. John -Original Message- From: Chris Brown [mailto:[EMAIL PROTECTED] Sent: Friday, March 21, 2003 6:43 AM To: Tomcat Developers List Subject: Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs Hi Remy, It might be worth COPYING the original web.xml at deployment time, to make a runtime-web.xml, to do what you propose, leaving the original web.xml untouched. This way, you can add the declarations for compiled JSPs, and -- as a bonus -- allow clean modification of things like init-params for servlets, filters, and the context itself. Such modifications could be done in the admin webapp. If the application is redeployed, or at least if web.xml is modified, then a new copy of web.xml can be made, merging in the modifications made to the older (now obsolete) copy, and of course, the declarations for the compiled JSPs. I'm all for deploying applications as simply as possible, letting end-users customise things from nice graphical interfaces without touching configuration files directly. Many less experienced individuals screw up web.xml when attempting to modify stuff, and it implies unpacking WARs, and looking through lots of confusing application structure (where's web.xml? what's xml anyway? why doesn't tomcat start now that I've typed an apostrophie in the servlet's init-param...?) - Chris - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, March 21, 2003 12:05 PM Subject: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs Hi, It is not very convinient or easy to insert the declarations for compiled JSPs into the webapp's web.xml file. It also has the disadvantage of adding a lot of mess in the web.xml, which the user may not like. For that reason, I propose that Tomcat parses a new (optional) XML file, with the same DTD as web.xml, which would contain declarations identical to web.xml, and which would be used for declaring the compiled JSPs. I propose naming that file compiledjsp.xml. An additional advantage is that it would allow Tomcat to precompile webapps as they are deployed (otherwise, nasty XML manipulation is needed to do that, and I think overwriting the originial web.xml during deployment is bad). Maybe someone has a better solution for this problem. Any comments ? Remy - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JSP Tag spec question
I have a bodytag that extends BodyTagSupport If I call that tag without a body the doAfterBody() method never gets invoked. ie tag:test attr1=1/ does not work but tag:test attr1=1!-- some comment here --/tag:test does work tag:test attr1=1/tag:test does not work tag:test attr1=1 /tag:test does work (note the space between the tags) I tried to see what the spec says about this and from reading it I think this is not working correctly. Please let me know John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [4.1.21] Stability rating
-Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Thursday, February 27, 2003 10:52 AM To: Tomcat Developers List Subject: [4.1.21] Stability rating ballot [ ] Alpha [ ] Beta [X] Stable (GA) /ballot Please vote (after testing the release, if possible ;). Thanks, Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RequestDispatcher.forward() problem
I am not sure if this helps, but a forward happens at the server so the server makes the forwarded request and returns the results to the browser, so the browser never knows the request has changed and therefor the URL in the browser will not change, on the other hand a redirect tells the browser to go get the new page so the browser URL will update to the new URL. John -Original Message- From: Simon Senécal [mailto:[EMAIL PROTECTED]] Sent: Friday, February 21, 2003 9:35 AM To: [EMAIL PROTECTED] Subject: RequestDispatcher.forward() problem I need help. (I use Tomcat 4.1.18) I'm in JSP1 in a webapp (Webapp1) and I use RequestDispatcher.forward(request, response) to forward in JSP2 located in another webapp (Webapp2). The two webapps are on the same server. The forwarding works, but once I'm in the JSP2 (in Webapp2), it looks like I'm still in the context of Webapp1, the URL of the request remains the URL of JSP1 in Webapp1. However, the servlet API documentation specifically says: For a RequestDispatcher obtained via getRequestDispatcher(), the ServletRequest object has its path elements and parameters adjusted to match the path of the target resource. Here is a simplified part of the code I use in JSP1: ServletContext contxt = getServletContext().getContext(/Webapp2); RequestDispatcher disp = contxt.getRequestDispatcher(/JSPinWebapp2.jsp); disp.forward(request, response); Is this a bug, or is there something that I'm missing or not understanding about forwarding? Simon Senécal Lab-Volt Québec (Software Development) 418-849-1000 #348 http://www.labvolt.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RequestDispatcher.forward() problem
There is a single sign on in tomcat, but I have never used it. You might want to ask about it in the user mailing list [EMAIL PROTECTED] or better yet read the archives and see if this question has already been answered there. John -Original Message- From: Simon Senécal [mailto:[EMAIL PROTECTED]] Sent: Friday, February 21, 2003 10:12 AM To: Tomcat Developers List Subject: RequestDispatcher.forward() problem Thanks for your reply, John. Can you transport data from one webapp to the other when you use the sendRedirect() method? Here is my true problem. I want to transport data such as a username and a password between two webapps (and I don't want to use URL rewriting). The user logs on Webapp1 and after authentification, the user has the choice to go to Webapp2, and I need the username and password to work in Webapp2. As I understand it, I can't use the session object to transport data because each Webapp has it's own session object. So I thought of using the forwarding method and use the request object to store my data (with setAttribute and getAttribute). It works, but like I said in my previous email, after forwarding, I'm still in the context of Webapp1. Simon. At 09:51 2003-02-21 -0500, you wrote: I am not sure if this helps, but a forward happens at the server so the server makes the forwarded request and returns the results to the browser, so the browser never knows the request has changed and therefor the URL in the browser will not change, on the other hand a redirect tells the browser to go get the new page so the browser URL will update to the new URL. John -Original Message- I need help. (I use Tomcat 4.1.18) I'm in JSP1 in a webapp (Webapp1) and I use RequestDispatcher.forward(request, response) to forward in JSP2 located in another webapp (Webapp2). The two webapps are on the same server. The forwarding works, but once I'm in the JSP2 (in Webapp2), it looks like I'm still in the context of Webapp1, the URL of the request remains the URL of JSP1 in Webapp1. However, the servlet API documentation specifically says: For a RequestDispatcher obtained via getRequestDispatcher(), the ServletRequest object has its path elements and parameters adjusted to match the path of the target resource. Here is a simplified part of the code I use in JSP1: ServletContext contxt = getServletContext().getContext(/Webapp2); RequestDispatcher disp = contxt.getRequestDispatcher(/JSPinWebapp2.jsp); disp.forward(request, response); Is this a bug, or is there something that I'm missing or not understanding about forwarding? Simon Senécal Lab-Volt Québec (Software Development) 418-849-1000 #348 http://www.labvolt.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: class-loading and java.endorsed.dirs
There already is a java.endorsed.dirs set up it is common.lib/endorsed (atleast in the 4.1.x) and is documented AFAIK John -Original Message- From: Voytenko, Dimitry [mailto:[EMAIL PROTECTED]] Sent: Friday, February 21, 2003 1:35 PM To: 'Tomcat Developers List' Subject: RE: class-loading and java.endorsed.dirs Hi Tim, Thanks for an answer. It makes sense. In this case, it looks like the only way users can take advantage of all Xalan's features (including extension mechanism) is to store Xalan's jars into shared\lib directory and add this directory to java.endorsed.dirs, since normally most users deploy their applications using WAR. If this is true: 1. Could I request adding this info to FAQ? 2. Could I request adding shared\lib to java.endorsed.dirs in setclasspath.bat(sh)? Thanks, Dimitry -Original Message- From: Tim Moore [mailto:[EMAIL PROTECTED]] Sent: Friday, February 21, 2003 08:15 To: Tomcat Developers List Subject: RE: class-loading and java.endorsed.dirs This is a JVM thing, not a tomcat thing. You're not normally allowed to override built-in Java classes locally (for security reasons). In JDK 1.4, the XML/XSLT classes are built in. The endorsed standards override mechanism was added to 1.4 because of the fact that some people might need or want to use an alternate XML parser or transformer. So the JAVA_ENDORSED_DIRS thing tells the JVM that it's OK to override Xalan with libraries from the specified directories. So I don't think there's any way to specify on a per-webapp basis which impl to use. It's all or nothing at the VM instance level. Also see http://java.sun.com/j2se/1.4/docs/guide/standards/ for more info. -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -Original Message- From: Voytenko, Dimitry [mailto:[EMAIL PROTECTED]] Sent: Friday, February 21, 2003 12:30 AM To: '[EMAIL PROTECTED]' Subject: class-loading and java.endorsed.dirs Hi, Here's what happend. It looks pretty strange. I couldn't find explanation to this neither in Tomcat docs, Servlet specs or Mailing List. I have a servlet, with doGet implemented as: System.err.println(XALAN VERSION = + org.apache.xalan.Version.getVersion()); In the application's WEB_INF/lib directory I have xalan.jar of version 2.4.1, which I thought should have been used. But instead, as the result of execution of the servlet, I got XALAN VERSION = Xalan Java 2.2 D11 This is the Xalan version included to JDK 1.4. Isn't application's JAR should be used (as stated in SRV.9.7.2 of the Servlet 2.3 specification)? Then, I changed setclasspath.bat JAVA_ENDORSED_DIRS env. variable to include my WEB_INF/lib directory (application wasn't packed into WAR). This variable is then passed as the value of java.endorsed.dirs java startup parameter. As the result, I got XALAN VERSION = Xalan Java 2.4.1 which I expected in the first place. Does this mean that libraries in the endorsed dir have bigger priority? It's a little confusing why this change whould make such a difference. Is there a way to specify forcefully that application should only use local libraries if they're specified? Thanks, Dimitry E Voytenko - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Sector Data, LLC, is not affiliated with Sector, Inc., or SIAC - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JDK 1.4 - again
http://www.caucho.com/ It is pretty fast. A lot of ISPs seem to use it for providing jsp / servlets to their users. -Original Message- From: Steve Burrus [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 19, 2003 6:47 PM To: Tomcat Developers List Subject: Re: JDK 1.4 - again What do u mean by a Resin 3.0 anyway?? What kind of a web container is that? I have NEVER really heard about that ever before! Would you please humor me and tell me all this resin 3.0? You say that it's a lot faster than Tomcat. How can that possibly be. Tomcat is pretty fast. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.0.1-dev] Testing with JRockit 8
I have a build from cvs of 5.0 running on RH 8 JDK 1.4.1 and have had no problems, but have not been doing performance testing. -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 13, 2003 9:18 AM To: Tomcat Developers List Subject: [5.0.1-dev] Testing with JRockit 8 For my book, I have been testing Tomcat with JRockit. I tested on a Win2k / Linux dual boot box, so it has the advantage of allowing to compare OSes :) The result: - on Windows, its performance was pretty much amazing (it *did* actually beat IBM on Linux, which was previously making Windows look really bad). - on Linux, it locks up the computer after a few requests and I have to kill -9 all Java threads individually (why ?). I don't think there's a problem with Tomcat which would cause that. For the record, I was using RH 8 with the latest kernel patch (the one Costin says is bad in his weblog ;-) ). The main disadvantage of JRockit is its insane memory usage (basically, it's 2* Sun Hotspot client; maybe there will be a use for those Athlon 64s even for small servers after all ;-) ). The other result is that Tomcat on Linux appears to run more reliably than Tomcat on Windows (except for the socket lingering bug that did cause problems), as on Windows, with all VMs, a few connections are rejected (while it never happens on Linux). I don't believe this behavior is caused by a Tomcat bug. Any comments, or anyone able to reproduce this ? Remy - 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]
Jasper race condition patch
This patch fixes a race condition in the JspWrapperServlet
The cause of this race condition is the use of the Double-Checked idiom.
For more information on why the Double-Checked idiom does NOT work
please read the following
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
Thanks,
John Trollinger
--- /old/JspServletWrapper.java 2003-01-15 09:54:16.0 -0500
+++ /new/JspServletWrapper.java 2003-01-24 10:39:40.0 -0500
@@ -133,28 +133,27 @@
public Servlet getServlet()
throws ServletException, IOException, FileNotFoundException
{
-if (ctxt.isReload()) {
-synchronized (this) {
-// Synchronizing on jsw enables simultaneous loading
-// of different pages, but not the same page.
-if (ctxt.isReload()) {
-// This is to maintain the original protocol.
-destroy();
-
-try {
-servletClass = ctxt.load();
-theServlet = (Servlet) servletClass.newInstance();
-} catch( IllegalAccessException ex1 ) {
-throw new JasperException( ex1 );
-} catch( InstantiationException ex ) {
-throw new JasperException( ex );
-}
+
+synchronized (this) {
+// Synchronizing on jsw enables simultaneous loading
+// of different pages, but not the same page.
+if (ctxt.isReload()) {
+// This is to maintain the original protocol.
+destroy();
-theServlet.init(config);
-firstTime = false;
+try {
+servletClass = ctxt.load();
+theServlet = (Servlet) servletClass.newInstance();
+} catch( IllegalAccessException ex1 ) {
+throw new JasperException( ex1 );
+} catch( InstantiationException ex ) {
+throw new JasperException( ex );
}
-}
-}
+
+theServlet.init(config);
+firstTime = false;
+}
+}
return theServlet;
}
@@ -185,9 +184,8 @@
}
}
-if (ctxt.isReload()) {
-getServlet();
-}
+getServlet();
+
// If a page is to only to be precompiled return.
if (precompile) {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Fork set to true on jasper
When setting fork to true on windows I get a Error running javac.exe compiler When looking at the stack trace it looks as if the classpath is too long and gets truncated at 1000 chars so the class can not be compiled. Does anyone know a work around for this, I tried the user list with no response. Thanks, john -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
A little help please
Could someone familiar with Jasper please look at bug 15845. This is causing us problems and we found a work around but without the knowing why the code was running the way it was in the first place it is hard to validate that our solution will not have any adverse affects. Thanks, John -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Problem with Socket closing
See bug 12810 -Original Message- From: Greg Strobl [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 12, 2002 9:38 AM To: '[EMAIL PROTECTED]' Subject: Problem with Socket closing Hi, Tomcat 4.1.12 OS: W2K JRE: Sun 1.4.1_01 (Originally found using 1.4.0) I am seeing a problem with Tomcat closing a socket connection and having a write error. This happens with both SSL and regular sockets (the log example that is at the end show an SSL example.) I can reproduce the problem at times but sometimes that test case works (and the page renders as it should.) Our website sits on top of a data warehouse and I mostly experience the problem with the pages that have the longer queries. Does anybody know why this happens? Is there a fix? What can I do to try figure out what is causing the problem? I have turned up the debugging level on Tomcat (to 1) and that didn't produce much more information. I have added (println) statements to my code to see if there is a problem in it. It appears that my code always completes even when the socket connection is broken. Basically, I am at a point where I don't know what to try next. Here is the log output: 2002-12-11 17:07:28 ApplicationDispatcher[] Servlet.service() for servlet jsp threw exception org.apache.jasper.JasperException: Connection has been shutdown: javax.net.ssl.SSLException: java.net.SocketException: Software caused connection abort: socket write error at org.apache.jasper.servlet.JspServletWrapper.service(JspServlet Wrapper.java:2 48) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet .java:289) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationDispatcher.invoke(Applicat ionDispatcher. java:684) at org.apache.catalina.core.ApplicationDispatcher.doForward(Appli cationDispatch er.java:432) at org.apache.catalina.core.ApplicationDispatcher.forward(Applica tionDispatcher .java:356) at org.apache.jasper.runtime.PageContextImpl.forward(PageContextI mpl.java:427) at org.apache.jsp.page_jsp._jspService(page_jsp.java:100) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:136) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServletWrapper.service(JspServlet Wrapper.java:2 04) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet .java:289) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationDispatcher.invoke(Applicat ionDispatcher. java:684) at org.apache.catalina.core.ApplicationDispatcher.doForward(Appli cationDispatch er.java:432) at org.apache.catalina.core.ApplicationDispatcher.forward(Applica tionDispatcher .java:356) at org.apache.jasper.runtime.PageContextImpl.forward(PageContextI mpl.java:427) at org.apache.jsp.page_jsp._jspService(page_jsp.java:116) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:136) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServletWrapper.service(JspServlet Wrapper.java:2 04) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet .java:289) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilt er(Application FilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli cationFilterCh ain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardW rapperValve.ja va:260) at org.apache.catalina.core.StandardPipeline$StandardPipelineValv eContext.invok eNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipel ine.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardC ontextValve.ja va:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValv eContext.invok eNext(StandardPipeline.java:643) at org.apache.catalina.valves.CertificatesValve.invoke(Certificat esValve.java:2 46) at org.apache.catalina.core.StandardPipeline$StandardPipelineValv eContext.invok eNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipel ine.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at
Jasper Classloader question
I am trying to access the jasper class loader directly. I want to do this so that I can get a jsp class file out of it at runtime vs having to do a jsp:include to call the jsp. I am having a little trouble getting through the jasper code and would like a little direction please. I know that I am going to have to change some classes and this is a temp solution for us but something that is needed. Again any help is great.. Thanks, john -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Javac memory leak
Ok, I did some testing running 4.1.14 as a service... Now my knowledge of memory management is not so good so this might mean nothing. When running as a service if I goto every example jsp page (the examples that come with the install) Compiled Memory starts at 37872 and ends at 39048 Not compiled Memory starts at 39635 and ends at 58760 Does this not look like a memory leak in the jsp compile code?? Thanks, John -Original Message- From: Holger Brozio [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 12:14 PM To: Tomcat Developers List Subject: Re: Javac memory leak I also have no memory leak problems now with Tomcat 4.1.12. But i'm using jikes instead of javac as jsp page compiler. Whats about switching to jikes. If the memory leak problem is gone with jikes, javac still leaks memory, otherwise it is a problem in the jsp pages. Cheers Holger - Original Message - From: John Trollinger [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 20, 2002 3:39 PM Subject: Javac memory leak Does anyone know if the javac memory leak still exists (1.4.1 docs say it does not). I have a test the goes through a bunch of jsp pages and if they are not precompiled I get a out of memory exception. Thanks, John -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Javac memory leak
When I run the examples with -verbose:gc this is what I get (just the snippits at the end) From uncompiled jsp pages [GC 14707K-13665K(28412K), 0.0059002 secs] [GC 15521K-15518K(28412K), 0.0128997 secs] [GC 17374K-16086K(28412K), 0.0092266 secs] [GC 17942K-16258K(28412K), 0.0086307 secs] [GC 18114K-16213K(28412K), 0.0046327 secs] [GC 18069K-17934K(28412K), 0.0114056 secs] [GC 19790K-19672K(28412K), 0.0155838 secs] Did you see me on the stderr window? Did you see me on the browser window as well? [GC 21520K-20092K(28412K), 0.0094920 secs] [GC 21947K-20095K(28412K), 0.0075890 secs] [GC 21951K-21758K(28412K), 0.0131385 secs] [GC 23614K-23528K(28412K), 0.0137372 secs] [GC 25384K-23769K(28412K), 0.0079125 secs] [GC 25625K-24336K(28412K), 0.0073652 secs] [GC 26192K-26170K(28412K), 0.0153369 secs] [GC 28026K-27460K(29436K), 0.0190963 secs] [Full GC 27460K-15538K(29436K), 0.2839948 secs] [GC 17394K-15720K(28412K), 0.0060262 secs] [GC 17575K-15746K(28412K), 0.0046218 secs] [GC 17602K-15745K(28412K), 0.0027241 secs] [GC 17601K-15745K(28412K), 0.0025604 secs] [GC 17601K-15746K(28412K), 0.0026679 secs] Stopping service Tomcat-Standalone From compiled jsp pages [GC 11356K-10577K(14028K), 0.0061505 secs] [GC 11532K-11034K(14028K), 0.0046978 secs] [GC 11994K-11305K(14028K), 0.0060575 secs] [GC 12265K-11341K(14028K), 0.0059876 secs] [GC 12297K-11396K(14028K), 0.0065578 secs] [GC 12356K-11538K(14028K), 0.0063572 secs] [GC 12498K-11598K(14028K), 0.0040036 secs] [GC 12558K-11965K(14028K), 0.0052529 secs] Did you see me on the stderr window? Did you see me on the browser window as well? [GC 12925K-12020K(14028K), 0.0046872 secs] Stopping service Tomcat-Standalone As you can see there is about a 4 meg diff between the two This is using j2sdk 1.4.1 on windows XP with 512 ram using tomcat 4.1.14LE -Original Message- From: peter lin [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 10:56 AM To: Tomcat Developers List Subject: Re: Javac memory leak Just to double check against tomcat 4.1.12, the memory usage seems normal to me John. After tomcat starts up, it is using 23megs. My webapp loads when tomcat starts up, so your numbers may be lower. The system has 256megs of memory and 750mhz cpu. after I I hit all the pages in /examples/jsp/ directory, the memory allocated to java is 40megs. I even ran it with OptimizeIt and I don't see any memory leaks. peter peter lin wrote: that is unusual. I've done baseline performance tests with the standard examples and haven't seen that kind of behavior with 4.1.10-12. Can you start tomcat with verbose:gc and see what kind of output you're getting. Just because the memory allocated to Java is 58megs at the end, it doesn't mean it's actually using all of it actively. getting the GC output will tell you how much memory is being used, when GC runs and whether or not a fullGC ran. in past experience with 4.0.4, after loading all the example pages tomcat's memory allocation is around 45megs. peter John Trollinger wrote: Ok, I did some testing running 4.1.14 as a service... Now my knowledge of memory management is not so good so this might mean nothing. When running as a service if I goto every example jsp page (the examples that come with the install) Compiled Memory starts at 37872 and ends at 39048 Not compiled Memory starts at 39635 and ends at 58760 Does this not look like a memory leak in the jsp compile code?? Thanks, John -Original Message- From: Holger Brozio [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 12:14 PM To: Tomcat Developers List Subject: Re: Javac memory leak I also have no memory leak problems now with Tomcat 4.1.12. But i'm using jikes instead of javac as jsp page compiler. Whats about switching to jikes. If the memory leak problem is gone with jikes, javac still leaks memory, otherwise it is a problem in the jsp pages. Cheers Holger - Original Message - From: John Trollinger [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 20, 2002 3:39 PM Subject: Javac memory leak Does anyone know if the javac memory leak still exists (1.4.1 docs say it does not). I have a test the goes through a bunch of jsp pages and if they are not precompiled I get a out of memory exception. Thanks, John -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional
RE: Javac memory leak
This is the examples with the install.. What I don't understand is why there is a difference when compiled vs uncompiled and the diff is always there. When we run our tests if our jsp pages are uncompiled the diff is about 170 meg.. That is what causes me to be a little nervous. I will try optimizeit and see what it shows.. Thanks for all your time.. John -Original Message- From: peter lin [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 11:36 AM To: Tomcat Developers List Subject: Re: Javac memory leak This is from the examples jsp right? or are they from your webapp? the latest optimizeit has a leak finder feature. you may want to download the trail version and give it a shot. from the data it looks like a lot of objects are promoted to old memory from heap. It doesn't necessarily constitute a memory leak though. if you use a lot of static variables, that could easily account for objects getting promoted to old memory peter John Trollinger wrote: When I run the examples with -verbose:gc this is what I get (just the snippits at the end) From uncompiled jsp pages [GC 14707K-13665K(28412K), 0.0059002 secs] [GC 15521K-15518K(28412K), 0.0128997 secs] [GC 17374K-16086K(28412K), 0.0092266 secs] [GC 17942K-16258K(28412K), 0.0086307 secs] [GC 18114K-16213K(28412K), 0.0046327 secs] [GC 18069K-17934K(28412K), 0.0114056 secs] [GC 19790K-19672K(28412K), 0.0155838 secs] Did you see me on the stderr window? Did you see me on the browser window as well? [GC 21520K-20092K(28412K), 0.0094920 secs] [GC 21947K-20095K(28412K), 0.0075890 secs] [GC 21951K-21758K(28412K), 0.0131385 secs] [GC 23614K-23528K(28412K), 0.0137372 secs] [GC 25384K-23769K(28412K), 0.0079125 secs] [GC 25625K-24336K(28412K), 0.0073652 secs] [GC 26192K-26170K(28412K), 0.0153369 secs] [GC 28026K-27460K(29436K), 0.0190963 secs] [Full GC 27460K-15538K(29436K), 0.2839948 secs] [GC 17394K-15720K(28412K), 0.0060262 secs] [GC 17575K-15746K(28412K), 0.0046218 secs] [GC 17602K-15745K(28412K), 0.0027241 secs] [GC 17601K-15745K(28412K), 0.0025604 secs] [GC 17601K-15746K(28412K), 0.0026679 secs] Stopping service Tomcat-Standalone From compiled jsp pages [GC 11356K-10577K(14028K), 0.0061505 secs] [GC 11532K-11034K(14028K), 0.0046978 secs] [GC 11994K-11305K(14028K), 0.0060575 secs] [GC 12265K-11341K(14028K), 0.0059876 secs] [GC 12297K-11396K(14028K), 0.0065578 secs] [GC 12356K-11538K(14028K), 0.0063572 secs] [GC 12498K-11598K(14028K), 0.0040036 secs] [GC 12558K-11965K(14028K), 0.0052529 secs] Did you see me on the stderr window? Did you see me on the browser window as well? [GC 12925K-12020K(14028K), 0.0046872 secs] Stopping service Tomcat-Standalone As you can see there is about a 4 meg diff between the two This is using j2sdk 1.4.1 on windows XP with 512 ram using tomcat 4.1.14LE -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Javac memory leak
Well d/l optimizeit and realized it would take a few weeks for me to understand what it is trying to tell me.. Just to double check against tomcat 4.1.12, the memory usage seems normal to me John. After tomcat starts up, it is using 23megs. My webapp loads when tomcat starts up, so your numbers may be lower. The system has 256megs of memory and 750mhz cpu. after I I hit all the pages in /examples/jsp/ directory, the memory allocated to java is 40megs. Peter, did you try it with the examples compiled and then uncompiled and get the same results.. Or did you just run them once?? I even ran it with OptimizeIt and I don't see any memory leaks. peter -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Javac memory leak
Does anyone know if the javac memory leak still exists (1.4.1 docs say it does not). I have a test the goes through a bunch of jsp pages and if they are not precompiled I get a out of memory exception. Thanks, John -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Javac memory leak
We are using Tomcat 4.1.12 on windows and when running an automated test that navigates through a set of about 75 jsp pages (they have includes in them that kick of more compiles) it gets a OutOfMemoryException halfway through the compile. Our system is quite complex so I don't know if I can get an example of this.. John -Original Message- From: peter lin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 9:43 AM To: Tomcat Developers List Subject: Re: Javac memory leak I haven't seen the memory leak on solaris or windows, but isn't the leak only on linux? I thought jasper2 fixes the problem with com.sun.tools.javac.Main since it uses the system native javac? peter John Trollinger wrote: Does anyone know if the javac memory leak still exists (1.4.1 docs say it does not). I have a test the goes through a bunch of jsp pages and if they are not precompiled I get a out of memory exception. Thanks, John -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Javac memory leak
If the pages are precompiled I do not have any problems at all, it is only when the jsp cache has been deleted that this shows up. John -Original Message- From: peter lin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 9:57 AM To: Tomcat Developers List Subject: Re: Javac memory leak Hmm, that sounds bizzare. I'm been using/testing 4.1.10-4.1.12 on both solaris and windows with jdk1.4.1. I've ran several stress test using JMeter simulating light to medium (64 concurrent connections) load for 1-10K requests without any problems. My pages are heavy on JSTL, so they are fairly heavy weight. Even when I run stress tests with 5K unique requests for 10K+ requests, I haven't seen memory leaks. the number of JSP range in 100-200 range. peter John Trollinger wrote: We are using Tomcat 4.1.12 on windows and when running an automated test that navigates through a set of about 75 jsp pages (they have includes in them that kick of more compiles) it gets a OutOfMemoryException halfway through the compile. Our system is quite complex so I don't know if I can get an example of this.. John -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Javac memory leak
We have 2, one is webdav and the other is our actual application. We use a lot of custom tags and a lot of both types of includes (when I say a lot we have jsp pages that include over 500 other jsp pages, and no, this is not my design :) ) -Original Message- From: peter lin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 10:12 AM To: Tomcat Developers List Subject: Re: Javac memory leak by any chance do you have multiple webapps or just one? in my case, I only have one webapp which has some services it loads when tomcat starts. All of my pages are dynamic with all the text in resourceBundles. The dynamic data is retrieved from a middle layer in XML format. JSTL is used to get text from resourceBundles and parse the XML. I'm on win2K also. peter John Trollinger wrote: If the pages are precompiled I do not have any problems at all, it is only when the jsp cache has been deleted that this shows up. John -Original Message- From: peter lin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 9:57 AM To: Tomcat Developers List Subject: Re: Javac memory leak Hmm, that sounds bizzare. I'm been using/testing 4.1.10-4.1.12 on both solaris and windows with jdk1.4.1. I've ran several stress test using JMeter simulating light to medium (64 concurrent connections) load for 1-10K requests without any problems. My pages are heavy on JSTL, so they are fairly heavy weight. Even when I run stress tests with 5K unique requests for 10K+ requests, I haven't seen memory leaks. the number of JSP range in 100-200 range. peter John Trollinger wrote: We are using Tomcat 4.1.12 on windows and when running an automated test that navigates through a set of about 75 jsp pages (they have includes in them that kick of more compiles) it gets a OutOfMemoryException halfway through the compile. Our system is quite complex so I don't know if I can get an example of this.. John -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Javac memory leak
But that would not account for the leak only occuring when pages need a compile. If the pages are compiled I never see the leak. -Original Message- From: peter lin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 10:43 AM To: Tomcat Developers List Subject: Re: Javac memory leak John Trollinger wrote: We have 2, one is webdav and the other is our actual application. We use a lot of custom tags and a lot of both types of includes (when I say a lot we have jsp pages that include over 500 other jsp pages, and no, this is not my design :) ) I'm guessing there's some memory leak in one of the custom tags some where. early in the development of the project I did have memory leaks, but it was a bug in our code. Once I looked at the number of threads running and the GC output, it was obvious our custom tag was the cause. In my particular case, the connection to the middle layer wasn't getting garbaged immediately. Once I fixed that, my memory leak went away. could be something as simple as a tag.release() not releasing correctly :) peter -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JSPC refactoring/documentation
Has there or will there be any type of requirement gathering on jspc refactoring. I would like to help refactor this but would like to know what options need to be supported / added and which ones to remove. John -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: [VOTE] Proposed jspc refactoring
I have to disagree with this, jspc is a pre compiler, not a webapp packager. John I agree that JSPC needs to be simplified and that the webapp mode should be retained. But the webapp mode should allow for a war file to be generated which is self contained including the precompiled JSP classses. And for the generated war to be able to run from the war file with no need to unpack it. Also I agree that this feature is a proprietary feature of Tomcat and we should no longer try to generate a war that can be deployed in any container. There may be a way to do this: Put the generated JSP class files in a /WEB-INF/jspwork/ directory. This work directory would only be used by jasper for loading jsp pages, the normal work directory would still be used for all other things. Add the jspwork attribute to the DefaultContext and Context config elements. This attribute would specify the directory path within the war file to use for loading the JSP page classes from by Jasper. This would allow JSPC to create a war file which was self contained including the precompiled JSP page classes and be runnable directly from the war or unpacked into a directory. +1 if we modify Tomcat Jasper to support precompiled JSP pages running +from a self contained war file. Regards, Glenn -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: [VOTE] Proposed jspc refactoring
ballot +1 [ ] Remove the options -1 [X] Do not remove the options /ballot I think some of the options are useless and should go away, but some of them are (or could be usefull if they worked). Right now I don't think jspc meets many peoples needs, maybe it is time to find out the needs of users for jspc and implement those correctly. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: [VOTE] Proposed jspc refactoring
I have to time to go through and fix all the options (including cleaning up the code) but I would like to see what options are actually used (or would like to be used if they work) I also have no problems maintaining jscp as I use it a lot and have customized it to do what I want. I would just like some direction to go with.. John -Original Message- From: news [mailto:news;main.gmane.org] On Behalf Of Costin Manolache Sent: Thursday, November 07, 2002 1:39 PM To: [EMAIL PROTECTED] Subject: Re: [VOTE] Proposed jspc refactoring Remy has a point - the current code is not very clean, and doesn't seem to be tested/maintained enough. I use the ant tasks - and I have a feeling many other users of jspc are doing the same. Removing the CLI and keeping the basic functionality seems like a good idea. For example compiling a jsp page outside a webapp can't work in all cases - if it has includes, etc it needs to resolve, it needs taglib definitions from WEB-INF, etc. I can't see any good reason to keep it if it's half broken by definition. Also - compiling the java files is the job of javac, and the mapping and web.xml fragment generation can be more easily done using only the ant tasks. I would go even further - since we are already using ant to compile the java to .class, it may be a good idea to make the .jsp-.java task 'first class'. In any case - the task is supported ( at least by me, it seems Henri is using it as well ). If there are people who want to support the CLI and the other options - then we can keep them, but if not - I think it's better to remove them or mark as unsupported. Costin Hans Bergsten wrote: Remy Maucherat wrote: Hi, jspc is IMO overly complex, with many features nobody knows how to use, and nobody cares to test (hence sometimes some of them are randomly broken during Jasper refactorings). I will not formally vote on this, because I've been inactive in this project for so long I feel I need to familiarize myself with the current code base before I can exercise my voting priviledges. But I do have some comments, see below. I propose that: - In Tomcat 5, all jspc options are removed, in favor of allowing only the webapp mode (with its relevant options). This webapp mode would generate code and classes which should be deployed in the work directory, exactly the same as if they were dynamically compiled by Jasper (which has the big advantage of using only one big operation mode for everything). Single file mode is IMO useless (dynamic compilation works fine). I agree with you regading single file mode, but not with the rest. - In Tomcat 4.1, the options will stay in for compatibility, but the usage help will be modified to be the same as Tomcat 5. I'm not sure what you mean by this proposal. Are you saying that the TC 4.1.x version would have a usage message (documentation) that doesn't match its features? If so, why? If there will be differences between the TC 4.1.x and TC 5 versions, I assume we will maintain a separate code base for each version, each with documentation that correctly reflects their features. It has to be noted that: - The JSP runtime is now very efficient. The old webapp mode (with its static web.xml) is a hack (and a 100% proprietary one at that). Efficiency is not all that important here, since precomiplation is done before deployment (that's the whole idea, right ;-) Not sure what you mean with 100% proprietary. The web.xml file (or fragment) that is generated is defined by the servlet spec. - Precompilation should only occur at webapp deployment time in the general case (the generated code is closely tied to the Jasper runtime release). I don't agree. It's very handy to be able to generate a JAR file with all JSP pages for an application and deploy it to many different container instances (Tomcat or others, as long as jasper-runtime.jar is included). There are many users that want to keep the production environment as simple (and small in embedded systems, for instance) as possible, and deploying precompiled JSP pages lets me use a production environment without the JSP compiler and use JRE instead of the JDK. - Additional features could be added to the manager servlet to, for example, cause precompilation of the deployed webapp in a separate process. That's a separate thing, more of a container feature than JSPC in my mind. - I am -1 to returning to the old webapp option behavior (ie, the generated files should by default be deployed in the work directory, not /WEB-INF/classes). Why not discuss what the problems with the current options are, and try to find a solution instead? Like I've said, it's been a while since I was actively involved with Tomcat development, but
RE: JSPC problems with webapp option
There are some people that would like to precompile the webapp and then just deploy the generated servlets with there webapp, to remove this option would really hinder their ability to due this (although the package naming already makes this tough to do and there are patches floating around to allow the packages to be generated from the dir structure, I also belive there are bugs about this) Just my 2 cents.. John -Original Message- From: Remy Maucherat [mailto:remm;apache.org] Sent: Wednesday, November 06, 2002 9:29 AM To: Tomcat Developers List Subject: JSPC problems with webapp option Hi all, I toyed a bit with the webapp option of JSPC, and a few things seemed really odd. - Although there are options to generate web.xml files or fragments, this makes no sense as the generated files are now meant to be put in the work directory instead. This was probably done as a workaround for the slow Jasper runtime (that has been fixed). I think those options should be removed, and it should be made clear that the target directory should be the webapp's work directory. - There should be an optional compilation flag (also compile if present). That's very convinient IMO. I propose -c (with false being the default). Those changes should be simple to implement (I plan to do it, and integrate them in 4.1.15). Comments ? Remy -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Problem with navigating faster that JSP pages can compile
I did not want to create a bug for this, as I can not reproduct it with a simple example. We have a webapp that has some huge jsp pages that take a good while to compile. If you navigate to another page before the previous page finishes its compile sometime the new page will get a compile error. When you look at the error it is as if the compiler merged the two generated classes. You will see the beginning of one word from the first jsp page and the end of a word from the second in the error message (ie if jsp1 had String john = Hi john; and jsp2 had boolean cold = true; then the compile error would refer to Strlean cold = true; unknown class Strlean) if you look at the .java files for the jsp pages they are fine and as they should be and a refresh will fix the problem. Does anyone know where should start to look to see if I can resolve (or atleast recreate in a simple example) this problem. Thanks, John -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Where have the 4.1x nightly builds
I can not seem to find the nighly builds for 4.1.x have they moved and the links are just broken. Thanks, John -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: [5.0] [VOTE] Remove deprecated and unsupported components
ballot [ ] Remove deprecated org.apache.catalina.connector components from the j-t-catalina module [X ] Leave them in /ballot Atleast untill all the excessive log messages are removed from the coyote connectors (ie the socket error messages) or there is a way to disable them (ie give them a log level) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JSP Compilation Issues (Multiple Domains)
Can we get the sync changes in the 4.1.x releases as we also have problems with this and currently maintain our own jasper code base with the sync code in it. -Original Message- From: Kin-Man Chung [mailto:[EMAIL PROTECTED]] Sent: Monday, September 30, 2002 9:47 PM To: [EMAIL PROTECTED] Subject: Re: JSP Compilation Issues (Multiple Domains) If you are using JDK javac for compiling the servlet generated by the JSP compiler, then you probably ran into the problem that the javac not being thread-safe. In Tomcat 5 the javac compilation is synchronized, so that the compilation is serialized. Guess that fix is not ported to 4.1.5. :-( I always assume that JSP pages would be deployed precompiled, and simultaneous compilation under development mode is rare. Maybe my assumption is wrong? Date: Mon, 30 Sep 2002 18:30:48 -0700 From: Joseph Kiok [EMAIL PROTECTED] Subject: JSP Compilation Issues (Multiple Domains) To: [EMAIL PROTECTED] X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600. X-Priority: 3 X-MSMail-priority: Normal Hi All, I'm currently running multiple domains (2 specifically) on top of Apache/Tomcat. It seems that when I hit both domains at the same time (using 2 browser windows), I get a JSP compilation error most (85%) of the time. However, when I reload the page with no JSP code change, it'll compile properly. (Some of the time like 10-15%, it won't recompile until I touch the file manually) Note: It doesn't happen when I only access one domain. PROBLEM SUMMARY: When loading JSPs on multiple domains (hosts) simultaneously, a JSP compile error is generated. SYSTEM COMPONENTS: - Solaris 2.8 - JDK 1.4.0_01 - Tomcat 4.1.12 - Apache 1.3.20 SOLUTIONS TRIED (FAILED): - Configured different workers for each domains (hosts) as recommended in the tomcat mod_jk document. - Downloaded the source of tomcat and recompiled everything on our environment. Any help would be appreciated. Thanks. Best regards, Joseph Kiok -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JSP Compilation Issues (Multiple Domains)
+1 to the sync option -Original Message- From: Glenn Nielsen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 01, 2002 9:45 AM To: Tomcat Developers List Subject: Re: JSP Compilation Issues (Multiple Domains) Another way to fix this would be to install the external compiler jikes and configure Jasper 2 to use this. I would also like to see a servlet init parameter added to jasper that can enable or disable synchronized JSP compiles. This way those who know they have a thread safe way to compile JSP's don't get hit by the synchronize. Regards, Glenn John Trollinger wrote: Can we get the sync changes in the 4.1.x releases as we also have problems with this and currently maintain our own jasper code base with the sync code in it. -Original Message- From: Kin-Man Chung [mailto:[EMAIL PROTECTED]] Sent: Monday, September 30, 2002 9:47 PM To: [EMAIL PROTECTED] Subject: Re: JSP Compilation Issues (Multiple Domains) If you are using JDK javac for compiling the servlet generated by the JSP compiler, then you probably ran into the problem that the javac not being thread-safe. In Tomcat 5 the javac compilation is synchronized, so that the compilation is serialized. Guess that fix is not ported to 4.1.5. :-( I always assume that JSP pages would be deployed precompiled, and simultaneous compilation under development mode is rare. Maybe my assumption is wrong? Date: Mon, 30 Sep 2002 18:30:48 -0700 From: Joseph Kiok [EMAIL PROTECTED] Subject: JSP Compilation Issues (Multiple Domains) To: [EMAIL PROTECTED] X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600. X-Priority: 3 X-MSMail-priority: Normal Hi All, I'm currently running multiple domains (2 specifically) on top of Apache/Tomcat. It seems that when I hit both domains at the same time (using 2 browser windows), I get a JSP compilation error most (85%) of the time. However, when I reload the page with no JSP code change, it'll compile properly. (Some of the time like 10-15%, it won't recompile until I touch the file manually) Note: It doesn't happen when I only access one domain. PROBLEM SUMMARY: When loading JSPs on multiple domains (hosts) simultaneously, a JSP compile error is generated. SYSTEM COMPONENTS: - Solaris 2.8 - JDK 1.4.0_01 - Tomcat 4.1.12 - Apache 1.3.20 SOLUTIONS TRIED (FAILED): - Configured different workers for each domains (hosts) as recommended in the tomcat mod_jk document. - Downloaded the source of tomcat and recompiled everything on our environment. Any help would be appreciated. Thanks. Best regards, Joseph Kiok -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: How to run multiple instances of JSP pages/servlets in Tomcat?
The servlet spec explains how to do this servlet servlet-nameMyJspPage/servlet-name jsp-file/mywebapp/MyJspPage.jsp/jsp-file init-param param-nameconfigFile/param-name param-valuemy.conf/param-value /init-param load-on-startup1/load-on-startup /servlet -Original Message- From: Luca Ventura [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 26, 2002 10:50 AM To: tomcat-dev Subject: How to run multiple instances of JSP pages/servlets in Tomcat? Hello everybody! In Tomcat 4.x I don't know how I can call automatically a JSP page when the web application starts. I mean...in Tomcat 4.x there is the web.xml file where I can declare: servlet servlet-nameMyServlet/servlet-name servlet-classMyServlet/servlet-class init-param param-nameconfigFile/param-name param-valuemy.conf/param-value /init-param load-on-startup1/load-on-startup /servlet In this way the servlet MyServlet is called when the web app. starts... Can I do the same thing with a jsp page (the jsp page should be like a servlet, in fact it is translated into a servlet when it is called the first time)? If yes, in which way? Another questions: how can I tell the Web Server Tomcat to activate more instances of a servlet or a JSP page? Thanks a lot to everybody! Luca -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Don't buy all the velocity hype.. It is not as great as they make it out to be. Please no flames from the velocity disiples as I will not respond. -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 6:23 PM To: Tomcat Dev List Subject: Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability On Wed, 2002-09-25 at 07:31, Matt Fury wrote: What's easier though? Upgrading a Tomcat server with a patch or re-architecting your whole site to accomodate for Velocity?? Short term, upgrading Tomcat. Long term, doing it in Velocity. Bojan -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
System.out.println() calls in servlet init methods
Can someone tell me why System.out.println() calls in the init methods of servlets do not make it out to the console at all. They will make it into a log file but never print to the console itself. System.out.println() calls in the doGet and doPost print out to the console as expected. Thanks, John -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jasper 2 Question
To answer your original question, I do not believe there is any enhancements to add documentation back to the generated servelt code. If you would like to see this enhancement you can allways suggest it to the tomcat developers, or you could add the code in yourself and submit a patch. And don't buy all the velocity hype... :-) -Original Message- From: Lenny Karpel [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 19, 2002 6:28 PM To: 'Tomcat Developers List' Subject: RE: Jasper 2 Question ok .. now I am really confused .. here is the tomcat development group .. the 'Official Reference Implementation' for JSP .. and I am being told by people within this group .. to NOT use it .. this is truly amazing .. how can this possibly be .. my original question is about 'bugs' in jasper2 .. not about what tools I should use .. my question is not one of religion .. once again .. the quote from the intellij site .. As for Tomcat 4.1.x support, I'm afraid we are out-of-luck here. Tomcat 4.0.4 used to generate useful comments in the servlet code, that allowed the integration plugin to map jsp line numbers to servlet line numbers. But from the new version of Tomcat (Jasper2 in particular), this functionality is missing. At least I haven't been able to find anything to enable comment generation, and nobody from Tomcat user-list answered my question about this. for myself .. all I want to know .. is if this 'situation' in jasper2 will be fixed .. if so .. when .. if not .. why .. we use JSP here .. as do quite a few others .. in quite a few places .. i did not post this question to find out that the developers of JSP (jasper) would rather I use something else .. could this possibly be how the 'managers' of this development effort feel ?? -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 19, 2002 3:25 PM To: Tomcat Dev List Subject: RE: Jasper 2 Question On Fri, 2002-09-20 at 04:30, Lenny Karpel wrote: is it right that when I ask a serious question about jasper2 that I get these totally ridiculous answers ? Well, Jon and Pier are known to throw in a curly one from time to time, which keeps all of us here on the list in good spirits ;-) Anyway, there is a serious side to all this as JSP's are inherently evil. You'll find that creating true MVC applications in Velocity is almost trivial. I suggest you do read Jon's article. The fact that JSP's are official, doesn't mean they are good. Bojan -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jasper 2 Question
Nooo. No more velocity.. Please.. No more.. -Original Message- From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 19, 2002 1:48 PM To: tomcat-dev Subject: Re: Jasper 2 Question on 2002/9/19 8:06 AM, Lenny Karpel [EMAIL PROTECTED] wrote: sorry .. I don't understand your response ! are you saying that we shouldn't use jsp ? I have been saying that for years now! http://jakarta.apache.org/velocity/ymtd/ymtd.html =) -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Bug 11091 has now been untouched for over a month
Sean, The error still exists.. I fixed the directory structure and can get other exceptions to work fine, but when I though and map a javax.servlet.jsp.JspException it fails every time.. I think it happens before it checks to see where to forward the error as I have looked at that code in the jasper runtime and it should work in there... John -Original Message- From: Sean Reilly [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 04, 2002 10:40 AM To: [EMAIL PROTECTED] Cc: Tomcat Developers List Subject: RE: Bug 11091 has now been untouched for over a month Here are the contents of the attachment. The directory structure is as follows: Error.jsp and test.jsp would be in the web-app's main directory web.xml goes in a WEB-INF subdirectory Sean -Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 04, 2002 2:20 AM To: Tomcat Developers List Subject: Re: Bug 11091 has now been untouched for over a month Sean Reilly wrote: Hi, I posted bug #11091 (http://issues.apache.org/bugzilla/show_bug.cgi?id=11091) on July 23rd. Since then, nobody besides myself has posted a comment to it, and it is still assigned to [EMAIL PROTECTED] The recent test milestone (4.1.10) released on August 30th does not fix the issue. Has anyone looked into this bug at all? Are there any plans to fix it? Any comments at all would be very much appreciated. I cannot read the attachement (id=2450). Could you please mail it to me? I will try to have a look. Thanks in advance, Sean Sean Reilly Programmer, Point2 Technologies, Inc. (306) 955-1855 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Spec question: RE BUG 12052
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 28, 2002 12:15 PM To: Tomcat Developers List Subject: Re: Spec question: RE BUG 12052 On 28 Aug 2002, Bojan Smojver wrote: Date: 28 Aug 2002 23:27:18 +1000 From: Bojan Smojver [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Dev List [EMAIL PROTECTED] Subject: Spec question: RE BUG 12052 Craig, I think this bug report is invalid, since Tomcat/Apache has no knowledge of load balancers and firewalls, so it is unrealistic to expect to return port numbers that it doesn't know about. What do you think? http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12052 Other opinions welcome :-) There are circumstances when we're not going to know the port number, but normal use of Tomcat behind JK doesn't seem to be one of them, IMHO. Consider Apache running on port 80, forwarding to Tomcat on 8009 (the default setup). I think it's reasonable for the application developer to assume that getServerPort() is going to return 80 and not 8009, because they should conceptually view the entire Apache+Tomcat thing as a single server. I have to disagree with you there. If a request comes to the servlet engine on port 8009 then getServerPort() should return that. It is bad to have Tomcat try and guess where its requests are coming from. As for implementing this, a couple of possibilities: * Include the port number along with the host name (haven't checked if this is already happening) * Add a protocol variable in the JK protocol so that the web server can forward which port number the request was received on. * Add a Connector property saying the port number that should be used for getServerPort() for all requests processed by this connector (the deprecated HttpConnector code had proxyPort for this purpose). If a load balancer or proxy *ahead* of Apache is doing the port shifting, there's not a lot we can do. But we should cover the case for requests that come in to the web server and get forwarded by us. Bojan Craig -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Spec question: RE BUG 12052
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 28, 2002 1:04 PM To: Tomcat Developers List Subject: RE: Spec question: RE BUG 12052 On Wed, 28 Aug 2002, John Trollinger wrote: Consider Apache running on port 80, forwarding to Tomcat on 8009 (the default setup). I think it's reasonable for the application developer to assume that getServerPort() is going to return 80 and not 8009, because they should conceptually view the entire Apache+Tomcat thing as a single server. I have to disagree with you there. If a request comes to the servlet engine on port 8009 then getServerPort() should return that. It is bad to have Tomcat try and guess where its requests are coming from. And what if Apache+jk is used with unix domain sockets or JNI ? The 8009 is just an implementation detail of something internal. In Apache+jk, the 'container' is Tomcat( java side ) plus at least a small piece of jk. It is an open question if Apache can be considered a part of the 'servlet container' in this case and should abide the rules set by the servlet spec. My answer is no - mostly because the spec sets some mapping rules that just can't match any of the main 3 web servers, and at least IIS is not going to change to follow the servlet spec. So the only practical aproach is to consider the web server is not part of the serlvet container. But mod_jk is IMO a part of the servlet container. Costin I can agree that mod_jk can be seen as part of the servlet container, but I wonder how you are going to fake tomcat into thinking the request came from port 80 when it really came from port 8009 and what other implication / assumptions would occur because of this. As for implementing this, a couple of possibilities: * Include the port number along with the host name (haven't checked if this is already happening) * Add a protocol variable in the JK protocol so that the web server can forward which port number the request was received on. * Add a Connector property saying the port number that should be used for getServerPort() for all requests processed by this connector (the deprecated HttpConnector code had proxyPort for this purpose). If a load balancer or proxy *ahead* of Apache is doing the port shifting, there's not a lot we can do. But we should cover the case for requests that come in to the web server and get forwarded by us. Bojan Craig -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jasper 2 class files
This would be an easy change to JspC so that you could have a flag that would generate package names instead of using the standard package name. If there is any interest in this let me know.. -Original Message- From: Steve Downey [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 21, 2002 8:00 PM To: Tomcat Developers List Subject: RE: Jasper 2 class files However, in the context of JspC, it's a problem to map them to the same package and class name. The custom URLClassLoader works within the JSP engine, but the general servlet class loader doesn't know about those rules. So when it sees those entries in web.xml, it will map all hello.jsp files, no matter where they reside, to org.apache.jsp.hello_jsp. -Original Message- From: Glenn Nielsen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 21, 2002 7:54 PM To: Tomcat Developers List Subject: Re: Jasper 2 class files Yes, you can have two JSP pages with the same name but in different directories and everything will work fine even though they have the same package and class name. This is because a custom URLClassLoader is created for each individual JSP page. That class loader only loads the one java class for that one JSP page. For example: /myapp/this/hello.jsp /muapp/that/hello.jsp The class files will end up in: $CATALINA_BASE/work/Standalone/localhost/myapp/this/hello.class $CATALINA_BASE/work/Standalone/localhost/myapp/that/hello.class Since two different URLClassLoaders are used Jasper can load each of the above two classes even though they have the same package and class name. The old methods Jasper used for loading java classes generated for JSP pages was very inefficient. The above change simplified Jasper and improved its performance by 25%. Regards, Glenn John Trollinger wrote: Greg, I took this off of the bug tracking because it is not a bug and I thought there are people a lot smarter than me in this mailing list that could help answer you questions. I do not know how jasper differentiates between hello.jsp and /anydir/hello.jsp when the both compile to a class org.jasper.jsp.hello_jsp but it does work... My hello.jsp in the root dir prints hello Jasper world and my hello.jsp in the subdir prints hello john world. It works without a hitch.. (notice that I have removed the .java files for the 2 hello world files and it did not regenerate them) Here is my file list Directory of C:\appserver\Tomcat\jspcache 08/21/2002 02:19 PMDIR . 08/21/2002 02:19 PMDIR .. 08/21/2002 11:47 AM 3,496 date_jsp.java 08/21/2002 11:52 AM 2,975 hello_jsp.class 08/21/2002 11:51 AM 2,883 index_jsp.class 08/21/2002 11:51 AM 1,863 index_jsp.java 08/21/2002 01:27 PMDIR subdir 4 File(s) 11,217 bytes Directory of C:\appserver\Tomcat\jspcache\subdir 08/21/2002 01:27 PMDIR . 08/21/2002 01:27 PMDIR .. 08/21/2002 11:47 AM 3,334 date2_jsp.java 08/21/2002 11:52 AM 2,970 hello_jsp.class Here is my jsp.xml !-- Automatically created by Tomcat JspC. Place this fragement in the web.xml before all icon, display-name, description, distributable, and context-param elements. -- servlet servlet-nameorg.apache.jsp.date_jsp/servlet-name servlet-classorg.apache.jsp.date_jsp/servlet-class /servlet servlet servlet-nameorg.apache.jsp.hello_jsp/servlet-name servlet-classorg.apache.jsp.hello_jsp/servlet-class /servlet servlet servlet-nameorg.apache.jsp.date2_jsp/servlet-name servlet-classorg.apache.jsp.date2_jsp/servlet-class /servlet servlet servlet-nameorg.apache.jsp.hello_jsp/servlet-name servlet-classorg.apache.jsp.hello_jsp/servlet-class /servlet servlet-mapping servlet-nameorg.apache.jsp.date_jsp/servlet-name url-pattern/date.jsp/url-pattern /servlet-mapping servlet-mapping servlet-nameorg.apache.jsp.hello_jsp/servlet-name url-pattern/hello.jsp/url-pattern /servlet-mapping servlet-mapping servlet-nameorg.apache.jsp.date2_jsp/servlet-name url-pattern/subdir/date2.jsp/url-pattern /servlet-mapping servlet-mapping servlet-nameorg.apache.jsp.hello_jsp/servlet-name url-pattern/subdir/hello.jsp/url-pattern /servlet-mapping !-- All session-config, mime-mapping, welcome-file-list, error-page, taglib, resource-ref, security-constraint, login-config, security-role, env-entry, and ejb-ref elements should follow this fragment. -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL
getting patches commited
If I add a patch to a bug does the patch still have to be submitted as a patch (via the [patch] subject line) to get into committers hands? Thanks, John -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[patch] jasper2 4.1.9 - fixed the JspC to generate the class files in the right directory structure (bug 11891)
This patch also changes the class file name stuff to eliminate
unnecessary char escaping.
--- old/JspCompilationContext.java 2002-08-21 08:55:23.0 -0400
+++ new/JspCompilationContext.java 2002-08-21 08:35:26.0 -0400
@@ -267,7 +267,7 @@
}
for (int i = iSep; i iEnd; i++) {
char ch = jspUri.charAt(i);
-if (Character.isLetterOrDigit(ch)) {
+if (Character.isJavaIdentifierPart(ch)) {
modifiedClassName.append(ch);
} else if (ch == '.') {
modifiedClassName.append('_');
--- old/JspC.java 2002-08-21 08:55:31.0 -0400
+++ new/JspC.java 2002-08-21 09:19:51.0 -0400
@@ -131,6 +131,8 @@
public static final String SWITCH_WEBAPP_XML = -webxml;
public static final String SWITCH_MAPPED = -mapped;
public static final String SWITCH_DIE = -die;
+public static final String SHOW_SUCCESS =-s;
+public static final String LIST_ERRORS = -l;
public static final int NO_WEBXML = 0;
public static final int INC_WEBXML = 10;
@@ -196,6 +198,9 @@
*/
private TldLocationsCache tldLocationsCache = null;
+private boolean listErrors = false;
+private boolean showSuccess = false;
+
public boolean getKeepGenerated() {
// isn't this why we are running jspc?
return true;
@@ -386,11 +391,11 @@
if (dirset) {
int indexOfSlash = clctxt.getJspFile().lastIndexOf('/');
-String pathName = ;
+ /* String pathName = ;
if (indexOfSlash != -1) {
pathName = clctxt.getJspFile().substring(0, indexOfSlash);
-}
-String tmpDir = outputDir + File.separatorChar + pathName;
+}*/
+String tmpDir = outputDir + File.separatorChar; // + pathName;
File f = new File(tmpDir);
if (!f.exists()) {
f.mkdirs();
@@ -519,6 +524,8 @@
{
try {
String jspUri=file.replace('\\','/');
+String baseDir = scratchDir.getCanonicalPath();
+this.setOutputDir( baseDir + jspUri.substring( 0, jspUri.lastIndexOf( '/'
+) ) );
JspCompilationContext clctxt = new JspCompilationContext
( jspUri, false, this, context, null, null );
@@ -540,6 +547,7 @@
clctxt.setClassPath(classPath);
Compiler clc = clctxt.createCompiler();
+this.setOutputDir( baseDir );
if( compile ) {
// Generate both .class and .java
@@ -556,7 +564,9 @@
// Generate mapping
generateWebMapping( file, clctxt );
-
+if ( showSuccess ) {
+log.println( Built File: + file );
+}
return true;
} catch (FileNotFoundException fne) {
Constants.message(jspc.error.fileDoesNotExist,
@@ -565,7 +575,10 @@
} catch (Exception e) {
Constants.message(jspc.error.generalException,
new Object[] {file, e}, Logger.ERROR);
-if (dieLevel != NO_DIE_LEVEL) {
+if ( listErrors ) {
+ log.println( Error in File: + file );
+ return true;
+ } else if (dieLevel != NO_DIE_LEVEL) {
dieOnExit = true;
}
throw new JasperException( e );
@@ -873,6 +886,10 @@
setUriroot( nextArg());
} else if (tok.equals(SWITCH_FILE_WEBAPP)) {
setUriroot( nextArg());
+} else if ( tok.equals( SHOW_SUCCESS ) ) {
+showSuccess = true;
+} else if ( tok.equals( LIST_ERRORS ) ) {
+listErrors = true;
} else if (tok.equals(SWITCH_WEBAPP_INC)) {
webxmlFile = nextArg();
if (webxmlFile != null) {
@@ -912,6 +929,13 @@
Constants.jasperLog.setVerbosityLevel(verbosityLevel);
}
+/**
+ * allows user to set where the log goes other than System.out
+ * @param log
+ */
+public static void setLog( PrintStream log ) {
+ JspC.log = log;
+}
}
--- old/messages.properties 2002-07-18 19:25:05.0 -0400
+++ new/messages.properties 2002-08-21 08:43:37.0 -0400
@@ -173,6 +173,8 @@
\-v[#] Verbose mode (optional number is level, default is 2)\n\
\-d dirOutput Directory\n\
\-dd dir Literal Output Directory. (package dirs will not be made)\n\
+\-l Outputs the name of the JSP page upon failure\n\
+\-s Outputs the name of the JSP page upon success\n\
\-p name Name of target package\n\
\-c name Name of target class name\n\
\(only applies to first JSP page)\n\
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Jasper 2 class files
Greg, I took this off of the bug tracking because it is not a bug and I thought there are people a lot smarter than me in this mailing list that could help answer you questions. I do not know how jasper differentiates between hello.jsp and /anydir/hello.jsp when the both compile to a class org.jasper.jsp.hello_jsp but it does work... My hello.jsp in the root dir prints hello Jasper world and my hello.jsp in the subdir prints hello john world. It works without a hitch.. (notice that I have removed the .java files for the 2 hello world files and it did not regenerate them) Here is my file list Directory of C:\appserver\Tomcat\jspcache 08/21/2002 02:19 PMDIR . 08/21/2002 02:19 PMDIR .. 08/21/2002 11:47 AM 3,496 date_jsp.java 08/21/2002 11:52 AM 2,975 hello_jsp.class 08/21/2002 11:51 AM 2,883 index_jsp.class 08/21/2002 11:51 AM 1,863 index_jsp.java 08/21/2002 01:27 PMDIR subdir 4 File(s) 11,217 bytes Directory of C:\appserver\Tomcat\jspcache\subdir 08/21/2002 01:27 PMDIR . 08/21/2002 01:27 PMDIR .. 08/21/2002 11:47 AM 3,334 date2_jsp.java 08/21/2002 11:52 AM 2,970 hello_jsp.class Here is my jsp.xml !-- Automatically created by Tomcat JspC. Place this fragement in the web.xml before all icon, display-name, description, distributable, and context-param elements. -- servlet servlet-nameorg.apache.jsp.date_jsp/servlet-name servlet-classorg.apache.jsp.date_jsp/servlet-class /servlet servlet servlet-nameorg.apache.jsp.hello_jsp/servlet-name servlet-classorg.apache.jsp.hello_jsp/servlet-class /servlet servlet servlet-nameorg.apache.jsp.date2_jsp/servlet-name servlet-classorg.apache.jsp.date2_jsp/servlet-class /servlet servlet servlet-nameorg.apache.jsp.hello_jsp/servlet-name servlet-classorg.apache.jsp.hello_jsp/servlet-class /servlet servlet-mapping servlet-nameorg.apache.jsp.date_jsp/servlet-name url-pattern/date.jsp/url-pattern /servlet-mapping servlet-mapping servlet-nameorg.apache.jsp.hello_jsp/servlet-name url-pattern/hello.jsp/url-pattern /servlet-mapping servlet-mapping servlet-nameorg.apache.jsp.date2_jsp/servlet-name url-pattern/subdir/date2.jsp/url-pattern /servlet-mapping servlet-mapping servlet-nameorg.apache.jsp.hello_jsp/servlet-name url-pattern/subdir/hello.jsp/url-pattern /servlet-mapping !-- All session-config, mime-mapping, welcome-file-list, error-page, taglib, resource-ref, security-constraint, login-config, security-role, env-entry, and ejb-ref elements should follow this fragment. -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jasper 2 class files
If you take the generated class files and war them up and just call them as servlets how does the classloader differentiate /org.jasper.jsp.hello_jsp from /subdir/org.jasper.jsp.hello_jsp. I can see how it does it when a JSP file exists but if you just move the generated files over I don't see how the classloader could figure this out? If this is in your web.xml how does it know one hello_jsp from the other without the jsp pages there and without going through jasper? servlet servlet-nameorg.apache.jsp.hello_jsp/servlet-name servlet-classorg.apache.jsp.hello_jsp/servlet-class /servlet servlet-mapping servlet-nameorg.apache.jsp.hello_jsp/servlet-name url-pattern/subdir/hello.jsp/url-pattern /servlet-mapping -Original Message- From: Steve Downey [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 21, 2002 2:56 PM To: Tomcat Developers List Subject: Re: Jasper 2 class files Is jspcache the place that Tomcat is looking for generated classes? If so, then the custom JSP classloader is doing its magic. The java and class files produced by the JspC command line compiler should be able to be jared up and placed into the WEB-INF directory, like any other servlet. And the web.xml then maps the jsp URIs to servlets. Jasper 1 could do this, I provided some of the patches to make it work. The real test is to take all of the output from JspC and create a WAR file from it. Without the base jsp files. This WAR should operate in ANY servlet container. On Wednesday 21 August 2002 02:22 pm, John Trollinger wrote: Greg, I took this off of the bug tracking because it is not a bug and I thought there are people a lot smarter than me in this mailing list that could help answer you questions. I do not know how jasper differentiates between hello.jsp and /anydir/hello.jsp when the both compile to a class org.jasper.jsp.hello_jsp but it does work... My hello.jsp in the root dir prints hello Jasper world and my hello.jsp in the subdir prints hello john world. It works without a hitch.. (notice that I have removed the .java files for the 2 hello world files and it did not regenerate them) Here is my file list Directory of C:\appserver\Tomcat\jspcache 08/21/2002 02:19 PMDIR . 08/21/2002 02:19 PMDIR .. 08/21/2002 11:47 AM 3,496 date_jsp.java 08/21/2002 11:52 AM 2,975 hello_jsp.class 08/21/2002 11:51 AM 2,883 index_jsp.class 08/21/2002 11:51 AM 1,863 index_jsp.java 08/21/2002 01:27 PMDIR subdir 4 File(s) 11,217 bytes Directory of C:\appserver\Tomcat\jspcache\subdir 08/21/2002 01:27 PMDIR . 08/21/2002 01:27 PMDIR .. 08/21/2002 11:47 AM 3,334 date2_jsp.java 08/21/2002 11:52 AM 2,970 hello_jsp.class Here is my jsp.xml !-- Automatically created by Tomcat JspC. Place this fragement in the web.xml before all icon, display-name, description, distributable, and context-param elements. -- servlet servlet-nameorg.apache.jsp.date_jsp/servlet-name servlet-classorg.apache.jsp.date_jsp/servlet-class /servlet servlet servlet-nameorg.apache.jsp.hello_jsp/servlet-name servlet-classorg.apache.jsp.hello_jsp/servlet-class /servlet servlet servlet-nameorg.apache.jsp.date2_jsp/servlet-name servlet-classorg.apache.jsp.date2_jsp/servlet-class /servlet servlet servlet-nameorg.apache.jsp.hello_jsp/servlet-name servlet-classorg.apache.jsp.hello_jsp/servlet-class /servlet servlet-mapping servlet-nameorg.apache.jsp.date_jsp/servlet-name url-pattern/date.jsp/url-pattern /servlet-mapping servlet-mapping servlet-nameorg.apache.jsp.hello_jsp/servlet-name url-pattern/hello.jsp/url-pattern /servlet-mapping servlet-mapping servlet-nameorg.apache.jsp.date2_jsp/servlet-name url-pattern/subdir/date2.jsp/url-pattern /servlet-mapping servlet-mapping servlet-nameorg.apache.jsp.hello_jsp/servlet-name url-pattern/subdir/hello.jsp/url-pattern /servlet-mapping !-- All session-config, mime-mapping, welcome-file-list, error-page, taglib, resource-ref, security-constraint, login-config, security-role, env-entry, and ejb-ref elements should follow this fragment. -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Jasper 2 jspc.bat and JspC.class
I have been working on JspC.java to have it generate the .class files in the same directory structure that the jsp files are in ie /root/dir/test.jsp -- /root/dir/test_jsp.java -- /root/dir/test_jsp.class this is for compiling a webapp vs one file at a time. The problem I have encountered is that the compiler tries to compile a jsp that is used as a Include Directive. This fails the compile. Is there anyway I can detect this as to skip these files. Thanks, John -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JspC / jspc.bat
In trying to use JspC I have noticed that it does not create the .java files the same way Jasper does when going to the page in a browser. I am trying to change this so that they both work the same way (and use as much of the same code as possible for obvious reasons), is anyone else working on this or would anyone like to see it as a patch to Jasper 2 when I am done. If anyone knows why its behavior is like this and that it should not change please let me know as well. Thanks, John Trollinger -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: HttpSession and CTRL-N / File new window
And how do I force all the users of my application to do this? -Original Message- From: Hugh J. L. [mailto:[EMAIL PROTECTED]] Sent: Monday, August 12, 2002 8:23 AM To: Tomcat Developers List Subject: Re: HttpSession and CTRL-N / File new window Launch a new IE from OS, but not a new IE window from current IE. --- John Trollinger [EMAIL PROTECTED] wrote: I have noticed that in IE if you do a CTRL-N to bring up a new window in IE it will have the same session as the currently opened window. Is there anyway around this.. or a way to create a new session in the second window. Thanks, John -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: HttpSession and CTRL-N / File new window
Sorry, I hit the wrong to in address book.. just noticed that :-) -Original Message- From: Ian Darwin [mailto:[EMAIL PROTECTED]] Sent: Monday, August 12, 2002 10:23 AM To: Tomcat Developers List Subject: Re: HttpSession and CTRL-N / File new window On August 12, 2002 08:32 am, you wrote: And how do I force all the users of my application to do this? Use Netscape :-) And please move usage questions to [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PROPOSAL] Split the repo's
[ ] I don't want the API's split into separate repo's [ ] I don't care [X] I want the API's split into separate repo's. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: That Cookie thing
I have to disagree with the default as well.. as that can be dangerous
to someone who simply forgot to supply the path.. this could cause
security issues with where the cookie can be read.. the way is
currently works if you forgot to provide the path a you will find out
quickly that something is not working in the same manor that you did and
can fix it.
-Original Message-
From: John Baker [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 01, 2002 8:33 AM
To: Tomcat Developers List
Subject: Re: That Cookie thing
On Monday 01 July 2002 13:29, Tim Funk wrote:
http://wp.netscape.com/newsref/std/cookie_spec.html
OR
http://www.ietf.org/rfc/rfc2109.txt
OR
http://www.ietf.org/rfc/rfc2965.txt
PATH=path
Optional. The Path attribute specifies the subset of URLs to which
this
cookie applies.
But as IE/Moz/Konqueror (anyone else fancy trying some others?) ignore
this,
would it be more useful to provide a default in some way so it isn't
ignored?
The chances of getting all those three to stick to the spec are low ;-)
Or
even a warning in the logs that your code is not likely to work?
Of course, normally I'd say follow the spec, but sadly if your target
audience doesn't, there isn't really much you can do.
John Baker wrote:
On Monday 01 July 2002 13:16, peter lin wrote:
that's the problem with assumptions :)
Actually I believe the W3C spec says the path will default to
directory
the pages resides in. So that page /hello/greeting.jsp will have
/hello as the path. Only files under /hello can read the
cookie.
Atleast that's my understanding of how cookie path is supposed to be
set. Some one correct me if I am wrong.
Well a reliable source tells me that there is no w3c spec for
Cookies,
and infact the concept was conjured by Netscape. There is an RFC
spec for
Cookies, but it's largely ignored.
So as the useful browsers out there ignore Cookie requests without a
path, it might be handy to add it by default so other people don't
spend
an hour or two sitting there thinking Why doesn't this work?. The
current context path would be handy, so the response code could look
like
this:
public void addCookie(Cookie c)
{
// whatever
if (c.getPath() == null)
c.setPath(getContextPath());
// etc
}
Just a thought :)
peter
John Baker wrote:
On Monday 01 July 2002 12:59, peter lin wrote:
if you want the cookies to be readable by all pages, you should
set it
to /. That's standard practice. Also, if you have multiple
webserver
with names like www1, www2, www3., you should also set the
cookie
to use yourbiz.com.
I know this ;-) But I'd forgotten to put the / there, and assumed
the
browser would assume this if no / was passed to it. However they
don't,
so I was suggesting that if a Cookie has no path set then one
should be
written by default as a totally useless header is currently written
in
the form:
Set-Cookie: someName=someValue; expires
and due to the lack of a path, every browser ignores it.
--
John Baker, BSc CS.
Java Developer, TEAM/Slb. http://www.teamenergy.com
Views expressed in this mail are my own.
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Anyone know a way around this
Generated servlet error:
C:\WEBCTRL2_0\jspcache\testsystem\properties\lvl5\huge$jsp.java:30165:
code too large for try statement
} catch (Throwable t) {
^
C:\WEBCTRL2_0\jspcache\testsystem\properties\lvl5\huge$jsp.java:2969:
code too large for try statement
try {
^
An error occurred at line: 102 in the jsp file:
/testsystem/properties/lvl5/huge.staging.jsp
Generated servlet error:
Note: C:\WEBCTRL2_0\jspcache\testsystem\properties\lvl5\huge$jsp.java
uses or overrides a deprecated API.
Note: Recompile with -deprecation for details.
2 errors
Compile failed; see the compiler error output for details.
at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java)
at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java)
at
org.apache.jasper.compiler.Compiler.compile(Compiler.java:274)
at
org.apache.jasper.JspEngineContext.compile(JspEngineContext.java:385)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja
va:157)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:287)
at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:238)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
e.java:243)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:566)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
72)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
e.java:215)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:566)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authenticator
Base.java:472)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:564)
at
org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.ja
va:246)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:564)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
72)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:236
6)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
:164)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:566)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462
)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:564)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
72)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
java:163)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:566)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
72)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.j
ava:1005)
at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:
1098)
at java.lang.Thread.run(Thread.java:479)
at
org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHa
ndler.java:120)
at
org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.ja
va:293)
at
org.apache.jasper.compiler.Compiler.compile(Compiler.java:291)
at
org.apache.jasper.JspEngineContext.compile(JspEngineContext.java:385)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja
va:157)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:287)
at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:238)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
e.java:243)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja
va:566)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
72)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
RE: HA tomcat ( was: RE: 5.0 proposal)
Although Pier is sometimes harsh with his words he does have some valid points. I would be nice for tomcat to be somewhat modular so if all you want is a servlet engine just get those components. This also goes with moving the CVS repositories.. so you can get only the modules you want and build the parts of tomcat that you need with out all the overhead. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 25, 2002 1:07 PM To: Tomcat Developers List Subject: HA tomcat ( was: RE: 5.0 proposal) On Tue, 25 Jun 2002, GOMEZ Henri wrote: Pier could you detail what should be a Tomcat HA, and how it could fit in TC 5.0 proposal ? As far as I can remember it was voted -1... What about TC 5.0 with HA capability ? TC5.0 will have a 'higher availability' then 4.1 which is better than 4.0. Same goes for 3.3 versus 3.2, and so on. rant -stop reading if you're not interested in flames -- I am trying as hard as possible to remain calm and on the subject when discussing with 'angry' Pier - but the FUD he is using is unbelievable. He can't use tomcat4.0 in production ? Maybe he's trying to do that with mod_webapp ( with no load balancing AFAIK, and 'auto configuration' ). And he complains about features - well, Apache is full of features, and most people know how to not enable the modules that they don't need on a production site. Now he proposes a HA tomcat - as if all our efforts in so far has been in adding useless features and nobody else cares about HA. Well, if you would pay attention a lot of work is beeing put in improving the lb ( an essential factor for HA ), in adding management ( guess what - JMX is not only for configuration, but also for getting runtime info and notifications ), and in improving the low-level objects to beter deal with the load ( that's coyote ) plus for 5.0 a simpler core that would allow more modularity ( coyote again ). And the solution he proposes: removing 'useless' features like jasper or JMX. Well, I know quite a few people who managed to get tomcat in production on a variety of sites ( including very large loads). Even with tomcat3.2 - a generation behind the current 3.3 and 4.0. They do that using load balancing and customizing the installation. Unfortunately Pier's tomcat4.0 doesn't support load balancing, and it seems he's having problems with the admin module of 4.1. Well, send a patch - or just disable the offending module in your code. Tomcat out-of-box is feature full and more intended for developers ( who greatly outnumber the 'production sites'). If you read the 5.0 proposal, it allows ( or includes ) the ability to release customized tomcats. Of course, nobody stops Pier on working on whatever he wants - a -1 means he can't do it in the main branch and he can't use the name 'tomcat', but the proposal/ area has allwasy been open. If he can get a 'higher availability' than we'll get with 5.0 - great, we'll all be happy. But now Pier treatens he'll just leave us oprhapns ( without a father). I certainly hope he's not serious with that, and if he does - I hope he'll return. And in the meantime he may try to learn to be a bit more polite and modest - and control his frustrations. /rant Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PROPOSAL] Minor fix for servletapi-4 GenericServlet
There is another question here. When log() is called no default log level is assigned to it so there is no way to prevent log() messages from cluttering the log files. What about a change to allow the setting of the log level for the log() method in server.xml or web.xml (or even giving it a its own log level) so then all the log() messages can be turned on and off.. -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 12, 2002 3:36 PM To: Tomcat Developers List Subject: Re: [PROPOSAL] Minor fix for servletapi-4 GenericServlet Christopher K. St. John wrote: In the jakarta-servletapi-4 repository, the class: javax.servlet.GenericServlet has init() and destory() methods that call log(). While not specifically prohibited in the 2.3 spec, it results in unncessary output into logs. Also, it's annoying. My proposal is to remove the two log() statements from GenericServet.init() and GenericServlet.destory(). If somebody needs them for debugging, they can add them back into their local copy. This was reported as bug #7190. I've included a patch as an attachment to this message (it just removes the two log messages and updates the copyright date) +1. This sounds reasonable to me. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PROPOSAL] Tomcat 4 System.err/System.out logging
The other problem with logging is that messages logged without a trace level are not given a default trace level so there is no way to stop those messages from being displayed. Why are messages not given a default log level if they are not created with one. John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Glenn Nielsen Sent: Tuesday, May 21, 2002 8:01 AM To: [EMAIL PROTECTED] Subject: [PROPOSAL] Tomcat 4 System.err/System.out logging Problem --- Frequently code running within a web application context will print to System.out, System.err, printStackTrace(), etc. This output ends up getting logged to catalina.out without any timestamps. When you have multiple virtual hosts/contexts it can be a pain to correlate the stack traces and other output in catalina.out with the web application context which generated it. Proposed Solution - 1. Create a JNDI named resource for the ServletContext (java:comp/env/context) scoped to the web application. 2. Create a custom PrintStream object which uses the above JNDI named resource to find which ServletContext to direct output to. If no context is found, it prints to the default System.err and System.out. If a ServletContext is found it uses its log method for output. 3. On Tomcat startup use System.setErr() and System.setOut() to replace the default PrintStream with the above custom PrintStream. Comments, suggestions, and alternate solutions are welcome. :-) Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Communication cross classloaders
Is there anyway for one webapplication to get visablity to classes from a class loader in another web application? Thanks, John Trollinger -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tomcat WebDav servlet and webapp properties
I admit that what I am trying to do is a hack up front, but any help would be great. I am trying make the webdav servlet that comes with tomcat like ftp over port 80. What we want to do is allow people to change files for any webapp deployed by connecting to the webdav webapp. The problem we are having is how fool the webdav servlet into using a different path. For example take a look at the following directory structure Tomcat -- webapps -- appone -- directoryone -- apptwo -- webdav We want the webdav servlet be able to be configured so that it uses the tomcat/webapps/appone/directoryone as the root path when connected to by a webdav client. Is this even posible. Thanks John Trollinger -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat WebDav servlet and webapp properties
Yeah.. It might.. Can you send it over to me.. [EMAIL PROTECTED] Thanks, John -Original Message- From: Nick Sharples [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 16, 2002 10:27 AM To: Tomcat Developers List Subject: Re: Tomcat WebDav servlet and webapp properties John Trollinger writes: I admit that what I am trying to do is a hack up front, but any help would be great. I am trying make the webdav servlet that comes with tomcat like ftp over port 80. What we want to do is allow people to change files for any webapp deployed by connecting to the webdav webapp. The problem we are having is how fool the webdav servlet into using a different path. For example take a look at the following directory structure Tomcat -- webapps -- appone -- directoryone -- apptwo -- webdav We want the webdav servlet be able to be configured so that it uses the tomcat/webapps/appone/directoryone as the root path when connected to by a webdav client. Is this even posible. I hacked up a WebDav solution to a *person webfolder* requirement we had alittle while ago. It's not that clever, all it does is authenticate the user and take them to a personal WebDav folder under the WebDav context. It's a complete hack and not exactly what your after but mail me if you think it would help. ..Nick -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
