Re: [Vote] (was Re: Top Level Project? Time for Top Level Lists?)

2005-09-13 Thread Keith Wannamaker

Per all the reasons Mark mentioned:

Keith


Bugs
 [X]  forward to [EMAIL PROTECTED]
 [ ]  forward to [EMAIL PROTECTED]

Commits
  [X]  forward to [EMAIL PROTECTED]
  [ ]  forward to [EMAIL PROTECTED]


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



svn and sites

2005-07-21 Thread Keith Wannamaker

Remy, you're right, this isn't good--

$ time svn praise CHANGES | wc
svn: Caught signal
real25m56.794s

Side question-- is the website move just waiting to be done by somebody? 
 I don't mind moving things over and putting a redirect at the old one, 
if it is time for that.


Also, I tried to subscribe to [EMAIL PROTECTED] but no joy, I assume 
the lists are not up yet?


Thanks,
Keith


Remy Maucherat wrote:
introduced (I then do diffs between revisions). It seems with SVN I have 
to retrieve the full revision list for the repository (which will take 
hours). If someone can offer a workaround for this problem, then I'll 
support a move to SVN :)


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



arbitrary jk_common http methods

2005-04-27 Thread Keith Wannamaker
Mladen, one of the features of the the former connector was being able 
to handle arbitrary http methods.  At the time, a new one was being 
added to delta-v or acl every time we turned around.  Having a fallback 
path of pushing through unknown methods eliminated the need to rebuild 
jk for each new method.  I could be wrong but in reading jk_ajp_common 
it seems that the code now requires the method to be known.  You might 
want to think about re-adding this functionality if this is true, as it 
will no doubt save headaches down the road.

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


Re: arbitrary jk_common http methods

2005-04-27 Thread Keith Wannamaker
Hi Mladen, this functionality was in jk2
(jk_requtil.c:jk2_requtil_getMethodId) but probably not in the original
mod_jk.  A special method code means to look for the method name later 
in the message.  I respect the work you have done trying to merge so 
many copies of jk back down into one  :-)

Thanks,
Keith
Mladen Turk wrote:
Keith Wannamaker wrote:
Mladen, one of the features of the the former connector was being able 
to handle arbitrary http methods.

I'm not aware such a feature ever existed.
Only the ajp13 http methods can be handled by the ajp protocol,
and that was always. Two methods (SELECT, and ACL) were missing
because I forgot to add them when rewriting method handler.
Regards,
Mladen.
-
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: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

2005-04-21 Thread Keith Wannamaker
No one has commented so I withdraw my (valid) veto and I'll roll back
5.0 per Remy's wish.  I'm disappointed because I remember when Tomcat 
was an open-source project.

Keith
My veto of this change still stands, and it would be your responsibility 
of finding a fix more compatible with IE.  If no one else besides me 
thinks IE compatibility is important, head of tree is fine and I will 
withdraw my veto.

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


Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

2005-04-19 Thread Keith Wannamaker
Remy, I have to -1 your change in AuthenticatorBase 1.13.  You broke a 
larger case than you fixed -- Mozilla may work now but IE doesn't.  See 
bugs 34083, 27122, 28662, 29336, 29975, and 30618 for the IE problem. 
Mozilla should be fixed in a way compatible with IE.

By uncommenting !isSecure, my change in 1.26 and on can all be backed out.
If no one else is concerned that Tomcat 5.5 doesn't work by default with 
IE under SSL, then I'll withdraw my veto and rename the attribute I 
added to 'securePagesWithPragma' and make the pragma conditional, with a 
default of being included.

Keith
Remy Maucherat wrote:
I see more and more people trying to shove 
down people's throat whatever defaults they like best. 
:-) me too
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

2005-04-19 Thread Keith Wannamaker
Remy Maucherat wrote:
Thanks. If you can find precisely what the issue with Mozilla was, and 
certify the behavior is now correct in Firefox (= no stupid caching with 
SSL), then you can indeed uncomment the isSecure here:

// FIXME: Disabled for Mozilla FORM support over SSL
// (improper caching issue)
//!request.isSecure() 
My veto of this change still stands, and it would be your responsibility 
of finding a fix more compatible with IE.  If no one else besides me 
thinks IE compatibility is important, head of tree is fine and I will 
withdraw my veto.

Keith

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


Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

2005-04-19 Thread Keith Wannamaker
If no one else weighs in on the root issue in a day or so, and you 
disagree with this change, I'll be happy to roll it back and/or backport 
5.5 head of tree in its place.

Keith
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
keith   2005/04/18 13:20:46
  Modified:catalina/src/share/org/apache/catalina/authenticator Tag:
TOMCAT_5_0 AuthenticatorBase.java
  Log:
  [34083 et al] For webapps with security constraints, we default to 
sending
  headers to disable caching.  This is well-intentioned but IE will 
not open
  office documents under SSL with the Pragma header.  Remove the Pragma
  header and change the Cache-Control to private based on comments in
  the many bugs about this and my reading of the 1.1 spec.

Since we're on the subject, the 5.0.x branch is supposed to be stable. 
Changes which might break things are not a good idea.

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


Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

2005-04-18 Thread Keith Wannamaker
I'd like to omit pragma header by default.  What specific client 
requires it?  The community has identified a specific, widespread 
failure with the former code-- it did not work out of the box with IE 
under SSL.So, if we want to keep the pragma header the default, what 
are the reasons?

Keith
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
keith   2005/04/18 13:21:57
  Modified:catalina/src/share/org/apache/catalina/authenticator
AuthenticatorBase.java
  Log:
  [34083 et al] For webapps with security constraints, we default to 
sending
  headers to disable caching.  This is well-intentioned but IE will 
not open
  office documents under SSL with the Pragma header.  Remove the Pragma
  header and change the Cache-Control to private based on comments in
  the many bugs about this and my reading of the 1.1 spec.
Per Remy make this behavior optional, with a new valve attribute

When I say make it optional, I mean: the current behavior should 
remain the default (as it has been since day one, and I am not the one 
who actually did it), but I am ok with having the new proposed behavior 
as an option (and documenting it).

Maybe a better attribute name can be found, BTW. 
IECompatibleProxyCacheDisableHeaders is probably better than 
StupidSettingWhichWillIntroduceBrokenBehaviorIfYouSetItToFalse, but not 
by much.

Rémy
-
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: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

2005-04-18 Thread Keith Wannamaker
Pragma has never been sent out on a secure connection until recently 
(rev 1.13)  This is brand new behavior and it causes problems with IE 
under SSL.  At the time you even said you'd be willing to roll it back. 
 I'd be happy to leave cache-control to no-cache, it is the Pragma that 
is killing us.  Are you aware of a client that depends solely on Pragma 
for cache instruction?  I would argue that being unable to serve pages 
to IE under SSL is more significant than a caching problem in a client 
that doesn't understand cache-control.

Keith
Remy Maucherat wrote:
Keith Wannamaker wrote:
I'd like to omit pragma header by default.  What specific client 
requires it?  The community has identified a specific, widespread 
failure with the former code-- it did not work out of the box with IE 
under SSL.So, if we want to keep the pragma header the default, 
what are the reasons?

I am not willing to discuss this issue. This has been like this forever, 
the behavior was not introduced by myself, and existing flags do exist. 
Your new flag restricts security, and could cause inappropriate caching 
of pages on the client, which could cause user errors on important 
sections of the website.

Rémy
-
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: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

2005-04-18 Thread Keith Wannamaker
I read:
// FIXME: Disabled for Mozilla FORM support over SSL
// (improper caching issue)
Indeed (I now remember the issue), there would be serious issues should 
this not be the default.
The issue here is, apparently, that Mozilla has a caching bug we are 
working around, so we have to disable caching.  However, I don't know 
that the broken Mozilla agent requires the Pragma header to do this.

Now, I think you are misrepresenting the IE issue, and it's not such a 
big issue. 
Here is a test war for you and those interested,
http://apache.org/~keith/ietest.war.  If you deploy this you will see 
that you cannot download the one file in the webapp with IE with head of 
tree.  If you comment out the pragma header in AuthenticatorBase, it 
works fine.

Despite your renaming, I want to emphasize that I am not talking about 
the cache-control header, and am fine with it being either private or 
no-cache.

I am perfectly fine with adding new configurability and 
documenting it properly, but defaults should lean towards the safer 
solution.
I disagree, defaults should be friendly to the largest client base.
BTW, I really don't see any problem with not using the defaults, and 
actually configuring something. Is that really a big issue for you and 
the people who reported this problem ? For example, in JBoss, I use a 
different default configuration and I don't make a big issue out of it.
I think Tomcat should work with IE under SSL, and yes, I think it is a 
big issue that Tomcat doesn't, out of the box.

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


Re: [34083,etc..] method of disabling cache

2005-04-15 Thread Keith Wannamaker
I haven't heard anything from this, so I plan on replacing the three 
headers this code sets with a single cache-control: private header this 
weekend in tc 5.0 and 5.5.

Keith
Keith Wannamaker wrote:
Remy, what are your reasons for not using cache-control: private?
We discovered some time ago that the Pragma: no-cache causes IE trouble 
when under ssl.  Why wouldn't cache-control: private be sufficient?  If 
we're enabling this behavior by default, it would make sense to use the 
most interoperable cache-disabling solution.

Thanks,
Keith
cf http://issues.apache.org/bugzilla/show_bug.cgi?id=34083
-
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: [34083,etc..] method of disabling cache

2005-04-15 Thread Keith Wannamaker
Does cache-control: private not achieve the correct behavior for you?
Keith
Remy Maucherat wrote:
Keith Wannamaker wrote:
I haven't heard anything from this, so I plan on replacing the three 
headers this code sets with a single cache-control: private header 
this weekend in tc 5.0 and 5.5.

Make it optional.
Rémy
-
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]


[34083,etc..] method of disabling cache

2005-04-14 Thread Keith Wannamaker
Remy, what are your reasons for not using cache-control: private?
We discovered some time ago that the Pragma: no-cache causes IE trouble 
when under ssl.  Why wouldn't cache-control: private be sufficient?  If 
we're enabling this behavior by default, it would make sense to use the 
most interoperable cache-disabling solution.

Thanks,
Keith
cf http://issues.apache.org/bugzilla/show_bug.cgi?id=34083
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Query on Tomcat 4.1.31 , 4.1.29

2005-04-01 Thread Keith Wannamaker
Here is the link to 4.1.31 and its release notes
http://archive.apache.org/dist/jakarta/tomcat-4/v4.1.31/
Thanks,
Keith
sun fire wrote:
Hi,
 Where can I find the enhancements of Tomcat version 4.1.31 over 4.1.29 ? All releases available belong to the 5.x versions and 4.* versions don't seem to be available on the web site for me to see the change logs. Are there, Appreciate your help. Are some of the bug-fixes from 4.1.29 - 4.1.31 related to security issues ? 
 
Thanks ,
  Sunil

		
-
Do you Yahoo!?
 Better first dates. More second dates. Yahoo! Personals 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: TLP Draft Proposal

