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

[remm]

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
  
  
  1.12.2.2  +4 -4  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java
  
  Index: JspC.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v
  retrieving revision 1.12.2.1
  retrieving revision 1.12.2.2
  diff -u -r1.12.2.1 -r1.12.2.2
  --- JspC.java 21 Aug 2002 17:54:24 -  1.12.2.1
  +++ JspC.java 7 Nov 2002 08:46:53 -   1.12.2.2
  @@ -123,7 +123,7 @@
   public static final String SWITCH_PACKAGE_NAME = "-p";
   public static final String SWITCH_CLASS_NAME = "-c";
   public static final String SWITCH_FULL_STOP = "--";
  -public static final String SWITCH_COMPILE = "--compile";
  +public static final String SWITCH_COMPILE = "-compile";
   public static final String SWITCH_URI_BASE = "-uribase";
   public static final String SWITCH_URI_ROOT = "-uriroot";
   public static final String SWITCH_FILE_WEBAPP = "-webapp";
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk quickhowto.xml

[hgomez]

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
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/jk/quickhowto.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- quickhowto.xml6 Nov 2002 17:11:27 -   1.3
  +++ quickhowto.xml7 Nov 2002 09:16:15 -   1.4
  @@ -1,18 +1,18 @@
   
   
   
  -Quick Start JK HowTo
  +Quick Start HowTo
   Henri Gomez
   $Date$
   
   
   
 This document describes the configuration files used by JK on the
  -  Tomcat and Web Server side for the impatients:
  +  Web Server side for the 'impatients':
   
   
  -workers.properties is used on the webserver side. For the Apache
  -servers the default path is in the ServerRoot/conf directory.
  +workers.properties is a mandatory file used by the webserver and which
  +is the same for all JK implementations (Apache/IIS/NES).
   
   
   WebServers add-ons to be set on the webserver side. 
  @@ -27,48 +27,45 @@
   
   
   
  -Here is the minimun workers.properties, using just ajp12, ajp13 and 
load-balancing to connect your Apache webserver
  -to the Tomcat engine
  +Here is a minimum workers.properties, using just ajp13 to connect your 
Apache webserver
  +to the Tomcat engine, complete documentation is available in Workers HowTo. 
   
   
   
  -# Define 3 workers, 2 real workers using ajp12, ajp13 and the last one being 
a loadbalancing worker 
  -worker.list=worker1, worker2, worker3
  -# Set properties for worker1 (ajp12)
  -worker.worker1.type=ajp12
  +# Define 1 real worker using ajp13 
  +worker.list=worker1
  +# Set properties for worker1 (ajp13)
  +worker.worker1.type=ajp13
   worker.worker1.host=locahost
  -worker.worker1.port=8007
  -worker.worker1.lbfactor=5
  -# Set properties for worker2 (ajp13)
  -worker.worker2.type=ajp13
  -worker.worker2.host=locahost
  -worker.worker2.port=8009
  -worker.worker2.lbfactor=50
  -worker.worker2.cachesize=10
  -worker.worker2.cache_timeout=600
  -worker.worker2.socket_keepalive=1
  -worker.worker2.socket_timeout=300
  -# Set properties for worker3 (lb) which use worker1 and worker2
  -worker.worker3.balanced_workers=worker1,worker2
  +worker.worker1.port=8009
  +worker.worker1.lbfactor=50
  +worker.worker1.cachesize=10
  +worker.worker1.cache_timeout=600
  +worker.worker1.socket_keepalive=1
  +worker.worker1.socket_timeout=300
   
   
   
   
   
   
  +   Here is a minimun informations about Apache configuration, a 
  +   complete documentation is available in Apache 
HowTo.
  +
  +
You should first have mod_jk.so (unix) or mod_jk.dll (Windows) 
installed
in your Apache module directory (see your Apache documentation to locate it).
   
   
  - Usual locations on Unix:
  + Usual locations for modules directory on Unix:

  - /usr/lib/apache
  - /usr/lib/apache2
  - /usr/local/apache/libexec
  + /usr/lib/apache/
  + /usr/lib/apache2/
  + /usr/local/apache/libexec/

   
   
  - Usual locations on Windows :
  + Usual locations for modules directory on Windows :

C:\Program Files\Apache Group\Apache\modules\
C:\Program Files\Apache Group\Apache2\modules\
  @@ -79,17 +76,35 @@
   
   
   Here is the minimum which should be set in httpd.conf directly or 
  -included from another file, the default path is in the ServerRoot/conf 
directory.
  +included from another file:
  +
  +
  + Usual locations for configuration directory on Unix:
  + 
  + /etc/httpd/conf/
  + /etc/httpd2/conf/
  + /usr/local/apache/conf/
  + 
  +
  +
  + Usual locations for configuration directory on Windows :
  + 
  + C:\Program Files\Apache Group\Apache\conf\
  + C:\Program Files\Apache Group\Apache2\conf\
  + 
   
   
   
   # Load mod_jk module
  +# Update this path to match your modules location
   LoadModulejk_module  libexec/mod_jk.so
   # Declare the module for 
   AddModule mod_jk.c
   # Where to find workers.properties
  +# Update this path to match your conf directory location (put 
workers.properties next to httpd.conf)
   JkWorkersFile /etc/httpd/conf/workers.properties
   # Where to put jk logs
  +# Update this path to match your logs directory location (put mod_jk.log next 
to access_log)
   JkLogFile /var/log/httpd/mod_jk.log
   # Set the jk log level [debug/error/info]
   JkLogLevelinfo
  @@ -99,17 +114,24 @@
   JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
   # JkRequestLogFormat set the request format 
   JkRequestLogFormat "%w %V %T"
  -# Send servlet for context /examples to worker named worker2 (aj

cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk2 confighowto.xml

[hgomez]

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
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/jk2/confighowto.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- confighowto.xml   9 Oct 2002 13:01:29 -   1.2
  +++ confighowto.xml   7 Nov 2002 09:16:24 -   1.3
  @@ -35,7 +35,7 @@
   
   jk2.properties:
   
  -# The default port is 8009 but you can use onother one
  +# The default port is 8009 but you can use another one
   # channelSocket.port=8019
   
   That is all needed on the Tomcat side to configure the JK2.
  @@ -43,7 +43,7 @@
   
   workers2.properties:
   
  -# Define the comunication channel 
  +# Define the communication channel 
   [channel.socket:localhost:8009]
   info=Ajp13 forwarding over socket
   tomcatId=localhost:8009
  @@ -78,30 +78,30 @@
   workers2.properties:
   
   # Define the comunication channel 
  -[channel.jni:jni]
  -info=The jni channel, used if tomcat is started inprocess
  +[channel.jni:jni]
  +info=The jni channel, used if tomcat is started inprocess
   
   # Define the parameters for the Java Virtual Machine
  -[vm:]
  -info=Parameters used to load a JVM in the server process
  
-OPT=-Djava.class.path=${TOMCAT_HOME}/lib/tomcat-jni.jar;${TOMCAT_HOME}/lib/tomcat.jar
  -OPT=-Dtomcat.home=${TOMCAT_HOME}
  -OPT=-Dcatalina.home=${TOMCAT_HOME}
  -OPT=-Xmx128M
  +[vm:]
  +info=Parameters used to load a JVM in the server process
  
