RE: mod_jk 1.2.0 (CVS) + TC 3.3 B1

2001-08-20 Thread GOMEZ Henri

Hi to all,

I'm back from hollidays :(

After finally getting over the 'graceful restart' issues...

Could you developp it more please ?

Is this for some reason a 'forbidden' combination? I've observed some
really strange stuff going on with this combo - parameters don't get
passed correctly, even session stuff tends to be screwed (ie. same
session data appears in two totally different browsers).

Is this something that's known not to work or did I just screw things
up? Things work just fine when mod_jk shipped with TC 3.3 B1 
is used. Is
mod_jk 1.2.0 only to be used with the latest TC 3.3 CVS snapshot?

mod_jk in JTC is an evolution of mod_jk in CVS. Some refactoring 
was done to share code between ajp13 and ajp14. 

If this is not a known thing, I can send some more data...

Yes, please, strace could help in that case.



RE: New SSL HOWTOs

2001-08-20 Thread GOMEZ Henri

That's a good works and we should in with my tomcat-ssl-howto.html :)

There is still things to be mentioned like :

- how to import OpenSSL, Thawte or Verisign WebServer certificates.
- in case of client authentification, how the stuff works.
 
  2 cases :

  You start you're own CA, using openca (www.openca.org) or part of 
  jonama works (www.multimania.com/jonama/). Then you generate both
  client certs and web-server certs with the newly created CA. Don't
  forget to import the CA cert 

  You're using Thawte or Verisign or other major CA providers and
  in that case you should import the CA cert.

  That kind of question cover about 95% of the question on 
  tomcat-ssl-howto.html and I saw with your works a great occasion 
  to have a better documentation : 

  What about merging ?

 

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



-Original Message-
From: Christopher Cain [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 16, 2001 8:12 PM
To: Tomcat-Dev
Subject: New SSL HOWTOs


While creating the 3.3 version of my SSL HOWTO, I also polished off the
wording here and there and added a TOC and section marks for easier
navigation. Attached are both the 3.3 and 4.0 versions of the file.
Consider this 4.0 version to supercede the one I sent last night (or
early this morning, as it were :-)

If someone could please let me know for sure that adding extension JARs
to the {JDK_HOME}/jre/lib/ext directory under JDK 1.1.8 effectively
makes them installed extensions (makes them available without
necessarily being in the CLASSPATH) just like in = JDK 1.2. Other than
that, I'm pretty sure the TC 3.3 version of the doc is valid for JDK
1.1.8 environments as well. If someone a little more familiar 
with 1.1.8
could maybe give it a quick once-over and see if anything jumps out,
that would be great.

- Christopher




[PATCH] TC4 shell Scripts

2001-08-20 Thread Stephane Bailliez


Fixed some bugs that prevented its use under cygwin.

Paths must always be converted in Unix format before anything is touched and
must be converted back to windows format.

Also added a better cygwin detection (was relying on an OSTYPE env variable,
now using uname)

Cheers,

-- 
 Stéphane Bailliez 
 Software Engineer, Paris - France 
 iMediation - http://www.imediation.com 
 Disclaimer: All the opinions expressed above are mine and not those from my
company. 



 digest.sh.diff
 catalina.sh.diff


Re: mod_jk 1.2.0 (CVS) + TC 3.3 B1

2001-08-20 Thread Bojan Smojver

GOMEZ Henri wrote:
 
 Hi to all,
 
 I'm back from hollidays :(

Welcome back! Hope you had a good one...

 After finally getting over the 'graceful restart' issues...
 
 Could you developp it more please ?

This is related to the previous thread Problem with mod_jk 1.2.0
(latest CVS snapshot) where mod_jk would pass NULL or incorrect
pointers to some functions after graceful restart of Apache. You'll find
a few 'gdb where' dumps in the thread. I'm not certain is this problem
has actually been fixed or did it just 'accidentally' become something
else...

 Is this for some reason a 'forbidden' combination? I've observed some
 really strange stuff going on with this combo - parameters don't get
 passed correctly, even session stuff tends to be screwed (ie. same
 session data appears in two totally different browsers).
 
 Is this something that's known not to work or did I just screw things
 up? Things work just fine when mod_jk shipped with TC 3.3 B1
 is used. Is
 mod_jk 1.2.0 only to be used with the latest TC 3.3 CVS snapshot?
 
 mod_jk in JTC is an evolution of mod_jk in CVS. Some refactoring
 was done to share code between ajp13 and ajp14.

 If this is not a known thing, I can send some more data...
 
 Yes, please, strace could help in that case.

OK. I'll run up a few examples and send you the strace.

Bojan



mod_jk is great : WAS: Is anyone working on iPlanet integration?

2001-08-20 Thread GOMEZ Henri

 Craig wrote :

Of course, Costin neglects to mention that, approximately a year ago,
there were exactly zero Tomcat committers that understook mod_jk at all --
and that it took some heroic efforts on the part of many folks who came
along later (to whom the entire Tomcat community is grateful!!!) to get
mod_jk to the point where it could be understood and maintained.

I was allready working on mod_jk, one year ago, code revue, fixes and 
understanding of internals. If someone like me, which could spend no more 
than 5/6 hour by weeks, could learn mod_jk, I'm sure that OpenSource 
professionals could master that piece of code in days.

I'm working on mod_jk, when time permit, and will continue on ajp14 and 
autoconf even if now the remaining parts are mainly java code to be
deployed.

mod_jk is really a great piece of code with its workers concept 
and abstraction of web-server hosting it. 

Gal does an amazing works and it's design is still valid and efficient
today. And that design is usable on just ALL web-servers available todays,
IIS, NES/IPLANET, APACHE 1.3/2.0, DOMINO.

It's really sad to not choose it to handle webapp protocol 
(originally called ajp20) and so having to reinvent the wheel. 

But maybe somedays a contributor will add webapp protocol support
to mod_jk and will close the discussion ;)




RE: System.err.println

2001-08-20 Thread Rob S.

Hi Kenny,

tomcat-user is the place where this message should have been sent.  Please
don't send your message to both lists for questions in the future, unless it
affects both users and developers.  Thanks =)

- r

 -Original Message-
 From: Kenny Ma [mailto:[EMAIL PROTECTED]]
 Sent: Sunday, August 19, 2001 11:48 PM
 To: [EMAIL PROTECTED]
 Subject: System.err.println


 I am using Tomcat 3.2.3/Redhat 7.1

 I have a servlet program, the program line 1 is System.err.println(TEST)

 when i run the servlet, the output goes into console

 I want the err.println output to a file
 (/usr/local/apache/logs/error_log),
 what can I do ?
 or how to config Tomcat ?


 /* Kenny Ma
[EMAIL PROTECTED] */






RE: Tomcat startup script

2001-08-20 Thread Larry Isaacs

I'll try to make sure some additional information gets added
to the FAQ, comments in tomcat.bat/tomcat.sh, and
tomcat_ug.html.

Larry

 -Original Message-
 From: Christopher Cain [mailto:[EMAIL PROTECTED]]
 Sent: Sunday, August 19, 2001 8:41 PM
 To: [EMAIL PROTECTED]
 Subject: Re: Tomcat startup script
 
 
 Quoting Christopher Cain [EMAIL PROTECTED]:
 
  That's a cool idea, IMHO.
 
 With the option to not run HotSpot, as pointed out. Craig and 
 Larry/Costin, if 
 I wanted to add a small one-liner to a doc file pointing this 
 out. I hadn't 
 thought of it myself, and I'm not positive that I would have 
 thought of using 
 the *_OPTS variables to do it, so alot of other people might 
 find it useful. 
 Which doc file do you think it makes sense in? For 4.0, 
 RUNNING.txt maybe? For 
 3.3, README.txt maybe?
 
 Props to Bojan ... it hadn't even occurred to me to set 
 Tomcat to use HotSpot =)
 
 - Christopher
 



RE: New SSL HOWTOs

2001-08-20 Thread Larry Isaacs



 -Original Message-
 From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
 Sent: Monday, August 20, 2001 5:23 AM
 To: [EMAIL PROTECTED]
 Subject: RE: New SSL HOWTOs
 
 
 That's a good works and we should in with my tomcat-ssl-howto.html :)
 
 There is still things to be mentioned like :
 
 - how to import OpenSSL, Thawte or Verisign WebServer certificates.
 - in case of client authentification, how the stuff works.
  
   2 cases :
 
   You start you're own CA, using openca (www.openca.org) or part of 
   jonama works (www.multimania.com/jonama/). Then you generate both
   client certs and web-server certs with the newly created CA. Don't
   forget to import the CA cert 
 
   You're using Thawte or Verisign or other major CA providers and
   in that case you should import the CA cert.
 
   That kind of question cover about 95% of the question on 
   tomcat-ssl-howto.html and I saw with your works a great occasion 
   to have a better documentation : 
 
   What about merging ?

+1.  If one or both of you could work on that, I could keep working
on other documentation. Any help would be appreciated.

Larry

 
  
 
 -
 Henri Gomez ___[_]
 EMAIL : [EMAIL PROTECTED](. .) 
 PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
 PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 
 
 
 
 -Original Message-
 From: Christopher Cain [mailto:[EMAIL PROTECTED]]
 Sent: Thursday, August 16, 2001 8:12 PM
 To: Tomcat-Dev
 Subject: New SSL HOWTOs
 
 
 While creating the 3.3 version of my SSL HOWTO, I also 
 polished off the
 wording here and there and added a TOC and section marks for easier
 navigation. Attached are both the 3.3 and 4.0 versions of the file.
 Consider this 4.0 version to supercede the one I sent last night (or
 early this morning, as it were :-)
 
 If someone could please let me know for sure that adding 
 extension JARs
 to the {JDK_HOME}/jre/lib/ext directory under JDK 1.1.8 effectively
 makes them installed extensions (makes them available without
 necessarily being in the CLASSPATH) just like in = JDK 1.2. 
 Other than
 that, I'm pretty sure the TC 3.3 version of the doc is valid for JDK
 1.1.8 environments as well. If someone a little more familiar 
 with 1.1.8
 could maybe give it a quick once-over and see if anything jumps out,
 that would be great.
 
 - Christopher
 
 



RE: Connection aborted by peer: socket write error

2001-08-20 Thread Ng Aik Teong

it cause by  a bug in
org/apache/tomcat/code/BufferedServletOutputStream.java
 
there is a cicular buffer  where it set to 8k, when the html file which have
included  files which  size is
more  then 8k , the above message will occur. 
the cicular buffer was not reset after commit.
Below is the source .
 
   public void recycle() {
 //  System.out.println(Recycle BOS  );
 bufferCount = 0;
 totalCount = 0;
 closed = false;
usingWriter = false;
resA.setBufferCommitted(false);  // this is missing in the source.
}




RE: Sources in Binary Distributions

2001-08-20 Thread GOMEZ Henri

A little late +1 

Thanks to remove sources from binaries :)

That's how the majority of OSS projects works today.

 Source - binaries (eventually packaging like RPM/DEB)

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Saturday, July 28, 2001 1:18 AM
To: [EMAIL PROTECTED]
Subject: Re: Sources in Binary Distributions




On Fri, 27 Jul 2001, Christopher Cain wrote:

 
 On a related topic, I was a little surprised to find a 
source directory
 in my dist build.

Well, ant dist ***is*** how binary distributions (for both 
the nightly
builds and releases) are created, so this should not be too much of a
surprise :-).

Craig McClanahan




Re: Sources in Binary Distributions

2001-08-20 Thread Rob S.

ducks from possible continuance of this thread

=)

- r

On Mon, 20 Aug 2001 14:55:39 +0200 [EMAIL PROTECTED] wrote:
 A little late +1
 
 Thanks to remove sources from binaries :)
 
 That's how the majority of OSS projects works today.
 
  Source - binaries (eventually packaging like RPM/DEB)
 
 -
 Henri Gomez   ___[_]
 EMAIL : [EMAIL PROTECTED]  (. .)
 PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
 PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
 
 
 
 -Original Message-
 From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
 Sent: Saturday, July 28, 2001 1:18 AM
 To: [EMAIL PROTECTED]
 Subject: Re: Sources in Binary Distributions
 
 
 
 
 On Fri, 27 Jul 2001, Christopher Cain wrote:
 
 
  On a related topic, I was a little surprised to find a
 source directory
  in my dist build.
 
 Well, ant dist ***is*** how binary distributions (for both
 the nightly
 builds and releases) are created, so this should not be too much of a
 surprise :-).
 
 Craig McClanahan
 






RE: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix

2001-08-20 Thread GOMEZ Henri

What the status of that one about a week later ?

I recall the discussions some months ago about replacing
the previous uri with unparsed_uri.

Did we have a way to determine that the uri came from 
mod_rewrite and not from client (via the notes). 
In that case what about using r-uri instead of r-unparsed_uri ?

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



-Original Message-
From: Bill Barker [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 15, 2001 9:51 PM
To: [EMAIL PROTECTED]
Subject: Re: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix


1.3.17 (with negotiation_module removed to prevent that problem).
- Original Message -
From: [EMAIL PROTECTED]
To: Bill Barker [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, August 15, 2001 1:01 PM
Subject: Re: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix


 Apache2.0 + mod_jk + JNI + tc3.3 gives me the correct answer,
 404 ( with the correct URI - /?A=B.jsp ). Note that typing
 the unencoded version is returning the correct answer too, i.e.
 index.html.

 What version of apache are you using ?

 Costin



 On Wed, 15 Aug 2001, Bill Barker wrote:

  It is actually worse than that.  TC3.3B1 (with the mod_jk 
that it ships
  with, I haven't tried j-t-c yet) gives a directory listing 
in response
to:
  http://myserver/%3f%41%3d%42.jsp
  - Original Message -
  From: [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]; Bill Barker
  [EMAIL PROTECTED]
  Sent: Wednesday, August 15, 2001 11:44 AM
  Subject: Re: [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix
 
 
   On Wed, 15 Aug 2001, Bill Barker wrote:
  
Personally, I agree with Justin and Costin that mod_jk 
should be
able to
  use
the uri field.
   
Having said that, I'd like to point out that the 
mod_jk.c in j-t-c
is
flat-out broken.  It doesn't handle the case where the 
'?' itself is
encoded.  Since this case is part of a currently 
popular attack on
IIS,
  it
will show up.
  
   Interesting finding. However tomcat decoder should be 
able to do so -
if
   it doesn't we must fix it. Can you check against 3.3beta1 ?
  
   As a note, IMHO it is perfectly legal to have an encoded 
'?' in the
URI,
   and the behavior should be: the '?' will be decoded 
_after_ the URI is
   separated from query string, and it's used as part of 
the file name.
  
   AFAIK there is no reason a file ( or pathInfo ) can't 
have the '?'
char
   inside, and the URI spec allow that.
  
   ( of course, paranoia may force us to remove this kind 
of behavior ).
  
   Costin
  
  
  
  
 







RE: [VOTE] Sources in Binary Distributions

2001-08-20 Thread GOMEZ Henri


Jean-frederic wrote :

Well, if in 10 years I have to do some maintenance at a 
customer it would be
nice to have the sources with the running system. But I am not 
sure that a
customer will also have the source of his applications...

That's all the power of packaging method like RPM, 
separating products (exec, requisite and installation) 
and how to build it ;)

FYI, the source are never included in binary RPMS and
I never install them in my RPMs (jakarta, xml, httpd).
The Source RPM (.SRPM) contains the released source(s),
patches if needed, and initconfig files. And of course
show how to build the binary package :)




Re: New SSL HOWTOs

2001-08-20 Thread Christopher Cain

No problem.

Henri, if you could please send me the html file you have, I'll
integrate it with the what I had :)

For the 4.0 doc, I'll send a patch aagainst what was already checked
into cvs.

For 3.3 ... Larry, have you made any mods yet to the original doc I sent
(like perhaps the JDK 1.1 installed extension issue)? If not, I'll just
send along a new version of the doc with all relevant mods. If so, could
you please shoot me a copy of the doc as it sits now, and I'll integrate
Henri's doc with that.

- Christopher

Larry Isaacs wrote:
 
  -Original Message-
  From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
  Sent: Monday, August 20, 2001 5:23 AM
  To: [EMAIL PROTECTED]
  Subject: RE: New SSL HOWTOs
 
 
  That's a good works and we should in with my tomcat-ssl-howto.html :)
 
  There is still things to be mentioned like :
 
  - how to import OpenSSL, Thawte or Verisign WebServer certificates.
  - in case of client authentification, how the stuff works.
 
2 cases :
 
You start you're own CA, using openca (www.openca.org) or part of
jonama works (www.multimania.com/jonama/). Then you generate both
client certs and web-server certs with the newly created CA. Don't
forget to import the CA cert 
 
You're using Thawte or Verisign or other major CA providers and
in that case you should import the CA cert.
 
That kind of question cover about 95% of the question on
tomcat-ssl-howto.html and I saw with your works a great occasion
to have a better documentation :
 
What about merging ?
 
 +1.  If one or both of you could work on that, I could keep working
 on other documentation. Any help would be appreciated.
 
 Larry



RE: New SSL HOWTOs

2001-08-20 Thread Curtis Dougherty

Chris -

I may be the biggest idiot on the planet but I have Read and Re-Read the SSL
How-2 for Tomcat 4 - honestly... it reads exactly like the REM'arks in the
Server.xml...The problem is not the content... but Tomcat 4 b6 just doesn't
want to use SSL (https://localhost:8443/examples)

Poof!  broken...

:(

cd

-Original Message-
From: Christopher Cain [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 20, 2001 10:18 AM
To: [EMAIL PROTECTED]
Subject: Re: New SSL HOWTOs


No problem.

Henri, if you could please send me the html file you have, I'll
integrate it with the what I had :)

For the 4.0 doc, I'll send a patch aagainst what was already checked
into cvs.

For 3.3 ... Larry, have you made any mods yet to the original doc I sent
(like perhaps the JDK 1.1 installed extension issue)? If not, I'll just
send along a new version of the doc with all relevant mods. If so, could
you please shoot me a copy of the doc as it sits now, and I'll integrate
Henri's doc with that.

- Christopher

Larry Isaacs wrote:
 
  -Original Message-
  From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
  Sent: Monday, August 20, 2001 5:23 AM
  To: [EMAIL PROTECTED]
  Subject: RE: New SSL HOWTOs
 
 
  That's a good works and we should in with my tomcat-ssl-howto.html :)
 
  There is still things to be mentioned like :
 
  - how to import OpenSSL, Thawte or Verisign WebServer certificates.
  - in case of client authentification, how the stuff works.
 
2 cases :
 
You start you're own CA, using openca (www.openca.org) or part of
jonama works (www.multimania.com/jonama/). Then you generate both
client certs and web-server certs with the newly created CA. Don't
forget to import the CA cert 
 
You're using Thawte or Verisign or other major CA providers and
in that case you should import the CA cert.
 
That kind of question cover about 95% of the question on
tomcat-ssl-howto.html and I saw with your works a great occasion
to have a better documentation :
 
What about merging ?
 
 +1.  If one or both of you could work on that, I could keep working
 on other documentation. Any help would be appreciated.
 
 Larry



RE: New SSL HOWTOs

2001-08-20 Thread Larry Isaacs

I enjoyed reading it, but haven't attempted any modifications.

I believe the document Henri is referencing is in CVS for
jakarta-tomcat at src/doc/tomcat-ssl-howto.html  Understanding
the issues with respect to merging these is the main reason
I haven't done much with your document yet.

Larry

 -Original Message-
 From: Christopher Cain [mailto:[EMAIL PROTECTED]]
 Sent: Monday, August 20, 2001 11:18 AM
 To: [EMAIL PROTECTED]
 Subject: Re: New SSL HOWTOs
 
 
 No problem.
 
 Henri, if you could please send me the html file you have, I'll
 integrate it with the what I had :)
 
 For the 4.0 doc, I'll send a patch aagainst what was already checked
 into cvs.
 
 For 3.3 ... Larry, have you made any mods yet to the original 
 doc I sent
 (like perhaps the JDK 1.1 installed extension issue)? If not, 
 I'll just
 send along a new version of the doc with all relevant mods. 
 If so, could
 you please shoot me a copy of the doc as it sits now, and 
 I'll integrate
 Henri's doc with that.
 
 - Christopher
 
 Larry Isaacs wrote:
  
   -Original Message-
   From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
   Sent: Monday, August 20, 2001 5:23 AM
   To: [EMAIL PROTECTED]
   Subject: RE: New SSL HOWTOs
  
  
   That's a good works and we should in with my 
 tomcat-ssl-howto.html :)
  
   There is still things to be mentioned like :
  
   - how to import OpenSSL, Thawte or Verisign WebServer 
 certificates.
   - in case of client authentification, how the stuff works.
  
 2 cases :
  
 You start you're own CA, using openca (www.openca.org) 
 or part of
 jonama works (www.multimania.com/jonama/). Then you 
 generate both
 client certs and web-server certs with the newly 
 created CA. Don't
 forget to import the CA cert 
  
 You're using Thawte or Verisign or other major CA providers and
 in that case you should import the CA cert.
  
 That kind of question cover about 95% of the question on
 tomcat-ssl-howto.html and I saw with your works a great occasion
 to have a better documentation :
  
 What about merging ?
  
  +1.  If one or both of you could work on that, I could keep working
  on other documentation. Any help would be appreciated.
  
  Larry
 



LICENSE copyright dates

2001-08-20 Thread Rob S.

I dunno squat about this stuff, so kindly delete this email if it's irrelevant =)

The (c) in $CATALINA_HOME/LICENSE currently reads:

Copyright (c) 1999, 2000  The Apache Software Foundation.

Should there be a 2001 there?

- r




Session destruction bug - Tomcat 3.3-b1.

2001-08-20 Thread Prasanna Uppaladadium

Hello.

There is a bug related to destroying session objects in Tomcat 3.3.b1.

Bug description


The valueUnbound() method is never called on attributes that are set on
a given session even if the attribute implements the
HttpSessionBindingListener interface.

Hypothesis


A session is abstracted by an instance of the class ServerSession in
package org.apache.tomcat.core. A ServerSession object has with it a set
(an array) of BaseInterceptors. When the ServerSession is timed out, its
setState(int state) method is called. This method iterates over the
array of BaseInterceptors and calls the method sessionState(Request
request, ServerSession session, int state). The order in which the
method is called for the set of registered BaseInterceptors is as
follows:

1.  org.apache.tomcat.modules.config.PathSetter
2. org.apache.tomcat.modules.config.ServerXmlReader
3.  org.apache.tomcat.modules.session.SessionExpirer
4.  org.apache.tomcat.modules.session.SessionIdGenerator
5. org.apache.tomcat.modules.session.SimpleSessionStore
6. org.apache.tomcat.facade.Servlet22Interceptor

The problem arises in the last 2 calls. When the SimpleSessionStore's
sessionState(...) method is called, it recycles the ServerSession object
- the implementation calls the recycle() method on the ServerSession
object. The implementation of recycle() on ServerSession clears all the
registered attributes!

The implementation of sessionState(...) on Servlet22Interceptor attempts
to loop through the set of attributes on the ServerSession object and
calls the valueUnbound() mehod if it finds instances of
HttpSessionBindingListener implementations. However, when the method
gets called, it never finds any attributes on the session [obviously
because they were just removed SimpleSessionStore.setState(...)].

I am not sure if this bug has been fixed - I am pretty sure that the bug
existed in release 3.2.3 of Tomcat as well.

Fix


I am not sure what the correct fix for the bug is. I will leave it to
the experts on this list to sort it out. For the moment, I am commenting
out the call to ServerSession.recycle() in
SimpleSessionStore.sessionState(...). Any pointers to the correct fix
will be appreciated.

Thanks,
Prasanna.





RE: New SSL HOWTOs

2001-08-20 Thread GOMEZ Henri

I'll update that doc since there is change in server.xml
between 3.2 and 3.3 and my HOW-TO cover the both :)