2005-03-22 Thread Keith Wannamaker
I'd be honored to be part of this transition if others deem it appropriate.
Thanks,
Keith
Yoav Shapira wrote:
NOTE: Who am I missing?  Kin-man?  Craig?  Keith?  Others?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: SVN migration?

2005-02-04 Thread Keith Wannamaker
The last time I looked at the Eclipse SVN plugin it just called out to 
the native svn binary to do the real work-- I wonder how well anything 
but basic operations can be integrated until it is using a java svn 
client.  Then again, maybe that has been written since I looked at it 
last.  I'd be -0 for the move until Eclipse has some robust support for svn.

Keith
Henri Yandell wrote:
Just noticed an email on commons-dev.
Subclipse doesn't support the synchonize feature yet. 

Hen
On Fri, 4 Feb 2005 02:57:35 -0500, Henri Yandell [EMAIL PROTECTED] wrote:
Tool-wise, Subclipse is an Eclipse plugin that seems to work fine for
standard development (checkout, update, diff, commit). I'm unsure
whether you can create tags/branches using it as I always do that on
the command line, be it cvs or svn. IntelliJ has a plugin and the next
version will have it built in. TortoiseSvn is spoken well of, and I
can vouch for svn on linux/OS X, I've had no problems in the last year
of use.

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


launching tomcat from java

2004-11-03 Thread Keith Wannamaker
What needs to be done to launch tomcat via reflection?
jdk1.4 gives me java.lang.NoClassDefFoundError: 
javax/management/MBeanRegistration.

Why does jmx have to be in the bootstrap loader?
System.setProperty(catalina.home, l_catalinaHome.getAbsolutePath());
URL urls[] = new URL[] {
  new File(base, STANDALONE_BIN + jmx.jar).toURL(),
  new File(base, STANDALONE_BIN + bootstrap.jar).toURL(),
  new File(base, STANDALONE_BIN + commons-logging-api.jar).toURL()
  };
URLClassLoader ucl = new URLClassLoader(urls, null);
  Class c = ucl.loadClass(className);
  Method main = c.getDeclaredMethod(main, new Class[] 
{String[].class}
 );
  Object argslist[] = new Object[1];
  argslist[0] = new String[] { stop };
  Object ret = main.invoke(null, argslist);

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


[5.0] preRegister npe

2004-10-26 Thread Keith Wannamaker
StandardContext.start throws a (caught) npe for every web application 
unless preRegister has been called on the context (line 4151).  This is 
pretty annoying in Eclipse because it automatically stops on all npes.

For me, preRegister is always called AFTER start, so this stanza always 
npes.  Anyone help on what needs to be done to reverse the order of 
these calls?  If not any opposition to something like--

Index: StandardContext.java
===
RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.130.2.1
diff -u -r1.130.2.1 StandardContext.java
--- StandardContext.java	28 Aug 2004 12:49:54 -	1.130.2.1
+++ StandardContext.java	26 Oct 2004 21:21:44 -
@@ -4143,7 +4143,7 @@

 // Look for a realm - that may have been configured earlier.
 // If the realm is added after context - it'll set itself.
