Re: [5.0] Input optimization

[Chris Brown]

> If you could come up with a better name for the "substract" method ;-)
> It's supposed to be the opposite of append.

prepend() ?


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

Re: cvs commit:jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5InputBuffer.java

[Lacoste (Frisurf)]

On Sun, 2003-01-05 at 18:20, [EMAIL PROTECTED] wrote:
> remm2003/01/05 09:20:41
> 
>   Modified:coyote/src/java/org/apache/coyote/tomcat5 InputBuffer.java
>   Log:
>   - Fix skip and reset.
>   
>   Revision  ChangesPath
>   1.3   +14 -9 
>jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/InputBuffer.java
>   
>   Index: InputBuffer.java
>   ===
>   RCS file: 
>/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/InputBuffer.java,v
>   retrieving revision 1.2
>   retrieving revision 1.3
>   diff -u -r1.2 -r1.3
>   --- InputBuffer.java5 Jan 2003 13:26:39 -   1.2
>   +++ InputBuffer.java5 Jan 2003 17:20:41 -   1.3
>   @@ -413,13 +413,19 @@
>
>long nRead = 0;
>while (nRead < n) {
>   -if (cb.getLength() > n) {
>   +if (cb.getLength() >= n) {
>cb.setOffset(cb.getStart() + (int) n);
>nRead = n;
>} else {
>nRead += cb.getLength();
>cb.setOffset(cb.getEnd());
>   -int nb = realReadChars(cb.getChars(), 0, cb.getEnd());
>   +int toRead = 0;
>   +if (cb.getChars().length < (n - nRead)) {
>   +toRead = cb.getChars().length;
>   +} else {
>   +toRead = (int) (n - nRead);
>   +}
>   +int nb = realReadChars(cb.getChars(), 0, toRead);

what about

int nb = realReadChars(cb.getChars(), 
   0, 
   Math.max(cb.getChars().length, (int) (n -
nRead)));

?

Jerome

-- 
Jerome Lacoste (Frisurf) <[EMAIL PROTECTED]>
CoffeeBreaks


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

Re: [5.0] Input optimization

[Lacoste (Frisurf)]

On Sun, 2003-01-05 at 18:40, Remy Maucherat wrote:
> Costin Manolache wrote:
> > Great ! 
> 
> If you could come up with a better name for the "substract" method ;-)
> It's supposed to be the opposite of append.

I found this:
>From The Collaborative International Dictionary of English v.0.44
[gcide]:

  Disappendent \Dis`ap*pend"ent\, a.
 Freed from a former connection or dependence; disconnected.
 [R.]
 [1913 Webster]

But I don't like it much.

untie() neither. Perhaps changing append() would make it easier to find
an opposite ?

J


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

where to download tomcat 4.1 nightly builds?

[Andreas Schildbach]

hi all,

where can i download the latest tomcat 4.1 nightly build?
the jakarta download page gets me to
http://jakarta.apache.org/builds/jakarta-tomcat-4.0/nightly/,
which appears to be empty.

regards,

andreas



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

Re: where to download tomcat 4.1 nightly builds?

[Mats Nyberg]

that seems right. i can't find any nightly builds of any 4.1.x tomcats
either.

why don't you CVS it?

send me an email and i'll get yo a fresh zip from the CVS if you don't
fetch one for yourself.


On Mon, 2003-01-06 at 08:10, Andreas Schildbach wrote:
> hi all,
> 
> where can i download the latest tomcat 4.1 nightly build?
> the jakarta download page gets me to
> http://jakarta.apache.org/builds/jakarta-tomcat-4.0/nightly/,
> which appears to be empty.
> 
> regards,
> 
> andreas
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
-- 
Mats Nyberg <[EMAIL PROTECTED]>


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

Re: [5.0] Input optimization

[Ken Horn]

chop() / cut() ?



   

  Jerome "Lacoste  

  (Frisurf)"   To:   Tomcat Developers List 
<[EMAIL PROTECTED]>
   Subject:  Re: [5.0] Input optimization  

   

  06/01/2003 08:37 

  Please respond to

  "Tomcat  

  Developers List" 

   

   





On Sun, 2003-01-05 at 18:40, Remy Maucherat wrote:
> Costin Manolache wrote:
> > Great !
>
> If you could come up with a better name for the "substract" method ;-)
> It's supposed to be the opposite of append.

I found this:
>From The Collaborative International Dictionary of English v.0.44
[gcide]:

  Disappendent \Dis`ap*pend"ent\, a.
 Freed from a former connection or dependence; disconnected.
 [R.]
 [1913 Webster]

But I don't like it much.

untie() neither. Perhaps changing append() would make it easier to find
an opposite ?

J


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





--

This e-mail may contain confidential and/or privileged information. If you are not the 
intended recipient (or have received this e-mail in error) please notify the sender 
immediately and destroy this e-mail. Any unauthorized copying, disclosure or 
distribution of the material in this e-mail is strictly forbidden.



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

DO NOT REPLY [Bug 10948] - JNDI lookup in servlet init fails

[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=10948

JNDI lookup in servlet init fails





--- Additional Comments From [EMAIL PROTECTED]  2003-01-06 14:18 ---
I also believe this bug still exists in latest release (4.1.18 LE).

I have found that adding ResourceLink's to a webapps context fixes allows 
lookups in init().  However, I do not want to use ResourceLink because I need 
to remotely deploy using Manager, and there is not equivalent of ResourceLink 
in the web.xml specification (right?).

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

RE: where to download tomcat 4.1 nightly builds?

[Kevin Jones]

ditto for 5.0. Where are the nightlies gone - I've downloaded them in
the past but they seem to have disappeared off the site?

Kevin Jones
Developmentor
www.develop.com

> -Original Message-
> From: Andreas Schildbach [mailto:[EMAIL PROTECTED]] 
> Sent: 06 January 2003 09:10
> To: [EMAIL PROTECTED]
> Subject: where to download tomcat 4.1 nightly builds?
> 
> 
> hi all,
> 
> where can i download the latest tomcat 4.1 nightly build?
> the jakarta download page gets me to
> http://jakarta.apache.org/builds/jakarta-tomcat-4.0/nightly/,
> which appears to be empty.
> 
> regards,
> 
> andreas
> 
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 


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

DO NOT REPLY [Bug 15819] New: - Duplicate context listener entries in server.xml when saving

[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=15819

Duplicate context listener entries in server.xml when saving

   Summary: Duplicate context listener entries in server.xml when
saving
   Product: Tomcat 4
   Version: 4.1.18
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Webapps:Administration
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When commiting changes with the admin tool, or deploying webapps with manager, 
an extra  tag is added to every context in server.xml.

So over time, server.xml grows and grows!

The Listener entries are all exactly the same.

An example of how this looks in server.xml:


  
  
  
  
  
  
  


  
  
  
  
  
  
  


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

DO NOT REPLY [Bug 10948] - JNDI lookup in servlet init fails

[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=10948

JNDI lookup in servlet init fails





--- Additional Comments From [EMAIL PROTECTED]  2003-01-06 17:10 ---
There is no mechanism for defining resource links in web.xml because they are a
Tomcat specific feature.  However, if you use the manager webapp's "deploy"
command, you can include a "META-INF/context.xml" file in the WAR that Tomcat
will respect -- in there you can put a  element (including the nested
resource definitions or resource links).

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

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/config manager.xml

[glenn]

glenn   2003/01/06 09:41:15

  Modified:webapps/tomcat-docs/config manager.xml
  Log:
  Fix documenation bug 7139, thanks to Daniel Rall
  
  Revision  ChangesPath
  1.4   +1 -1  jakarta-tomcat-4.0/webapps/tomcat-docs/config/manager.xml
  
  Index: manager.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/manager.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- manager.xml   28 Aug 2002 17:04:07 -  1.3
  +++ manager.xml   6 Jan 2003 17:41:15 -   1.4
  @@ -370,7 +370,7 @@
 Name of the database column, contained in the specified
 session table, that contains the maxInactiveInterval
 property of this session.  The column type must accept a
  -  Jave integer (32 bits).
  +  Java integer (32 bits).
   
   
   
  
  
  

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

cvs commit: jakarta-tomcat-catalina/webapps/docs/config manager.xml

[glenn]

glenn   2003/01/06 09:41:57

  Modified:webapps/docs/config manager.xml
  Log:
  Fix documenation bug 7139, thanks to Daniel Rall
  
  Revision  ChangesPath
  1.3   +1 -1  jakarta-tomcat-catalina/webapps/docs/config/manager.xml
  
  Index: manager.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/config/manager.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- manager.xml   28 Aug 2002 16:46:02 -  1.2
  +++ manager.xml   6 Jan 2003 17:41:57 -   1.3
  @@ -370,7 +370,7 @@
 Name of the database column, contained in the specified
 session table, that contains the maxInactiveInterval
 property of this session.  The column type must accept a
  -  Jave integer (32 bits).
  +  Java integer (32 bits).
   
   
   
  
  
  

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

DO NOT REPLY [Bug 7139] - Typo in manager.xml documentation

[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=7139

Typo in manager.xml documentation

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-01-06 17:44 ---
Thanks for submitting the documentation patch.  It has been applied to both
Tomcat 5 and Tomcat 4.1 documentation.

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

DO NOT REPLY [Bug 7139] - Typo in manager.xml documentation

[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=7139

Typo in manager.xml documentation

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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

Re: where to download tomcat 4.1 nightly builds?

[Petr Jiricka]

I was able to find them for Tomcat 5:

http://jakarta.apache.org/builds/jakarta-tomcat/nightly-5/

but not for Tomcat 4.1.

Speaking of 5.0, is it known when the next milestone/beta of Tomcat 5 
will be released ? Is there any scheduled ?

Thanks
Petr

Kevin Jones wrote:

ditto for 5.0. Where are the nightlies gone - I've downloaded them in
the past but they seem to have disappeared off the site?

Kevin Jones
Developmentor
www.develop.com



-Original Message-
From: Andreas Schildbach [mailto:[EMAIL PROTECTED]] 
Sent: 06 January 2003 09:10
To: [EMAIL PROTECTED]
Subject: where to download tomcat 4.1 nightly builds?


hi all,

where can i download the latest tomcat 4.1 nightly build?
the jakarta download page gets me to
http://jakarta.apache.org/builds/jakarta-tomcat-4.0/nightly/,
which appears to be empty.

regards,

andreas



--
To unsubscribe, e-mail:   
 [EMAIL PROTECTED]>
For 
additional commands, 
e-mail: 



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





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

Re: where to download tomcat 4.1 nightly builds?

[Remy Maucherat]

Petr Jiricka wrote:

I was able to find them for Tomcat 5:

http://jakarta.apache.org/builds/jakarta-tomcat/nightly-5/

but not for Tomcat 4.1.

Speaking of 5.0, is it known when the next milestone/beta of Tomcat 5 
will be released ? Is there any scheduled ?

Features are being added, so it got delayed.
Tomcat 5 is supposed to be very easy to build from CVS 
(http://jakarta.apache.org/tomcat/building.html), so IMO there's little 
point in having nightly builds.

Remy


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

Re: cvs commit: jakarta-tomcat-5/resources mbeans.xml

[Remy Maucherat]

[EMAIL PROTECTED] wrote:

costin  2003/01/05 22:09:47

  Added:   resources mbeans.xml
  Log:
  A small test file for the 'jmx-ified' config / profile.
  
  Each component will be defined as an mbean - with explicit control
  over class loaders. This version uses ant ( it's much easier ), but
  a standalone version using mlet-like syntax will work the same.

That's probably dumb, but I couldn't find the classloader task.

Remy


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

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/collections LRUCache.java

[remm]

remm2003/01/06 10:34:40

  Modified:util/java/org/apache/tomcat/util/collections LRUCache.java
  Log:
  - Minor update to LRUCache.
  
  Revision  ChangesPath
  1.3   +18 -6 
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/collections/LRUCache.java
  
  Index: LRUCache.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/collections/LRUCache.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- LRUCache.java 31 Dec 2001 18:20:04 -  1.2
  +++ LRUCache.java 6 Jan 2003 18:34:40 -   1.3
  @@ -88,12 +88,11 @@
   {
   currentSize = 0;
   cacheSize = i;
  +nodes = new Hashtable(i);
   }
   
   public Object get(Object key)
   {
  -if(nodes == null)
  -return null;
   CacheNode node = (CacheNode)nodes.get(key);
   if(node != null)
   {
  @@ -108,8 +107,6 @@
   
   public void put(Object key, Object value)
   {
  -if(nodes == null)
  -nodes = new Hashtable(cacheSize);
   CacheNode node = (CacheNode)nodes.get(key);
   if(node == null)
   {
  @@ -131,10 +128,25 @@
   nodes.put(key, node);
   }
   
  +public Object remove(Object key) {
  +CacheNode node = (CacheNode)nodes.get(key);
  +if (node != null) {
  +if (node.prev != null) {
  +node.prev.next = node.next;
  +}
  +if (node.next != null) {
  +node.next.prev = node.prev;
  +}
  +if (last == node)
  +last = node.prev;
  +if (first == node)
  +first = node.next;
  +}
  +return node;
  +}
  +
   public void clear()
   {
  -if(nodes != null)
  -nodes.clear();
   first = null;
   last = null;
   }
  
  
  

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

cvs commit: jakarta-tomcat-connectors/coyote build.xml

[remm]

remm2003/01/06 10:35:20

  Modified:coyote   build.xml
  Log:
  - Fix javadoc task.
  
  Revision  ChangesPath
  1.15  +2 -2  jakarta-tomcat-connectors/coyote/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/build.xml,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- build.xml 13 Aug 2002 15:41:02 -  1.14
  +++ build.xml 6 Jan 2003 18:35:20 -   1.15
  @@ -287,7 +287,7 @@
  description="Create component Javadoc documentation">
   mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/util build.xml

[remm]

remm2003/01/06 10:36:18

  Modified:util build.xml
  Log:
  - Fix javadoc task.
  
  Revision  ChangesPath
  1.15  +13 -8 jakarta-tomcat-connectors/util/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/util/build.xml,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- build.xml 15 Oct 2002 21:02:13 -  1.14
  +++ build.xml 6 Jan 2003 18:36:18 -   1.15
  @@ -22,6 +22,15 @@
   
   
   
  +
  +
  +
  +
  +
  +
  +
  +
  +
   
   
   
  @@ -49,12 +58,7 @@
   optimize="off"
   verbose="off"
   excludes="**/CVS/**">
  -
  -
  -
  -
  -
  -
  +
   
   
   
  @@ -97,8 +101,9 @@
 version="true"
 windowtitle="Tomcat Utilities Documentation"
doctitle="Tomcat Utilities"
  -   bottom="Copyright © 2001 Apache Software Foundation.  All 
Rights Reserved."
  - />
  +   bottom="Copyright © 2001 Apache Software Foundation.  All 
Rights Reserved.">
  +
  +
   
   
   
  
  
  

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

cvs commit: jakarta-tomcat-catalina/webapps/docs build.xml index.xml project.xml

[remm]

remm2003/01/06 10:36:59

  Modified:webapps/docs build.xml index.xml project.xml
  Log:
  - Include javadocs for Coyote.
  
  Revision  ChangesPath
  1.3   +26 -2 jakarta-tomcat-catalina/webapps/docs/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/build.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- build.xml 16 Nov 2002 14:59:07 -  1.2
  +++ build.xml 6 Jan 2003 18:36:59 -   1.3
  @@ -65,11 +65,35 @@
 
   
   
  +
  +
  +
  +
  +
  +  
  +
  +
  +
  +
  +
  +
  +
  +  
  +
  +
  +
  +
  +
  +
  +
  +  
  +
  +
   
  -
  +
   
   
  -
  +
 
   
   
  
  
  
  1.4   +22 -0 jakarta-tomcat-catalina/webapps/docs/index.xml
  
  Index: index.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/index.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- index.xml 8 Dec 2002 13:42:10 -   1.3
  +++ index.xml 6 Jan 2003 18:36:59 -   1.4
  @@ -135,6 +135,28 @@
   
   
   
  +
  +
  +Coyote includes a low level connector API, a set of low level utility
  +objects, as well as high performance implementations for the HTTP/1.1, AJP 1.3
  +and JNI protocols. Catalina is based on the Coyote API.
  +
  +The following documents are for Java developers who wish to contribute to
  +the development of the Coyote connector portion of Tomcat
  +itself, or to better understand its internal architecture and operation.
  +
  +
  +Coyote API 
Javadocs
  +- Javadoc API documentation for the Coyote API.
  +Coyote HTTP/1.1 
Javadocs
  +- Javadoc API documentation for the Coyote HTTP/1.1 connector.
  +Util API Javadocs
  +- Javadoc API documentation for the Coyote Utilties API.
  +
  +
  +
  +
  +
   
   
   The following documents are for Java developers who wish to contribute to
  
  
  
  1.6   +7 -1  jakarta-tomcat-catalina/webapps/docs/project.xml
  
  Index: project.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/project.xml,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- project.xml   16 Nov 2002 14:59:07 -  1.5
  +++ project.xml   6 Jan 2003 18:36:59 -   1.6
  @@ -29,7 +29,7 @@
   
   
   
  -
  +
   
   
  @@ -52,6 +52,12 @@
   
   
   
  +
  +
  +
  +
  +
  +
   
   
   
  
  
  

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

cvs commit: jakarta-tomcat-5/resources mbeans.xml

[remm]

remm2003/01/06 10:38:31

  Modified:resources mbeans.xml
  Log:
  - Harmonize property names with the ones used in build.properties.
  - Load the main properties.
  
  Revision  ChangesPath
  1.2   +9 -2  jakarta-tomcat-5/resources/mbeans.xml
  
  Index: mbeans.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/resources/mbeans.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- mbeans.xml6 Jan 2003 06:09:47 -   1.1
  +++ mbeans.xml6 Jan 2003 18:38:31 -   1.2
  @@ -1,4 +1,11 @@
   
  +
  +  
  +  
  +  
  +  
  +  
  +
 
 
 
  @@ -7,7 +14,7 @@
   
 
   
  -  
  +  
 

   
  @@ -15,7 +22,7 @@
   
 
 
  -  
  +  
   
 
   
  
  
  

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

Tomcat 4.0.1 vs. Tomcat 4.0.6

[Jindong Li]

Hi there,

Not sure if I've come to the right place...but here's my question anyway...

I've been trying out Tomcat 4.0.6, one thing we noticed is that once our
servlets are instantiated, it takes really a long time to shut down Tomcat -
I don't think it's anything related to the way our servlets are written, I
looked up in the mail archive and did not really find anything very useful,
any idea at all why this is happening?

With Tomcat 4.0.1 though, we didn't not have this problem at all, even if
our servlets are instantiated, shutting down Tomcat takes no time at all...

Thanks in advance and appreciate any input on this...

Jindong.

Re: cvs commit: jakarta-tomcat-5/resources mbeans.xml

[Costin Manolache]

Remy Maucherat wrote:

> [EMAIL PROTECTED] wrote:
>> costin  2003/01/05 22:09:47
>> 
>>   Added:   resources mbeans.xml
>>   Log:
>>   A small test file for the 'jmx-ified' config / profile.
>>   
>>   Each component will be defined as an mbean - with explicit control
>>   over class loaders. This version uses ant ( it's much easier ), but
>>   a standalone version using mlet-like syntax will work the same.
> 
> That's probably dumb, but I couldn't find the classloader task.

Sorry - my mistake.

Requires ant1.6 ( i.e. the HEAD right now ).

The classloader task will add jars to the "core" ant loader - so you
don't have to place them in ant/lib or CLASSPATH, while avoiding
some of the problems with multiple loaders.

There is also an  task ( pretty obvious ) and support for
"dynamic properties" - i.e. you'll be able to use 
${jmx:domain:objectname:attribute} or ${jxpath:}. If I find some time
I'll add a ${jspel:...}.

Costin



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

Re: cvs commit: jakarta-tomcat-5/resources mbeans.xml

[Costin Manolache]

Remy Maucherat wrote:

> [EMAIL PROTECTED] wrote:
>> costin  2003/01/05 22:09:47
>> 
>>   Added:   resources mbeans.xml
>>   Log:
>>   A small test file for the 'jmx-ified' config / profile.
>>   
>>   Each component will be defined as an mbean - with explicit control
>>   over class loaders. This version uses ant ( it's much easier ), but
>>   a standalone version using mlet-like syntax will work the same.
> 
> That's probably dumb, but I couldn't find the classloader task.

BTW - this won't work. It does load the components, but they're not
registering with each other. I checked it in so other people can review
the syntax and comment on the general idea. 

I need to add the code to register for registration notifications
and call the right methods - probably next week.

Costin



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

Re: cvs commit: jakarta-tomcat-5/resources mbeans.xml

[Remy Maucherat]

Costin Manolache wrote:

Remy Maucherat wrote:



[EMAIL PROTECTED] wrote:


costin  2003/01/05 22:09:47

 Added:   resources mbeans.xml
 Log:
 A small test file for the 'jmx-ified' config / profile.
 
 Each component will be defined as an mbean - with explicit control
 over class loaders. This version uses ant ( it's much easier ), but
 a standalone version using mlet-like syntax will work the same.

That's probably dumb, but I couldn't find the classloader task.



BTW - this won't work. It does load the components, but they're not
registering with each other. I checked it in so other people can review
the syntax and comment on the general idea. 

I need to add the code to register for registration notifications
and call the right methods - probably next week.

Thanks for the details. As far as I'm concerned, it looks really cool :)

Remy


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

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

[luehe]

luehe   2003/01/06 10:57:16

  Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
JspUtil.java Node.java Validator.java
   jasper2/src/share/org/apache/jasper/runtime
JspRuntimeLibrary.java
  Log:
  Implemented JSTL EL rules for coercing of empty string and null values
  
  Revision  ChangesPath
  1.144 +32 -90
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.143
  retrieving revision 1.144
  diff -u -r1.143 -r1.144
  --- Generator.java16 Dec 2002 23:37:59 -  1.143
  +++ Generator.java6 Jan 2003 18:57:14 -   1.144
  @@ -2511,7 +2511,19 @@
}
}
   
  - private String convertString(Class c, String s, String attrName,
  + /*
  +  * @param c The target class to which to coerce the given string
  +  * @param s The string value
  +  * @param attrName The name of the attribute whose value is being
  +  * supplied
  +  * @param propEditorClass The property editor for the given attribute
  +  * @param isNamedAttribute true if the given attribute is a named
  +  * attribute (that is, specified using the jsp:attribute standard
  +  * action), and false otherwise
  +  */
  + private String convertString(Class c,
  +  String s,
  +  String attrName,
 Class propEditorClass,
 boolean isNamedAttribute)
throws JasperException {
  @@ -2530,107 +2542,37 @@
} else if (c == String.class) {
return quoted;
} else if (c == boolean.class) {
  - if (isNamedAttribute)
  - return "Boolean.valueOf(" + s + ").booleanValue()";
  - else
  - return Boolean.valueOf(s).toString();
  + return JspUtil.coerceToPrimitiveBoolean(s, isNamedAttribute);
} else if (c == Boolean.class) {
  - if (isNamedAttribute)
  - return "new Boolean(" + s + ")";
  - else
  - // Detect format error at translation time
  - return "new Boolean(" + Boolean.valueOf(s).toString() + ")";
  + return JspUtil.coerceToBoolean(s, isNamedAttribute);
} else if (c == byte.class) {
  - return "((byte)" + Byte.valueOf(s).toString() + ")";
  + return JspUtil.coerceToPrimitiveByte(s, isNamedAttribute);
} else if (c == Byte.class) {
  - if (isNamedAttribute)
  - return "new Byte(" + s + ")";
  - else
  - // Detect format error at translation time
  - return "new Byte((byte)" + Byte.valueOf(s).toString() + ")";
  + return JspUtil.coerceToByte(s, isNamedAttribute);
} else if (c == char.class) {
  - if (isNamedAttribute) {
  - return "org.apache.jasper.runtime.JspRuntimeLibrary.getChar(" + s 
+ ")";
  - } else {
  - // non-normative (normative method would fail to compile)
  - if (s.length() > 0) {
  - char ch = s.charAt(0);
  - // this trick avoids escaping issues
  - return "((char) " + (int) ch + ")";
  - } else {
  - throw new NumberFormatException(
  -err.getString("jsp.error.bad_string_char"));
  - }
  - }
  + return JspUtil.coerceToChar(s, isNamedAttribute);
} else if (c == Character.class) {
  - if (isNamedAttribute) {
  - return "org.apache.jasper.runtime.JspRuntimeLibrary.getCharacter(" 
+ s + ")";
  - } else {
  - // non-normative (normative method would fail to compile)
  - if (s.length() > 0) {
  - char ch = s.charAt(0);
  - // this trick avoids escaping issues
  - return "new Character((char) " + (int) ch + ")";
  - } else {
  - throw new NumberFormatException(
  - err.getString("jsp.error.bad_string_Character"));
  - }
  - }
  + return JspUtil.coerceToCharacter(s, isNamedAttribute);
} else if (c == double.class) {
  - if (isNamedAttribute)
  - return "Double.valueOf(" + s + ").doubleValue()";
  - else
  - return Double.valueOf(s).toString();
  + return JspUtil.coerceToPrimitiveDoubl

Re: [PATCH] forward instead of redirect for welcome files

[Hans Bergsten]

Matt Parker wrote:

I'd like to suggest that catalina perform a forward, rather than a
redirect, for requests that end with '/'. With a redirect, special
configuration is necessary for proxy servers to work correctly. Also, a
forward doesn't require an additional round trip to the client--a
redirect must get back to the client and the client then issues a new
request. I've tested this under Linux. Thanks!


You mean requests that do _not_ end with '/', right? Unfortunatly,
you must do a redirect in this case so that the browser can resolve
relative paths in the page correctly. If you use a forward, it can't
do so correctly.

Hans


--- DefaultServlet.java	2003-01-03 16:20:23.0 -0700
+++ DefaultServlet.java.new	2003-01-03 16:20:18.0 -0700
@@ -942,26 +942,18 @@
 
 if (!request.getRequestURI().endsWith("/")) {
 String redirectPath = path;
-String contextPath = request.getContextPath();
-if ((contextPath != null) && (!contextPath.equals("/"))) {
-redirectPath = contextPath + redirectPath;
-}
 if (!(redirectPath.endsWith("/")))
 redirectPath = redirectPath + "/";
 redirectPath = appendParameters(request, redirectPath);
-response.sendRedirect(redirectPath);
+request.getRequestDispatcher(redirectPath).forward(request, response);
 return;
 }
 
 ResourceInfo welcomeFileInfo = checkWelcomeFiles(path, resources);
 if (welcomeFileInfo != null) {
 String redirectPath = welcomeFileInfo.path;
-String contextPath = request.getContextPath();
-if ((contextPath != null) && (!contextPath.equals("/"))) {
-redirectPath = contextPath + redirectPath;
-}
 redirectPath = appendParameters(request, redirectPath);
-response.sendRedirect(redirectPath);
+request.getRequestDispatcher(redirectPath).forward(request, response);
 return;
 }




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


--
Hans Bergsten<[EMAIL PROTECTED]>
Gefion Software   
Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
Details at


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

Tomcat 4.1.17 SocketException

[Jindong Li]

Here's another one when I'm trying Tomcat 4.1.x :

Here's the exception I got:

java.net.SocketException: Connection aborted by peer: socket write error
at java.net.SocketOutputStream.socketWrite(Native Method)
at java.net.SocketOutputStream.write(SocketOutputStream.java:83)
at
org.apache.catalina.connector.ResponseBase.flushBuffer(ResponseBase.java:675
)
at
org.apache.catalina.connector.HttpResponseBase.doFlushBuffer(HttpResponseBas
e.java:795)
at
org.apache.catalina.connector.HttpResponseBase.flushBuffer(HttpResponseBase.
java:785)
at
org.apache.catalina.connector.ResponseBase.write(ResponseBase.java:648)
at
org.apache.catalina.connector.ResponseStream.write(ResponseStream.java:313)
at
org.apache.catalina.connector.http.HttpResponseStream.write(HttpResponseStre
am.java:190)
at
org.apache.catalina.servlets.DefaultServlet.copyRange(DefaultServlet.java:19
96)
at
org.apache.catalina.servlets.DefaultServlet.copy(DefaultServlet.java:1745)
at
org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.jav
a:1073)
at
org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:506)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:260)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
va:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180
)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.
java:170)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172
)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:509)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:641)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
:174)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:
1040)
at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1151
)
at java.lang.Thread.run(Thread.java:484)

Any input would be greatly appreciated...

Jindong.

Re: [PATCH] forward instead of redirect for welcome files

[Matt Parker]

On Mon, 2003-01-06 at 12:14, Hans Bergsten wrote:
> Matt Parker wrote:
> > I'd like to suggest that catalina perform a forward, rather than a
> > redirect, for requests that end with '/'. With a redirect, special
> > configuration is necessary for proxy servers to work correctly. Also, a
> > forward doesn't require an additional round trip to the client--a
> > redirect must get back to the client and the client then issues a new
> > request. I've tested this under Linux. Thanks!
> 
> You mean requests that do _not_ end with '/', right? Unfortunatly,
> you must do a redirect in this case so that the browser can resolve
> relative paths in the page correctly. If you use a forward, it can't
> do so correctly.
> 
> Hans
> 


No, I mean requests that _do_ end with a trailing slash, but that should
be resolved to one of the files specified in the web application's
. This is similar to Apache's DirectoryIndex
directive. Maybe the following Apache documentation snippet can explain
it more clearly than I can:

"The DirectoryIndex directive sets the list of resources
to look for, when the client requests an index of the directory
by specifying a / at the end of the a directory name."

For Apache, this is index.html by default. When Apache receives a
trailing slash (e.g. /foo/bar/), it resolves index.html and returns it.
Note that it does _not_ send a redirect to index.html. The redirect
occurs only when there is no trailing slash at the end of a directory
request (e.g. /foo/bar is redirected to /foo/bar/, which is then
resolved to index.html)

So tomcat's behavior is actually going against what Apache does.

Hope I'm explaining it correctly.

Matt



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

Re: [PATCH] forward instead of redirect for welcome files

[Costin Manolache]

Matt Parker wrote:

> 
> On Mon, 2003-01-06 at 12:14, Hans Bergsten wrote:
>> Matt Parker wrote:
>> > I'd like to suggest that catalina perform a forward, rather than a
>> > redirect, for requests that end with '/'. With a redirect, special
>> > configuration is necessary for proxy servers to work correctly. Also, a
>> > forward doesn't require an additional round trip to the client--a
>> > redirect must get back to the client and the client then issues a new
>> > request. I've tested this under Linux. Thanks!
>> 
>> You mean requests that do _not_ end with '/', right? Unfortunatly,
>> you must do a redirect in this case so that the browser can resolve
>> relative paths in the page correctly. If you use a forward, it can't
>> do so correctly.

> No, I mean requests that _do_ end with a trailing slash, but that should
> be resolved to one of the files specified in the web application's
> . This is similar to Apache's DirectoryIndex
> directive. Maybe the following Apache documentation snippet can explain
> it more clearly than I can:
> 
> "The DirectoryIndex directive sets the list of resources
> to look for, when the client requests an index of the directory
> by specifying a / at the end of the a directory name."
> 
> For Apache, this is index.html by default. When Apache receives a
> trailing slash (e.g. /foo/bar/), it resolves index.html and returns it.
> Note that it does _not_ send a redirect to index.html. The redirect
> occurs only when there is no trailing slash at the end of a directory
> request (e.g. /foo/bar is redirected to /foo/bar/, which is then
> resolved to index.html)
> 
> So tomcat's behavior is actually going against what Apache does.


The problem is that once again the servlet spec defines a behavior that 
is different from the common practices on web servers.

The welcome-file-list can include more than index.html - you may have
foo/index.html, etc ( i.e. things in other dirs ). That means #anchors 
would break if we don't do redirect.

A second reason for doing redirects: a redirect will let the web server
handle the file serving ( if the index.html is a static file - or some 
resource that apache can handle ).

A third reason: it's safer :-)

Costin







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

DO NOT REPLY [Bug 14722] - Missing/invalid string resource for StandardSession

[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=14722

Missing/invalid string resource for StandardSession





--- Additional Comments From [EMAIL PROTECTED]  2003-01-06 20:03 ---
This is a really simple bug fix.  Will this get assigned in the near future?

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

Re: DO NOT REPLY [Bug 14722] - Missing/invalid string resource for StandardSession

[ravi appala]

Please remove me. I sent email to unsubscribe 3
times,still receiving emails.

Thanks,


--- [EMAIL PROTECTED] wrote:
> 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=14722
> 
> Missing/invalid string resource for StandardSession
> 
> 
> 
> 
> 
> --- Additional Comments From [EMAIL PROTECTED] 
> 2003-01-06 20:03 ---
> This is a really simple bug fix.  Will this get
> assigned in the near future?
> 
> --
> To unsubscribe, e-mail:  
> 
> For additional commands, e-mail:
> 
> 


=
Thanks,
RAVI KUMAR APPALA

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

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

Re: [PATCH] forward instead of redirect for welcome files

[Matt Parker]

On Mon, 2003-01-06 at 12:57, Costin Manolache wrote:

> The problem is that once again the servlet spec defines a behavior that 
> is different from the common practices on web servers.
> 

I don't see that this particular behavior is actually specified, unless
I'm looking in the wrong place. I think it leaves it open for the
"default" servlet to interpret.


> The welcome-file-list can include more than index.html - you may have
> foo/index.html, etc ( i.e. things in other dirs ). That means #anchors 
> would break if we don't do redirect.

This argument would apply equally to Apache's current implementation.
You can specify multiple index files with the DirectoryIndex directive.
So since Apache doesn't redirect, this must not be the case.

> A second reason for doing redirects: a redirect will let the web server
> handle the file serving ( if the index.html is a static file - or some 
> resource that apache can handle ).

Then wouldn't that be specified in the web server's config? Also,
redirecting the client to make yet another request couldn't possibly be
faster than simply serving the static file.

> 
> A third reason: it's safer :-)

?? how is it safer? 

> 
> Costin

I don't mean to be argumentative, but I really think that it's The Right
Way to do it. However I'll defer to the Tomcat team (I guess I don't
have a choice :)

Cheers,

Matt



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

Re: [PATCH] forward instead of redirect for welcome files

[Hans Bergsten]

Matt Parker wrote:

On Mon, 2003-01-06 at 12:14, Hans Bergsten wrote:


Matt Parker wrote:


I'd like to suggest that catalina perform a forward, rather than a
redirect, for requests that end with '/'. With a redirect, special
configuration is necessary for proxy servers to work correctly. Also, a
forward doesn't require an additional round trip to the client--a
redirect must get back to the client and the client then issues a new
request. I've tested this under Linux. Thanks!


You mean requests that do _not_ end with '/', right? Unfortunatly,
you must do a redirect in this case so that the browser can resolve
relative paths in the page correctly. If you use a forward, it can't
do so correctly.

Hans





No, I mean requests that _do_ end with a trailing slash, but that should
be resolved to one of the files specified in the web application's
. This is similar to Apache's DirectoryIndex
directive. Maybe the following Apache documentation snippet can explain
it more clearly than I can:

	"The DirectoryIndex directive sets the list of resources
	to look for, when the client requests an index of the directory
	by specifying a / at the end of the a directory name."

For Apache, this is index.html by default. When Apache receives a
trailing slash (e.g. /foo/bar/), it resolves index.html and returns it.
Note that it does _not_ send a redirect to index.html. The redirect
occurs only when there is no trailing slash at the end of a directory
request (e.g. /foo/bar is redirected to /foo/bar/, which is then
resolved to index.html)

So tomcat's behavior is actually going against what Apache does.

Hope I'm explaining it correctly.


Okay, that's different. Maybe I misread your patch, but to me it looked
as if you changed the behavior when there's no trailing slash.

Anyway, I leave it to Costin to decide if it can be applied safely or
not.

Hans
--
Hans Bergsten<[EMAIL PROTECTED]>
Gefion Software   
Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
Details at


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

Re: [PATCH] forward instead of redirect for welcome files

[Costin Manolache]

Matt Parker wrote:

>> The welcome-file-list can include more than index.html - you may have
>> foo/index.html, etc ( i.e. things in other dirs ). That means #anchors
>> would break if we don't do redirect.
> 
> This argument would apply equally to Apache's current implementation.
> You can specify multiple index files with the DirectoryIndex directive.
> So since Apache doesn't redirect, this must not be the case.

Well, it seems I'm wrong - Apache also allows relative paths in 
DirectoryIndex. 

And if the directory ends with "/", the anchors would probably work.

My mistake.


>> A second reason for doing redirects: a redirect will let the web server
>> handle the file serving ( if the index.html is a static file - or some
>> resource that apache can handle ).
> 
> Then wouldn't that be specified in the web server's config? Also,
> redirecting the client to make yet another request couldn't possibly be
> faster than simply serving the static file.

Not necesarily faster - but if the file is a .shtml or .php - apache may
handle it better. 
Probably not a very good reason ( since not too many people are mixing java 
with non-java pages ).


>> A third reason: it's safer :-)
> 
> ?? how is it safer?

More predictible. 


> I don't mean to be argumentative, but I really think that it's The Right
> Way to do it. However I'll defer to the Tomcat team (I guess I don't
> have a choice :)

If I remember corectly - this was how the first implementation of welcome 
files worked ( long, long ago ). After several strange bugs it changed to
do redirects. 

Tomcat3.3 has an option - useInternal - that will change the behavior (
I think it defaults to false ).

It could be a good idea to add this option in 5.0 ( or 4.1 ). 

Costin



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

Re: [PATCH] forward instead of redirect for welcome files

[Matt Parker]

On Mon, 2003-01-06 at 14:43, Hans Bergsten wrote:
> Okay, that's different. Maybe I misread your patch, but to me it looked
> as if you changed the behavior when there's no trailing slash.

Actually my patch is forwarding under both circumstances, but according
to SRV.9.10 of Servlet 2.4, this is actually correct (phew! :)

Matt



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

Re: [PATCH] forward instead of redirect for welcome files

[Costin Manolache]

Matt Parker wrote:

> On Mon, 2003-01-06 at 14:43, Hans Bergsten wrote:
>> Okay, that's different. Maybe I misread your patch, but to me it looked
>> as if you changed the behavior when there's no trailing slash.
> 
> Actually my patch is forwarding under both circumstances, but according
> to SRV.9.10 of Servlet 2.4, this is actually correct (phew! :)

Forwarding if there is no ending "/" doesn't seem right. I'm very sure 
anchors will be broken.

It may be a good idea to include a modified patch that makes this optional -
but IMO redirect should remain the default. But please verify that anchors
work, including cases where the welcome file is in another directory.



Costin



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

Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0mod_jk.c

[Aditya]

> On 2 Jan 2003 12:58:58 -, [EMAIL PROTECTED] said:
> glenn 2003/01/02 04:58:58
>
>   Modified: jk/native/apache-1.3 mod_jk.c jk/native/apache-2.0
> mod_jk.c Log: Make sure http errors are handled by Apache if not
> handled by Tomcat
> 
>   Revision Changes Path 1.34 +6 -1
> jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c

This fix seems to cause container form-based authentication to have
"problems" - instead of the usual sequence of:

1) GET protected page -> 302 to login page

2) GET login page -> 200 retrieved

3) POST login page -> 302 to protected page

