DO NOT REPLY [Bug 16316] - DataSourceRealm can not find JNDI name in context

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

removes the response wrapper

We have a filter that wraps request and response for every incoming request before any of the application servlets/jsps are invoked. This works well for application code like requestdispatcher.forward and requestdispatcher.include. However, and corresponding implementation in PageContextImpl.jav

cvs commit: jakarta-tomcat-5 build.xml

jfarcand2003/01/22 18:52:47 Modified:.build.xml Log: Oups..fix run-watchdog-security Revision ChangesPath 1.70 +4 -7 jakarta-tomcat-5/build.xml Index: build.xml === RCS file: /home/

cvs commit: jakarta-tomcat-5 build.xml build.properties.default

jfarcand2003/01/22 18:51:27 Modified:.build.xml build.properties.default Log: Re-arrange the watchdog target (was broken). Rename the target run-watchdog. This target will checkout watchdog, compile it, start Tomcat, deploy watchdog and run the test. In build.properties, i

Re: [PROPOSAL] Replace Jasper's logging facility with commons-logging

White, > But would it be a nice idea to use Log 4J through out tomcat? no, we want to preserve the abstraction level provided by commons-logging, which provides support for log4j in addition to other logging packages. Jan > comments.. > Jan Luehe <[EMAIL PROTECTED]> wrote:Jasper currently use

Gump descriptors

Hola a todos: Given that i did the first gump descriptors move, and given the actual status of Gump as a jakarta whole community project ( open to any jakarta committer ) i'l move them back to Gump, if nobody is against.. Saludos, Ignacio J. Ortega -- To unsubscribe, e-mail:

cvs commit: jakarta-tomcat-jasper/jasper2 build.xml

luehe 2003/01/22 15:07:38 Modified:jasper2 build.xml Log: Added org.apache.jasper.compiler.Localizer to jasper-runtime.jar Revision ChangesPath 1.19 +1 -1 jakarta-tomcat-jasper/jasper2/build.xml Index: build.xml

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java

Hans Bergsten wrote: Jeanfrancois Arcand wrote: Hans Bergsten wrote: Jeanfrancois Arcand wrote: [...] We can support runtime package name addition (when the servlet is generated, ask the security manager to protect the package). So it can be optional, i.e. being able to tell jasper t

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java

On Wed, 22 Jan 2003, Hans Bergsten wrote: > Again, I'm only talking about JSPC here; I'm not arguing for removing > the package name that JspServlet adds. > >From a usability perspective, having JSPC work differently (in this regard) from runtime compilation doesn't seem like a good idea. A pa

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java

Jeanfrancois Arcand wrote: Hans Bergsten wrote: Jeanfrancois Arcand wrote: [...] We can support runtime package name addition (when the servlet is generated, ask the security manager to protect the package). So it can be optional, i.e. being able to tell jasper to generate servlet using

java.lang.NoClassDefFoundError: javax/servlet/Filter

Hello, I'm trying to use Filters within Tomcat 4.1.12. When I start Tomcat, however, I get the following error message within the log the Filter pertains to: 2003-01-22 16:11:36 StandardContext[/ws]: Exception starting filter TestFilter java.lang.NoClassDefFoundError: javax/servlet/Filter

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java

