cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.1.txt

2003-07-18 Thread billbarker
billbarker2003/07/18 00:35:57

  Modified:.RELEASE-NOTES-4.1.txt
  Log:
  Document Authenticator change.
  
  Revision  ChangesPath
  1.77  +4 -1  jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt
  
  Index: RELEASE-NOTES-4.1.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt,v
  retrieving revision 1.76
  retrieving revision 1.77
  diff -u -r1.76 -r1.77
  --- RELEASE-NOTES-4.1.txt 15 Jul 2003 08:24:52 -  1.76
  +++ RELEASE-NOTES-4.1.txt 18 Jul 2003 07:35:57 -  1.77
  @@ -764,6 +764,9 @@
   [4.1.25] StandardSession:
Clone enumerated list to allow mutating.
   
  +[4.1.27] AuthenticatorBase:
  + Don't set the no-caching headers on protected POSTed pages, so that
  + the browser's back button works as expected.
   
   
   Coyote Bug Fixes:
  
  
  

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



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

2003-07-18 Thread billbarker
billbarker2003/07/18 00:48:56

  Modified:webapps/docs changelog.xml
  Log:
  Document changes.
  
  Revision  ChangesPath
  1.8   +8 -3  jakarta-tomcat-catalina/webapps/docs/changelog.xml
  
  Index: changelog.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- changelog.xml 14 Jul 2003 18:47:08 -  1.7
  +++ changelog.xml 18 Jul 2003 07:48:56 -  1.8
  @@ -98,7 +98,10 @@
 to properly remove the config file even if it does not match the 
 context path (remm)
 /fix
  -
  +  fix
  +  Don't set the no-caching headers for protected POSTed pages.  This makes
  +  the back button in the browser works as expected. (billbarker)
  +  /fix
   /changelog
   
 /subsection
  @@ -131,8 +134,10 @@
 Add support for enabling subset of supported SSL cipher suites 
 in PureTLS implementation (billbarker)
 /add
  -  
  -
  +  fix
  +  Slight re-factoring of the JSSE SSL implementation to allow it to work 
  +  with non-Sun vendor's 1.4.x JVMs. (billbarker)
  +  /fix
   /changelog
   
 /subsection
  
  
  

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



Re: [5] hotfixes

2003-07-18 Thread Remy Maucherat
Tim Funk wrote:
One feature of enterprise ready software is the ability to apply small 
patches to an existing system. For example: if a single class (or a few 
classes) have an error and that is the only fix - it might be nice to 
deploy a jar (or jars) that have a higher classloader preference. (But 
not parent loading)

This might be nice for those who want bug fixes but they don't (or can't 
recompile everything) and need a bug fixed and can't wait for the next 
release. (Due to PHB syndrome)

The alternative is to make the unpack the jar into the classes dir. This 
can also be error prone when cleaning up if the user has their own classes.

Currently o.a.c.startup.ClassLoaderFactory just does a standard 
directory listing. It might be nice to have the directory listed sorted 
in some manner so files with certain attributes might be loaded first.

I was thinking of either
- sorting by date
- looking for hotfix--MM--hh-mm-ss.jar  (or similar) first and 
sorting those files by name so the newest ones get loaded first.

Comments?
Sounds like a good idea :)
I have released hotfixes in the past, in the form of an archive which 
contained unpacked classes (which have a priority over the JARs). 
Distributing a timestamped JAR seems cleaner.

Remy

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


[5.0] Tester

2003-07-18 Thread Remy Maucherat
I have put the tester back in activity for TC 5 (and it caught the 
failure for error pages), but unfortunately there are a few limitations 
caused by the HTTP client used (for example, if the status is 500, you 
can't read the content). It would be a good idea IMO to switch to 
commons-httpclient (which I'll do, but it's not a very high priority).

Comments ?

Remy



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


cvs commit: jakarta-tomcat-catalina/tester/src/bin tester.xml tester.bat tester.sh

2003-07-18 Thread remm
remm2003/07/18 02:47:23

  Modified:tester/src/bin tester.xml
  Removed: tester   build.bat build.sh
   tester/src/bin tester.bat tester.sh
  Log:
  - Fix some obvious tester problems.
  
  Revision  ChangesPath
  1.4   +20 -19jakarta-tomcat-catalina/tester/src/bin/tester.xml
  
  Index: tester.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/tester/src/bin/tester.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- tester.xml11 Sep 2002 03:33:58 -  1.3
  +++ tester.xml18 Jul 2003 09:47:23 -  1.4
  @@ -8,7 +8,8 @@
   !--  property name=protocol   value=HTTP/1.0/ --
 property name=protocol   value=/ !-- Use HttpURLConnection --
 property name=context.path   value=/tester/
  -  property name=examples.path  value=/jsp-examples/
  +  property name=jsp-examples.path  value=/jsp-examples/
  +  property name=servlets-examples.path  value=/servlets-examples/
 property name=golden.pathvalue=${context.path}/golden/
 property name=manager.path   value=/manager/
 property name=reload.pathvalue=/tester/
  @@ -33,8 +34,8 @@
   
   !-- Should be able to use relative path to document root --
   tester host=${host} port=${port} protocol=${protocol}
  - request=${examples.path}/.. debug=${debug}
  -  status=302/
  + request=${jsp-examples.path}/.. debug=${debug}
  +  status=200/
   
   !-- Should be able to successfully retrieve a golden file --
   tester host=${host} port=${port} protocol=${protocol}
  @@ -115,37 +116,37 @@
   
   !-- Should be able to execute the Date example --
   tester host=${host} port=${port} protocol=${protocol}
  - request=${examples.path}/dates/date.jsp debug=${debug}
  + request=${jsp-examples.path}/dates/date.jsp debug=${debug}
 status=200/
   
   !-- Should not be able to view the source of the Date example --
   tester host=${host} port=${port} protocol=${protocol}
  - request=${examples.path}/dates/date.Jsp debug=${debug}
  + request=${jsp-examples.path}/dates/date.Jsp debug=${debug}
 status=404/
   
   !-- Should not be able to view the source of the Date example --
   tester host=${host} port=${port} protocol=${protocol}
  - request=${examples.path}/dates/Date.jsp debug=${debug}
  + request=${jsp-examples.path}/dates/Date.jsp debug=${debug}
 status=404/
   
   !-- Should not be able to view the source of the Date example --
   tester host=${host} port=${port} protocol=${protocol}
  - request=${examples.path}/Dates/date.jsp debug=${debug}
  + request=${jsp-examples.path}/Dates/date.jsp debug=${debug}
 status=404/
   
   !-- Should be able to execute the HelloWorld servlet example --
   tester host=${host} port=${port} protocol=${protocol}
  - request=${examples.path}/servlet/HelloWorldExample debug=${debug}
  + request=${servlets-examples.path}/servlet/HelloWorldExample 
debug=${debug}
 status=200/
   
   !-- Should not be able to execute HelloWorld with different cases --
   tester host=${host} port=${port} protocol=${protocol}
  - request=${examples.path}/servlet/helloWorldExample debug=${debug}
  + request=${servlets-examples.path}/servlet/helloWorldExample 
debug=${debug}
 status=404/
   
   !-- Should not be able to execute HelloWorld with different cases --
   tester host=${host} port=${port} protocol=${protocol}
  - request=${examples.path}/Servlet/HelloWorldExample debug=${debug}
  + request=${servlets-examples.path}/Servlet/HelloWorldExample 
debug=${debug}
 status=404/
   
 /target
  @@ -197,7 +198,7 @@
   
   !-- Verify we can access the JSP page normally --
   tester host=${host} port=${port} protocol=${protocol}
  - request=${examples.path}/snp/snoop.jsp
  + request=${jsp-examples.path}/snp/snoop.jsp
 status=200/
   
 /target
  @@ -241,25 +242,25 @@
   tester host=${host} port=${port} protocol=${protocol}
request=${context.path}/ErrorPage05?type=Array
  debug=${debug}
  -  status=200
  +  status=500
 outContent=ErrorPage06 PASSED - JSP/
   
   tester host=${host} port=${port} protocol=${protocol}
request=${context.path}/WrappedErrorPage05?type=Array
  debug=${debug}
  -  status=200
  +  status=500
 outContent=ErrorPage06 PASSED - JSP/
   
   tester host=${host} port=${port} protocol=${protocol}
request=${context.path}/ErrorPage05?type=Number
  debug=${debug}
  -  status=200
  +  status=500
 outContent=ErrorPage06 PASSED - HTML/
   
   tester host=${host} port=${port} 

[VOTE] 4.1.26 stability rating

2003-07-18 Thread Remy Maucherat
[ ] Alpha
[ ] Beta
[ ] Stable
I hope people had enough time to test this build (and thanks for voting) :)

Remy



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


Re: [5.0] Tester

2003-07-18 Thread Tim Funk
Is there any chance we'd want to use Latka instead? (Which uses HttpClient)

-Tim

Remy Maucherat wrote:
I have put the tester back in activity for TC 5 (and it caught the 
failure for error pages), but unfortunately there are a few limitations 
caused by the HTTP client used (for example, if the status is 500, you 
can't read the content). It would be a good idea IMO to switch to 
commons-httpclient (which I'll do, but it's not a very high priority).

Comments ?

Remy



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


Re: [5.0] Tester

2003-07-18 Thread Remy Maucherat
Tim Funk wrote:
Is there any chance we'd want to use Latka instead? (Which uses HttpClient)
Well, I don't know that component ;-)
There's an apparent problem with it, though: it's an alpha 1 release, 
and doesn't seem to be evolving anymore (last release in 2001, so it's 
likely not in sync with HttpClient). Any other ideas ?

I think the safest bet would be to adapt the TestClient class to use 
HttpClient 2.0 b2.

Remy

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