4) GET protected page -> 200 retrieved

The *first* time I try to go to the protected page, instead of (4), I get:

HTTP status 400 (invalid direct reference...)

However, if I then try to get the protected page a *second* time, it works fine...

reverting to a verison of mod_jk that does not include the below fix
doesn't evidence this problem...

Adi


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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardServer.java

[amyroh]

amyroh  2003/01/06 15:22:26

  Modified:catalina/src/share/org/apache/catalina/core
StandardServer.java
  Log:
  Correct fix.
  
  Revision  ChangesPath
  1.10  +5 -10 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardServer.java
  
  Index: StandardServer.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardServer.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- StandardServer.java   3 Jan 2003 19:47:46 -   1.9
  +++ StandardServer.java   6 Jan 2003 23:22:26 -   1.10
  @@ -883,12 +883,7 @@
   } else if (c == '"') {
   filtered.append(""");
   } else if (c == '&') {
  -int j = input.indexOf(";", i);
  -if (j > 0) {
  -filtered.append(c);
  -} else {
  -filtered.append("&");
  -}
  +filtered.append("&");
   } else {
   filtered.append(c);
   }
  
  
  

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

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardServer.java

[amyroh]

amyroh  2003/01/06 15:25:25

  Modified:catalina/src/share/org/apache/catalina/core
StandardServer.java
  Log:
  Correct fix.
  
  Revision  ChangesPath
  1.35  +5 -10 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardServer.java
  
  Index: StandardServer.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardServer.java,v
  retrieving revision 1.34
  retrieving revision 1.35
  diff -u -r1.34 -r1.35
  --- StandardServer.java   3 Jan 2003 19:47:01 -   1.34
  +++ StandardServer.java   6 Jan 2003 23:25:24 -   1.35
  @@ -824,12 +824,7 @@
   } else if (c == '"') {
   filtered.append(""");
   } else if (c == '&') {
  -int j = input.indexOf(";", i);
  -if (j > 0) {
  -filtered.append(c);
  -} else {
  -filtered.append("&");
  -}
  +filtered.append("&");
   } else {
   filtered.append(c);
   }
  
  
  

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