+OPT=-Djava.class.path=${TOMCAT_HOME}/lib/tomcat-jni.jar;${TOMCAT_HOME}/lib/tomcat.jar
  +OPT=-Dtomcat.home=${TOMCAT_HOME}
  +OPT=-Dcatalina.home=${TOMCAT_HOME}
  +OPT=-Xmx128M
   
   # JNI worker startup handler
  -[worker.jni:onStartup]
  -info=Command to be executed by the VM on startup. This one will start tomcat.
  -class=org/apache/jk/apr/TomcatStarter
  -ARG=start
  -stdout=${serverRoot}/logs/stdout.log
  -stderr=${serverRoot}/logs/stderr.log
  -
  +[worker.jni:onStartup]
  +info=Command to be executed by the VM on startup. This one will start tomcat.
  +class=org/apache/jk/apr/TomcatStarter
  +ARG=start
  +stdout=${serverRoot}/logs/stdout.log
  +stderr=${serverRoot}/logs/stderr.log
  +
   # JNI worker shutdown handler
  -[worker.jni:onShutdown]
  -info=Command to be executed by the VM on shutdown. This one will stop tomcat.
  -class=org/apache/jk/apr/TomcatStarter
  -ARG=stop
  +[worker.jni:onShutdown]
  +info=Command to be executed by the VM on shutdown. This one will stop tomcat.
  +class=org/apache/jk/apr/TomcatStarter
  +ARG=stop
   
   # Map the Tomcat examples webapp to the Web server uri space
   [uri:/examples/*]
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/xdocs faq.xml

[hgomez]

hgomez  2002/11/07 01:16:35

  Modified:jk/xdocs faq.xml
  Log:
  Update faq
  
  Revision  ChangesPath
  1.5   +6 -1  jakarta-tomcat-connectors/jk/xdocs/faq.xml
  
  Index: faq.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/faq.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- faq.xml   24 Sep 2002 10:23:51 -  1.4
  +++ faq.xml   7 Nov 2002 09:16:35 -   1.5
  @@ -71,6 +71,11 @@
   
   
   
  +
  +
  +For the impatients
  +
  +
   
   Apache and JK
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[VOTE] Proposed jspc refactoring

[Remy Maucherat]

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 relevant options). This webapp mode would 
generate code and classes which should be deployed in the work 
directory, exactly the same as if they were dynamically compiled by 
Jasper (which has the big advantage of using only one big operation mode 
for everything). Single file mode is IMO useless (dynamic compilation 
works fine).
- In Tomcat 4.1, the options will stay in for compatibility, but the 
usage help will be modified to be the same as Tomcat 5.

It has to be noted that:
- The JSP runtime is now very efficient. The old webapp mode (with its 
static web.xml) is a hack (and a 100% proprietary one at that).
- Precompilation should only occur at webapp deployment time in the 
general case (the generated code is closely tied to the Jasper runtime 
release).
- Additional features could be added to the manager servlet to, for 
example, cause precompilation of the deployed webapp in a separate process.
- I am -1 to returning to the old "webapp" option behavior (ie, the 
generated files should by default be deployed in the work directory, not 
/WEB-INF/classes).


+1 [ ] Remove the options
-1 [ ] Do not remove the options


Note: Users may vote, but only committers have binding votes.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Antw: [VOTE] Proposed jspc refactoring

[Sebastian Millies]

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 Jasper 
runtime).

So I'm against the proposal. 


+1 [ ] Remove the options
-1 [ X] Do not remove the options


-- Sebastian




--
Sebastian Millies, IDS Scheer AG
Postfach 10 15 34, 66015 Saarbrücken
Zimmer 2.34,   email: [EMAIL PROTECTED]
fon +49-681-210-3221, fax +49-681-210-1311 
Public Key Fingerprint:
5C70 3E4D 7A13 A9E4 D794 04F4 C80B 34FD 8796 1C50

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[remm]

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  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/PageContextImpl.java
  
  Index: PageContextImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/PageContextImpl.java,v
  retrieving revision 1.31
  retrieving revision 1.32
  diff -u -r1.31 -r1.32
  --- PageContextImpl.java  7 Nov 2002 00:49:53 -   1.31
  +++ PageContextImpl.java  7 Nov 2002 10:51:14 -   1.32
  @@ -581,11 +581,13 @@
   } catch (IllegalStateException ise) {
   include(errorPageURL);
   }
  +
   // The error page could be inside an include.
   
   Object 
newException=request.getAttribute("javax.servlet.error.exception");
   
  -if( (newException!= null) && (newException==origException) ) {
  +if ((origException == null) || 
  +((newException != null) && (newException == origException))) {
   request.removeAttribute("javax.servlet.error.exception");
   }
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[jean-frederic clere]

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 webapp mode (with its relevant options). This webapp mode would 
generate code and classes which should be deployed in the work 
directory, exactly the same as if they were dynamically compiled by 
Jasper (which has the big advantage of using only one big operation mode 
for everything). Single file mode is IMO useless (dynamic compilation 
works fine).
- In Tomcat 4.1, the options will stay in for compatibility, but the 
usage help will be modified to be the same as Tomcat 5.

It has to be noted that:
- The JSP runtime is now very efficient. The old webapp mode (with its 
static web.xml) is a hack (and a 100% proprietary one at that).
- Precompilation should only occur at webapp deployment time in the 
general case (the generated code is closely tied to the Jasper runtime 
release).
- Additional features could be added to the manager servlet to, for 
example, cause precompilation of the deployed webapp in a separate process.
- I am -1 to returning to the old "webapp" option behavior (ie, the 
generated files should by default be deployed in the work directory, not 
/WEB-INF/classes).


+1 [ ] Remove the options
-1 [ ] Do not remove the options



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.



Note: Users may vote, but only committers have binding votes.

Remy


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 







--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Remy Maucherat]

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 too complex for users right 
now (too many useless options).

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Henri Gomez]

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 webapp mode (with its relevant options). This webapp mode would 
generate code and classes which should be deployed in the work 
directory, exactly the same as if they were dynamically compiled by 
Jasper (which has the big advantage of using only one big operation mode 
for everything). Single file mode is IMO useless (dynamic compilation 
works fine).
- In Tomcat 4.1, the options will stay in for compatibility, but the 
usage help will be modified to be the same as Tomcat 5.

I would say that we're extensively JSPC in ant tasks to generate servlet 
(.java), compile via javac and then put all the classes in a .jar which
will be included in the final .war (in lib) which include the jsp 
mapping generated by JSPC.

With this methodology, we're sure that what we deploy on our production
will works (no jsp compilation error on users browser), no time spent in
compilation at runtime, easy deployement since the WAR alleady included
everything.

So what did you means by classes which should be deployed in work 
directory ?

- I am -1 to returning to the old "webapp" option behavior (ie, the 
generated files should by default be deployed in the work directory, not 
/WEB-INF/classes).

It's not my opinion, JSP are nothing more than servlet after all and
why prevent users to have then in WEB-INF/classes or WEB-INF/lib ?

Also consider massive web hosting situation with many tomcats running
the same WebApps (with differents settings and JVM owner).

Having everything in a .war (ie data + precompiled jsp in .class or 
.jar) make life easier for web admins since upgrading a version is just
to replace a .war by a new one.

With your proposed solution, they will have update the war, clean the
work directory (by hand ?) and move the new classes in the work 
directory. Also did Manager/Admin will be updated for such task ?


+1 [ ] Remove the options
-1 [ ] Do not remove the options


Note: Users may vote, but only committers have binding votes.


So I'm -1 on removing the options



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/xdocs faq.xml

[hgomez]

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
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/faq.xml,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- faq.xml   7 Nov 2002 09:16:35 -   1.5
  +++ faq.xml   7 Nov 2002 11:44:09 -   1.6
  @@ -276,6 +276,19 @@
   
   
   
  +
  +
  +configure assume you have some GNU tools allready installed and configured for your 
system, and ad minima libtool.
  +
  +
  +Also some systems may have mixed cc and gcc setup which may make you puzzled when 
trying to link an Apache built with native
  +c compiler with a jk/jk2 build with gcc.
  +
  +
  +In fine some native make didn't works as expect so you should use a GNU make 
gmake.
  +
  +
  +
   
   
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[jean-frederic clere]

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, as I think it's just too complex for users right 
now (too many useless options).

Ok, my vote is:

+1 [X] Remove the options
-1 [ ] Do not remove the options


I have look again in the code ;-)





Remy


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 







--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: New jakarta logo to be included in tomcat 3/4/5 ?

[Larry Isaacs]

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,
> 
> I just updated in jtc/jk docs the jakarta logo by the new one.
> 
> Any objection I do the same for the others tomcat projects ?
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[ADDON] tomcat.nsi for Nullsoft 2.0

[Mladen Turk]

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:   
For additional commands, e-mail: 

Re: [ADDON] tomcat.nsi for Nullsoft 2.0

[Remy Maucherat]

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 
(little functional improvement, so why bother ?).

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat/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

[hgomez]

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 latest jakarta logo...
  
  Revision  ChangesPath
  1.2   +77 -50jakarta-tomcat/src/doc/images/banner.gif
  
<>
  
  
  1.31  +2 -2  jakarta-tomcat/src/doc/serverxml.html
  
  Index: serverxml.html
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/doc/serverxml.html,v
  retrieving revision 1.30
  retrieving revision 1.31
  diff -u -r1.30 -r1.31
  --- serverxml.html3 Nov 2002 02:52:01 -   1.30
  +++ serverxml.html7 Nov 2002 13:23:32 -   1.31
  @@ -18,7 +18,7 @@
 
http://jakarta.apache.org/index.html";>

 
  
  
  
  1.11  +3 -3  jakarta-tomcat/src/doc/index.html
  
  Index: index.html
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/doc/index.html,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- index.html14 Feb 2002 14:25:53 -  1.10
  +++ index.html7 Nov 2002 13:23:32 -   1.11
  @@ -15,8 +15,8 @@
 
   http://jakarta.apache.org/index.html";>
 
   
  
  
  
  1.4   +3 -3  jakarta-tomcat/src/doc/tomcat-apache-howto.html
  
  Index: tomcat-apache-howto.html
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/doc/tomcat-apache-howto.html,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- tomcat-apache-howto.html  9 Feb 2001 04:21:27 -   1.3
  +++ tomcat-apache-howto.html  7 Nov 2002 13:23:32 -   1.4
  @@ -14,8 +14,8 @@
 
   http://jakarta.apache.org/index.html";>
 
   
  
  
  
  1.26  +2 -2  jakarta-tomcat/src/doc/tomcat-ug.html
  
  Index: tomcat-ug.html
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/doc/tomcat-ug.html,v
  retrieving revision 1.25
  retrieving revision 1.26
  diff -u -r1.25 -r1.26
  --- tomcat-ug.html18 Apr 2002 13:58:00 -  1.25
  +++ tomcat-ug.html7 Nov 2002 13:23:32 -   1.26
  @@ -18,7 +18,7 @@
 
http://jakarta.apache.org/index.html";>

 
  
  
  
  1.16  +1 -1  jakarta-tomcat/src/doc/mod_jk-howto.html
  
  Index: mod_jk-howto.html
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/doc/mod_jk-howto.html,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- mod_jk-howto.html 21 Oct 2001 15:28:44 -  1.15
  +++ mod_jk-howto.html 7 Nov 2002 13:23:32 -   1.16
  @@ -36,7 +36,7 @@
   
   
   
  -http://jakarta.apache.org/index.html";>
  +http://jakarta.apache.org/index.html";>
   
   
   
  
  
  
  1.14  +1 -1  jakarta-tomcat/src/doc/tomcat-ssl-howto.html
  
  Index: tomcat-ssl-howto.html
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/doc/tomcat-ssl-howto.html,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- tomcat-ssl-howto.html 6 Jun 2002 19:37:07 -   1.13
  +++ tomcat-ssl-howto.html 7 Nov 2002 13:23:32 -   1.14
  @@ -37,7 +37,7 @@
   
   
   
  -http://jakarta.apache.org/index.html";>
  +http://jakarta.apache.org/index.html";>
   
   
   
  
  
  
  1.5   +1 -1  jakarta-tomcat/src/doc/Tomcat-on-NetWare-HowTo.html
  
  Index: Tomcat-on-NetWare-HowTo.html
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/doc/Tomcat-on-NetWare-HowTo.html,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- Tomcat-on-NetWare-HowTo.html  30 Oct 2001 17:28:31 -  1.4
  +++ Tomcat-on-NetWare-HowTo.html  7 Nov 2002 13:23:32 -   1.5
  @@ -38,7 +38,7 @@
 
   
 http://jakarta.apache.org/index.html";>
  -
  +
 
   
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: New jakarta logo to be included in tomcat 3/4/5 ?

[Henri Gomez]

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:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14282] - mod_jk/ajp13 returns wrong response after bad chunk-encoding request

[bugzilla]

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_bug.cgi?id=14282

mod_jk/ajp13 returns wrong response after bad chunk-encoding request





--- Additional Comments From [EMAIL PROTECTED]  2002-11-07 13:33 ---
There was some fixes recently in the ajp13 java code, 
so could you try with a TC 4 from CVS ?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [ADDON] tomcat.nsi for Nullsoft 2.0

[jean-frederic clere]

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:
http://apache.mappingsoft.com/download/jakarta-tomcat-4.1.14-LE-jdk14.ex
e


MT.





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [VOTE] Proposed jspc refactoring

[John Trollinger]

> 
> 
> +1 [ ] Remove the options
> -1 [X] Do not remove the options
> 

I think some of the options are useless and should go away, but some of
them are (or could be usefull if they worked).

Right now I don't think jspc meets many peoples needs, maybe it is time
to find out the needs of users for jspc and implement those correctly.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [ADDON] tomcat.nsi for Nullsoft 2.0

[Henri Gomez]

Is the Nullsoft 2.0 the OpenSource installer found under www.nullsoft.com?


http://nsis.sourceforge.net/



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [ADDON] tomcat.nsi for Nullsoft 2.0

[Remy Maucherat]

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:   
For additional commands, e-mail: 

Re: [ADDON] tomcat.nsi for Nullsoft 2.0

[Henri Gomez]

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 be used, from alpha0 to alpha7, they're all 
tagged from the same day




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [ADDON] tomcat.nsi for Nullsoft 2.0

[Henri Gomez]

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 (zlib).
Includes portions derived from bzip2 (see documentation for details).
Contributors: [EMAIL PROTECTED], Ryan Geiss, Andras Varga, Drew Davidson, 
Peter Windridge, Dave Laundon, Robert Rainwater, Yaroslav Faybishenko, 
Jeff Doozan, Amir Szekely, et al.


Processing plugin dlls: "C:\Program Files\NSIS\plugins\*.dll"
 - InstallOptions.dll::dialog
 - LangDLL.dll::LangDialog
 - nsisdl.dll::download
 - nsisdl.dll::download_quiet
SetCompressor: bzip2


Processing config:
Changing directory to: "D:"


Processing script file: "D:\ntomcat.nsi"
!define: "MUI_PRODUCT"="Apache Tomcat"
!define: "MUI_VERSION"="4.1.14"
!define: "MUI_NAME"="Apache Tomcat Install System 4.1.14"
!define: "VER_MAJOR"="4.1"
!define: "VER_MINOR"="14"
OutFile: "jakarta-tomcat-4.1.14-LE-jdk14.exe"
SetCompressor: bzip2
!include: "C:\Program Files\NSIS\Contrib\Modern UI\System.nsh"
!include: could not open file: "C:\Program Files\NSIS\Contrib\Modern 
UI\System.nsh"
Error in script "D:\ntomcat.nsi" on line 17 -- aborting creation process





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [ADDON] tomcat.nsi for Nullsoft 2.0

[Remy Maucherat]

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 ;)

BTW, which version should be used, from alpha0 to alpha7, they're all
tagged from the same day


Every other week, I upgrade to the latest nightly (there's a CVS build 
on the website). alpha 7 is waaay out of date.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-5 tomcat.nsi

[remm]

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
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/tomcat.nsi,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- tomcat.nsi29 Oct 2002 11:22:49 -  1.12
  +++ tomcat.nsi7 Nov 2002 14:40:54 -   1.13
  @@ -2,8 +2,10 @@
   ; Tomcat script for Nullsoft Installer
   ; $Id$
   
  -!define NAME "Apache Tomcat"
  -!define VERSION "@VERSION@"
  +!define MUI_PRODUCT "Apache Tomcat"
  +!define MUI_VERSION "@VERSION@"
  +
  +!define MUI_NAME "${MUI_PRODUCT} ${MUI_VERSION}"
   
   !include "${NSISDIR}\Contrib\Modern UI\System.nsh"
   
  @@ -13,24 +15,21 @@
 !define MUI_INSTALLOPTIONS
   
 !define MUI_LICENSEPAGE
  -  !define MUI_COMPONENTPAGE
  -  !define MUI_DIRSELECTPAGE
  -  !define MUI_INSTALLBUTTONTEXT_NEXT
  +  !define MUI_COMPONENTSPAGE
  +  !define MUI_DIRECTORYPAGE
 !define MUI_ABORTWARNING
 !define MUI_UNINSTALLER
   
  -  !define MUI_SETPAGE_FUNCTIONNAME "SetPage"
  -  !define MUI_UNSETPAGE_FUNCTIONNAME "un.SetPage"
  +  !define MUI_CUSTOMPAGECOMMANDS
  +
  +  !define TEMP1 $R0
  +  !define TEMP2 $R1
   
 ;Language
  -;English
  -LoadLanguageFile "${NSISDIR}\Contrib\Language files\English.nlf"
  -!include "${NSISDIR}\Contrib\Modern UI\Language files\English.nsh"
  +  !insertmacro MUI_LANGUAGE "English"
   
 ;General
  -  Name "${NAME} ${VERSION}"
 OutFile tomcat-installer.exe
  -  BrandingText "${NAME} ${VERSION} Installer"
   
 ;Compression options
 CRCCheck on
  @@ -38,15 +37,39 @@
 SetCompressor bzip2
 SetDatablockOptimize on
   
  -  !insertmacro MUI_INTERFACE
  -  !insertmacro MUI_INSTALLOPTIONS "$7" "$8"
  +  ;Page order
  +  !insertmacro MUI_PAGECOMMAND_LICENSE
  +  !insertmacro MUI_PAGECOMMAND_COMPONENTS
  +  !insertmacro MUI_PAGECOMMAND_DIRECTORY
  +  Page custom SetConfiguration
  +  Page custom SetChooseJVM
  +  !insertmacro MUI_PAGECOMMAND_INSTFILES
   
 ;License dialog
 LicenseData INSTALLLICENSE
   
  +  ;Component-selection page
  +;Descriptions
  +LangString DESC_SecTomcat ${LANG_ENGLISH} "Install the Tomcat Servlet 
container."
  +LangString DESC_SecTomcatCore ${LANG_ENGLISH} "Install the Tomcat Servlet 
container core."
  +LangString DESC_SecTomcatService ${LANG_ENGLISH} "Install the Tomcat service, 
used to automatically start Tomcat in the background when the computer is started. 
This requires Windows NT 4.0, Windows 2000 or Windows XP."
  +LangString DESC_SecTomcatSource ${LANG_ENGLISH} "Install the Tomcat source 
code."
  +LangString DESC_SecTomcatDocs ${LANG_ENGLISH} "Install the Tomcat documentation 
bundle. This include documentation on the servlet container and its configuration 
options, on the Jasper JSP page compiler, as well as on the native webserver 
connectors."
  +LangString DESC_SecMenu ${LANG_ENGLISH} "Create a Start Menu program group for 
Tomcat."
  +LangString DESC_SecExamples ${LANG_ENGLISH} "Installs some examples web 
applications."
  +
 ;Folder-select dialog
 InstallDir "$PROGRAMFILES\Apache Group\Tomcat 5.0"
   
  +  ;Install Options pages
  +  LangString TEXT_JVM_TITLE ${LANG_ENGLISH} "Java Virtual Machine"
  +  LangString TEXT_JVM_SUBTITLE ${LANG_ENGLISH} "Java Virtual Machine path 
selection."
  +  LangString TEXT_JVM_PAGETITLE ${LANG_ENGLISH} "Java Virtual Machine path 
selection"
  +
  +  LangString TEXT_CONF_TITLE ${LANG_ENGLISH} "Configuration"
  +  LangString TEXT_CONF_SUBTITLE ${LANG_ENGLISH} "Tomcat basic configuration."
  +  LangString TEXT_CONF_PAGETITLE ${LANG_ENGLISH} "Tomcat 5 Configuration Options"
  +
 ;Install types
 InstType Normal
 InstType Minimum
  @@ -55,16 +78,31 @@
 ; Main registry key
 InstallDirRegKey HKLM "SOFTWARE\Apache Group\Tomcat\5.0" ""
   
  +  ;Uninstaller
  +  !define MUI_UNCUSTOMPAGECOMMANDS
  +  !insertmacro MUI_UNPAGECOMMAND_CONFIRM
  +  !insertmacro MUI_UNPAGECOMMAND_INSTFILES
  +
 ReserveFile "${NSISDIR}\Plugins\InstallOptions.dll"
 ReserveFile "jvm.ini"
 ReserveFile "config.ini"
   
  +;
  +;Modern UI System
  +
  +!insertmacro MUI_SYSTEM
  +
  +;
  +;Installer Sections
  +
   SubSection "Tomcat" SecTomcat
   
   Section "Core" SecTomcatCore
   
 SectionIn 1 2 3
   
  +  Call checkJvm
  +
 SetOutPath $INSTDIR
 File tomcat.ico
 File LICENSE
  @@ -179,12 +217,7 @@
   
   SectionEnd
   
  -Section ""
  -
  -  ;Invisible section to display the Finish header
  -  !insertmacro MUI_FINISHHEADER
  -
  -SectionEnd
  +!insertmacro MUI_SECTIONS_FINISHHEADER
   
   Section -post
   
  @@ -206,123 +239,39 @@

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/xmlparserASCIIReader.java UCSReader.java UTF8Reader.java XMLEncodingDetector.java

[Remy Maucherat]

[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 Validator.java
   jasper2/src/share/org/apache/jasper/resources
messages.properties messages_es.properties
messages_ja.properties
  Added:   jasper2/src/share/org/apache/jasper/xmlparser
ASCIIReader.java UCSReader.java UTF8Reader.java
XMLEncodingDetector.java
  Log:
  First cut at I18N changes.
  

There are problems with that patch:

- What does it do ?

- It seems like a big change, was it discussed before on the list ?

- Trying to access the admin webapp:
java.lang.StackOverflowError
	at org.apache.jasper.xmlparser.UTF8Reader.read(UTF8Reader.java:293)
	at 
org.apache.jasper.xmlparser.XMLEncodingDetector.load(XMLEncodingDetector.java:1041)
	at 
org.apache.jasper.xmlparser.XMLEncodingDetector.load(XMLEncodingDetector.java:1065)
	at 
org.apache.jasper.xmlparser.XMLEncodingDetector.load(XMLEncodingDetector.java:1065)
(you get the idea)

Thanks,
Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_socket.c

[hgomez]

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  jakarta-tomcat-connectors/jk/native2/common/jk_channel_socket.c
  
  Index: jk_channel_socket.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_socket.c,v
  retrieving revision 1.41
  retrieving revision 1.42
  diff -u -r1.41 -r1.42
  --- jk_channel_socket.c   28 Sep 2002 20:06:19 -  1.41
  +++ jk_channel_socket.c   7 Nov 2002 15:22:31 -   1.42
  @@ -83,6 +83,9 @@
   #define closesocket close
   #endif
   
  +/* affects include files on Solaris (for FIONBIO on Solaris 8) */
  +#define BSD_COMP
  +
   #define DEFAULT_HOST "127.0.0.1"
   
   /** Information specific for the socket channel
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 13386] - JK2 connector for Apache2: missing -DBSD_COMP for C compiler

[bugzilla]

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_bug.cgi?id=13386

JK2 connector for Apache2: missing -DBSD_COMP for C compiler

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-11-07 15:24 ---
Added the BSD_COMP.

in Apache 2, support/ab.c and test/zb.c include the BSD_COMP

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[remm]

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  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/xmlparser/XMLEncodingDetector.java
  
  Index: XMLEncodingDetector.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/xmlparser/XMLEncodingDetector.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- XMLEncodingDetector.java  6 Nov 2002 20:14:20 -   1.1
  +++ XMLEncodingDetector.java  7 Nov 2002 15:23:43 -   1.2
  @@ -1062,7 +1062,7 @@
}
// handle the trailing edges
if (fCurrentEntity.position == fCurrentEntity.count) {
  - load(0, true);
  + load(0, false);
}
}
}
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_socket.c

[hgomez]

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
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_socket.c,v
  retrieving revision 1.42
  retrieving revision 1.43
  diff -u -r1.42 -r1.43
  --- jk_channel_socket.c   7 Nov 2002 15:22:31 -   1.42
  +++ jk_channel_socket.c   7 Nov 2002 15:31:01 -   1.43
  @@ -71,6 +71,9 @@
* @author: Costin Manolache
*/
   
  +/* affects include files on Solaris (for FIONBIO on Solaris 8) */
  +#define BSD_COMP
  +
   #include "jk_map.h"
   #include "jk_env.h"
   #include "jk_channel.h"
  @@ -82,9 +85,6 @@
   #ifndef WIN32
   #define closesocket close
   #endif
  -
  -/* affects include files on Solaris (for FIONBIO on Solaris 8) */
  -#define BSD_COMP
   
   #define DEFAULT_HOST "127.0.0.1"
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_socket.c

[Mladen Turk]

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:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_socket.c

[Henri Gomez]

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:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_socket.c

[jean-frederic clere]

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:   
For additional commands, e-mail: 







--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Costin Manolache]

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 dynamically compiled by
> Jasper (which has the big advantage of using only one big operation mode
> for everything). Single file mode is IMO useless (dynamic compilation
> works fine).