DO NOT REPLY [Bug 16144] - NullPointerException in JDBCRealm when password is null

2003-07-18 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16144.
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=16144

NullPointerException in JDBCRealm when password is null





--- Additional Comments From [EMAIL PROTECTED]  2003-07-18 10:52 ---
Created an attachment (id=7369)
Fixes NullPointerException in JDBCRealm. NULL password in DB should not be an error.

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



Re: mod_jk 1.2 endpoint cache

2003-07-18 Thread Henri Gomez
Glenn Nielsen a écrit :
I have been testing mod_jk 1.2.5 with Apache 2 and load balancing.

I noticed in the source that mod_jk 1.2 endpoint cache's are disabled
by forcing ep_cache_sz=0.  I did a cvs log and could not find any
comments on why this is so.  Is there a reason why this is disabled?
Using a cache with a cache timeout sure would be handy for Apache 2
when using the worker MPM.
This feature is documented in the jk docs and I don't see where anything
is mentioned that it is disabled.


I allways set cache in workers.properties but yes we should fix the
documentation to explain that it's disabled by default.
I can do it ASAP

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


Re: [5.0] Tester

2003-07-18 Thread Tim Funk
I don't have much experience using Latka either but it used HttpClient and 
appeared to use an xml config file for all the tests. It also has the ability 
to add your own condition classes too.

But it does appear dormant in commons. :(

+1 to using just HttpClient

-Tim

Remy Maucherat wrote:
Tim Funk wrote:

Is there any chance we'd want to use Latka instead? (Which uses 
HttpClient)


Well, I don't know that component ;-)
There's an apparent problem with it, though: it's an alpha 1 release, 
and doesn't seem to be evolving anymore (last release in 2001, so it's 
likely not in sync with HttpClient). Any other ideas ?

I think the safest bet would be to adapt the TestClient class to use 
HttpClient 2.0 b2.

Remy


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


Re: mod_jk 1.2.5 release

2003-07-18 Thread Henri Gomez
Glenn Nielsen a écrit :

I have taken care of the serveral minor bug fixes I wanted to get
into the mod_jk 1.2.5 release.  But I still have the question
below about endpoint caching.
I would like to renable endpoint caching for use by threaded servers.

Is there any reason to not do this?

Regards,

Glenn

Glenn Nielsen wrote:

I have been testing mod_jk 1.2.5 with Apache 2 and load balancing.

I noticed in the source that mod_jk 1.2 endpoint cache's are disabled
by forcing ep_cache_sz=0.  I did a cvs log and could not find any
comments on why this is so.  Is there a reason why this is disabled?
Using a cache with a cache timeout sure would be handy for Apache 2
when using the worker MPM.
This feature is documented in the jk docs and I don't see where anything
is mentioned that it is disabled.
Ok, if you activate it by default, how many entries we'll be defined by
default so I could update documentation ?
In general I'm using 16 entries in cache by worker

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


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

2003-07-18 Thread hgomez
hgomez  2003/07/18 04:06:43

  Modified:jk/xdocs/jk workershowto.xml
  Log:
  Indicate that cache is disable by default.
  If Glenn set a default valuen I'll update the doc
  
  Revision  ChangesPath
  1.13  +1 -0  jakarta-tomcat-connectors/jk/xdocs/jk/workershowto.xml
  
  Index: workershowto.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/jk/workershowto.xml,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- workershowto.xml  27 May 2003 13:04:46 -  1.12
  +++ workershowto.xml  18 Jul 2003 11:06:43 -  1.13
  @@ -207,6 +207,7 @@
   bcachesize/b property is usefull when you're using JK in multithreaded 
   web servers such as Apache 2.0, IIS and Netscape. They will benefit the most by 
   setting this value to a higher level (such as the estimated average concurrent 
users for Tomcat).
  +If cachesize is not set, the connection cache support is disabled.
   /p
   
   p
  
  
  

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



Re: mod_jk 1.2 endpoint cache

2003-07-18 Thread Glenn Nielsen
Henri Gomez wrote:
Glenn Nielsen a écrit :

I have been testing mod_jk 1.2.5 with Apache 2 and load balancing.

I noticed in the source that mod_jk 1.2 endpoint cache's are disabled
by forcing ep_cache_sz=0.  I did a cvs log and could not find any
comments on why this is so.  Is there a reason why this is disabled?
Using a cache with a cache timeout sure would be handy for Apache 2
when using the worker MPM.
This feature is documented in the jk docs and I don't see where anything
is mentioned that it is disabled.


I allways set cache in workers.properties but yes we should fix the
documentation to explain that it's disabled by default.
I can do it ASAP

What I am saying is that use of the endpoint cache is completely disabled
in the code, it doesn't matter what you set the cachesize to in worker.properties.
Look at ajp_init() in ajp_common.c

Glenn

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


Re: mod_jk 1.2 endpoint cache

2003-07-18 Thread Henri Gomez
Glenn Nielsen a écrit :

Henri Gomez wrote:

Glenn Nielsen a écrit :

I have been testing mod_jk 1.2.5 with Apache 2 and load balancing.

I noticed in the source that mod_jk 1.2 endpoint cache's are disabled
by forcing ep_cache_sz=0.  I did a cvs log and could not find any
comments on why this is so.  Is there a reason why this is disabled?
Using a cache with a cache timeout sure would be handy for Apache 2
when using the worker MPM.
This feature is documented in the jk docs and I don't see where anything
is mentioned that it is disabled.




I allways set cache in workers.properties but yes we should fix the
documentation to explain that it's disabled by default.
I can do it ASAP

What I am saying is that use of the endpoint cache is completely disabled
in the code, it doesn't matter what you set the cachesize to in 
worker.properties.

Look at ajp_init() in ajp_common.c
Hey yes you're right, it should be instead :

p-ep_cache_sz = cache_sz;

You commit or I ?

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


Re: mod_jk 1.2 endpoint cache

2003-07-18 Thread Henri Gomez
Glenn Nielsen a écrit :

Henri Gomez wrote:

Glenn Nielsen a écrit :

I have been testing mod_jk 1.2.5 with Apache 2 and load balancing.

I noticed in the source that mod_jk 1.2 endpoint cache's are disabled
by forcing ep_cache_sz=0.  I did a cvs log and could not find any
comments on why this is so.  Is there a reason why this is disabled?
Using a cache with a cache timeout sure would be handy for Apache 2
when using the worker MPM.
This feature is documented in the jk docs and I don't see where anything
is mentioned that it is disabled.




I allways set cache in workers.properties but yes we should fix the
documentation to explain that it's disabled by default.
I can do it ASAP

What I am saying is that use of the endpoint cache is completely disabled
in the code, it doesn't matter what you set the cachesize to in 
worker.properties.

Look at ajp_init() in ajp_common.c


Ooops didn't see all the code :

---

ep_cache_sz is correctly set in line 1440

BTW, I wonder why there is a ep_mincache_sz, it's not used elsewhere

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


RE: [VOTE] 4.1.26 stability rating

2003-07-18 Thread Shapira, Yoav

Howdy,
On a couple of days testing, no problems.  Very light JSP testing, heavy
servlet testing.  Easily beta:

[ ] Alpha
[X] Beta
[ ] Stable

With some more time, more testing, maybe stable.

Yoav Shapira



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


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



RE: [5] hotfixes

2003-07-18 Thread Shapira, Yoav

Howdy,

Currently o.a.c.startup.ClassLoaderFactory just does a standard
directory
listing. It might be nice to have the directory listed sorted in some
manner
so files with certain attributes might be loaded first.

I was thinking of either
- sorting by date
- looking for hotfix--MM--hh-mm-ss.jar  (or similar) first and
sorting those files by name so the newest ones get loaded first.

Comments?

There used to be servers that did this (IPlanet and JServ come to mind,
both using alphabetical sorting), and the amount of hassle that caused
to developers was huge.  Even to date, I see developers who rely on jar
loading order to resolve having two classes with the same name in the
JVM.

I don't think this is a good idea.  In the case for a hotfix, I would
rather see a new jar altogether, replacing an existing jar.  Not an
addition, not an expansion, nor some fancy overriding mechanism.  It
significantly increases classloading debugging capability (which jar
did this class really get loaded from?).

I also tend to not fully agree with your beginning premise:

One feature of enterprise ready software is the ability to apply small
patches to an existing system.

That's a nice to have, not essential, and a deterrent due to the above
reasoning in the worst case.  I would consider tomcat enterprise-ready
now, without this feature per-se.

Perhaps I'm misinterpreting what small patches are, though?  Did you
have examples in mind?  I think it's the component owner's
responsibility to provide the fix/patch, and to do so in the manner best
fitting the component.  In most java cases, I think that's an updated
jar.  If the fix requires many jars, then probably the product wasn't
properly divided into modular jars to start with.

I don't mean to sound extreme on this ;)  I've heard far worse ideas.
But I think for a general purpose server this causes more possible
confusion and problems for users than it does good.

Yoav Shapira







This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


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



Re: mod_jk 1.2 endpoint cache

2003-07-18 Thread Glenn Nielsen
Henri Gomez wrote:
Glenn Nielsen a écrit :

Henri Gomez wrote:

Glenn Nielsen a écrit :

I have been testing mod_jk 1.2.5 with Apache 2 and load balancing.

I noticed in the source that mod_jk 1.2 endpoint cache's are disabled
by forcing ep_cache_sz=0.  I did a cvs log and could not find any
comments on why this is so.  Is there a reason why this is disabled?
Using a cache with a cache timeout sure would be handy for Apache 2
when using the worker MPM.
This feature is documented in the jk docs and I don't see where 
anything
is mentioned that it is disabled.




I allways set cache in workers.properties but yes we should fix the
documentation to explain that it's disabled by default.
I can do it ASAP