Hans Bergsten wrote: Jeanfrancois Arcand wrote: [...] We can support runtime package name addition (when the servlet is generated, ask the security manager to protect the package). So it can be optional, i.e. being able to tell jasper to generate servlet using org.apache.jsp (something co

Re: [proposal] add the apr_queue mechanism to apr_socket

Mladen Turk wrote: > > One more... > > Here is the scenario: > > If TC instance is too busy or reached the connection limit the next > connection is refused, causing entire worker to switch to the error > state. This isn't very smart (at least for threaded servers). > I propose that we use the

RE: [proposal] JK2 (WIN32) add dynamic load balancing

Mladen Turk wrote: > > >> -Original Message- >> > >> > The WIN32 has Performance Monitor that monitors server's activity. >> > There is also and interface to that using Registry >> functions, although >> > the data isn't really stored in the registry. We could use those >> > information

RE: [proposal] JK2 (WIN32) add dynamic load balancing

> -Original Message- > > > > The WIN32 has Performance Monitor that monitors server's activity. > > There is also and interface to that using Registry > functions, although > > the data isn't really stored in the registry. We could use those > > information to select the least loaded

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/xmlparser ParserUtils.java

luehe 2003/01/22 13:13:52 Modified:jasper2/src/share/org/apache/jasper Constants.java JspC.java jasper2/src/share/org/apache/jasper/compiler JspReader.java jasper2/src/share/org/apache/jasper/runtime JspFactoryImpl.java ProtectedFun

Re: cvs commit:jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java

> Date: Wed, 22 Jan 2003 13:20:48 -0600 > From: Glenn Nielsen <[EMAIL PROTECTED]> > Subject: Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java > To: Tomcat Developers List <[EMAIL PROTECTED]> > > > > Kin-Man Chung wrote: > > See below. > > > > > >>Date: Wed,

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties

luehe 2003/01/22 13:06:45 Modified:jasper2/src/share/org/apache/jasper/compiler TagLibraryInfoImpl.java jasper2/src/share/org/apache/jasper/resources messages.properties Log: Minor error code cleanup Revision Chan

Re: [Proposal] Securely sharing sessions between HTTP and HTTPS

One more thing. Given that in the current version of Tomcat the session id created in HTTP mode remains the same when switching to HTTPS, then the a vulnerability similar to that described by Craig is already there. One does not need to switch from HTTPS to HTTP to create a vulnerability, *just*

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java

costin 2003/01/22 12:54:54 Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java Log: Move tag pool initialization to _jspInit - to have access to config info. Revision ChangesPath 1.153 +16 -11 jakarta-tomcat-jasper/jasper2/src/share/org/apache/

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime HttpJspBase.java

costin 2003/01/22 12:52:21 Modified:jasper2/src/share/org/apache/jasper/runtime HttpJspBase.java Log: Added a _jspInit(), following the _jspDestroy() model. Revision ChangesPath 1.10 +5 -1 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/HttpJ

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java

Jeanfrancois Arcand wrote: [...] We can support runtime package name addition (when the servlet is generated, ask the security manager to protect the package). So it can be optional, i.e. being able to tell jasper to generate servlet using org.apache.jsp (something configurable via JMX ;-) ),

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java

Craig R. McClanahan wrote: On Wed, 22 Jan 2003, Hans Bergsten wrote: See my previous mail; you do _not_ need to have a package statement for the generated servlet class. Adding it just complicates life. There is a situation when *not* having the package statement can cause big problems for

Tomcat 4.1.19 stability?

Has Tomcat 4.1.19 been voted on as to its stability yet? Maybe I am too premature on asking this, how soon does a release typically get voted on after it is tagged? I see a few bugs fixed in 4.1.19 that I would like to have in our release, but also I need to have a stable release. Thanks, Jeff

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime TagHandlerPool.java

costin 2003/01/22 12:43:07 Modified:jasper2/src/share/org/apache/jasper/runtime TagHandlerPool.java Log: Another fix. I found how to do the init. Revision ChangesPath 1.6 +17 -11 jakarta-tomcat-jasper/jasper2/src/share/org/apache/ja

Re: [proposal] add the apr_queue mechanism to apr_socket

Mladen Turk wrote: One more... Here is the scenario: If TC instance is too busy or reached the connection limit the next connection is refused, causing entire worker to switch to the error state. This isn't very smart (at least for threaded servers). I propose that we use the apr_queue to sol

Problems with ManagedBean is session replication

Hello, I'm trying to run two tomcat instances on one computer - different ports, with session replication. Both instances will share the following directories: bin/ common/ server/ shared/ For the other directories there are two copies of each, on the folders for the two tomcat instances I'm r

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet JspServlet.java