Hope it'll be ready tomorrow...

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



-Original Message-
From: Larry Isaacs [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 20, 2001 5:30 PM
To: '[EMAIL PROTECTED]'
Subject: RE: New SSL HOWTOs


I enjoyed reading it, but haven't attempted any modifications.

I believe the document Henri is referencing is in CVS for
jakarta-tomcat at src/doc/tomcat-ssl-howto.html  Understanding
the issues with respect to merging these is the main reason
I haven't done much with your document yet.

Larry

 -Original Message-
 From: Christopher Cain [mailto:[EMAIL PROTECTED]]
 Sent: Monday, August 20, 2001 11:18 AM
 To: [EMAIL PROTECTED]
 Subject: Re: New SSL HOWTOs
 
 
 No problem.
 
 Henri, if you could please send me the html file you have, I'll
 integrate it with the what I had :)
 
 For the 4.0 doc, I'll send a patch aagainst what was already checked
 into cvs.
 
 For 3.3 ... Larry, have you made any mods yet to the original 
 doc I sent
 (like perhaps the JDK 1.1 installed extension issue)? If not, 
 I'll just
 send along a new version of the doc with all relevant mods. 
 If so, could
 you please shoot me a copy of the doc as it sits now, and 
 I'll integrate
 Henri's doc with that.
 
 - Christopher
 
 Larry Isaacs wrote:
  
   -Original Message-
   From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
   Sent: Monday, August 20, 2001 5:23 AM
   To: [EMAIL PROTECTED]
   Subject: RE: New SSL HOWTOs
  
  
   That's a good works and we should in with my 
 tomcat-ssl-howto.html :)
  
   There is still things to be mentioned like :
  
   - how to import OpenSSL, Thawte or Verisign WebServer 
 certificates.
   - in case of client authentification, how the stuff works.
  
 2 cases :
  
 You start you're own CA, using openca (www.openca.org) 
 or part of
 jonama works (www.multimania.com/jonama/). Then you 
 generate both
 client certs and web-server certs with the newly 
 created CA. Don't
 forget to import the CA cert 
  
 You're using Thawte or Verisign or other major CA providers and
 in that case you should import the CA cert.
  
 That kind of question cover about 95% of the question on
 tomcat-ssl-howto.html and I saw with your works a 
great occasion
 to have a better documentation :
  
 What about merging ?
  
  +1.  If one or both of you could work on that, I could keep working
  on other documentation. Any help would be appreciated.
  
  Larry
 




cvs commit: jakarta-tomcat/src/doc tomcat-ssl-howto.html

2001-08-20 Thread hgomez

hgomez  01/08/20 09:11:09

  Modified:src/doc  tomcat-ssl-howto.html
  Log:
  Updated documentation about SSL to handle TC 3.3
  new conf and add example of keytool use :)
  
  Revision  ChangesPath
  1.5   +384 -270  jakarta-tomcat/src/doc/tomcat-ssl-howto.html
  
  Index: tomcat-ssl-howto.html
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/doc/tomcat-ssl-howto.html,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- tomcat-ssl-howto.html 2001/06/13 09:27:00 1.4
  +++ tomcat-ssl-howto.html 2001/08/20 16:11:09 1.5
  @@ -1,270 +1,384 @@
  -html
  -head
  -!-- $Id  $ --
  -!-- Copyright 1999, Apache Software Foundation --
  -
  -meta http-equiv=Content-Type content=text/html
  -link rel=stylesheet href=style.css
  -style type=text/css
  -.inlinetd {
  -background-color: #E0E0E0;
  -vertical-align: text-top;
  -border-top: thick black;
  -border-right: thick black;
  -border-bottom: thick black;
  -border-left: thick black;
  -}
  -.inlineth {
  -background-color: #d0d0d0;
  -border-top: thick black;
  -border-right: thick black;
  -border-bottom: thick black;
  -border-left: thick black;
  -}
  -.inlinetable {
  -width: 75%;
  -border: thick;
  -background-color: #00;
  -}
  -.subsection { margin:20pt; }
  -.note { margin:20pt; padding:5pt; background-color:#e0e0ff; }
  -
  -/style
  -
  -titleTomcat and SSL/title
  -/head
  -
  -body
  -!-- Banner element, all hail the Project! -- 
  -table border=0 width=100% cellspacing=0 cellpadding=0
  -  tr 
  -td width=50% align=left a href=http://jakarta.apache.org/index.html; 
  -  img src=uguide/images/banner.gif width=350 height=100 alt=The Jakarta 
Project border=0 
  -  /a /td
  -td width=50% align=right img border=0 src=uguide/images/tomcat.gif 
width=100 height=71 alt=The mighty Tomcat - Meow! 
  -/td
  -  /tr
  -/table
  -h1Tomcat and SSL/h1
  -pBy Gomez Henri ttlt;a 
href=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/agt;/tt/p
  -h2Table of Contents/h2
  -ul
  -  lia href=#s2Tomcat and SSL/a/li
  -  lia href=#s3Building tomcat with SSL support/a/li
  -  lia href=#s4Tomcat with Apache and mod_jk/a/li
  -  lia href=#s5SSL via apache/a/li
  -  lia href=#s6SSL direct/a/li
  -  lia href=#s7Credits/a/li
  -/ul
  -hr
  -h2a name=s2Tomcat and SSL/a/h2
  -pTomcat could use SSL directly (via an HTTP connector supporting SSL) or via 
  -  an Apache SSLified (a href=http://www.apache-ssl.org;Apache-SSL/a or 
apache-mod_ssl) 
  -  with the mod_jk connector./p
  -hr
  -h2a name=s3Building tomcat with SSL support/a/h2
  -pIf you want to rebuild the tomcat with SSL, be carefull of your CLASSPATH. 
  -  I used to clear the CLASSPATH env var to avoid conflict in jar. A common case 
  -  of conflict is for XML parsers (xerces  jaxp). tomcat need a recent XML parser 
  -  like Apache Group xerces 1.1.2 or Sun's jaxp 1.0.1./p
  -pAt build time, (via ant), tomcat will check for some libs and will then included 

  -  more or less options. It's the case of SSL support. If you have the JSSE 1.0.2 
  -  jars in your CLASSPATH, tomcat will be built with SSL (SSLSocketFactory). tomcat 
  -  will use the JSSE jars (jcert.jar, jsse.jar, jnet.jar).This software COULDN'T 
  -  BE INCLUDED in tomcat. You'll have to go to a 
href=http://java.sun.com/products/jsse/%20;jsse 
  -  home page /aand download from there the domestic (US/Canada) or global archive. 

  -  Then copy the 3 jars in tomcat runtime classpath lib ($TOMCAT_HOME/lib)./p
  -hr
  -h2a name=s4Tomcat with Apache and mod_jk/a/h2
  -pIf you use Apache with SSL (apache-ssl or apache-mod_ssl), the apache connector 
  -  mod_jk will be able to forward to tomcat some SSL informations if JkExtractSSL 
  -  directive is present in your httpd.conf. /p
  -pInformations are :/p
  -table width=75% border=1
  -  tr 
  -tdHTTPS/td
  -tdapache redirect to tomcat from an SSL area/td
  -  /tr
  -  tr 
  -tdSSL_SESSION_ID/td
  -tdSSL session ID/td
  -  /tr
  -  tr 
  -tdSSL_CIPHER/td
  -tdSSL CIPHER used/td
  -  /tr
  -  tr 
  -tdSSL_CLIENT_CERT/td
  -tdSSL Certificate of client/td
  -  /tr
  -/table
  -pSince apache-ssl and apache-mod_ssl use differents env vars, you could adapt 
  -  SSL vars via the following JK vars /p
  -ul
  -  liJkExtractSSL/li
  -  liJkHTTPSIndicator/li
  -  liJkSESSIONIndicator/li
  -  liJkCIPHERIndicator/li
  -  liJkCERTSIndicator: /li
  -/ul
  -phere is an example of directive to include in httpd.conf for use with mod_ssl 
  -/p
  -pfont face=Courier New, Courier, mono size=-1# Should mod_jk send SSL 
  -  information to Tomact (default is On)br
  -  JkExtractSSL 

RE: New SSL HOWTOs

2001-08-20 Thread GOMEZ Henri

No problem.

Henri, if you could please send me the html file you have, I'll
integrate it with the what I had :)

Just updated and commited :)

Nota that file src/doc/tomcat-ssl-howto.html, should be also 
copied in tomcat 3.2 (will do that tomorrow)

Regards 



RE: New SSL HOWTOs

2001-08-20 Thread GOMEZ Henri

Henri, if you could please send me the html file you have, I'll
integrate it with the what I had :)

Will you include your part in my current tomcat-ssl-howto.html 
or doing the reverse ? 

I'd like (better) to see your works in the tomcat-ssl-howto.html :)




Patch to bug #345 complete ?

2001-08-20 Thread Henry Yeh


I have noticed that after applying the patch the date is now
included in the tomcat HTTP response header, but it still
does not send back not modified 304 if the file requested
hasn't been modified since the date specificed by the request ...

anyone has any ideas on how to fix this ? thanks !

Henry




Re: New SSL HOWTOs

2001-08-20 Thread Christopher Cain


Curtis Dougherty wrote:
 
 Chris -
 
 I may be the biggest idiot on the planet

Nah, SSL can just be a little tricky sometimes :)

 but I have Read and Re-Read the SSL How-2 for Tomcat 4 - honestly...
 it reads exactly like the REM'arks in the Server.xml

Well, hopefully it has a *little* more information ;-)

 ...The problem is not the content... but Tomcat 4 b6 just doesn't
 want to use SSL (https://localhost:8443/examples)
 
 Poof!  broken...
 
 :(

Hmmm ... well, referencing that directory would fail if you have
directory listing disabled. Does https://localhost:8443/index.html work?
Try https://localhost:8443/examples/servlets/index.html as well. What
about trying those same addresses with http: as the protocol, just to
verify that your machine is successfully resolving localhost. If that
protocol fails also, then try to ping localhost.

If you're running a *nix system, try using netstat to see whether or
not your machine is listening on 8443. If nothing above helps out,
please let me know your environment (OS, JDK, and TC version) and we'll
look into it a little further.

- Christopher



Re: New SSL HOWTOs

2001-08-20 Thread Christopher Cain


GOMEZ Henri wrote:
 
 Henri, if you could please send me the html file you have, I'll
 integrate it with the what I had :)
 
 Will you include your part in my current tomcat-ssl-howto.html
 or doing the reverse ?
 
 I'd like (better) to see your works in the tomcat-ssl-howto.html :)

Apologies to both Larry and Heni. I wasn't even aware that there was
already an SSL doc in the 3.x tree. D'oh!

In any case, my doc should definitely be integrated into
tomcat-ssl-howto.html instead of the other way around. Your doc has
historic precedence for the users =)

I'll go ahead and work my stuff into it this morning, and I'll post the
(proposed) result a little later today.

- Christopher



Re: Session destruction bug - Tomcat 3.3-b1.

2001-08-20 Thread cmanolache

Hi Prasanna,

I'm impressed with the excelent analysis of the bug, I wish more bugs were
reported this way ! I hope you'll stay around and help with other bugs.

The good news - this bug was fixed after 3.3b1 ( it was already in
bugzilla, but without all those details - it took me a while to find the
problem ). If you build from CVS you should have this fixed, please let me
know if you still have problems. ( and of course, I would be happy to hear
about more bugs from you :-)

Costin





Re: Patch to bug #345 complete ?

2001-08-20 Thread Justin Erenkrantz

On Mon, Aug 20, 2001 at 09:18:53AM -0700, Henry Yeh wrote:
 
 I have noticed that after applying the patch the date is now
 included in the tomcat HTTP response header, but it still
 does not send back not modified 304 if the file requested
 hasn't been modified since the date specificed by the request ...
 
 anyone has any ideas on how to fix this ? thanks !

Are you sending If-Modified-Since?  That doesn't look like it'd work 
in Tomcat.  

The 304 behavior doesn't apply to dynamic data as it is *always* 
regenerated.  So, I'm not even sure if you'd want it.  You definitely
don't want to look at the date on the jsp file as that tells you 
nothing (unlike static content).

Static content is a different story, but if you are serving static files
from Tomcat, you probably want a real HTTP server in front of it.  
-- justin




RE: Patch to bug #345 complete ?

2001-08-20 Thread Henry Yeh


yes. I analyzed the HTTP header that's being sent and received by the
browser.
If-Modified-Since messages are sent to tomcat, and we are dealing with
static files here (javascript and images). 
So is tomcat doesn't have the '304 behavior' for static files ? It does
send back 'last-modified' date information in the header, and that ALWAYS
matches the 'If-modified-since' date. Are we looking at another tomcat 
date bug here ?

thanks,
Henry

-Original Message-
From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 20, 2001 10:11 AM
To: [EMAIL PROTECTED]
Subject: Re: Patch to bug #345 complete ?


On Mon, Aug 20, 2001 at 09:18:53AM -0700, Henry Yeh wrote:
 
 I have noticed that after applying the patch the date is now
 included in the tomcat HTTP response header, but it still
 does not send back not modified 304 if the file requested
 hasn't been modified since the date specificed by the request ...
 
 anyone has any ideas on how to fix this ? thanks !

Are you sending If-Modified-Since?  That doesn't look like it'd work 
in Tomcat.  

The 304 behavior doesn't apply to dynamic data as it is *always* 
regenerated.  So, I'm not even sure if you'd want it.  You definitely
don't want to look at the date on the jsp file as that tells you 
nothing (unlike static content).

Static content is a different story, but if you are serving static files
from Tomcat, you probably want a real HTTP server in front of it.  
-- justin



Re: Patch to bug #345 complete ?

2001-08-20 Thread Justin Erenkrantz

On Mon, Aug 20, 2001 at 10:24:01AM -0700, Henry Yeh wrote:
 
 yes. I analyzed the HTTP header that's being sent and received by the
 browser.
 If-Modified-Since messages are sent to tomcat, and we are dealing with
 static files here (javascript and images). 
 So is tomcat doesn't have the '304 behavior' for static files ? It does
 send back 'last-modified' date information in the header, and that ALWAYS
 matches the 'If-modified-since' date. Are we looking at another tomcat 
 date bug here ?

It's more of a feature that was never written.  Tomcat has no code to
handle If-Modified-Since (based on a quick grep through the source 
code - I could be wrong).  You are welcome to write the code and apply 
it locally.  I'm not sure if it'll make it into the 3.x branch as I 
think it is frozen.  4.x is a possibility for inclusion, however.  (I 
seem to remember that you are using 3.x.)

However, you'll have to be aware that jsp's and servlets must ignore 
If-Modified-Since headers so the implementation can be tricky.  
-- justin




Tomcat on Windows vs. Unix

2001-08-20 Thread Bala Nemani

Hi:

 We are developing a web application using Tomcat 3.1, Oracle DB, JSP, Java
 Servelets using MVC Architecture. All the development and testing is being
 done in Windows platform (Tomcat running on Windows 2000). But customer
 would like to deploy Tomcat on Unix
 
 Are there any known issues that we need to be pay extra attention to? Have
 any one done this kind of deployment? Any help/hints are appreciated
 
 Regards,
 Bala Nemani
 



Re: Patch to bug #345 complete ?

2001-08-20 Thread Craig R. McClanahan

On Mon, 20 Aug 2001, Justin Erenkrantz wrote:

 On Mon, Aug 20, 2001 at 10:24:01AM -0700, Henry Yeh wrote:
  
  yes. I analyzed the HTTP header that's being sent and received by the
  browser.
  If-Modified-Since messages are sent to tomcat, and we are dealing with
  static files here (javascript and images). 
  So is tomcat doesn't have the '304 behavior' for static files ? It does
  send back 'last-modified' date information in the header, and that ALWAYS
  matches the 'If-modified-since' date. Are we looking at another tomcat 
  date bug here ?
 
 It's more of a feature that was never written.  Tomcat has no code to
 handle If-Modified-Since (based on a quick grep through the source 
 code - I could be wrong).  You are welcome to write the code and apply 
 it locally.  I'm not sure if it'll make it into the 3.x branch as I 
 think it is frozen.  4.x is a possibility for inclusion, however.  (I 
 seem to remember that you are using 3.x.)
 
 However, you'll have to be aware that jsp's and servlets must ignore 
 If-Modified-Since headers so the implementation can be tricky.  