DO NOT REPLY [Bug 15819] - Duplicate context listener entries in server.xml when saving

[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=15819

Duplicate context listener entries in server.xml when saving





--- Additional Comments From [EMAIL PROTECTED]  2003-01-06 23:29 ---
I can't seem to reproduce this bug.  Does anyone else have this problem?

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

Unable to compile class for JSP

[Gary Pollreis]

I have just installed Tomcat 4.1.18 under Windows 2000 (using Java JDK
1.4.0).  When I try to run the examples I get
"org.apache.jasper.JasperException: Unable to compile class for JSP" .
I have validated that my JAVA_HOME and CATALINA_HOME environment variables
are correct.
Any/all help would be appreciated.  Thanks in advance.

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

Re: Unable to compile class for JSP

[Matt Parker]

you should post this to the tomcat-users list. this list is for issues
related to development on the tomcat product.


On Mon, 2003-01-06 at 16:48, Gary Pollreis wrote:
> I have just installed Tomcat 4.1.18 under Windows 2000 (using Java JDK
> 1.4.0).  When I try to run the examples I get
> "org.apache.jasper.JasperException: Unable to compile class for JSP" .
> I have validated that my JAVA_HOME and CATALINA_HOME environment variables
> are correct.
> Any/all help would be appreciated.  Thanks in advance.
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 


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

RE: Unable to compile class for JSP

[Gary Pollreis]

will do - thanks for the heads up.

-Original Message-
From: Matt Parker [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 06, 2003 5:57 PM
To: Tomcat Developers List
Subject: Re: Unable to compile class for JSP


you should post this to the tomcat-users list. this list is for issues
related to development on the tomcat product.


On Mon, 2003-01-06 at 16:48, Gary Pollreis wrote:
> I have just installed Tomcat 4.1.18 under Windows 2000 (using Java JDK
> 1.4.0).  When I try to run the examples I get
> "org.apache.jasper.JasperException: Unable to compile class for JSP" .
> I have validated that my JAVA_HOME and CATALINA_HOME environment variables
> are correct.
> Any/all help would be appreciated.  Thanks in advance.
>
> --
> 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: [PATCH] forward instead of redirect for welcome files

[Tim Funk]

If a trailing / is not present, then performing a 
RequestDispatcher.forward will break all relative references (for the 
web browser)

-Tim

Costin Manolache wrote:
Matt Parker wrote:



On Mon, 2003-01-06 at 14:43, Hans Bergsten wrote:


Okay, that's different. Maybe I misread your patch, but to me it looked
as if you changed the behavior when there's no trailing slash.


Actually my patch is forwarding under both circumstances, but according
to SRV.9.10 of Servlet 2.4, this is actually correct (phew! :)



Forwarding if there is no ending "/" doesn't seem right. I'm very sure 
anchors will be broken.

It may be a good idea to include a modified patch that makes this optional -
but IMO redirect should remain the default. But please verify that anchors
work, including cases where the welcome file is in another directory.



Costin

 


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

RE: Unable to compile class for JSP

[Matt Parker]

Happy New Year :)

On Mon, 2003-01-06 at 17:00, Gary Pollreis wrote:
> will do - thanks for the heads up.
> 
> -Original Message-
> From: Matt Parker [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 06, 2003 5:57 PM
> To: Tomcat Developers List
> Subject: Re: Unable to compile class for JSP
> 
> 
> you should post this to the tomcat-users list. this list is for issues
> related to development on the tomcat product.
> 
> 
> On Mon, 2003-01-06 at 16:48, Gary Pollreis wrote:
> > I have just installed Tomcat 4.1.18 under Windows 2000 (using Java JDK
> > 1.4.0).  When I try to run the examples I get
> > "org.apache.jasper.JasperException: Unable to compile class for JSP" .
> > I have validated that my JAVA_HOME and CATALINA_HOME environment variables
> > are correct.
> > Any/all help would be appreciated.  Thanks in advance.
> >
> > --
> > 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: 
> 


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

Re: [PATCH] forward instead of redirect for welcome files

[Matt Parker]

On Mon, 2003-01-06 at 17:03, Tim Funk wrote:
> If a trailing / is not present, then performing a 
> RequestDispatcher.forward will break all relative references (for the 
> web browser)
> 
> -Tim
> 

It doesn't forward until after it appends the trailing slash, so I think
it's okay on that front.




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

Re: [PATCH] Iteration tags do not synchronize scripting variables after doStartTag

[Jan Luehe]

Dimitry,

> In jasper2, I have found one interesting bug. It hapens when tag
> implements BodyTag interface and doStartTag returns EVAL_BODY_INCLUDE.
>  
> See test-case and patch attached. The patch tested under Tomcat 4.1.18.

the current synchronization behaviour your are seeing is compliant
with the spec.

Attached is the latest javadocs of
javax.servlet.jsp.tagext.VariableInfo (from the upcoming JSP 2.0),
which contains a table listing the various variable synchronization
points for the different tag handler types (see section entitled
"Synchronization Protocol").

As you will notice, there is a synchronization point for instances of
BodyTag after the invocation of doInitBody(), but not after
doStartTag(). Only instances of Tag or IterationTag have a synchronization
point after doStartTag().
This is consistent with the description of the Synchronization Protocol 
in JSP.10.5.9 ("VariableInfo") in JSP 1.2. 

Therefore, your proposed patch is invalid.


Jan



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

Help! symbol jk_parse_log_level: referenced symbol not found?

[Brian_Carmody]

I'm trying to build a connector for iPlanet 6.0 on Solaris 8 connecting to
Tomcat 4.1.18 on another solaris 8 box. The iPlanet web server has iPlanet
6.0, and Sun's j2sdk1_3_1_06. I downloaded
jakarta-tomcat-connectors-4.1.18-src, and inside jk/native/netscape ran:
export JAVA_HOME=/path/to/jdk
make

It compiles cleanly, and produces jk_nsapi_plugin.o and
nsapi_redirector.so. I added an init statement to iPlanet to invoke
nsapi_redirector.so at startup, and get the following in the iPlanet error
log:

[05/Jan/2003:15:47:42] failure (28713): Configuration initialization
failed: Error running init function load-modules: dlopen of
/u01/iplanet/iws/tomcat-plugin/lib/nsapi_redirector.so failed (ld.so.1:
ns-httpd: fatal: relocation error: file
/u01/iplanet/iws/tomcat-plugin/lib/nsapi_redirector.so: symbol
jk_parse_log_level: referenced symbol not found)

Where do I start in debugging? Any help would be _most_ appreciated. (I'm
going to write a good iPlanet + Tomcat HOWTO once this gets worked out)

Thanks in advance,
Brian C.





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

Re: [PATCH] forward instead of redirect for welcome files

[Matt Parker]

On Mon, 2003-01-06 at 15:28, Costin Manolache wrote:
> Matt Parker wrote:
> 
> > On Mon, 2003-01-06 at 14:43, Hans Bergsten wrote:
> >> Okay, that's different. Maybe I misread your patch, but to me it looked
> >> as if you changed the behavior when there's no trailing slash.
> > 
> > Actually my patch is forwarding under both circumstances, but according
> > to SRV.9.10 of Servlet 2.4, this is actually correct (phew! :)
> 
> Forwarding if there is no ending "/" doesn't seem right. I'm very sure 
> anchors will be broken.
> 

The code to append a trailing / before it does anything else (assuming
it's a directory) is already present in the default servlet--my patch
forwards after this happens. Maybe I should have included more context
within the patch to make this clearer--sorry, I can see why this would
be so controversial without that key point. Otherwise it would
definitely break. The patch occurs after the line:

if (resourceInfo.collection) {
...
}

which means that it has already ruled that the request is a directory.

> It may be a good idea to include a modified patch that makes this optional -
> but IMO redirect should remain the default. But please verify that anchors
> work, including cases where the welcome file is in another directory.
> 

Verified the following:

http://foo/bar#anchor
http://foo/bar/#anchor

with a welcome-file of:
test/test.jsp

and was correctly forwarded to:

http://foo/bar/test/test.jsp#anchor


Matt




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

Re: [PATCH] Iteration tags do not synchronize scripting variables after doStartTag

[Jan Luehe]

> Dimitry,
> 
> > In jasper2, I have found one interesting bug. It hapens when tag
> > implements BodyTag interface and doStartTag returns EVAL_BODY_INCLUDE.
> >  
> > See test-case and patch attached. The patch tested under Tomcat 4.1.18.
> 
> the current synchronization behaviour your are seeing is compliant
> with the spec.
> 
> Attached is the latest javadocs of
> javax.servlet.jsp.tagext.VariableInfo (from the upcoming JSP 2.0),
> which contains a table listing the various variable synchronization
> points for the different tag handler types (see section entitled
> "Synchronization Protocol").

My previous reply seems to be missing the attachment.
Here it is.


Jan


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

Re: [PATCH] forward instead of redirect for welcome files

[Matt Parker]

> Verified the following:
> 
> http://foo/bar#anchor
> http://foo/bar/#anchor
> 
> with a welcome-file of:
> test/test.jsp
> 
> and was correctly forwarded to:
> 
> http://foo/bar/test/test.jsp#anchor
> 
> 

okay, I was a little premature (no jokes please). if the welcome file
itself has a relative link off of it, then it breaks. so that  on test.jsp will try to go to http://foo/bar/foo.jsp
rather than http://foo/bar/test/foo.jsp

i'll see if i can fix that. sorry...

Matt



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

Re: [PATCH] forward instead of redirect for welcome files

[Matt Parker]

On Mon, 2003-01-06 at 17:11, Matt Parker wrote:
> On Mon, 2003-01-06 at 17:03, Tim Funk wrote:
> > If a trailing / is not present, then performing a 
> > RequestDispatcher.forward will break all relative references (for the 
> > web browser)
> > 
> > -Tim
> > 
> 
> It doesn't forward until after it appends the trailing slash, so I think
> it's okay on that front.
> 

No, you're right. It's broken. Crud.


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

RE: Unable to compile class for JSP

[Costin Manolache]

Just had the same problem - it seems JDK1.4 on windows has an interesting
behavior - it will not load javac from tools.jar unless it is included in
endorsed.

I'm not a big windows user - if someone could confirm, we need to change the
scripts. I see this behavior with (at least) 1.4.0-b92.

Costin


Gary Pollreis wrote:

> will do - thanks for the heads up.
> 
> -Original Message-
> From: Matt Parker [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 06, 2003 5:57 PM
> To: Tomcat Developers List
> Subject: Re: Unable to compile class for JSP
> 
> 
> you should post this to the tomcat-users list. this list is for issues
> related to development on the tomcat product.
> 
> 
> On Mon, 2003-01-06 at 16:48, Gary Pollreis wrote:
>> I have just installed Tomcat 4.1.18 under Windows 2000 (using Java JDK
>> 1.4.0).  When I try to run the examples I get
>> "org.apache.jasper.JasperException: Unable to compile class for JSP" .
>> I have validated that my JAVA_HOME and CATALINA_HOME environment
>> variables are correct.
>> Any/all help would be appreciated.  Thanks in advance.
>>
>> --
>> 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: [PATCH] forward instead of redirect for welcome files

[Tim Moore]

> -Original Message-
> From: Matt Parker [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, January 06, 2003 7:39 PM
> To: Tomcat Developers List
> Subject: Re: [PATCH] forward instead of redirect for welcome files
> 
> 
> 
> > Verified the following:
> > 
> > http://foo/bar#anchor
> > http://foo/bar/#anchor
> > 
> > with a welcome-file of:
> > test/test.jsp
> > 
> > and was correctly forwarded to:
> > 
> > http://foo/bar/test/test.jsp#anchor
> > 
> > 
> 
> okay, I was a little premature (no jokes please). if the 
> welcome file itself has a relative link off of it, then it 
> breaks. so that  on test.jsp will try to go 
> to http://foo/bar/foo.jsp rather than http://foo/bar/test/foo.jsp
> 
> i'll see if i can fix that. sorry...
> 

If you want to mirror what Apache HTTPD does:

No slash present --> append slash (only!) and redirect
Slash present --> internally forward to welcome-file page

-- 
Tim Moore / Blackboard Inc. / Software Engineer
1899 L Street, NW / 5th Floor / Washington, DC 20036
Phone 202-463-4860 ext. 258 / Fax 202-463-4863

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

Re: Unable to compile class for JSP

[Jeanfrancois Arcand]

Hum...I don't have any problems under win2k using Sun JDK 1.4.1 (and I 
don't remember seeing that problem with 1.4). Have you try with 1.4.1? I 
will downgrade and see

-- Jeanfrancois

Costin Manolache wrote:

Just had the same problem - it seems JDK1.4 on windows has an interesting
behavior - it will not load javac from tools.jar unless it is included in
endorsed.

I'm not a big windows user - if someone could confirm, we need to change the
scripts. I see this behavior with (at least) 1.4.0-b92.

Costin


Gary Pollreis wrote:

 

will do - thanks for the heads up.

-Original Message-
From: Matt Parker [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 06, 2003 5:57 PM
To: Tomcat Developers List
Subject: Re: Unable to compile class for JSP


you should post this to the tomcat-users list. this list is for issues
related to development on the tomcat product.


On Mon, 2003-01-06 at 16:48, Gary Pollreis wrote:
   

I have just installed Tomcat 4.1.18 under Windows 2000 (using Java JDK
1.4.0).  When I try to run the examples I get
"org.apache.jasper.JasperException: Unable to compile class for JSP" .
I have validated that my JAVA_HOME and CATALINA_HOME environment
variables are correct.
Any/all help would be appreciated.  Thanks in advance.

--
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: Unable to compile class for JSP

[Costin Manolache]

Jeanfrancois Arcand wrote:

> Hum...I don't have any problems under win2k using Sun JDK 1.4.1 (and I
> don't remember seeing that problem with 1.4). Have you try with 1.4.1? I
> will downgrade and see

No, I'm just happy that I found the trick to make it work.
( I only tested tomcat4.1 with JDK1.4.0-b92 on w2k and xp )

Costin

> 
> -- Jeanfrancois
> 
> Costin Manolache wrote:
> 
>>Just had the same problem - it seems JDK1.4 on windows has an interesting
>>behavior - it will not load javac from tools.jar unless it is included in
>>endorsed.
>>
>>I'm not a big windows user - if someone could confirm, we need to change
>>the scripts. I see this behavior with (at least) 1.4.0-b92.
>>
>>Costin
>>
>>
>>Gary Pollreis wrote:
>>
>>  
>>
>>>will do - thanks for the heads up.
>>>
>>>-Original Message-
>>>From: Matt Parker [mailto:[EMAIL PROTECTED]]
>>>Sent: Monday, January 06, 2003 5:57 PM
>>>To: Tomcat Developers List
>>>Subject: Re: Unable to compile class for JSP
>>>
>>>
>>>you should post this to the tomcat-users list. this list is for issues
>>>related to development on the tomcat product.
>>>
>>>
>>>On Mon, 2003-01-06 at 16:48, Gary Pollreis wrote:
>>>
>>>
I have just installed Tomcat 4.1.18 under Windows 2000 (using Java JDK
1.4.0).  When I try to run the examples I get
"org.apache.jasper.JasperException: Unable to compile class for JSP" .
I have validated that my JAVA_HOME and CATALINA_HOME environment
variables are correct.
Any/all help would be appreciated.  Thanks in advance.

--
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: 
>>
>>
>>  
>>




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

RE: [PATCH] forward instead of redirect for welcome files

[Matt Parker]

> If you want to mirror what Apache HTTPD does:
> 
> No slash present --> append slash (only!) and redirect
> Slash present --> internally forward to welcome-file page

Well, here's the rub:

- The new servlet spec clearly states that either /foo or /foo/ should
return a welcome-file (if specified)

- Apache also has the problem with a relative link on a welcome file
which has a directory specified in it


However, I think that the patch benefits still outweigh its drawbacks:

- it satisfies the new servlet spec

- it circumvents the need for special processing and configuration when
placed behind a proxy server (a farely common production practice).

- it inherits a problem, but the problem is probably rare in practice,
and will already have been avoided by Apache users since it's the same.
i.e. i've never had a burning need to specify a welcome file or
directory index that has a subdirectory in it _and_ has a relative link,
so i can only guess that others either don't or already know to avoid
it.

What do y'all think?

I vote +1 :)


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

cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c

[glenn]

glenn   2003/01/06 17:27:11

  Modified:jk/native/apache-1.3 mod_jk.c
   jk/native/apache-2.0 mod_jk.c
  Log:
  Fix bug reported with form based authentication
  
  Revision  ChangesPath
  1.35  +2 -2  jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c
  
  Index: mod_jk.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c,v
  retrieving revision 1.34
  retrieving revision 1.35
  diff -u -r1.34 -r1.35
  --- mod_jk.c  2 Jan 2003 12:58:57 -   1.34
  +++ mod_jk.c  7 Jan 2003 01:27:11 -   1.35
  @@ -1611,7 +1611,7 @@
   if(rc) {
   /* If tomcat returned no body and the status is not OK,
  let apache handle the error code */
  -if( !r->sent_bodyct && r->status != HTTP_OK ) {
  +if( !r->sent_bodyct && r->status >= HTTP_BAD_REQUEST ) {
   return r->status;
   }
   return OK;  /* NOT r->status, even if it has changed. */
  
  
  
  1.65  +2 -2  jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
  
  Index: mod_jk.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
  retrieving revision 1.64
  retrieving revision 1.65
  diff -u -r1.64 -r1.65
  --- mod_jk.c  2 Jan 2003 12:58:57 -   1.64
  +++ mod_jk.c  7 Jan 2003 01:27:11 -   1.65
  @@ -1836,7 +1836,7 @@
   if(rc) {
   /* If tomcat returned no body and the status is not OK,
  let apache handle the error code */
  -if( !r->sent_bodyct && r->status != HTTP_OK ) {
  +if( !r->sent_bodyct && r->status >= HTTP_BAD_REQUEST ) {
   return r->status;
   }
   return OK;/* NOT r->status, even if it has changed. */
  
  
  

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

RE: [PATCH] forward instead of redirect for welcome files

[Matt Parker]

Here's the new version of the patch. the code to redirect if there is no
trailing slash remains untouched, but it now forwards if there is a
trailing slash. i've included more context to avoid potential confusion:


--- DefaultServlet.java 2003-01-03 16:20:23.0 -0700
+++ DefaultServlet.java.new 2003-01-06 18:27:25.0 -0700
@@ -939,46 +939,42 @@
 // If the resource is a collection (aka a directory), we check
 // the welcome files list.
 if (resourceInfo.collection) {
 
 if (!request.getRequestURI().endsWith("/")) {
 String redirectPath = path;
 String contextPath = request.getContextPath();
 if ((contextPath != null) &&
(!contextPath.equals("/"))) {
 redirectPath = contextPath + redirectPath;
 }
 if (!(redirectPath.endsWith("/")))
 redirectPath = redirectPath + "/";
 redirectPath = appendParameters(request, redirectPath);
 response.sendRedirect(redirectPath);
 return;
 }
 
 ResourceInfo welcomeFileInfo = checkWelcomeFiles(path,
resources);
 if (welcomeFileInfo != null) {
 String redirectPath = welcomeFileInfo.path;
-String contextPath = request.getContextPath();
-if ((contextPath != null) &&
(!contextPath.equals("/"))) {
-redirectPath = contextPath + redirectPath;
-}
 redirectPath = appendParameters(request, redirectPath);
-response.sendRedirect(redirectPath);
+   
request.getRequestDispatcher(redirectPath).forward(request, response);
 return;
 }
 
 } else {
 
 // Checking If headers
 boolean included =
 (request.getAttribute(Globals.CONTEXT_PATH_ATTR) !=
null);
 if (!included 
 && !checkIfHeaders(request, response, resourceInfo)) {
 return;
 }
 
 }
 
 // Find content type.
 String contentType =
 getServletContext().getMimeType(resourceInfo.path);
 
 Vector ranges = null;



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

Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c

[Glenn Nielsen]

Thanks for reporting this.  I have changed the code so that
if there is no content only status codes >= 400 are passed
back through apache.

The original patch was made so that when an error occurred at the
Ajp13Processor layer it could propogated back to the browser correctly
instead of a blank page being displayed.

Please test from a CVS build and let me know if this fixes the problem
for you.

Thanks,

Glenn

Aditya wrote:

On 2 Jan 2003 12:58:58 -, [EMAIL PROTECTED] said:
glenn 2003/01/02 04:58:58

 Modified: jk/native/apache-1.3 mod_jk.c jk/native/apache-2.0
mod_jk.c Log: Make sure http errors are handled by Apache if not
handled by Tomcat

 Revision Changes Path 1.34 +6 -1
jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c



This fix seems to cause container form-based authentication to have
"problems" - instead of the usual sequence of:

1) GET protected page -> 302 to login page

2) GET login page -> 200 retrieved

3) POST login page -> 302 to protected page

4) GET protected page -> 200 retrieved

The *first* time I try to go to the protected page, instead of (4), I get:

HTTP status 400 (invalid direct reference...)

However, if I then try to get the protected page a *second* time, it works fine...

reverting to a verison of mod_jk that does not include the below fix
doesn't evidence this problem...

Adi


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





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

RE: [PATCH] forward instead of redirect for welcome files

[Tim Moore]

> -Original Message-
> From: Matt Parker [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, January 06, 2003 8:11 PM
> To: Tomcat Developers List
> Subject: RE: [PATCH] forward instead of redirect for welcome files
> 
> 
> 
> > If you want to mirror what Apache HTTPD does:
> > 
> > No slash present --> append slash (only!) and redirect
> > Slash present --> internally forward to welcome-file page
> 
> Well, here's the rub:
> 
> - The new servlet spec clearly states that either /foo or 
> /foo/ should return a welcome-file (if specified)

Well if you redirect from /foo to /foo/ and handle the welcome file from
/foo/ then all is well. :-)

> - Apache also has the problem with a relative link on a 
> welcome file which has a directory specified in it

Ah...yes I imagine so.

> However, I think that the patch benefits still outweigh its drawbacks:
> 
> - it satisfies the new servlet spec
> 
> - it circumvents the need for special processing and 
> configuration when placed behind a proxy server (a farely 
> common production practice).
> 
> - it inherits a problem, but the problem is probably rare in 
> practice, and will already have been avoided by Apache users 
> since it's the same. i.e. i've never had a burning need to 
> specify a welcome file or directory index that has a 
> subdirectory in it _and_ has a relative link, so i can only 
> guess that others either don't or already know to avoid it.

Unless I'm missing something, if you don't redirect from /foo to /foo/,
then you'll have broken relative links even if the welcome file is not
in a subdirectory.  This would probably be a pretty common problem.

For example, if your welcome file has  then resolving
that relative to /foo would give you "/bar.html" while resolving it
relative to "/foo/" would give you "/foo/bar.html".  That means that
relative links will either work or not work, depending just on whether
the trailing slash is there.
-- 
Tim Moore / Blackboard Inc. / Software Engineer
1899 L Street, NW / 5th Floor / Washington, DC 20036
Phone 202-463-4860 ext. 258 / Fax 202-463-4863

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

DO NOT REPLY [Bug 15819] - Duplicate context listener entries in server.xml when saving

[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=15819

Duplicate context listener entries in server.xml when saving





--- Additional Comments From [EMAIL PROTECTED]  2003-01-07 01:38 ---
I am able to reproduce, but only if I create a DefaultContext and I restart 
Tomcat.  A Listener for each context is added in server.xml when I commit 
changes with the admin tool.  A new Listener is then added with the first 
commit changes after each restart.

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

RE: [PATCH] forward instead of redirect for welcome files

[Matt Parker]

On Mon, 2003-01-06 at 18:31, Tim Moore wrote:

> Unless I'm missing something, if you don't redirect from /foo to /foo/,
> then you'll have broken relative links even if the welcome file is not
> in a subdirectory.  This would probably be a pretty common problem.
> 
> For example, if your welcome file has  then resolving
> that relative to /foo would give you "/bar.html" while resolving it
> relative to "/foo/" would give you "/foo/bar.html".  That means that
> relative links will either work or not work, depending just on whether
> the trailing slash is there.

you're absolutely right (no pun intended :)

I was spacing out--the redirect is necessary when there's no trailing
slash, but forward is okay when there is a trailing slash. I posted a
new version of the patch that forwards only when there's a trailing
slash...



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

RE: [PATCH] Iteration tags do not synchronize scripting variables after doStartTag

[Dimitry Ivanov]

Jan,

Two quotes from JSP.10.2.2 ("BodyTag") in JSP 1.2 spec. 

Quote 1 (on page 177 second paragraph):
"If EVAL_BODY_INCLUDE is returned, then evaluation happens as in
Iteration-
Tag." 

Quote 2 (on page 178, last paragraph):
"If EVAL_BODY_INCLUDE is returned, setBodyContent() is not invoked,
doInitBody() is not invoked, the body is evaluated and "passed through"
to the
current out, doAfterBody() is invoked and then, after zero or more
iterations,
doEndTag() is invoked." 

 Generator shouldn't generate call to doInitBody when EVAL_BODY_INCLUDE 
returned by doStartTag.

 It seems the patch is valid.

Dimitry

>Dimitry,

>> In jasper2, I have found one interesting bug. It hapens when tag
>> implements BodyTag interface and doStartTag returns
EVAL_BODY_INCLUDE.
>>  
>> See test-case and patch attached. The patch tested under Tomcat
4.1.18.

>the current synchronization behaviour your are seeing is compliant
>with the spec.

>Attached is the latest javadocs of
>javax.servlet.jsp.tagext.VariableInfo (from the upcoming JSP 2.0),
>which contains a table listing the various variable synchronization
>points for the different tag handler types (see section entitled
>"Synchronization Protocol").

>As you will notice, there is a synchronization point for instances of
>BodyTag after the invocation of doInitBody(), but not after
>doStartTag(). Only instances of Tag or IterationTag have a
synchronization
>point after doStartTag().

>This is consistent with the description of the Synchronization Protocol

>in JSP.10.5.9 ("VariableInfo") in JSP 1.2. 

>Therefore, your proposed patch is invalid.

>Jan




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

RE: [PATCH] Iteration tags do not synchronize scripting variables after doStartTag

[Dimitry Ivanov]

Oh sorry... You right. It generates ivalid code when EVAL_BODY_BUFERRED
has returned...
I will correct it in several minutes.

-Original Message-
From: Dimitry Ivanov [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, January 07, 2003 5:42 AM
To: 'Jan Luehe'
Cc: 'Tomcat Developers List'
Subject: RE: [PATCH] Iteration tags do not synchronize scripting
variables after doStartTag


Jan,

Two quotes from JSP.10.2.2 ("BodyTag") in JSP 1.2 spec. 

Quote 1 (on page 177 second paragraph):
"If EVAL_BODY_INCLUDE is returned, then evaluation happens as in
Iteration-
Tag." 

Quote 2 (on page 178, last paragraph):
"If EVAL_BODY_INCLUDE is returned, setBodyContent() is not invoked,
doInitBody() is not invoked, the body is evaluated and "passed through"
to the
current out, doAfterBody() is invoked and then, after zero or more
iterations,
doEndTag() is invoked." 

 Generator shouldn't generate call to doInitBody when EVAL_BODY_INCLUDE 
returned by doStartTag.

 It seems the patch is valid.

Dimitry

>Dimitry,

>> In jasper2, I have found one interesting bug. It hapens when tag
>> implements BodyTag interface and doStartTag returns
EVAL_BODY_INCLUDE.
>>  
>> See test-case and patch attached. The patch tested under Tomcat
4.1.18.

>the current synchronization behaviour your are seeing is compliant
>with the spec.

>Attached is the latest javadocs of
>javax.servlet.jsp.tagext.VariableInfo (from the upcoming JSP 2.0),
>which contains a table listing the various variable synchronization
>points for the different tag handler types (see section entitled
>"Synchronization Protocol").

>As you will notice, there is a synchronization point for instances of
>BodyTag after the invocation of doInitBody(), but not after
>doStartTag(). Only instances of Tag or IterationTag have a
synchronization
>point after doStartTag().

>This is consistent with the description of the Synchronization Protocol

>in JSP.10.5.9 ("VariableInfo") in JSP 1.2. 

>Therefore, your proposed patch is invalid.

>Jan




--
To unsubscribe, e-mail:

For additional commands, e-mail:




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

[PATCH] Iteration tags do not synchronize scripting variables after doStartTag

[Dimitry Ivanov]

2nd attempt.

Tested with Tomcat 4.1.18.

-Original Message-
From: Dimitry Ivanov [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, January 07, 2003 5:48 AM
To: 'Jan Luehe'
Cc: 'Tomcat Developers List'
Subject: RE: [PATCH] Iteration tags do not synchronize scripting
variables after doStartTag


Oh sorry... You right. It generates ivalid code when EVAL_BODY_BUFERRED
has returned...
I will correct it in several minutes.

-Original Message-
From: Dimitry Ivanov [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, January 07, 2003 5:42 AM
To: 'Jan Luehe'
Cc: 'Tomcat Developers List'
Subject: RE: [PATCH] Iteration tags do not synchronize scripting
variables after doStartTag


Jan,

Two quotes from JSP.10.2.2 ("BodyTag") in JSP 1.2 spec. 

Quote 1 (on page 177 second paragraph):
"If EVAL_BODY_INCLUDE is returned, then evaluation happens as in
Iteration-
Tag." 

Quote 2 (on page 178, last paragraph):
"If EVAL_BODY_INCLUDE is returned, setBodyContent() is not invoked,
doInitBody() is not invoked, the body is evaluated and "passed through"
to the
current out, doAfterBody() is invoked and then, after zero or more
iterations,
doEndTag() is invoked." 

 Generator shouldn't generate call to doInitBody when EVAL_BODY_INCLUDE 
returned by doStartTag.

 It seems the patch is valid.

Dimitry

>Dimitry,

>> In jasper2, I have found one interesting bug. It hapens when tag
>> implements BodyTag interface and doStartTag returns
EVAL_BODY_INCLUDE.
>>  
>> See test-case and patch attached. The patch tested under Tomcat
4.1.18.

>the current synchronization behaviour your are seeing is compliant
>with the spec.

>Attached is the latest javadocs of
>javax.servlet.jsp.tagext.VariableInfo (from the upcoming JSP 2.0),
>which contains a table listing the various variable synchronization
>points for the different tag handler types (see section entitled
>"Synchronization Protocol").

>As you will notice, there is a synchronization point for instances of
>BodyTag after the invocation of doInitBody(), but not after
>doStartTag(). Only instances of Tag or IterationTag have a
synchronization
>point after doStartTag().

>This is consistent with the description of the Synchronization Protocol

>in JSP.10.5.9 ("VariableInfo") in JSP 1.2. 

>Therefore, your proposed patch is invalid.

>Jan




--
To unsubscribe, e-mail:

For additional commands, e-mail:




--
To unsubscribe, e-mail:

For additional commands, e-mail:





Generator.java.patch
Description: Binary data
--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [PATCH] forward instead of redirect for welcome files

[Costin Manolache]

Please at least make it optional - with the default beeing the current 
behavior.


Costin

Matt Parker wrote:

> Here's the new version of the patch. the code to redirect if there is no
> trailing slash remains untouched, but it now forwards if there is a
> trailing slash. i've included more context to avoid potential confusion:
> 
> 
> --- DefaultServlet.java   2003-01-03 16:20:23.0 -0700
> +++ DefaultServlet.java.new   2003-01-06 18:27:25.0 -0700
> @@ -939,46 +939,42 @@
>  // If the resource is a collection (aka a directory), we check
>  // the welcome files list.
>  if (resourceInfo.collection) {
>  
>  if (!request.getRequestURI().endsWith("/")) {
>  String redirectPath = path;
>  String contextPath = request.getContextPath();
>  if ((contextPath != null) &&
> (!contextPath.equals("/"))) {
>  redirectPath = contextPath + redirectPath;
>  }
>  if (!(redirectPath.endsWith("/")))
>  redirectPath = redirectPath + "/";
>  redirectPath = appendParameters(request, redirectPath);
>  response.sendRedirect(redirectPath);
>  return;
>  }
>  
>  ResourceInfo welcomeFileInfo = checkWelcomeFiles(path,
> resources);
>  if (welcomeFileInfo != null) {
>  String redirectPath = welcomeFileInfo.path;
> -String contextPath = request.getContextPath();
> -if ((contextPath != null) &&
> (!contextPath.equals("/"))) {
> -redirectPath = contextPath + redirectPath;
> -}
>  redirectPath = appendParameters(request, redirectPath);
> -response.sendRedirect(redirectPath);
> +
> request.getRequestDispatcher(redirectPath).forward(request, response);
>  return;
>  }
>  
>  } else {
>  
>  // Checking If headers
>  boolean included =
>  (request.getAttribute(Globals.CONTEXT_PATH_ATTR) !=
> null);
>  if (!included
>  && !checkIfHeaders(request, response, resourceInfo)) {
>  return;
>  }
>  
>  }
>  
>  // Find content type.
>  String contentType =
>  getServletContext().getMimeType(resourceInfo.path);
>  
>  Vector ranges = null;




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