What I am saying is that use of the endpoint cache is completely disabled
in the code, it doesn't matter what you set the cachesize to in 
worker.properties.

Look at ajp_init() in ajp_common.c


Ooops didn't see all the code :

---

ep_cache_sz is correctly set in line 1440

BTW, I wonder why there is a ep_mincache_sz, it's not used elsewhere

Sorry for the confusion, you are right.  It does get set later on.

Did you get a chance to review the minor changes I made in the last week?

With that resolved I am ready to roll another test mod_jk 1.2.5 release.

If that looks ok we can vote on doing the release.

Regards,

Glenn



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


Re: [5] hotfixes

2003-07-18 Thread Glenn Nielsen
Well stated, I agree with your concerns.

Shapira, Yoav wrote:
Howdy,


Currently o.a.c.startup.ClassLoaderFactory just does a standard
directory

listing. It might be nice to have the directory listed sorted in some
manner
so files with certain attributes might be loaded first.
I was thinking of either
- sorting by date
- looking for hotfix--MM--hh-mm-ss.jar  (or similar) first and
sorting those files by name so the newest ones get loaded first.
Comments?


There used to be servers that did this (IPlanet and JServ come to mind,
both using alphabetical sorting), and the amount of hassle that caused
to developers was huge.  Even to date, I see developers who rely on jar
loading order to resolve having two classes with the same name in the
JVM.
I don't think this is a good idea.  In the case for a hotfix, I would
rather see a new jar altogether, replacing an existing jar.  Not an
addition, not an expansion, nor some fancy overriding mechanism.  It
significantly increases classloading debugging capability (which jar
did this class really get loaded from?).
I also tend to not fully agree with your beginning premise:


One feature of enterprise ready software is the ability to apply small 
patches to an existing system.


That's a nice to have, not essential, and a deterrent due to the above
reasoning in the worst case.  I would consider tomcat enterprise-ready
now, without this feature per-se.
Perhaps I'm misinterpreting what small patches are, though?  Did you
have examples in mind?  I think it's the component owner's
responsibility to provide the fix/patch, and to do so in the manner best
fitting the component.  In most java cases, I think that's an updated
jar.  If the fix requires many jars, then probably the product wasn't
properly divided into modular jars to start with.
I don't mean to sound extreme on this ;)  I've heard far worse ideas.
But I think for a general purpose server this causes more possible
confusion and problems for users than it does good.
Yoav Shapira



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


AccessLogValve.java - Missing +

2003-07-18 Thread Yuri Schimke
Funkman, Thanks for fixing the timezone calculation bug.  I know I'm
just being picky now, but shouldn't positive timezone offsets have a
(redundant) '+' at the start.

From http://httpd.apache.org/docs/logs.html#common

[10/Oct/2000:13:55:36 -0700] (%t)
The time that the server finished processing the
request. The format is: 
[day/month/year:hour:minute:second zone]
day = 2*digit
month = 3*letter
year = 4*digit
hour = 2*digit
minute = 2*digit
second = 2*digit
zone = (`+' | `-') 4*digit
It is possible to have the time displayed in another
format by specifying %{format}t in the log format
string, where format is as in strftime(3) from the C
standard library.


On Wed, 2003-07-09 at 02:12, [EMAIL PROTECTED] wrote:



   +private String calculateTimeZoneOffset(long offset) {
   +StringBuffer tz = new StringBuffer();
   +if ((offset0))  {
   +tz.append(-);
   +offset = -offset;
   +}
   +
   +long hourOffset = offset/(1000*60*60);
   +long minuteOffset = (offset/(1000*60)) % 60;
   +
   +if (hourOffset10)
   +tz.append(0);
   +tz.append(hourOffset);
   +
   +if (minuteOffset10)
   +tz.append(0);
   +tz.append(minuteOffset);
   +
   +return tz.toString();
   +}
   +

--
Yuri Schimke
Aqris Software
+372 53 415 579

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



Re: mod_jk 1.2 endpoint cache

2003-07-18 Thread Henri Gomez

Sorry for the confusion, you are right.  It does get set later on.

Did you get a chance to review the minor changes I made in the last week?
Yes and I don't see any problems.

With that resolved I am ready to roll another test mod_jk 1.2.5 release.


If that looks ok we can vote on doing the release.
The build works for Apache 1.3/2.0 on Linux, I should make some tests,
and welcome any Windows binaries for Apache 2.0 ;)


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


DO NOT REPLY [Bug 21709] New: - %= % does not convert to string before passing arguments to custom tag handlers

2003-07-18 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21709.
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=21709

%= % does not convert to string before passing arguments to custom tag handlers

   Summary: %= % does not convert to string before passing
arguments to custom tag handlers
   Product: Tomcat 4
   Version: 4.1.24
  Platform: All
OS/Version: Windows NT/2K
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


This is a pretty obscure problem with a workaround, but to the best of my 
knowledge the error is a violation of the servlet/JSP spec so should be fixed.

I have a custom tag called krm:action and I am using the JSTL in this example.

c:set var=title
c:out value=${row.shortDesc}/
/c:set
krm:action display=link type=componentNum componentNum=PL-SITE-01 
title=%= pageContext.getAttribute(title) %
c:out value=${row.id}/
/krm:action

The compiler complains as follows:

[ServletException in:/adminPicklist/siteList-body.jsp] Unable to compile class 
for JSP

An error occurred at line: -1 in the jsp file: null

Generated servlet error:
[javac] Since fork is true, ignoring compiler setting.
[javac] Compiling 1 source file
[javac] Since fork is true, ignoring compiler setting.
[javac] C:\jakarta-tomcat-4.1.24
\work\Standalone\localhost\ebspnp\adminPicklist\siteList_0002dbody_jsp.java:140:
 setTitle(java.lang.String) in com.bah.krm.taglib.util.ActionTag cannot be 
applied to (java.lang.Object)
[javac]   _jspx_th_krm_action_0.setTitle( 
pageContext.getAttribute(title) );
[javac]^
[javac] 1 error

The simple workaround is just do a manual toString() as follows:

c:set var=title
c:out value=${row.shortDesc}/
/c:set
krm:action display=link type=componentNum componentNum=PL-SITE-01 
title=%= pageContext.getAttribute(title).toString() %
c:out value=${row.id}/
/krm:action

But the toString() call should happen automatically, shouldn't it?  Isn't that 
part of the spec?

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



cvs commit: jakarta-tomcat-5 build.properties.default build.xml

2003-07-18 Thread remm
remm2003/07/18 07:29:29

  Modified:.build.properties.default build.xml
  Log:
  - Add commons-httpclient to the download list, for use with the tester
component.
  
  Revision  ChangesPath
  1.98  +15 -8 jakarta-tomcat-5/build.properties.default
  
  Index: build.properties.default
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
  retrieving revision 1.97
  retrieving revision 1.98
  diff -u -r1.97 -r1.98
  --- build.properties.default  30 Jun 2003 18:21:34 -  1.97
  +++ build.properties.default  18 Jul 2003 14:29:29 -  1.98
  @@ -101,6 +101,15 @@
   
commons-logging.loc=http://www.apache.org/dist/jakarta/commons/logging/binaries/commons-logging-1.0.3.tar.gz
   
   
  +# - Commons Modeler, version 1.1 or later -
  +commons-modeler.home=${base.path}/commons-modeler-1.1dev
  +#commons-modeler.lib=${commons-modeler.home}
  +commons-modeler.lib=${commons-modeler.home}
  +commons-modeler.jar=${commons-modeler.lib}/commons-modeler.jar
  
+#commons-modeler.loc=http://jakarta.apache.org/builds/jakarta-commons/release/commons-modeler/v1.0/commons-modeler-1.0.tar.gz
  +commons-modeler.cvs.loc=jakarta-commons/modeler
  +
  +
   # - Java Naming and Directory Interface (JNDI), version 1.2 or later -
   # Note: Optional with JDK 1.3+
   jndi.home=${base.path}/jndi-1.2.1
  @@ -144,13 +153,11 @@
   
commons-dbcp.loc=http://jakarta.apache.org/builds/jakarta-commons/release/commons-dbcp/v1.0/commons-dbcp-1.0.zip
   
   
  -# - Commons Modeler, version 1.0 or later -
  -commons-modeler.home=${base.path}/commons-modeler-1.1dev
  -#commons-modeler.lib=${commons-modeler.home}
  -commons-modeler.lib=${commons-modeler.home}
  -commons-modeler.jar=${commons-modeler.lib}/commons-modeler.jar
  
-#commons-modeler.loc=http://jakarta.apache.org/builds/jakarta-commons/release/commons-modeler/v1.0/commons-modeler-1.0.tar.gz
  -commons-modeler.cvs.loc=jakarta-commons/modeler
  +# - Commons HttpClient, version 2.0 or later -
  +commons-httpclient.home=${base.path}/commons-httpclient-2.0-beta2
  +commons-httpclient.lib=${commons-httpclient.home}
  +commons-httpclient.jar=${commons-httpclient.lib}/commons-httpclient-2.0-beta2.jar
  
+commons-httpclient.loc=http://www.apache.org/dist/jakarta/commons/httpclient/binary/commons-httpclient-2.0-beta2.tar.gz
   
   
   # - Commons Pool, version 1.0.1 or later -
  
  
  
  1.141 +5 -0  jakarta-tomcat-5/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
  retrieving revision 1.140
  retrieving revision 1.141
  diff -u -r1.140 -r1.141
  --- build.xml 16 Jul 2003 22:50:41 -  1.140
  +++ build.xml 18 Jul 2003 14:29:29 -  1.141
  @@ -1589,6 +1589,11 @@
 param name=destdir value=${base.path}/
   /antcall
   
  +antcall target=downloadgz
  +  param name=sourcefile value=${commons-httpclient.loc}/
  +  param name=destfile value=${commons-httpclient.jar}/
  +/antcall
  +
   antcall target=downloadfile
 param name=sourcefile value=${nsis.loc}/
 param name=destfile value=${nsis.exe}/
  
  
  

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