I'm not sure I would make quite so blanket a statement as that.  If the
servlet itself understands that the content it produces changes rarely, it
can improve performance by respecting If-Modified-Since values.  To make
this worthwhile, though, it will also need to control the value sent for
the Last-Modified header, which you can do by overriding the
getLastModified() method of HttpServlet.

 -- justin
 
 

For what it's worth, Tomcat 4 stand-alone already correctly handles
If-Modified-Since headers, and sends back not modified responses
appropriately.


Craig




RE: Patch to bug #345 complete ?

2001-08-20 Thread Henry Yeh


where can we add code to actually compare the last modified 
and if-modified-since dates ?

-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 20, 2001 10:55 AM
To: [EMAIL PROTECTED]
Subject: Re: Patch to bug #345 complete ?


On Mon, 20 Aug 2001, Justin Erenkrantz wrote:

 On Mon, Aug 20, 2001 at 10:24:01AM -0700, Henry Yeh wrote:
  
  yes. I analyzed the HTTP header that's being sent and received by the
  browser.
  If-Modified-Since messages are sent to tomcat, and we are dealing with
  static files here (javascript and images). 
  So is tomcat doesn't have the '304 behavior' for static files ? It does
  send back 'last-modified' date information in the header, and that
ALWAYS
  matches the 'If-modified-since' date. Are we looking at another tomcat 
  date bug here ?
 
 It's more of a feature that was never written.  Tomcat has no code to
 handle If-Modified-Since (based on a quick grep through the source 
 code - I could be wrong).  You are welcome to write the code and apply 
 it locally.  I'm not sure if it'll make it into the 3.x branch as I 
 think it is frozen.  4.x is a possibility for inclusion, however.  (I 
 seem to remember that you are using 3.x.)
 
 However, you'll have to be aware that jsp's and servlets must ignore 
 If-Modified-Since headers so the implementation can be tricky.  

I'm not sure I would make quite so blanket a statement as that.  If the
servlet itself understands that the content it produces changes rarely, it
can improve performance by respecting If-Modified-Since values.  To make
this worthwhile, though, it will also need to control the value sent for
the Last-Modified header, which you can do by overriding the
getLastModified() method of HttpServlet.

 -- justin
 
 

For what it's worth, Tomcat 4 stand-alone already correctly handles
If-Modified-Since headers, and sends back not modified responses
appropriately.


Craig



RE: Patch to bug #345 complete ?

2001-08-20 Thread Craig R. McClanahan



On Mon, 20 Aug 2001, Henry Yeh wrote:

 
 where can we add code to actually compare the last modified 
 and if-modified-since dates ?
 

In Tomcat 4, it's inside the servlet that handles static files
(org.apache.catalina.servlets.DefaultServlet) -- I should have clarified
that my statement referred to serving static content only.

For 3.x, you'd have to deal with it in the equivalent functionality (IIRC
it's in an interceptor in 3.2 and in a module in 3.3).

Craig


 -Original Message-
 From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
 Sent: Monday, August 20, 2001 10:55 AM
 To: [EMAIL PROTECTED]
 Subject: Re: Patch to bug #345 complete ?
 
 
 On Mon, 20 Aug 2001, Justin Erenkrantz wrote:
 
  On Mon, Aug 20, 2001 at 10:24:01AM -0700, Henry Yeh wrote:
   
   yes. I analyzed the HTTP header that's being sent and received by the
   browser.
   If-Modified-Since messages are sent to tomcat, and we are dealing with
   static files here (javascript and images). 
   So is tomcat doesn't have the '304 behavior' for static files ? It does
   send back 'last-modified' date information in the header, and that
 ALWAYS
   matches the 'If-modified-since' date. Are we looking at another tomcat 
   date bug here ?
  
  It's more of a feature that was never written.  Tomcat has no code to
  handle If-Modified-Since (based on a quick grep through the source 
  code - I could be wrong).  You are welcome to write the code and apply 
  it locally.  I'm not sure if it'll make it into the 3.x branch as I 
  think it is frozen.  4.x is a possibility for inclusion, however.  (I 
  seem to remember that you are using 3.x.)
  
  However, you'll have to be aware that jsp's and servlets must ignore 
  If-Modified-Since headers so the implementation can be tricky.  
 
 I'm not sure I would make quite so blanket a statement as that.  If the
 servlet itself understands that the content it produces changes rarely, it
 can improve performance by respecting If-Modified-Since values.  To make
 this worthwhile, though, it will also need to control the value sent for
 the Last-Modified header, which you can do by overriding the
 getLastModified() method of HttpServlet.
 
  -- justin
  
  
 
 For what it's worth, Tomcat 4 stand-alone already correctly handles
 If-Modified-Since headers, and sends back not modified responses
 appropriately.
 
 
 Craig
 




Re: Tomcat on Windows vs. Unix

2001-08-20 Thread mailtracker

1.  keep in mind the differences in naming conventions on Windows and Unix:
backslashes and forward slashes, case-sensitivity, end-of-line
characters
(files created on Windows, if not transferred properly, will appear on Unix
with every line terminated with a ^M)

2. Why not use the latest release version of Tomcat, 3.2.3?  Is there a
compelling reason to stay with the 3.1 branch?


 From: Bala Nemani [EMAIL PROTECTED]
 Reply-To: [EMAIL PROTECTED]
 Date: Mon, 20 Aug 2001 13:51:32 -0400
 To: '[EMAIL PROTECTED]' [EMAIL PROTECTED]
 Subject: Tomcat on Windows vs. Unix
 
 Hi:
 
 We are developing a web application using Tomcat 3.1, Oracle DB, JSP, Java
 Servelets using MVC Architecture. All the development and testing is being
 done in Windows platform (Tomcat running on Windows 2000). But customer
 would like to deploy Tomcat on Unix
 
 Are there any known issues that we need to be pay extra attention to? Have
 any one done this kind of deployment? Any help/hints are appreciated
 
 Regards,
 Bala Nemani
 




[PATCH] Minor doc typo

2001-08-20 Thread Christopher Cain

;-)
 ssl-howto.patch


Re: Patch to bug #345 complete ?

2001-08-20 Thread Justin Erenkrantz

On Mon, Aug 20, 2001 at 10:54:43AM -0700, Craig R. McClanahan wrote:
 I'm not sure I would make quite so blanket a statement as that.  If the
 servlet itself understands that the content it produces changes rarely, it
 can improve performance by respecting If-Modified-Since values.  To make
 this worthwhile, though, it will also need to control the value sent for
 the Last-Modified header, which you can do by overriding the
 getLastModified() method of HttpServlet.

True - you are correct.  But, this wouldn't be something that Tomcat 
could do by default - this would require that the servlet itself 
handle this and have appropriate logic via getLastModified().  
The servlet can handle it, but that's user code not Tomcat code.  
-- justin




RE: Patch to bug #345 complete ?

2001-08-20 Thread Henry Yeh


so this #345 bug fix which sends date in the header in the HTTP
response. Is there any use to this date at all ?

-Original Message-
From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 20, 2001 11:27 AM
To: [EMAIL PROTECTED]
Subject: Re: Patch to bug #345 complete ?


On Mon, Aug 20, 2001 at 10:54:43AM -0700, Craig R. McClanahan wrote:
 I'm not sure I would make quite so blanket a statement as that.  If the
 servlet itself understands that the content it produces changes rarely, it
 can improve performance by respecting If-Modified-Since values.  To make
 this worthwhile, though, it will also need to control the value sent for
 the Last-Modified header, which you can do by overriding the
 getLastModified() method of HttpServlet.

True - you are correct.  But, this wouldn't be something that Tomcat 
could do by default - this would require that the servlet itself 
handle this and have appropriate logic via getLastModified().  
The servlet can handle it, but that's user code not Tomcat code.  
-- justin



Re: JSP Document parsing

2001-08-20 Thread Mark Abbott

Hi again - since no one voiced an opinion on the right way to 
approach this bug, I've done the simplest possible fix and attached a patch. 

This change will cause Jasper to always emit its own hardcoded values 
for the xmlns:jsp and version attributes of the jsp:root tag, ignoring any 
occurrences of those attributes in documents. This makes processing of 
JSP documents consistent whether they were specified in XML or JSP 
syntax. I also made the trivial fix to the double end tag problem.

I suspect that a more elaborate solution might be desirable for the version 
attribute, since if the document says it is version 1.3 (when we have such 
a version), but the compiler only handles 1.2, this ought to indicate a 
problem. But I'm not sure how to do that at this point, so this patch gets 
past the immediate problems that make valid documents unusable.

Cheers - Mark

Index: XmlOutputter.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/XmlOutputter.java,v
retrieving revision 1.15
diff -u -p --unified=5 -r1.15 XmlOutputter.java
--- XmlOutputter.java   2001/07/25 01:49:10 1.15
+++ XmlOutputter.java   2001/08/20 18:14:35
@@ -126,12 +126,12 @@ public class XmlOutputter {
 void addRootAttrs(Attributes attrs) {
jspRootLevel++;
 int attrsLength = attrs.getLength();
 for (int i = 0; i  attrsLength; i++) {
String qName = attrs.getQName(i);
-   if (attrs.getQName(i).startsWith(xmlns:jsp) 
-jspRootLevel  1) continue; 
+   if ((qName.startsWith(xmlns:jsp) || 
+qName.equals(version))) continue; 
 rootAttrs.addAttribute(attrs.getURI(i), attrs.getLocalName(i),
 attrs.getQName(i), attrs.getType(i), attrs.getValue(i));
 }
 }
 
@@ -142,18 +142,15 @@ public class XmlOutputter {
 rootAttrs.addAttribute(, xmlns, xmlns: + prefix, CDATA, uri);
  }
 
 
 /*
- * Only put the /jsp:root tag when we're dealing
- * with the top level 'container' page.
+ * Don't append the root end tag here because the
+ * getPageData method will append it later.
  */
 void rootEnd() {
jspRootLevel--;
-   if (jspRootLevel == 0) {
-   append(jsp:root);
-   }
 }
 
 /**
  * Append the cdata to the XML stream.
  */



Re: Patch to bug #345 complete ?

2001-08-20 Thread Craig R. McClanahan



On Mon, 20 Aug 2001, Justin Erenkrantz wrote:

 On Mon, Aug 20, 2001 at 10:54:43AM -0700, Craig R. McClanahan wrote:
  I'm not sure I would make quite so blanket a statement as that.  If the
  servlet itself understands that the content it produces changes rarely, it
  can improve performance by respecting If-Modified-Since values.  To make
  this worthwhile, though, it will also need to control the value sent for
  the Last-Modified header, which you can do by overriding the
  getLastModified() method of HttpServlet.
 
 True - you are correct.  But, this wouldn't be something that Tomcat 
 could do by default - this would require that the servlet itself 
 handle this and have appropriate logic via getLastModified().  
 The servlet can handle it, but that's user code not Tomcat code.  

Agreed.

On my earlier statement, I should have pointed out that the automatic
handling Tomcat 4 does is when serving static resources only.

 -- justin
 
 

Craig





cvs commit: jakarta-tomcat-4.0/catalina/src/bin digest.sh

2001-08-20 Thread bip

bip 01/08/20 11:36:04

  Modified:catalina/src/bin digest.sh
  Log:
  Fix for cygwin.
  
  Submitted by: Stephane Bailliez [[EMAIL PROTECTED]]
  
  Revision  ChangesPath
  1.2   +14 -1 jakarta-tomcat-4.0/catalina/src/bin/digest.sh
  
  Index: digest.sh
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/bin/digest.sh,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- digest.sh 2001/05/22 20:37:21 1.1
  +++ digest.sh 2001/08/20 18:36:04 1.2
  @@ -10,7 +10,7 @@
   #   This script is assumed to run from the bin directory or have the
   #   CATALINA_HOME env variable set.
   #
  -# $Id: digest.sh,v 1.1 2001/05/22 20:37:21 bip Exp $
  +# $Id: digest.sh,v 1.2 2001/08/20 18:36:04 bip Exp $
   # -
   
   
  @@ -45,6 +45,19 @@
   fi
   
   # - Set Up The System Classpath ---
  +# Cygwin support.  $cygwin _must_ be set to either true or false.
  +case `uname` in
  +  CYGWIN*) cygwin=true ;;
  +  *) cygwin=false ;;
  +esac
  + 
  +# For Cygwin, ensure paths are in UNIX format before anything is touched
  +if $cygwin ; then
  +  [ -n $CATALINA_HOME ] 
  +CATALINA_HOME=`cygpath --unix $CATALINA_HOME`
  +[ -n $JAVA_HOME ] 
  +JAVA_HOME=`cygpath --unix $JAVA_HOME`
  +fi
   
   CP=$CATALINA_HOME/server/lib/catalina.jar
   
  
  
  



RE: [PATCH] TC4 shell Scripts

2001-08-20 Thread Bip Thelin

 -Original Message-
 From: Stephane Bailliez [mailto:[EMAIL PROTECTED]] 
 
 Fixed some bugs that prevented its use under cygwin.

Can someone with cygwin try out the catalina.sh diff, I commited
the digest.sh diff.

Thanks, Bip Thelin



Re: Patch to bug #345 complete ?

2001-08-20 Thread Bill Barker

It looks like 3.3B1 already handles 304
(o.a.tomcat.modules.generators.StaticInterceptor).  However, I haven't
actually tested it (static files handled by Apache).
- Original Message -
From: Craig R. McClanahan [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, August 20, 2001 11:13 AM
Subject: RE: Patch to bug #345 complete ?




 On Mon, 20 Aug 2001, Henry Yeh wrote:

 
  where can we add code to actually compare the last modified
  and if-modified-since dates ?
 

 In Tomcat 4, it's inside the servlet that handles static files
 (org.apache.catalina.servlets.DefaultServlet) -- I should have clarified
 that my statement referred to serving static content only.

 For 3.x, you'd have to deal with it in the equivalent functionality (IIRC
 it's in an interceptor in 3.2 and in a module in 3.3).

 Craig


  -Original Message-
  From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
  Sent: Monday, August 20, 2001 10:55 AM
  To: [EMAIL PROTECTED]
  Subject: Re: Patch to bug #345 complete ?
 
 
  On Mon, 20 Aug 2001, Justin Erenkrantz wrote:
 
   On Mon, Aug 20, 2001 at 10:24:01AM -0700, Henry Yeh wrote:
   
yes. I analyzed the HTTP header that's being sent and received by
the
browser.
If-Modified-Since messages are sent to tomcat, and we are dealing
with
static files here (javascript and images).
So is tomcat doesn't have the '304 behavior' for static files ? It
does
send back 'last-modified' date information in the header, and that
  ALWAYS
matches the 'If-modified-since' date. Are we looking at another
tomcat
date bug here ?
  
   It's more of a feature that was never written.  Tomcat has no code to
   handle If-Modified-Since (based on a quick grep through the source
   code - I could be wrong).  You are welcome to write the code and apply
   it locally.  I'm not sure if it'll make it into the 3.x branch as I
   think it is frozen.  4.x is a possibility for inclusion, however.  (I
   seem to remember that you are using 3.x.)
  
   However, you'll have to be aware that jsp's and servlets must ignore
   If-Modified-Since headers so the implementation can be tricky.
 
  I'm not sure I would make quite so blanket a statement as that.  If the
  servlet itself understands that the content it produces changes rarely,
it
  can improve performance by respecting If-Modified-Since values.  To make
  this worthwhile, though, it will also need to control the value sent for
  the Last-Modified header, which you can do by overriding the
  getLastModified() method of HttpServlet.
 
   -- justin
  
  
 
  For what it's worth, Tomcat 4 stand-alone already correctly handles
  If-Modified-Since headers, and sends back not modified responses
  appropriately.
 
 
  Craig
 






RE: Patch to bug #345 complete ?

2001-08-20 Thread Henry Yeh


does any one have the bug # for the 304 Not Modified bug 
of tomcat ?

thanks,
Henry

-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 20, 2001 11:35 AM
To: [EMAIL PROTECTED]
Subject: Re: Patch to bug #345 complete ?




On Mon, 20 Aug 2001, Justin Erenkrantz wrote:

 On Mon, Aug 20, 2001 at 10:54:43AM -0700, Craig R. McClanahan wrote:
  I'm not sure I would make quite so blanket a statement as that.  If the
  servlet itself understands that the content it produces changes rarely,
it
  can improve performance by respecting If-Modified-Since values.  To make
  this worthwhile, though, it will also need to control the value sent for
  the Last-Modified header, which you can do by overriding the
  getLastModified() method of HttpServlet.
 
 True - you are correct.  But, this wouldn't be something that Tomcat 
 could do by default - this would require that the servlet itself 
 handle this and have appropriate logic via getLastModified().  
 The servlet can handle it, but that's user code not Tomcat code.  

Agreed.

On my earlier statement, I should have pointed out that the automatic
handling Tomcat 4 does is when serving static resources only.

 -- justin
 
 

Craig




RE: Tomcat 3.3 contextAdmin issues

2001-08-20 Thread Costin Manolache

On 20 Aug 2001 02:01:12 +0200, Paulo Gaspar wrote:

 Your explanation sure helps understanding what functionality is intended
 for each tag. I can take a look at that too. It is easier for me to 
 understand the taglibs than the rest of Tomcat.
 =;o)

Well, I hope understanding the rest of tomcat is not that difficult, but
the goal of the tags was to hide tomcat implementation details ( or
tomcat itself ). A context tag can have different implementations,
maybe specific to other servlet containers - the admin interface will be
the same, just a different taglib code will be used.

BTW, nothing requires you to use the tags or jsp - but whatever you use,
please keep the implementation behind an interface similar with the
tags. ( i.e. similar name and behaviors ).


 In this case I am talking about the comments in the method
 org.apache.tomcat.core.ContextManager.shutdown()
 
 In this method's source code there are 2 blocks of cleanup code that 
 were commented out. The fact that they were not just removed and the 
 nature of a comment:
   remove the modules ( XXX do we need that ? )
 before one of those blocks makes me wonder how sure it is that they
 are correct.

The code that is commented out used to be part of the method, including
the one with XXX comment ( and the answer is - we don't need to remove
the modules ).

The idea is quite simple - shutdown() is symetrical with init(). If you
add any context manually ( for example EmbededTomcat.addContext() ), you
should also remove it when you stop ( if you want to ). If a module is
adding contexts - it should also remove them ( or leave them in and
don't add them back ).

That's probably where the bug is, I need to review ContextXmlReader and
AutoWebApp to make sure they remove the contexts on shutdown.

shutdown() followed by init() should bring you back to the same state as
you were before ( if no configuration change happened ). 

Now, that's the theory - or what seems to be the 'correct' behavior for
the core. 3.3 is mostly about making sure the core behaves in a well
defined way - better modules will follow, and we can fix modules easily
without all the headache of a major release. 

If you have any doubts about the ContextManager behavior - please speak
now, we may still be able to fix it. 

Regarding the module removal - again, whoever adds modules should also
remove them back, shutdown shouldn't mess with that ( since init doesn't
either ).

In future, some modules will be enhanced to deal 'nicely' with restarts,
and I plan to add support module reloading ( via a module, of course
:-). As I mentioned so many times, after 3.3 we shouldn't have to change
anything in the core, so new modules can rely on some known and well
defined behavior ( well defined doesn't mean perfect, but good enough
:-). 


 Specific questions, besides the above ContextManager.shutdown() 
 issue:
  - Why is it possible to add 2 or more contexts with the same name
and base path? It is a cleanup issue that this happens with the 
restart.jsp code, but shouldn't this kind of duplication also 
be prevented?

Contexts should be identified by hostname and base path. If we don't
check for that - it's a bug. BTW, the right way to fix the bug is to add
the check - not in the core, but in a module ( that can do other checks
during the addContext/contextInit phases ). Again, this can wait until
after 3.3, I don't think it's a major issue. 

  - To make a hot restart, it looks like modules should be restarted
