remm2002/11/07 00:46:53
Modified:jasper2/src/share/org/apache/jasper Tag: tomcat_4_branch
JspC.java
Log:
- Port patch.
- Change --compile to -compile.
Revision ChangesPath
No revision
No revision
hgomez 2002/11/07 01:16:16
Modified:jk/xdocs/jk quickhowto.xml
Log:
Added documentation for the impatient ;)
Revision ChangesPath
1.4 +59 -37jakarta-tomcat-connectors/jk/xdocs/jk/quickhowto.xml
Index: quickhowto.xml
hgomez 2002/11/07 01:16:24
Modified:jk/xdocs/jk2 confighowto.xml
Log:
Fix typos
Revision ChangesPath
1.3 +22 -22jakarta-tomcat-connectors/jk/xdocs/jk2/confighowto.xml
Index: confighowto.xml
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 propose that:
- In Tomcat 5, all jspc options are removed, in favor of allowing only
the webapp mode (with its
As a user, I agree with Hans Bergsten's comments on the bug database.
Being able to deploy a single war file with all precompiled JSP's to
the
webapp directory is a very useful feature. It would be bad for us if we
weren't
able to do that any longer. (Only thing to remember is to use the
correct
remm2002/11/07 02:51:15
Modified:jasper2/src/share/org/apache/jasper/runtime
PageContextImpl.java
Log:
- Fix Watchdog failures.
Revision ChangesPath
1.32 +6 -4
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 propose that:
- In Tomcat 5, all jspc options are removed, in favor of allowing only
the
jean-frederic clere wrote:
The problem is that keeping the options is where the work has to be
done...
Removing cost (nearly) nothing but brinks nothing.
Probably the vote could be:
[ ] - Remove the options
[ ] - Keep the options _and_ fix them.
I don't really agree, as I think it's just
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 propose that:
- In Tomcat 5, all jspc options are removed, in favor of allowing only
the
hgomez 2002/11/07 03:44:09
Modified:jk/xdocs faq.xml
Log:
Some clarifications about build via configure
Revision ChangesPath
1.6 +14 -1 jakarta-tomcat-connectors/jk/xdocs/faq.xml
Index: faq.xml
Remy Maucherat wrote:
jean-frederic clere wrote:
The problem is that keeping the options is where the work has to be
done...
Removing cost (nearly) nothing but brinks nothing.
Probably the vote could be:
[ ] - Remove the options
[ ] - Keep the options _and_ fix them.
I don't really agree,
Hi Henri,
I have no objection to updating Tomcat 3.3.x. Thanks.
Cheers,
Larry
-Original Message-
From: Henri Gomez [mailto:hgomez;apache.org]
Sent: Wednesday, November 06, 2002 9:41 AM
To: Tomcat Developers List
Subject: New jakarta logo to be included in tomcat 3/4/5 ?
Hi,
Hi,
The new version (still beta) has nice UI interface, and cause of bz2 is
almost 1M less in size.
How it looks can be seen at:
http://apache.mappingsoft.com/download/jakarta-tomcat-4.1.14-LE-jdk14.ex
e
MT.
ntomcat.nsi
Description: Binary data
--
To unsubscribe, e-mail:
Mladen Turk wrote:
Hi,
The new version (still beta) has nice UI interface, and cause of bz2 is
almost 1M less in size.
How it looks can be seen at:
http://apache.mappingsoft.com/download/jakarta-tomcat-4.1.14-LE-jdk14.ex
e
Tomcat 5 is using a NSIS 2 nightly. I don't plan to backport that
hgomez 2002/11/07 05:23:33
Modified:src/doc/images banner.gif
src/doc serverxml.html index.html tomcat-apache-howto.html
tomcat-ug.html mod_jk-howto.html
tomcat-ssl-howto.html Tomcat-on-NetWare-HowTo.html
Log:
Use the
Larry Isaacs wrote:
Hi Henri,
I have no objection to updating Tomcat 3.3.x. Thanks.
Done.
What about TC 4 and 5 ?
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14282.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Mladen Turk wrote:
Hi,
The new version (still beta) has nice UI interface, and cause of bz2 is
almost 1M less in size.
Is the Nullsoft 2.0 the OpenSource installer found under www.nullsoft.com?
How it looks can be seen at:
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
Is the Nullsoft 2.0 the OpenSource installer found under www.nullsoft.com?
http://nsis.sourceforge.net/
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Henri Gomez wrote:
Is the Nullsoft 2.0 the OpenSource installer found under
www.nullsoft.com?
http://nsis.sourceforge.net/
The only problem with NSIS 2 is that the set of macros is changing twice
a day (or close to it).
Remy
--
To unsubscribe, e-mail:
Remy Maucherat wrote:
Henri Gomez wrote:
Is the Nullsoft 2.0 the OpenSource installer found under
www.nullsoft.com?
http://nsis.sourceforge.net/
The only problem with NSIS 2 is that the set of macros is changing twice
a day (or close to it).
Yes it seems ;)
BTW, which version should
http://nsis.sourceforge.net/
The only problem with NSIS 2 is that the set of macros is changing twice
a day (or close to it).
Exact, I tried to remake with alpha7 and got :
MakeNSIS v2.0a7 - Copyright 1999-2002 Nullsoft, Inc.
Portions Copyright (C) 1995-1998 Jean-loup Gailly and Mark Adler
Henri Gomez wrote:
Remy Maucherat wrote:
Henri Gomez wrote:
Is the Nullsoft 2.0 the OpenSource installer found under
www.nullsoft.com?
http://nsis.sourceforge.net/
The only problem with NSIS 2 is that the set of macros is changing
twice a day (or close to it).
Yes it seems ;)
remm2002/11/07 06:40:54
Modified:.tomcat.nsi
Log:
- Upgrade to latest NSIS 2 nightly (arg, I'm sick of it).
- Remove some hacks (the macros are getting less messy).
Revision ChangesPath
1.13 +72 -128 jakarta-tomcat-5/tomcat.nsi
Index: tomcat.nsi
[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
ParserController.java
hgomez 2002/11/07 07:22:31
Modified:jk/native2/common jk_channel_socket.c
Log:
FIONBIO doesn't get set unless BSD_COMP is defined on Solaris 8.
Provided by Paul Brzezinski
Revision ChangesPath
1.42 +3 -0
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13386.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
remm2002/11/07 07:23:43
Modified:jasper2/src/share/org/apache/jasper/xmlparser
XMLEncodingDetector.java
Log:
- This appreas to fix the stack overflow.
Revision ChangesPath
1.2 +1 -1
hgomez 2002/11/07 07:31:01
Modified:jk/native2/common jk_channel_socket.c
Log:
The define should be set before #includes
Revision ChangesPath
1.43 +3 -3 jakarta-tomcat-connectors/jk/native2/common/jk_channel_socket.c
Index: jk_channel_socket.c
Personally don't like hardcoded defines.
Could that be guessed or forced in makefiles?
+/* affects include files on Solaris (for FIONBIO on Solaris 8) */
+#define BSD_COMP
MT.
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands,
Mladen Turk wrote:
Personally don't like hardcoded defines.
me too.
Could that be guessed or forced in makefiles?
I searched thru Apache 2.0.43 source and find these
included by hand in files, but configure specialists
should be able to fix it.
JF ?
--
To unsubscribe, e-mail:
Mladen Turk wrote:
Personally don't like hardcoded defines.
Could that be guessed or forced in makefiles?
It must be guessed in the configure...
+/* affects include files on Solaris (for FIONBIO on Solaris 8) */
+#define BSD_COMP
MT.
--
To unsubscribe, e-mail:
As someone who is actually using jspc ...
- 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
Henri Gomez wrote:
Mladen Turk wrote:
Personally don't like hardcoded defines.
me too.
Could that be guessed or forced in makefiles?
I searched thru Apache 2.0.43 source and find these
included by hand in files, but configure specialists
should be able to fix it.
JF ?
Yes, but
-Original Message-
From: jean-frederic clere
It must be guessed in the configure...
Why? Think we just add the -DBSD_COMP to the JK_CFLAGS in Makefile.in
MT.
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
To clarify - I agree jspc has a lot of broken options and
features. My use case is:
taskdef classname=org.apache.jasper.JspC name=jasper2
classpath
pathelement location=${java.home}/../lib/tools.jar/
fileset dir=${tomcat.home}/server/lib
include name=*.jar/
Mladen Turk wrote:
-Original Message-
From: jean-frederic clere
It must be guessed in the configure...
Why? Think we just add the -DBSD_COMP to the JK_CFLAGS in Makefile.in
Sure but it's not very clean and didn't take use of configure
detection features.
BTW: we'll need to find
Costin Manolache wrote:
To clarify - I agree jspc has a lot of broken options and
features. My use case is:
taskdef classname=org.apache.jasper.JspC name=jasper2
classpath
pathelement location=${java.home}/../lib/tools.jar/
fileset dir=${tomcat.home}/server/lib
Costin Manolache wrote:
To clarify - I agree jspc has a lot of broken options and
features. My use case is:
Removing the CLI or any other options is fine for me. I don't need
jspc to compile or do any fancy thing - just compile JSPs to servlets
and generate the web.xml fragment.
Actually, I
-Original Message-
From: Henri Gomez
Why? Think we just add the -DBSD_COMP to the JK_CFLAGS in
Makefile.in
Sure but it's not very clean and didn't take use of configure
detection features.
BTW: we'll need to find a way to add it to jkant for those
who want to
use ant
What about doing something like this:
#ifdef SOLARIS2 == 8
#define BSD_COMP
#endif
The problem is that the BSD_COMP flag is only needed for ONE of the native
source files for each connector type (JK, JK2). I don't know, haven't
investigated if turning this on activates any other conditional
Mladen Turk wrote:
-Original Message-
From: jean-frederic clere
It must be guessed in the configure...
Why? Think we just add the -DBSD_COMP to the JK_CFLAGS in Makefile.in
Well... I will do nearly the same but in configure.in after testing if needed or
not. (BSD_COMP may break
Mladen Turk wrote:
-Original Message-
From: Henri Gomez
Why? Think we just add the -DBSD_COMP to the JK_CFLAGS in
Makefile.in
Sure but it's not very clean and didn't take use of configure
detection features.
BTW: we'll need to find a way to add it to jkant for those
who want to
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14359.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
What about trying to argue for why an error page returns error code 200?
Martin
-Original Message-
From: Remy Maucherat [mailto:remm;apache.org]
Sent: 07 November 2002 16:10
To: Tomcat Developers List
Subject: Re: [VOTE] Proposed jspc refactoring
Costin Manolache wrote:
To clarify -
remm2002/11/07 08:26:57
Modified:.tomcat.nsi
Log:
- Add back component descriptions.
Revision ChangesPath
1.14 +14 -1 jakarta-tomcat-5/tomcat.nsi
Index: tomcat.nsi
===
RCS file:
I asked an earlier question on the user list regarding silent installs, but
couldn't get an adequate response. I am looking to install Tomcat 4.1.12
silently. Does that functionality exist? I am looking for functionality
similar to the Java silent install listed here:
-Original Message-
From: Henri Gomez
Agreed, but the entire purpose of the ioctl is to disable the
nonblocking socket. We can use the fcntl for that.
So let use it that way, APR is a reference in native code
implementation ;)
I was looking at the docs and see no reason at
BTW, no matter how I look at it, the practice of generating servlets
seems really ugly to me (of course, there are so many ugly things about
JSPs, I guess it's only one of them).
Another big advantage of using JSP - servlet is that you didn't have
security problems of code exposure ;)
--
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10469.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
mturk 2002/11/07 08:46:28
Modified:jk/native2/common jk_channel_socket.c
Log:
There is no need to set the socket to the blocking mode, cause it
is already created as such by default.
Revision ChangesPath
1.44 +10 -4
Henri Gomez wrote:
BTW, no matter how I look at it, the practice of generating servlets
seems really ugly to me (of course, there are so many ugly things
about JSPs, I guess it's only one of them).
Another big advantage of using JSP - servlet is that you didn't have
security problems of
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10469.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Another big advantage of using JSP - servlet is that you didn't have
security problems of code exposure ;)
Hey, stop making fun of me, and get back to work ;-)
Oui patron ;)
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
Hi!
I have on several occations tried to get my patch commited without any
luck, no one have opposed the patch or the actual implementation.
The patch enables the JNDIRealm to connect to a directory server using SSL.
The patch (and docs-patch) can be found in my original post
Remy Maucherat wrote:
Costin Manolache wrote:
To clarify - I agree jspc has a lot of broken options and
features. My use case is:
Removing the CLI or any other options is fine for me. I don't need
jspc to compile or do any fancy thing - just compile JSPs to servlets
and generate the
remm2002/11/07 09:24:37
Modified:catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java
Log:
- Experimental change: add getURI method to properly encode codebase URLs.
Revision ChangesPath
1.11 +25 -8
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
I have a patch as well which I submitted back in June. I haven't received a
response either.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9702
Jon
- Original Message -
From: Fredrik Westermarck [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Thursday, November
remm2002/11/07 10:03:10
Modified:catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java
Log:
- codeBase is a URL (unencoded).
- source is a URI (encoded).
Revision ChangesPath
1.12 +8 -8
On Thu, 7 Nov 2002, Henri Gomez wrote:
Date: Thu, 07 Nov 2002 12:43:45 +0100
From: Henri Gomez [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Subject: Re: [VOTE] Proposed jspc refactoring
Remy Maucherat wrote:
Hi,
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14261.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
luehe 2002/11/07 10:34:19
Modified:jasper2/src/share/org/apache/jasper/compiler
PageDataImpl.java Validator.java
Log:
Append tag directive (containing single 'pageEncoding' attribute whose
value is hard-coded to UTF-8) to XML view of tag files, and
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
Costin Manolache wrote:
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.
jfarcand2002/11/07 11:04:55
Modified:catalina/src/conf catalina.policy
Log:
Revision ChangesPath
1.7 +1 -7 jakarta-tomcat-catalina/catalina/src/conf/catalina.policy
Index: catalina.policy
luehe 2002/11/07 11:09:03
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
Use 'this' qualifier to disambiguate jspContext instance
(e.g., required when invoking fragment from within simple tag).
Revision ChangesPath
1.122 +11 -11
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14261.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
What is the philosophy behind Digester (commons stuff required by Tomcat)
not being in the source release for Tomcat? For people trying to
understand how this all works and needing to know the details, this is a
bit of a runaround. I am sure there is a good reason, but cannot see it.
Micael
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
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14367.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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
For what it's worth, here's how I benefit from jspc on a regular basis.
I'm one of the principal developers of a fairly high-traffic site powered by tomcat
4.1.12.
We use jspc for correctness checking as part of our compile cycle, for two reasons:
a)To enforce valid jsp tag use (required
Hans Bergsten wrote:
Removing the CLI and keeping the basic functionality seems like
a good idea.
CLI as in ...? Sorry, I'm not familar with this acronym.
Command line interface. jspc.sh, main() and the argument processing.
Just use the jspc task in ant. My understanding is that ant's
jfarcand2002/11/07 13:11:40
Modified:jasper2/src/share/org/apache/jasper/runtime
PageContextImpl.java ProtectedFunctionMapper.java
HttpJspBase.java
Log:
Securize the package so it can work under the SecurityManager when the
jfarcand2002/11/07 13:13:06
Modified:jasper2/src/share/org/apache/jasper/servlet
JasperLoader.java
Log:
Securize the package so it can work under the SecurityManager whenthe
org.apache.jasper
s protected. Fix bugs when the JSP 2.0 examples were executed
jfarcand2002/11/07 13:14:53
Modified:jasper2/src/share/org/apache/jasper/compiler
JspRuntimeContext.java
Log:
Securize the package so it can work under the SecurityManager when the
org.apache.jasper
package is protected. Fix bugs when the JSP 2.0 examples
The numbers were suspect because I was running 3.3 under
JBuilder but 4.0 externally, I'd imagine. I set up clean
tomcat trees and ran them outside of any test environment
and I get these numbers: (100 rqs/10 concurrent cx)
TC 4.0.6 | TC 3.3.2
Http11 Http10|
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14372.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
luehe 2002/11/07 14:19:13
Modified:jasper2/src/share/org/apache/jasper/compiler PageInfo.java
ParserController.java Validator.java
jasper2/src/share/org/apache/jasper/resources
messages.properties messages_es.properties
jfarcand2002/11/07 14:52:25
Modified:catalina/src/share/org/apache/catalina/security
SecurityConfig.java
Log:
By default (if the catalina.properties is not founded), do not protect
org.apache.jsp, but org.apache.jasper. org.apache.jsp should not be
What is the philosophy behind Digester (commons stuff required by Tomcat)
not being in the source release for Tomcat? For people trying to
understand how this all works and needing to know the details, this is a
bit of a runaround. I am sure there is a good reason, but cannot see it.
Micael
costin 2002/11/07 15:33:39
Modified:jasper2/src/share/org/apache/jasper/runtime
PageContextImpl.java
Log:
Thanks for the fix. I added the test for newException!=oldException
after testing, just before commit.
The oldException is allways null, since
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12414.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
luehe 2002/11/07 15:52:07
Modified:jasper2/src/share/org/apache/jasper/compiler
JspDocumentParser.java
Log:
Fixed 12414: Tag file defined in XML syntax does not seem to recognize
import attribute in tag directive
Revision ChangesPath
1.25
luehe 2002/11/07 16:55:46
Modified:jasper2/src/share/org/apache/jasper/compiler Validator.java
Log:
Made enumeration of ValidationMessage[] returned by TLV's validate()
method more robust by also considering the case where a
ValidationMessage element might be null.
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 propose that:
- In Tomcat 5, all jspc options are removed, in favor of allowing only
the
I am +1 of refactoring the code and do something less overly complex.
I just have a look at the code and start speaking french. ;-)
I can help if needed.
-- Jeanfrancois
Remy Maucherat wrote:
Hi,
jspc is IMO overly complex, with many features nobody knows how to
use, and nobody cares to
kinman 2002/11/07 19:03:01
Modified:jasper2/src/share/org/apache/jasper/compiler
JspDocumentParser.java PageDataImpl.java
Log:
- Parse EL expressions in JSP page(in XML syntax).
- Output EL expressions in XML view.
Revision ChangesPath
1.26
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14377.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
It turns out TC 4.0.6 has the same auth bug as 3.3--
it challenges prior to redirects. The immediate problem
this causes is that some browsers will cache and send
credentials for the entire domain after being challenged
for a top level directory without a trailing slash.
So 4.0.6 exhibits this
billbarker2002/11/07 22:19:51
Modified:coyote/src/java/org/apache/coyote/tomcat3
Tomcat3Request.java
Log:
Clean up the handling of remoteAddr and remoteHost.
We share both of these with the coyoteRequest, so there is no reason to duplicate.
Revision
billbarker2002/11/07 22:20:59
Modified:coyote/src/java/org/apache/coyote/tomcat3
Tomcat3Adapter.java
Log:
Remember to recycle the request response, even when there is an error.
Revision ChangesPath
1.4 +6 -5
My patches to o.a.c.tomcat3 shouldn't do anything to turn TC3.3+Coyote from
a dog to a cat ;). They are just clean-ups.
Keith seems to have narrowed it down to o.a.c.tomcat3 (since o.a.c.http11 is
shared with Tomcat 4, and the rest of 3.3 is shared with the
Http10Connector). However, I can't
As a non-4.x expert, your patch looks ok. I would guess that it would still
have problems with a request to /foo/protected where the security-constraint
is only for /foo/protected/*.
- Original Message -
From: Keith Wannamaker [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday,
Bill Barker wrote:
As a non-4.x expert, your patch looks ok. I would guess that it would
still
have problems with a request to /foo/protected where the
security-constraint
is only for /foo/protected/*.
I don't agree, the patch is bad for 4.1.x and 5.0 (at least, you must
use the decoded URI
97 matches
Mail list logo
