Remy,
Remy Maucherat wrote On 09/28/05 03:12,:
[EMAIL PROTECTED] wrote:
+/*
+ * Clear the IntrospectionUtils cache.
+ *
+ * Implementation note:
+ * Any reference to IntrospectionUtils which may cause the static
+ * initalizer of that
Remy,
Remy Maucherat wrote On 09/28/05 10:18,:
Jan Luehe wrote:
We have seen the ThreadDeath in our callstacks, hence this fix.
Nobody is reading what I am writing anymore ...
No, I did.
I wrote:
The static initializer is called when loading the class, and obviously
the webapp CL
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36534.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG
Bill,
[EMAIL PROTECTED] wrote:
billbarker2005/07/20 20:59:10
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
Make certain that release is called for custom tags when tag-pooling is
disabled.
Fix for Bug #35696
Revision ChangesPath
Has anybody ever tried serializing a StandardContext?
StandardContext implements java.io.Serializable, but many
of its fields are not. I assume StandardContext has to
be serializable so it can be transmitted (e.g., via RMI)
to any remote javax.management.NotificationListener
(e.g.,
[Resending as first attempt seemed to have failed]
Has anybody ever tried serializing a StandardContext?
StandardContext implements java.io.Serializable, but many
of its fields are not. I assume StandardContext has to
be serializable so it can be transmitted (e.g., via RMI)
to any remote
[EMAIL PROTECTED] wrote:
remm2005/05/12 06:01:05
Modified:jasper2/src/share/org/apache/jasper/servlet
JspCServletContext.java
webapps/docs changelog.xml
Log:
- 34465: jspc without web.xml.
- Submitted by Yoichi Hirose.
Yoav Shapira wrote:
Hi,
This is just a reminder that I plan to cut and tag Tomcat version 5.5.9
tomorrow, Saturday March 26th, at 1400h my time, which is 1900h UTC/GMT.
Jan, as Remy and you discussed yesterday on the mailing list, please revert
your commit that throws the
Yoav,
Yoav Shapira wrote:
Hola,
My believe is that the above errata will be reflected in the next
(maintenance) release of the servlet spec. I will remind the servlet
spec lead that this needs to happen.
Jan
What's the ETA on this maintenance spec release?
work is supposed to start
Remy Maucherat wrote:
Bill Barker wrote:
- Original Message - From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List tomcat-dev@jakarta.apache.org
Sent: Tuesday, March 22, 2005 1:57 AM
Subject: Re: cvs commit:
Bill/Remy,
Bill Barker wrote:
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List tomcat-dev@jakarta.apache.org
Sent: Wednesday, March 02, 2005 11:56 AM
Subject: Re: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm
Remy,
Remy Maucherat wrote:
Jan Luehe wrote:
Bill/Remy,
But SRV.9.10 (Welcome Files) already has this:
The container may send the request to the welcome resource with
a forward, a redirect, or a container specific mechanism
**that is indistinguishable from a direct request
Bill,
Bill Barker wrote:
- Original Message -
From: Jan Luehe [EMAIL PROTECTED]
To: Tomcat Developers List tomcat-dev@jakarta.apache.org
Sent: Wednesday, March 02, 2005 12:51 PM
Subject: Re: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
luehe 2005/02/23 11:27:56
Modified:catalina/src/share/org/apache/catalina/authenticator
FormAuthenticator.java NonLoginAuthenticator.java
SSLAuthenticator.java SingleSignOn.java
Remy Maucherat wrote:
Jan Luehe wrote:
Remy Maucherat wrote:
Actually, this is probably a bad idea (or at least the implementation is
bad): the logger must be retrieved only when the context class loader of
the application is set.
This is where I'm not following: ;-)
I don't see any
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
luehe 2005/02/18 11:17:57
Modified:catalina/src/share/org/apache/catalina/realm
DataSourceRealm.java JAASCallbackHandler.java
JAASMemoryLoginModule.java JDBCRealm.java
Remy Maucherat wrote:
Jan Luehe wrote:
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
luehe 2005/02/18 11:17:57
Modified:catalina/src/share/org/apache/catalina/realm
DataSourceRealm.java JAASCallbackHandler.java
Remy,
Remy Maucherat wrote:
Jan Luehe wrote:
Remy Maucherat wrote:
I'm still confused. ;-)
Which log messages are supposed to go to LogFactory.getLog(), and which
ones to Container.getLogger()?
For example, in StandardContext.java, we're using LogFactory.getLog()
exclusively. Shouldn't most
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
This patch should fix the issue.
Let me know if you see any problems.
There's the same code (and more) in WebappClassLoader.stop():
// Clear the classloader reference in common-logging
Remy,
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
luehe 2005/02/14 11:27:41
Modified:catalina/src/share/org/apache/catalina/startup
ContextConfig.java LocalStrings.properties
Log:
Use configuration from alt-dd if specified.
(Setter for alt-dd had
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
luehe 2004/11/01 14:38:44
Modified:catalina/src/share/org/apache/catalina/connector
RequestFacade.java LocalStrings.properties
Log:
Throw more meaningful exception (instead of NPE) if underlying request has
Bill Barker wrote:
- Original Message -
From: Jan Luehe [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Monday, November 01, 2004 3:41 PM
Subject: Re: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector
RequestFacade.java
Bill,
Bill Barker wrote:
[EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
luehe 2004/10/27 15:58:17
+
+private Method[] getAllDeclaredMethods(Class c) {
+
+if (c.equals(javax.servlet.http.HttpServlet.class)) {
+return null;
+}
+
+
Actually, in the case of a JSP, we're dealing w/ JspServlet, which is an
instance of HttpServlet.
I've changed the code to return a constant set of methods if the servlet
is not an instance of HttpServlet, avoiding the NPE. :)
My bad. I should pay more attention to Jasper :).
However,
Bill Barker wrote:
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, October 25, 2004 2:18 PM
Subject: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security
SecurityUtil.java
@@ -251,18 +251,17 @@
Remy/Bill,
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
luehe 2004/10/14 17:00:35
Modified:catalina/src/share/org/apache/catalina/core
ApplicationHttpResponse.java
Log:
Expose any errors on an included resource.
For example, a JSP with this include
Hi Amy,
Amy Roh wrote:
I ran the Servlet/JSP TCKs. They both passed on the 5.0.29 release.
The Servlet TCK passed on the 5.5.3 release but the following 2 JSP TCK
tests failed out of 615 tests.
Test case throws exception: [BaseUrlClient] null failed! Check output
for cause of failure.
a..
Hi Remy,
[EMAIL PROTECTED] wrote:
remm2004/10/04 10:39:46
Modified:jasper2/src/share/org/apache/jasper/resources
LocalStrings.properties
jasper2/src/share/org/apache/jasper
EmbeddedServletOptions.java Options.java
Remy Maucherat wrote:
Jan Luehe wrote:
Hi Remy,
[EMAIL PROTECTED] wrote:
remm2004/10/04 10:39:46
Modified:jasper2/src/share/org/apache/jasper/resources
LocalStrings.properties
jasper2/src/share/org/apache/jasper
I feel strongly about this. Dev mode is the default, and is needed for
some special purpose stuff (where JSPs are regenerated on the fly), so
it need to perform relatively well.
IMO, the background reloading thread is way too complex and buggy. It
should go in favor of a much simpler
Remy Maucherat wrote:
Remy Maucherat wrote:
Is it a standalone class or something like this ? If it is - copy
paste into the Jasper code and remove the funky loading logic.
(I thought JDK 1.5 was supposed to include the same Xerces 2 we were
using - what happened ?)
Follow up: the Xerces
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
luehe 2004/09/30 14:57:09
Modified:jasper2/src/share/org/apache/jasper/xmlparser
XMLEncodingDetector.java
Log:
Log warning when XML prolog cannot be parsed.
The 2 JSP TCK failures reported by Jeanfrancois are due
Brian,
Brian Stansberry wrote:
Jan,
At 06:18 PM 9/16/2004 +, you wrote:
luehe 2004/09/16 11:18:41
Modified:catalina/src/share/org/apache/catalina/authenticator
SingleSignOn.java
Log:
- Removed deregister(String ssoid), because it is no longer needed
(used
Brian Stansberry wrote:
Hi Jan,
At 11:02 PM 9/20/2004 +, you wrote:
luehe 2004/09/16 11:18:41
Modified:catalina/src/share/org/apache/catalina/authenticator
SingleSignOn.java
Log:
- Removed deregister(String ssoid), because it is no longer needed
(used to
Hi Tim,
Tim Funk wrote:
This is just a nit, but in JspServlet.serviceJspFile() there is ...
synchronized(this) {
wrapper = (JspServletWrapper) rctxt.getWrapper(jspUri);
if (wrapper == null) {
// Check if the requested JSP page exists,
Remy Maucherat wrote:
ballot
I approve the release plan:
[X] Yes
[ ] No
/ballot
ballot
Tomcat 5.5 should use the following API set for the coding:
[ ] J2SE 1.3
[X] J2SE 1.4
[ ] J2SE 5.0
/ballot
J2SE 5.0 is in beta right now, and there won't be widespread support
for it for a while, so it's
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,
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
+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
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
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:
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
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
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
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
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
[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
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()
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
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
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:
[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
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
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:
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)
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
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
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
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
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
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
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
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
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
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,
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
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 =
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
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
+
+/*
+ * 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
1 - 100 of 136 matches
Mail list logo