too. Is this correct?

Modules should deal themself with the init/shutdown events, and restart.
Most existing modules do not need to be reloaded - but that can be done
too. I'm still investigating how to implement module restart, and hot
module add/remove. I don't think this can be done in 3.3, but in a set
of modules that can be released after 3.3 ( I have some code, but now I
want to focus on 3.3 and few other important pieces ).


  - When using restart.jsp, previously removed contexts (using the
admin pages) were not added back. Why?

Bug probably :-) Again, the right behavior is that whoever adds
something should take it back. 

  - Where are existing contexts detected and loaded? Is it on a 
module? And if yes, then which?

Contexts ( and modules ) are added in 2 ways:
- in applications embedding tomcat, by the application via calls to EmbededTomcat 
or ContextManager. 

- in standalone tomcat, by various configuration modules. Right now the list is:
ContextXmlReader
AutoWebApp.

The first will add modules declared in apps-XXX.xml and server.xml ( which 
shouldn't be used for contexts, that's only for backward compat ).

The second deals with webapps-like dirs ( you can define additional
dirs, very usefull for multiple virtual hosts ).

Thats' where you should check what happens on shutdown.

BTW, this review will help a lot - thank you very much. I think it's very
important to make sure the behavior is right in the first place, we can fix
the 

RE: Tomcat on Windows vs. Unix

2001-08-20 Thread Bala Nemani

Thanks for the response.

We are going to move to 3.2.3 soon. Thanks

-Original Message-
From: mailtracker [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 20, 2001 2:20 PM
To: [EMAIL PROTECTED]
Subject: Re: Tomcat on Windows vs. Unix


1.  keep in mind the differences in naming conventions on Windows and Unix:
backslashes and forward slashes, case-sensitivity, end-of-line
characters
(files created on Windows, if not transferred properly, will appear on Unix
with every line terminated with a ^M)

2. Why not use the latest release version of Tomcat, 3.2.3?  Is there a
compelling reason to stay with the 3.1 branch?


 From: Bala Nemani [EMAIL PROTECTED]
 Reply-To: [EMAIL PROTECTED]
 Date: Mon, 20 Aug 2001 13:51:32 -0400
 To: '[EMAIL PROTECTED]' [EMAIL PROTECTED]
 Subject: Tomcat on Windows vs. Unix
 
 Hi:
 
 We are developing a web application using Tomcat 3.1, Oracle DB, JSP,
Java
 Servelets using MVC Architecture. All the development and testing is
being
 done in Windows platform (Tomcat running on Windows 2000). But customer
 would like to deploy Tomcat on Unix
 
 Are there any known issues that we need to be pay extra attention to?
Have
 any one done this kind of deployment? Any help/hints are appreciated
 
 Regards,
 Bala Nemani
 



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

2001-08-20 Thread craigmcc

craigmcc01/08/20 15:43:52

  Modified:catalina/src/share/org/apache/catalina/servlets
InvokerServlet.java
   webapps/tomcat-docs index.xml project.xml
  Log:
  Synchronize around the first-time creation of a new Wrapper for the
  invoked servlet.  This avoids race conditions when multiple requests try
  to create the same wrapper at the same time.
  
  PR: Bugzilla #3188
  Submitted by: Eddie Ruvinsky [EMAIL PROTECTED]
  
  Revision  ChangesPath
  1.11  +29 -23
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerServlet.java
  
  Index: InvokerServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerServlet.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- InvokerServlet.java   2001/08/20 00:33:34 1.10
  +++ InvokerServlet.java   2001/08/20 22:43:52 1.11
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerServlet.java,v
 1.10 2001/08/20 00:33:34 craigmcc Exp $
  - * $Revision: 1.10 $
  - * $Date: 2001/08/20 00:33:34 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerServlet.java,v
 1.11 2001/08/20 22:43:52 craigmcc Exp $
  + * $Revision: 1.11 $
  + * $Date: 2001/08/20 22:43:52 $
*
* 
*
  @@ -87,7 +87,7 @@
* in the web application deployment descriptor.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.10 $ $Date: 2001/08/20 00:33:34 $
  + * @version $Revision: 1.11 $ $Date: 2001/08/20 22:43:52 $
*/
   
   public final class InvokerServlet
  @@ -342,25 +342,31 @@
   log(Creating wrapper for ' + servletClass +
   ' with mapping ' + pattern + ');
   
  -// Create and install a new wrapper
  -try {
  -wrapper = context.createWrapper();
  -wrapper.setName(name);
  -wrapper.setLoadOnStartup(1);
  -wrapper.setServletClass(servletClass);
  -context.addChild(wrapper);
  -context.addServletMapping(pattern, name);
  -} catch (Throwable t) {
  -log(sm.getString(invokerServlet.cannotCreate,
  - inRequestURI), t);
  -if (included)
  -throw new ServletException
  -(sm.getString(invokerServlet.cannotCreate,
  -  inRequestURI), t);
  -else {
  -response.sendError(HttpServletResponse.SC_NOT_FOUND,
  -   inRequestURI);
  -return;
  +// Create and install a new wrapper (synchronized to avoid
  +// race conditions when multiple requests try to initialize
  +// the same servlet at the same time)
  +synchronized (this) {
  +try {
  +wrapper = context.createWrapper();
  +wrapper.setName(name);
  +wrapper.setLoadOnStartup(1);
  +wrapper.setServletClass(servletClass);
  +context.addChild(wrapper);
  +context.addServletMapping(pattern, name);
  +} catch (Throwable t) {
  +log(sm.getString(invokerServlet.cannotCreate,
  + inRequestURI), t);
  +context.removeServletMapping(pattern);
  +context.removeChild(wrapper);
  +if (included)
  +throw new ServletException
  +(sm.getString(invokerServlet.cannotCreate,
  +  inRequestURI), t);
  +else {
  +response.sendError(HttpServletResponse.SC_NOT_FOUND,
  +   inRequestURI);
  +return;
  +}
   }
   }
   
  
  
  
  1.8   +4 -0  jakarta-tomcat-4.0/webapps/tomcat-docs/index.xml
  
  Index: index.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/index.xml,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- index.xml 2001/08/16 23:21:25 1.7
  +++ index.xml 2001/08/20 22:43:52 1.8
  @@ -116,6 +116,10 @@
   the development of the emJasper/em JSP container portion of Tomcat
   itself, or to better understand its internal architecture and operation./p
   ul
  +!--
  +lia href=jasper-requirements.htmlstrongJasper Overall 
Requirements/strong/a
  

[BUG] TC3.3B1 ignores transport-guarantee in web.xml

2001-08-20 Thread Bill Barker

It seems that everybody is delegating the checking of
transport-guarantee to somebody else, and as a result it is never checked.
Fortunately, this is easy to reproduce:

1) add a
user-data-constrainttransport-guaranteeCONFIDENTIAL/transport-guarantee
/user-data-constraint to the security-constraint

2) Access the page via http://myserver/myapp/path/to/page

The page will happily be displayed even though the use of the http protocol
was dis-allowed.




custom 404s from a servlet ?

2001-08-20 Thread yhs

Hi guys,
  does anyone know how i can modify tomcat's configuration files so my 404's can be 
invoked
from a servlet ? i.e. i want http://localhost:8080/someweirdlink?x=foo to be redirected
to http://localhost:8080/servlet/my404servlet?x=foo if someweidrlink doesnt exist...
similarly if servlet abc doesnt exist http://localhost:8080/servlet/abc should also
be redirected to http://localhost:8080/servlet/my404servlet ...
I'd like to keep everything else the same..i.e. jsps. html and servlets all remaining
the same but all site wide 404's in every directory be redirected to the same servlet.
im running tomcat 3.2.3...
Thanks.
-Ys-

Find the best deals on the web at AltaVista Shopping!
http://www.shopping.altavista.com



Re: custom 404s from a servlet ?

2001-08-20 Thread Dmitri Colebatch

yep - have a look at error-page (I think) in web.xml...  The servlet
spec outlines its use (http://java.sun.com/products/servlet).

hth
cheesr
dim

On 20 Aug 2001, yhs wrote:

 Hi guys,
   does anyone know how i can modify tomcat's configuration files so my 404's can be 
invoked
 from a servlet ? i.e. i want http://localhost:8080/someweirdlink?x=foo to be 
redirected
 to http://localhost:8080/servlet/my404servlet?x=foo if someweidrlink doesnt exist...
 similarly if servlet abc doesnt exist http://localhost:8080/servlet/abc should also
 be redirected to http://localhost:8080/servlet/my404servlet ...
 I'd like to keep everything else the same..i.e. jsps. html and servlets all remaining
 the same but all site wide 404's in every directory be redirected to the same 
servlet.
 im running tomcat 3.2.3...
 Thanks.
 -Ys-
 
 Find the best deals on the web at AltaVista Shopping!
 http://www.shopping.altavista.com
 




Re: custom 404s from a servlet ?

2001-08-20 Thread Bill Barker

I'm sure that other people are going to flame this thread as off-topic, but
the answer is to call

response.sendError(HttpServletResponse.SC_NOT_FOUND,someweirdlink doesn't
exist);
return;



- Original Message -
From: yhs [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, August 20, 2001 4:31 PM
Subject: custom 404s from a servlet ?


 Hi guys,
   does anyone know how i can modify tomcat's configuration files so my
404's can be invoked
 from a servlet ? i.e. i want http://localhost:8080/someweirdlink?x=foo to
be redirected
 to http://localhost:8080/servlet/my404servlet?x=foo if someweidrlink
doesnt exist...
 similarly if servlet abc doesnt exist http://localhost:8080/servlet/abc
should also
 be redirected to http://localhost:8080/servlet/my404servlet ...
 I'd like to keep everything else the same..i.e. jsps. html and servlets
all remaining
 the same but all site wide 404's in every directory be redirected to the
same servlet.
 im running tomcat 3.2.3...
 Thanks.
 -Ys-

 Find the best deals on the web at AltaVista Shopping!
 http://www.shopping.altavista.com






cvs commit: jakarta-tomcat-service/docs - New directory

2001-08-20 Thread pier

pier01/08/20 18:12:07

  jakarta-tomcat-service/docs - New directory



cvs commit: jakarta-tomcat-service/docs service.css service.html

2001-08-20 Thread pier

pier01/08/20 18:13:13

  Added:   docs service.css service.html
  Log:
  Initial (not finished yet) writing of a specification for Service classes.
  
  Revision  ChangesPath
  1.1  jakarta-tomcat-service/docs/service.css
  
  Index: service.css
  ===
  BODY {
font-family: arial, helvetica, sans-serif;
font-size: 10pt;
text-align: justify;
  }
  
  H1 {
border-width: 2px;
border-style: ridge;
border-color: #cc;
background-color: #ff;
font-size: 14pt;
font-weight: bold;
text-align: center;
padding: 2px;
  }
  
  H2 {
border-width: 2px;
border-style: ridge;
border-color: #cc;
background-color: #ff;
font-size: 12pt;
font-weight: bold;
text-align: left;
padding: 2px;
  }
  
  H3 {
font-size: 10pt;
font-weight: bold;
text-align: left;
  }

  H4 {
font-size: 8pt;
font-weight: normal;
font-style: italic;
text-align: center;
  }
  
  P {
margin-left: 20px;
  }
  
  P.note {
border-width: 1px;
border-style: ridge;
border-color: #cc;
background-color: #ee;
font-size: 8pt;
font-weight: normal;
text-align: justify;
margin-left: 20%;
margin-right: 20%;
padding: 4px;
  }
  
  P.copyright {
font-size: 8pt;
font-weight: normal;
text-align: center;
  }
  
  PRE {
border-width: 1px;
border-style: ridge;
border-color: #cc;
background-color: #ee;
font-size: 8pt;
font-weight: normal;
text-align: left;
margin-left: 10%;
margin-right: 10%;
padding: 4px;
  }
  
  CODE {
font-size: 8pt;
white-space: pre;
font-weight: normal;
  }
  
  EM.key {
color: #99;
font-style: normal;
white-space: pre;
  }
  
  EM.ref {
color: #99;
font-style: normal;
white-space: pre
  }
  
  EM.com {
color: #009900;
font-style: normal;
white-space: pre
  }
  
  OL {
list-style: decimal outside;
font-size: 10pt;
  }
  
  OL OL {
list-style: lower-alpha outside;
font-size: 8pt;
  }
  
  A:link {
color: #ee;
text-decoration: none;
white-space: pre;
  }
  
  A:visited {
color: #ee;
text-decoration: none;
white-space: pre;
  }
  
  A:active {
color: #ee;
text-decoration: none;
white-space: pre;
  }
  
  
  
  1.1  jakarta-tomcat-service/docs/service.html
  
  Index: service.html
  ===
  !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 3.2 Final//EN
  HTML
HEAD
  TITLEApache Service Specification - Version 1.0/TITLE
  LINK REL=stylesheet TYPE=text/css HREF=service.css TITLE=service
  META HTTP-EQUIV=content-type CONTENT=text/html; charset=ISO-8859-1
/HEAD
BODY
  
  H1Apache Service Specification/H1
  H4Version 1.0/H4

  P CLASS=note
strongAbstract:/strong
This document specifies the behavior and life cycle of an abstract
Javatrade; service, in relation to its native container. In addition
it defines a mechanism for controlling a service, and its interaction
with the native OS process in which its existance is confined.
  /P

  H2Index/H2
  OL
LIA HREF=#1Introduction/A
LIA HREF=#2Scope of this specification/A
LIA HREF=#3The Service interface and its life cycle/A
OL
  LIA HREF=#3AInstantiation/A
  LIA HREF=#3BInitialization/A
  LIA HREF=#3CStartup/A
  LIA HREF=#3DStop/A
  LIA HREF=#3EDestruction/A
/OL
  /OL
  
  A NAME=1H2Introduction/H2/A
  P
Since 1994, the Javatrade; programming language evolved and became a
valid tool to develop, other than applets and client applications,
reliable and performant server applications. The major disadvantage of
the Javatrade; platform is that still today the only portable way to
start a Javatrade; applcation relies on a single point of entry: the
CODEEM CLASS=keypublic static void/EM main(EM 
CLASS=refString/EM[])/CODE
method.
  /P
  P
Having a single-point of entry is a valid solution for client
applications, where interactively a user can command to the application
to quit (which can terminate the Virtual Machine process at calling the
CODEEM CLASS=refSystem/EM.exit(EM CLASS=keyint/EM)/CODE
method), but in those cases where the application is not interactive
(server applications) there is currently no portable way to notify
the Virtual Machine of its imminent shutdown.
  /P
  P
A server application written in Java might have to perform several tasks
before being able to shutdown the Virtual Machine process. For example
in the case of a Servlet container, before the VM process 

Re: cvs commit: jakarta-tomcat-service/docs service.cssservice.html

2001-08-20 Thread Jon Stevens

Why is this a .html file and not a .xml file?

-jon

on 8/20/01 6:13 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

 pier01/08/20 18:13:13
 
 Added:   docs service.css service.html
 Log:
 Initial (not finished yet) writing of a specification for Service classes.
 
 Revision  ChangesPath
 1.1  jakarta-tomcat-service/docs/service.css
 
 Index: service.css
 ===
 BODY {
   font-family: arial, helvetica, sans-serif;
   font-size: 10pt;
   text-align: justify;
 }
 
 H1 {
   border-width: 2px;
   border-style: ridge;
   border-color: #cc;
   background-color: #ff;
   font-size: 14pt;
   font-weight: bold;
   text-align: center;
   padding: 2px;
 }
 
 H2 {
   border-width: 2px;
   border-style: ridge;
   border-color: #cc;
   background-color: #ff;
   font-size: 12pt;
   font-weight: bold;
   text-align: left;
   padding: 2px;
 }
 
 H3 {
   font-size: 10pt;
   font-weight: bold;
   text-align: left;
 }
   
 H4 {
   font-size: 8pt;
   font-weight: normal;
   font-style: italic;
   text-align: center;
 }
 
 P {
   margin-left: 20px;
 }
 
 P.note {
   border-width: 1px;
   border-style: ridge;
   border-color: #cc;
   background-color: #ee;
   font-size: 8pt;
   font-weight: normal;
   text-align: justify;
   margin-left: 20%;
   margin-right: 20%;
   padding: 4px;
 }
 
 P.copyright {
   font-size: 8pt;
   font-weight: normal;
   text-align: center;
 }
 
 PRE {
   border-width: 1px;
   border-style: ridge;
   border-color: #cc;
   background-color: #ee;
   font-size: 8pt;
   font-weight: normal;
   text-align: left;
   margin-left: 10%;
   margin-right: 10%;
   padding: 4px;
 }
 
 CODE {
   font-size: 8pt;
   white-space: pre;
   font-weight: normal;
 }
 
 EM.key {
   color: #99;
   font-style: normal;
   white-space: pre;
 }
 
 EM.ref {
   color: #99;
   font-style: normal;
   white-space: pre
 }
 
 EM.com {
   color: #009900;
   font-style: normal;
   white-space: pre
 }
 
 OL {
   list-style: decimal outside;
   font-size: 10pt;
 }
 
 OL OL {
   list-style: lower-alpha outside;
   font-size: 8pt;
 }
 
 A:link {
   color: #ee;
   text-decoration: none;
   white-space: pre;
 }
 
 A:visited {
   color: #ee;
   text-decoration: none;
   white-space: pre;
 }
 
 A:active {
   color: #ee;
   text-decoration: none;
   white-space: pre;
 }
 
 
 
 1.1  jakarta-tomcat-service/docs/service.html
 
 Index: service.html
 ===
 !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 3.2 Final//EN
 HTML
   HEAD
 TITLEApache Service Specification - Version 1.0/TITLE
 LINK REL=stylesheet TYPE=text/css HREF=service.css TITLE=service
 META HTTP-EQUIV=content-type CONTENT=text/html; charset=ISO-8859-1
   /HEAD
   BODY
 
 H1Apache Service Specification/H1
 H4Version 1.0/H4
   
 P CLASS=note
   strongAbstract:/strong
   This document specifies the behavior and life cycle of an abstract
   Javatrade; service, in relation to its native container. In addition
   it defines a mechanism for controlling a service, and its interaction
   with the native OS process in which its existance is confined.
 /P
   
 H2Index/H2
 OL
   LIA HREF=#1Introduction/A
   LIA HREF=#2Scope of this specification/A
   LIA HREF=#3The Service interface and its life cycle/A
   OL
 LIA HREF=#3AInstantiation/A
 LIA HREF=#3BInitialization/A
 LIA HREF=#3CStartup/A
 LIA HREF=#3DStop/A
 LIA HREF=#3EDestruction/A
   /OL
 /OL
 
 A NAME=1H2Introduction/H2/A
 P
   Since 1994, the Javatrade; programming language evolved and became a
   valid tool to develop, other than applets and client applications,
   reliable and performant server applications. The major disadvantage of
   the Javatrade; platform is that still today the only portable way to
   start a Javatrade; applcation relies on a single point of entry: the
   CODEEM CLASS=keypublic static void/EM main(EM
 CLASS=refString/EM[])/CODE
   method.
 /P
 P
   Having a single-point of entry is a valid solution for client
   applications, where interactively a user can command to the application
   to quit (which can terminate the Virtual Machine process at calling the
   CODEEM CLASS=refSystem/EM.exit(EM CLASS=keyint/EM)/CODE
   method), but in those cases where the application is not interactive
   (server applications) there is currently no portable way to notify
   the Virtual Machine of its imminent shutdown.
 /P
 P
   A server application written in Java might have to perform several tasks
   before being able to shutdown the Virtual Machine process. For example
   in the case of a Servlet container, before the VM process is shut down,
   sessions might need to be serialized to disk, and web 

Re: cvs commit: jakarta-tomcat-service/docs service.cssservice.html

2001-08-20 Thread Pier P. Fumagalli

Jon Stevens at [EMAIL PROTECTED] wrote:

 Why is this a .html file and not a .xml file?

Because the service code is not built using Java, 99.9% of it is C code, and
I don't need ANT to build it... I don't want to rely on something JAVA to
build the docs... It's plain unformatted HTML... All styling is done in the
CSS... Being the spec, I prefer to have it plain (either HTML or plaintext),
functional documentation, we'll see...

Pier




RE: [ANNOUNCEMENT] Tomcat 4.0-beta-7 Released

2001-08-20 Thread mettu . kumar

Criag,

PFD3? Only PFD2 is accessable from Sun web site. 
Aslo Suns web site says Tomcat 4.0-beta-7 supports PFD2.

http://java.sun.com/products/servlet/download.html



Kumar.

-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 09, 2001 11:02 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [ANNOUNCEMENT] Tomcat 4.0-beta-7 Released


A release candidate version of Tomcat 4.0, version beta 7, has been
released.  This version conforms to the Proposed Final Draft 3 version of
the Servlet 2.3 and JSP 1.2 specifications, which will go final soon, and
incorporates all of the latest bugfixes.

In addition, for users who run Tomcat 4.0 on Windows 9x, this release
fixes a security vulnerability that allows users to browse the directory
tree above the web application's context root by using request URIs
including three or more dots (/...).  Users running on Win2K and Unix
systems are *not* susceptible to this vulneratibility.

In addition, as with the previous version, an installer-based version of
Tomcat 4.0-beta-7 is available for Windows users, as well as native code
versions of the mod_webapp connector for Apache.

Binary distributions are available at:

  http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-b7/

Source distributions are available at:

  http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-b7/src/

Craig McClanahan




cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/config http11.xml server.xml service.xml warp.xml

2001-08-20 Thread craigmcc

craigmcc01/08/20 19:28:21

  Modified:webapps/tomcat-docs index.xml project.xml tomcat-docs.xsl
  Added:   webapps/tomcat-docs proxy-howto.xml
   webapps/tomcat-docs/config http11.xml server.xml service.xml
warp.xml
  Log:
  Migrate the first four pages of the Server Configuration information
  (Server, Service, HTTP/1.1 Connector, and WARP Connector) to the new
  documentation style.  Added a new attributes template to the stylesheet
  to support rendering of attribute/description tables.
  
  Separated out the information on configuring Tomcat behind a proxy server
  into a new Proxy Support HOW-TO document.
  
  Revision  ChangesPath
  1.9   +3 -0  jakarta-tomcat-4.0/webapps/tomcat-docs/index.xml
  
  Index: index.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/index.xml,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- index.xml 2001/08/20 22:43:52 1.8
  +++ index.xml 2001/08/21 02:28:21 1.9
  @@ -65,6 +65,9 @@
   lia href=manager-howto.htmlstrongManager App HOW-TO/strong/a -
   Operating the codeManager/code web app to deploy, undeploy, and
   redeploy applications while Tomcat is running./li
  +lia href=proxy-howto.htmlstrongProxy Support HOW-TO/strong/a -
  +Configuring Tomcat 4 to run behind a proxy server (or a web server
  +functioning as a proxy server)./li
   lia href=ssl-howto.htmlstrongSSL Configuration HOW-TO/strong/a -
   Installing and
   configuring SSL support so that your Tomcat will serve requests using
  
  
  
  1.9   +1 -0  jakarta-tomcat-4.0/webapps/tomcat-docs/project.xml
  
  Index: project.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/project.xml,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- project.xml   2001/08/20 22:43:52 1.8
  +++ project.xml   2001/08/21 02:28:21 1.9
  @@ -25,6 +25,7 @@
   menu name=Administrators
   item name=Config. Reference href=config/index.html/
   item name=Manager App HOW-TOhref=manager-howto.html/
  +item name=Proxy Support HOW-TO  href=proxy-howto.html/
   item name=SSL Config HOW-TO href=ssl-howto.html/
   /menu
   
  
  
  
  1.3   +45 -14jakarta-tomcat-4.0/webapps/tomcat-docs/tomcat-docs.xsl
  
  Index: tomcat-docs.xsl
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/tomcat-docs.xsl,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- tomcat-docs.xsl   2001/08/05 04:02:30 1.2
  +++ tomcat-docs.xsl   2001/08/21 02:28:21 1.3
  @@ -1,7 +1,7 @@
   ?xml version=1.0 encoding=ISO-8859-1?
   !-- Content Stylesheet for tomcat-docs Documentation --
   
  -!-- $Id: tomcat-docs.xsl,v 1.2 2001/08/05 04:02:30 craigmcc Exp $ --
  +!-- $Id: tomcat-docs.xsl,v 1.3 2001/08/21 02:28:21 craigmcc Exp $ --
   
   xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
 version=1.0
  @@ -14,22 +14,23 @@
   
   
 !-- Defined parameters (overrideable) --
  -  xsl:paramname=home-name select='The Jakarta Project'/
  -  xsl:paramname=home-href select='http://jakarta.apache.org/'/
  -  xsl:paramname=home-logo select='/images/jakarta-logo.gif'/
  -  xsl:paramname=relative-path select='.'/
  -  xsl:paramname=void-imageselect='/images/void.gif'/
  +  xsl:paramname=home-nameselect='The Jakarta Project'/
  +  xsl:paramname=home-hrefselect='http://jakarta.apache.org/'/
  +  xsl:paramname=home-logoselect='/images/jakarta-logo.gif'/
  +  xsl:paramname=relative-pathselect='.'/
  +  xsl:paramname=void-image   select='/images/void.gif'/
   
   
 !-- Defined variables (non-overrideable) --
  -  xsl:variable name=body-bg   select='#ff'/
  -  xsl:variable name=body-fg   select='#00'/
  -  xsl:variable name=body-link select='#525D76'/
  -  xsl:variable name=banner-bg select='#525D76'/
  -  xsl:variable name=banner-fg select='#ff'/
  -  xsl:variable name=sub-banner-bg select='#828DA6'/
  -  xsl:variable name=sub-banner-fg select='#ff'/
  -  xsl:variable name=source-color  select='#023264'/
  +  xsl:variable name=body-bg  select='#ff'/
  +  xsl:variable name=body-fg  select='#00'/
  +  xsl:variable name=body-linkselect='#525D76'/
  +  xsl:variable name=banner-bgselect='#525D76'/
  +  xsl:variable name=banner-fgselect='#ff'/
  +  xsl:variable name=sub-banner-bgselect='#828DA6'/
  +  xsl:variable name=sub-banner-fgselect='#ff'/
  +  xsl:variable name=source-color select='#023264'/
  +  xsl:variable name=attributes-color select='#023264'/
   
   
 !-- 

Re: cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/confighttp11.xml server.xml service.xml warp.xml

2001-08-20 Thread Pier P. Fumagalli

[EMAIL PROTECTED] at [EMAIL PROTECTED] wrote:
 
 1.1  jakarta-tomcat-4.0/webapps/tomcat-docs/config/warp.xml

Whoha! :) Great work Craig... I'll patch it up tomorrow since I'm feeling
documenty these days :) :) :)