luehe 2003/01/22 12:39:29 Modified:jasper2/src/share/org/apache/jasper/compiler Compiler.java jasper2/src/share/org/apache/jasper/servlet JspServlet.java Log: more logging-related changes Revision ChangesPath 1.46 +0 -8 jakarta-tomcat-jasper/ja

Re: [proposal] JK2 (WIN32) add dynamic load balancing

Mladen Turk wrote: > Hi guys, > > It's been a long time :-). > > I would like to add the dynamic load balancing to the existing one. > Since I know how to implement that only on WIN platform, I'll elaborate > that a bit. > > The WIN32 has Performance Monitor that monitors server's activity. The

[proposal] add the apr_queue mechanism to apr_socket

One more... Here is the scenario: If TC instance is too busy or reached the connection limit the next connection is refused, causing entire worker to switch to the error state. This isn't very smart (at least for threaded servers). I propose that we use the apr_queue to solve that. The socket wi

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java

On Wed, 22 Jan 2003, Hans Bergsten wrote: > > See my previous mail; you do _not_ need to have a package statement > for the generated servlet class. Adding it just complicates life. > There is a situation when *not* having the package statement can cause big problems for users. The JSP spec do

[proposal] JK2 (WIN32) add dynamic load balancing

Hi guys, It's been a long time :-). I would like to add the dynamic load balancing to the existing one. Since I know how to implement that only on WIN platform, I'll elaborate that a bit. The WIN32 has Performance Monitor that monitors server's activity. There is also and interface to that using

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java

Hans Bergsten wrote: Remy Maucherat wrote: Jeanfrancois Arcand wrote: The only problem I see by removing the package org.apache.jsp is that when Tomcat run under the security manager, it is no longer possible to protect an application from package insertion/access (dangerous). It is st

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/xmlparser ASCIIReader.java ParserUtils.java UTF8Reader.java XercesEncodingDetector.java

luehe 2003/01/22 12:08:25 Modified:jasper2/src/share/org/apache/jasper Constants.java EmbededServletOptions.java JspC.java JspCompilationContext.java jasper2/src/share/org/apache/jasper/compiler Defa

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime TagHandlerPool.java

[EMAIL PROTECTED] wrote: > costin 2003/01/22 11:58:45 > > Modified:jasper2/src/share/org/apache/jasper/runtime > TagHandlerPool.java > Log: > Strange - getServletConfig() returns null. Need help.. This happens because TagHandlerPools are created in the con

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime TagHandlerPool.java

costin 2003/01/22 11:58:45 Modified:jasper2/src/share/org/apache/jasper/runtime TagHandlerPool.java Log: Strange - getServletConfig() returns null. Revision ChangesPath 1.5 +5 -0 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jaspe

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java

costin 2003/01/22 11:55:47 Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java Log: Use the factory method of TagHandlerPool Revision ChangesPath 1.152 +5 -5 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime PerThreadTagHandlerPool.java

costin 2003/01/22 11:54:55 Added: jasper2/src/share/org/apache/jasper/runtime PerThreadTagHandlerPool.java Log: Commit a version of the "per thread" tag pool. Can be plugged in per servlet or per webapp. Revision ChangesPath 1.1

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime TagHandlerPool.java

costin 2003/01/22 11:54:25 Modified:jasper2/src/share/org/apache/jasper/runtime TagHandlerPool.java Log: Few small optimizations ( take expensive operations out of sync ). Added a factory method and a mechanism to configure individual jsps at _runtime_

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java

Remy Maucherat wrote: Jeanfrancois Arcand wrote: The only problem I see by removing the package org.apache.jsp is that when Tomcat run under the security manager, it is no longer possible to protect an application from package insertion/access (dangerous). It is still possible to protect the

removes the response wrapper

We have a filter that wraps request and response for every incoming request before any of the application servlets/jsps are invoked. This works well for application code like requestdispatcher.forward and requestdispatcher.include. However, and corresponding implementation in PageContextImpl.jav

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java