-1

I actually need real java classes, with a package name I can customize 
and deployed in an arbitrary directory  (outside tomcat tree).


> It has to be noted that:
> - The JSP runtime is now very efficient. The old webapp mode (with its
> static web.xml) is a hack (and a 100% proprietary one at that).

Not sure which 'webapp mode', but generating the web.xml fragment is
an essential feature and 100% standard - it translates JSPs to servlets
and generates the web.xml declarations. After the operation you'll have
very servlets in a standard web.xml.

As for jasper runtime - it can be included in the webapp ( just like any
library ). AFAIK the runtime doesn't depend on tomcat.

> - Precompilation should only occur at webapp deployment time in the
> general case (the generated code is closely tied to the Jasper runtime
> release).

I need precompilation at build time - the distributed .war will have only
servlets.

> - Additional features could be added to the manager servlet to, for
> example, cause precompilation of the deployed webapp in a separate
> process. - I am -1 to returning to the old "webapp" option behavior (ie,
> the generated files should by default be deployed in the work directory,
> not /WEB-INF/classes).

Again, I must -1 this too.



> 
> 
> +1 [ ] Remove the options
> -1 [X] Do not remove the options
> 

I agree jspc needs some refactoring - and only the 'webapp' mode should
be preserved, but I think my use case is valid and should be preserved.

At the moment I only use jasper inside ant - so removing the CLI completely,
removing the javac compilation and so on would be fine ( for me ).

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_socket.c

[jean-frederic clere]

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 FIONBIO does not exist everywhere so we need more than checking for 
FIONBIO. I will have a look.




--
To unsubscribe, e-mail:   

For additional commands, e-mail: 







--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_socket.c

[Mladen Turk]

> -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:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Costin Manolache]

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.

Costin

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 webapp mode (with its relevant options). This webapp mode would
> generate code and classes which should be deployed in the work
> directory, exactly the same as if they were dynamically compiled by
> Jasper (which has the big advantage of using only one big operation mode
> for everything). Single file mode is IMO useless (dynamic compilation
> works fine).
> - In Tomcat 4.1, the options will stay in for compatibility, but the
> usage help will be modified to be the same as Tomcat 5.
> 
> It has to be noted that:
> - The JSP runtime is now very efficient. The old webapp mode (with its
> static web.xml) is a hack (and a 100% proprietary one at that).
> - Precompilation should only occur at webapp deployment time in the
> general case (the generated code is closely tied to the Jasper runtime
> release).
> - Additional features could be added to the manager servlet to, for
> example, cause precompilation of the deployed webapp in a separate
> process. - I am -1 to returning to the old "webapp" option behavior (ie,
> the generated files should by default be deployed in the work directory,
> not /WEB-INF/classes).
> 
> 
> +1 [ ] Remove the options
> -1 [ ] Do not remove the options
> 
> 
> Note: Users may vote, but only committers have binding votes.
> 
> Remy




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_socket.c

[Henri Gomez]

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 a way to add it to jkant for those who want to 
use ant to build native code ;{



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Henri Gomez]

Costin Manolache wrote:

To clarify - I agree jspc has a lot of broken options and
features. My use case is:


  


  


  



  








   
  
  



I'm using a similar way with jspc from Tomcat 3.3.2-dev :

	
		
		
	


   
	



	





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Remy Maucherat]

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 don't care about any use case of jspc (which is good as it's 
broken).
I was just trying to help out fix bugs, and thought it would be better 
to try to provide user friendly tools (instead of bloated and broken 
ones). I'll focus on some other area of the code then.

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).

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_socket.c

[Mladen Turk]

> -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 to build native code ;{
> 

Agreed, but the entire purpose of the ioctl is to disable the
nonblocking socket.
We can use the fcntl for that.
 

int fd_flags;
fd_flags = fcntl(sd, F_GETFL, 0);
#if defined(O_NONBLOCK)
fd_flags &= ~O_NONBLOCK;
#elif defined(O_NDELAY)
fd_flags &= ~O_NDELAY;
#elif defined(FNDELAY)
fd_flags &= ~O_FNDELAY;
#else
/* : this breaks things, but an alternative isn't obvious...*/
return -1;
#endif
if (fcntl(sd, F_SETFL, fd_flags) == -1) {
return errno;
}


That's how its done in apr.

MT.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_socket.c

[Brzezinski, Paul J]

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 includes
which may change the behavior of the connectors...

Paul




: -Original Message-
: From: jean-frederic clere 
: [mailto:jfrederic.clere@;fujitsu-siemens.com] 
: Sent: Thursday, November 07, 2002 10:51 AM
: To: Tomcat Developers List
: Subject: Re: cvs commit: 
: jakarta-tomcat-connectors/jk/native2/common jk_channel_socket.c
: 
: 
: 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:   
: 
: > For 
: additional commands, 
: e-mail: 
: > 
: > 
: > 
: 
: 
: 
: 
: --
: To unsubscribe, e-mail:   
: 
: For 
: additional commands, 
: e-mail: 
: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_socket.c

[jean-frederic clere]

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 something in other platforms).


MT.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 







--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_socket.c

[Henri Gomez]

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 
use ant to build native code ;{



Agreed, but the entire purpose of the ioctl is to disable the
nonblocking socket.
We can use the fcntl for that.
 

int fd_flags;
fd_flags = fcntl(sd, F_GETFL, 0);
#if defined(O_NONBLOCK)
fd_flags &= ~O_NONBLOCK;
#elif defined(O_NDELAY)
fd_flags &= ~O_NDELAY;
#elif defined(FNDELAY)
fd_flags &= ~O_FNDELAY;
#else
/* : this breaks things, but an alternative isn't obvious...*/
return -1;
#endif
if (fcntl(sd, F_SETFL, fd_flags) == -1) {
return errno;
}


That's how its done in apr.

So let use it that way, APR is a reference in native code implementation  ;)




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14359] New: - largefile option has no effect

[bugzilla]

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_bug.cgi?id=14359

largefile option has no effect

   Summary: largefile option has no effect
   Product: Tomcat 4
   Version: 4.1.12
  Platform: All
OS/Version: All
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In my opinion the largefile option of the jsp servlet in the global web.xml 
file seems to be without effect. No ".dat" file are generated like in 4.0.x. I 
have also scanned the jasper2 code for this option. The option is set at the 
EmbededServletOptions class, but nobody seems to use this value inside of the 
jasper package?

If i have a large jsp page, which produces a method, that is bigger than 64k 
the following execption is thrown:

javax.servlet.ServletException: org/apache/jsp/ch1253utf8_jsp (Code of a method 
longer than 65535 bytes)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationDispatcher.invoke
(ApplicationDispatcher.java:684)
at org.apache.catalina.core.ApplicationDispatcher.doInclude
(ApplicationDispatcher.java:575)
at org.apache.catalina.core.ApplicationDispatcher.include
(ApplicationDispatcher.java:498)

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [VOTE] Proposed jspc refactoring

[Martin Algesten]

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 - 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 don't care about any use case of jspc (which is good as it's

broken).
I was just trying to help out fix bugs, and thought it would be better 
to try to provide user friendly tools (instead of bloated and broken 
ones). I'll focus on some other area of the code then.

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).

Remy


--
To unsubscribe, e-mail:

For additional commands, e-mail:




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-5 tomcat.nsi

[remm]

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: /home/cvs/jakarta-tomcat-5/tomcat.nsi,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- tomcat.nsi7 Nov 2002 14:40:54 -   1.13
  +++ tomcat.nsi7 Nov 2002 16:26:57 -   1.14
  @@ -272,6 +272,19 @@
   
   FunctionEnd
   
  +;
  +;Descriptions
  +
  +!insertmacro MUI_FUNCTIONS_DESCRIPTION_START
  +  !insertmacro MUI_DESCRIPTION_TEXT ${SecTomcat} $(DESC_SecTomcat)
  +  !insertmacro MUI_DESCRIPTION_TEXT ${SecTomcatCore} $(DESC_SecTomcatCore)
  +  !insertmacro MUI_DESCRIPTION_TEXT ${SecTomcatService} $(DESC_SecTomcatService)
  +  !insertmacro MUI_DESCRIPTION_TEXT ${SecTomcatSource} $(DESC_SecTomcatSource)
  +  !insertmacro MUI_DESCRIPTION_TEXT ${SecTomcatDocs} $(DESC_SecTomcatDocs)
  +  !insertmacro MUI_DESCRIPTION_TEXT ${SecMenu} $(DESC_SecMenu)
  +  !insertmacro MUI_DESCRIPTION_TEXT ${SecExamples} $(DESC_SecExamples)
  +!insertmacro MUI_FUNCTIONS_DESCRIPTION_END
  +
   
   ; =
   ; FindJavaPath Function
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

silent install for Tomcat 4.1.12

[Anthony Shawver]

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:

http://java.sun.com/j2se/1.4/docs/guide/plugin/developer_guide/silent.html

Tony

RE: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_socket.c

[Mladen Turk]

> -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 all to call that at the
first place.
Since we are sure that the socket is created in the blocking mode, then
seting timeout doesn't need to set the socket to the blocking mode at
the first place.
Think that I copied that code from the APR at the first place (seting
socket timeout), but in the apr you cannot be sure that if the socket is
blocking or not, so you have to set it to the correct mode.

I'll #if 0 that setting, so we can check that.

MT.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Henri Gomez]

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 ;)



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 10469] - URLs of resources from application archives contain spaces

[bugzilla]

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_bug.cgi?id=10469

URLs of resources from application archives contain spaces





--- Additional Comments From [EMAIL PROTECTED]  2002-11-07 16:42 ---
I have encoded my urls with response.encodeURL(), while this puts the sessionID 
in correctly when needed, it does encode spaces to %20.

The following is an excerpt from
http://www.oreillynet.com/cs/user/view/cs_msg/3520
--
Spaces in URL's are generally given special interpretation, so, when they are 
not intended to have any such special interpretation, they are supposed to be 
escaped (%20, of course).  While it's true that some browsers will 
appropriately modify a given URL in their HTTP interchange with the server, 
this is non-standard and cannot be relied upon.

Therefore, the URL "http://www.oreillynet.com/mac/2001/06/01/graphics/h-m 
switch.gif" should be "http://www.oreillynet.com/mac/2001/06/01/graphics/h-m%
20switch.gif".

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_socket.c

[mturk]

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 jakarta-tomcat-connectors/jk/native2/common/jk_channel_socket.c
  
  Index: jk_channel_socket.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_socket.c,v
  retrieving revision 1.43
  retrieving revision 1.44
  diff -u -r1.43 -r1.44
  --- jk_channel_socket.c   7 Nov 2002 15:31:01 -   1.43
  +++ jk_channel_socket.c   7 Nov 2002 16:46:28 -   1.44
  @@ -71,9 +71,6 @@
* @author: Costin Manolache
*/
   
  -/* affects include files on Solaris (for FIONBIO on Solaris 8) */
  -#define BSD_COMP
  -
   #include "jk_map.h"
   #include "jk_env.h"
   #include "jk_channel.h"
  @@ -303,6 +300,15 @@
   if (ntimeout >= 0) {
   /* convert from seconds to ms */
   int set = ntimeout * 1000;
  +
  +/* When a socket is created, it operates in blocking mode 
  + * by default (nonblocking mode is disabled), so there is no need
  + * to set it to the blocking mode prior timeout setting.
  + * This is consistent with BSD sockets.
  + *
  + * XXX: How to check the timeouts effectively?
  +*/ 
  +#if 0
   u_long zero = 0;
   #ifdef WIN32
   if (ioctlsocket(sock, FIONBIO, &zero) == SOCKET_ERROR) {
  @@ -315,7 +321,7 @@
  socketInfo->host, socketInfo->port, errno, strerror( 
errno ) );
   return JK_ERR;
   }
  -
  +#endif 
   setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO, (char *) &set, sizeof(set));
   setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO, (char *) &set, sizeof(set));
   }
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Remy Maucherat]

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 code exposure ;)



Hey, stop making fun of me, and get back to work ;-)

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 10469] - URLs of resources from application archives contain spaces

[bugzilla]

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_bug.cgi?id=10469

URLs of resources from application archives contain spaces





--- Additional Comments From [EMAIL PROTECTED]  2002-11-07 16:54 ---
My original bug posting refers actually to the bug in the Tomcat class loader, 
that should be motified to encode the URLs of resources loaded from the 
application archive with spaces escaped. The bug I submitted doesn't in any way 
refer to URLs that are exchanged between the client and the server.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Henri Gomez]

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:   
For additional commands, e-mail: 

[Request] Commit the JNDIRealm patch

[Fredrik Westermarck]

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 
.