Pier




Re: mod_jk 1.2.0 (CVS) + TC 3.3 B1

2001-08-20 Thread Bojan Smojver

 GOMEZ Henri wrote:
  mod_jk in JTC is an evolution of mod_jk in CVS. Some refactoring
  was done to share code between ajp13 and ajp14.
 
  If this is not a known thing, I can send some more data...
 
  Yes, please, strace could help in that case.
 
 OK. I'll run up a few examples and send you the strace.

I think this problem has to do with sessions.

The first page I used for testing is a product catalogue and is tied up
to a session. Basically you select a category of the products that you'd
like to see and then the filtered out selection of products gets
displayed when you submit. Then you further narrow your search and so
on. This is a JSP page with beans of session scope - they actually store
what you selected last.

The other test page is an ordering system and is also session based, but
this is a Velocity page, driven by one of my own servlets that keeps
track of bean scope.

This is the scenario:

- open one browser and load the page
- enter/select information on the page and submit (repeat this often in
different browsers)
- randomly, you might get parameters back on the page or you might get a
blank page, or you might even get parameters submitted by a totally
different browser (ie. from a DIFFERENT SESSION!)
- switching between accepting and rejecting cookies in the browsers
doesn't make any difference
- even with SessionId cookiesFirst=false noCookies=true / in
server.xml it doesn't work (ie. this relies purely on URL rewriting,
which I always do in my code and the browser shows the rewritten URL)

I'm sending you (directly to your e-mail address) two strace log files,
first with cookies, second without cookies - but the results in the
browser are identical. For some reason sessions don't quite make it back
to Tomcat.

Both applications work perfectly with Tomcat TC 3.3 B1 + mod_jk shipped
with it.

Rather then use old code, I've downloaded and compiled the latest Tomcat
3.3 CVS snapshot. There is no point debugging old code.

Let me know if there's anything else you need (or where can I look) to
help fix this.

Bojan



RE: [ANNOUNCEMENT] Tomcat 4.0-beta-7 Released

2001-08-20 Thread Craig R. McClanahan



On Mon, 20 Aug 2001 [EMAIL PROTECTED] wrote:

 Criag,
 
 PFD3? Only PFD2 is accessable from Sun web site. 
 Aslo Suns web site says Tomcat 4.0-beta-7 supports PFD2.
 
 http://java.sun.com/products/servlet/download.html
 

Originally, it was my understanding that PFD3 (of both specs) was going to
be published to the world (the way that PFD2 was), rather than just to the
JSR_053 expert group that is responsible for the contents.  That turns out
not to be the case -- the PFD3 versions are essentially what has been
submitted to the JCP Executive Committee for a vote, and will become the
final versions real soon now.

In terms of changes from PFD2, there were *very* few -- mostly corner
cases where the behavior was not completely documented in PFD2.  There
were zero changes in the servlet and JSP APIs, and likewise no change in
the deployment descriptors (and I would not expect to see any further
changes like that, either).

 
 Kumar.
 

Craig




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

2001-08-20 Thread costin

costin  01/08/20 21:41:32

  Modified:src/share/org/apache/tomcat/util IntrospectionUtils.java
  Log:
  A number of additions to IntrospectioUtils, in order to support the class loader
  hierarchy in EmbededTomcat and the simpler startup mechanism.
  
  Nothing spectacular, just the plain old java.lang.reflect.
  
  Revision  ChangesPath
  1.13  +127 -20   
jakarta-tomcat/src/share/org/apache/tomcat/util/IntrospectionUtils.java
  
  Index: IntrospectionUtils.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/IntrospectionUtils.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- IntrospectionUtils.java   2001/08/17 04:07:45 1.12
  +++ IntrospectionUtils.java   2001/08/21 04:41:32 1.13
  @@ -208,7 +208,8 @@
File f1=new File ( f, ..);
install = f1.getCanonicalPath();
if( installSysProp != null )
  - System.getProperties().put( installSysProp, install );
  + System.getProperties().put( installSysProp,
  + install );
if( homeSysProp != null )
System.getProperties().put( homeSysProp, install );
return install;
  @@ -221,6 +222,36 @@
return null;
   }
   
  +/** Debug method, display the classpath
  + */
  +public static void displayClassPath( String msg, URL[] cp ) {
  + System.out.println(msg);
  + for( int i=0; icp.length; i++ ) {
  + System.out.println( cp[i].getFile() );
  + }
  +}
  +
  +public static String PATH_SEPARATOR = System.getProperty(path.separator);
  +/**
  + * Adds classpath entries from a vector of URL's to the
  + * tc_path_add System property.  This System property lists
  + * the classpath entries common to web applications. This System
  + * property is currently used by Jasper when its JSP servlet
  + * compiles the Java file for a JSP.
  +*/
  +public static String classPathAdd(URL urls[], String cp )
  +{
  + if( urls==null ) return cp;
  +
  + for( int i=0; iurls.length; i++ ) {
  +if( cp != null)
  +cp += PATH_SEPARATOR + urls[i].getFile();
  +else
  +cp = urls[i].getFile();
  +}
  +return cp;
  +}
  +
   /** Find a method with the right name
If found, call the method ( if param is int or boolean we'll convert
value to the right type before) - that means you can have setDebug(1).
  @@ -324,6 +355,29 @@
}
   }
   
  +/** 
  + */
  +public static void setProperty( Object o, String name ) {
  + String setter= set +capitalize(name);
  + try {
  + Method methods[]=findMethods( o.getClass() );
  + Method setPropertyMethod=null;
  + // find setFoo() method
  + for( int i=0; i methods.length; i++ ) {
  + Class paramT[]=methods[i].getParameterTypes();
  + if( setter.equals( methods[i].getName() ) 
  + paramT.length == 0 ) {
  + methods[i].invoke( o, new Object[] {} );
  + return;
  + }
  + }
  + } catch( Exception ex1 ) {
  + if( dbg  0 )
  + d(Exception for  + o.getClass() +   + name);
  + if( dbg  1 ) ex1.printStackTrace();
  + } 
  +}
  +
   /** Replace ${NAME} with the property value
*/
   public static String replaceProperties(String value,
  @@ -499,27 +553,56 @@
   return urls;
   }
   
  +/** Construct a URL classpath from files in a directory,
  + *  a cpath property, and tools.jar.
  + */
  +public static URL[] getClassPath( String dir, String cpath,
  +   String cpathProp, boolean addTools )
  + throws IOException, MalformedURLException
  +{
  + Vector jarsV = new Vector();
  + if( dir!=null )
  + addToClassPath( jarsV, dir );
  + 
  + if( cpath != null )
  + addJarsFromClassPath(jarsV,cpath);
  + 
  + if( cpathProp!=null ) {
  + String cpath1=System.getProperty( cpathProp );
  + addJarsFromClassPath(jarsV,cpath1);
  + }
  +
  + if(addTools)
  + addToolsJar( jarsV );
  + 
  + return getClassPath(jarsV);
  +}
  +
   //  Mapping command line params to setters
   
   public static boolean processArgs(Object proxy, String args[] ) 