-if( realm == null ) {
+if( realm == null  mserver != null ) {
 ObjectName realmName=null;
 try {
 realmName=new ObjectName( getEngineName() + 
:type=Host,host= +

I have to think I'm doing something wrong but I'm not sure what.
This patch sure does seem to help things.
Thanks for any input,
Keith
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Tomcat 5.0 under load

2004-10-15 Thread Keith Wannamaker
Last month I took Yoav's advice and attempted to upgrade our production 
server from 4.1 to 5.0.  The production server handles 5 - 10 requests a 
second across 300 threads.  The problem I had then, and the problem I 
have now is that the server's accept thread will die within a short time 
after server start.  I hate to think I am the only person running tomcat 
5 under a heavy load, but it sure looks that way.

I initially blamed threadpool's bulletproofing, but because 4.1.31 and 
5.0.28 share the same threadpool, and 4.1.31 runs indefinitely, there is 
a problem in core 5.0 that this load is exercising.

I very much want to be able to recommend that tomcat 5.0 is 
production-ready but since we can't run it, I certainly am not in a 
position to do that.  I have reserved the next day or two for 
bulletproofing tomcat 5.0, so the point of this is to solicit any 
comments from those who may have been faced with the same problem and 
have looked at the problem themselves.

Thanks for any input,
Keith
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Tomcat 5.0 under load

2004-10-15 Thread Keith Wannamaker
The time window is within about 15 minutes.  We run tomcat standalone, 
with the standard http/11 connector.  The server.xml is minimal.  I 
agree with the reproduceable angle, that is always a good place to start.

Keith
Shapira, Yoav wrote:
Hi,
There are certainly other sites running Tomcat 5.0 under heavy load,
such as the ones listed on our wiki.  I personally have put Tomcat
5.0-based apps in production that have handled the load you describe
(and much higher peak bursty loads) for months at a time without need to
restart.  

However, it could very well be your specific app or configuration is
exercising parts of Tomcat in ways other apps aren't.  Every app load
profile is unique.  So this should definitely result in an improvement
to Tomcat, or maybe the connectors if you're running Tomcat behind a
front-end web server.
I have no specific advice beyond the usual, which is to start with
something reproducible.  Can you get the accept thread to die every time
within a given time window after the server start?  Does it happen with
Tomcat standalone as well as behind a front-end server, or just the
latter?  Does it happen with the out-of-the-box server.xml or a heavily
modified one?
Yoav Shapira http://www.yoavshapira.com
 

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


Re: Tomcat 5.0 under load

2004-10-15 Thread Keith Wannamaker
Hey Remy,
Some facts:
- the higher level code cannot cause the accept thread to die
Thread dump from T0 shows the two expected accepts, from main and from 
the HttpConnector; thread dump at T(5mins) shows the main accept, many 
idle Http handler threads waiting for work, and a few long-running 
uploads  downloads, but no Http accept.  So, indeed, the thread is 
either stopping itself with no message or being killed with no message.

Interesting note on logging.  I tried today to use both jdk14 logger and 
simple log to show the progress of the accept.  The behavior of going 
through either logger is that init messages come through but runIt 
messages don't.  I thought it was the logger config so I reverted to 
System.out and still got that behavior.  I wonder if the underlying 
exception causing the problem is being squelched by whatever is 
squelching my messages.  Ever seen this?

If Keith is feeling like experimenting a little (without too much risk 
involved, though): try 5.5.3 with strategy=ms on the Connector. This 
will use the old TC 4.0 thread pool strategy, which is far less fancy, 
and was never reported as having trouble on stuff like RH 9.
I may try this.
Thanks,
Keith
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Tomcat 5.0 under load

2004-10-15 Thread Keith Wannamaker
Hey Remy, by RH 9 bug do you mean the problem with jdk14 and nptl on 
RH9?  (os is RH9)  I am running without nptl.

I did some more tracing and what I am seeing is that notify is called, 
the thread is waiting, but it never wakes up.

Keith
Remy Maucherat wrote:
Keith Wannamaker wrote:
Hey Remy,
Some facts:
- the higher level code cannot cause the accept thread to die

Thread dump from T0 shows the two expected accepts, from main and from 
the HttpConnector; thread dump at T(5mins) shows the main accept, many 
idle Http handler threads waiting for work, and a few long-running 
uploads  downloads, but no Http accept.  So, indeed, the thread is 
either stopping itself with no message or being killed with no message.

This is the same as the RH 9 bug. Which OS are you using ?
Interesting note on logging.  I tried today to use both jdk14 logger 
and simple log to show the progress of the accept.  The behavior of 
going through either logger is that init messages come through but 
runIt messages don't.  I thought it was the logger config so I 
reverted to System.out and still got that behavior.  I wonder if the 
underlying exception causing the problem is being squelched by 
whatever is squelching my messages.  Ever seen this?

Well, no. I have to admit I didn't look in detail at what everything 
does, since I didn't write that algorithm, and never quite understood 
why it works.


If Keith is feeling like experimenting a little (without too much 
risk involved, though): try 5.5.3 with strategy=ms on the 
Connector. This will use the old TC 4.0 thread pool strategy, which 
is far less fancy, and was never reported as having trouble on stuff 
like RH 9.

I may try this.

That algorithm is really stupid. OTOH, it does seem to have more syncing 
(not that I can see any performance impact from it).

R?my
-
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]


[ANNOUNCEMENT] Jakarta Tomcat 4.1.31 Stable Released

2004-10-12 Thread Keith Wannamaker
The Jakarta Tomcat team is pleased to announce availability of
Jakarta Tomcat 4.1.31, available for download:
http://jakarta.apache.org/site/binindex.cgi
This is a maintenance release which incorporates a number of bug
fixes which were backported from Tomcat 5.  More information is 
available in the release notes,

http://www.apache.org/dist/jakarta/tomcat-4/v4.1.31/RELEASE-NOTES

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


TCKs for 4.1.31

2004-10-06 Thread Keith Wannamaker
Hey Amy, would you mind running the TCKs against the 4.1.31 rc?
http://apache.org/~keith/rc2/
How does one go about obtaining these tests?
Thanks,
Keith
Amy Roh wrote:
Thanks Jan for the update.
I have confirmed that all JSP TCK tests pass with the latest 
StandardWrapper.java.  I have retagged the file so the 5.5.3 release has 
the fix.

Thanks,
Amy

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


[VOTE] Tomcat 4.1.31

2004-09-25 Thread Keith Wannamaker
I have uploaded a Tomcat 4.1.31 release canidate #2 to
http://apache.org/~keith/rc2/
The change from RC1 is to correct the servlet-api doc's path.
Continuing the 4.1.x release pattern-- after a week's worth of voting,
if the outcome is stable, I will mirror and announce this RC as Tomcat
4.1.31.
Please vote on the stability of this release:
Ballot
[ ] Alpha
[ ] Beta
[ ] Stable
/Ballot
Thanks,
Keith
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [VOTE] 4.1.31 stability

2004-09-20 Thread Keith Wannamaker
Hi Kurt, good catch.  I'll fix it and build RC2.
Keith
Kurt Miller wrote:
From: Keith Wannamaker [EMAIL PROTECTED]
I have uploaded a Tomcat 4.1.31 release canidate to 
http://apache.org/~keith/rc1/


In the binary releases, the servletapi documentation was installed
into /webapps/tomcat-docs/servletapi/api/ instead of
/webapps/tomcat-docs/servletapi/. This breaks the 'Servlet/JSP
Javadocs' link in tomcat-docs.
-Kurt

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


[VOTE] 4.1.31 stability

2004-09-19 Thread Keith Wannamaker
I have uploaded a Tomcat 4.1.31 release canidate to 
http://apache.org/~keith/rc1/

Continuing the 4.1.x release pattern-- after a week's worth of voting, 
if the outcome is stable, I will mirror and announce this RC as Tomcat 
4.1.31.

Please vote on the stability of this release:
Ballot
[ ] Alpha
[ ] Beta
[ ] Stable
/Ballot
Thanks,
Keith
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


4.1.31 tag Saturday

2004-09-16 Thread Keith Wannamaker
I will be tagging 4.1.31 Saturday in preparation for a 4.1.31 release 
canidate release.

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


Version announcements

2004-09-12 Thread Keith Wannamaker
I have a question about the consensus of verion announcements.
My understanding/recollection of the process is to only announce release 
canidates on tomcat-dev, then after some time a vote is taken on 
a/b/stable, then the resulting version is announced via jakarta-announce 
with the appropriate rating, and the web site was updated.

Lately the 5.x process seems to be to put release canidates on the 
website and announce them on a variety of lists before a stability 
rating vote is taken, cf 
http://marc.theaimsgroup.com/?l=tomcat-userm=109378770730995w=2

Was this a concious policy change or is it up to the whim of the RM?
Keith
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


content-length long

2004-08-26 Thread Keith Wannamaker
By setContentLength taking an int instead of a long, even in jsr154,
does this mean the only way to send back files longer than max_int
is to chunk them?

Spec folks, has there ever been dicussion of changing this  related
parameters to long?

Keith


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



[RESULT] 4.1.31 maintenance release

2004-08-23 Thread Keith Wannamaker
The vote carried.  I am aiming for the end of the month for
tagging and building a RC for 4.1.31.

Keith


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



RE: Where's 4.1.31?

2004-08-20 Thread Keith Wannamaker
Yoav, I haven't RM'd a release yet but if you or another RM-pro
is willing to show me what is involved I might be willing to wear
the hat for 4.1.31.  Here is how I understand the process:

- tag and create a release canidate
- email to announce@
- wait 48 hours for show stoppers
- delcare the RC a release
- email to announce@, update jakarta site

I'd even be willing to document this process if it is not already.

[EMAIL PROTECTED]


-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Sent: Friday, August 20, 2004 9:13 AM
To: Tomcat Developers List
Subject: RE: Where's 4.1.31?



Hi,
You can't expect a 4.1.31 anytime soon.  It's in a maintenance mode
where only Spec violations and security flaws are the things that would
get a new release out.  We suggest the same thing we've been suggesting
for a while now, upgrade to 5.x.

Yoav Shapira
Millennium Research Informatics


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



RE: Where's 4.1.31?

2004-08-20 Thread Keith Wannamaker
Hi Jess, in our case we don't have the resources at this point in
time to certify our product with a completely new code base.  

I'm sure different people have different reasons.

Keith


-Original Message-
From: Jess Holle [mailto:[EMAIL PROTECTED]
Sent: Friday, August 20, 2004 10:38 AM
To: Tomcat Developers List
Subject: Re: Where's 4.1.31?


The offer to do this is great, but I am more than a little curious:

Why would anyone bother with a 4.1.x upgrade at this point?  5.0.27 is 
faster, more stable, etc, at this point as best I can tell.


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



RE: Where's 4.1.31?

2004-08-20 Thread Keith Wannamaker
Hi Yoav, thanks for the release documentation.  Do you mind if I
check this in to jt-4.0?  I think it would be very helpful.

I am aware that 5.0 uses significantly different code which is
in itself a good reason for continuing maintenance releases of 4.1.

Backporting patches would be a nice side-improvement if it were
done, but I think there have been enough fixes to 4.1 itself
to warrant a new release without said backports.

From a procedural standpoint, it is my understanding that the 
only vote needed is one to label a rc (ie beta or stable).  
Is that correct?

If so, I'd like to be the 4.1.31 RM and I will go to work on 
syncing the release notes and get an rc out this weekend.

Keith



-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Sent: Friday, August 20, 2004 10:44 AM
To: Tomcat Developers List
Subject: RE: Where's 4.1.31?



Hi,
The process is already somewhat documented.  For example,
http://cvs.apache.org/~yoavs/tomcatReleaseManager.html is my personal
notes, and http://jakarta.apache.org/commons/releases/ is mostly
Jakarta-general, not specific to Commons.  It deviates from the process
you posted in that we usually label a release alpha or beta, leave it
out in the wild for a bit to give users a chance to use it, and then
call it stable (with a new announcement).


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



[VOTE] 4.1.31 maintenance release

2004-08-20 Thread Keith Wannamaker
Hi,

I propose to apply pending bugzilla 4.1 patches and issue
a 4.1.31 release.  The existance of unreleased committed fixes,
unapplied patches, and multiple requests for 4.1.31 on tomcat-dev
clearly represent an interest in a maintenance relase of
4.1.31.  I volunteer to be the RM for this release.

Voting will run till Monday night due to the weekend, then
I will tally the results.



ballot
The 4.1.31 maintenance release should happen:
[ ] Yes
[ ] No
/ballot


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



RE: Where's 4.1.31?

2004-08-20 Thread Keith Wannamaker
Hi Jeanfrancois, we share enthusiasm but not opinions.  I believe
since there are pending 4.1 patches in bugzilla and committed 4.1 
fixes then there is clearly an interest in preserving the 4.1 
tree in maintenance mode, and that means maintenance releases.

My understanding of the jakarta PMC guidelines is that a release
plan is a lazy majority vote, so your -1 would trigger a majority
vote on a 4.1.31 release.

So, I will issue a vote on this release.

Keith



-Original Message-
From: Jeanfrancois Arcand [mailto:[EMAIL PROTECTED]
Sent: Friday, August 20, 2004 12:46 PM
To: Tomcat Developers List
Subject: Re: Where's 4.1.31?




You have my -1 for a release.


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



style

2004-06-29 Thread Keith Wannamaker
I notice that tabs are showing up in some changes, specifically 
in jk2, but also in some other places.  I want to make sure that
we are all on the same page for using the apache coding standards
which call for no tabs and 4-space indents.  
Keith


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



RE: Connector bugs

2004-06-16 Thread Keith Wannamaker
+1
Keith

-Original Message-
From: Mark Thomas [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 16, 2004 1:37 PM
To: 'Tomcat Developers List'
Subject: Connector bugs

I propose re-assigning all connector bugs currently against TC4 to TC5.
I propose to mark the bugs against the deprecated connectors (a further 29)
as
WONTFIX.


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



RE: why is jk_registry.h in ./jk/native2/common? /2

2004-06-15 Thread Keith Wannamaker
Hi Guenter, I don't see any reason not to move it, but I
would be sure to update the devstudio as well as build.xml
files.  Probably the best thing to do is delete it and
commit it with a message indicating the original location.

Keith

-Original Message-
From: Günter Knauf [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 15, 2004 8:54 AM
To: [EMAIL PROTECTED]
Subject: why is jk_registry.h in ./jk/native2/common? /2


Hi folks,
can please some of the other commiters give some feedback?

possible responses are:
[ ] dont know
[X] move it to ./jk/native2/include
[ ] dontr move it - it has to stay in common for xxx reason


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



FW: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Protocol.java

2004-05-27 Thread Keith Wannamaker
Yoav, you might want to remove this.

Thanks,
Keith


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 27, 2004 11:12 AM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11
Http11Protocol.java


yoavs   2004/05/27 09:12:09

  Modified:http11/src/java/org/apache/coyote/http11 Http11Protocol.java
  Log:
  Added support for threadPriority attribute
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=28914).

  Revision  ChangesPath
  1.54  +13 -7
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Pro
tocol.java

  Index: Http11Protocol.java
  ===
  RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11
/Http11Protocol.java,v
  retrieving revision 1.53
  retrieving revision 1.54
  diff -u -r1.53 -r1.54
  --- Http11Protocol.java   2 Mar 2004 01:17:39 -   1.53
  +++ Http11Protocol.java   27 May 2004 16:12:09 -  1.54
  @@ -76,14 +76,11 @@
   public void setAttribute( String name, Object value ) {
   if( log.isTraceEnabled())
   log.trace(sm.getString(http11protocol.setattribute, name,
value));
  +
  +System.out.println(getClass().getName() +
  + : setAttribute( + name + ,  + value + ): here.);
  +
   attributes.put(name, value);


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



jakarta-servletapi-4

2003-12-09 Thread Keith Wannamaker
Does anyone object to me tagging head of this module with TOMCAT_4_1_29 ?

Keith


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



RE: jakarta-servletapi-4

2003-12-09 Thread Keith Wannamaker
Works for me -- no rush.  How about just tag it once you've
checked those doc warning fixes in? :-)

Keith

| -Original Message-
| From: Mark Thomas [mailto:[EMAIL PROTECTED]
| Sent: Tuesday, December 09, 2003 2:03 PM
| To: 'Tomcat Developers List'
| Subject: RE: jakarta-servletapi-4
| 
| 
| If you can wait a day or so I have some fixes to the javadoc comments to 
| commit. Only affects javadoc warnings during build so no problem if you need to 
| go ahead without them. I need to figure out how to use my newly acquired commit 
| privs before I can make the changes ;)
| 
| Mark
| 
| On Tuesday, December 09, 2003 5:56 PM, Keith Wannamaker 
| [SMTP:[EMAIL PROTECTED] wrote:
|  Does anyone object to me tagging head of this module with TOMCAT_4_1_29 ?
| 
|  Keith
| 
| 
|  -
|  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]
| 

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



[patch] wrong rx to invalid url

2003-09-18 Thread Keith Wannamaker
I'd like to commit something along these lines to the
v4 and v5 CoyoteAdaptors:

--- coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java16 Mar 2003 
01:56:27 -  1.13.2.3
+++ coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java18 Sep 2003 
19:45:09 -
@@ -273,7 +273,13 @@

 // URI decoding
 req.decodedURI().duplicate(req.requestURI());
-req.getURLDecoder().convert(req.decodedURI(), false);
+try {
+  req.getURLDecoder().convert(req.decodedURI(), false);
+} catch (IOException ioe) {
+res.setStatus(400);
+res.setMessage(Invalid URI);
+throw new IOException(Invalid URI);
+}
 req.decodedURI().setEncoding(UTF-8);

 // Normalize decoded URI

UDecoder.convert will throw a CharConversionException for
urls which contain '%' with invalid or no trailing hex digits.
This exception is ignored and Tomcat is returning a 200 with
an empty body, which is wrong.

Any suggestions on a better way to correct are welcome.

Keith


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



RE: [patch] wrong rx to invalid url

2003-09-18 Thread Keith Wannamaker
Yes it can be, good catch.

Keith

| -Original Message-
| From: Remy Maucherat [mailto:[EMAIL PROTECTED]
| Sent: Thursday, September 18, 2003 4:07 PM
| To: Tomcat Developers List
| Subject: Re: [patch] wrong rx to invalid url
| 
| 
| Keith Wannamaker wrote:
| 
|  I'd like to commit something along these lines to the
|  v4 and v5 CoyoteAdaptors:
|  
|  --- coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java16 Mar 
2003 01:56:27 -  1.13.2.3
|  +++ coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java18 Sep 
2003 19:45:09 -
|  @@ -273,7 +273,13 @@
|  
|   // URI decoding
|   req.decodedURI().duplicate(req.requestURI());
|  -req.getURLDecoder().convert(req.decodedURI(), false);
|  +try {
|  +  req.getURLDecoder().convert(req.decodedURI(), false);
|  +} catch (IOException ioe) {
|  +res.setStatus(400);
|  +res.setMessage(Invalid URI);
|  +throw new IOException(Invalid URI);
|  +}
|   req.decodedURI().setEncoding(UTF-8);
|  
|   // Normalize decoded URI
|  
|  UDecoder.convert will throw a CharConversionException for
|  urls which contain '%' with invalid or no trailing hex digits.
|  This exception is ignored and Tomcat is returning a 200 with
|  an empty body, which is wrong.
|  
|  Any suggestions on a better way to correct are welcome.
| 
| +1, this seems ok (good thing the request is properly recycled anyway). 
| BTW, can't the original ioe be rethrown (this seems simpler) ?
| 
| Remy
| 
| 
| 
| -
| 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: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteAdapter.java

2003-09-18 Thread Keith Wannamaker
I been unsuccessful all afternoon at building j-t-catalina, and end-of-day
has caught me.  If this commit gives anyone fits, let me know and I'll be
glad to roll it back.

Keith

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
| Sent: Thursday, September 18, 2003 6:21 PM
| To: [EMAIL PROTECTED]
| Subject: cvs commit:
| jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5
| CoyoteAdapter.java
| 
| 
| keith   2003/09/18 15:20:51
| 
|   Modified:catalina/src/share/org/apache/coyote/tomcat5
| CoyoteAdapter.java
|   Log:
|   Respond 400 to requests which contain '%' with no or invalid trailing hex digits
|   
|   Revision  ChangesPath
|   1.13  +11 -5 
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteAdapter.java
|   
|   Index: CoyoteAdapter.java
|   ===
|   RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteAdapter.java,v
|   retrieving revision 1.12
|   retrieving revision 1.13
|   diff -u -r1.12 -r1.13
|   --- CoyoteAdapter.java  7 Sep 2003 07:38:42 -   1.12
|   +++ CoyoteAdapter.java  18 Sep 2003 22:20:51 -  1.13
|   @@ -265,7 +265,13 @@
|// URI decoding
|MessageBytes decodedURI = req.decodedURI();
|decodedURI.duplicate(req.requestURI());
|   -req.getURLDecoder().convert(decodedURI, false);
|   +try {
|   +  req.getURLDecoder().convert(decodedURI, false);
|   +} catch (IOException ioe) {
|   +  res.setStatus(400);
|   +  res.setMessage(Invalid URI);
|   +  throw ioe;
|   +}
|
|// Normalize decoded URI
|if (!normalize(req.decodedURI())) {
|   
|   
|   
| 
| -
| 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]



eclipse dependencies

2003-08-10 Thread Keith Wannamaker
I'm switching to eclipse, so I get to rexamine dependencies 
in tc (4.1).  Just wanted to make a note for others who may 
try to do this:  since there are circular dependencies
between j-t-connectors and j-t-4.0, it is important to build 
coyote in a separate project which references both of these 
projects, and to exclude coyote from the j-t-connector project.
This makes me believe that coyote shouldn't live in j-t-connectors,
but I suppose there is a good reason why it is there.  Anyway, FYI. 
Keith


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



RE: [RFC] Handling the '*' URL

2003-07-11 Thread Keith Wannamaker
Hi Bill, I am partial to handling it in the default servlet.
I agree the root context can't speak definitively for all 
contexts, but I think it has a better chance of knowing a
proper response than the connector.

Keith

| -Original Message-
| From: Bill Barker [mailto:[EMAIL PROTECTED]
| Sent: Friday, July 11, 2003 2:08 AM
| To: Tomcat Developers List
| Subject: [RFC] Handling the '*' URL
| 
| 
| This is really a Request-For-Comments, I'm not proposing anything.  I'm
| looking into resolving Bug #21454.
| 
| At the moment, requests for e.g:
|   OPTIONS * HTTP/1.1
|   TRACE * HTTP/1.1
| get properly handled by TC 5 (thanks to Keith's patch), buy passing them to
| DefaultServlet.  However, the '*' URL is really a HTTP Protocol URL, so it
| seems to me that it really should be handled by the Connector instead of the
| Servlet.  On the other hand, we have access to the rich Servlet-API
| implementations (Ok, so I don't in 3.3-land, but I can fake it ;-).  So my
| problem is that I can't see the correct route to go here.
| 
| Opinions?
| 
| 
| -
| 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: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteAdapter.java

2003-07-03 Thread Keith Wannamaker
Hi Remy, * does map to the default context.  Can you think of any special 
downstream handling that we should do for '*'?  

Keith

| -Original Message-
| From: Remy Maucherat [mailto:[EMAIL PROTECTED]
| Sent: Thursday, July 03, 2003 2:50 AM
| To: Tomcat Developers List
| Subject: Re: cvs commit:
| jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5
| CoyoteAdapter.java
| 
| 
| [EMAIL PROTECTED] wrote:
|  keith   2003/07/02 17:16:49
|  
|Modified:catalina/src/share/org/apache/coyote/tomcat5
|  CoyoteAdapter.java
|Log:
|Allow * as a valid url
| 
| Errr, ok, well, that's a possibly risky patch. I think that does get 
| mapped to the root context and its default servlet (and the servlet path 
| should be *).
| I verified a /* security constraint mapping matched this URL.
| 
| Remy


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



RE: [VOTE] [4.1.24] Stability rating

2003-03-20 Thread Keith Wannamaker
| ballot
| [ ] Alpha
| [ ] Beta
| [X] Stable (GA)
| /ballot
| 

Keith

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



RE: A tomcat SSL question

2003-03-14 Thread Keith Wannamaker
Hi Mark, you can start the vm with -Djavax.net.debug=all to get
under the hood of jsse and see why the handshake is failing.
You may also need to do some conversion as described here:
http://www.comu.de/docs/tomcat_ssl.htm.  

Keith

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
| Sent: Thursday, March 13, 2003 9:53 PM
| To: [EMAIL PROTECTED]
| Subject: A tomcat SSL question
| 
| 
| So, would you please give me a hint, how can I use the certificate generated by my 
little Java program to run tomcat with SSL?
| 
| Thanks a lot in advance.
| 
| Mark (Choreson)


-
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/http/mapper Mapper.java

2003-03-13 Thread Keith Wannamaker
Hi Bill,

I had closed the bug because Remy told me it was already
fixed in 5.0.  I guess it wasn't.  If you do any more work
on it you should indicate the bug which is 14616.

Keith

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
| Sent: Thursday, March 13, 2003 1:18 AM
| To: [EMAIL PROTECTED]
| Subject: cvs commit:
| jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper
| Mapper.java
| 
| 
| billbarker2003/03/12 22:17:53
| 
|   Modified:util/java/org/apache/tomcat/util/http/mapper Mapper.java
|   Log:
|   Initial support to do a redirect to a directory where the URL doesn't end in '/'.
|   
|   This prevents browsers from becoming confused when they get a 401 response for 
e.g. /foo.  With this turned on, the 
| browser will get a 302 response to /foo/ before authentication is checked.
|   


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



RE: Please Help, Building JK2 failed

2003-03-13 Thread Keith Wannamaker
Hi Al, well of course production code is in CVS too.  Just use
the appropriate tag when checking out.  There might have been
something funny about your tarball, and you can eliminate this
possibility by pulling straight from CVS.

Keith

| -Original Message-
| From: Al [mailto:[EMAIL PROTECTED]
| Sent: Thursday, March 13, 2003 1:07 PM
| To: 'Tomcat Developers List'
| Subject: RE: Please Help, Building JK2 failed
| 
| 
| Anonymous CVS from where?  Why checkout from CVS?  I am trying to build
| a production JK2, not checkout development code.  My source came from
| the jakarta site as a release.
| 
| -Original Message-
| From: news [mailto:[EMAIL PROTECTED] On Behalf Of Costin Manolache
| Sent: Wednesday, March 12, 2003 10:38 AM
| To: [EMAIL PROTECTED]
| Subject: Re: Please Help, Building JK2 failed
| 
| 
| Al wrote:
| 
| 
|  jkant:
|  
|  BUILD FAILED 
|  file:/usr/local/web/tmp/apache/JK2/jakarta-tomcat-connectors-jk2-2.0.2
|  -s
|  rc/jk/build.xml:235: Warning: Could not find file
| 
| /usr/local/web/tmp/apache/JK2/jakarta-tomcat-connectors-jk2-2.0.2-src/jk
|  /jkant/ant.tasks to copy.
| 
| Where did you got the sources ? 
| 
| Try using anonymous CVS - the file should be there.
| 
| Costin
| 
| 
| -
| 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]
| 
| 

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



RE: 4.1 authentication bug / bug 14616

2003-03-12 Thread Keith Wannamaker
Hey Bill, thanks for the input.  I am all ears if you can think of
a better way to fix this in 4.1.  Rather than forward-porting this
fix to 5.0, I will look at better ways of doing it there since you
indicate they exist.

I think this is the way to go for 4.1 since it will fix both the
most and the worst cases, namely inter-webapp credential sharing.

Keith

| -Original Message-
| From: Bill Barker [mailto:[EMAIL PROTECTED]
| Sent: Wednesday, March 12, 2003 1:28 AM
| To: Tomcat Developers List
| Subject: Re: 4.1 authentication bug / bug 14616
| 
| 
| 
| - Original Message -
| From: Costin Manolache [EMAIL PROTECTED]
| To: [EMAIL PROTECTED]
| Sent: Tuesday, March 11, 2003 8:52 PM
| Subject: Re: 4.1 authentication bug / bug 14616
| 
| 
|  I think it is reasonable to fix it.
| 
|  This can be serious - if someone relies on application isolation ( like
|   a hosting environment ), the consequences can be really bad, with
|  one webapp guessing the credentials of another one.
|  The fix seems reasonably simple and clean.
| 
| 
| Except that it isn't really a fix.  Like Remy, I'd like to see a more
| general fix (e.g. using the new 5.0 Mapper).  However, I won't -1 if Keith
| wants to commit his patch.  It does fix the worst-case condition.
| 

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



RE: 4.1 authentication bug / bug 14616

2003-03-12 Thread Keith Wannamaker
Remy,

The fix corrects the bug, which is that credentials are shared
between webapps.  As I've asked before, if there is a better way
to correct it, I'm all for it.  There are a lot of bugs that have
been in the code for a long time, it doesn't mean they aren't bugs.

The behavior bothers me, and it would bother anyone else who
set up multiple webapps with authentication.

Keith


| -Original Message-
| From: Remy Maucherat [mailto:[EMAIL PROTECTED]
| Sent: Wednesday, March 12, 2003 10:24 AM
| To: Tomcat Developers List
| Subject: Re: 4.1 authentication bug / bug 14616
| 
| 
| As I've said before, I don't really mind this bug, and the proposed 
| solution is a hack. The behavior has been there forever, so apparently 
| it doesn't bother anyone. So I prefer keeping the current behavior.
| 
| The 5.0 mapper already handles that cleanly, and needs a little more 
| code for directory redirect. I supposed along with the welcome file 
| support change, that's a major behavior change.


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



RE: Compiling from sources

2003-03-12 Thread Keith Wannamaker
Hi Joseph,

Try checking out jakarta-tomcat-4.0 and jakarta-tomcat-connectors
with tag TOMCAT_4_1_22 or TOMCAT_4_1_18.  The failure is due to a
recent checkin that broke the build.  If you extract the fifteen or
so project dependencies into one separate dir, then point your 
build.properties to that dir, it is pretty good about picking them up.
Just step through build.properties and tweak a few version numbers here 
and there.  At any rate, the break of head will not last long.

Keith

| -Original Message-
| From: Joseph Hindin [mailto:[EMAIL PROTECTED]
| Sent: Wednesday, March 12, 2003 11:04 AM
| To: [EMAIL PROTECTED]
| Subject: Compiling from sources
| 
| 
|  For a couple of days I am trying to compile tomcat v4 from sources. 
| Unfortunately, the experience is not very encouraging.
| As a first step, I've tried to compile stable version by downloading 
| source code tarball. The tarball uses several Jakarta projects. 
| build.xml files for the subprojects are completely inconsistent, so it 
| took more than a day to get all subprojects, related technologies, etc. 
| At the end, the tarball approach failed, as connectors version required 
| functionality not available in modeler tarball ( 
| Registry.registerComponent was missing ).
|  Now I am trying to compile tomcat using CVS. Tomcat 
| build.properties doesn't fit CVS tree structure; several projects from 
| commons don't fit, too.
| Am I doing something wrong?
| 


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



4.1 authentication bug / bug 14616

2003-03-11 Thread Keith Wannamaker
Greetings,

I brought this up in November.  Remy and I have a disagreement 
on how important fixing this bug is.  I want to see if there is
a quorum of other committers who understand the problem and think
it should be fixed prior to the next stable build release of 4.1.

The immediate problem is that current Tomcat behavior causes
browsers to submit auth credentials to webapps other than the
webapp who originally sent the 401 challenge.

Most web servers, like Apache, are careful to redirect for
trailing slashes before challenging for authentication.  Tomcat
does this backward.  The result is the client will usually cache
the need for auth for the entire domain and not just a single 
webapp.

Here is a repeat of the scenario I mentioned in November
http://marc.theaimsgroup.com/?l=tomcat-devm=103673355109222w=2

 Context path=/foo docBase=foo /
 Context path=/bar docBase=bar /

foo and bar web.xml protected with
security-constraint
  web-resource-collection
web-resource-namename /web-resource-name
url-pattern/*/url-pattern
  /web-resource-collection
  auth-constraint
role-nameadmin/role-name
  /auth-constraint
/security-constraint

Current behavior:
Request Response
GET /foo401
 (at this point browsers will send credentials to any url in this domain)
GET /foo with auth  301 redirect to /foo/
GET /foo/   200
GET /bar with auth
 ^

Correct behavior:
GET /foo301 redirect to /foo/
GET /foo/   401
GET /foo/ with auth 200
GET /bar without auth
 

My proposed patch is attached to bug 14616
http://issues.apache.org/bugzilla/show_bug.cgi?id=14616
While this does not cover the case of subdirectories within 
a context, it does fix the most egregious case for context
roots.

Please comment if you are not comfortable with credentials being
inadvertently shared between all webapps on a given domain.

Keith

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



RE: auth bug fix for 4.0.6

2002-11-08 Thread Keith Wannamaker
Remy, I don't even know if 4.1.x and 5.0 share the bug or not;
I haven't tested it, though I suspect they do.  I do know 4.0.6
has the bug.

I'm not sure what interpretation you are questioning -- if it
is the placement or nature of the fix, sure, I said someone may
want to tweak the location and method of the fix.  However the
behavior is very standard and necessary (Apache handles auth
and redirects the same way for the same reason).

In the example I gave, the security constraint was /* for the 
context.

Keith

| -Original Message-
| From: Remy Maucherat [mailto:remm;apache.org]
| Sent: Friday, November 08, 2002 2:42 AM
| To: Tomcat Developers List
| Subject: Re: auth bug fix for 4.0.6
| 
| 
| Bill Barker wrote:
| 
|  As a non-4.x expert, your patch looks ok.  I would guess that it would 
|  still
|  have problems with a request to /foo/protected where the 
|  security-constraint
|  is only for /foo/protected/*.
| 
| I don't agree, the patch is bad for 4.1.x and 5.0 (at least, you must 
| use the decoded URI there). Tomcat 4.0.x is probably ok.
| 
| I also don't agree with Keith's interpretation depending on what the 
| constraint is. Can you give examples ?
| 
| Remy
| 
| 
|  It turns out TC 4.0.6 has the same auth bug as 3.3--
|  it challenges prior to redirects.  The immediate problem
|  this causes is that some browsers will cache and send
|  credentials for the entire domain after being challenged
|  for a top level directory without a trailing slash.
|  
|  So 4.0.6 exhibits this wrong behavior:
|   GET /foo   -  401
|   GET /foo with auth -  301 to /foo/
|   GET /foo/ with auth-  200
|   GET /bar with auth  .. (browser will send auth to other realms!)
|  
|  With the following patch it will exhibit this correct behavior:
|   GET /foo   -  301 to /foo/
|   GET /foo/  -  401
|   GET /foo/ with auth-  200
|   GET /bar  WITHOUT auth
|  
|  
|  I'll be glad to ci it, but those more in the know may
|  have a better location for the fix in mind.
|  
|  Keith


--
To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org




RE: auth bug fix for 4.0.6

2002-11-08 Thread Keith Wannamaker
Very good eyes Bill, I agree.  The correct fix would have to 
incorporate both the context name and the constraint URI.

Keith

| -Original Message-
| From: Bill Barker [mailto:wbarker;wilshire.com]
| Sent: Friday, November 08, 2002 2:11 AM
| To: Tomcat Developers List
| Subject: Re: auth bug fix for 4.0.6
| 
| 
| I would guess that it would still
| have problems with a request to /foo/protected where the security-constraint
| is only for /foo/protected/*.
|
| 

--
To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org




RE: Coyote/Http11 under load

2002-11-07 Thread Keith Wannamaker
The numbers were suspect because I was running 3.3 under
JBuilder but 4.0 externally, I'd imagine.  I set up clean
tomcat trees and ran them outside of any test environment
and I get these numbers:  (100 rqs/10 concurrent cx)

TC 4.0.6   | TC 3.3.2
Http11   Http10|Http11Http10
   |
Rq/sec26.9 25.89   | 18 27
kb/sec393  377 | 266404

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

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

Keith


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

--
To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org




auth bug fix for 4.0.6

2002-11-07 Thread Keith Wannamaker
It turns out TC 4.0.6 has the same auth bug as 3.3--
it challenges prior to redirects.  The immediate problem
this causes is that some browsers will cache and send 
credentials for the entire domain after being challenged
for a top level directory without a trailing slash.

So 4.0.6 exhibits this wrong behavior:
 GET /foo   -  401
 GET /foo with auth -  301 to /foo/
 GET /foo/ with auth-  200
 GET /bar with auth  .. (browser will send auth to other realms!)

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


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

Keith


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


--
To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org




Coyote/Http11 under load

2002-11-06 Thread Keith Wannamaker
I'm using http11 on a busy site with more or less Tomcat 3.3 head
(3.3.2-dev).  I set up the connector with ServerSoTimeout=5000,
SoTimeout=5000, maxThreads 100, maxSpare 50, minSpare 20.

This yields severe performance problems after only a short time in
service.  On reverting back to http10, the performance goes back
up and remains up.

I checked with optimizeit and the threads with coyote look to be 
doing what they are supposed to.  So, I started using ab to test
the server with concurrent connections.  The results I get with
20 concurrent connections:

coyote/http11   4.2rq/sec, 63kb/sec
http10  6.3rq/sec, 92kb/sec

Any similar experiences or ideas?  I'm continuing to investigate.
Keith


--
To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org




RE: Coyote/Http11 under load

2002-11-06 Thread Keith Wannamaker
Same box, same app, same test, with Tomcat 4.0.6's http10 and 11 adaptor:

coyote/http1137rq/sec, 406kb/sec
http10   30rq/sec, 181kb/sec

I've always held that 3.3 was more lean and mean than 4.0 but
now I'm wondering if this is just indicating some basic architectural
differences.  

Keith

| -Original Message-
| Subject: Coyote/Http11 under load
| 
| 
| I'm using http11 on a busy site with more or less Tomcat 3.3 head
| (3.3.2-dev). 
| 
| coyote/http11   4.2rq/sec, 63kb/sec
| http10  6.3rq/sec, 92kb/sec


--
To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org




RE: [PROPOSAL] Split the repo's

2002-07-18 Thread Keith Wannamaker

| 
| [X] I don't want the API's split into separate repo's
| [ ] I don't care
| [ ] I want the API's split into separate repo's.
| 

TC 4 has too many external module dependencies as it is.

Keith


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




Tomcat 4.x auth issue

2002-07-03 Thread Keith Wannamaker

Tomcat 4.x has a problem -- it challenges for auth
prior to any redirects.  This is wrong because it causes
most browsers to cache auth info for the entire domain 
when hitting top-level directories.

For example:

   WRONG way:
GET /foo   -  401
GET /foo with auth -  301 to /foo/index.html
GET /foo/index.html with auth  -  200
GET /bar  WITH auth  .. (browser will send auth to entire doman!)
   
   RIGHT way: (Apache being the best example)
GET /foo   -  301 to /foo/index.html
GET /foo/index.html-  401
GET /foo/index.html with auth  -  200
GET /bar  WITHOUT auth

It looks like this is difficult to fix since the
is this a directory?  Are there welcome files? logic
needs to move up out of DefaultServlet to a location
in the request chain prior to the auth valve.

Any better ideas are welcome as I begin hacking..

Keith
 

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




RE: Tomcat 4.x auth issue

2002-07-03 Thread Keith Wannamaker

The bugfix turned out to be a one-liner:

Index: SecurityConstraint.java
===
RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/de
ploy/SecurityConstraint.java,v
retrieving revision 1.5
diff -u -r1.5 SecurityConstraint.java
--- SecurityConstraint.java 22 Jul 2001 20:25:10 -  1.5
+++ SecurityConstraint.java 4 Jul 2002 02:50:10 -
@@ -455,7 +455,7 @@

 // Normalize the argument strings
 if ((path == null) || (path.length() == 0))
-path = /;
+return(false);
 if ((pattern == null) || (pattern.length() == 0))
 pattern = /;

I'll apply this fix if someone more versed in 4.x approves it.

Keith

| -Original Message-
| From: Keith Wannamaker [mailto:[EMAIL PROTECTED]]
| Sent: Wednesday, July 03, 2002 7:34 PM
| To: [EMAIL PROTECTED]
| Subject: Tomcat 4.x auth issue
| 
| 
| Tomcat 4.x has a problem -- it challenges for auth
| prior to any redirects.  This is wrong because it causes
| most browsers to cache auth info for the entire domain 
| when hitting top-level directories.


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




[3.3.2-dev] CoyoteConnector2 invalid headers

2002-06-03 Thread Keith Wannamaker

When using CC2 with TC 3.3.2, every request sets both
the content-length and the transfer-encoding, which
is not only wrong, but can confuse some clients.

Content-Length: 9
Transfer-Encoding: chunked

The 4.0 org.apache.catalina.connector.http.HttpConnector
does not have this problem.  Any quick ideas while I dig
through the code?

Keith


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




RE: ant tasks for 3.3

2002-05-22 Thread Keith Wannamaker

Hmm, you might try taking xerces out the CLASSPATH property
if there is already one in {ant.home}/lib

I would guess there are two copies of an XML provider in
your classpath.. are you using JDK1.4?  I did a google on
this error and apparently it comes up a lot.

Keith

| -Original Message-
| From: Jason Corley [mailto:[EMAIL PROTECTED]]
| Sent: Wednesday, May 22, 2002 9:16 AM
| To: [EMAIL PROTECTED]
| Subject: ant tasks for 3.3
| 
| 
| 
| I'm trying to use Keith's ant tasks for tomcat 3.3 and I'm having some issues.  I'm 
|not sure if I'm doing something wrong 
| or if there is an incompatibility somewhere.  I have the tomcat 3.3a RPMs installed, 
|and I'm using ant 1.5b1.  My 
| build.xml (I added the line breaks on the CLASSPATH variable for readability -- it 
|isn't in the actual file) is as follows:


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




RE: [VOTE] New committer: Denis Benoit

2002-05-21 Thread Keith Wannamaker

+1

Keith

| -Original Message-
| From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
| Sent: Tuesday, May 21, 2002 9:33 PM
| To: [EMAIL PROTECTED]
| Subject: [VOTE] New committer: Denis Benoit
| 
| 
| I'd like to propose Denis Benoit Denis.Benoit at fbn.ca as a committer on
| the Tomcat project.

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




jakarta-tomcat-jasper Jasper2

2002-05-20 Thread Keith Wannamaker

FYI The ant jspc testcases are failing with head of j-t-j/jasper2:

Using Jasper in jakarta-tomcat/
  [wannamak@piper jsp]$ java org.apache.jasper.JspC -v
   -d /usr/local/cvs/jakarta-ant/src/etc/testcases/taskdefs/optional/jsp/java

/usr/local/cvs/jakarta-ant/src/etc/testcases/taskdefs/optional/jsp/simple.jsp
  JspC: uriRoot implicitly set to
/usr/local/cvs/jakarta-ant/src/etc/testcases/ta
  skdefs/optional/jsp

Using Jasper2 in jakarta-tomcat-jas[er/
  [wannamak@piper optional]$ java org.apache.jasper.JspC
   -d /usr/local/cvs/jakarta-ant/src/etc/testcases/taskdefs/optional/jsp/java

/usr/local/cvs/jakarta-ant/src/etc/testcases/taskdefs/optional/jsp/simple.jsp
   2002-05-20 01:37:21 - ERROR-the file '/simple.jsp' generated the following
gener
   al exception: java.lang.NullPointerException
   java.lang.NullPointerException
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.init(FileOutputStream.java:102)
at java.io.FileOutputStream.init(FileOutputStream.java:62)
at org.apache.jasper.compiler.Compiler.compile(Unknown Source)
at org.apache.jasper.JspC.parseFile(Unknown Source)
at org.apache.jasper.JspC.parseFiles(Unknown Source)
at org.apache.jasper.JspC.main(Unknown Source)

Any ideas?

Keith


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




RE: tomcat-dev compile failure

2002-05-18 Thread Keith Wannamaker

Ah, I thought the JspC task had been around longer.
I agree.  The build should now ignore that task unless
an appropriate version of Ant is installed.

Keith

| -Original Message-
| From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]]
| Sent: Saturday, May 18, 2002 12:03 PM
| To: 'Keith Wannamaker'; 'tomcat-dev'
| Subject: RE: tomcat-dev compile failure
| 
| 
| I'm using ant 1.4.1 , just deleted tomcat-ant dependency from target
| tomcat-jars, as a woraround, but if tomcat-ant depends on beta software
| i should be commented by default
| 


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




RE: cvs commit: jakarta-tomcat RELEASE-NOTES-3.3.2.txt

2002-05-17 Thread Keith Wannamaker

Yes, put build/tomcat/ant/tomcat-ant.jar in your classpath 
and do something like:

property name=jspc value=org.apache.tomcat.ant.Tomcat3Precompiler /
taskdef resource=ant.properties /

target name=jsp
  jspc srcdir=/foo/jsps
destdir=tomcat_work_path/webapps/foo
uriroot=/foo/jsps compiler=${jspc} 
  include name=**/*.jsp /
  classpath refid=appropriate_classpath /
  /jspc 
  javac srcdir=tomcat_work_path/webapps/foo 
  classpath refid=another_appropriate_classpath /
  /javac
  jspversion srcdir=tomcat_work_path/webapps/foo /
  !-- one can also delete the .javas from the work dir if desired --
/target

The 'Tomcat3Precompiler' wraps the standards jspc, but
mangles the names with a version number (foo_1).

The 'jspversion' task a creates .ver file for every class
file of the form name_number.class

Keith

| -Original Message-
| From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
| Sent: Friday, May 17, 2002 8:06 AM
| To: Tomcat Developers List
| Subject: RE: cvs commit: jakarta-tomcat RELEASE-NOTES-3.3.2.txt
| 
| 
|   (Re-) Open the log files with append, so that log 
| rotation can
|   be configured to be other than daily.
|   +
|   + Package an Ant compiler adapter that compiles JSPs 
| with the correct
|   + naming convention and an Ant task which creates 
| .ver files.  These
|   + tasks allow the Tomcat work directory to be 
| pre-populated with 
|   + compiled JSPs.
|
| 
| Great, Do you have a task parm with the work directory location ?
| 
| --
| To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
| For additional commands, e-mail: mailto:[EMAIL PROTECTED]
| 
| 

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




RE: cvs commit: jakarta-tomcat RELEASE-NOTES-3.3.2.txt

2002-05-17 Thread Keith Wannamaker

It's already checked in to Tomcat, so the jar is created
when you do a build. 
Keith

| -Original Message-
| From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
| Sent: Friday, May 17, 2002 8:26 AM
| To: Tomcat Developers List
| Subject: RE: cvs commit: jakarta-tomcat RELEASE-NOTES-3.3.2.txt
| 
| 
| Did you have a preliminary version available ?
| 
| -
| Henri Gomez ___[_]
| EMAIL : [EMAIL PROTECTED](. .) 
| PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
| PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 
| 


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




RE: ant tools for 3.3 and dtomcat3/rc script

2002-05-17 Thread Keith Wannamaker

No, for a Tomcat which has already been installed,
you should use the JspC tomcat option to precompile
JSPs.

What I did is to create an Ant task with the same 
functionality as the already-present JspC option,
for use in build environments.

Keith

| -Original Message-
| From: Jason Corley [mailto:[EMAIL PROTECTED]]
| Sent: Friday, May 17, 2002 9:26 AM
| To: [EMAIL PROTECTED]
| Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
| Subject: ant tools for 3.3 and dtomcat3/rc script
| 
| 
| 
| Would it be possible to take Keith's tomcat3 JSP precompiler and add 
| it as an option to dtomcat3 (and rc script for the RPM)?  What I'm 
| thinking of is being able to run:
|   /etc/rc.d/init.d/tomcat3 precompile
|   /etc/rc.d/init.d/tomcat3 start
| Henri you've probably already thought about this for the 3.3.2 
| release RPM; were you planning on trying to implement?
| 

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




RE: ant tools for 3.3 and dtomcat3/rc script

2002-05-17 Thread Keith Wannamaker

I agree that's why I wrote the task :-)  
Maybe I misuderstood Jason,.. thought he wanted to use
the ant tool post-installation-- tomcat recompile would
be a better option in that case, IMO.  But, of course, 
the ant tool can be used, if ant is available.

Keith

| -Original Message-
| From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
| Sent: Friday, May 17, 2002 9:47 AM
| To: Tomcat Developers List
| Subject: RE: ant tools for 3.3 and dtomcat3/rc script
| 
| 
| No, for a Tomcat which has already been installed,
| you should use the JspC tomcat option to precompile
| JSPs.
| 
| What I did is to create an Ant task with the same 
| functionality as the already-present JspC option,
| for use in build environments.
| 
| From my experience in production deployement having
| jspc in ant is much better than just using tomcat recompile.
| 

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




RE: ant tools for 3.3 and dtomcat3/rc script

2002-05-17 Thread Keith Wannamaker

You've got it.  I thought you were talking post-install, but,
again, if Ant's available you can use the task whenever you 
wanted to.

Keith

| -Original Message-
| From: Jason Corley [mailto:[EMAIL PROTECTED]]
| Sent: Friday, May 17, 2002 9:50 AM
| To: Tomcat Developers List
| Subject: RE: ant tools for 3.3 and dtomcat3/rc script
| 
| 
| 
| Hmm, perhaps I'm a little confused (not that difficult to believe :-) 
| but I thought jspc didn't create files with the proper naming scheme 
| for tomcat.  I thought the ant task was a wrapper around jspc that 
| solves that problem (along with the other ant task you posted that 
| creates the appropriate .class/.ver files).
| Jason
| 

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




found 3.3-head thread problem

2002-05-15 Thread Keith Wannamaker

Remember last week when I mentioned the thread problem in 3.3-head?

In PoolTcpEndpoint, when there is a SocketException, we log a
non-fatal error message.  The problem began when Remy pointed
the string manager to an empty bundle.  StringManager.getString
will return a null rather than throw a missing resource, and a
null check is not done by JDK 1.3 prior to trying to format the
message.  The resulting npe terminated the thread.  Gradually
over time, all accepting threads are terminated.

So, no big deal, add the missing resources, but I'm wondering, 
why don't we check to see if our accepting thread count dwindles
or vanishes, and start more up?  Is this logic non-existant or broken?

Keith


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




RE: found 3.3-head thread problem

2002-05-15 Thread Keith Wannamaker

This is why-- in PoolThreadEndpoint, a new thread is 
started only when a socket is accepted.  Since the npe
happened  before this, the whole thing shut down without
running another thread.

So, we need to wrap for Throwable, and I think the best
place to do it is around the accept in PTE.runIt.  I'll
add it right now..

Keith


| Great finding. 
| 
| I would also add another round of try/catch for Throwable 
| to catch any other NPE in the catch().
| 
| Not sure about the logic - it is supposed to detect and start
| new threads... If you can take a look...
| 
| Costin
| 
| 
| --
| To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
| For additional commands, e-mail: mailto:[EMAIL PROTECTED]
| 
| 

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




ant tools for 3.3

2002-05-15 Thread Keith Wannamaker

I've written some ant tools that allow builds to populate 
the Tomcat work directories with precompiled JSPs.  I'm
trying to decide a home for them, if any, and was thinking
of a new package org.apache.tomcat.ant .. any other
preference?

code is @ http://apache.org/~keith/

Keith

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




RE: ant tools for 3.3

2002-05-15 Thread Keith Wannamaker

Ok, I added it to the build, but not the distribution
(no good place for it?).  Also, I didn't put ant.props
in META-INF because it could not be found by the app 
there.  It's just in the top level of the jar.  I know
I'm missing something here.. 

Also, I went ahead and put the adapter in j-t for now,
rather than j-t-j.  It can always be moved later, especially
since I know nothing about the mangler j-t-j.  Yes, optimally,
mangling support would be more flexible and it should go over
there, but it's ok for now in j-t.

Keith


| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
| Sent: Wednesday, May 15, 2002 7:06 PM
| To: Tomcat Developers List
| Subject: Re: ant tools for 3.3
| 
| 
| On Wed, 15 May 2002, Keith Wannamaker wrote:
| 
|  I've written some ant tools that allow builds to populate 
|  the Tomcat work directories with precompiled JSPs.  I'm
|  trying to decide a home for them, if any, and was thinking
|  of a new package org.apache.tomcat.ant .. any other
|  preference?
| 
| +1
| 
| Just make sure the build.xml is able to exclude the tasks from
| the 'main' jars and create separate jars for the new tasks.
| 
| Also - please include META-INF/ant.properties ( for multiple
| taskdefs with resource= )
| 
| Costin
| 

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




Thread issues

2002-05-10 Thread Keith Wannamaker

Hey folks,
There seems to be a threading issue introduced between
3.3 and current 3.3.2-dev head.  When running the code
under heavy load with four tcp endpoints (2 http10, ajp12,
ajp13) eventually one of the http connectors disappears
from thread dumps.  In going through diffs the most
significant change I see is Bill's change to the expirer,
but I'm not sure if that is related at all.  The purpose
of this note is to solicit ideas on debugging and to see
if anyone else has run into this behavior.

Thanks,
Keith


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




RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/mappers DecodeInterceptor.java

2002-04-23 Thread Keith Wannamaker

Costin, et al, if you folks know of a faster way to check for this,
by all means

-Keith

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
| Sent: Tuesday, April 23, 2002 2:50 PM
| To: [EMAIL PROTECTED]
| Subject: cvs commit:
| jakarta-tomcat/src/share/org/apache/tomcat/modules/mappers
| DecodeInterceptor.java
| 
| 
| keith   02/04/23 12:49:40
| 
|   Modified:src/share/org/apache/tomcat/modules/mappers
| DecodeInterceptor.java
|   Log:
|   Our security measure is too agressive; incorrectly mangles
|   proxy-style urls.  Check for http/https exceptions when
|   removing double slashes.


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




RE: cvs commit: jakarta-tomcat/src/tests/webpages/WEB-INF test-tomcat.xml

2002-04-18 Thread Keith Wannamaker

I haven't heard from any 4.0 folks -- any interest
in me doing something similar for that tree?

Keith

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
| Sent: Thursday, April 18, 2002 8:58 AM
| To: [EMAIL PROTECTED]
| Subject: cvs commit: jakarta-tomcat/src/tests/webpages/WEB-INF
| test-tomcat.xml
| 
|   Log:
|   Remove '.sh' extensions from shell scripts (in the build).
|   Update references.
|   


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




Bug in safe url parsing

2002-02-05 Thread Keith Wannamaker

Greetings,

There is a bug in ByteChunk.indexOf which manifests itself
in the safe url parsing.  That is, BC.indexOf returns an
offset relative to the start of the byte buffer, rather
than the internal starting point.

So, when safe url checks for indexOf('%'), depending on the
length of the method name, a number of %'s at the beginning
of the URL may be missed.

So, the following URLs would be tagged as safe (currently):
GET /wannamak/%25%5C

A quick fix is to use indexOf(%), which converts the
relevant part of the byte array to a string, so the offset
is correct.

However, I think that it would be better to correct BC.indexOf
in the following manner:

Index: ByteChunk.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/buf/ByteChun
k.java,v
retrieving revision 1.8
diff -u -r1.8 ByteChunk.java
--- ByteChunk.java  19 Jul 2001 05:49:02 -  1.8
+++ ByteChunk.java  5 Feb 2002 17:36:42 -
@@ -626,7 +626,8 @@
  * @param s the string
  */
 public int indexOf(char c, int starting) {
-   return indexOf( buff, start+starting, end, c);
+   int ret = indexOf( buff, start+starting, end, c);
+   return (ret = start) ? ret - start : -1;
 }

 public static int  indexOf( byte bytes[], int off, int end, char qq )

I will commit this later today if I hear no objection.

Regards,
Keith


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




FW: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/generators ErrorHandler.java

2001-12-20 Thread Keith Wannamaker

A 4.x person might want to take a look to make sure this
doesn't happen there, too.  The performance and stability
of Netscape is like night and day with this...

Keith


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 20, 2001 2:57 PM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-tomcat/src/share/org/apache/tomcat/modules/generators
ErrorHandler.java


keith   01/12/20 11:56:44

  Modified:src/share/org/apache/tomcat/modules/generators
ErrorHandler.java
  Log:
  The statusHandler is returning a body for 304 responses,
  which is forbidden by both HTTP/1.1 and HTTP/1.0.

  IE is forgiving, but Netscape Navs  6.x assume that a
  body is not there, even if the content-length is set
  (it is).  So, the 304 response body gets munged with the
  next response body.  Of course, this does not happen
  standalone because the bug requires connections to be
  kept alive.

  cf http://www.w3.org/Protocols/HTTP/1.0/spec.html#Code304,
 http://www.w3.org/Protocols/HTTP/1.1/spec.html#Code304

  Revision  ChangesPath
  1.21  +5 -0
jakarta-tomcat/src/share/org/apache/tomcat/modules/generators/ErrorHandler.java

  Index: ErrorHandler.java
  ===
  RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/generators/ErrorHan
dler.java,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- ErrorHandler.java 2001/10/06 02:31:10 1.20
  +++ ErrorHandler.java 2001/12/20 19:56:44 1.21
  @@ -665,6 +665,11 @@
// status is already set
int sc=res.getStatus();

  +if( sc == 304 ) {
  +  //NotModified must not return a body
  +  return;
  +}
  +
if( sbNote==0 ) {
sbNote=req.getContextManager().getNoteId(ContextManager.REQUEST_NOTE,
 StatusHandler.buff);




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


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




ajpv12 socket closure

2001-12-12 Thread Keith Wannamaker

I've been debugging a socket problem in ajpv12 (NT) where bits
are being written by Tomcat to the socket (back to mod_jk), but
jk's read fails with a SHUTDOWN.  It's as if the bits don't 
quite make it onto the wire, and the socket closure is a hard close.

I thought the point of so_linger was to specify the amount of time
to try to send the queue bits onto the wire prior to closing the socket.

Wouldn't this indicate that the present value (100) is too small?

The relevant t-d thread is 
http://w6.metronet.com/~wjm/tomcat/2000/Sep/msg00151.html

Thanks for any info,
Keith

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




RE: ajpv12 socket closure

2001-12-12 Thread Keith Wannamaker

It turns out that disabling Nagle in Ajp12Interceptor
fixes this problem of lost data.  The question is, why?
I can't imagine that Nagle holds back data during a
socket shutdown.  Yet, I don't have any other explanation.

I'm not going to commit a change for this until I understand
why this solves the problem, but at least the fix is now 
documented for posterity.

Keith


| -Original Message-
| From: Keith Wannamaker [mailto:[EMAIL PROTECTED]]
| Sent: Wednesday, December 12, 2001 2:59 PM
| To: [EMAIL PROTECTED]
| Subject: ajpv12 socket closure
| 
| 
| I've been debugging a socket problem in ajpv12 (NT) where bits
| are being written by Tomcat to the socket (back to mod_jk), but
| jk's read fails with a SHUTDOWN.  It's as if the bits don't 
| quite make it onto the wire, and the socket closure is a hard close.
| 
| I thought the point of so_linger was to specify the amount of time
| to try to send the queue bits onto the wire prior to closing the socket.
| 
| Wouldn't this indicate that the present value (100) is too small?
| 
| The relevant t-d thread is 
| http://w6.metronet.com/~wjm/tomcat/2000/Sep/msg00151.html
| 
| Thanks for any info,
| Keith
| 
| --
| To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
| For additional commands, e-mail: mailto:[EMAIL PROTECTED]
| 

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




RE: 3.3 classloading resources

2001-11-28 Thread Keith Wannamaker

Hi Costin,
Yes, I verified that this does indeed do the trick.
Wonder if Sun is going to fix ResourceBundle to handle this?
Hope so!  At any rate, thanks for the tip.

Keith

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
| Sent: Monday, November 26, 2001 6:49 PM
| To: Tomcat Developers List
| Subject: Re: 3.3 classloading  resources
| 
| 
| The solution - for JDK1.2+ - is to use the 3 parameter getBundle, with
| Thread.currentThread().getContextClassLoader() as the third param.
| For JDK1.1 there's nothing you can do.
| 
| Let me know if it doesn't work - I tried this before and I had no
| problems.  The resources could be in WEB-INF/classes, a jar in
| WEB-INF/lib or any jar in the app.classloader.


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




3.3 classloading resources

2001-11-26 Thread Keith Wannamaker

I think there may be a problem with resource loading in TC3.3.
If I add a property file to the app class path by setting 
org.apache.tomcat.apps.classpath, then the call to 
ResourceBundle.getBundle(foo) doesn't find it.  Nor does
it get located if I place the said property file in tomcat/lib/apps.
In fact, the only way I have been able to find it is to 
override the classpath in the tomcat script.

The good news is that, by setting org.apache.tomcat.apps.classpath,
initClassLoaders() does set the AppsLoader class to a ClassLoader 
which contains my properties file.

The bad news is this doesn't seem to be the deafult loader used
in the call to ResourceBundle.getBundle(foo).

The only thing I can think of trying is
ResourceBundle.getBundle(foo, Locale.getDefault(),
 magic.ContextManager.getAppsLoader());
but that binds the code to the Tomcat container.

My next step is to rebuild the jdk with debugging info to see which
loader is actually being used in ResourceBundle.getBundle, but
I appreciate any insight in the interim.

Keith


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




RE: [PATCH][3.3] tomcat.sh cleanup

2001-10-21 Thread Keith Wannamaker

It would be nice also to display the command that is used
to initialize the jk web config files, jkconf or whatever.
Keith

| -Original Message-
| From: Jeff Turner [mailto:[EMAIL PROTECTED]]
| Sent: Sunday, October 21, 2001 2:44 AM
| To: [EMAIL PROTECTED]
| Subject: [PATCH][3.3] tomcat.sh cleanup
| 
| 
| Hi,
| 
| The help text displayed when you type ./tomcat.sh currently reads:
| 
| Usage:
| tomcat (start|env|run|stop|jspc)
| start - start tomcat in the background
| run   - start tomcat in the foreground
| run -wait - wait until tomcat is initialized before returning  
| -security - use a SecurityManager when starting
| stop  - stop tomcat
| env  -  set CLASSPATH and TOMCAT_HOME env. variables
| jspc - run jsp pre compiler
| 
| 
| This is out of date (missing 'enableAdmin' and 'estart'), is partially
| incorrect (-wait applies to 'start', not 'run'), and is hard to read.
| 
| The attached patch fixes this, so it will print:
| 
| ./tomcat.sh (start|run|stop|enableAdmin|estart|env|jspc)
|   start- start tomcat in the background
|   start -security  -   use a SecurityManager when starting
|   start -noout -   redirect stdout/stderr to $TOMCAT_HOME/logs/stdout.log
|   start -wait  -   wait until tomcat is initialized before returning
|   run  - start tomcat in the foreground
|   run -security-   use a SecurityManager when starting
|   stop - stop tomcat
|   stop -force  - stop tomcat with the 'kill' command if necessary
|   enableAdmin  - Trust the admin web application,
|  i.e. rewrites conf/apps-admin.xml with trusted=true
|   estart   - Start Tomcat using the/your EmbededTomcat class which
|  uses a hardcoded set of modules
|   env  - set CLASSPATH and TOMCAT_HOME env. variables
|   jspc - run jsp pre compiler
| 
| 
| The patch also fixes indentation, and parametrizes the MAX_WAIT variable to
| reliably fix another doc bug.
| 
| 
| Also, I noticed that line 294 contains:
| 
| TOMCAT_OPTS=$TOMCAT_OPTS 
| -Djava.security.policy==${TOMCAT_HOME}/conf/tomcat.policy 
| 
| Shouldn't that be a single '='? There is the same thing in tomcat.bat. Not
| being sure of the implications, I haven't changed this in the patch.
| 
| 
| --Jeff
| 



RE: Volunteers for: - RE: TC 3.3: getRequestURI()

2001-10-01 Thread Keith Wannamaker

Henri, I do not think this will be useful
or necessary with the planned changes.  I'd
be -1.

r-uri will be used, making the mod_rewrite 
folks happy, and the facade will encode the 
uri, which implements the spec correctly.

Does this plan break something, the reason
you want to add an Option?

Keith


| -Original Message-
| From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
| Sent: Monday, October 01, 2001 5:18 AM
| To: [EMAIL PROTECTED]
| Subject: RE: Volunteers for: - RE: TC 3.3: getRequestURI()
| 
| 
| 
| - Revert jk/apache to use uri, remove the encode call ( again, j-t and
| j-t-c - one more week to do that, after that we'll be j-t-c 
| only ). Henri
| - could you do this and the next one ?
| 
| I'll reintroduce the JkOptions which will help us play with
| different encoding :
| 
| ForwardStandardURI :
| 
| will send just std uri 
| 
| s-req_uri = r-uri
| 
| 
| ForwardEscapedURI :
| 
| will send escaped 
| 
| s-req_uri = ap_escape_uri(r-uri))
| 
| 
| ForwardUnparsedURI :
| 
| will send escaped
| 
| s-req_uri  = r-unparsed_uri;
| if (s-req_uri != NULL) {
| char *query_str = strchr(s-req_uri, '?');
| if (query_str != NULL) {
| *query_str = 0;
| }
| 
| We could later drop support for some options
| and make by default ForwardEscapedURI 
|



RE: Volunteers for: - RE: TC 3.3: getRequestURI()

2001-10-01 Thread Keith Wannamaker

What whould happen in 3.3 if ForwardEscapedURI was chosen?
Wouldn't the facade escape it again?

Keith

| -Original Message-
| From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
| Sent: Monday, October 01, 2001 10:10 AM
| To: [EMAIL PROTECTED]
| Subject: RE: Volunteers for: - RE: TC 3.3: getRequestURI()
| 
| 
| Henri, I do not think this will be useful
| or necessary with the planned changes.  I'd
| be -1.
| 
| r-uri will be used, making the mod_rewrite 
| folks happy, and the facade will encode the 
| uri, which implements the spec correctly.
| 
| Does this plan break something, the reason
| you want to add an Option?
| 
| The idea is to conserve compatibility with
| Tomcat 3.2.x and Tomcat 4.0 until they have
| their java side implementing the required stuff.
| 
| 
| Keith
| 
| 
| | -Original Message-
| | From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
| | Sent: Monday, October 01, 2001 5:18 AM
| | To: [EMAIL PROTECTED]
| | Subject: RE: Volunteers for: - RE: TC 3.3: getRequestURI()
| | 
| | 
| | 
| | - Revert jk/apache to use uri, remove the encode call ( 
| again, j-t and
| | j-t-c - one more week to do that, after that we'll be j-t-c 
| | only ). Henri
| | - could you do this and the next one ?
| | 
| | I'll reintroduce the JkOptions which will help us play with
| | different encoding :
| | 
| | ForwardStandardURI :
| | 
| | will send just std uri 
| | 
| | s-req_uri = r-uri
| | 
| | 
| | ForwardEscapedURI :
| | 
| | will send escaped 
| | 
| | s-req_uri = ap_escape_uri(r-uri))
| | 
| | 
| | ForwardUnparsedURI :
| | 
| | will send escaped
| | 
| | s-req_uri  = r-unparsed_uri;
| | if (s-req_uri != NULL) {
| | char *query_str = strchr(s-req_uri, '?');
| | if (query_str != NULL) {
| | *query_str = 0;
| | }
| | 
| | We could later drop support for some options
| | and make by default ForwardEscapedURI 
| |
| 



RE: Volunteers for: - RE: TC 3.3: getRequestURI()

2001-10-01 Thread Keith Wannamaker

Why can't we implement the 3.3 collaborative solution in 4.0 ?
That would maintain compatibility.

I just hate to provide an option which could result
in wrong (double escaped) behavior.  At the least,
it's one more variable to debug, at worst, it will
generate erroneous bug reports.  I'd hesitate to
add it.

Keith

| -Original Message-
| From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
| Sent: Monday, October 01, 2001 10:35 AM
| To: [EMAIL PROTECTED]
| Subject: RE: Volunteers for: - RE: TC 3.3: getRequestURI()
| 
| 
| What whould happen in 3.3 if ForwardEscapedURI was chosen?
| Wouldn't the facade escape it again?
| 
| 
| My goal in mod_jk is to keep compatibility with ALL tomcat
| release, TC 3.2, 3.3 and 4.0. 
| 
| The option will let us configure it, even if by default 
| mod_jk found in TC 3.3 and J-T-C will use the TC 3.3 
| collaborative scheme (part in Native and part in Java).
| 
| Let's note that the JkOptions are only available in Apache
| 1.3/2.0 and such flags could be needed also in IIS/NES/DOMINO
| 



RE: Volunteers for: - RE: TC 3.3: getRequestURI()

2001-10-01 Thread Keith Wannamaker

I thought you were talking about the mod_jk in the TC3.3
branch.  If you're talking j-t-c only, then I don't mind an
Option, as long as it defaults to the 3.3 behavior.

Keith

| -Original Message-
| From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
| Sent: Monday, October 01, 2001 11:24 AM
| To: [EMAIL PROTECTED]
| Subject: RE: Volunteers for: - RE: TC 3.3: getRequestURI()
| 
| 
| Why can't we implement the 3.3 collaborative solution in 4.0 ?
| That would maintain compatibility.
| 
| And also in TC 3.2.4 ?
| 
| I just hate to provide an option which could result
| in wrong (double escaped) behavior.  At the least,
| it's one more variable to debug, at worst, it will
| generate erroneous bug reports.  I'd hesitate to
| add it.
| 
| The Option could be hidden and use the TC 3.3 behaviour
| by default...




RE: cvs commit: jakarta-tomcat/src/native/mod_jk/common jk_global.h

2001-10-01 Thread Keith Wannamaker

I thought what we decided to do was use

s-uri = r-uri (a URI decoded already in Apache)

and in the facade, re-encode it.  So
JK_OPT_FWDURICOMPAT should be the default.


| -Original Message-
|   + * We use JkOptions to determine which method to be used 
|   + * 
|   + * ap_escape_uri is the latest recommanded but require
|   + *   some java decoding (in TC 3.3 rc2)
|   + *
|   + * unparsed_uri is used for strict compliance with spec and
|   + *  old Tomcat (3.2.3 for example)
|   + *
|   + * uri is use for compatibilty with mod_rewrite with old Tomcats
| */




RE: TC 3.3: getRequestURI()

2001-09-26 Thread Keith Wannamaker

I'm not sure I understand why the session id was not
also showing up with r-unparsed_uri.  I'm doing some
experimenting now..

Keith

|/login/login.vm%3bjsessionid=q95pbsuof1

| Probably not.  It's a side of effect of the last change which was
| to use s-req_uri = ap_escape_uri(r-pool, r-uri);. This looks
| like a good example of a re-encoded URI not being equal to the
| original.
| 
| Thanks for noticing this.
| 
| Larry
| 



RE: TC 3.3: getRequestURI()

2001-09-26 Thread Keith Wannamaker

Are you using mod_jk?

| -Original Message-
| From: Bill Barker [mailto:[EMAIL PROTECTED]]
| Sent: Wednesday, September 26, 2001 1:17 PM
| To: [EMAIL PROTECTED]
| Subject: Re: TC 3.3: getRequestURI()
| 
| 
| I don't get this with RC1.  From tomcat-log with debugging enabled for




RE: [PATCH] Potential buffer overflow attach in mod_jk

2001-09-26 Thread Keith Wannamaker

Hi Bill, would you resubmit a patch that makes use of either
Apache or jk's pools?  ie ap_strdup or jk_pool_strdup.
That would be a better way to solve the problem.  Apache
modules should and do avoid os memory-allocation routines
like the plague.  I think uw_map-p would be ok, but please
do some testing.

Thanks,
Keith

| -Original Message-
| From: Bill Barker [mailto:[EMAIL PROTECTED]]
| Sent: Wednesday, September 26, 2001 2:37 PM
| To: [EMAIL PROTECTED]
| Subject: Fw: [PATCH] Potential buffer overflow attach in mod_jk
| 
| 
| Urm, let's try that again with a patch that at least compiles..




RE: TC 3.3: getRequestURI()

2001-09-26 Thread Keith Wannamaker

I'm +1 for this.  It is the best solution.

Keith

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
| 
| 3. Revert to the use of uri ( i.e. the decoded uri ), and
| change the getRequestURI ( the facade ) to generated a
| 'canonical' encoding.
| Problems:




RE: [PATCH] Potential buffer overflow attach in mod_jk

2001-09-26 Thread Keith Wannamaker

I was afraid of that... guess os memory allocation it is, then.

Keith

| It looked to me like
| uw_map-p wasn't suitable for per-request allocations (i.e. it would just
| eat memory until the server was re-started), and since this is in common, I
| couldn't use ap_strdup since that breaks all non-Apache servers.




  1   2   >