Can someone with privileges to commit please commit it to TC4.1?


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Costin Manolache]

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 web.xml fragment.
> 
> 
> Actually, I don't care about any use case of jspc (which is good as it's
> broken).
> I was just trying to help out fix bugs, and thought it would be better
> to try to provide user friendly tools (instead of bloated and broken
> ones). I'll focus on some other area of the code then.

I do care about this use case, and I'm pretty sure it's not broken.

I have no problem with deprecating the other features and CLI - 
if nobody is maintaining them it would be better to cut them. But
I use this feature ( and intend to fix it if it brakes )

 
> 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).

:-) 

It's not that bad -  generating servlets is one of the things I like 
in jsp.

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java

[remm]

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 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
  
  Index: WebappClassLoader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- WebappClassLoader.java16 Oct 2002 16:08:29 -  1.10
  +++ WebappClassLoader.java7 Nov 2002 17:24:37 -   1.11
  @@ -945,7 +945,7 @@
   // Note : Not getting an exception here means the resource was
   // found
   try {
  -result.addElement(getURL(new File(files[i], name)));
  +result.addElement(getURI(new File(files[i], name)));
   } catch (MalformedURLException e) {
   // Ignore
   }
  @@ -958,7 +958,7 @@
   JarEntry jarEntry = jarFiles[i].getJarEntry(name);
   if (jarEntry != null) {
   try {
  -String jarFakeUrl = getURL(jarRealFiles[i]).toString();
  +String jarFakeUrl = getURI(jarRealFiles[i]).toString();
   jarFakeUrl = "jar:" + jarFakeUrl + "!/" + name;
   result.addElement(new URL(jarFakeUrl));
   } catch (MalformedURLException e) {
  @@ -1563,7 +1563,7 @@
   private ResourceEntry findResourceInternal(File file, String path){
   ResourceEntry entry = new ResourceEntry();
   try {
  -entry.source = getURL(new File(file, path));
  +entry.source = getURI(new File(file, path));
   entry.codeBase = entry.source;
   } catch (MalformedURLException e) {
   return null;
  @@ -1676,7 +1676,7 @@
   
   entry = new ResourceEntry();
   try {
  -entry.codeBase = getURL(jarRealFiles[i]);
  +entry.codeBase = getURI(jarRealFiles[i]);
   String jarFakeUrl = entry.codeBase.toString();
   jarFakeUrl = "jar:" + jarFakeUrl + "!/" + path;
   entry.source = new URL(jarFakeUrl);
  @@ -1939,6 +1939,23 @@
   // Ignore
   }
   return realFile.toURL();
  +
  +}
  +
  +
  +/**
  + * Get URL.
  + */
  +protected URL getURI(File file)
  +throws MalformedURLException {
  +
  +File realFile = file;
  +try {
  +realFile = realFile.getCanonicalFile();
  +} catch (IOException e) {
  +// Ignore
  +}
  +return realFile.toURI().toURL();
   
   }
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Hans Bergsten]

Remy Maucherat wrote:

Hi,

jspc is IMO overly complex, with many features nobody knows how to use, 
and nobody cares to test (hence sometimes some of them are randomly 
broken during Jasper refactorings).

I will not formally vote on this, because I've been inactive in this
project for so long I feel I need to familiarize myself with the
current code base before I can exercise my voting priviledges. But I
do have some comments, see below.


I propose that:
- In Tomcat 5, all jspc options are removed, in favor of allowing only 
the webapp mode (with its relevant options). This webapp mode would 
generate code and classes which should be deployed in the work 
directory, exactly the same as if they were dynamically compiled by 
Jasper (which has the big advantage of using only one big operation mode 
for everything). Single file mode is IMO useless (dynamic compilation 
works fine).

I agree with you regading single file mode, but not with the rest.


- In Tomcat 4.1, the options will stay in for compatibility, but the 
usage help will be modified to be the same as Tomcat 5.

I'm not sure what you mean by this proposal. Are you saying that the
TC 4.1.x version would have a usage message (documentation) that doesn't
match its features? If so, why? If there will be differences between the
TC 4.1.x and TC 5 versions, I assume we will maintain a separate code
base for each version, each with documentation that correctly reflects
their features.


It has to be noted that:
- The JSP runtime is now very efficient. The old webapp mode (with its 
static web.xml) is a hack (and a 100% proprietary one at that).

Efficiency is not all that important here, since precomiplation is
done before deployment (that's the whole idea, right ;-)

Not sure what you mean with "100% proprietary". The web.xml file (or
fragment) that is generated is defined by the servlet spec.


- Precompilation should only occur at webapp deployment time in the 
general case (the generated code is closely tied to the Jasper runtime 
release).

I don't agree. It's very handy to be able to generate a JAR file with
all JSP pages for an application and deploy it to many different
container instances (Tomcat or others, as long as jasper-runtime.jar
is included). There are many users that want to keep the production
environment as simple (and small in embedded systems, for instance) as
possible, and deploying precompiled JSP pages lets me use a production
environment without the JSP compiler and use JRE instead of the JDK.


- Additional features could be added to the manager servlet to, for 
example, cause precompilation of the deployed webapp in a separate process.

That's a separate thing, more of a container feature than JSPC in my
mind.


- I am -1 to returning to the old "webapp" option behavior (ie, the 
generated files should by default be deployed in the work directory, not 
/WEB-INF/classes).

Why not discuss what the problems with the current options are, and
try to find a solution instead? Like I've said, it's been a while since
I was actively involved with Tomcat development, but I know that in
Tomcat 4.0.4, JSPC seemed to work fine with all options available at
the time. How did Jasper2 break things? If I understand what the main
problem is, I can help find a solution (primarily for Tomcat 4.1.x; I'm
afraid I don't have enough cycles to get into Tomcat 5 at the moment).

Hans
--
Hans Bergsten		[EMAIL PROTECTED]
Gefion Software		http://www.gefionsoftware.com
JavaServer Pages	http://TheJSPBook.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Request] Commit the JNDIRealm patch

[Jonathan Eric Miller]

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 07, 2002 11:00 AM
Subject: [Request] Commit the JNDIRealm patch


> 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
> .
>
> Can someone with privileges to commit please commit it to TC4.1?
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java

[remm]

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  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
  
  Index: WebappClassLoader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- WebappClassLoader.java7 Nov 2002 17:24:37 -   1.11
  +++ WebappClassLoader.java7 Nov 2002 18:03:10 -   1.12
  @@ -1564,7 +1564,7 @@
   ResourceEntry entry = new ResourceEntry();
   try {
   entry.source = getURI(new File(file, path));
  -entry.codeBase = entry.source;
  +entry.codeBase = getURL(new File(file, path));
   } catch (MalformedURLException e) {
   return null;
   }   
  @@ -1618,7 +1618,7 @@
   new PrivilegedFindResource(files[i], path);
   entry = (ResourceEntry)AccessController.doPrivileged(dp);
} else {
  -entry = findResourceInternal(files[i], path);   
  
  +entry = findResourceInternal(files[i], path);
}
   
   ResourceAttributes attributes =
  @@ -1676,8 +1676,8 @@
   
   entry = new ResourceEntry();
   try {
  -entry.codeBase = getURI(jarRealFiles[i]);
  -String jarFakeUrl = entry.codeBase.toString();
  +entry.codeBase = getURL(jarRealFiles[i]);
  +String jarFakeUrl = getURI(jarRealFiles[i]).toString();
   jarFakeUrl = "jar:" + jarFakeUrl + "!/" + path;
   entry.source = new URL(jarFakeUrl);
   } catch (MalformedURLException e) {
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Craig R. McClanahan]

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,
> >
> > 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 relevant options). This webapp mode would
> > generate code and classes which should be deployed in the work
> > directory, exactly the same as if they were dynamically compiled by
> > Jasper (which has the big advantage of using only one big operation mode
> > for everything). Single file mode is IMO useless (dynamic compilation
> > works fine).
> > - In Tomcat 4.1, the options will stay in for compatibility, but the
> > usage help will be modified to be the same as Tomcat 5.
>
> I would say that we're extensively JSPC in ant tasks to generate servlet
> (.java), compile via javac and then put all the classes in a .jar which
> will be included in the final .war (in lib) which include the jsp
> mapping generated by JSPC.
>
> With this methodology, we're sure that what we deploy on our production
> will works (no jsp compilation error on users browser), no time spent in
> compilation at runtime, easy deployement since the WAR alleady included
> everything.
>

An additional advantage for some folks is that you can run the resulting
webapp on a JRE instead of a JDK.

> So what did you means by classes which should be deployed in work
> directory ?
>
> > - I am -1 to returning to the old "webapp" option behavior (ie, the
> > generated files should by default be deployed in the work directory, not
> > /WEB-INF/classes).
>
> It's not my opinion, JSP are nothing more than servlet after all and
> why prevent users to have then in WEB-INF/classes or WEB-INF/lib ?
>
> Also consider massive web hosting situation with many tomcats running
> the same WebApps (with differents settings and JVM owner).
>
> Having everything in a .war (ie data + precompiled jsp in .class or
> .jar) make life easier for web admins since upgrading a version is just
> to replace a .war by a new one.
>
> With your proposed solution, they will have update the war, clean the
> work directory (by hand ?) and move the new classes in the work
> directory. Also did Manager/Admin will be updated for such task ?
>
> > 
> > +1 [ ] Remove the options
> > -1 [ ] Do not remove the options
> > 
> >
> > Note: Users may vote, but only committers have binding votes.
>
> So I'm -1 on removing the options
>
>

I'm -1 on removing the options unless they are replaced with equivalent
functionality that *does* work correctly and *is* maintained.  (Basically,
this is J-F's "do not remove and fix" option.

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14261] - JNDI data source not configured correctly.

[bugzilla]

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_bug.cgi?id=14261

JNDI data source not configured correctly.





--- Additional Comments From [EMAIL PROTECTED]  2002-11-07 18:26 ---
Is this problem resolved? Could you give an example of what the Context 
attributes should be and where in the server.xml should this Context section go.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[luehe]

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 suppress
  'pageEncoding' attribute in any existing tag directives.
  
  Revision  ChangesPath
  1.17  +98 -29
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageDataImpl.java
  
  Index: PageDataImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageDataImpl.java,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- PageDataImpl.java 6 Nov 2002 20:58:10 -   1.16
  +++ PageDataImpl.java 7 Nov 2002 18:34:19 -   1.17
  @@ -120,7 +120,7 @@
*
* @param page the page nodes from which to generate the XML view
*/
  -public PageDataImpl(Node.Nodes page, PageInfo pageInfo)
  +public PageDataImpl(Node.Nodes page, Compiler compiler)
throws JasperException {
   
// First pass
  @@ -131,7 +131,7 @@
// Second pass
buf = new StringBuffer();
SecondPassVisitor secondPassVisitor
  - = new SecondPassVisitor(page.getRoot(), buf, pageInfo);
  + = new SecondPassVisitor(page.getRoot(), buf, compiler);
page.visit(secondPassVisitor);
   }
   
  @@ -237,7 +237,7 @@
   
private Node.Root root;
private StringBuffer buf;
  - private PageInfo pageInfo;
  + private Compiler compiler;
   
// current jsp:id attribute value
private int jspId;
  @@ -246,10 +246,10 @@
 * Constructor
 */
public SecondPassVisitor(Node.Root root, StringBuffer buf,
  -  PageInfo pageInfo) {
  +  Compiler compiler) {
this.root = root;
this.buf = buf;
  - this.pageInfo = pageInfo;
  + this.compiler = compiler;
}
   
/*
  @@ -371,7 +371,7 @@
}
   
public void visit(Node.TagDirective n) throws JasperException {
  - appendTag(JSP_TAG_DIRECTIVE, n.getAttributes(), null, null);
  + appendTagDirective(n);
}
   
public void visit(Node.AttributeDirective n) throws JasperException {
  @@ -408,7 +408,11 @@
if (tag.equals(JSP_ROOT) || body != null || text != null) {
buf.append(">\n");
if (tag.equals(JSP_ROOT)) {
  - appendPageDirective();
  + if (compiler.getCompilationContext().isTagFile()) {
  + appendTagDirective();
  + } else {
  + appendPageDirective();
  + }
}
if (body != null) {
body.visit(this);
  @@ -430,9 +434,27 @@
 * document, and since XML allows only single-value attributes,
 * the values of multiple import attributes must be combined into one,
 * separated by comma.
  +  *
  +  * If the given page directive contains just 'contentType' and/or
  +  * 'pageEncoding' attributes, we ignore it, as we've already appended
  +  * a page directive containing just these two attributes.
 */
private void appendPageDirective(Node.PageDirective pageDir) {
  + boolean append = false;
Attributes attrs = pageDir.getAttributes();
  + int len = attrs.getLength();
  + for (int i=0; i@ -441,7 +463,6 @@
buf.append(jspId++).append("\"\n");
   
// append remaining attributes
  - int len = attrs.getLength();
for (int i=0; i@ -449,7 +470,7 @@
/*
 * Page directive's 'import' attribute is considered
 * further down, and its 'pageEncoding' and 'contentType'
  -  * attributes are ignored, since we've already created 
  +  * attributes are ignored, since we've already appended
 * a new page directive containing just these two
 * attributes
 */
  @@ -477,6 +498,71 @@
buf.append("/>\n");
}
   
  + /*
  +  * Appends a page directive with 'pageEncoding' and 'contentType'
  +  * attributes.
  +  *
  +  * The value of the 'pageEncoding' attribute is hard-coded
  +  * to UTF-8, whereas the value of the 'contentType' attribute, which
  +  * is identical to what the container will pass to
  +  * ServletResponse.setContentType(), is derived from the pageInfo.
  +  */
  + private void appendPageDirective() {
  + buf.append("<").append(JSP_PAGE_DIRECTIVE);
  + buf.append("\n");
  +
  + // append jsp:id
  + buf.append("  ").appen

Re: [VOTE] Proposed jspc refactoring

[Costin Manolache]

Remy has a point - the current code is not very clean, and doesn't
seem to be tested/maintained enough.

I use the ant tasks - and I have a feeling many other users of jspc
are doing the same. 

Removing the CLI and keeping the basic functionality seems like 
a good idea.

For example compiling a jsp page outside a webapp can't work
in all cases - if it has includes, etc it needs to resolve, it 
needs taglib definitions from WEB-INF, etc. I can't see any
good reason to keep it if it's half broken by definition.

Also - compiling the java files is the job of , 
and the mapping and web.xml fragment generation can be 
more easily done using only the ant tasks.

I would go even further - since we are already using ant to 
compile the java to .class, it may be a good idea to make the
.jsp->.java task 'first class'.

In any case - the task is supported ( at least by me, it seems Henri is 
using it as well ).
If there are people who want to support the CLI and the other 
options - then we can keep them, but if not - I think it's better
to remove them or mark as unsupported.

Costin 



Hans Bergsten wrote:

> Remy Maucherat wrote:
>> Hi,
>> 
>> jspc is IMO overly complex, with many features nobody knows how to use,
>> and nobody cares to test (hence sometimes some of them are randomly
>> broken during Jasper refactorings).
> 
> I will not formally vote on this, because I've been inactive in this
> project for so long I feel I need to familiarize myself with the
> current code base before I can exercise my voting priviledges. But I
> do have some comments, see below.
> 
>> I propose that:
>> - In Tomcat 5, all jspc options are removed, in favor of allowing only
>> the webapp mode (with its relevant options). This webapp mode would
>> generate code and classes which should be deployed in the work
>> directory, exactly the same as if they were dynamically compiled by
>> Jasper (which has the big advantage of using only one big operation mode
>> for everything). Single file mode is IMO useless (dynamic compilation
>> works fine).
> 
> I agree with you regading single file mode, but not with the rest.
> 
>> - In Tomcat 4.1, the options will stay in for compatibility, but the
>> usage help will be modified to be the same as Tomcat 5.
> 
> I'm not sure what you mean by this proposal. Are you saying that the
> TC 4.1.x version would have a usage message (documentation) that doesn't
> match its features? If so, why? If there will be differences between the
> TC 4.1.x and TC 5 versions, I assume we will maintain a separate code
> base for each version, each with documentation that correctly reflects
> their features.
> 
>> It has to be noted that:
>> - The JSP runtime is now very efficient. The old webapp mode (with its
>> static web.xml) is a hack (and a 100% proprietary one at that).
> 
> Efficiency is not all that important here, since precomiplation is
> done before deployment (that's the whole idea, right ;-)
> 
> Not sure what you mean with "100% proprietary". The web.xml file (or
> fragment) that is generated is defined by the servlet spec.
> 
>> - Precompilation should only occur at webapp deployment time in the
>> general case (the generated code is closely tied to the Jasper runtime
>> release).
> 
> I don't agree. It's very handy to be able to generate a JAR file with
> all JSP pages for an application and deploy it to many different
> container instances (Tomcat or others, as long as jasper-runtime.jar
> is included). There are many users that want to keep the production
> environment as simple (and small in embedded systems, for instance) as
> possible, and deploying precompiled JSP pages lets me use a production
> environment without the JSP compiler and use JRE instead of the JDK.
> 
>> - Additional features could be added to the manager servlet to, for
>> example, cause precompilation of the deployed webapp in a separate
>> process.
> 
> That's a separate thing, more of a container feature than JSPC in my
> mind.
> 
>> - I am -1 to returning to the old "webapp" option behavior (ie, the
>> generated files should by default be deployed in the work directory, not
>> /WEB-INF/classes).
> 
> Why not discuss what the problems with the current options are, and
> try to find a solution instead? Like I've said, it's been a while since
> I was actively involved with Tomcat development, but I know that in
> Tomcat 4.0.4, JSPC seemed to work fine with all options available at
> the time. How did Jasper2 break things? If I understand what the main
> problem is, I can help find a solution (primarily for Tomcat 4.1.x; I'm
> afraid I don't have enough cycles to get into Tomcat 5 at the moment).
> 
> Hans




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Hans Bergsten]

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.

"CLI" as in ...? Sorry, I'm not familar with this acronym.


For example compiling a jsp page outside a webapp can't work
in all cases - if it has includes, etc it needs to resolve, it 
needs taglib definitions from WEB-INF, etc. I can't see any
good reason to keep it if it's half broken by definition.

Right, I agree.


Also - compiling the java files is the job of , 
and the mapping and web.xml fragment generation can be 
more easily done using only the ant tasks.

Even though I see one advantage with including compilation to class
files in JSPC (simlicity, no need to set up Ant, which is not always
available in the web app developers environment), I wasn't aware of
the -compile option until this week (since it's not documented).
I'm okay with removing it and handle compilation in other ways.


I would go even further - since we are already using ant to 
compile the java to .class, it may be a good idea to make the
.jsp->.java task 'first class'.

Not sure I follow. If you mean to do this in addition to fixing
JSPC (with the -webapp option), it's okay with me.


In any case - the task is supported ( at least by me, it seems Henri is 
using it as well ).
If there are people who want to support the CLI and the other 
options - then we can keep them, but if not - I think it's better
to remove them or mark as unsupported.

See above.

Hans
--
Hans Bergsten		[EMAIL PROTECTED]
Gefion Software		http://www.gefionsoftware.com
JavaServer Pages	http://TheJSPBook.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-catalina/catalina/src/conf catalina.policy

[jfarcand]

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
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/conf/catalina.policy,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- catalina.policy   4 Nov 2002 20:22:43 -   1.6
  +++ catalina.policy   7 Nov 2002 19:04:55 -   1.7
  @@ -63,12 +63,6 @@
   permission java.security.AllPermission;
   };
   
  -// The new JSP 2.0 implementation needs some special privileges in order to work.
  -// FIX ME: Need to reduce the permission scope.
  -grant codeBase "file:${catalina.home}/webapps/jsp-examples/-" {
  -  permission java.security.AllPermission;  
  -};
  -
   // == WEB APPLICATION PERMISSIONS =
   
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[luehe]

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
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
  
  Index: Generator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
  retrieving revision 1.121
  retrieving revision 1.122
  diff -u -r1.121 -r1.122
  --- Generator.java6 Nov 2002 22:49:07 -   1.121
  +++ Generator.java7 Nov 2002 19:09:03 -   1.122
  @@ -1832,8 +1832,8 @@
   
// Copy virtual page scope of tag file to page scope of invoking
// page
  - out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
jspContext).copyTagToPageScope(javax.servlet.jsp.tagext.VariableInfo.NESTED);");
  - out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
jspContext).copyTagToPageScope(javax.servlet.jsp.tagext.VariableInfo.AT_BEGIN);");
  + out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
this.jspContext).copyTagToPageScope(javax.servlet.jsp.tagext.VariableInfo.NESTED);");
  + out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
this.jspContext).copyTagToPageScope(javax.servlet.jsp.tagext.VariableInfo.AT_BEGIN);");
   
// Invoke fragment
String varReaderAttr = n.getTextAttribute("varReader");
  @@ -1852,8 +1852,8 @@
out.pushIndent();
// Copy page scope of invoking page back to virtual page scope of
// tag file
  - out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
jspContext).copyPageToTagScope(javax.servlet.jsp.tagext.VariableInfo.NESTED);");
  - out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
jspContext).copyPageToTagScope(javax.servlet.jsp.tagext.VariableInfo.AT_BEGIN);");
  + out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