throws Exception
   {
String args0[]=null;
  - if( null != findMethod( proxy.getClass(), getOptions1, new Class[] {} )) {
  + if( null != findMethod( proxy.getClass(),
  + getOptions1, new Class[] {} )) {

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/compat Jdk11Compat.java Jdk12Support.java

2001-08-20 Thread costin

costin  01/08/20 21:44:02

  Modified:src/share/org/apache/tomcat/util/compat Jdk11Compat.java
Jdk12Support.java
  Log:
  Fix a possible security problem ( if JdkCompat ends up with too many permissions,
  the previous code could allow granting them to untrusted code ).
  
  Now the priviledged call is done in the context of the caller ( you can't run without
  a context, and the only way untrusted code could get the context is via JdkCompat )
  
  Better to be safe.
  
  Revision  ChangesPath
  1.9   +5 -1  
jakarta-tomcat/src/share/org/apache/tomcat/util/compat/Jdk11Compat.java
  
  Index: Jdk11Compat.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/compat/Jdk11Compat.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- Jdk11Compat.java  2001/08/16 00:20:47 1.8
  +++ Jdk11Compat.java  2001/08/21 04:44:02 1.9
  @@ -93,10 +93,14 @@
return new SimpleClassLoader( urls, parent );
   }
   
  +public Object getAccessControlContext() throws Exception {
  + return null;
  +}
  +
   /** Do a priviledged action. For java2 a wrapper will be provided
and the AccesscController will be called.
*/
  -public Object doPrivileged( Action action ) throws Exception {
  +public Object doPrivileged( Action action, Object acc ) throws Exception {
// ( using util's permissions !)
return action.run();
   }
  
  
  
  1.6   +9 -3  
jakarta-tomcat/src/share/org/apache/tomcat/util/compat/Jdk12Support.java
  
  Index: Jdk12Support.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/compat/Jdk12Support.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- Jdk12Support.java 2001/08/16 00:20:47 1.5
  +++ Jdk12Support.java 2001/08/21 04:44:02 1.6
  @@ -78,8 +78,14 @@
return URLClassLoader.newInstance( urls, parent );
   }
   
  -
  -public Object doPrivileged( Action action ) throws Exception {
  +public Object getAccessControlContext() throws Exception {
  + return AccessController.getContext();
  +}
  +
  +public Object doPrivileged( Action action, Object accO ) throws Exception {
  + AccessControlContext acc=(AccessControlContext)accO;
  + if( acc==null )
  + throw new Exception(Invalid access control context );
Object proxy=action.getProxy();
if( proxy==null ) {
proxy=new PrivilegedProxy(action);
  @@ -88,7 +94,7 @@
   
try {
return AccessController.
  - doPrivileged((PrivilegedExceptionAction)proxy);
  + doPrivileged((PrivilegedExceptionAction)proxy, acc);
} catch( PrivilegedActionException pe ) {
Exception e = pe.getException();
throw e;
  
  
  



cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/depend DependClassLoader12.java DependClassLoader.java

2001-08-20 Thread costin

costin  01/08/20 21:48:35

  Modified:src/share/org/apache/tomcat/util/depend
DependClassLoader.java
  Added:   src/share/org/apache/tomcat/util/depend
DependClassLoader12.java
  Log:
  A much more serious problem here. We recently fixed DependClassLoader - it needs
  to use defineClass() itself, it it relys on the parent the other classes which
  depend on the loaded class will be loaded with the parent loader.
  
  This change had a side effect - since defineClass() was used with 3 parms, without
  the protection domain.
  
  The first fix was required to fix reloading, this one is required to fix sandboxing.
  I reproduced the same tricks we used in jasper to maintain compatibility with JDK1.1
  ( however, I may need to add one more method ). This is not finalized, and is
  possible it'll brake JDK1.1 compilation ( not difficult to fix, but I have few other
  changes to commit).
  
  Revision  ChangesPath
  1.6   +17 -3 
jakarta-tomcat/src/share/org/apache/tomcat/util/depend/DependClassLoader.java
  
  Index: DependClassLoader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/depend/DependClassLoader.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- DependClassLoader.java2001/08/16 00:22:17 1.5
  +++ DependClassLoader.java2001/08/21 04:48:35 1.6
  @@ -89,13 +89,15 @@
   
   final static int debug=0;
   DependManager dependM;
  +protected Object pd;
   static Jdk11Compat jdkCompat=Jdk11Compat.getJdkCompat();
   
  -public DependClassLoader( DependManager depM, ClassLoader parent ) {
  +public DependClassLoader( DependManager depM, ClassLoader parent, Object pd ) {
super(); // will check permissions
this.parent=parent;
this.parent2=jdkCompat.getParentLoader( parent );
dependM=depM;
  + this.pd=pd;
   }
   
   // debug only
  @@ -119,7 +121,13 @@
   protected synchronized Class loadClass(String name, boolean resolve)
   throws ClassNotFoundException
   {
  -if( debug0) log( loadClass()  + name +   + resolve);
  + return loadClassInternal( name, resolve );
  +}
  +
  +protected Class loadClassInternal( String name, boolean resolve )
  + throws ClassNotFoundException
  +{
  + if( debug0) log( loadClass()  + name +   + resolve);
// The class object that will be returned.
   Class c = null;
   
  @@ -165,7 +173,7 @@
if( data==null ) 
throw new ClassNotFoundException( name +  lenght==0);
   
  - c=defineClass(data, 0, data.length);
  + c=defineClassCompat( name, data, 0, data.length, res );
dependency( c, res );

if (resolve) resolveClass(c);
  @@ -173,6 +181,12 @@
return c;
   }
   
  +protected Class defineClassCompat( String name, byte data[], int s, int end, 
URL res )
  + throws ClassNotFoundException
  +{
  + return defineClass(data, s, end);
  +}
  +
   public URL getResource(String name) {
return parent.getResource(name);
   }
  
  
  
  1.1  
jakarta-tomcat/src/share/org/apache/tomcat/util/depend/DependClassLoader12.java
  
  Index: DependClassLoader12.java
  ===
  /*
   * Copyright (c) 1997-1999 The Java Apache Project.  All rights reserved.
   *
   * Redistribution and use in source and binary forms, with or without
   * modification, are permitted provided that the following conditions
   * are met:
   *
   * 1. Redistributions of source code must retain the above copyright
   *notice, this list of conditions and the following disclaimer.
   *
   * 2. Redistributions in binary form must reproduce the above copyright
   *notice, this list of conditions and the following disclaimer in
   *the documentation and/or other materials provided with the
   *distribution.
   *
   * 3. All advertising materials mentioning features or use of this
   *software must display the following acknowledgment:
   *This product includes software developed by the Java Apache 
   *Project for use in the Apache JServ servlet engine project
   *http://java.apache.org/.
   *
   * 4. The names Apache JServ, Apache JServ Servlet Engine and 
   *Java Apache Project must not be used to endorse or promote products 
   *derived from this software without prior written permission.
   *
   * 5. Products derived from this software may not be called Apache JServ
   *nor may Apache nor Apache JServ appear in their names without 
   *prior written permission of the Java Apache Project.
   *
   * 6. Redistributions of any form whatsoever must retain the following
   *acknowledgment:
   *This product includes software developed by the Java Apache 
 

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/log Log.java LogHandler.java LogManager.java

2001-08-20 Thread costin

costin  01/08/20 21:52:17

  Modified:src/share/org/apache/tomcat/util/log Log.java
LogHandler.java LogManager.java
  Log:
  Few fixes here. The changes in startup showed few obscure bugs on log initialization.
  
  Note that LogManager is used as a guard on all sensitive accesses to Log. Now adding 
a
  channel will 'fix' all logs that were created earlier for the channel ( with default
  logger )
  
  This is important for loggers that are created before LogSetter module gets a chance
  to initialize the logging subsystem. In normal operation we don't do any logging 
before
  that anyway, but for debugging it's usefull ( and makes the package more usefull for
  use outside tomcat )
  
  Revision  ChangesPath
  1.6   +16 -4 jakarta-tomcat/src/share/org/apache/tomcat/util/log/Log.java
  
  Index: Log.java
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/log/Log.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- Log.java  2001/03/02 04:11:42 1.5
  +++ Log.java  2001/08/21 04:52:17 1.6
  @@ -124,7 +124,7 @@
  sink/logger at runtime, and without requiring the log
  user to do any special action or be aware of the changes
   */
  -private LogHandler proxy=new LogHandler(); // the default
  +private LogHandler proxy; // the default
   
   // Used to get access to other logging channels.
   // Can be replaced with an application-specific impl.
  @@ -133,9 +133,10 @@
   
   //  Various constructors 
   
  -protected Log(String channel, String prefix, Object owner) {
  +protected Log(String channel, String prefix, LogHandler proxy, Object owner) {
this.logname=channel;
this.prefix=prefix;
  + this.proxy=proxy;
   }
   
   /**
  @@ -227,17 +228,28 @@
*  have been created from the default LogManager, and 
*  provide a special manager implemetation.
*/
  -public static void setLogManager( LogManager lm ) {
  +public static LogManager setLogManager( LogManager lm ) {
// can be changed only once - so that user
// code can't change the log manager in running servers
if( logManager.getClass() == LogManager.class ) {
  + LogManager oldLM=logManager;
logManager=lm;
  + return oldLM;
}
  + return null;
   }
   
  +public String  getChannel( LogManager lm ) {
  + if( lm != logManager ) return null;
  + return logname;
  +}
  +
   public void setProxy( LogManager lm, LogHandler l ) {
// only the manager can change the proxy
  - if( lm!= logManager ) return;
  + if( lm!= logManager ) {
  + System.out.println(Attempt to change proxy  + lm +   + logManager);
  + return;
  + }
proxy=l;
   }
   
  
  
  
  1.2   +1 -1  
jakarta-tomcat/src/share/org/apache/tomcat/util/log/LogHandler.java
  
  Index: LogHandler.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/log/LogHandler.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- LogHandler.java   2001/03/02 04:11:44 1.1
  +++ LogHandler.java   2001/08/21 04:52:17 1.2
  @@ -84,7 +84,7 @@
   public  class LogHandler {
   
   protected PrintWriter sink = defaultSink;
  -protected int level = Log.WARNING;
  +protected int level = Log.INFORMATION;
   
   
   /**
  
  
  
  1.2   +25 -13
jakarta-tomcat/src/share/org/apache/tomcat/util/log/LogManager.java
  
  Index: LogManager.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/log/LogManager.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- LogManager.java   2001/03/02 04:11:44 1.1
  +++ LogManager.java   2001/08/21 04:52:17 1.2
  @@ -72,11 +72,19 @@
**/
   public class LogManager {
   
  -static LogHandler defaultChannel=null;
  +static LogHandler defaultChannel=new LogHandler();
   
   protected Hashtable loggers=new Hashtable();
   protected Hashtable channels=new Hashtable();
   
  +public  Hashtable getLoggers() {
  + return loggers;
  +}
  +
  +public Hashtable getChannels() {
  + return channels;
  +}
  +
   public static void setDefault( LogHandler l ) {
if( defaultChannel==null)
defaultChannel=l;
  @@ -86,32 +94,36 @@
if(name==null) name=;
   
channels.put( name, logH );
  + Enumeration enum=loggers.keys();
  + while( enum.hasMoreElements() ) {
  + String k=(String)enum.nextElement();
  + Log l=(Log)loggers.get( k );
  + if( name.equals( 

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core Context.java ContextManager.java

2001-08-20 Thread costin

costin  01/08/20 21:55:39

  Modified:src/share/org/apache/tomcat/core Context.java
ContextManager.java
  Log:
  2 small changes. In Context, avoid the creation of a log that will be thrown away
  a bit later ( which is usefull only to log messages before the context is 
initialized)
  
  In context manager make sure we set the tomcat.home property, which is required
  in reading the policy file. The shell script is setting it, but if EmbededTomcat
  is used we have no way to insure that.
  
  Revision  ChangesPath
  1.149 +2 -1  jakarta-tomcat/src/share/org/apache/tomcat/core/Context.java
  
  Index: Context.java
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Context.java,v
  retrieving revision 1.148
  retrieving revision 1.149
  diff -u -r1.148 -r1.149
  --- Context.java  2001/08/17 03:59:48 1.148
  +++ Context.java  2001/08/21 04:55:39 1.149
  @@ -231,8 +231,9 @@
   // are servlets allowed to access internal objects? 
   private boolean trusted=false;
   
  +private static Log defaultContextLog=Log.getLog(org/apache/tomcat/core, 
Context);
   // log channels for context and servlets 
  -private Log loghelper = Log.getLog(org/apache/tomcat/core, this);
  +private Log loghelper = defaultContextLog;
   private Log loghelperServlet;
   
   // servlet API implemented by this Context
  
  
  
  1.189 +1 -0  
jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java
  
  Index: ContextManager.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java,v
  retrieving revision 1.188
  retrieving revision 1.189
  diff -u -r1.188 -r1.189
  --- ContextManager.java   2001/08/17 03:59:48 1.188
  +++ ContextManager.java   2001/08/21 04:55:39 1.189
  @@ -250,6 +250,7 @@
*/
   public void setHome(String home) {
this.home=home;
  + System.getProperties().put(TOMCAT_HOME, home );
   }
   
   public String getHome() {
  
  
  



cvs commit: jakarta-tomcat/src/facade22/org/apache/tomcat/facade RequestDispatcherImpl.java

2001-08-20 Thread costin

costin  01/08/20 21:56:44

  Modified:src/facade22/org/apache/tomcat/facade
RequestDispatcherImpl.java
  Log:
  Update for the compat fix.
  
  Revision  ChangesPath
  1.19  +2 -2  
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/RequestDispatcherImpl.java
  
  Index: RequestDispatcherImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/RequestDispatcherImpl.java,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- RequestDispatcherImpl.java2001/03/31 21:52:33 1.18
  +++ RequestDispatcherImpl.java2001/08/21 04:56:44 1.19
  @@ -164,7 +164,7 @@
if( System.getSecurityManager() != null ) {
try {
forwardAction.prepare( request, response );
  - jdk11Compat.doPrivileged( forwardAction );
  + jdk11Compat.doPrivileged( forwardAction, 
jdk11Compat.getAccessControlContext() );
} catch( Exception e) {
wrapException( e, null );
}
  @@ -179,7 +179,7 @@
if( System.getSecurityManager() != null ) {
try {
includeAction.prepare( request, response );
  - jdk11Compat.doPrivileged( includeAction );
  + jdk11Compat.doPrivileged( includeAction, 
jdk11Compat.getAccessControlContext() );
} catch( Exception e) {
wrapException( e, null );
}
  
  
  



cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config LoaderInterceptor11.java

2001-08-20 Thread costin

costin  01/08/20 21:58:22

  Modified:src/share/org/apache/tomcat/modules/config
LoaderInterceptor11.java
  Log:
  Use _application_ loader, not parent loader. It worked because of a double bug,
  but fixing the first bug revealed this one.
  
  Revision  ChangesPath
  1.17  +13 -4 
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/LoaderInterceptor11.java
  
  Index: LoaderInterceptor11.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/LoaderInterceptor11.java,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- LoaderInterceptor11.java  2001/07/19 05:56:00 1.16
  +++ LoaderInterceptor11.java  2001/08/21 04:58:22 1.17
  @@ -78,9 +78,14 @@
* @author [EMAIL PROTECTED]
*/
   public class LoaderInterceptor11 extends BaseInterceptor {
  -boolean useAL=true;
  +boolean useAppsL=true;
  +boolean useParentL=false;
  +boolean useCommonL=false;
  +boolean useContainerL=false;
   boolean useNoParent=false;
  +
   private int attributeInfo;
  +String loader=null;
   
   public LoaderInterceptor11() {
   }
  @@ -89,7 +94,7 @@
*  that is set by the application embedding tomcat.
*/
   public void setUseApplicationLoader( boolean b ) {
  - useAL=b;
  + useAppsL=b;
   }
   
   /** Use no parent loader. The contexts will be completely isolated.
  @@ -98,6 +103,10 @@
useNoParent=b;
   }
   
  +public void setLoader( String name ) {
  + loader=name;
  +}
  +
   public void engineInit( ContextManager cm )
throws TomcatException
   {
  @@ -198,9 +207,9 @@
   }
   
ClassLoader parent=null;
  - if( useAL  !context.isTrusted() ) {
  + if( useAppsL  !context.isTrusted() ) {
if( debug  0 ) log( Using webapp loader  + context.isTrusted());
  - parent=cm.getParentLoader();
  + parent=cm.getAppsLoader();
} else if( useNoParent ) {
if( debug  0 ) log( Using no parent loader );
parent=null;
  
  
  



cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config LogSetter.java

2001-08-20 Thread costin

costin  01/08/20 21:58:51

  Modified:src/share/org/apache/tomcat/modules/config LogSetter.java
  Log:
  Update for the fix in util.log
  
  Revision  ChangesPath
  1.14  +6 -1  
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/LogSetter.java
  
  Index: LogSetter.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/LogSetter.java,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- LogSetter.java2001/08/12 02:11:09 1.13
  +++ LogSetter.java2001/08/21 04:58:51 1.14
  @@ -287,7 +287,12 @@
   /** Adapter and registry for QueueLoggers
*/
   static class TomcatLogManager extends LogManager {
  -
  + TomcatLogManager() {
  + // can't be changed after this
  + LogManager olm=Log.setLogManager( this ); 
  + this.loggers=olm.getLoggers();
  + this.channels=olm.getChannels();
  + }
   
   }
   
  
  
  



cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config PolicyLoader.java PolicyInterceptor.java

2001-08-20 Thread costin

costin  01/08/20 22:10:38

  Modified:src/share/org/apache/tomcat/modules/config PolicyLoader.java
PolicyInterceptor.java
  Log:
  Fixes in sandboxing.
  
  Add a message advising to set -Djava.security.policy. On some VMs it is possible
  to set it later, but in some it isn't - the right way to run the sandbox is to
  make sure a policy is defined.
  
  PolicyInterceptor will enable the sandbox - it is not required if you embed
  tomcat and have a different mechanism to set sandboxing. As with other modules,
  it just provide a default and/or template for more advanced modules.
  
  Also added a Policy.refresh(), few more log statements.
  
  Updated the default permissions to include read for lib/common and read/apps
  ( but not read/container, of course ).
  
  Added getClassLoader permission by default, it's needed by jaxp, jaxm, etc.
  
  Added a sandbox option on PolicyLoader to force the use of the sandbox,
  the default is to use it only if a sandbox property is set on context manger.
  
  Revision  ChangesPath
  1.2   +15 -4 
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/PolicyLoader.java
  
  Index: PolicyLoader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/PolicyLoader.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- PolicyLoader.java 2001/01/25 05:07:37 1.1
  +++ PolicyLoader.java 2001/08/21 05:10:38 1.2
  @@ -83,6 +83,7 @@
   public class PolicyLoader extends BaseInterceptor {
   String securityManagerClass=java.lang.SecurityManager;
   String policyFile=null;
  +boolean sandbox=false;
   
   public PolicyLoader() {
   }
  @@ -103,6 +104,13 @@
policyFile=pf;
   }
   
  +/** Enable/disable the module, independent of command line
  + options
  +*/
  +public void setSandbox( boolean b ) {
  + this.sandbox=b;
  +}
  +
   static Jdk11Compat jdk11Compat=Jdk11Compat.getJdkCompat();
   
   public void addInterceptor(ContextManager cm, Context ctx,
  @@ -113,12 +121,15 @@
   
if( ! jdk11Compat.isJava2() )
return;
  - 
  +
  + if( debug  0 )
  + log(Checking for security manager  + cm.getProperty( sandbox ));
// find if PolicyInterceptor has already been loaded
  - if( System.getSecurityManager() != null ||
  + if( sandbox ||
  + System.getSecurityManager() != null ||
cm.getProperty(sandbox) != null )
{
  - log(Found security manager );
  + log(Loading sandbox );
try {
Class c=Class.
forName( org.apache.tomcat.modules.config.PolicyInterceptor );
  @@ -126,7 +137,7 @@
PolicyLoader policyModule=(PolicyLoader)c.newInstance();
policyModule.setSecurityManagerClass( securityManagerClass);
policyModule.setPolicyFile( policyFile );
  -
  + policyModule.setDebug( debug );
cm.addInterceptor( policyModule );
   
// we could also remove PolicyLoader, since it's no longer
  
  
  
  1.11  +39 -14
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/PolicyInterceptor.java
  
  Index: PolicyInterceptor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/PolicyInterceptor.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- PolicyInterceptor.java2001/08/12 02:12:20 1.10
  +++ PolicyInterceptor.java2001/08/21 05:10:38 1.11
  @@ -94,12 +94,21 @@
policyFile=pf;
   }
   
  +public void addInterceptor(ContextManager cm, Context ctx,
  +BaseInterceptor module)
  + throws TomcatException
  +{
  + // Just override parent 
  +}
  +
   /** Set the security manager, so that policy will be used
*/
   public void engineInit(ContextManager cm) throws TomcatException {
if( System.getSecurityManager() != null ) return;
try {
if( null == System.getProperty(java.security.policy)) {
  + log( Setting java.security.policy. This may fail on some VMs, please
  +  +  set it as a system property before starting tomcat);
File f=null;
if( policyFile==null ) {
policyFile=conf/tomcat.policy;
  @@ -113,15 +122,19 @@
try {
policyFile=f.getCanonicalPath();
} catch(IOException ex ) {}
  - log(Setting policy file to  + policyFile);
  - System.setProperty(java.security.policy,
  -policyFile);
  +
  + if( debug  0 )
  + log(Setting policy file to  + 

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config ServerXmlReader.java

2001-08-20 Thread costin

costin  01/08/20 22:11:45

  Modified:src/share/org/apache/tomcat/modules/config
ServerXmlReader.java
  Log:
  Check system properties as well when replacing ${XXX} in server.xml.
  
  Revision  ChangesPath
  1.17  +4 -1  
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ServerXmlReader.java
  
  Index: ServerXmlReader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ServerXmlReader.java,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- ServerXmlReader.java  2001/07/29 00:43:28 1.16
  +++ ServerXmlReader.java  2001/08/21 05:11:45 1.17
  @@ -191,7 +191,10 @@
return cm.getHome();
}
// XXX add other predefined properties
  - return cm.getProperty( key );
  + String s=cm.getProperty( key );
  + if( s==null )
  + s=System.getProperty(key);
  + return s;
}
   }
   
  
  
  



cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config HookSetter.java

2001-08-20 Thread costin

costin  01/08/20 22:13:29

  Added:   src/share/org/apache/tomcat/modules/config HookSetter.java
  Log:
  HookSetter module - it'll make sure the hooks contain only the modules that
  have overriden the hook method ( keeping the invocation chain at the minimum).
  
  It used to be part of ServerXmlReader, but we need it for cases when server.xml
  is not used to start tomcat ( i.e. EmbeddedTomcat ).
  
  Revision  ChangesPath
  1.1  
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/HookSetter.java
  
  Index: HookSetter.java
  ===
  /*
   * 
   *
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 1999 The Apache Software Foundation.  All rights
   * reserved.
   *
   * Redistribution and use in source and binary forms, with or without
   * modification, are permitted provided that the following conditions
   * are met:
   *
   * 1. Redistributions of source code must retain the above copyright
   *notice, this list of conditions and the following disclaimer.
   *
   * 2. Redistributions in binary form must reproduce the above copyright
   *notice, this list of conditions and the following disclaimer in
   *the documentation and/or other materials provided with the
   *distribution.
   *
   * 3. The end-user documentation included with the redistribution, if
   *any, must include the following acknowlegement:
   *   This product includes software developed by the
   *Apache Software Foundation (http://www.apache.org/).
   *Alternately, this acknowlegement may appear in the software itself,
   *if and wherever such third-party acknowlegements normally appear.
   *
   * 4. The names The Jakarta Project, Tomcat, and Apache Software
   *Foundation must not be used to endorse or promote products derived
   *from this software without prior written permission. For written
   *permission, please contact [EMAIL PROTECTED]
   *
   * 5. Products derived from this software may not be called Apache
   *nor may Apache appear in their names without prior written
   *permission of the Apache Group.
   *
   * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
   * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
   * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
   * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
   * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
   * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
   * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
   * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
   * SUCH DAMAGE.
   * 
   *
   * This software consists of voluntary contributions made by many
   * individuals on behalf of the Apache Software Foundation.  For more
   * information on the Apache Software Foundation, please see
   * http://www.apache.org/.
   *
   * [Additional notices, if required by prior licensing conditions]
   *
   */
  package org.apache.tomcat.modules.config;
  
  import java.beans.*;
  import java.io.*;
  import java.lang.reflect.*;
  import java.util.Hashtable;
  import java.util.*;
  import java.net.*;
  import org.apache.tomcat.util.res.StringManager;
  import org.apache.tomcat.util.io.FileUtil;
  import org.apache.tomcat.util.xml.*;
  import org.apache.tomcat.core.*;
  import org.apache.tomcat.modules.server.*;
  import org.apache.tomcat.util.log.*;
  import org.apache.tomcat.util.hooks.*;
  import org.apache.tomcat.util.IntrospectionUtils;
  import org.xml.sax.*;
  
  /**
   * Keep hook chains to minimal, using introspection.
   *
   * @author Costin Manolache
   */
  public class HookSetter extends BaseInterceptor {
  
  public HookSetter() {
  }
  
  //  Properties 
  
  //  Hooks 
  
  /** When this module is added, it'll automatically load
   *  a configuration file and add all global modules.
   */
  public void addInterceptor(ContextManager cm, Context ctx,
   BaseInterceptor module)
throws TomcatException
  {
Hooks.setHookFinder( new IntrospectionHookFinder() );
  }
  
  static class IntrospectionHookFinder implements Hooks.HookFinder {
public boolean hasHook( Object o, String hook ) {
return IntrospectionUtils.hasHook( o, hook );
}
  }
  }
  
  
  
  



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

2001-08-20 Thread costin

costin  01/08/20 22:16:37

  Modified:src/share/org/apache/tomcat/modules/mappers
ReloadInterceptor.java
  Log:
  Use the fixed DependLoader. This will probably fail with JDK1.1 ( i.e. reloading
  will not work with 1.1 ). I'll fix this later, it's not a big priority ( reloading
  is important for development, etc - JDK1.1 is too limited anyway, and this would add
  an extra overhead ). Since this is not a critical functionality ( a container without
  reloading is still a valid container ), and small devices don't need this too much,
  it may remain unfixed for a while.
  
  ( well, it's not difficult to fix, but I put it at the end of the queue)
  
  Revision  ChangesPath
  1.9   +6 -2  
jakarta-tomcat/src/share/org/apache/tomcat/modules/mappers/ReloadInterceptor.java
  
  Index: ReloadInterceptor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/mappers/ReloadInterceptor.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- ReloadInterceptor.java2001/06/13 01:42:15 1.8
  +++ ReloadInterceptor.java2001/08/21 05:16:36 1.9
  @@ -152,7 +152,11 @@
   protected void  loaderHook( DependManager dm, Context context ) {
// ReloadInterceptor must be configured _after_ LoaderInterceptor
ClassLoader cl=context.getClassLoader();
  - ClassLoader loader=new DependClassLoader( dm, cl);
  + 
  + ClassLoader loader=
  + new DependClassLoader12( dm, cl,
  +  context.getAttribute( Context.ATTRIB_PROTECTION_DOMAIN));
  +
context.setClassLoader(loader);
context.setAttribute( org.apache.tomcat.classloader, loader);
   }
  @@ -187,7 +191,7 @@
// So far we work as if the admin interface was
// used to remove/add the context.
// Or like the deploytool in J2EE.
  - Context ctx1=new Context();
  + Context ctx1=cm.createContext();
ctx1.setContextManager( cm );
ctx1.setPath(ctx.getPath());
ctx1.setDocBase(ctx.getDocBase());
  
  
  



cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/startup Jspc.java

2001-08-20 Thread costin

costin  01/08/20 22:19:55

  Added:   src/share/org/apache/tomcat/startup Jspc.java
  Log:
  A new startup class, wrapping JspC. It'll set the classpath and all that's needed
  to run it. This simplifies the shell scripts ( and it'll also work for platforms
  where .sh or .bat are not present ).
  
  Jspc was broken in 3.3b1 ( at least on unix ). I didn't tested it too much, but
  it starts and seems to be fine.
  
  Revision  ChangesPath
  1.1  jakarta-tomcat/src/share/org/apache/tomcat/startup/Jspc.java
  
  Index: Jspc.java
  ===
  package org.apache.tomcat.startup;
  
  import java.beans.*;
  import java.io.*;
  import java.io.IOException;
  import java.lang.reflect.*;
  import java.util.Hashtable;
  import java.util.*;
  import java.net.*;
  import org.apache.tomcat.util.res.StringManager;
  import org.apache.tomcat.util.xml.*;
  import org.apache.tomcat.util.compat.*;
  import org.apache.tomcat.util.log.*;
  import org.xml.sax.*;
  import org.apache.tomcat.util.collections.*;
  import org.apache.tomcat.util.IntrospectionUtils;
  
  /**
   * 
   * @author Costin Manolache
   */
  public class Jspc {
  
  Hashtable attributes=new Hashtable();
  String args[];
  String installDir;
  ClassLoader parentL;
  
  public Jspc() {
  }
  
  // Properties 
  
  public void setArgs( String args[]) {
this.args=args;
  }
  
  public void setInstall( String s ) {
installDir=s;
  }
  
  //  execute 
  static Jdk11Compat jdk11Compat=Jdk11Compat.getJdkCompat();
  
  public void execute() throws Exception
  {
if( args!=null )
processArgs( args );
Vector v=new Vector();
String commonDir=installDir + File.separator + lib +
File.separator + container;
IntrospectionUtils.addToClassPath( v, commonDir);
IntrospectionUtils.addToolsJar(v);
String containerDir=installDir + File.separator + lib +
File.separator + container;
IntrospectionUtils.addToClassPath( v, containerDir);
String appsDir=installDir + File.separator + lib +
File.separator + apps;
IntrospectionUtils.addToClassPath( v, appsDir);
URL commonCP[]=
IntrospectionUtils.getClassPath( v );
ClassLoader commonCL=
jdk11Compat.newClassLoaderInstance(commonCP, parentL);
  
Class jspcClass=commonCL.loadClass( org.apache.jasper.JspC);
IntrospectionUtils.callMain( jspcClass, args );
  }

  //  Command-line args processing 
  
  /** Process arguments - set object properties from the list of args.
   */
  public  boolean processArgs(String[] args) {
try {
if( args.length  0   jspc.equalsIgnoreCase( args[0])) {
String args1[]=new String[args.length-1];
System.arraycopy( args,1, args1, 0, args.length-1);
args=args1;
}
setArgs(args);  
// return IntrospectionUtils.processArgs( this, args,getOptions1(),
// null, getOptionAliases());
} catch( Exception ex ) {
ex.printStackTrace();
}
return false;
  }
  
  /** Callback from argument processing
   */
  public void setProperty(String s,Object v) {
if ( dL  0 ) debug( Generic property  + s );
attributes.put(s,v);
  }
  
  /** Called by Main to set non-string properties
   */
  public void setAttribute(String s,Object o) {
if( install.equals( s ) ) {
setInstall( (String)o);
}

  if ( args.equals(s) ) {
args=(String[])o;
}
  if ( parentClassLoader.equals(s) ) {
parentL=(ClassLoader)o;
}
  
  
attributes.put(s,o);
  }
  
  //  Main 
  
  public static void main(String args[] ) {
try {
Jspc task=new Jspc();
task.setArgs( args );
  task.execute();
} catch(Exception ex ) {
ex.printStackTrace();
System.exit(1);
}
  }
  
  private static int dL=10;
  private void debug( String s ) {
System.out.println(Jspc:  + s );
  }
  }
  
  
  



cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/startup EmbededTomcat.java

2001-08-20 Thread costin

costin  01/08/20 22:29:27

  Modified:src/share/org/apache/tomcat/startup EmbededTomcat.java
  Log:
  Ok, this is the big one !
  
  I did a lot of work on this area, now things should be much cleaner and simpler
  ( by my taste ).
  
  First, most of the settings from Main.java are now part of EmbededTomcat. We
  expect people to use EmbededTomcat to include tomcat in other apps, not
  Main - since we need to provide a reach interface and more control.
  
  Main.java is now reduced to the same role as java -jar ( and is equivalent
  with it - or should be ). It just create a simple class loader including all
  the classes in common, and then pass control to EmbededTomcat, which does
  all the real work.
  
  In other words, to embed tomcat you need to include all the common in
  a classpath, then use EmbeddedTomcat as a regular bean - set properties and
  call the methods you need.
  
  EmbededTomcat will set the container environment ( which must be separated
  in another class loader - security and isolation ).
  
  I also added a bit more documentation.
  
  An important change - there is no dependency between ET and container classes
  ( see 2 lines above ).
  
  EmbededTomcat now  works in both modes - if setEstart is used ( equivalent
  with java -jar tomcat.jar estart ), it'll use the hardcoded modules
  ( or an alternate set, depending on your code ). The default, or if
  start command is used on the command line, is to load tomcat using
  server.xml, as before.
  
  Revision  ChangesPath
  1.47  +586 -225  
jakarta-tomcat/src/share/org/apache/tomcat/startup/EmbededTomcat.java
  
  Index: EmbededTomcat.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/startup/EmbededTomcat.java,v
  retrieving revision 1.46
  retrieving revision 1.47
  diff -u -r1.46 -r1.47
  --- EmbededTomcat.java2001/08/17 04:23:00 1.46
  +++ EmbededTomcat.java2001/08/21 05:29:27 1.47
  @@ -5,35 +5,83 @@
   
   import org.apache.tomcat.core.*;
   import org.apache.tomcat.util.log.*;
  -import org.apache.tomcat.modules.server.*;
  +import org.apache.tomcat.util.compat.*;
  +import org.apache.tomcat.util.IntrospectionUtils;
   import java.security.*;
   import java.util.*;
   
  +/* EmbededTomcat is the bean you use to embed tomcat in your application.
  +   Main is a wrapper that will guess TOMCAT_HOME and dispatch to 
  +   tasks performing different actions, including EmbededTomcat.
  +
  +*/
  +
  +/* Required setup:
  +   -  EmbededTomcat is assumed to be loaded in the same class loader with
  +   lib/common, and without lib/container. It'll deal with setting a separate
  +   class loader for container and applications.
  +
  +   - home property must be set, or TOMCAT_HOME env.
  +
  +*/
  +
   /**
  + *
  + *  Use this class to embed tomcat in your application. If all you want is to
  + *  start/stop tomcat, with minimal customization, you can use Main.main()
*
  - *  Wrapper around ContextManager. Use this class to embed tomcat in your
  - *  application if you want to use API-based configuration ( instead
  - *  or in addition to server.xml ).
  + *  This class is designed as a java bean, where you set different properties,
  + *  then call methods to perform actions. The main method is execute, that
  + *  will start tomcat. Few other methods allow to perform different other tasks.
  + *
  + *  EmbededTomcat is usable as an ant task as well, using the TaskAdapter.
  + *  ( see sample - TODO XXX ).
  + * 
  + *  Adding tomcat to your application:
  + * 
  + *  - Create a java class that will act as adapter and start tomcat ( and
  + *hold your customization code ). The class and all the files in
  + *TOMCAT_HOME/lib/common must be available in the class loader.
  + *lib/container and lib/apps should  _not_ be visible, EmbededTomcat
  + *will handle that. All the application files you want visible from 
  + *tomcat must be included as well.
  + *ADVANCED1. Completely separated classloader
*
  - *  The order is important:
  + *  - In your adapter, create an instance of EmbededTomcat.
* 
  - *  1. set properties like workDir and debug
  - *  2. add all interceptors including your application-specific
  - *  3. add the endpoints 
  - *  4. add at least the root context ( you can add more if you want )
  - *  5. call start(). The web service will be operational.
  - *  6. You can add/remove contexts
  - *  7. stop().
  + *  - set properties you want to customize. 
*  
  - *  You can add more contexts after start, but interceptors and  
  - *  endpoints must be set before the first context and root must be
  - *  set before start().
  + *  - add all interceptors including your application-specific. That includes
  + *   the connector modules ( shortcuts are provided for common sets of
  + *   modules and for common connector configuration ).
  + *
  + *  - add 

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/startup Main.java

2001-08-20 Thread costin

costin  01/08/20 22:35:05

  Modified:src/share/org/apache/tomcat/startup Main.java
  Log:
  As expected, Main.java is now smaller. The first argument to Main is used
  to load a bean. It'll only set the common class loader, pass args[] and
  class loader informations, and call execute() method on the bean
  ( ant style ).
  
  Note that the bean itself will process the args. Right now we use magic
  to turn args into setXXX() calls ( like we do for server.xml, or like ant
  does with it's tasks ). Single option arguments are equivalent with
  boolean setters.
  
  Revision  ChangesPath
  1.37  +188 -228  jakarta-tomcat/src/share/org/apache/tomcat/startup/Main.java
  
  Index: Main.java
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/startup/Main.java,v
  retrieving revision 1.36
  retrieving revision 1.37
  diff -u -r1.36 -r1.37
  --- Main.java 2001/07/16 01:09:07 1.36
  +++ Main.java 2001/08/21 05:35:05 1.37
  @@ -1,4 +1,4 @@
  -/* $Id: Main.java,v 1.36 2001/07/16 01:09:07 costin Exp $
  +/* $Id: Main.java,v 1.37 2001/08/21 05:35:05 costin Exp $
* 
*
* The Apache Software License, Version 1.1
  @@ -70,278 +70,238 @@
   import org.apache.tomcat.util.compat.Jdk11Compat;
   
   // The main idea is to have a starter with minimal class loader deps,
  -// and use it to create the initial environment
  +// and use it to create the initial environment. This class is pretty generic,
  +// deps on tomcat are minimal ( depends only on tomcat.util ).
   
   /**
  - Starter class for Tomcat.
  - p
  - This is a replacement/enhancement for the .sh and .bat files - you can
  - use JDK1.2 java -jar tomcat.jar, or ( for jdk 1.1 ) you just need to
  - include a single jar file in the classpath.
  - p
  - This class creates three class loader instances: 
  - ol
  - lia 'common' loader to be the parent of both the server
  - container and also webapp loaders./li
  - lian 'applications' loader to load classes used by all webapps, but
  - not the servlet engine./i
  - lia 'container' loader exclusively for the tomcat servlet engine./li
  - /ol
  - Both the 'apps' loader and 'container' loader have the common loader as
  - the parent class loader.  The class path for each is assembled like so:
  - ul
  - licommon - all elements of the 
  -   codeorg.apache.tomcat.common.classpath/code
  -   property plus all *.jar files found in ${TOMCAT_HOME}/lib/common/.
  -   /li
  - liapps - all elements of the 
  -   codeorg.apache.tomcat.apps.classpath/code
  -   property plus all *.jar files found in ${TOMCAT_HOME}/lib/apps/.
  -   In addition, all classes loaded via the 'common' loader./i
  - licontainer - all jar files found in ${TOMCAT_HOME}/lib/container/ plus 
  -   the class folder ${TOMCAT_HOME}/classes and finally also the utility 
  -   jar file ${JAVA_HOME}/lib/tools.jar.  In addition, all classes loaded
  -   via the common loader./li
  - /ul
  - After creating the above class loaders, this class instantiates, initializes
  - and starts an instance of the class 
codeorg.apache.tomcat.startup.Tomcat/code.
  - p
  - @author Costin Manolache
  - @author Ignacio J. Ortega
  - @author Mel Martinez [EMAIL PROTECTED]
  - @version $Revision: 1.36 $ $Date: 2001/07/16 01:09:07 $
  + * Launcher capable of setting class loader and guessing locations.
  + * p
  + * This is a replacement/enhancement for the .sh and .bat files - you can
  + * use JDK1.2 java -jar [PROGRAM].jar, or ( for jdk 1.1 ) you just need to
  + * include a single jar file in the classpath.
  + * p
  + * The class will first guess it's own location by looking in each classpath
  + * location. It'll then process the command line parameters and based on
  + * a properties file, locate the actual class that will be started.
  + * p
  + * It'll then construct a class loader ( common ) from the content of a
  + * specified directory and/or additionl system property. Based on the first
  + * argument, it'll instantiate a class ( in the created class loader ), set the
  + * parameters, and call it's execute() method.
  + *
  + * @author Costin Manolache
  + * @author Ignacio J. Ortega
  + * @author Mel Martinez [EMAIL PROTECTED]
*/
   public class Main{
  +public static final String PROPERTY_COMMON_LOADER =
  + org.apache.tomcat.common.loader;
   
  -/**
  -name of configuration property to set (using the -D option at
  -startup or via .properties file) to specify the classpath
  -to be used by the ClassLoader shared amongst all web applications
  -(but not by the servlet container).  Specify this string as
  -normal file 

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/startup StopTomcat.java EnableAdmin.java

2001-08-20 Thread costin

costin  01/08/20 22:35:26

  Modified:src/share/org/apache/tomcat/startup StopTomcat.java
EnableAdmin.java
  Log:
  Few fixes.
  
  Revision  ChangesPath
  1.10  +17 -1 
jakarta-tomcat/src/share/org/apache/tomcat/startup/StopTomcat.java
  
  Index: StopTomcat.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/startup/StopTomcat.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- StopTomcat.java   2001/08/17 04:23:00 1.9
  +++ StopTomcat.java   2001/08/21 05:35:26 1.10
  @@ -84,6 +84,7 @@
   // explicit command line params ( for port, host or secret )
   boolean commandLineParams=false;
   String secretFile=null;
  +String args[];
   
   public StopTomcat() 
   {
  @@ -134,10 +135,25 @@
secret=s;
commandLineParams=true;
   }
  +
  +// Generic properties / attributes
  +
  +public void setAttribute(String s, Object o ) {
  +}
  +
  +public void setProperty( String name, String v ) {
  +
  +}
  +
  +public void setArgs( String args[] ) {
  + this.args=args;
  +}
   
   //  Ant execute 
   
   public void execute() throws Exception {
  + if( args!=null )
  + processArgs( args );
System.out.println(sm.getString(tomcat.stop));
try {
stopTomcat(); // stop serving
  @@ -304,7 +320,7 @@
   public static void main(String args[] ) {
try {
StopTomcat tomcat=new StopTomcat();
  - tomcat.processArgs( args );
  + tomcat.setArgs( args );
tomcat.execute();
} catch(Exception ex ) {
System.out.println(sm.getString(tomcat.fatal));
  
  
  
  1.2   +12 -15
jakarta-tomcat/src/share/org/apache/tomcat/startup/EnableAdmin.java
  
  Index: EnableAdmin.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/startup/EnableAdmin.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- EnableAdmin.java  2001/08/17 04:23:00 1.1
  +++ EnableAdmin.java  2001/08/21 05:35:26 1.2
  @@ -8,9 +8,7 @@
   import java.util.*;
   import java.net.*;
   import org.apache.tomcat.util.res.StringManager;
  -import org.apache.tomcat.modules.config.*;
   import org.apache.tomcat.util.xml.*;
  -import org.apache.tomcat.core.*;
   import org.apache.tomcat.util.log.*;
   import org.xml.sax.*;
   import org.apache.tomcat.util.collections.*;
  @@ -25,7 +23,8 @@
   public class EnableAdmin {
   
   Hashtable attributes=new Hashtable();
  -
  +String args[];
  +
   public EnableAdmin() {
   }
   
  @@ -41,6 +40,7 @@
   
   public void setArgs(String args[]) {
attributes.put(args, args);
  + this.args=args;
   }
   
   public void setConfig( String s ) {
  @@ -84,6 +84,14 @@
   
   public void execute() throws Exception
   {
  + if( args!=null ) {
  + boolean ok=processArgs( args );
  + if ( ! ok ) {
  + printUsage();
  + return;
  + }
  + }
  +
System.out.println(Overriding apps-admin settings );
String home=(String)attributes.get(home);
if( home==null) home=(String)attributes.get(install);
  @@ -127,7 +135,6 @@
*/
   public  boolean processArgs(String[] args) {
try {
  - setArgs(args);  
return IntrospectionUtils.processArgs( this, args,getOptions1(),
   null, getOptionAliases());
} catch( Exception ex ) {
  @@ -139,8 +146,6 @@
   /** Callback from argument processing
*/
   public void setProperty(String s,Object v) {
  - if( getOptionAliases().get( s ) !=null )
  - s=(String)getOptionAliases().get( s );
if ( dL  0 ) debug( Generic property  + s );
attributes.put(s,v);
   }
  @@ -148,16 +153,8 @@
   /** Called by Main to set non-string properties
*/
   public void setAttribute(String s,Object o) {
  - if( getOptionAliases().get( s ) !=null )
  - s=(String)getOptionAliases().get( s );
  -
   if ( args.equals(s) ) {
String args[]=(String[])o;
  - boolean ok=processArgs( args );
  - if ( ! ok ) {
  - printUsage();
  - return;
  - }
}
   
   
  @@ -169,7 +166,7 @@
   public static void main(String args[] ) {
try {
EnableAdmin task=new EnableAdmin();
  - task.processArgs( args );
  + task.setArgs(args);
   task.execute();
} catch(Exception ex ) {
ex.printStackTrace();
  
  
  



cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/startup Property.java Tomcat.java

2001-08-20 Thread costin

costin  01/08/20 22:37:16

  Modified:src/share/org/apache/tomcat/startup Tomcat.java
  Added:   src/share/org/apache/tomcat/startup Property.java
  Log:
  Tomcat.java is no longer used/needed, added deprecated mark. It still works, but
  you should use the real beans ( tasks ) that perform the actions you need.
  
  Revision  ChangesPath
  1.64  +16 -71jakarta-tomcat/src/share/org/apache/tomcat/startup/Tomcat.java
  
  Index: Tomcat.java
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/startup/Tomcat.java,v
  retrieving revision 1.63
  retrieving revision 1.64
  diff -u -r1.63 -r1.64
  --- Tomcat.java   2001/08/17 04:23:00 1.63
  +++ Tomcat.java   2001/08/21 05:37:16 1.64
  @@ -11,7 +11,6 @@
   import org.apache.tomcat.modules.config.*;
   import org.apache.tomcat.util.xml.*;
   import org.apache.tomcat.core.*;
  -import org.apache.tomcat.util.log.*;
   import org.xml.sax.*;
   import org.apache.tomcat.util.collections.*;
   import org.apache.tomcat.util.IntrospectionUtils;
  @@ -26,8 +25,9 @@
* 
* It can be used in association with Main.java - in order to set the
* CLASSPATH.
  - * 
  - * @author [EMAIL PROTECTED]
  + *
  + * @deprecated Use individual tasks instead: StopTomcat, EmbededTomcat, 
EnableConfig, etc.
  + * @author Costin Manolache
*/
   public class Tomcat {
   
  @@ -40,7 +40,6 @@
   static final String DEFAULT_CONFIG=conf/server.xml;
   
   Hashtable attributes=new Hashtable();
  -static Log log=Log.getLog( tc_log, Tomcat );
   
   public Tomcat() {
   }
  @@ -50,6 +49,7 @@
if( dL  0 ) debug( setHome  + home );
attributes.put( home, home );
   }
  +
   public void setH(String home) {
setHome( home );
   }
  @@ -110,6 +110,9 @@
   //  execute 
   
   public void execute() throws Exception {
  + if( attributes.get(home)==null )
  + attributes.put(home, System.getProperty(tomcat.home));
  +
if( attributes.get(stop) != null ) {
stopTomcat();
} else if( attributes.get(enableAdmin) != null ){
  @@ -148,49 +151,16 @@
   }
   
   public void startTomcat() throws TomcatException {
  - if( tomcat==null ) tomcat=new EmbededTomcat();
  - setTomcatProperties();
  - 
  - if( ! tomcat.isInitialized() ) {
  - long time1=System.currentTimeMillis();
  - PathSetter pS=new PathSetter();
  - tomcat.addInterceptor( pS );
  -
  - ServerXmlReader sxmlConf=new ServerXmlReader();
  - if( null!=attributes.get( config ) )
  - sxmlConf.setConfig( (String)attributes.get(config) );
  - tomcat.addInterceptor( sxmlConf );
  -
  - tomcat.initContextManager();
  -
  - long time2=System.currentTimeMillis();
  - tomcat.log(Init time   + (time2-time1));
  + try {
  + EmbededTomcat task= new  EmbededTomcat();
  + task.setHome( (String)attributes.get(home) );
  + task.processArgs( (String[])attributes.get(args));
  + task.execute(); 
  + } catch (Exception te) {
  + throw new TomcatException( te );
}
  -
  - long time3=System.currentTimeMillis();
  - tomcat.start();
  - long time4=System.currentTimeMillis();
  - tomcat.log(Startup  + ( time4-time3 ));
  -}
  -
  -private void setTomcatProperties() {
  - if( attributes.get(home) != null )
  - tomcat.setHome( (String)attributes.get(home));
  - if( attributes.get(install) != null )
  - tomcat.setInstall( (String)attributes.get(install));
  - if( attributes.get(parentClassLoader) != null )
  - 
tomcat.setParentClassLoader((ClassLoader)attributes.get(parentClassLoader));
  - if( attributes.get(commonClassLoader) != null )
  - 
tomcat.setCommonClassLoader((ClassLoader)attributes.get(commonClassLoader));
  - if( attributes.get(appsClassLoader) != null )
  - tomcat.setAppsClassLoader( (ClassLoader)attributes.get(appsClassLoader));
  - if( attributes.get(containerClassLoader) != null )
  - tomcat.setContainerClassLoader( 
(ClassLoader)attributes.get(containerClassLoader));
  - if( null!= attributes.get(sandbox))
  - tomcat.setSandbox( true );
   }
   
  -
   //  Command-line args processing 
   
   public static void printUsage() {
  @@ -210,34 +180,12 @@
   System.out.println(In the absence of \-enableAdmin\ and \-stop\, 
Tomcat will be started);
   }
   
  -
  -static String options1[]= { help, stop, sandbox, security,  
enableAdmin };
  -static Hashtable optionAliases=new Hashtable();
  -static Hashtable optionDescription=new Hashtable();
  -static {
  - optionAliases.put(h, home);
  - optionAliases.put(i, install);
  - 

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SessionIdGenerator.java

2001-08-20 Thread costin

costin  01/08/20 22:38:24

  Modified:src/share/org/apache/tomcat/modules/session
SessionIdGenerator.java
  Log:
  Update for the fix in compat.
  
  Revision  ChangesPath
  1.5   +1 -1  
jakarta-tomcat/src/share/org/apache/tomcat/modules/session/SessionIdGenerator.java
  
  Index: SessionIdGenerator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/session/SessionIdGenerator.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- SessionIdGenerator.java   2001/04/21 19:33:11 1.4
  +++ SessionIdGenerator.java   2001/08/21 05:38:24 1.5
  @@ -177,7 +177,7 @@
// We're in a sandbox...
PriviledgedIdGenerator di = new PriviledgedIdGenerator(this, jsIdent);
try {
  - newId= (String)jdk11Compat.doPrivileged(di);
  + newId= (String)jdk11Compat.doPrivileged(di, 
jdk11Compat.getAccessControlContext());
} catch( Exception ex ) {
newId=null;
}
  
  
  



cvs commit: jakarta-tomcat build.xml

2001-08-20 Thread costin

costin  01/08/20 22:41:35

  Modified:.build.xml
  Log:
  Etomcat.jar goes to common ( that EmbededTomcat )
  
  Revision  ChangesPath
  1.148 +1 -1  jakarta-tomcat/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat/build.xml,v
  retrieving revision 1.147
  retrieving revision 1.148
  diff -u -r1.147 -r1.148
  --- build.xml 2001/08/03 02:30:50 1.147
  +++ build.xml 2001/08/21 05:41:35 1.148
  @@ -387,7 +387,7 @@
 include name=org/apache/tomcat/startup/**/
   /jar
   
  -jar jarfile=${tomcat.build}/lib/etomcat.jar
  +jar jarfile=${tomcat.build}/lib/common/etomcat.jar
basedir=${tomcat.build}/classes
manifest=src/build/manifests/manifest.embedded
 include name=org/apache/tomcat/startup/**/
  
  
  



cvs commit: jakarta-tomcat/src/build/manifests manifest.embedded

2001-08-20 Thread costin

costin  01/08/20 22:41:54

  Modified:src/build/manifests manifest.embedded
  Log:
  Update the manifest.
  
  Revision  ChangesPath
  1.2   +1 -1  jakarta-tomcat/src/build/manifests/manifest.embedded
  
  Index: manifest.embedded
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/build/manifests/manifest.embedded,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- manifest.embedded 2001/06/08 02:52:44 1.1
  +++ manifest.embedded 2001/08/21 05:41:54 1.2
  @@ -1,5 +1,5 @@
   Manifest-Version: 1.0
   Main-Class: org.apache.tomcat.startup.EmbededTomcat
  -Class-Path: container/tomcat_util.jar common/tomcat_core.jar 
container/tomcat_modules.jar common/servlet.jar container/facade22.jar 
common/jasper-runtime.jar container/jaxp.jar container/parser.jar
  +Class-Path: tomcat_core.jar servlet.jar jasper-runtime.jar core_util.jar 
connector_util.jar
   
   
  
  
  



cvs commit: jakarta-tomcat/src/shell jspc.sh

2001-08-20 Thread costin

costin  01/08/20 22:43:24

  Modified:src/shell jspc.sh
  Log:
  Fixed tomcat.sh jspc ( which was broken ), jspc.sh will just call that ( like
  startup.sh, shutdown.sh, etc )
  
  Revision  ChangesPath
  1.4   +3 -96 jakarta-tomcat/src/shell/jspc.sh
  
  Index: jspc.sh
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/shell/jspc.sh,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- jspc.sh   2001/06/29 20:53:53 1.3
  +++ jspc.sh   2001/08/21 05:43:23 1.4
  @@ -1,103 +1,10 @@
   #!/bin/sh
   #
  -# $Id: jspc.sh,v 1.3 2001/06/29 20:53:53 hgomez Exp $
  +# $Id: jspc.sh,v 1.4 2001/08/21 05:43:23 costin Exp $
   
   # Shell script to runt JspC
   
  -# There are other, simpler commands to run JspC.   The two
  -# commented commands good replacements. The first works well with
  -# Java Platform 1.1 based runtimes. The second works well with
  -# Java2 Platform based runtimes.
   
  -#jre -cp runner.jar:servlet.jar:classes org.apache.jasper.JspC $*
  -#java -cp runner.jar:servlet.jar:classes org.apache.jasper.JspC $*
  +BASEDIR=`dirname $0`
   
  -if [ -f $HOME/.tomcatrc ] ; then 
  -  . $HOME/.tomcatrc
  -fi
  -
  -if [ $TOMCAT_HOME =  ] ; then
  -  # try to find tomcat
  -  if [ -d ${HOME}/opt/tomcat/conf ] ; then 
  -TOMCAT_HOME=${HOME}/opt/tomcat
  -  fi
  -
  -  if [ -d /opt/tomcat/conf ] ; then 
  -TOMCAT_HOME=/opt/tomcat
  -  fi
  -
  -  ## resolve links - $0 may be a link to ant's home
  -  PRG=$0
  -  progname=`basename $0`
  -  
  -  while [ -h $PRG ] ; do
  -ls=`ls -ld $PRG`
  -link=`expr $ls : '.*- \(.*\)$'`
  -if expr $link : '.*/.*'  /dev/null; then
  - PRG=$link
  -else
  - PRG=`dirname $PRG`/$link
  -fi
  -  done
  -  
  -  TOMCAT_HOME=`dirname $PRG`/..
  -
  -fi
  -
  -if [ -z $JAVA_HOME ] ;  then
  -  JAVACMD=`which java`
  -  if [ -z $JAVACMD ] ; then
  -echo Cannot find JAVA. Please set your PATH.
  -exit 1
  -  fi
  -  JAVA_BINDIR=`dirname $JAVACMD`
  -  JAVA_HOME=$JAVA_BINDIR/..
  -fi
  -
  -if [ $JAVACMD =  ] ; then 
  -   # it may be defined in env - including flags!!
  -   JAVACMD=$JAVA_HOME/bin/java
  -fi
  -
  -
  -oldCP=$CLASSPATH
  - 
  -CLASSPATH=.
  -for i in ${TOMCAT_HOME}/lib/container/* ${TOMCAT_HOME}/lib/common/* ; do
  -  CLASSPATH=${CLASSPATH}:$i
  -done
  -
  -CLASSPATH=${CLASSPATH}:${JAVA_HOME}/lib/tools.jar
  -#echo XXX $CLASSPATH
  -
  -
  -# Backdoor classpath setting for development purposes when all classes
  -# are compiled into a /classes dir and are not yet jarred.
  -if [ -d ${TOMCAT_HOME}/classes ]; then
  -CLASSPATH=${TOMCAT_HOME}/classes:${CLASSPATH}
  -fi
  -
  -if [ $oldCP !=  ]; then
  -CLASSPATH=${CLASSPATH}:${oldCP}
  -fi
  -
  -export CLASSPATH
  -
  -if [ ! -f server.xml ] ; then 
  -   if [ $2 =  ] ; then
  - # Probably we are in a wrong directory, use tomcat_home
  - # If arguments are passed besides start/stop, probably a -f was used,
  - # or the user knows what he's doing
  - echo cd ${TOMCAT_HOME} 
  - cd ${TOMCAT_HOME}
  -   fi
  -fi
  -
  -$JAVACMD org.apache.jasper.JspC $@
  -
  -if [ $oldCP !=  ]; then
  -CLASSPATH=${oldCP}
  -export CLASSPATH
  -else
  -unset CLASSPATH
  -fi
  +$BASEDIR/tomcat.sh start $@
  
  
  



cvs commit: jakarta-tomcat/src/shell tomcat.bat

2001-08-20 Thread costin

costin  01/08/20 22:52:12

  Modified:src/shell tomcat.bat
  Log:
  Update for the new Main.java.
  
  Also removed tomcat ant option, ant is no longer bundled ( it was there in 3.0 
because
  we didn't had a separate release, if I remember corectly ).
  
  For sandbox use, don't specify -Djava.security.manager - PolicyLoader will set one
  based on user options.
  
  Revision  ChangesPath
  1.37  +8 -16 jakarta-tomcat/src/shell/tomcat.bat
  
  Index: tomcat.bat
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/shell/tomcat.bat,v
  retrieving revision 1.36
  retrieving revision 1.37
  diff -u -r1.36 -r1.37
  --- tomcat.bat2001/08/19 22:52:51 1.36
  +++ tomcat.bat2001/08/21 05:52:12 1.37
  @@ -29,7 +29,7 @@
   rem Tomcat, refer to the Tomcat Users Guide (tomcat_ug.html found
   rem in the doc directory.
   rem
  -rem $Id: tomcat.bat,v 1.36 2001/08/19 22:52:51 larryi Exp $
  +rem $Id: tomcat.bat,v 1.37 2001/08/21 05:52:12 costin Exp $
   rem -
   
   
  @@ -99,14 +99,12 @@
   if %1 == start goto startServer
   if %1 == stop goto stopServer
   if %1 == run goto runServer
  -if %1 == ant goto runAnt
   if %1 == env goto doEnv
   if %1 == jspc goto runJspc
   
   :doUsage
  -echo Usage:  tomcat ( ant ^| env ^| jspc ^| run ^| start ^| stop )
  +echo Usage:  tomcat (  env ^| jspc ^| run ^| start ^| stop )
   echo Commands:
  -echo   ant -   Run Ant in Tomcat's environment
   echo   env -   Set up environment variables that Tomcat would use
   echo   jspc -  Run JSPC in Tomcat's environment
   echo   run -   Start Tomcat in the current window
  @@ -117,39 +115,33 @@
   :startServer
   echo Starting Tomcat in new window
   if %2 == -security goto startSecure
  -%_STARTJAVA% %TOMCAT_OPTS% -Dtomcat.home=%TOMCAT_HOME% 
org.apache.tomcat.startup.Main %2 %3 %4 %5 %6 %7 %8 %9
  +%_STARTJAVA% %TOMCAT_OPTS% -Dtomcat.home=%TOMCAT_HOME% 
org.apache.tomcat.startup.Main start %2 %3 %4 %5 %6 %7 %8 %9
   goto cleanup
   
   :startSecure
   echo Starting Tomcat with a SecurityManager
  -%_SECSTARTJAVA% %TOMCAT_OPTS% -Djava.security.manager 
-Djava.security.policy==%TOMCAT_HOME%/conf/tomcat.policy -Dtomcat.home=%TOMCAT_HOME% 
org.apache.tomcat.startup.Main %3 %4 %5 %6 %7 %8 %9
  +%_SECSTARTJAVA% %TOMCAT_OPTS% 
-Djava.security.policy==%TOMCAT_HOME%/conf/tomcat.policy -Dtomcat.home=%TOMCAT_HOME% 
org.apache.tomcat.startup.Main start -sandbox %3 %4 %5 %6 %7 %8 %9
   goto cleanup
   
   :runServer
   rem Running Tomcat in this window
   if %2 == -security goto runSecure
  -%_RUNJAVA% %TOMCAT_OPTS% -Dtomcat.home=%TOMCAT_HOME% org.apache.tomcat.startup.Main 
%2 %3 %4 %5 %6 %7 %8 %9
  +%_RUNJAVA% %TOMCAT_OPTS% -Dtomcat.home=%TOMCAT_HOME% org.apache.tomcat.startup.Main 
start %2 %3 %4 %5 %6 %7 %8 %9
   goto cleanup
   
   :runSecure
   rem Running Tomcat with a SecurityManager
  -%_RUNJAVA% %TOMCAT_OPTS% -Djava.security.manager 
-Djava.security.policy==%TOMCAT_HOME%/conf/tomcat.policy -Dtomcat.home=%TOMCAT_HOME% 
org.apache.tomcat.startup.Main %3 %4 %5 %6 %7 %8 %9
  +%_RUNJAVA% %TOMCAT_OPTS% -Djava.security.policy==%TOMCAT_HOME%/conf/tomcat.policy 
-Dtomcat.home=%TOMCAT_HOME% org.apache.tomcat.startup.Main start -sandbox %3 %4 %5 %6 
%7 %8 %9
   goto cleanup
   
   :stopServer
   rem Stopping the Tomcat Server
  -%_RUNJAVA% %TOMCAT_OPTS% -Dtomcat.home=%TOMCAT_HOME% org.apache.tomcat.startup.Main 
-stop %2 %3 %4 %5 %6 %7 %8 %9
  +%_RUNJAVA% %TOMCAT_OPTS% -Dtomcat.home=%TOMCAT_HOME% org.apache.tomcat.startup.Main 
stop %2 %3 %4 %5 %6 %7 %8 %9
   goto cleanup
   
  -:runAnt
  -rem Run ANT in Tomcat's Environment
  -set CP=%CP%;%TOMCAT_HOME%\lib\ant.jar
  -%_RUNJAVA% %ANT_OPTS% -Dant.home=%TOMCAT_HOME% -Dtomcat.home=%TOMCAT_HOME% 
org.apache.tools.ant.Main %2 %3 %4 %5 %6 %7 %8 %9
  -goto cleanup
  -
   :runJspc
   rem Run JSPC in Tomcat's Environment
  -%_RUNJAVA% %JSPC_OPTS% -Dtomcat.home=%TOMCAT_HOME% org.apache.jasper.JspC %2 %3 %4 
%5 %6 %7 %8 %9
  +%_RUNJAVA% %JSPC_OPTS% -Dtomcat.home=%TOMCAT_HOME% org.apache.tomcat.startup.Main 
jspc %2 %3 %4 %5 %6 %7 %8 %9
   goto cleanup
   
   rem - Set CLASSPATH to Tomcat's Runtime Environment --- 
  
  
  



cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/depend DependClassLoader12.java

2001-08-20 Thread costin

costin  01/08/20 23:09:06

  Modified:src/share/org/apache/tomcat/util/depend
DependClassLoader12.java
  Log:
  Exception mismatch, now fixed.
  
  Revision  ChangesPath
  1.2   +3 -1  
jakarta-tomcat/src/share/org/apache/tomcat/util/depend/DependClassLoader12.java
  
  Index: DependClassLoader12.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/depend/DependClassLoader12.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- DependClassLoader12.java  2001/08/21 04:48:35 1.1
  +++ DependClassLoader12.java  2001/08/21 06:09:06 1.2
  @@ -86,9 +86,11 @@
return loadClassInternal( lname, lresolve );
}
});
  - } catch( Exception ex ) {
  + } catch( PrivilegedActionException pex ) {
  + Exception ex=pex.getException();
if( ex instanceof ClassNotFoundException )
throw (ClassNotFoundException)ex;
  + // unknown - better display it 
ex.printStackTrace();
throw new ClassNotFoundException( name );
}
  
  
  



Ken X Horn has left the building (fwd)

2001-08-20 Thread Rob S.

Pier!!!

I am not very happy with Ken X Horn.

I think i'll try to contact Tim Dawson or John Havranek.

- r

-- Forwarded message --
From: Ken X Horn Ken X 
Horn%ARCORDIA%JPMORGAN_EXTERNAL%JPMHUBDOMAIN%JPMORGAN@jpmorgan.com
Date: Mon, 20 Aug 2001 14:11:09 +0100
Subject: Ken X Horn has left the building

I will be out of the office from 18/08/2001 until 01/01/2099.

I am no longer working at Arcordia. For Portal issues, please contact Tim
Dawson or John Havranek.

For non-work related (shock!), I can be contacted on [EMAIL PROTECTED]

Ken.



This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase  Co., its
subsidiaries and affiliates.