mod_jk 1.2.5 test source distribution

2003-07-18 Thread Glenn Nielsen
I have generated another mod_jk 1.2.5 test source distribution,
it can be found at:
http://cvs.apache.org/~glenn/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz

Please build and test binaries for different OS and web servers.

I will call for a release vote for mod_jk 1.2.5 one week from today.
Then do the release Monday July 28 if the vote to release succeeds.
Does that schedule work for everyone?

Thanks,

Glenn

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


DO NOT REPLY [Bug 21711] New: - Error when compiling a JSP that uses a TLD 1.1

2003-07-18 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21711.
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=21711

Error when compiling a JSP that uses a TLD 1.1

   Summary: Error when compiling a JSP that uses a TLD 1.1
   Product: Tomcat 5
   Version: 5.0.4
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When compiling a jsp that uses a 1.1 TLD, with tag that have an attribute called 
id, it generates the following error:

java.lang.ClassCastException
at javax.servlet.jsp.tagext.TagData.getAttributeString(TagData.java:176)
at javax.servlet.jsp.tagext.TagData.getId(TagData.java:129)
at javax.servlet.jsp.tagext.TagInfo.getVariableInfo(TagInfo.java:282)
at org.apache.jasper.compiler.Node$CustomTag.setTagData(Node.java:1475)
at org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.
java:788)
at org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1444)
at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2142)
at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2184)
at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2190)
at org.apache.jasper.compiler.Node$Root.accept(Node.java:471)
at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2142)
at org.apache.jasper.compiler.Validator.validate(Validator.java:1499)
at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:264)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:458)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:444)
at org.apache.jasper.JspCompilationContext.
compile(JspCompilationContext.java:603)
at org.apache.jasper.servlet.JspServletWrapper.
service(JspServletWrapper.java:300)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:
293)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at org.apache.catalina.core.ApplicationFilterChain.
internalDoFilter(ApplicationFilterChain.java:286)
at org.apache.catalina.core.ApplicationFilterChain.
doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.
invoke(StandardWrapperValve.java:256)
at org.apache.catalina.core.StandardValveContext.
invokeNext(StandardValveContext.java:151)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.
java:562)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:974)
at org.apache.catalina.core.StandardContextValve.
invoke(StandardContextValve.java:205)
at org.apache.catalina.core.StandardValveContext.
invokeNext(StandardValveContext.java:151)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.
java:562)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:974)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.
java:177)
at org.apache.catalina.core.StandardValveContext.
invokeNext(StandardValveContext.java:151)
at org.apache.catalina.valves.ErrorDispatcherValve.
invoke(ErrorDispatcherValve.java:171)
at org.apache.catalina.core.StandardValveContext.
invokeNext(StandardValveContext.java:149)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.
java:172)
at org.apache.catalina.core.StandardValveContext.
invokeNext(StandardValveContext.java:149)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.
java:562)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:974)
at org.apache.catalina.core.StandardEngineValve.
invoke(StandardEngineValve.java:156)
at org.apache.catalina.core.StandardValveContext.
invokeNext(StandardValveContext.java:151)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.
java:562)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:974)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:
203)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.
java:637)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.
processConnection(Http11Protocol.java:488)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.
java:568)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.
run(ThreadPool.java:631)
at 

Re: AccessLogValve.java - Missing +

2003-07-18 Thread Tim Funk
Doh! Your right. ( If its supposed to mimic the apache's %t, which I think it 
should)

-Tim

Yuri Schimke wrote:
Funkman, Thanks for fixing the timezone calculation bug.  I know I'm
just being picky now, but shouldn't positive timezone offsets have a
(redundant) '+' at the start.
From http://httpd.apache.org/docs/logs.html#common



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


Re: [5] hotfixes

2003-07-18 Thread Martin Algesten
Hello,

I don't agree with Glenn or Yoav.

For each tomcat 4.1.x version I use there are a couple of things I have 
to fix over and over again. My approach to making changes is: 1) take 
the official binary release of tomcat and 2) make *minimal* changes to 
address the problems I have with it.

Currently I end up with compiling a couple of java classes manually 
with the destination directory being the server/classes such as:
javac -d /jakarta-tomcat-4.1.24/server/classes StandardContext.java

I strongly don't want to replace the whole 'catalina.jar' because of my 
tiny change (risking screwing something up unintentionally).

I can clearly see a benefit of also having an option to deploy my 
changes as a jar instead of the .class files I now end up with. I 
wasn't aware that the .jar files were not sorted alphabetically (and 
that explains some trouble I've had in the past trying to rely on it). 
I strongly suggest they should be, it doesn't hurt and will probably 
help silly users like myself.

However I'm not sure about a 'hotfix-' kind of prefix for jarfiles 
since it is not explicit enough (you have to know you can create a file 
with that name and that it will be priorities over other jar files). I 
think a better approach would be to have a 'lib-hotfix' directory so 
you get a visual indicator that the possibility of hotfixes exist.

Martin



On Friday, July 18, 2003, at 02:32 PM, Glenn Nielsen wrote:

Well stated, I agree with your concerns.

Shapira, Yoav wrote:
Howdy,
Currently o.a.c.startup.ClassLoaderFactory just does a standard
directory
listing. It might be nice to have the directory listed sorted in some
manner
so files with certain attributes might be loaded first.
I was thinking of either
- sorting by date
- looking for hotfix--MM--hh-mm-ss.jar  (or similar) first 
and
sorting those files by name so the newest ones get loaded first.

Comments?
There used to be servers that did this (IPlanet and JServ come to 
mind,
both using alphabetical sorting), and the amount of hassle that caused
to developers was huge.  Even to date, I see developers who rely on 
jar
loading order to resolve having two classes with the same name in the
JVM.
I don't think this is a good idea.  In the case for a hotfix, I would
rather see a new jar altogether, replacing an existing jar.  Not an
addition, not an expansion, nor some fancy overriding mechanism.  It
significantly increases classloading debugging capability (which jar
did this class really get loaded from?).
I also tend to not fully agree with your beginning premise:
One feature of enterprise ready software is the ability to apply 
small patches to an existing system.
That's a nice to have, not essential, and a deterrent due to the above
reasoning in the worst case.  I would consider tomcat enterprise-ready
now, without this feature per-se.
Perhaps I'm misinterpreting what small patches are, though?  Did you
have examples in mind?  I think it's the component owner's
responsibility to provide the fix/patch, and to do so in the manner 
best
fitting the component.  In most java cases, I think that's an updated
jar.  If the fix requires many jars, then probably the product wasn't
properly divided into modular jars to start with.
I don't mean to sound extreme on this ;)  I've heard far worse ideas.
But I think for a general purpose server this causes more possible
confusion and problems for users than it does good.
Yoav Shapira


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


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


Re: [5.0] Tester

2003-07-18 Thread Costin Manolache
What about anteater ? 

Costin