this.jspContext).copyPageToTagScope(javax.servlet.jsp.tagext.VariableInfo.NESTED);");
  + out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
this.jspContext).copyPageToTagScope(javax.servlet.jsp.tagext.VariableInfo.AT_BEGIN);");
out.popIndent();
out.printil("}");
   
  @@ -1880,8 +1880,8 @@
   
// Copy virtual page scope of tag file to page scope of invoking
// page
  - out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
jspContext).copyTagToPageScope(javax.servlet.jsp.tagext.VariableInfo.NESTED);");
  - out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
jspContext).copyTagToPageScope(javax.servlet.jsp.tagext.VariableInfo.AT_BEGIN);");
  + out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
this.jspContext).copyTagToPageScope(javax.servlet.jsp.tagext.VariableInfo.NESTED);");
  + out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
this.jspContext).copyTagToPageScope(javax.servlet.jsp.tagext.VariableInfo.AT_BEGIN);");
   
// Invoke body
String varReaderAttr = n.getTextAttribute("varReader");
  @@ -1899,8 +1899,8 @@
out.pushIndent();
// Copy page scope of invoking page back to virtual page scope of
// tag file
  - out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
jspContext).copyPageToTagScope(javax.servlet.jsp.tagext.VariableInfo.NESTED);");
  - out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
jspContext).copyPageToTagScope(javax.servlet.jsp.tagext.VariableInfo.AT_BEGIN);");
  + out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
this.jspContext).copyPageToTagScope(javax.servlet.jsp.tagext.VariableInfo.NESTED);");
  + out.printil("((org.apache.jasper.runtime.JspContextWrapper) 
this.jspContext).copyPageToTagScope(javax.servlet.jsp.tagext.VariableInfo.AT_BEGIN);");
out.popIndent();
out.printil("}");
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14261] - JNDI data source not configured correctly.

[bugzilla]

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_bug.cgi?id=14261

JNDI data source not configured correctly.





--- Additional Comments From [EMAIL PROTECTED]  2002-11-07 19:10 ---
I have the configuration information in the Global naming section. Upon 
startup, I see the following RefAddrs passed in to the BasicDataSourceFactory 
code:

INFO: Initializing Coyote HTTP/1.1 on port 9080
In code!
Type: scope
Content: Shareable

Type: auth
Content: Container

Type: url
Content: jdbc:oracle:thin:@east2:1521:DWMSDEV

Type: maxIdle
Content: 2

Type: maxActive
Content: 5

Type: maxWait
Content: -1

Type: driverClassName
Content: oracle.jdbc.driver.OracleDriver

Type: removeAbandoned
Content: true

Type: username
Content: s154480

Type: factory
Content: org.apache.commons.dbcp.BasicDataSourceFactory

Type: logAbandoned
Content: true

Type: password
Content: mjm2278

ra=Type: driverClassName
Content: oracle.jdbc.driver.OracleDriver



The following entry is from within the BasicDataSource code.
DriverClassName=oracle.jdbc.driver.OracleDriver


When I actually visit the first page that uses the data source, I see the 
BasicDataSourceFactory called with the following refaddrs:

In code!
Type: description
Content: Storms Connection

Type: scope
Content: Shareable

Type: auth
Content: Application


This last line shows that BasicDataSource does not get the DriverClass, because 
there is no refaddr for that parameter. Essentially, when the application tries 
to use the datasource, it can't find the object that was already created, and 
the BasicDataSourceFactory does not get the parameters specified in the global 
naming section, so the BasicDataSource that is created is unusable. 

I find quite a few references to this problem on the web. It appears to be 
somewhat common.

I am willing to help debug in any way I can. This has pretty much stopped my 
development. 

Mike
ra=null

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[OT] Digester Not In Tomcat SRC

[micael]

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

---

This electronic mail  transmission and any accompanying documents contain 
information belonging to the sender which may be confidential and legally 
privileged.  This information is intended only for the use of the 
individual or entity to whom this electronic mail transmission was sent as 
indicated above. If you are not the intended recipient, any disclosure, 
copying, distribution, or action taken in reliance on the contents of the 
information contained in this transmission is strictly prohibited.  If you 
have received this transmission in error, please delete the message.  Thank you 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [VOTE] Proposed jspc refactoring

[John Trollinger]

I have to time to go through and fix all the options (including cleaning
up the code) but I would like to see what options are actually used (or
would like to be used if they work)

I also have no problems maintaining jscp as I use it a lot and have
customized it to do what I want.  

I would just like some direction to go with..

John

> -Original Message-
> From: news [mailto:news@;main.gmane.org] On Behalf Of Costin Manolache
> Sent: Thursday, November 07, 2002 1:39 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [VOTE] Proposed jspc refactoring
> 
> 
> Remy has a point - the current code is not very clean, and 
> doesn't seem to be tested/maintained enough.
> 
> I use the ant tasks - and I have a feeling many other users 
> of jspc are doing the same. 
> 
> Removing the CLI and keeping the basic functionality seems like 
> a good idea.
> 
> For example compiling a jsp page outside a webapp can't work
> in all cases - if it has includes, etc it needs to resolve, it 
> needs taglib definitions from WEB-INF, etc. I can't see any 
> good reason to keep it if it's half broken by definition.
> 
> Also - compiling the java files is the job of , 
> and the mapping and web.xml fragment generation can be 
> more easily done using only the ant tasks.
> 
> I would go even further - since we are already using ant to 
> compile the java to .class, it may be a good idea to make the 
> .jsp->.java task 'first class'.
> 
> In any case - the task is supported ( at least by me, it 
> seems Henri is 
> using it as well ).
> If there are people who want to support the CLI and the other 
> options - then we can keep them, but if not - I think it's 
> better to remove them or mark as unsupported.
> 
> Costin 
> 
> 
> 
> Hans Bergsten wrote:
> 
> > Remy Maucherat wrote:
> >> Hi,
> >> 
> >> jspc is IMO overly complex, with many features nobody knows how to 
> >> use, and nobody cares to test (hence sometimes some of them are 
> >> randomly broken during Jasper refactorings).
> > 
> > I will not formally vote on this, because I've been 
> inactive in this 
> > project for so long I feel I need to familiarize myself with the 
> > current code base before I can exercise my voting 
> priviledges. But I 
> > do have some comments, see below.
> > 
> >> I propose that:
> >> - In Tomcat 5, all jspc options are removed, in favor of allowing 
> >> only the webapp mode (with its relevant options). This webapp mode 
> >> would generate code and classes which should be deployed 
> in the work 
> >> directory, exactly the same as if they were dynamically 
> compiled by 
> >> Jasper (which has the big advantage of using only one big 
> operation 
> >> mode for everything). Single file mode is IMO useless (dynamic 
> >> compilation works fine).
> > 
> > I agree with you regading single file mode, but not with the rest.
> > 
> >> - In Tomcat 4.1, the options will stay in for 
> compatibility, but the 
> >> usage help will be modified to be the same as Tomcat 5.
> > 
> > I'm not sure what you mean by this proposal. Are you saying 
> that the 
> > TC 4.1.x version would have a usage message (documentation) that 
> > doesn't match its features? If so, why? If there will be 
> differences 
> > between the TC 4.1.x and TC 5 versions, I assume we will maintain a 
> > separate code base for each version, each with documentation that 
> > correctly reflects their features.
> > 
> >> It has to be noted that:
> >> - The JSP runtime is now very efficient. The old webapp mode (with 
> >> its static web.xml) is a hack (and a 100% proprietary one at that).
> > 
> > Efficiency is not all that important here, since precomiplation is 
> > done before deployment (that's the whole idea, right ;-)
> > 
> > Not sure what you mean with "100% proprietary". The web.xml file (or
> > fragment) that is generated is defined by the servlet spec.
> > 
> >> - Precompilation should only occur at webapp deployment 
> time in the 
> >> general case (the generated code is closely tied to the Jasper 
> >> runtime release).
> > 
> > I don't agree. It's very handy to be able to generate a JAR 
> file with 
> > all JSP pages for an application and deploy it to many different 
> > container instances (Tomcat or others, as long as 
> jasper-runtime.jar 
> > is included). There are many users that want to keep the production 
> > environment as simple (and small in embedded systems, for 
> instance) as 
> > possible, and deploying precompiled JSP pages lets me use a 
> production 
> > environment without the JSP compiler and use JRE instead of the JDK.
> > 
> >> - Additional features could be added to the manager 
> servlet to, for 
> >> example, cause precompilation of the deployed webapp in a separate 
> >> process.
> > 
> > That's a separate thing, more of a container feature than 
> JSPC in my 
> > mind.
> > 
> >> - I am -1 to returning to the old "webapp" option behavior 
> (ie, the 
> >> generated files should by default be deployed in the work 
> directory, 
> >> not /WEB-INF

DO NOT REPLY [Bug 14367] New: - servlet.init() not getting called

[bugzilla]

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_bug.cgi?id=14367

servlet.init() not getting called

   Summary: servlet.init() not getting called
   Product: Tomcat 4
   Version: 4.1.12
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


THis looks like a trivial issue but I researched a solution to the problem that 
I am going to state below on google, on bugs database for TOMCAT at your site 
and also posed this problem in the TOMCAT users list and I have not found an 
answer to the problem.

Here is the problem: My web application has not number of servlets and some of 
them have a init() method where certain initializations take place. After 
running into a null pointer exception, I found that the init() method is not 
getting called. Has anybody else reported this problem?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/xmlparser ASCIIReader.java UCSReader.java UTF8Reader.java XMLEncodingDetector.java

[Jan Luehe]

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
> > ParserController.java Validator.java
> >jasper2/src/share/org/apache/jasper/resources
> > messages.properties messages_es.properties
> > messages_ja.properties
> >   Added:   jasper2/src/share/org/apache/jasper/xmlparser
> > ASCIIReader.java UCSReader.java UTF8Reader.java
> > XMLEncodingDetector.java
> >   Log:
> >   First cut at I18N changes.
> >   
> 
> There are problems with that patch:
> 
> - What does it do ?
> 
> - It seems like a big change, was it discussed before on the list ?


the above changes address a number of I18N fixes to the JSP 1.2
spec, which have been discussed in the JSR-152 EG and will be addressed
by the upcoming JSP 2.0 spec.

The biggest change is about determining the page chatacter (source)
encoding of JSP pages in XML syntax. According to the JSP 1.2 spec,
the 'pageEncoding' attribute of the page directive must be used, but
this is incompatible with the XML spec, which defines an encoding
autodetection mechanism and XML prolog encoding attribute to specify
this encoding.

The JSP 2.0 spec is going to require that for JSP pages in XML syntax,
the page character encoding is determined as described in section
4.3.3 and appendix F.1 of the XML specification.

I realize I should have included this information in my commit message.
Sorry about that.


> - Trying to access the admin webapp:
> java.lang.StackOverflowError
>   at org.apache.jasper.xmlparser.UTF8Reader.read(UTF8Reader.java:293)
>   at 
> 
org.apache.jasper.xmlparser.XMLEncodingDetector.load(XMLEncodingDetector.java:10
> 41)
>   at 
> 
org.apache.jasper.xmlparser.XMLEncodingDetector.load(XMLEncodingDetector.java:10
> 65)
>   at 
> 
org.apache.jasper.xmlparser.XMLEncodingDetector.load(XMLEncodingDetector.java:10
> 65)
> (you get the idea)


Thanks for having fixed this already!



Jan


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [VOTE] Proposed jspc refactoring (how I use jspc)

[Sean Reilly]

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 attributes present, etc)
b)We use a jstl validator to keep over-enthusiastic web developers from using 
scriptlets in jsp pages