One note, my comments below only apply to the package name for generated classes for those JSP pages compiled at runtime. What package name is used for precompiled JSP pages using JspC.java is not an issue. Glenn Glenn Nielsen wrote: Kin-Man Chung wrote: See below. Date: Wed, 22 Jan 2003

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java

Kin-Man Chung wrote: See below. Date: Wed, 22 Jan 2003 19:03:08 +0100 From: Remy Maucherat <[EMAIL PROTECTED]> Subject: Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java To: Tomcat Developers List <[EMAIL PROTECTED]> Costin Manolache wrote: Remy Mauche

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java

Remy Maucherat wrote: > Jeanfrancois Arcand wrote: >> The only problem I see by removing the package org.apache.jsp is that >> when Tomcat run under the security manager, it is no longer possible to >> protect an application from package insertion/access (dangerous). >> >> It is still possible t

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java

Jeanfrancois Arcand wrote: The only problem I see by removing the package org.apache.jsp is that when Tomcat run under the security manager, it is no longer possible to protect an application from package insertion/access (dangerous). It is still possible to protect the application by manually

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java

The only problem I see by removing the package org.apache.jsp is that when Tomcat run under the security manager, it is no longer possible to protect an application from package insertion/access (dangerous). It is still possible to protect the application by manually adding the new package nam

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java

Hans Bergsten wrote: Remy Maucherat wrote: See my previous mail; you do _not_ need to have a package statement for the generated servlet class. Adding it just complicates life. Ooops, sorry, I'm trying to do plenty of things at once, and misunderstood your reply. I'll remove the org.apache.jsp

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java

remm2003/01/22 11:00:35 Modified:jasper2/src/share/org/apache/jasper JspC.java Log: - Remove the default package. Thanks to Hans for getting me right. Revision ChangesPath 1.26 +4 -4 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java I

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java

Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: Then why not default to the context path ? Can you give examples ? It's very hard to determine the context path from JSPC IMO. I agree. I think the naming conventions for the generated servlets should be settled down, d

Re: cvs commit:jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java

See below. > Date: Wed, 22 Jan 2003 19:03:08 +0100 > From: Remy Maucherat <[EMAIL PROTECTED]> > Subject: Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java > To: Tomcat Developers List <[EMAIL PROTECTED]> > > Costin Manolache wrote: > > Remy Maucherat wrote: > >

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 respon

[Proposal] Securely sharing sessions between HTTP and HTTPS

This is a follow up on Craig's message: http://marc.theaimsgroup.com/?l=tomcat-user&m=104213500528622&w=2 > Consider a scenario where you have "admin" pages that require SSL, and > normal pages that can run on either. Assume Tomcat were modified to > migrate your session back. > > Consider the f

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java

Costin Manolache wrote: Remy Maucherat wrote: Then why not default to the context path ? Can you give examples ? It's very hard to determine the context path from JSPC IMO. I think the naming conventions for the generated servlets should be settled down, documented - and treated as APIs ( i.

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java

Remy Maucherat wrote: > Hans Bergsten wrote: >> [EMAIL PROTECTED] wrote: >> >>> remm2003/01/22 03:40:00 >>> >>> Modified:jasper2/src/share/org/apache/jasper JspC.java >>> Log: >>> - Fix package name generation. >>> - Default to "org.apache.jsp" package name. >> >> >> Why do

DO NOT REPLY [Bug 12196] - request.getRemoteUser() returns null for AJP request with remote username

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 16338] New: - HTML Form Fields not processed correctly with JSP directive

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java

Remy Maucherat wrote: Hans Bergsten wrote: [EMAIL PROTECTED] wrote: remm2003/01/22 03:40:00 Modified:jasper2/src/share/org/apache/jasper JspC.java Log: - Fix package name generation. - Default to "org.apache.jsp" package name. Why do you need a default package name? Do

DO NOT REPLY [Bug 14069] - Ant DeployTask and UndeplyTask causes tomcatAuthentication to be removed from CoyoteConnector settings in server.xml

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java