Tim Funk wrote:

 Is there any chance we'd want to use Latka instead? (Which uses
 HttpClient)
 
 -Tim
 
 Remy Maucherat wrote:
 I have put the tester back in activity for TC 5 (and it caught the
 failure for error pages), but unfortunately there are a few limitations
 caused by the HTTP client used (for example, if the status is 500, you
 can't read the content). It would be a good idea IMO to switch to
 commons-httpclient (which I'll do, but it's not a very high priority).
 
 Comments ?
 
 Remy




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



Re: mod_jk 1.2.5 test source distribution

2003-07-18 Thread Henri Gomez
Glenn Nielsen a écrit :

I have generated another mod_jk 1.2.5 test source distribution,
it can be found at:
http://cvs.apache.org/~glenn/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz

Please build and test binaries for different OS and web servers.

I will call for a release vote for mod_jk 1.2.5 one week from today.
Then do the release Monday July 28 if the vote to release succeeds.
Does that schedule work for everyone?


That's ok for me.

It works for me on Redhat 7.2 + Apache 2.0.47 and Redhat 8.0 + Apache 
2.0.40 (+ updates from Redhat).



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


Re: [5] hotfixes

2003-07-18 Thread Tim Funk
Yeah, I am scared of side effects too. This funtionality will be helpful in 
the following situations:
- My previous post where the access log doesn't print '+' in front of the offset
- ExtendedAccessLogValve printed the date instead of bytes (recent patch)
- The recent Connector fixes we have seen for SSL related issues
- JDBC, JNDI realm fixes
- Misc valve or clustering fixes

In all of the above - they are for bug fixes that don't warrant an immediate 
release. They are usually for fringe cases where it makes tomcat a PITA to 
use if not fixed.

If one chooses not to use this feature, then the current functionality stays 
the same.

The patch I have in mind will not include the webapp classloader. Since the 
spec doesn't seem to define a jar order - I prefer not to impose one.

Currently a user has 2 workarounds:
- Take the milestone source tree and apply the patches and build
- Build from HEAD
- Place the fix in XXX/classes
The first two scenarios is a lot of work and very risky since other 
unintended changes can easily be introduced. (At least the HEAD method is)
The third scenario can be hard to maintain from an admin point of view if the 
user also uses their own classes in the lib directory.

I also like Martin 's idea of possibly introducing another directory called 
lib-hotfix. That seems cleaner and clearer than a date (or file) based sort.

-Tim

Shapira, Yoav wrote:
Perhaps I'm misinterpreting what small patches are, though?  Did you
have examples in mind?  I think it's the component owner's
responsibility to provide the fix/patch, and to do so in the manner best
fitting the component.  In most java cases, I think that's an updated
jar.  If the fix requires many jars, then probably the product wasn't
properly divided into modular jars to start with.


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


Re: [5.0] Tester

2003-07-18 Thread Remy Maucherat
Costin Manolache wrote:
What about anteater ? 
(yet another project I didn't know about)
The sad truth is that I'm lazy :)
I want to rewrite the minimum possible amount of code and fix the tests 
which can't work with the JDK's HTTP client (ex: it returns 500 - TC 5 
now restores the original error code; neat - but I still want to read 
the entity body; the JDK then throws an exception to inform me I'm 
stupid to attempt to do that; thanks Sun) :)

Remy



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


Bug in JkMX.java

2003-07-18 Thread Davanum Srinivas
Do you want me to create a bugzilla report? here's the diff. Need to check for the 
whole class
(mx4j.adaptor.http.HttpAdaptor)

Thanks,
dims

Index: JkMX.java
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/JkMX.java,v
retrieving revision 1.12
diff -d -u -b -B -w -u -r1.12 JkMX.java
--- JkMX.java   2 Jun 2003 01:22:32 -   1.12
+++ JkMX.java   18 Jul 2003 15:24:29 -
@@ -112,7 +112,7 @@
 public void loadAdapter() throws IOException {
 boolean adapterLoaded = false;

-if (classExists(mx4j.adaptor.http)) {
+if (classExists(mx4j.adaptor.http.HttpAdaptor)) {
 try {
 serverName = new ObjectName(Http:name=HttpAdaptor);
 mserver.createMBean(mx4j.adaptor.http.HttpAdaptor, serverName, 
null);


=
Davanum Srinivas - http://webservices.apache.org/~dims/

__
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

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



[5.0] Optimizing the core a bit more

2003-07-18 Thread Remy Maucherat
In an effort to tweak the core a bit more to simplify things:

- Remove ContainerBase.invoke: A Container always has a Pipeline 
associated with it; as such, the Container interface should have a 
getPipeline method, and this should be called instead. This will reduce 
a bit the call stack.

- I noticed the RequestListenerValve was added twice to the pipeline 
(using the tester). This doesn't seem right, obviously.

- The RequestListenerValve builds the list of the listeners it must 
notify dynamically, on each request (twice for each request = lots of 
useless instanceof). This should IMO be done statically in start (with 
the array of listeners being cleared on stop).

Remy

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


Re: [5] hotfixes

2003-07-18 Thread Remy Maucherat
Tim Funk wrote:
Yeah, I am scared of side effects too. This funtionality will be helpful 
in the following situations:
- My previous post where the access log doesn't print '+' in front of 
the offset
- ExtendedAccessLogValve printed the date instead of bytes (recent patch)
- The recent Connector fixes we have seen for SSL related issues
- JDBC, JNDI realm fixes
- Misc valve or clustering fixes

In all of the above - they are for bug fixes that don't warrant an 
immediate release. They are usually for fringe cases where it makes 
tomcat a PITA to use if not fixed.

If one chooses not to use this feature, then the current functionality 
stays the same.

The patch I have in mind will not include the webapp classloader. Since 
the spec doesn't seem to define a jar order - I prefer not to impose one.

Currently a user has 2 workarounds:
- Take the milestone source tree and apply the patches and build
- Build from HEAD
- Place the fix in XXX/classes
The first two scenarios is a lot of work and very risky since other 
unintended changes can easily be introduced. (At least the HEAD method is)
The third scenario can be hard to maintain from an admin point of view 
if the user also uses their own classes in the lib directory.

I also like Martin 's idea of possibly introducing another directory 
called lib-hotfix. That seems cleaner and clearer than a date (or file) 
based sort.
After reading everyone's comments, I will vote -1 to the hotfix 
proposal, because:
- people will abuse it, have *lots* of hotfixes installed
- the subsequent bugs being reported will be harder to debug given the 
increased difficulty of reproducing the user's configuration
- users will basically expect us (= me the RM) to release one hotfix for 
every bugfix, which is something I don't want to do
- hotfix conflicts and incompatibilities
- added complexity in the container to manage the hotfixes (the 
container needs simplification whenever possible :) )
- the HTTPd project doesn't do it, for a very similar product; OTOH, M$ 
does it; one of the vendors is IMO more trustworthy than the other (ok, 
it's a bad argument ;-) )

Note that I did release hotfixes in very specific cases in the past, for 
security related problems.

Remy



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


Small issue with 4.1.26 catalina.sh

2003-07-18 Thread Shapira, Yoav

Howdy,
Tomcat 4.1.26-LE
Solaris 8
JDK 1.4.2

Invoking $CATALINA_HOME/bin/startup.sh produces the following output:

/home/shapira/tomcat/bin/catalina.sh: !: not found
Using CATALINA_BASE:   /home/shapira/tomcat
Using CATALINA_HOME:   /home/shapira/tomcat
Using CATALINA_TMPDIR: /home/shapira/tomcat/temp
Using JAVA_HOME:   /home/shapira/jdk/j2sdk1.4.2

The same output repeats when invoking shutdown.sh.  The server starts up
fine, works fine, and shuts down fine.

Why am I getting that :not found line?  I've never gotten it before.

Thanks,

Yoav Shapira
Millennium ChemInformatics





This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


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



RE: [5] hotfixes

2003-07-18 Thread Shapira, Yoav

Howdy,
I would also vote -1 as I mentioned before.  It's another source for
confusion and bugs, and does not add much in practice I think.  The
small bugs that necessitate one class changes are typically not
showstoppers, but more the PITA category that Tim referred to.  To the
individual developer/server admin, it's either:
- Sure it's PITA but I don't have tom worry; file a bug report and wait
for the next release, or
- This is so annoying I can't stand it and will put my own class files
here to fix it

If something is a real showstopper, we're going to want a real release
to fix it anyways, with documentation, testing, etc.

Yoav Shapira
Millennium ChemInformatics


-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED]
Sent: Friday, July 18, 2003 11:52 AM
To: Tomcat Developers List
Subject: Re: [5] hotfixes

Tim Funk wrote:
 Yeah, I am scared of side effects too. This funtionality will be
helpful
 in the following situations:
 - My previous post where the access log doesn't print '+' in front of
 the offset
 - ExtendedAccessLogValve printed the date instead of bytes (recent
patch)
 - The recent Connector fixes we have seen for SSL related issues
 - JDBC, JNDI realm fixes
 - Misc valve or clustering fixes

 In all of the above - they are for bug fixes that don't warrant an
 immediate release. They are usually for fringe cases where it makes
 tomcat a PITA to use if not fixed.

 If one chooses not to use this feature, then the current
functionality
 stays the same.

 The patch I have in mind will not include the webapp classloader.
Since
 the spec doesn't seem to define a jar order - I prefer not to impose
one.

 Currently a user has 2 workarounds:
 - Take the milestone source tree and apply the patches and build
 - Build from HEAD
 - Place the fix in XXX/classes

 The first two scenarios is a lot of work and very risky since other
 unintended changes can easily be introduced. (At least the HEAD
method
is)
 The third scenario can be hard to maintain from an admin point of
view
 if the user also uses their own classes in the lib directory.

 I also like Martin 's idea of possibly introducing another directory
 called lib-hotfix. That seems cleaner and clearer than a date (or
file)
 based sort.

After reading everyone's comments, I will vote -1 to the hotfix
proposal, because:
- people will abuse it, have *lots* of hotfixes installed
- the subsequent bugs being reported will be harder to debug given the
increased difficulty of reproducing the user's configuration
- users will basically expect us (= me the RM) to release one hotfix
for
every bugfix, which is something I don't want to do
- hotfix conflicts and incompatibilities
- added complexity in the container to manage the hotfixes (the
container needs simplification whenever possible :) )
- the HTTPd project doesn't do it, for a very similar product; OTOH, M$
does it; one of the vendors is IMO more trustworthy than the other (ok,
it's a bad argument ;-) )

Note that I did release hotfixes in very specific cases in the past,
for
security related problems.

Remy



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




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


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



Re: [5] hotfixes

2003-07-18 Thread Glenn Nielsen
Tim,

If the problem is that bug fixes have not made it into a release
in a timely manner, then we should be doing releases more frequently.
Or put back in place the nightly builds.
Using hotfixes to bridge the gap between releases is overkill IMHO.

I am still -1 on adding this.

Glenn

Tim Funk wrote:
Yeah, I am scared of side effects too. This funtionality will be helpful 
in the following situations:
- My previous post where the access log doesn't print '+' in front of 
the offset
- ExtendedAccessLogValve printed the date instead of bytes (recent patch)
- The recent Connector fixes we have seen for SSL related issues
- JDBC, JNDI realm fixes
- Misc valve or clustering fixes

In all of the above - they are for bug fixes that don't warrant an 
immediate release. They are usually for fringe cases where it makes 
tomcat a PITA to use if not fixed.

If one chooses not to use this feature, then the current functionality 
stays the same.

The patch I have in mind will not include the webapp classloader. Since 
the spec doesn't seem to define a jar order - I prefer not to impose one.

Currently a user has 2 workarounds:
- Take the milestone source tree and apply the patches and build
- Build from HEAD
- Place the fix in XXX/classes
The first two scenarios is a lot of work and very risky since other 
unintended changes can easily be introduced. (At least the HEAD method is)
The third scenario can be hard to maintain from an admin point of view 
if the user also uses their own classes in the lib directory.

I also like Martin 's idea of possibly introducing another directory 
called lib-hotfix. That seems cleaner and clearer than a date (or file) 
based sort.

-Tim

Shapira, Yoav wrote:

Perhaps I'm misinterpreting what small patches are, though?  Did you
have examples in mind?  I think it's the component owner's
responsibility to provide the fix/patch, and to do so in the manner best
fitting the component.  In most java cases, I think that's an updated
jar.  If the fix requires many jars, then probably the product wasn't
properly divided into modular jars to start with.




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


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


Re: [5] hotfixes

2003-07-18 Thread Tim Funk
Thats ok with me, I'm glad this was discussed in case this topic comes up in 
the future.

-Tim

Remy Maucherat wrote:
After reading everyone's comments, I will vote -1 to the hotfix 
proposal, because: 


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


DO NOT REPLY [Bug 21714] New: - MX4J mx4j.adaptor.http.HttpAdaptor is not loaded

2003-07-18 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21714.
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=21714

MX4J mx4j.adaptor.http.HttpAdaptor is not loaded

   Summary: MX4J mx4j.adaptor.http.HttpAdaptor is not loaded
   Product: Tomcat 4
   Version: Nightly Build
  Platform: All
   URL: http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-
connectors/jk/java/org/apache/jk/common/JkMX.java.diff?r
1=1.11r2=1.12diff_format=h
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Connector:Coyote JK 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Need to check for the whole class (mx4j.adaptor.http.HttpAdaptor) and not
mx4j.adaptor.http. See diff below :

Index: JkMX.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/JkMX.java,v
retrieving revision 1.12
diff -d -u -b -B -w -u -r1.12 JkMX.java
--- JkMX.java   2 Jun 2003 01:22:32 -   1.12
+++ JkMX.java   18 Jul 2003 15:24:29 -
@@ -112,7 +112,7 @@
 public void loadAdapter() throws IOException {
 boolean adapterLoaded = false;

-if (classExists(mx4j.adaptor.http)) {
+if (classExists(mx4j.adaptor.http.HttpAdaptor)) {
 try {
 serverName = new ObjectName(Http:name=HttpAdaptor);
 mserver.createMBean(mx4j.adaptor.http.HttpAdaptor,
serverName, null);

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



Re: Bug in JkMX.java

2003-07-18 Thread Davanum Srinivas
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21714

--- Davanum Srinivas [EMAIL PROTECTED] wrote:
 Do you want me to create a bugzilla report? here's the diff. Need to check for the 
 whole class
 (mx4j.adaptor.http.HttpAdaptor)
 
 Thanks,
 dims
 
 Index: JkMX.java
 ===
 RCS file: 
 /home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/JkMX.java,v
 retrieving revision 1.12
 diff -d -u -b -B -w -u -r1.12 JkMX.java
 --- JkMX.java   2 Jun 2003 01:22:32 -   1.12
 +++ JkMX.java   18 Jul 2003 15:24:29 -
 @@ -112,7 +112,7 @@
  public void loadAdapter() throws IOException {
  boolean adapterLoaded = false;
 
 -if (classExists(mx4j.adaptor.http)) {
 +if (classExists(mx4j.adaptor.http.HttpAdaptor)) {
  try {
  serverName = new ObjectName(Http:name=HttpAdaptor);
  mserver.createMBean(mx4j.adaptor.http.HttpAdaptor, serverName, 
 null);
 
 
 =
 Davanum Srinivas - http://webservices.apache.org/~dims/
 
 __
 Do you Yahoo!?
 The New Yahoo! Search - Faster. Easier. Bingo.
 http://search.yahoo.com
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


=
Davanum Srinivas - http://webservices.apache.org/~dims/

__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

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



Re: [5.0] Tester

2003-07-18 Thread Craig R. McClanahan


On Fri, 18 Jul 2003, Remy Maucherat wrote:

 Date: Fri, 18 Jul 2003 11:30:35 +0200
 From: Remy Maucherat [EMAIL PROTECTED]
 Reply-To: Tomcat Developers List [EMAIL PROTECTED]
 To: Tomcat Developers List [EMAIL PROTECTED]
 Subject: [5.0] Tester

 I have put the tester back in activity for TC 5 (and it caught the
 failure for error pages), but unfortunately there are a few limitations
 caused by the HTTP client used (for example, if the status is 500, you
 can't read the content). It would be a good idea IMO to switch to
 commons-httpclient (which I'll do, but it's not a very high priority).


Switching is fine if you want, but the existing tester does (or at least
it did) have a mode where it uses a low-level socket instead of
HttpURLConnection, and therefore doesn't give you the useless garbage on a
500.  The trick is to set the protocol property to HTTP/1.0 instead of
an empty string.

 Comments ?

 Remy


Craig

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



DO NOT REPLY [Bug 21219] - Corrupted Message Body on interrupted GET

2003-07-18 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21219.
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=21219

Corrupted Message Body on interrupted GET





--- Additional Comments From [EMAIL PROTECTED]  2003-07-18 16:31 ---
I feel this bug should be reopened -- my understanding that only a change in 
Tomcat will enable servlets to behave properly.

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



Re: [5.0] Tester

2003-07-18 Thread Remy Maucherat
Craig R. McClanahan wrote:
I have put the tester back in activity for TC 5 (and it caught the
failure for error pages), but unfortunately there are a few limitations
caused by the HTTP client used (for example, if the status is 500, you
can't read the content). It would be a good idea IMO to switch to
commons-httpclient (which I'll do, but it's not a very high priority).
Switching is fine if you want, but the existing tester does (or at least
it did) have a mode where it uses a low-level socket instead of
HttpURLConnection, and therefore doesn't give you the useless garbage on a
500.  The trick is to set the protocol property to HTTP/1.0 instead of
an empty string.
I had missed the executeSocket method. That's useful :)
Switching to HttpClient still makes sense IMO, but is not essential to 
fix some tests.

Remy



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


Re: [5.0] Optimizing the core a bit more

2003-07-18 Thread Remy Maucherat
Remy Maucherat wrote:
In an effort to tweak the core a bit more to simplify things:

- Remove ContainerBase.invoke: A Container always has a Pipeline 
associated with it; as such, the Container interface should have a 
getPipeline method, and this should be called instead. This will reduce 
a bit the call stack.

- I noticed the RequestListenerValve was added twice to the pipeline 
(using the tester). This doesn't seem right, obviously.
Actually, since it is a needed feature for spec compliance, and to 
simplify things a little, it should be in core, and I'll integrate the 
code in StandardContextValve.

Similarly, the code in the ErrorDispatcherValve should be integrated in 
StandardHostValve.

OTOH, the ErrorReportValve should stay as is as a Valve, as it is not 
required for spec compliance, and it is valid to remove or replace it.

Comments ?

Remy



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


Minor typo stopping 4.1.26 from running on NetWare.

2003-07-18 Thread Jeff Tulley
There is a minor capitalization typo that is causing 4.1.26 to not start
up properly on NetWare.  I think this typo has been there a while, but
the newer version of struts causes the typo to actually trigger an error
now.

I have attached a diff file; could somebody please make this simple
change for me?

Thanks,

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com
RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/admin/WEB-INF/struts-config.xml,v
retrieving revision 1.52
diff -u -r1.52 struts-config.xml
--- struts-config.xml   9 Apr 2003 22:36:33 -   1.52
+++ struts-config.xml   18 Jul 2003 17:40:07 -
@@ -85,7 +85,7 @@
 type=org.apache.webapp.admin.defaultcontext.DefaultContextForm/
 
 form-bean  name=defaultContextsForm
-
type=org.apache.webapp.admin.defaultContext.DefaultContextsForm/
+
type=org.apache.webapp.admin.defaultcontext.DefaultContextsForm/
 
 !-- = Connector Module = --
 


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

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

2003-07-18 Thread remm
remm2003/07/18 11:48:59

  Modified:catalina/src/share/org/apache/catalina Container.java
  Log:
  - Add a getPipeline() to allow bypassing the (useless) invoke method.
  
  Revision  ChangesPath
  1.6   +11 -4 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Container.java
  
  Index: Container.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Container.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- Container.java23 May 2003 10:54:15 -  1.5
  +++ Container.java18 Jul 2003 18:48:58 -  1.6
  @@ -237,6 +237,13 @@
   
   
   /**
  + * Return the Pipeline object that manages the Valves associated with
  + * this Container.
  + */
  +public Pipeline getPipeline();
  +
  +
  +/**
* Return the Cluster with which this Container is associated.  If there is
* no associated Cluster, return the Cluster associated with our parent
* Container (if any); otherwise return codenull/code.
  
  
  

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



DO NOT REPLY [Bug 21717] New: - Can't insert page '...': Illegal to flush within a custom tag

2003-07-18 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21717.
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=21717

Can't insert page '...': Illegal to flush within a custom tag 

   Summary: Can't insert page '...': Illegal to flush within a
custom tag
   Product: Tomcat 4
   Version: 4.1.24
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Can't insert page '...': Illegal to flush within a custom tag 
I'm getting this message in tomcat 4.1.x, also tried tomcat 5 dev.

I can't seem to find a real explaination for this behaviour in related bug 
reports (3543  3776).

in bug report 3543:
Up until 4.0-rc1, Tomcat 4 was incorrectly *not* doing the flush in it.  In 
rc1,
this was added to conform to the spec.  Because it is a spec requirement, 
there is no way to turn it off.

in the jsp 1.2 specs i found this note:
JSP 1.2 extends JavaServer Pages™ 1.1 Specification (JSP 1.1) in the following
ways:
• ...
• Fixing the infamous “flush before you include” limitation in JSP 1.1.

But i did not find the line telling an include should be illegal if it is made
by a tag handler... (could be looking over it :)

I know weblogic 6.1 doesn't complain about this... don't know about the more
recent versions.

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



cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardContextValve.java StandardEngineValve.java StandardHostValve.java

2003-07-18 Thread remm
remm2003/07/18 11:49:28

  Modified:catalina/src/share/org/apache/catalina/core
StandardContextValve.java StandardEngineValve.java
StandardHostValve.java
  Log:
  - Add a getPipeline() to allow bypassing the (useless) invoke method.
  
  Revision  ChangesPath
  1.8   +6 -6  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContextValve.java
  
  Index: StandardContextValve.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContextValve.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- StandardContextValve.java 26 May 2003 22:03:59 -  1.7
  +++ StandardContextValve.java 18 Jul 2003 18:49:28 -  1.8
  @@ -194,7 +194,7 @@
   if (((StandardContext) container).getSwallowOutput()) {
   try {
   SystemLogHandler.startCapture();
  -wrapper.invoke(request, response);
  +wrapper.getPipeline().invoke(request, response);
   } finally {
   String log = SystemLogHandler.stopCapture();
   if (log != null  log.length()  0) {
  @@ -202,7 +202,7 @@
   }
   }
   } else {
  -wrapper.invoke(request, response);
  +wrapper.getPipeline().invoke(request, response);
   }
   
   }
  
  
  
  1.5   +5 -5  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardEngineValve.java
  
  Index: StandardEngineValve.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardEngineValve.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- StandardEngineValve.java  26 May 2003 22:03:59 -  1.4
  +++ StandardEngineValve.java  18 Jul 2003 18:49:28 -  1.5
  @@ -153,7 +153,7 @@
   }
   
   // Ask this Host to process this request
  -host.invoke(request, response);
  +host.getPipeline().invoke(request, response);
   
   }
   
  
  
  
  1.6   +5 -5  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardHostValve.java
  
  Index: StandardHostValve.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardHostValve.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- StandardHostValve.java26 May 2003 22:03:59 -  1.5
  +++ StandardHostValve.java18 Jul 2003 18:49:28 -  1.6
  @@ -174,7 +174,7 @@
   }
   
   // Ask this Context to process this request
  -context.invoke(request, response);
  +context.getPipeline().invoke(request, response);
   
   }
   
  
  
  

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



Re: URI Space and smarter hand off between Apache/Tomcat

2003-07-18 Thread P. Brewer

--- Marc Slemko [EMAIL PROTECTED] wrote:
 On Thu, 17 Jul 2003, P. Brewer wrote:
 
  I found the following thread from a year ago:
 
  http://marc.theaimsgroup.com/?l=tomcat-devm=102815260317741w=2\
 
. . . deleted . . .
  Was it shot down for a technical reason?  Just didn't get
 implmented?
  Or is implemented and not documented?  I can help with C code,
 but
  probably not much help with Java code.
 
 You would probably be better off to just make mod_jk* properly
 support
 Apache (and other webserver) configuration directives such as
 Directory
 and Files, then use them to control what gets passed on to tomcat.
 
 Having mod_jk trying to do parsing based on filenames on disk is a
 very bad idea for performance and security reasons, especially on
 win32 platforms.
 
I'm not sure where you are coming from, I am not suggesting pasing
based on filenames on disk.  I am speaking of resource names in the
request URL.  Granted in most cases there is a matching file name on
disk, but that is irrelivant for this process. 

The matching occurs on the URI and the decision to pass to Tomcat is
made with out ever looking at the disk. 

for example: 

JkMount /weatherPage/* 
JkNotMount /weatherPage/images/* 
JkNotMount /weatherPage/*.html 

would yeild the following results 
Request   Handled By Server 
---
http://my.server/weatherPage/index.html apache 
http://my.server/weatherPage/textForcast

__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

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



Re: URI Space and smarter hand off between Apache/Tomcat

2003-07-18 Thread P. Brewer

--- Marc Slemko [EMAIL PROTECTED] wrote:
 On Thu, 17 Jul 2003, P. Brewer wrote:
 
  I found the following thread from a year ago:
 
  http://marc.theaimsgroup.com/?l=tomcat-devm=102815260317741w=2\
 
. . . deleted . . .
  Was it shot down for a technical reason?  Just didn't get
 implmented?
  Or is implemented and not documented?  I can help with C code,
 but
  probably not much help with Java code.
 
 You would probably be better off to just make mod_jk* properly
 support
 Apache (and other webserver) configuration directives such as
 Directory
 and Files, then use them to control what gets passed on to tomcat.
 
 Having mod_jk trying to do parsing based on filenames on disk is a
 very bad idea for performance and security reasons, especially on
 win32 platforms.
 
I'm not sure where you are coming from, I am not suggesting pasing
based on filenames on disk.  I am speaking of resource names in the
request URL.  Granted in most cases there is a matching file name on
disk, but that is irrelivant for this process. 

The matching occurs on the URI and the decision to pass to Tomcat is
made with out ever looking at the disk. 

for example: 

JkMount /weatherPage/* 
JkNotMount /weatherPage/images/* 
JkNotMount /weatherPage/*.html 

would yeild the following results 
Request   Handled By Server 
---
http://my.server/weatherPage/index.html apache 
http://my.server/weatherPage/textForcasttomcat 
http://my.server/weatherPage/images/sun.gif apache 
http://my.server/weatherPage/currentTemp.jpgtomcat 
http://my.server/weatherPage/images/cloud.jpg   apache 
http://my.server/weatherPage/city/newyork.html  apache 
http://my.server/weatherPage/city/current?city=newyork  tomcat 

ps. Sorry for incomplete submission. 

__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

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



DO NOT REPLY [Bug 3884] - SingleThreadModel servlets not pooled results in low performance

2003-07-18 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3884.
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=3884

SingleThreadModel servlets not pooled results in low performance

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |



--- Additional Comments From [EMAIL PROTECTED]  2003-07-18 22:12 ---
With 4.1.24, I make a simple isThreadSafe=false jsp with only:
try {
System.out.println(Before sleep, instance is +this+ time 
is +System.currentTimeMillis());
Thread.sleep(60*1000);
System.out.println(After sleep, instance is +this+ time 
is +System.currentTimeMillis());
} catch(InterruptedException ex) {}


and at the moment, it serializes, as hitting it w/ 2 browsers leads to:

Before sleep, instance is [EMAIL PROTECTED] time is 1058566078026
After sleep, instance is [EMAIL PROTECTED] time is 1058566138034
Before sleep, instance is [EMAIL PROTECTED] time is 1058566138034
After sleep, instance is [EMAIL PROTECTED] time is 1058566198042

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



DO NOT REPLY [Bug 3884] - SingleThreadModel servlets not pooled results in low performance

2003-07-18 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3884.
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=3884

SingleThreadModel servlets not pooled results in low performance

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-07-18 22:19 ---
What you're using is a STM JSP, which is not the same as a servlet since its
invoked through a non STM wrapper servlet: the JasperServlet. Pooling cannot be
implemented in that case (unless adding a pool in the JasperServlet itself, but
it would be yet another horrible hack inside Jasper, so I'm -1 for it).

If you want to get the same behavior as with a regular STM servlet, you have to
precompile your JSP (and map it in web.xml), in which case Catalina will
identify your servlet as STM and pool it.

I'm reverting to the old resolution.

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



[5.0] Servlet logging and error messages

2003-07-18 Thread Remy Maucherat
I'm working on the following changes:

- Stripping out all the Catalina related part of the stack trace in the 
HTML generated by the ErrorReportValve; that eases debugging.

- When an exception occurs, and it is a ServletException, I think the 
root cause should be logged, not the external exception, which 99% of 
the time is useless.

- I strongly believe that all webapp triggered logging (init errors, 
service errors, etc) should go to the servlet container provided logger 
(ie Context.getLogger()). Right now, a significant amount is sent to 
commons-logging. I was aware that the intent was to switch the container 
itself to commons-logging (and I am +1 for it), but c-l or another 
generic logging framework such as log4j, is IMO not adapted to provide 
the webapp logging (same for the access log, obvioously).

Comments ?

Remy



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


cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/compat Jdk14Compat.java JdkCompat.java

2003-07-18 Thread remm
remm2003/07/18 15:24:38

  Modified:util/java/org/apache/tomcat/util/compat Jdk14Compat.java
JdkCompat.java
  Log:
  - Add compat code to print out partial stack traces.
  
  Revision  ChangesPath
  1.4   +27 -4 
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/compat/Jdk14Compat.java
  
  Index: Jdk14Compat.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/compat/Jdk14Compat.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- Jdk14Compat.java  26 Mar 2003 11:01:39 -  1.3
  +++ Jdk14Compat.java  18 Jul 2003 22:24:37 -  1.4
  @@ -75,7 +75,8 @@
   /**
*  See JdkCompat. This is an extension of that class for Jdk1.4 support.
*
  - *  @author Tim Funk
  + * @author Tim Funk
  + * @author Remy Maucherat
*/
   public class Jdk14Compat extends JdkCompat {
   // -- Constants
  @@ -119,6 +120,28 @@
*/
   public long getMaxMemory() {
   return Runtime.getRuntime().maxMemory();
  +}
  +
  +
  +/**
  + * Print out a partial servlet stack trace (truncating at the last 
  + * occurrence of javax.servlet.).
  + */
  +public String getPartialServletStackTrace(Throwable t) {
  +StringBuffer trace = new StringBuffer();
  +trace.append(t.toString()).append('\n');
  +StackTraceElement[] elements = t.getStackTrace();
  +int pos = elements.length;
  +for (int i = (elements.length - 1); i = 0; i--) {
  +if (elements[i].getClassName().startsWith(javax.servlet.)) {
  +pos = i + 1;
  +break;
  +}
  +}
  +for (int i = 0; i  pos; i++) {
  +trace.append('\t').append(elements[i].toString()).append('\n');
  +}
  +return trace.toString();
   }
   
   
  
  
  
  1.5   +16 -3 
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/compat/JdkCompat.java
  
  Index: JdkCompat.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/compat/JdkCompat.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- JdkCompat.java26 Mar 2003 11:01:39 -  1.4
  +++ JdkCompat.java18 Jul 2003 22:24:37 -  1.5
  @@ -66,6 +66,8 @@
   import java.io.IOException;
   import java.net.URL;
   import java.net.MalformedURLException;
  +import java.io.PrintWriter;
  +import java.io.StringWriter;
   
   import org.apache.commons.logging.Log;
   import org.apache.commons.logging.LogFactory;
  @@ -198,6 +200,17 @@
*/
   public long getMaxMemory() {
   return (-1L);
  +}
  +
  +
  +/**
  + * Print out a partial servlet stack trace (truncating at the last 
  + * occurrence of javax.servlet.).
  + */
  +public String getPartialServletStackTrace(Throwable t) {
  +StringWriter stackTrace = new StringWriter();
  +t.printStackTrace(new PrintWriter(stackTrace));
  +return stackTrace.toString();
   }
   
   
  
  
  

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



cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves ErrorReportValve.java

2003-07-18 Thread remm
remm2003/07/18 15:25:53

  Modified:catalina/src/share/org/apache/catalina/valves
ErrorReportValve.java
  Log:
  - Print out partial stack traces (on JDK 1.4; older JDKs would need substring
based hacks, and I'm not sure it's a very good idea ...).
  
  Revision  ChangesPath
  1.5   +13 -10
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java
  
  Index: ErrorReportValve.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- ErrorReportValve.java 21 Jun 2003 17:37:17 -  1.4
  +++ ErrorReportValve.java 18 Jul 2003 22:25:52 -  1.5
  @@ -79,6 +79,9 @@
   import javax.servlet.http.Cookie;
   import javax.servlet.http.HttpServletRequest;
   import javax.servlet.http.HttpServletResponse;
  +
  +import org.apache.tomcat.util.compat.JdkCompat;
  +
   import org.apache.catalina.Container;
   import org.apache.catalina.Globals;
   import org.apache.catalina.HttpRequest;
  @@ -319,20 +322,20 @@
   sb.append(/u/p);
   
   if (throwable != null) {
  -StringWriter stackTrace = new StringWriter();
  -throwable.printStackTrace(new PrintWriter(stackTrace));
  +String stackTrace = JdkCompat.getJdkCompat()
  +.getPartialServletStackTrace(throwable);
   sb.append(pb);
   sb.append(sm.getString(errorReportValve.exception));
   sb.append(/b pre);
  -sb.append(stackTrace.toString());
  +sb.append(stackTrace);
   sb.append(/pre/p);
   while (rootCause != null) {
  -stackTrace = new StringWriter();
  -rootCause.printStackTrace(new PrintWriter(stackTrace));
  +stackTrace = JdkCompat.getJdkCompat()
  +.getPartialServletStackTrace(rootCause);
   sb.append(pb);
   sb.append(sm.getString(errorReportValve.rootCause));
   sb.append(/b pre);
  -sb.append(stackTrace.toString());
  +sb.append(stackTrace);
   sb.append(/pre/p);
   
   /* In case root cause is somehow heavily nested */
  
  
  

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



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

2003-07-18 Thread remm
remm2003/07/18 15:26:15

  Modified:catalina/src/share/org/apache/catalina/core
StandardWrapperValve.java
  Log:
  - Log root cause of an exception.
  
  Revision  ChangesPath
  1.16  +11 -2 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapperValve.java
  
  Index: StandardWrapperValve.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapperValve.java,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- StandardWrapperValve.java 26 May 2003 22:03:59 -  1.15
  +++ StandardWrapperValve.java 18 Jul 2003 22:26:15 -  1.16
  @@ -284,8 +284,17 @@
   // do not want to do exception(request, response, e) processing
   } catch (ServletException e) {
   hreq.removeAttribute(Globals.JSP_FILE_ATTR);
  +Throwable rootCause = e;
  +while (rootCause instanceof ServletException) {
  +Throwable t = ((ServletException) rootCause).getRootCause();
  +if (t != null) {
  +rootCause = t;
  +} else {
  +break;
  +}
  +}
   log.error(sm.getString(standardWrapper.serviceException,
  - wrapper.getName()), e);
  +   wrapper.getName()), rootCause);
   throwable = e;
   exception(request, response, e);
   } catch (Throwable e) {
  
  
  

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



cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves LocalStrings_fr.properties

2003-07-18 Thread remm
remm2003/07/18 15:31:55

  Modified:catalina/src/share/org/apache/catalina/valves
LocalStrings_fr.properties
  Log:
  - Fix typos on the 500 error message.
  
  Revision  ChangesPath
  1.2   +1 -1  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/LocalStrings_fr.properties
  
  Index: LocalStrings_fr.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/LocalStrings_fr.properties,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- LocalStrings_fr.properties5 Nov 2002 09:35:31 -   1.1
  +++ LocalStrings_fr.properties18 Jul 2003 22:31:55 -  1.2
  @@ -56,7 +56,7 @@
   http.417=L''attente indiqué dans la directive Expect de l''entête de requête 
({0}) ne peut être satisfaite.
   http.422=Le serveur a compris le type de contenu (content type) ainsi que la 
synthaxe de la requête mais a été incapable de traiter les instructions contenues 
({0}).
   http.423=La ressource source ou destination de la méthode est vérrouillée ({0}).
  -http.500=Le serveur a recontrer une erreur interne ({0}) qui l''a empèché de 
satisfaire la requête.
  +http.500=Le serveur a rencontré une erreur interne ({0}) qui l''a empêché de 
satisfaire la requête.
   http.501=Le serveur ne supporte pas la fonctionnalité demandée pour satisfaire 
cette requête ({0}).
   http.502=Le serveur a reçu une réponse invalide d'un serveur qu''il consultait en 
tant que relais ou passerelle ({0}).
   http.503=Le service demandé ({0}) n''est pas disponible actuellement.
  
  
  

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



cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util StringManager.java

2003-07-18 Thread remm
remm2003/07/18 15:54:20

  Modified:catalina/src/share/org/apache/catalina/util
StringManager.java
  Log:
  - Fix a problem where the Strings weren't escaped in the same way for chars
such as '. This caused problems for localization in French.
  
  Revision  ChangesPath
  1.4   +9 -5  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/StringManager.java
  
  Index: StringManager.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/StringManager.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- StringManager.java9 Apr 2003 04:29:56 -   1.3
  +++ StringManager.java18 Jul 2003 22:54:19 -  1.4
  @@ -142,8 +142,12 @@
*
* @param key
*/
  -
   public String getString(String key) {
  +return MessageFormat.format(getStringInternal(key), null);
  +}
  +
  +
  +protected String getStringInternal(String key) {
   if (key == null) {
   String msg = key is null;
   
  @@ -173,7 +177,7 @@
   
   public String getString(String key, Object[] args) {
   String iString = null;
  -String value = getString(key);
  +String value = getStringInternal(key);
   
   // this check for the runtime exception is some pre 1.1.6
   // VM's don't do an automatic toString() on the passed in
  
  
  

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



DO NOT REPLY [Bug 21709] - %= % does not convert to string before passing arguments to custom tag handlers

2003-07-18 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21709.
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=21709

%= % does not convert to string before passing arguments to custom tag handlers

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-07-18 23:47 ---
Sorry, looked at the spec and I think this bug is bogus.  Tomcat behaves as it 
should.

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



Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/compatJdk14Compat.java JdkCompat.java

2003-07-18 Thread Tim Funk
I have no issue with substring use for jdk1.3 getPartialServletStackTrace() 
since it should not get called often so the performance shouldn't be an issue 
(or am I missing something more subtle).

Possible alternative (for the 1.3 version).
public String getPartialServletStackTrace(Throwable t) {
StringWriter stackTrace = new StringWriter();
t.printStackTrace(new PrintWriter(stackTrace));
String st = stackTrace.toString();
int i = st.lastIndexOf(javax.servlet.);
if (i-1)
return st.substring(0, i);
else
return st;
}
-Tim

[EMAIL PROTECTED] wrote:
remm2003/07/18 15:24:38

  Modified:util/java/org/apache/tomcat/util/compat Jdk14Compat.java
JdkCompat.java
  Log:
  - Add compat code to print out partial stack traces.


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


Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/compatJdk14Compat.java JdkCompat.java

2003-07-18 Thread Remy Maucherat
Tim Funk wrote:
I have no issue with substring use for jdk1.3 
getPartialServletStackTrace() since it should not get called often so 
the performance shouldn't be an issue (or am I missing something more 
subtle).
Yes, zero performance impact.

Possible alternative (for the 1.3 version).
public String getPartialServletStackTrace(Throwable t) {
StringWriter stackTrace = new StringWriter();
t.printStackTrace(new PrintWriter(stackTrace));
String st = stackTrace.toString();
int i = st.lastIndexOf(javax.servlet.);
if (i-1)
return st.substring(0, i);
else
return st;
}
Sounds like a good start. There should be a 	at  prefix in front of 
each line (which is something I don't like with traces, since the at 
can never be i18n ready). I'll try to hack that a little bit tomorrow, 
unless it gets automagically done while I sleep :)

Remy



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


DO NOT REPLY [Bug 15002] - Tag files in different directories not belonging to different tag libraries

2003-07-18 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15002.
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=15002

Tag files in different directories not belonging to different tag libraries

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-07-19 00:53 ---
I'm unable to reproduce this, so I assume it has been fixed, and just not 
updated in Bugzilla.  Anyone who can reproduce it, please reopen.

Running a fresh checkout of Tomcat 5 on Windows XP, I was able to run all the 
tagfile examples in the jsp-examples webapp.

I also tested the original problem case of /WEB-INF/tags/foo/test.tag and /WEB-
INF/tags/bar/test.tag.  There was no sign of a conflict, and the tags compiled 
to scratch_dir/appname/org/apache/jsp/tag/web/foo/test.java and 
scratch_dir/appname/org/apache/jsp/tag/web/bar/test.java, respectively, as 
Jan's note said they would.

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