Including jsp checking in the compile cycle (and inflicting bodily harm on developers 
who cvs commit without compiling ;-) is a big help in keeping code quality high.

It's been mentionied in this thread (I think by Remy), that
"Efficiency is not all that important here, since precomiplation is done before 
deployment"
I would respectfully disagree on this point.

Not including jsp compilation, our entire build cycle, from a stock tomcat zip to a 
running tomcat instance with deployed webapps (including all servlet compilation and 
source code style checking) takes about 35 seconds.
Using ant's incremental capabilities, a non-complete build often takes less than 10 
seconds.  I love that our developers can compile at the drop of a hat, and I encourage 
this as often as I can.

So to me, efficiency is very important; the faster, the better.  Right now, a jsp 
precompilation for 120 jsp pages (which we can put off until production deployment to 
organizational peculiarities) takes 54 seconds... longer than the rest of our build 
cycle put together.  I would love for jsp compile checking to be performed as part of 
a regular developer's build cycle, and the faster JspC gets, the easier that is.  
Also, we do use incremental jsp compiles on a regular basis.

Also, I would love to deploy precompiled jsps to production, but conformance to the 
jsp and servlet specs is important to us, so a servlet compliant way (as opposed to 
the "copying to the work directory" solution) would be a positive feature for us.

So to sum up, we jspc an entire webapp at a time, but love incremental compilation 
(which is the only reason I can think of that someone would need to only compile a 
single jsp), and the faster the process is, the better.

Thanks,
Sean

PS:  Also, if you're looking for an example of the kind of performance you can get 
from a tomcat-powered server (as many people in the user's list seem to be), we're 
probably a pretty good example.  We served 52,708 page views yesterday (of definitely 
non-static content) from two dual p3 800mhz boxes, and when cpu usage goes over 5% on 
either machine, we get seriously upset.

http://usediron.point2.com

Sean Reilly
Programmer, Point2 Technologies, Inc.
(306) 955-1855
[EMAIL PROTECTED]



-Original Message-
From: John Trollinger [mailto:jakarta@;trollingers.com]
Sent: Thursday, November 07, 2002 1:24 PM
To: 'Tomcat Developers List'
Subject: RE: [VOTE] Proposed jspc refactoring


I have to time to go through and fix all the options (including cleaning
up the code) but I would like to see what options are actually used (or
would like to be used if they work)

I also have no problems maintaining jscp as I use it a lot and have
customized it to do what I want.  

I would just like some direction to go with..

John

> -Original Message-
> From: news [mailto:news@;main.gmane.org] On Behalf Of Costin Manolache
> Sent: Thursday, November 07, 2002 1:39 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [VOTE] Proposed jspc refactoring
> 
> 
> Remy has a point - the current code is not very clean, and 
> doesn't seem to be tested/maintained enough.
> 
> I use the ant tasks - and I have a feeling many other users 
> of jspc are doing the same. 
> 
> Removing the CLI and keeping the basic functionality seems like 
> a good idea.
> 
> For example compiling a jsp page outside a webapp can't work
> in all cases - if it has includes, etc it needs to resolve, it 
> needs taglib definitions from WEB-INF, etc. I can't see any 
> good reason to keep it if it's half broken by definition.
> 
> Also - compiling the java files is the job of , 
> and the mapping and web.xml fragment generation can be 
> more easily done using only the ant tasks.
> 
> I would go even further - since we are already using ant to 
> compile the java to .class, it may be a good idea to make the 
> .jsp->.java task 'first class'.
> 
> In any case - the task is supported ( at least by me, it 
> seems Henri is 
> using it as well ).
> If there are people who want to support the CLI and the other 
> options - then we can keep them, but if not - I think it's 
> better to remove them or mark as unsupported.
> 
> Costin 
> 
> 
> 
> Hans Bergsten wrote:
> 
> > Remy Maucherat wrote:
> >> Hi,
> >> 
> >> jspc is IMO overly complex, with many features nobody knows how to 
> >> use, and nobody cares to test (hence sometimes some of them are 
> >> randomly broken during Jasper refactorings).
> > 
> > I will not formally vote on this, because I've been 
> inactive in this 
> > project for so long I feel I need 

Re: [VOTE] Proposed jspc refactoring

[Costin Manolache]

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 
 can also generate code for other  containers, so one 
extra benefit.

And if jspc becomes first-class - we'll stop the 
nightly gump test failures for ant :-) ( JSPC is 
actually tested by gump - part of ant tests ).