Hans Bergsten wrote: [EMAIL PROTECTED] wrote: remm2003/01/22 03:40:00 Modified:jasper2/src/share/org/apache/jasper JspC.java Log: - Fix package name generation. - Default to "org.apache.jsp" package name. Why do you need a default package name? Doesn't this make it harder

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspC.java

[EMAIL PROTECTED] wrote: remm2003/01/22 03:40:00 Modified:jasper2/src/share/org/apache/jasper JspC.java Log: - Fix package name generation. - Default to "org.apache.jsp" package name. Why do you need a default package name? Doesn't this make it harder to to use, since the pa

DO NOT REPLY [Bug 15845] - 4.1.19 Memory Leak when creating compilier for JSP pages

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 16335] New: - Setting Jasper logging level to DEBUG causes request.setCharacterencoding() to be ignored

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: Why unpackWars=true default?

Remy Maucherat wrote: Glenn Nielsen wrote: Chris Brown wrote: My main gripe with the unpackWARs setting is that if WARs are unpacked, it makes it more troublesome to upgrade, because a newer version of the WAR file is ignored if any previous version has already been unpacked (until the unpa

RE: Tomcat 5 target JDK1.4?

Sorry if I'm intruding here, I've been following the discussion and I have to say I agree with Costin... What we have here is that due to a JDK14 bug that's preventing our application from working properly we have to stay with JDK131 for now until JDK142 is out. We're trying to move to a newer ve

DO NOT REPLY [Bug 15845] - 4.1.19 Memory Leak when creating compilier for JSP pages

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

RE: Jk connector and security roles (was: DO NOT REPLY [Bug 16253] - Security roles in web.xml do not work with IIS)

Ari, ( many time without posting, readed most of everyone every day, but paycheck commanded me :() > > Btw, I guess that it is impossible to use roles > when one has apache as front end also. > Yes, AFAIK this is the case for Apache too.. and in addition i dont think there is nothin

DO NOT REPLY [Bug 15845] - 4.1.19 Memory Leak when creating compilier for JSP pages

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: Tomcat 5 target JDK1.4?

V. Cekvenich wrote: I'm very happy that Tomcat works well on 1.4, I can't however see any reason to "requiring" 1.4, what are the benefits? Should we artificially create obstacles for the sake of it? Martin Would you be "more" happier if JDK 1.4 made tomcat faster and more stable and have l

Re: Why unpackWars=true default?

Glenn Nielsen wrote: Chris Brown wrote: My main gripe with the unpackWARs setting is that if WARs are unpacked, it makes it more troublesome to upgrade, because a newer version of the WAR file is ignored if any previous version has already been unpacked (until the unpacked files are deleted).

DO NOT REPLY [Bug 15845] - 4.1.19 Memory Leak when creating compilier for JSP pages

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: Why unpackWars=true default?

Chris Brown wrote: My main gripe with the unpackWARs setting is that if WARs are unpacked, it makes it more troublesome to upgrade, because a newer version of the WAR file is ignored if any previous version has already been unpacked (until the unpacked files are deleted). If the WAR file is upd

Re: Precompiled jsps

An offshoot! I have a suggestion wrt to the admin part. Can we make it a bit more user friendly. Wont a web interface help? It wont be too much work since servlets are pretty much there to do the work.One just needs to put it into a few htmls. I also feel it would be nice if one could do a bit of

DO NOT REPLY [Bug 16331] New: - don't override the default port for the channelSocket

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: Tomcat 5 target JDK1.4?

V. Cekvenich wrote: I'm very happy that Tomcat works well on 1.4, I can't however see any reason to "requiring" 1.4, what are the benefits? Should we artificially create obstacles for the sake of it? Martin Would you be "more" happier if JDK 1.4 made tomcat faster and more stable and have l

DO NOT REPLY [Bug 16326] New: - the number of background threads increases

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 15845] - 4.1.19 Memory Leak when creating compilier for JSP pages

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: Tomcat 5 target JDK1.4?

I'm very happy that Tomcat works well on 1.4, I can't however see any reason to "requiring" 1.4, what are the benefits? Should we artificially create obstacles for the sake of it? Martin Would you be "more" happier if JDK 1.4 made tomcat faster and more stable and have less jars, relative to

DO NOT REPLY [Bug 15845] - 4.1.19 Memory Leak when creating compilier for JSP pages

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 15845] - 4.1.19 Memory Leak when creating compilier for JSP pages

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: Precompiled jsps

