According to JSP.7.4 (The Tag Library Descriptor Format), it is
illegal for a tag to define scripting variables in both its TLD and
TagExtraInfo class.
Jasper already enforces this, but its code generator makes separate
method calls for declaring/synchronizing scripting variables from a
TLD and
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
*/
package org.apache.jasper.runtime;
import javax.servlet.jsp.JspException;
import javax.servlet.jsp.tagext.Tag;
/**
* Pool of tag handlers that can be reused.
*
* @author Jan Luehe
*/
public class
As discussed with Kin-Man, the following patch (for Jasper2)
addresses two issues related to scripting variables exposed by
custom tags (via TagExtraInfo class or TLD):
ISSUE 1:
+++
According to the JSP spec, scripting variables with scope AT_BEGIN
or AT_END are supposed to be visible from
I've noticed the JSP API javadocs at
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jspapi
are out-of-date, and I'm wondering what I need to do in order to sync
them up with the latest API versions at jakarta-servletapi-5.
The JSP API javadocs in the nightly build of the tomcat-docs webapp
Remy/Bill,
Ouch, that's one nasty hack.
-1, please revert it.
There are callbacks to the processor to evaluate the SSL related
attributes. If something is broken, this should be fixed, but using that
pattern. I believe get/setSocket are useless, and the calls should be
entierely removed.
Bill,
SSLAuthenticator makes a request for a special Request attribute
(org.apache.coyote.request.X509Certificate), which fires off an Action
hook (ACTION_REQ_SSL_CERTIFICATE) to renegotiate the handshake if necessary.
I changed TC 5 a little while back to do a lazy-evaluation of the SSL
Remy,
P.S.: I'm also +1 for removing the CertificatesValve, since it is
confusing to have several valves essentially doing the same thing.
There's no need to hardcode the authenticator, you only need to add it
in startup.Authenticators.properties, and it will be added in the
pipeline as
I am fixing a bug filed by Ryan Lubke (Bugtraq 4871238). I do have a fix
in place, but I would like to make sure it's appropriate.
Consider the following scenario: Servlet1 acquires a RequestDispatcher
and forwards the request to Servlet2. However, before forwarding the
request, it wraps the
Remy others,
Here's the list of the components which will need to be released as
stable before Tomcat 5.0 gets stable. I'm associating a proposed owner
for the component, based on past interactions with the components.
- el: Core JSP 2.0 feature; this is a critical component, and needs to
Currently, the limit up to which the size of an
org.apache.coyote.tomcat5.OutputBuffer may grow is identical to the
original buffer size:
public OutputBuffer(int size) {
bb = new ByteChunk(size);
bb.setLimit(size);
...
cb = new CharChunk(size);
Remy,
luehe 2003/07/10 08:51:40
Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteConnector.java CoyoteRequest.java
Log:
Consider CoyoteConnector's bufferSize property when creating
CoyoteRequest objects
Why break the no arg constructor design
Remy,
Jan Luehe wrote:
Currently, the limit up to which the size of an
org.apache.coyote.tomcat5.OutputBuffer may grow is identical to the
original buffer size:
public OutputBuffer(int size) {
bb = new ByteChunk(size);
bb.setLimit(size);
...
cb = new
It can also be useful if you have a client that doesn't support chunked
encoding - which is probably true for a _lot_ of scripting tools.
If there is any other way to have the response not use chunked encoding,
then I agree this is not needed.
Do we still support HTTP/1.0 or some request header to
Marc,
It can also be useful if you have a client that doesn't support chunked
encoding - which is probably true for a _lot_ of scripting tools.
If there is any other way to have the response not use chunked encoding,
then I agree this is not needed.
Do we still support HTTP/1.0 or some request
Hi Costin,
More info:
The page is:
%@ taglib uri=/WEB-INF/struts-logic.tld prefix=logic %
logic:iterate id=id1 name=name1 property=prop1
logic:iterate id=id2 name=name2 property=prop2
Foo
/logic:iterate
/logic:iterate
I get:
a$jsp.java:75:25:75:25: Error:
Hi Costin,
But there is still a problem - now if you have:
logic:iterate id='i'
/logic:iterate
logic:iterate id='i'
/logic:iterate
( i.e. the same variable name ), it will fail with duplicated declaration,
the code will be:
Object i;
...
Object i;
( id is
Costin,
If those variable declaration problems are fixed, I'll release a new
4.1.6 milestone as soon as I can fix the JNDI problems.
Not yet...
I attached the failed jsp.
Costin
[...]
%@ page language=java %
%@
Costin,
- I have a
bean:define id=a name=foo/
The generated code is:
a = (java.lang.Object) pageContext.findAttribute(a);
a = (java.lang.Object) pageContext.findAttribute(a);
a = (java.lang.Object) pageContext.findAttribute(a);
( i.e. 3 times the same line ).
Not a bug, but
Costin,
- I have a
bean:define id=a name=foo/
The generated code is:
a = (java.lang.Object) pageContext.findAttribute(a);
a = (java.lang.Object) pageContext.findAttribute(a);
a = (java.lang.Object) pageContext.findAttribute(a);
( i.e. 3 times the same line ).
Remy,
I'm testing 4.1.10-dev before tagging, and I ran into some serious problems.
Jasper 2 seems broken (in the TC 4 branch; the HEAD/TC 5 branch may be
broken as well, but I didn't have time to test it), and fails to compile
most pages from the admin webapp.
my apologies! When
Costin,
Something like:
logic:iterate id=sub name=scope property=associations
bean:write name=sub property=value/
/logic:iterate
It'll fist generate a duplicated declaration ( once at top level,
once at block level ) for _jspx_sub_1, and then look for a
variable named 'sub' that is
Ralph,
I think there is a serious bug in the jsp compiler from tomcat 4.1.10.
The compiler creates wrong code for nested variables. Here an example
that works with 4.1.9 and does not with 4.1.10
OK, I really think the spec needs to be clarified in this respect.
JSP.10.5.9 (VariableInfo) of
Ralph,
I think there is a serious bug in the jsp compiler from tomcat 4.1.10.
The compiler creates wrong code for nested variables. Here an example
that works with 4.1.9 and does not with 4.1.10
this is now fixed.
Jan
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional
Milt,
Ralph,
I think there is a serious bug in the jsp compiler from tomcat 4.1.10.
The compiler creates wrong code for nested variables. Here an example
that works with 4.1.9 and does not with 4.1.10
this is now fixed.
What version/realease/nightly build is it fixed in?
I
Remy,
[EMAIL PROTECTED] wrote:
luehe 2002/11/06 12:14:20
Modified:jasper2/src/share/org/apache/jasper/compiler
ErrorDispatcher.java JspReader.java JspUtil.java
PageDataImpl.java PageInfo.java
Torsten,
I've applied your patch.
However, I found the following issues with it:
PATCH Content:
Adding handling of init parameter tagPoolSize
Changing Generator to use tagPoolSize for initialize TagHandlerPool
This should, hopefully, be correctly formatted.
Index:
Jim,
Tomcat 4.1.12 does not accept a custom tag with attributes lang
or maxRows. When I asked about this on the Tomcat users list I was
informed that it also does not accept the attribute class.
Specifically if I define those attributes then when the jsp is compiled I
get an unable to find
Ryan,
I think that the following error message is incorrect:
- Scripting elements ( %@, %!, %=, % ) are disallowed here.
Since directives (%@) are not scripting elements.
I've attached a patch to correct the messages.properties.
Thanks for your patch!
I've slightly modified it to
I'd like to resume discussion on a proposal circulated by James
Strachan on March 13, 2002, about turning the implementation of JSTL's
expression language (EL) into a reusable component and moving it from
the Standard Taglib, an implementation of JSTL hosted by
jakarta-taglibs, to jakarta-commons,
Costin,
+1
Is the EL depenent on javax.servlet or javax.servlet.jsp, or is it
completely independent and useable in non-servlet-container environments ?
There are some dependencies on servlet containers. For example, the EL
supports implicit objects, one of them being pageContext, so if you
Dimitry,
In jasper2, I have found one interesting bug. It hapens when tag
implements BodyTag interface and doStartTag returns EVAL_BODY_INCLUDE.
See test-case and patch attached. The patch tested under Tomcat 4.1.18.
the current synchronization behaviour your are seeing is compliant
with
Dimitry,
In jasper2, I have found one interesting bug. It hapens when tag
implements BodyTag interface and doStartTag returns EVAL_BODY_INCLUDE.
See test-case and patch attached. The patch tested under Tomcat 4.1.18.
the current synchronization behaviour your are seeing is
Dimitry:
I still believe your patch is invalid, as it would amount to
synchronizing AT_BEGIN and NESTED variables after calling
doStartTag(). However, the spec explicitly mentions that for tag
handlers implementing BodyTag, those variables must not be
synchronized after doStartTag(), *only* after
Jasper currently uses its own private logging facility implemented
in the org.apache.jasper.logging package. This is inconsistent with
the way the other Tomcat subsystems perform logging
(by leveraging the commons-logging package).
Proposal is to remove org.apache.jasper.logging, and replace
Hans,
Jasper currently uses its own private logging facility implemented
in the org.apache.jasper.logging package. This is inconsistent with
the way the other Tomcat subsystems perform logging
(by leveraging the commons-logging package).
Proposal is to remove
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 uses
+
+/*
+ * Add X-Powered-By header for JSP, if Catalina already
added a
+ * corresponding header for servlets
+ */
+if (response.containsHeader(X-Powered-By)) {
+response.addHeader(X-Powered-By, JSP/2.0);
+}
+
This is a
Remy Maucherat wrote:
BTW, I don't see why the spec saying that the header is optional implies
that the flag must be implemented as something optional. It merely means
that an implementation may ignore completely this feature.
Actually, the Servlet spec is going to say this:
Note that this
Currently, if webapp developers do not want to expose the source of
their JSP files, they have to precompile them and add a servlet
mapping for each JSP to their web.xml (e.g., with the help of jspc).
If the webapp contains a large number of JSPs, the web.xml is going to
grow pretty big.
Would it
Remy,
So I guess we have no choice but make it configurable (or not support
it at all, which I don't think is an option), but since you've agreed
that we should make this a configurable option (provided it is added
at the right places), this is no longer an issue.
I just committed a revised impl
Tim Funk wrote:
How will phantom pages be addressed? Pages where the jsp once existed
but then was deleted, but the corresponding class was not deleted?
That's why I suggested an option for JspServlet that would disable this
optimization and require a servlet mapping for each precompiled JSP.
Arg, what a hack ;-) (and my definition is that we get into the servlet
container; if it's an internal servlet, it seems good enough, and the
page being served was served by a Servlet API 2.4 component)
Come on, this is a stupid feature nobody but marketting cares about (and
I'd say the said
Bill Barker wrote:
+protected TrustManager[] getTrustManagers(String keystoreType)
+throws Exception {
+
+TrustManager[] tm = null;
Don't you need a check for keystoreType == null here?
Yes, thanks, just added one.
Jan
+
+KeyStore trustStore =
Jan Luehe wrote:
Bill Barker wrote:
Just make certain to close bug #19610 after the commit.
Done.
Notice that 19610 also requests the ability to assign different
passwords to each individual key. JSSE currently does not support
this feature via its standard APIs.
I meant: [...] the ability
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
luehe 2003/08/11 14:44:49
+public void setProtocols(String k) {
+setAttribute(protocols, k);
+}
+
This probably should be sslProtocols, no ?
Hmm, but that would make it inconsistent with Http11Protocol's
setProtocol
Bill Barker wrote:
Just make certain to close bug #19610 after the commit.
Done.
Notice that 19610 also requests the ability to assign different
passwords to each individual key. JSSE currently does not support
this feature via its standard APIs.
Jan
- Original Message -
From: Jan
I would like to add support for specifying a keystore alias property
on CoyoteConnector. This will allow control over which (of possible
many) keypair and supporting cert chain the connector is going to
select to authenticate itself to the client during the SSL handshake,
when client auth is
+1. I second what Kin-Man said. :)
Jan
Remy Maucherat wrote:
I'd like to nominate Eric Carmichael as a committer on the Tomcat
project. Eric has been steadily supplying quality patches to the new
Jasper which will implement the JSP 2.0 specification, and has helped
fix outstanding bug
Torsten,
see JSP.8.3 (Semantics of Tag Files), 3rd bullet:
For each invocation to the tag, the JSP Context Wrapper must present a
clean page scope containing no initial elements. All scopes other than
the page scope must be identical to those in the Invoking JSP Context
and must be
I think the current description of the classloader delegation model
from a web application's perspective is still somewhat misleading.
Currently, the document describes this order:
/WEB-INF/classes of your web application
/WEB-INF/lib/*.jar of your web application
Bootstrap classes of
On that topic, is there a reason that Tomcat 5.0.x still uses
commons-logging-api.jar instead of commons-logging.jar? If you're
putting
this jar in common/lib, you'd avoid the need for webapps to have to
include commons-logging.jar themselves in order to use the default
functionality.
Craig,
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
luehe 2003/09/17 16:26:33
Modified:catalina/src/share/org/apache/catalina/core
StandardWrapper.java
Log:
Fix for Bugtraq 4924326 (JMX registrations of servlets that map to
the same jsp-file use the same
Currently, any JARs in the classloader delegation chain of a webapp's
classloader are scanned for packaged TLDs. This is convenient, as it
allows a JAR-packaged taglib to be simply dropped in common/lib and
shared by all webapps, rather than requiring each webapp to bundle the
taglib in its own
(in TldConfig.java), and again in Jasper's TldLocationsCache for
taglibs.
Jan
Yoav Shapira
Millennium ChemInformatics
-Original Message-
From: Jan Luehe [mailto:[EMAIL PROTECTED]
Sent: Monday, September 22, 2003 3:40 PM
To: Tomcat Developers List
Subject: [PROPOSAL] Narrow down the list of JARs
Amy Roh wrote:
The proposal is to add a configurable String property (tldJarNames)
on Context, which specifies the comma-separated list of JAR file names
(without any path info) that must be scanned for TLDs.
+1
Amy :-)
Yeah! Thanks! :)
Jan
Petr,
I haven't committed any changes related to the proposal yet, as I was
waiting for more feedback. The changes I committed in TldConfig.java
were unrelated.
As Jan has already pointed out, it should improve the startup time for
Tomcat 5 (since scanning TLD files is a major hit).
I too
Remy,
sorry, but I don't see which part of our email exchange you found
very frustrating. As I said, I'm open to suggestions, and if my
patch is deemed useless, I'll revert it. No problem.
I've done some measurements on my Ultra 60. TldConfig already
calculates the tldScanTime for each context,
Hans,
thanks for stepping in.
sorry, but I don't see which part of our email exchange you found
very frustrating. As I said, I'm open to suggestions, and if my
patch is deemed useless, I'll revert it. No problem.
[...]
Sorry for not jumping in earlier in this discussion.
When I implemented
Hans,
good point. What about environments that embed Tomcat without following
Tomcat's directory layout, and in which the classloader hierachy/depth
is different from that in Tomcat?
I don't give them that option (with regards to this) in LiteWebServer.
The only place I look for shared
Remy,
As I mentioned in my private email to you, it may not always be
practical to rely on the list of noTldJars configured in
catalina.properties if you bundle Tomcat with your own product. That's
why I added the setProperty method on CatalinaProperties, in order
to be able to override the value
Remy Maucherat wrote:
OK, I'll revert my patch (and leave it as a private extension), until
we have found a better solution that everybody agrees on.
Thanks :)
As for a solution, I believe your hardcoded list was acceptable, if not
completely optimal.
OK, in this case, I'll add that part of
Remy Maucherat wrote:
Jan Luehe wrote:
Remy Maucherat wrote:
As for a solution, I believe your hardcoded list was acceptable, if
not completely optimal.
OK, in this case, I'll add that part of the patch back in, without the
CatalinaProperties.setProperty, which I'll keep as a private
Remy Maucherat wrote:
Jan Luehe wrote:
Remy Maucherat wrote:
As for a solution, I believe your hardcoded list was acceptable, if
not completely optimal.
OK, in this case, I'll add that part of the patch back in, without the
CatalinaProperties.setProperty, which I'll keep as a private
Hans/Remy,
I don't know more than you do about when J2EE 1.4 will be released, but
the specs are starting to move through final approval now, so I'm pretty
sure it will happen in a month or two. Three months for running a few
Beta releases instead of releasing it as something it's not doesn't
Bill,
this.contentType = contentType.substring(0, beginCharsetParam);
-String tail = contentType.substring(beginCharsetParam + 1);
+// Trim the semicolon preceding the charset
+int charsetSemi = this.contentType.lastIndexOf(';');
This is still not working
I may be totally wrong here, but it seems that if the
backgroundProcessorDelay property on a StandardContext is set to
something greater than zero (default is -1, inherited from
ContainerBase), the context's sessions are never purged.
This is because in ContainerBase$ContainerBackgroundProcessor,
Thanks for confirming, Remy!
I'll make these changes.
Jan
Remy Maucherat wrote:
Jan Luehe wrote:
I may be totally wrong here, but it seems that if the
backgroundProcessorDelay property on a StandardContext is set to
something greater than zero (default is -1, inherited from
ContainerBase
Consider the following scenario:
1. Client sends POST request (with content type other than
application/x-www-form-urlencoded) to SSL-enabled server (with
client auth turned off).
2. Server parses request header, and determines that the resource
identified by the request-URI is
Remy Maucherat wrote:
Bill Barker wrote:
[EMAIL PROTECTED] wrote:
luehe 2003/10/30 13:01:39
Modified:util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
Log:
Fixed problem where if maxThreads is set to 1,
ThreadPool.findControlRunnable() will log this error on the first
Remy Maucherat wrote:
Jan Luehe wrote:
Remy Maucherat wrote:
I guess I don't understand what makes 1 bad but 2 OK. Where do we
draw the line of what is a stupid config?
Yes, definitely, 2 is nearly as stupid as 1. We need a reasonable
minimal value for maxThreads; let's say 10 - 20.
Remy,
I
Remy,
I agree we should help users come up with reasonable config values,
but I'm just afraid rejecting any maxThreads 10 or 20 will send the
wrong message, as if there was a bug in the way we dispatch incoming
requests that requires at least 10 threads.
Nope, I disagree. If maxThreads (say)
Bill Barker wrote:
Currently, connector objectname includes address in this format:
domain:type=Connector,port=8080,address=0.0.0.0.
This causes a problem when IPV6 addresses are used since IPV6 addresses
include colons. The javax.management.ObjectName doesn't allow to have
colon character in
Remy Maucherat wrote:
Larry Isaacs wrote:
Hi Jan,
This looked like a good idea, so I ported it to Tomcat 4.1.x.
I'll go ahead and un-port it for consistincy with Tomcat 5.
I thought it was a good idea too. Too bad this has to be unported.
I'll see what I can do to have this fix back in.
Maybe
Patch is attached.
Also, please update jstl.jar and standard.jar in
jakarta-servletapi-5/jsr152/examples/WEB-INF/lib
with their JSTL-1.1 counterparts from
http://www.tux.org/pub/net/apache/dist/jakarta/taglibs/standard/binaries/
Thanks!
Jan
Executing ssh-askpass to query the password...
+1.
Jan
Remy Maucherat wrote:
Hi,
I'd like to nominate Mark Thomas as a Tomcat committer. He has
contibuted a significant amount of fixes already, and does what nobody
else does: roam Bugzila to fix older issues and cleanup the database. He
has special interest in the WebDAV code, which
[For some reason, a commit notification was never sent for this
change i committed last night]
date: 2004/04/07 02:27:47; author: luehe; state: Exp; lines: +18 -18
Fixed problem where when replacing global JspServlet with
webapp-specific one, the wrapper for the global JspServlet (which had
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
luehe 2004/04/07 14:34:12
Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
Log:
When the webapp specific JspServlet inherits the mappings from the
global JspServlet, we need to wipe
Sandy McArthur wrote:
Does this mean J2SE 1.3 support is no more?
On Apr 14, 2004, at 1:45 PM, [EMAIL PROTECTED] wrote:
Log:
Added support for exception chaining.
+iae.initCause(e);
If there is a strong desire to maintain BC with J2SE 1.3,
I'll resort to the JdkCompat
seiji takegata wrote:
Hi,
I'm trying to generate PDF document from JSP, using itext library.
(http://www.lowagie.com/iText/)
I set contentType attribute to get browser open AdobeReader, and
pageEncoding to get right encoding for Japanese characters,
%@ page contentType=application/pdf
Martin,
thanks for reporting the issue, and proposing a patch.
Your patch is consistent with this recommendation in the class comment
of java.net.URLConnection:
Calling the ttclose()/tt methods on the ttInputStream/tt or
ttOutputStream/tt of an ttURLConnection/tt after a request may
free
Hi Remy,
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
luehe 2004/04/21 16:37:07
Modified:catalina/src/share/org/apache/catalina Manager.java
Log:
Expose more of the session management methods at the top-level
Manager interface
This is not a good idea since:
- it changes the
I accidentally committed a wrong log message with my latest commit for
org.apache.jasper.compiler.TagFileProcessor.
Could someone with cvsadmin privileges change the log message for
the head version (revision 1.59) of this file as follows:
cvs admin -m 1.59:Fixed Bugzilla 28937: No error message
+1
Jan
Remy Maucherat wrote:
Hi,
Yoav has expressed interest in being the release manager for Tomcat 5.
Since he has shown interest in nearly all Tomcat components, and
apparently has enough time at the moment, I think he would be the most
qualified to replace me, and has my +1.
Rémy
This fixes an ArrayIndexOutOfBoundsException when superclass does
not declare any methods (see Bugtraq 4968841).
Jan
[EMAIL PROTECTED]'s password:
Warning: Remote host denied X11 forwarding, perhaps xauth program could not be run on
the server side.
Index:
Bill,
luehe 2004/07/27 17:43:17
Modified:coyote/src/java/org/apache/coyote Response.java
Log:
Fixed Bugtraq 6152759 (Default charset not included in Content-Type
response header if no char encoding was specified).
According to the Servlet 2.4 spec, calling:
Remy,
Remy Maucherat wrote:
Remy Maucherat wrote:
Cool. So after all the efforts I'm doing to optimize, you casually add
GC, because the servlet API is completely stupid ?
So -1 for your patch: you need to rework it. I also didn't read all
that funny stuff in the specification, so where does it
Remy,
Remy Maucherat wrote:
Jan Luehe wrote:
Bill,
then I'd suggest simply
doing:
setCharacterEncoding(getCharacterEncoding());
in Response.getWriter (since the spec only requires that we identify the
charset when using a Writer, and we don't really know what it is when
using
OutputStream
Jan Luehe wrote:
Remy,
Remy Maucherat wrote:
Jan Luehe wrote:
Bill,
then I'd suggest simply
doing:
setCharacterEncoding(getCharacterEncoding());
in Response.getWriter (since the spec only requires that we identify
the
charset when using a Writer, and we don't really know what it is
when using
+1
Jan
Remy Maucherat wrote:
Hi,
I'd like to nominate Peter Rossbach pr _at_ objektpark.de as a
committer on the Tomcat project. Peter submitted a significant amount of
useful patches for Tomcat, and wants to contribute more.
He has my +1.
Rémy
Remy Maucherat wrote:
Bill Barker wrote:
- Original Message - From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, August 05, 2004 6:27 PM
Subject: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector
Request.java
luehe 2004/08/05 18:27:50
[EMAIL PROTECTED]
The DateFormat[] passed in from Request.parseDate() is *identical* to
the static formats in FHDF, so why are we not just passing null
from Request.parseDate() and leverage FHDF.formats (instead of having
each Request object provide its own SimpleDateFormat[] instance var)?
Is it
Remy Maucherat wrote:
Jan Luehe wrote:
Agreed.
I stumbled across mem usage as I was running a stress test
under OptimizeIt (and eventually getting OutOfMemory errors from
Servlets), and noticed a large number of char[] instances had been
allocated due to each Request creating its own
[EMAIL PROTECTED] wrote:
luehe 2004/02/03 12:20:19
Modified:jasper2/src/share/org/apache/jasper/compiler
TagLibraryInfoImpl.java
Log:
Convert selected tag attribute types to their Fully-Qualified-Name
equivalents if the taglib is JSP 1.2 based.
This
Jan Luehe wrote:
[EMAIL PROTECTED] wrote:
luehe 2004/02/03 12:20:19
Modified:jasper2/src/share/org/apache/jasper/compiler
TagLibraryInfoImpl.java
Log:
Convert selected tag attribute types to their Fully-Qualified-Name
equivalents if the taglib is JSP 1.2
Is there any interest in making the session id length configurable?
If so, please consider my patch (attached).
Thanks,
Jan
Index: Manager.java
===
RCS file:
Hi Christian,
The 2.3 HttpServletRequest interface provides a setAttribute() method to
change the values of a given attribute. It does NOT however provide a
similar setParameter() method, allowing you to programatically modify the
values that accompany the request - I assume this means that we
Remy Maucherat wrote:
Jan Luehe wrote:
This is a bug. The String[] returned by req.getParameterValues() should
have been a clone.
I just committed a fix.
I'd like to point out that this bug is not worth any performance drop.
You should move those clones to the case where there's a security
Remy Maucherat wrote:
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
luehe 2004/03/10 20:18:31
Modified:catalina/src/share/org/apache/catalina/session
StandardSession.java
Log:
Fixed regression re: Bugtraq 4839736
(HttpSession.setMaxInactiveInterval()
Jeanfrancois Arcand wrote:
Petr Jiricka wrote:
Hi,
I remember there was an issue that the default DD in conf/web.xml was
not valid by the schema - is this change related to that issue?
Yes, this should fix the issue.
Also, with the updated schema, it is now possible to upgrade the
default
Shapira, Yoav wrote:
Hola,
I'm ready to cut 5.0.28 once the JSP folks are done with their work. I
think you guys are actually all done and waiting for me, right? Shall
we say this weekend with Friday as the deadline for committing any code
on the TOMCAT_5_0 branch?
+1.
All Jasper critical bugs,
1 - 100 of 136 matches
Mail list logo