( there are failures - but it seems they happen only
in gump env, and I wasn't yet able to fix them ).

>> I would go even further - since we are already using ant to
>> compile the java to .class, it may be a good idea to make the
>> .jsp->.java task 'first class'.
> 
> Not sure I follow. If you mean to do this in addition to fixing
> JSPC (with the -webapp option), it's okay with me.

Basically add an execute() method and setters to Compiler, and 
calling jasper indirectly, using the ant task. 

Jasper will be a very large ant task. That means we could 
switch jasper versions ( or other jsp impl ), it could be used
in other containers or applications, etc.

( well, I'm not volunteering for that - but I think it would
be a nice idea for 5.0 ).


BTW, a separate issue would be extending the JMX support
to jasper. We use JMX mostly for configuration, but that's
only a small part of what can be done. We can extract 
informations or control jasper at runtime ( recompile, set
jikes, etc ). And jasper would be even easier to embed.


Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[jfarcand]

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 
org.apache.jasper is protected. Fix bugs when the JSP 2.0 examples were executed under 
the SecurityManager.
  
  Revision  ChangesPath
  1.33  +33 -16
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/PageContextImpl.java
  
  Index: PageContextImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/PageContextImpl.java,v
  retrieving revision 1.32
  retrieving revision 1.33
  diff -u -r1.32 -r1.33
  --- PageContextImpl.java  7 Nov 2002 10:51:14 -   1.32
  +++ PageContextImpl.java  7 Nov 2002 21:11:40 -   1.33
  @@ -62,7 +62,9 @@
   package org.apache.jasper.runtime;
   
   import java.io.*;
  -
  +import java.security.AccessController;
  +import java.security.PrivilegedExceptionAction;
  +import java.security.PrivilegedActionException;
   import java.util.EmptyStackException;
   import java.util.Enumeration;
   import java.util.Hashtable;
  @@ -645,21 +647,36 @@
* @param defaultPrefix Default prefix for this evaluation
* @return The result of the evaluation
*/
  -public static Object proprietaryEvaluate( String expression,
  -Class expectedType, PageContext pageContext,
  - ProtectedFunctionMapper functionMap, String defaultPrefix )
  -throws ELException
  +public static Object proprietaryEvaluate( final String expression, 
  + final Class expectedType,  final PageContext pageContext,
  +  final ProtectedFunctionMapper functionMap,  final String defaultPrefix )
  +   throws ELException
   {
  - java.util.HashMap funcMap =
  + final java.util.HashMap funcMap =
(functionMap == null)? null: functionMap.getFnMap();
  +
  +if (System.getSecurityManager() != null){
  +try {
  +return AccessController.doPrivileged(new 
PrivilegedExceptionAction(){
   
  -try {
  -return PageContextImpl.proprietaryEvaluator.evaluate( "",
  -expression, expectedType, null, pageContext,
  - funcMap, defaultPrefix );
  -}
  -catch( JspException e ) {
  -throw new ELException( e );
  +public Object run() throws Exception{
  +   return PageContextImpl.proprietaryEvaluator.evaluate( 
"", 
  +expression, expectedType, null, pageContext,
  +funcMap, defaultPrefix );
  +}
  +});
  +} catch( PrivilegedActionException ex ) {
  +Exception e = ex.getException();
  +throw new ELException( e );
  +}
  +} else {
  +try{
  +   return PageContextImpl.proprietaryEvaluator.evaluate( "", 
  +expression, expectedType, null, pageContext,
  +funcMap, defaultPrefix );
  +} catch(JspException e){
  +throw new ELException( e );
  +}  
   }
   }
   
  
  
  
  1.2   +25 -10
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/ProtectedFunctionMapper.java
  
  Index: ProtectedFunctionMapper.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/ProtectedFunctionMapper.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- ProtectedFunctionMapper.java  6 Nov 2002 18:48:17 -   1.1
  +++ ProtectedFunctionMapper.java  7 Nov 2002 21:11:40 -   1.2
  @@ -65,7 +65,8 @@
   import java.util.HashMap;
   import java.security.AccessController;
   import java.security.PrivilegedAction;
  -
  +import java.security.PrivilegedExceptionAction;
  +import java.security.PrivilegedActionException;
   /**
* Maps EL functions to their Java method counterparts.  Keeps the
* actual Method objects protected so that JSP pages can't indirectly
  @@ -125,14 +126,28 @@
* could be found.
*/
   public void mapFunction( String prefix, String fnName,
  -Class c, String methodName, Class[] args ) 
  +final Class c, final String methodName, final Class[] args ) 
   {
java.lang.reflect.Method method;
  - try {
  - method = c.getDeclaredMethod(methodName, args);
  - } catch( NoSuchMethodException e ) {
  -throw new RuntimeException(
  -"Invalid function mapping - no such method: " + e.getMessage());
  +if (System.getS

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

[jfarcand]

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 under the 
SecurityManager.
  
  Revision  ChangesPath
  1.6   +38 -12
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JasperLoader.java
  
  Index: JasperLoader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JasperLoader.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- JasperLoader.java 21 Oct 2002 18:44:00 -  1.5
  +++ JasperLoader.java 7 Nov 2002 21:13:05 -   1.6
  @@ -66,6 +66,8 @@
   import java.security.CodeSource;
   import java.security.PermissionCollection;
   import java.security.PrivilegedAction;
  +import java.security.PrivilegedActionException;
  +import java.security.PrivilegedExceptionAction;
   import java.security.ProtectionDomain;
   
   import javax.servlet.http.*;
  @@ -79,6 +81,7 @@
*
* @author Anil K. Vijendran
* @author Harish Prabandham
  + * @author Jean-Francois Arcand
*/
   public class JasperLoader extends URLClassLoader {
   
  @@ -140,7 +143,7 @@
* 
* @exception ClassNotFoundException if the class was not found
*/
  -public Class loadClass(String name, boolean resolve)
  +public Class loadClass(final String name, boolean resolve)
   throws ClassNotFoundException {
   
   Class clazz = null;
  @@ -157,12 +160,15 @@
int dot = name.lastIndexOf('.');
   if (securityManager != null) { 
   if (dot >= 0) {
  -try {
  -securityManager.checkPackageAccess(name.substring(0,dot));
  +try {
  +// Do not call the security manager since by default, we grant 
that package.
  +if 
(!"org.apache.jasper.runtime".equalsIgnoreCase(name.substring(0,dot))){
  +securityManager.checkPackageAccess(name.substring(0,dot));
  +}
   } catch (SecurityException se) {
   String error = "Security Violation, attempt to use " +
   "Restricted Class: " + name;
  -System.out.println(error);
  +se.printStackTrace();
   throw new ClassNotFoundException(error);
   }  
   }  
  @@ -170,13 +176,22 @@
   
// Class is in a package, delegate to thread context class loader
if( !name.startsWith(Constants.JSP_PACKAGE_NAME) ) {
  -ClassLoader classLoader = null;
if (securityManager != null) {
  - classLoader = 
(ClassLoader)AccessController.doPrivileged(privLoadClass);
  -} else {
  - classLoader = Thread.currentThread().getContextClassLoader();
  -}
  -clazz = classLoader.loadClass(name);
  +final ClassLoader classLoader = 
(ClassLoader)AccessController.doPrivileged(privLoadClass);
  +try{
  +clazz = (Class)AccessController.doPrivileged(new 
PrivilegedExceptionAction(){
  +public Object run() throws Exception{
  +return classLoader.loadClass(name);
  +}
  +});
  +} catch(PrivilegedActionException ex){
  +ex.getException().printStackTrace();
  +
  +}
  + } else {
  +clazz = 
Thread.currentThread().getContextClassLoader().loadClass(name);
  +  }
  +
if( resolve )
resolveClass(clazz);
return clazz;
  @@ -228,10 +243,21 @@
   /*
* Load JSP class data from file.
*/
  -private byte[] loadClassDataFromFile(String fileName) {
  +private byte[] loadClassDataFromFile(final String fileName) {
   byte[] classBytes = null;
   try {
  -InputStream in = getResourceAsStream(fileName);
  +InputStream in = null;
  +
  +if (System.getSecurityManager() != null){
  +in = (InputStream)AccessController.doPrivileged(new 
PrivilegedAction(){
  +public Object run(){
  +return getResourceAsStream(fileName);
  +}
  +});
  +} else {
  +in = getResourceAsStream(fileName);
  +}
  +
 

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

[jfarcand]

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 were executed under the 
SecurityManager.
  
  Revision  ChangesPath
  1.6   +19 -4 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspRuntimeContext.java
  
  Index: JspRuntimeContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspRuntimeContext.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- JspRuntimeContext.java3 Aug 2002 23:29:21 -   1.5
  +++ JspRuntimeContext.java7 Nov 2002 21:14:53 -   1.6
  @@ -130,6 +130,20 @@
   "runtime.TagHandlerPool");
   factory.getClass().getClassLoader().loadClass( basePackage +
   "servlet.JspServletWrapper");
  +factory.getClass().getClassLoader().loadClass( basePackage +
  +"runtime.JspFragmentHelper");
  +factory.getClass().getClassLoader().loadClass( basePackage +
  +"runtime.ProtectedFunctionMapper");
  +factory.getClass().getClassLoader().loadClass( basePackage +
  +"runtime.ProtectedFunctionMapper$1");
  +factory.getClass().getClassLoader().loadClass( basePackage +
  +"runtime.ProtectedFunctionMapper$2");
  +factory.getClass().getClassLoader().loadClass( basePackage +
  +"runtime.PageContextImpl");  
  + factory.getClass().getClassLoader().loadClass( basePackage +
  +"runtime.PageContextImpl$1");  
  +factory.getClass().getClassLoader().loadClass( basePackage +
  +"runtime.JspContextWrapper");   
   } catch (ClassNotFoundException ex) {
   System.out.println(
   "Jasper JspRuntimeContext preload of class failed: " +
  @@ -392,6 +406,7 @@
   // Allow the JSP to access org.apache.jasper.runtime.HttpJspBase
   permissionCollection.add( new RuntimePermission(
   "accessClassInPackage.org.apache.jasper.runtime") );
  +
   if (parentClassLoader instanceof URLClassLoader) {
   URL [] urls = parentClassLoader.getURLs();
   String jarUrl = null;
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Coyote/Http11 under load

[Keith Wannamaker]

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|Http11Http10
   |
Rq/sec26.9 25.89   | 18 27
kb/sec393  377 | 266404

Coyote/11 with Tomcat 3.3 is still a dog.  I would imagine
you'd get the similar numbers with any servlet as I changed
nothing but the servlet container between the tests.

I'm still investigating, but it may be easier for us to
move to 4.0.

Keith


| -Original Message-
| From: Remy Maucherat [mailto:remm@;apache.org]
| Sent: Thursday, November 07, 2002 2:22 AM
| To: Tomcat Developers List
| Subject: Re: Coyote/Http11 under load
| 
| 
| Keith Wannamaker wrote:
| 
| > Same box, same app, same test, with Tomcat 4.0.6's http10 and 11 adaptor:
| >
| > coyote/http1137rq/sec, 406kb/sec
| > http10   30rq/sec, 181kb/sec
| >
| > I've always held that 3.3 was more "lean and mean" than 4.0 but
| > now I'm wondering if this is just indicating some basic architectural
| > differences.
| 
| I don't understand those numbers. Even the two above (how can there be 
| twice the bandwidth with only 20% more requests if the bench is correct ?).
| I thought 3.3 + Coyote HTTP/1.1 was as fast as the default HTTP/1.0.
| 
| Remy
| 
| >
| > Keith
| >
| > | -Original Message-
| > | Subject: Coyote/Http11 under load
| > |
| > |
| > | I'm using http11 on a busy site with more or less Tomcat 3.3 head
| > | (3.3.2-dev).
| > |
| > | coyote/http11   4.2rq/sec, 63kb/sec
| > | http10  6.3rq/sec, 92kb/sec
|
| 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14372] New: - This bug causes problems with other applications when it executes.

[bugzilla]

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_bug.cgi?id=14372

This bug causes problems with other applications when it executes.

   Summary: This bug causes problems with other applications when it
executes.
   Product: Tomcat 4
   Version: 4.0.6 Final
  Platform: PC
OS/Version: Windows 9x
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I get this message when im running tomcat version 4.0.6, i also recieved the 
same bug running the latest version of tomcat 4. 
The message i get is:

An illegal error occured.
JAVA caused an invalid page fault in
module JVM.DLL at 0167:6d476cc7.
Once i get this message i cant run tomcat again and when i try i get a nessage 
keep saying an illegal error occured.  This bug also prevents me from loading 
some of my applications on my computer and dont let me open any web pages at 
all.  I have to re-boot my computer to beable to run tomcat and my other 
applications again.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[luehe]

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
messages_fr.properties messages_ja.properties
  Log:
  Report translation-time error if different page character encodings
  are detected in two or more of the following: the XML prolog of a JSP
  page, the pageEncoding attribute of the page directive of the JSP
  page, and in a JSP configuration element (whose URL pattern matches
  the page).
  
  Revision  ChangesPath
  1.15  +8 -19 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageInfo.java
  
  Index: PageInfo.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageInfo.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- PageInfo.java 6 Nov 2002 20:14:19 -   1.14
  +++ PageInfo.java 7 Nov 2002 22:19:13 -   1.15
  @@ -94,10 +94,7 @@
* (declaration).
* Only meaningful for XML documents.
*/
  -private String xmlEncoding = null;
  -
  -// Indicates whether page has XML declaration with encoding attribute
  -private boolean hasEncodingProlog = false;
  +private String xmlPrologEncoding = null;
   
   private int maxTagNesting = 0;
   private boolean scriptless = false;
  @@ -235,22 +232,14 @@
return pageEncoding;
   }
   
  -public void setXmlEncoding(String xmlEncoding) {
  - this.xmlEncoding = xmlEncoding;
  +public void setXmlPrologEncoding(String xmlPrologEncoding) {
  + this.xmlPrologEncoding = xmlPrologEncoding;
   }
   
  -public String getXmlEncoding() {
  - return xmlEncoding;
  +public String getXmlPrologEncoding() {
  + return xmlPrologEncoding;
   }
   
  -public void setHasEncodingProlog(boolean hasEncodingProlog) {
  - this.hasEncodingProlog = hasEncodingProlog;
  -}
  -
  -public boolean hasEncodingProlog() {
  - return hasEncodingProlog;
  -}
  -
   public int getMaxTagNesting() {
   return maxTagNesting;
   }
  
  
  
  1.26  +10 -6 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ParserController.java
  
  Index: ParserController.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ParserController.java,v
  retrieving revision 1.25
  retrieving revision 1.26
  diff -u -r1.25 -r1.26
  --- ParserController.java 7 Nov 2002 00:50:52 -   1.25
  +++ ParserController.java 7 Nov 2002 22:19:13 -   1.26
  @@ -192,9 +192,6 @@
   
if (isTopFile) {
pageInfo.setIsXml(isXml);
  - if (isXml) {
  - pageInfo.setXmlEncoding(encoding);
  - }
isTopFile = false;
} else {
compiler.getPageInfo().addDependant(absFileName);
  @@ -274,12 +271,19 @@
   ctxt, err);
sourceEnc = (String) ret[0];
boolean isEncodingSetInProlog = ((Boolean) ret[1]).booleanValue();
  - if (isTopFile) {
  - pageInfo.setHasEncodingProlog(isEncodingSetInProlog);
  - }
if (isEncodingSetInProlog) {
// Prolog present only in XML syntax
isXml = true;
  + if (isTopFile) {
  + String jspConfigPageEnc = pageInfo.getPageEncoding();
  + if (jspConfigPageEnc != null
  + && !jspConfigPageEnc.equals(sourceEnc)) {
  + err.jspError(
  + "jsp.error.page.prolog_config_encoding_conflict",
  + sourceEnc, jspConfigPageEnc);
  + }
  + pageInfo.setXmlPrologEncoding(sourceEnc);
  + }
} else if (sourceEnc.equals("UTF-8")) {
/*
 * We don't know if we're dealing with an XML document
  
  
  
  1.52  +29 -12
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java
  
  Index: Validator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java,v
  retrieving revision 1.51
  retrieving revision 1.52
  diff -u -r1.51 -r1.52
  --- Validator.java7 Nov 2002 18:34:19 -   1.51
  +++ Validator.java7 Nov 2002 22:19:13 -   1.52
  @@ -255,17 +255,34 @@
if (pageEncodingSeen) 
err.jspError(n, "jsp.error.page.multip

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security SecurityConfig.java

[jfarcand]

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 protected.
  
  Revision  ChangesPath
  1.5   +2 -2  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityConfig.java
  
  Index: SecurityConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityConfig.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- SecurityConfig.java   4 Nov 2002 05:16:23 -   1.4
  +++ SecurityConfig.java   7 Nov 2002 22:52:25 -   1.5
  @@ -76,7 +76,7 @@
   
   private final static String PACKAGE_ACCESS =  "sun.,"
   + "org.apache.catalina." 
  -+ ",org.apache.jsp."
  ++ ",org.apache.jasper."
   + ",org.apache.coyote."
   + ",org.apache.tomcat.";
   
  @@ -84,7 +84,7 @@
   + ",org.apache.catalina." 
   + ",org.apache.coyote."
   + ",org.apache.tomcat."
  -+ ",org.apache.jsp.";
  ++ ",org.apache.jasper.";
   /**
* List of protected package from conf/catalina.properties
*/
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Why No Digester in SRC Release?

[Micael]

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
Micael

---

This electronic mail  transmission and any accompanying documents contain 
information belonging to the sender which may be confidential and legally 
privileged.  This information is intended only for the use of the 
individual or entity to whom this electronic mail transmission was sent as 
indicated above. If you are not the intended recipient, any disclosure, 
copying, distribution, or action taken in reliance on the contents of the 
information contained in this transmission is strictly prohibited.  If you 
have received this transmission in error, please delete the message.  Thank you 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[costin]

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 the attribute is set later.
  Now it should be ok, and deal with errors in the error page.
  
  Revision  ChangesPath
  1.34  +5 -6  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/PageContextImpl.java
  
  Index: PageContextImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/PageContextImpl.java,v
  retrieving revision 1.33
  retrieving revision 1.34
  diff -u -r1.33 -r1.34
  --- PageContextImpl.java  7 Nov 2002 21:11:40 -   1.33
  +++ PageContextImpl.java  7 Nov 2002 23:33:38 -   1.34
  @@ -569,7 +569,6 @@
// part of forwarding the request to the error page, from
// throwing it if the response has not been committed (the response
// will have been committed if the error page is a JSP page).
  -Object 
origException=request.getAttribute("javax.servlet.error.exception");
   
request.setAttribute("javax.servlet.jsp.jspException", t);
request.setAttribute("javax.servlet.error.status_code",
  @@ -588,8 +587,8 @@
   
   Object 
newException=request.getAttribute("javax.servlet.error.exception");
   
  -if ((origException == null) || 
  -((newException != null) && (newException == origException))) {
  +// t==null means the attribute was not set.
  +if( (newException!= null) && (newException==t) ) {
   request.removeAttribute("javax.servlet.error.exception");
   }
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 12414] - Tag file defined in XML syntax does not seem to recignize import attribute in tag directive

[bugzilla]

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_bug.cgi?id=12414

Tag file defined in XML syntax does not seem to recignize import attribute in tag 
directive

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[luehe]

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  +8 -3  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java
  
  Index: JspDocumentParser.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java,v
  retrieving revision 1.24
  retrieving revision 1.25
  diff -u -r1.24 -r1.25
  --- JspDocumentParser.java1 Nov 2002 02:54:41 -   1.24
  +++ JspDocumentParser.java7 Nov 2002 23:52:07 -   1.25
  @@ -284,6 +284,11 @@
locator);
}
node = new Node.TagDirective(attrsCopy, start, current);
  + String imports = attrs.getValue("import");
  + // There can only be one 'import' attribute per tag directive
  + if (imports != null) {
  + ((Node.TagDirective) node).addImport(imports);
  + }
} else if (qName.equals(JSP_ATTRIBUTE_DIRECTIVE)) {
if (!isTagFile) {
throw new SAXParseException(
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[luehe]

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.
  
  Revision  ChangesPath
  1.53  +10 -8 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java
  
  Index: Validator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java,v
  retrieving revision 1.52
  retrieving revision 1.53
  diff -u -r1.52 -r1.53
  --- Validator.java7 Nov 2002 22:19:13 -   1.52
  +++ Validator.java8 Nov 2002 00:55:45 -   1.53
  @@ -1117,11 +1117,13 @@
tli.getShortName()));
   errMsg.append("");
   for (int i=0; i");
  -errMsg.append(errors[i].getId());
  -errMsg.append(": ");
  -errMsg.append(errors[i].getMessage());
  -errMsg.append("");
  + if (errors[i] != null) {
  + errMsg.append("");
  + errMsg.append(errors[i].getId());
  + errMsg.append(": ");
  + errMsg.append(errors[i].getMessage());
  + errMsg.append("");
  + }
   }
   }
   }
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Glenn Nielsen]

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 webapp mode (with its relevant options). This webapp mode would 
generate code and classes which should be deployed in the work 
directory, exactly the same as if they were dynamically compiled by 
Jasper (which has the big advantage of using only one big operation mode 
for everything). Single file mode is IMO useless (dynamic compilation 
works fine).
- In Tomcat 4.1, the options will stay in for compatibility, but the 
usage help will be modified to be the same as Tomcat 5.

It has to be noted that:
- The JSP runtime is now very efficient. The old webapp mode (with its 
static web.xml) is a hack (and a 100% proprietary one at that).
- Precompilation should only occur at webapp deployment time in the 
general case (the generated code is closely tied to the Jasper runtime 
release).
- Additional features could be added to the manager servlet to, for 
example, cause precompilation of the deployed webapp in a separate process.
- I am -1 to returning to the old "webapp" option behavior (ie, the 
generated files should by default be deployed in the work directory, not 
/WEB-INF/classes).


+1 [ ] Remove the options
-1 [ ] Do not remove the options


Note: Users may vote, but only committers have binding votes.

Remy


I agree that JSPC needs to be simplified and that the webapp mode should
be retained.  But the webapp mode should allow for a war file to be generated
which is self contained including the precompiled JSP classses.  And for the
generated war to be able to run from the war file with no need to unpack it.

Also I agree that this feature is a proprietary feature of Tomcat and we
should no longer try to generate a war that can be deployed in any container.

There may be a way to do this:

Put the generated JSP class files in a /WEB-INF/jspwork/ directory.  This work
directory would only be used by jasper for loading jsp pages, the normal work
directory would still be used for all other things.

Add the "jspwork" attribute to the DefaultContext and Context config elements.
This attribute would specify the directory path within the war file to use for
loading the JSP page classes from by Jasper.

This would allow JSPC to create a war file which was self contained including
the precompiled JSP page classes and be runnable directly from the war or
unpacked into a directory.

+1 if we modify Tomcat & Jasper to support precompiled JSP pages running from a
self contained war file.

Regards,

Glenn




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed jspc refactoring

[Jeanfrancois Arcand]

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 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 relevant options). This webapp mode would 
generate code and classes which should be deployed in the work 
directory, exactly the same as if they were dynamically compiled by 
Jasper (which has the big advantage of using only one big operation 
mode for everything). Single file mode is IMO useless (dynamic 
compilation works fine).
- In Tomcat 4.1, the options will stay in for compatibility, but the 
usage help will be modified to be the same as Tomcat 5.

It has to be noted that:
- The JSP runtime is now very efficient. The old webapp mode (with its 
static web.xml) is a hack (and a 100% proprietary one at that).
- Precompilation should only occur at webapp deployment time in the 
general case (the generated code is closely tied to the Jasper runtime 
release).
- Additional features could be added to the manager servlet to, for 
example, cause precompilation of the deployed webapp in a separate 
process.
- I am -1 to returning to the old "webapp" option behavior (ie, the 
generated files should by default be deployed in the work directory, 
not /WEB-INF/classes).


+1 [ ] Remove the options
-1 [ ] Do not remove the options


Note: Users may vote, but only committers have binding votes.

Remy


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[kinman]

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  +63 -6 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java
  
  Index: JspDocumentParser.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java,v
  retrieving revision 1.25
  retrieving revision 1.26
  diff -u -r1.25 -r1.26
  --- JspDocumentParser.java7 Nov 2002 23:52:07 -   1.25
  +++ JspDocumentParser.java8 Nov 2002 03:03:01 -   1.26
  @@ -359,9 +359,66 @@
if ((current instanceof Node.JspText) || !isAllSpace) {
Mark start = new Mark(path, locator.getLineNumber(),
  locator.getColumnNumber());
  - char[] bufCopy = new char[len];
  - System.arraycopy(buf, offset, bufCopy, 0, len);
  - new Node.TemplateText(bufCopy, start, current);
  +
  + CharArrayWriter ttext = new CharArrayWriter();
  + int limit = offset + len;
  + int lastCh = 0;
  + for (int i = offset; i < limit; i++) {
  + int ch = buf[i];
  + if (lastCh == '$' && ch == '{') {
  + char[] bufCopy = ttext.toCharArray();
  + if (bufCopy.length > 0) {
  + new Node.TemplateText(bufCopy, start, current);
  + ttext = new CharArrayWriter();
  + }
  + // following "${" to first unquoted "}"
  + i++;
  + boolean singleQ = false;
  + boolean doubleQ = false;
  + lastCh = 0;
  + for (; ; i++) {
  + if (i >= limit) {
  + throw new SAXParseException(
  + err.getString("jsp.error.unterminated", "${"),
  + locator);
  +
  + }
  + ch = buf[i];
  + if (lastCh == '\\' && (singleQ || doubleQ)) {
  + ttext.write(ch);
  + lastCh = 0;
  + continue;
  + }
  + if (ch == '}') {
  + new Node.ELExpression(ttext.toCharArray(), start, current);
  + ttext = new CharArrayWriter();
  + break;
  + }
  + if (ch == '"')
  + doubleQ = !doubleQ;
  + else if (ch == '\'')
  + singleQ = !singleQ;
  +
  + ttext.write(ch);
  + lastCh = ch;
  + }
  + } else {
  + if( (lastCh == '$') && (ch != '{') ) {
  +ttext.write( '$' );
  +}
  +if( ch != '$' ) {
  +ttext.write( ch );
  +}
  +}
  +lastCh = ch;
  + }
  + if (lastCh == '$') {
  + ttext.write('$');
  + }
  + char[] bufCopy = ttext.toCharArray();
  + if (bufCopy.length > 0) {
  + new Node.TemplateText(bufCopy, start, current);
  + }
}
   }
   
  
  
  
  1.18  +18 -3 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageDataImpl.java
  
  Index: PageDataImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageDataImpl.java,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- PageDataImpl.java 7 Nov 2002 18:34:19 -   1.17
  +++ PageDataImpl.java 8 Nov 2002 03:03:01 -   1.18
  @@ -306,6 +306,21 @@
appendTag(JSP_SCRIPTLET, n.getAttributes(), null, n.getText());
}
   
  + public void visit(Node.ELExpression n) throws JasperException {
  + if (!n.isXmlSyntax()) {
  + buf.append("<").append(JSP_TEXT);
  + buf.append(" jsp:id=\"");
  + buf.append(jspId++).append("\">");
  + }
  + buf.append("${");
  + buf.append(n.getText());
  + buf.append("}");
  + if (!n.isXmlSyntax()) {
  + buf.append(JSP_TEXT_END);
  + }
  + buf.append("\n");
  + }
  +
public void visit(Node.IncludeAction n) throws JasperException {
appendTag(JSP_INCLUDE, n.getAttributes(), n.getBody(), null);
}
  
  
  

--
To unsubscribe, e-mail:   

DO NOT REPLY [Bug 14377] New: - Error when accessing JSP. But, pure servlets are working.

[bugzilla]

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_bug.cgi?id=14377

Error when accessing JSP. But, pure servlets are working.

   Summary: Error when accessing JSP. But, pure servlets are
working.
   Product: Tomcat 4
   Version: 4.0.3 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Using J2sdk 1.4.1, Tomcat4.0.3.

When I click the link for JSP Examples comes with tomcat, it reports INTERNAL 
SERVER ERROR. But, when I test the Servelet Examples, it is Working well.

Any Instalation problem / version mismatch ?

Error is attached below. (This is when I select the URL - 
http://localhost:8000/examples/jsp/num/numguess.jsp)


type Exception report

message Internal Server Error

description The server encountered an internal error (Internal Server Error) 
that prevented it from fulfilling this request.

exception 

javax.servlet.ServletException: sun/tools/javac/Main
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:485)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:243)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke
(ContainerBase.java:943)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:190)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke
(AuthenticatorBase.java:475)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke
(ContainerBase.java:943)
at org.apache.catalina.core.StandardContext.invoke
(StandardContext.java:2343)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:180)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke
(ErrorDispatcherValve.java:170)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
at org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:170)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
at org.apache.catalina.valves.AccessLogValve.invoke
(AccessLogValve.java:468)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke
(ContainerBase.java:943)
at org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:174)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke
(ContainerBase.java:943)
at org.apache.catalina.connector.http.HttpProcessor.process
(HttpProcessor.java:1012)
at org.apache.catalina.connector.http.HttpProcessor.run
(HttpProcessor.java:1107)
at java.lang.Thread.run(Thread.java:479)