Costin Manolache wrote: Finally - the precompilation for /admin works, just use ant build-admin-precompile That's pretty cool :) The jsp-examples should be precompiled too ( unless they're intended to show how slow jsp can be on the first request). We have to give Jon arguments ;-) Afte

DO NOT REPLY [Bug 15845] - 4.1.19 Memory Leak when creating compilier for JSP pages

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 15845] - 4.1.19 Memory Leak when creating compilier for JSP pages

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 16323] - Cadaver/RFC 2518 locking incompatibility

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

RE: strange messages in tomcat 4.1.18

I've asked myself this question. (I think) the messages are about a connection being left open (as in "Keep-Alive" and then being closed by the client. I'ts easy to find the where this output is made from in the source. It might be that "INFO" is a tad much for this kind of messages (perhaps "DEB

DO NOT REPLY [Bug 16323] New: - Cadaver/RFC 2518 locking incompatibility

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties

remm2003/01/22 03:55:41 Modified:jasper2/src/share/org/apache/jasper JspC.java jasper2/src/share/org/apache/jasper/resources messages.properties Log: - Remove debug. - Add the compile command line swicth to the help. Revision Changes

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/tagplugins/jstl ForEach.java

remm2003/01/22 03:44:02 Modified:jasper2/src/share/org/apache/jasper/tagplugins/jstl ForEach.java Log: - Fix problem with the type of the loop index. Revision ChangesPath 1.3 +7 -4 jakarta-tomcat-jasper/jasper2/src/share/org/apache/

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java

remm2003/01/22 03:40:00 Modified:jasper2/src/share/org/apache/jasper JspC.java Log: - Fix package name generation. - Default to "org.apache.jsp" package name. Revision ChangesPath 1.24 +12 -6 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.j

DO NOT REPLY [Bug 16319] New: - RequestDispatcher.include in a customTag causes IllegalStateException

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

cvs commit: jakarta-tomcat-5 build.xml

remm2003/01/22 02:23:22 Modified:.build.xml Log: - Sorry Costin, but I disagree with that change. Why make my build environment look like crap just because Gump chose to do so ? Revision ChangesPath 1.68 +1 -1 jakarta-tomcat-5/build.xml Inde

Re: Tomcat 5 target JDK1.4?

I'm very happy that Tomcat works well on 1.4, I can't however see any reason to "requiring" 1.4, what are the benefits? Should we artificially create obstacles for the sake of it? +1 -- To unsubscribe, e-mail: For additional commands, e-mail:

DO NOT REPLY [Bug 16316] - DataSourceRealm can not find JNDI name in context

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 16316] New: - DataSourceRealm can not find JNDI name in context

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

RE: Tomcat 5 target JDK1.4?

> -Original Message- > From: Sean Reilly [mailto:[EMAIL PROTECTED]] > Sent: 21 January 2003 23:37 > To: Tomcat Developers List > Subject: RE: Tomcat 5 target JDK1.4? > > The many other arguments against requiring 1.4 > notwithstanding (and I'm not attempting to refute _any_ of > them

RE: Tomcat 5 target JDK1.4?

> -Original Message- > From: V. Cekvenich [mailto:[EMAIL PROTECTED]] > Sent: 21 January 2003 23:04 > > TC5 is ways of. > And I think everyone can agree that JDK1.4 is more stable than 1.3. I don't agree. Stability is the sum of your whole infrastructure, API, web servers etc etc. Most

Re: Why unpackWars=true default?

To clarify, when I said I "consider" WARs as if they were EXEs, I mean that in many cases I think it's good practice to have a WAR file that doesn't try to modify itself internally (bit like having an EXE or whatever that modifies its contents or self-modifying assembler code...). Some webapps be