root cause 

java.lang.NoClassDefFoundError: sun/tools/javac/Main
at org.apache.jasper.compiler.SunJavaCompiler.compile
(SunJavaCompiler.java:136)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:272)
at org.apache.jasper.servlet.JspServlet.loadJSP(JspServlet.java:552)
at 
org.apache.jasper.servlet.JspServlet$JspServletWrapper.loadIfNecessary
(JspServlet.java:177)
at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service
(JspServlet.java:189)
at org.apache.jasper.servlet.JspServlet.serviceJspFile
(JspServlet.java:382)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.Applica

auth bug fix for 4.0.6

[Keith Wannamaker]

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 wrong behavior:
 GET /foo   ->  401
 GET /foo with auth ->  301 to /foo/
 GET /foo/ with auth->  200
 GET /bar with auth  .. (browser will send auth to other realms!)

With the following patch it will exhibit this correct behavior:
 GET /foo   ->  301 to /foo/
 GET /foo/  ->  401
 GET /foo/ with auth->  200
 GET /bar  WITHOUT auth


I'll be glad to ci it, but those more in the know may
have a better location for the fix in mind.

Keith


Index: catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java
===
RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java,v
retrieving revision 1.23.2.5
diff -u -r1.23.2.5 AuthenticatorBase.java
--- catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java
27 Feb 2002 17:42:58 -  1.23.2.5
+++ catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java
8 Nov 2002 05:25:06 -
@@ -422,8 +422,18 @@
 context.invokeNext(request, response);
 return;
 }
 HttpRequest hrequest = (HttpRequest) request;
 HttpResponse hresponse = (HttpResponse) response;
+
+// Do not authenticate prior to redirects
+String uri = ((HttpServletRequest) request.getRequest()).getRequestURI();
+if (uri.length() > 0 && ! uri.endsWith("/") &&
+uri.equals(request.getContext().getName())) {
+context.invokeNext(request, response);
+return;
+}
+
 if (debug >= 1)
 log("Security checking request " +
 ((HttpServletRequest) request.getRequest()).getMethod() + " " +


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3 Tomcat3Request.java

[billbarker]

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  ChangesPath
  1.11  +0 -22 
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3/Tomcat3Request.java
  
  Index: Tomcat3Request.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3/Tomcat3Request.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- Tomcat3Request.java   19 Jun 2002 18:21:24 -  1.10
  +++ Tomcat3Request.java   8 Nov 2002 06:19:51 -   1.11
  @@ -210,36 +210,14 @@
   
   public MessageBytes remoteAddr() {
if( remoteAddrMB.isNull() ) {
  - try {
  - remoteAddrMB.duplicate(coyoteRequest.remoteAddr());
  - } catch(IOException iex) { // can't happen
  - }
  - }
  - if( remoteAddrMB.isNull() ) {
coyoteRequest.action( ActionCode.ACTION_REQ_HOST_ATTRIBUTE, coyoteRequest 
);
  - try{
  - remoteAddrMB.duplicate( coyoteRequest.remoteAddr() );
  - remoteHostMB.duplicate( coyoteRequest.remoteHost() );
  - } catch(IOException iex) { // can't happen
  - }
}
return remoteAddrMB;
   }
   
   public MessageBytes remoteHost() {
if( remoteHostMB.isNull() ) {
  - try {
  - remoteHostMB.duplicate(coyoteRequest.remoteHost());
  - } catch(IOException iex) { // can't happen
  - }
  - }
  - if( remoteHostMB.isNull() ) {
coyoteRequest.action( ActionCode.ACTION_REQ_HOST_ATTRIBUTE, coyoteRequest 
);
  - try{
  - remoteAddrMB.duplicate( coyoteRequest.remoteAddr() );
  - remoteHostMB.duplicate( coyoteRequest.remoteHost() );
  - } catch(IOException iex) { // can't happen
  - }
}
return remoteHostMB;
   }
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3 Tomcat3Adapter.java

[billbarker]

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  
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3/Tomcat3Adapter.java
  
  Index: Tomcat3Adapter.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3/Tomcat3Adapter.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- Tomcat3Adapter.java   10 May 2002 23:30:18 -  1.3
  +++ Tomcat3Adapter.java   8 Nov 2002 06:20:59 -   1.4
  @@ -112,10 +112,11 @@
   resA=(Tomcat3Response)reqA.getResponse();
   }
   
  - 
  - cm.service( reqA, resA );
  -
  -reqA.recycle();
  -resA.recycle();
  + try {
  + cm.service( reqA, resA );
  + } finally {
  + reqA.recycle();
  + resA.recycle();
  + }
   }
   }
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Coyote/Http11 under load

[Bill Barker]

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 find anything there just by looking
(and, this is one of the thinnest packages you can find).  The
CoyoteConnector add a preService method (which has a similar method in 4.x),
and a postRequest method (which is presumably for Jk2, since it does nothing
for HTTP).

I'm not going to have time for probably at least a couple of weeks to be
able to run 3.3.2-dev under OptimizeIt to try and pin down where the bottle
neck is.  But if someone else has time, I can try and answer the "why does
this do that" type of questions.

- Original Message -
From: "Keith Wannamaker" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, November 06, 2002 9:49 PM
Subject: RE: Coyote/Http11 under load


> Same box, same app, same test, with Tomcat 4.0.6's http10 and 11 adaptor:
>
> coyote/http1137rq/sec, 406kb/sec
> http10   30rq/sec, 181kb/sec
>
> I've always held that 3.3 was more "lean and mean" than 4.0 but
> now I'm wondering if this is just indicating some basic architectural
> differences.
>
> Keith
>
> | -Original Message-
> | Subject: Coyote/Http11 under load
> |
> |
> | I'm using http11 on a busy site with more or less Tomcat 3.3 head
> | (3.3.2-dev).
> |
> | coyote/http11   4.2rq/sec, 63kb/sec
> | http10  6.3rq/sec, 92kb/sec
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: auth bug fix for 4.0.6

[Bill Barker]

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, November 07, 2002 9:36 PM
Subject: auth bug fix for 4.0.6


> 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 wrong behavior:
>  GET /foo   ->  401
>  GET /foo with auth ->  301 to /foo/
>  GET /foo/ with auth->  200
>  GET /bar with auth  .. (browser will send auth to other realms!)
>
> With the following patch it will exhibit this correct behavior:
>  GET /foo   ->  301 to /foo/
>  GET /foo/  ->  401
>  GET /foo/ with auth->  200
>  GET /bar  WITHOUT auth
>
>
> I'll be glad to ci it, but those more in the know may
> have a better location for the fix in mind.
>
> Keith
>
>
> Index:
catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java
> ===
> RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenti
cator/AuthenticatorBase.java,v
> retrieving revision 1.23.2.5
> diff -u -r1.23.2.5 AuthenticatorBase.java
> ---
catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java
> 27 Feb 2002 17:42:58 -  1.23.2.5
> +++
catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java
> 8 Nov 2002 05:25:06 -
> @@ -422,8 +422,18 @@
>  context.invokeNext(request, response);
>  return;
>  }
>  HttpRequest hrequest = (HttpRequest) request;
>  HttpResponse hresponse = (HttpResponse) response;
> +
> +// Do not authenticate prior to redirects
> +String uri = ((HttpServletRequest)
request.getRequest()).getRequestURI();
> +if (uri.length() > 0 && ! uri.endsWith("/") &&
> +uri.equals(request.getContext().getName())) {
> +context.invokeNext(request, response);
> +return;
> +}
> +
>  if (debug >= 1)
>  log("Security checking request " +
>  ((HttpServletRequest) request.getRequest()).getMethod() +
" " +
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: auth bug fix for 4.0.6

[Remy Maucherat]

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 there). Tomcat 4.0.x is probably ok.

I also don't agree with Keith's interpretation depending on what the 
constraint is. Can you give examples ?

Remy


>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 wrong behavior:
> GET /foo   ->  401
> GET /foo with auth ->  301 to /foo/
> GET /foo/ with auth->  200
> GET /bar with auth  .. (browser will send auth to other realms!)
>
>With the following patch it will exhibit this correct behavior:
> GET /foo   ->  301 to /foo/
> GET /foo/  ->  401
> GET /foo/ with auth->  200
> GET /bar  WITHOUT auth
>
>
>I'll be glad to ci it, but those more in the know may
>have a better location for the fix in mind.
>
>Keith
>
>
>Index:

catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java

>===
>RCS file:

/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenti
cator/AuthenticatorBase.java,v

>retrieving revision 1.23.2.5
>diff -u -r1.23.2.5 AuthenticatorBase.java
>---

catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java

>27 Feb 2002 17:42:58 -  1.23.2.5
>+++

catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java

>8 Nov 2002 05:25:06 -
>@@ -422,8 +422,18 @@
> context.invokeNext(request, response);
> return;
> }
> HttpRequest hrequest = (HttpRequest) request;
> HttpResponse hresponse = (HttpResponse) response;
>+
>+// Do not authenticate prior to redirects
>+String uri = ((HttpServletRequest)

request.getRequest()).getRequestURI();

>+if (uri.length() > 0 && ! uri.endsWith("/") &&
>+uri.equals(request.getContext().getName())) {
>+context.invokeNext(request, response);
>+return;
>+}
>+
> if (debug >= 1)
> log("Security checking request " +
> ((HttpServletRequest) 
request.getRequest()).getMethod() +

" " +

>
>--
>To unsubscribe, e-mail:



>For additional commands, e-mail:





--
To unsubscribe, e-mail:
For additional commands, e-mail:





--
To unsubscribe, e-mail:   
For additional commands, e-mail: