Re: Client Certificates working with mod_jk but not with mod_webapp

[jean-frederic clere]

Markus Maeder wrote:
> 
> Hi
> 
> The problem is, that
> X509Certificate jsseCerts[] = (X509Certificate [])
> request.getAttribute("javax.servlet.request.X509Certificate");
> is null with mod_webapp (but as expected with mod_jk).
> 
> May you please send me the configuration stuff you used in httpd.conf?
> Which versions do you use (Apache, OS DIstribution and Version, Tomcat,
> mod_webapp)?

Apache/1.3.22 Server + mod_ssl
OS - Linux, Solaris and ReliantUnix -
Tomcat and mod_webapp from
http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.2-b2/

> 
> Markus
> 
> Zitat von jean-frederic clere <[EMAIL PROTECTED]>:
> 
> > Markus Maeder wrote:
> > >
> > > Hi
> > >
> > > Some days ago I posted following message in tomcat-user and had one reply
> > > stating he is having the same problem.
> > >
> > > I'd like to fix this problem. Is there somebody already working on this? If
> > not,
> > > which source should I get to track down the problem?
> >
> > What is the problem? It works well on my tests, try the test application I
> > have
> > attached to the mail..
> >
> > >
> > > Markus
> > >
> > > My message in tomcat-user:
> > > --- Markus Maeder <[EMAIL PROTECTED]> wrote:
> > > > Hi!
> > > >
> > > > I was playing around with Tomcat 4.0.1 and couldn't
> > > > get the client certificates
> > > > from apache through mod_webapp. So I tried Tomcat
> > > > 4.0.2 b2 and the build from
> > > > January 27. I even compiled a new mod_webapp
> > > > (1.0.2-tc402).
> > > >
> > > > Then I tried ajp13 and mod_jk. This is working fine
> > > > after I changed my code
> > > > (working in Tomcat 3.2x) from
> > > >
> > > > String certAttribute =
> > > > "javax.servlet.request.X509Certificate";
> > > > X509Certificate certificate =
> > > >
> > > (java.security.cert.X509Certificate)request.getAttribute(certAttribute);
> > > >
> > > > To version for Tomcat 4:
> > > > String certAttribute =
> > > > "javax.servlet.request.X509Certificate";
> > > > X509Certificate certificate[] =
> > > >
> > >
> > (java.security.cert.X509Certificate[])request.getAttribute(certAttribute);
> > > >
> > > > As I think I missed something in the configuration
> > > > of mod_webapp, I wonder, if
> > > > somebody has a working configuration for getting
> > > > client certificates with
> > > > mod_webapp, apache 1.3 and mod_ssl.
> > > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > 
> > > For additional commands, e-mail:
> > 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

##
## httpd.conf -- Apache HTTP server configuration file
##

#
# Based upon the NCSA server configuration files originally by Rob McCool.
#
# This is the main Apache server configuration file.  It contains the
# configuration directives that give the server its instructions.
# See http://www.apache.org/docs/> for detailed information about
# the directives.
#
# Do NOT simply read the instructions in here without understanding
# what they do.  They're here only as hints or reminders.  If you are unsure
# consult the online docs. You have been warned.  
#
# After this file is processed, the server will look for and process
# /usr/local/apache/conf/srm.conf and then /usr/local/apache/conf/access.conf
# unless you have overridden these with ResourceConfig and/or
# AccessConfig directives here.
#
# The configuration directives are grouped into three basic sections:
#  1. Directives that control the operation of the Apache server process as a
# whole (the 'global environment').
#  2. Directives that define the parameters of the 'main' or 'default' server,
# which responds to requests that aren't handled by a virtual host.
# These directives also provide default values for the settings
# of all virtual hosts.
#  3. Settings for virtual hosts, which allow Web requests to be sent to
# different IP addresses or hostnames and have them handled by the
# same Apache server process.
#
# Configuration and logfile names: If the filenames you specify for many
# of the server's control files begin with "/" (or "drive:/" for Win32), the
# server will use that explicit path.  If the filenames do *not* begin
# with "/", the value of ServerRoot is prepended -- so "logs/foo.log"
# with ServerRoot set to "/usr/local/apache" will be interpreted by the
# server as "/usr/local/apache/logs/foo.log".
#

### Section 1: Global Environment
#
# The directives in this section affect the overall operation of Apache,
# such as the number of concurrent requests it can handle or where it
# can find its configuration files.
#

#
# ServerType is either inetd, or standalone.  Inetd mode is only supported on
# Unix platforms.
#
ServerType standalone

#
# ServerRoot: The top of the directory tree under which the server's
# configuration, error, and log files are kept.
#
# NOTE!  If you intend to place this on an NFS (or otherwise network)
# mounted filesys

Re: setContentType

[jean-frederic clere]

Will Droste wrote:
> 
> OS: W2k
> Tomcat: 4.0.1
> Java: 1.3.1
> Using Tomcat as a standalone HTTP/1.1 server.
> 
> Don't know if this is a bug or not..  I do a
> setContentType("text/xml;charset=UnicodeLittle") on the response object
> and
> the response headers are returned in UnicodeLittle not ASCII.

I have done the same with response.setContentType("text/xml;charset=Cp037"); all
(headers + content) are returned in EBCDIC. Sounds like a bug.

>  I only
> expected the body of the request to be UnicodeLittle not the headers and
> status line.  To make things more confusing the chunk encoding lines are
> in
> ASCII and not UnicodeLittle.  If the status line is encoding along the
> headers I expected the whole response to be encoded.
> 
> Thanks for any help in advance.
> 
> Regards,
> Will Droste

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

RE: Tomcat 4 / mod_webapp RPMs available...

[GOMEZ Henri]

>We've been customizing the src rpm's available at:
>
>http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.
>0.1/rpms/
>
>and the mod_webapp rpm at:
>
>http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.
>0.2-b2/rpms/
>
>to produce RPM's that our team feels are stable an logically install on
>Redhat 7.x. We've done a number of things to them.
>
>In mod_webapp:
>
>We fixed a WebAppMount directive placed in the httpd.conf file that was
>incorrect (should have been WebAppDeploy).

Thanks, I miss that patch another time.

>We also check if ServerName is set in httpd.conf and attempt 
>to resolve and
>add it if it is not.

Good

>In the Tomcat RPM's
>
>We moved the install directory back to /var/tomcat/... because 
>some of our
>installers for other software and Location definitions in 
>Apache http.conf
>require it to be there...

Warning, the RPM goal is to enable people use differents versions,
ie Tomcat 3.3 and Tomcat 4, which are not exclusive and could be
used at the same time. So you need in that case 2 differents home
/var/tomcat3 and /var/tomcat4.


>We also set the default ports back to that of
>tomcat 3.2. This makes sense because we never really saw a 
>reason to run
>tomcat 3.2 and 4.0 together on the same machine. We thought if we were
>deploying our Software which uses tomcat4.0 it would be the only tomcat
>servlet engine running on a machine.

But many users asked me to have TC 3.3 and 4.0 at the same time on their
boxes to tests applications migration from Servlet 2.2/1.1 to 2.3/1.2

>We modified the Permissions on the webapps directory to give 
>tomcat group
>users rights to edit files in it, where the 
>/etc/rc.d/init.d/tomcat script
>didn't provide theses permissions previously.

It's bad for security, tomcat shouldn't be allowed to 
be able to write these files, only logs and works dirs

>We altered the sleep hack in /etc/rc.d/init.d/tomcat to wait 
>longer because
>the tomcat-apache connector needs more time to stop. This 
>makes "restart"
>work (although somewhat slower).

Ok

>We tried to do all this while properly updating all the 
>documentation in the
>src and nonarch rpm's.
>
>Our question is:
>Would you like these RPM's to make available via Jakarta? For 
>us it would be
>beneficial if we could point our administrators/installers to 
>an external
>persistent source which we didn't need to maintain for getting 
>the external
>packages (like Tomcat4.0) that are required prior to 
>installing our projects
>packages.

You make many usefull modifications, I'd like to put back
in the original RPM, but I won't touch the home location or
include a potential security with webapps directory.

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

DO NOT REPLY [Bug 6213] New: - Apache, Tomcat 4 & mod_jk.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6213

Apache, Tomcat 4 & mod_jk.

   Summary: Apache, Tomcat 4 & mod_jk.
   Product: Tomcat 4
   Version: 4.0.1 Final
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I'll like to know how to compile/install/configure the mod_jk all together with
Tomcat 4 & Apache 1.3.2x. Can I use the source of Tomcat 3.x?
Thanks for yr help in advance.

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

DO NOT REPLY [Bug 6214] New: - Problems on ClientAuth

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6214

Problems on ClientAuth

   Summary: Problems on ClientAuth
   Product: Tomcat 3
   Version: 3.3 Final
  Platform: PC
OS/Version: Windows 9x
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Config
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Sorry for my bad english but Now I'll try to explain the problem

Running Tomcat 3.3a on Intel Windows 98 I've seen that tomcat doesn't ask the 
browser for client auth. I'm sure I've configured correctly the server.xml 
so what's the problem???

Thank you

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

Re: [PATCH] RETRY: Tomcat 4.0 Docs SSL-Howto

[jean-frederic clere]

pero wrote:
> 
> Hi there,
> 
> I posted this patch a while ago. Noone applied it, so I'm
> wondering if it is too bad or if you are to busy (somehow I
> hope the last thing :)
> 
> I did a new "diff" against the latest version (see attachment).
> 
> Any comments are welcome!
> 
> cheers
> pero
> 
> -Original Message-
> From: pero [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, December 15, 2001 1:48 AM
> To: Tomcat Developers List
> Subject: [PATCH] Tomcat 4.0 Docs SSL-Howto
> 
> Hi,
> 
> last summer I posted a step-by-step instruction on how to install
> a certificate from a certificate authority (such as verisign, thawte...)
> to both tomcat-4 lists.
> Until now I got several (partly private) responses regarding
> this issue and there are questions dealing with that topic on the
> mailinglist, too.
> So I decided to contribute my documentation and put it into the
> ssl-howto.xml found in the webapps/tomcat-docs directory.
> 
> I hope this patch helps some people out of this partly weird procedure
> of installing a trusted certificate.
> 
> I appended a "diff -u", which I thought is the standard format you use
> here (you see, it's my first patch :). I tried to follow all kinds of
> guidelines I could figure out, but if something's wrong - let me know!
> 
> If there are any further questions or comments - just hit "reply"...

I like it - If noone complains I will try to commit it -

> 
> cheers,
> pero
> 
>   
>  Name: ssl-howto.diff
>ssl-howto.diffType: diff files (text/plain)
>  Encoding: quoted-printable
> 
>   
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

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

DO NOT REPLY [Bug 6215] New: - ServletRequest#getRemoteAddr() returns 127.0.0.1 after 2 requests.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6215

ServletRequest#getRemoteAddr() returns 127.0.0.1 after 2 requests.

   Summary: ServletRequest#getRemoteAddr() returns 127.0.0.1 after 2
requests.
   Product: Tomcat 3
   Version: 3.3 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Servlet
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi !

I am testing Apache-tomcat 3.3a on Windows 2000 platform.
and I find an unexpected result.

I started up the tomcat (stand alone)
,and displayed default example URI below several times 
from another machine (over LAN).

(Request Info Example)
/examples/servlet/RequestInfoExample

It shows correct URI 2times.But It shows 127.0.0.1 after that requests.
Does ServletRequest#getRemoteAddr() have some trouble? 

With Regards

Ryo

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

DO NOT REPLY [Bug 5746] - Settting an error page for the status code 500 doesn't display the page.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5746

Settting an error page for the status code 500 doesn't display the page.





--- Additional Comments From [EMAIL PROTECTED]  2002-02-04 11:17 ---
Created an attachment (id=1120)
To test status code (/test/errorCode?statusCode=405)

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

RE: [PATCH] RETRY: Tomcat 4.0 Docs SSL-Howto

[GOMEZ Henri]

>> If there are any further questions or comments - just hit "reply"...
>
>I like it - If noone complains I will try to commit it -
>
>> 

I just ask pedro to send me a plain copy, so let me take 
at look at ;)

PS: Christopher and Eric should take a look also ;)

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

RE: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt

[GOMEZ Henri]

>>   +5958  Wrong mod_jk.conf for path pattern
>Easy enough to fix.  The only question is if we want to change only
>${Server}Config, or do we want to change the mod_jk behavior 
>so that the two
>statements:
>JkMount /myApp/foobar/* ajp13
>  and
>JkMount /myApp/foobar* ajp13
>are the same (i.e. more like )?

Update only Server config since many production sites
use the current JkMount /myApp/foobar/* ajp13 way to 
map their WEBAPP. 

Just to avoid us to upgrade related bugs reports ;)

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

DO NOT REPLY [Bug 6218] New: - Relative links broken for servlets

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6218

Relative links broken for servlets

   Summary: Relative links broken for servlets
   Product: Tomcat 4
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Installable Packages
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The links on the static pages in the servlets section of the examples webapp are
all relative, allowing you to deploy the app anywhere, however the servlets
themselves generate absolute links to /examples/.

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

DO NOT REPLY [Bug 6218] - Relative links broken for servlets

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6218

Relative links broken for servlets





--- Additional Comments From [EMAIL PROTECTED]  2002-02-04 13:04 ---
Created an attachment (id=1123)
Fix

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

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

[jfclere]

jfclere 02/02/04 05:36:07

  Modified:webapps/tomcat-docs/config http11.xml
  Log:
  Arrange webapp link.
  
  Revision  ChangesPath
  1.3   +1 -1  jakarta-tomcat-4.0/webapps/tomcat-docs/config/http11.xml
  
  Index: http11.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/http11.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- http11.xml25 Aug 2001 01:14:13 -  1.2
  +++ http11.xml4 Feb 2002 13:36:07 -   1.3
  @@ -29,7 +29,7 @@
 If you wish to configure the Connector that is used
 for connections to web servers using the WARP protocol (such as the
 mod_webapp connector for Apache 1.3), see
  -  here instead.
  +  here instead.
   
 At server startup time, this Connector will create a
 number of request processing threads (based on the value configured for
  
  
  

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

Re: Apache 1.3.22 and 1.3.23 LoadModule Error with Tomcat 4.0.1

[Jim Jagielski]

Micael Padraig Og mac Grene wrote:
> 
> I am getting an error I cannot find in the lists.  The error, on trying to 
> run Apache, after adding LoadModule and AddModule to conf, I get the error:
> 
> Invalid Command 'LoadModule', perhaps this is mis-spelled or defined by a 
> module not included in the server configuration.
> 
> I downloaded the appropriate mod_webapp.so and copied it to libexec.  Then 
> I added LoadModule and AddModule to the httpd.conf file as 
> directed.  Still, it get this error.  Any ideas?
> 

I would guess that mod_so ain't included. Did you build with support
for DSOs (for Apache)?

-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
 will lose both and deserve neither" - T.Jefferson

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

DO NOT REPLY [Bug 6219] New: - FORM authentication does not work when using AJP connector to IIS (tested in 4.0.1 and 4.0.2b2)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6219

FORM authentication does not work when using AJP connector to IIS (tested in 4.0.1 and 
4.0.2b2)

   Summary: FORM authentication does not work when using AJP
connector to IIS (tested in 4.0.1 and 4.0.2b2)
   Product: Tomcat 4
   Version: 4.0.2 Beta 2
  Platform: All
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: JK/AJP Connector
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


FORM authentication does not work, because inside 
FormAuthenticator.authenticate, getUserPrincipal() never returns null - 
instead, it returns a Principal with empty user name - which is created in 
Ajp13Request.setAjpRequest, in this code:

  String remoteUser = ajp.remoteUser().toString();
  if(remoteUser != null)
setUserPrincipal(new Ajp13Principal(remoteUser));

remoteUser.toString() won't return NULL - it will return empty String (because 
in AJP packet, there actually was a field REMOTE_USER, but with length = 0)

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

RE: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt

[Larry Isaacs]

FYI: I thought I had addressed this issue, but couldn't remeber.
After checking, Tomcat 3.3.1-dev had been ouputing, for
forwardAll="false":

JkMount /myApp/foobar ajp13
JkMount /myApp/foobar/* ajp13

since the middle of December.

Larry

> -Original Message-
> From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
> Sent: Monday, February 04, 2002 7:50 AM
> To: Tomcat Developers List
> Subject: RE: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt
> 
> 
> >>   +5958  Wrong mod_jk.conf for path pattern
> >Easy enough to fix.  The only question is if we want to change only
> >${Server}Config, or do we want to change the mod_jk behavior 
> >so that the two
> >statements:
> >JkMount /myApp/foobar/* ajp13
> >  and
> >JkMount /myApp/foobar* ajp13
> >are the same (i.e. more like )?
> 
> Update only Server config since many production sites
> use the current JkMount /myApp/foobar/* ajp13 way to 
> map their WEBAPP. 
> 
> Just to avoid us to upgrade related bugs reports ;)
> 
> --
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 

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

RE: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt

[Larry Isaacs]

I agree with "latering" 4416.  I have everthing about ready,
so I plan on tagging and assembling 3.3.1-beta1 tonight.

Larry

> -Original Message-
> From: Bill Barker [mailto:[EMAIL PROTECTED]]
> Sent: Monday, February 04, 2002 3:00 AM
> To: Tomcat Developers List
> Subject: Re: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt
> 
> 
> 
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: "Tomcat Developers List" <[EMAIL PROTECTED]>
> Sent: Sunday, February 03, 2002 10:36 PM
> Subject: Re: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt
> 
> 
> > On Sat, 2 Feb 2002, Bill Barker wrote:
> >
> > > >   +4416  URI En/Decoding not working
> > > >   +  (investigate and fix if feasible)
> > > My vote is for LATER, since as I understand the bug it is 
> too late to
> test
> > > this well, and  the fix (if not done right) has the 
> potential to create
> > > security problems.  The fix is to basically flip UEncoder 
> on it's head,
> and
> > > work with "un-safe chars" instead of "safe chars" (as 
> well as to add the
> > > logic to use the encoding).  If Costin (since it's his 
> baby) thinks he's
> up
> > > to it, by all means go for it.  I just don't want to 
> delay the release
> for
> > > the amount of time it would take me to make and be 
> comfortable with the
> fix
> > > (esp. since there is a work-around already).
> >
> > I'm not sure I understand - the bug seems to be about
> > DecodeInterceptor using 8859_1 for decoding, even if a different
> > decoding was found.
> >
> > I don't think it is touching UEncoder and the url encoding/decoding.
> > The url decoding has nothing to do with the charset - we decode
> > %xx as bytes, the url encoding happens after char->byte and decoding
> > happen before byte->char conversions ( i.e. uencoding operates on
> > bytes ).
> My understanding of this is that if the request is for:
> /el-niño.jsp
> then most of the time Tomcat will read it correctly. But it 
> will return for
> requestURI:
> /el-ni%A1o.jso
> The "safe chars" map to the same code points under 
> iso-latin-1 and utf-8
> (that's why they are "safe chars").  UEncoder is strict in 
> what is safe, but
> the RFC isn't.  You are allowed to use exteded chars if the 
> other side is
> capable of detecting the charset.
> >
> > It is possible we have a bug - and a test case would help 
> finding it. The
> > code is quite tricky ( I spent huge amounts of time with 
> charset/encoding
> 
> > issues ), and I agree LATER is good given the risks. But if I have
> > the test case, I can take a look, it may be a simple fix.
> >
> > The way it is supposed to work - first the bytes are url decoded,
> > then we detect the charset, then convert bytes to chars.
> >
> > Am I missing something here ?
> >
> > Costin
> >
> >
> > --
> > To unsubscribe, e-mail:
> 
> > For additional commands, e-mail:
> 
> >
> 
> 
> --
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 

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

DO NOT REPLY [Bug 6223] New: - setContentType changes HTTP headers to type specfied

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6223

setContentType changes HTTP headers to type specfied

   Summary: setContentType changes HTTP headers to type specfied
   Product: Tomcat 4
   Version: 4.0.1 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: HTTP/1.1 Connector
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I do a setContentType("text/xml;charset=UnicodeLittle") on the response object 
and the response headers are returned in UnicodeLittle not ASCII.  If I'm not 
mistaken the RFC2616 says they should be ASCII.  I only expected the body of 
the request to be UnicodeLittle not the headers and status line.  To make 
things more confusing the chunk encoding lines are in ASCII and not 
UnicodeLittle.  If the status line is encoding along the headers I expected the 
whole response to be encoded.

Thanks for any help.

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

Re: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt

[costinm]

On Mon, 4 Feb 2002, Bill Barker wrote:

> My understanding of this is that if the request is for:
> /el-niño.jsp
> then most of the time Tomcat will read it correctly. But it will return for
> requestURI:
> /el-ni%A1o.jso
> The "safe chars" map to the same code points under iso-latin-1 and utf-8
> (that's why they are "safe chars").  UEncoder is strict in what is safe, but
> the RFC isn't.  You are allowed to use exteded chars if the other side is
> capable of detecting the charset.

I wouldn't change this behavior - I think it's better to return the
second form rather than first. The URL is supposed to be 7-bit safe.
It is something you can write on a paper or type on any keyboard.

%A1 is not the same under 8859_1 and utf8 ( AFAIK - I may be
wrong ). And "/el-niño.jsp" is hard to type on a keyboard or to view
for people with non-8859_1 charsets. ( %A1 will have a very different
char ).

IMHO the RFC is clear enough about what a 'safe char' is, and my
understanding was that anything >0x7f isn't.

( the 'encoded' URI is something you are supposed to print, go
to a different computer, type, and get to the page. You can't
type ñ on a chinese or greek keyboard )

Costin



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

RE: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt

[Jonathan Reichhold]

/el-niño.jsp should be sent (per the w3c recommendation) as
/el-nin%c3%b1o.jsp which is a UTF-8 encoded bytes sequences for any
characters which aren't in the ~60 characters allowed from ASCII.  The
encoding used for the byte conversion is not specified in the official
URI spec (RFC 2396), but the w3c in December recommended UTF-8 should be
used by all.  IE and Mozilla already appear to encode requests this way.
The server is technically supposed to attempt to read the bytes as UTF-8
and decode with the platform default as a fallback.

For the record, /el-niño.jsp is /el-nin%f1.jsp if the bytes are encoded
via iso-latin-1.  Any character >0x7f isn't safe will be encoded as 2-4
bytes under UTF-8.  Certain byte sequences are also reserved.  I've
spent a long time with this trying to create truly internationalized
code.

If you look at the Java 1.4 Release Candidate you will see that they now
recognize in URLEncode and URLDecode that this is the correct behaviour.
URLEncode and URLDecode have deprecated methods that don't pass in the
encoding.  I think they should default to UTF-8, but the default is the
platform default. 

The w3c has a good section on this at
http://www.w3.org/International/O-URL-and-ident.html

They also have Java source for encoding/decoding the URI's at
http://www.w3.org/International/O-URL-code.html




-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
Sent: Monday, February 04, 2002 8:57 AM
To: Tomcat Developers List
Subject: Re: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt


On Mon, 4 Feb 2002, Bill Barker wrote:

> My understanding of this is that if the request is for:
> /el-niño.jsp
> then most of the time Tomcat will read it correctly. But it will 
> return for
> requestURI:
> /el-ni%A1o.jso
> The "safe chars" map to the same code points under iso-latin-1 and
utf-8
> (that's why they are "safe chars").  UEncoder is strict in what is
safe, but
> the RFC isn't.  You are allowed to use exteded chars if the other side
is
> capable of detecting the charset.

I wouldn't change this behavior - I think it's better to return the
second form rather than first. The URL is supposed to be 7-bit safe. It
is something you can write on a paper or type on any keyboard.

%A1 is not the same under 8859_1 and utf8 ( AFAIK - I may be wrong ).
And "/el-niño.jsp" is hard to type on a keyboard or to view for people
with non-8859_1 charsets. ( %A1 will have a very different char ).

IMHO the RFC is clear enough about what a 'safe char' is, and my
understanding was that anything >0x7f isn't.

( the 'encoded' URI is something you are supposed to print, go to a
different computer, type, and get to the page. You can't type ñ on a
chinese or greek keyboard )

Costin



--
To unsubscribe, e-mail:

For additional commands, e-mail:




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

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

[jfclere]

jfclere 02/02/04 10:03:13

  Modified:webapps/tomcat-docs/config webapp.xml
  Log:
  Start replacing the FIXMEs by something a little better.
  
  Revision  ChangesPath
  1.2   +56 -5 jakarta-tomcat-4.0/webapps/tomcat-docs/config/webapp.xml
  
  Index: webapp.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/webapp.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- webapp.xml25 Jan 2002 15:21:34 -  1.1
  +++ webapp.xml4 Feb 2002 18:03:12 -   1.2
  @@ -96,10 +96,49 @@
 It supports the following additional attributes (in addition to the
 common attributes listed above):
   
  -  
  +  
   
  -  FIXME - Document any additional configuration attributes
  -  supported by the WARP connector.
  +
  +  The maximum queue length for incoming connection requests when
  +  all possible request processing threads are in use.  Any requests
  +  received when the queue is full will be refused.  The default
  +  value is 10.
  +
  +
  +
  +  The debugging detail level of log messages generated by this
  +  component, with higher numbers creating more detailed output.
  +  If not specified, this attribute is set to zero (0).
  +
  +
  +
  +  The maximum number of request processing threads to be created
  +  by this Connector, which therefore determines the
  +  maximum number of simultaneous requests that can be handled.  If
  +  not specified, this attribute is set to 20.
  +
  +
  +
  +  The number of request processing threads that will be created
  +  when this Connector is first started.  This
  +  attribute should be set to a value smaller than that set for
  +  maxProcessors.  The default value is 5.
  +
  +
  +
  +  The TCP port number on which this Connector
  +  will create a server socket and await incoming connections.  Your
  +  operating system will allow only one server application to listen
  +  to a particular port number on a particular IP address.
  +
  +
  +
  +  Set the applications base directory for Hosts 
  +  created via WARP.
  +  The default value is "webapps".
  +
  +
  +  
   
 
   
  @@ -108,8 +147,20 @@
   
   
   
  -  FIXME - Document any use of a nested Factory
  -  element for communicating with mod_webapp over SSL.
  +  
  +  
  +  mod-webapp offers a specific Engine when running the
  +  Webapp Connector in its own
  +  service.
  +  This Engine allows webapp to create and to map the
  +  Hosts corresponding to the VirtualHost defined in the
  +  httpd.conf file.
  +  The standard implementation of Webapp Engine is
  +  org.apache.catalina.connector.warp.WarpEngine.
  +  It supports the standard Engine.
  +  attributes. 
  +
  +  
   
   
   
  
  
  

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

RE: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt

[costinm]

On Mon, 4 Feb 2002, Jonathan Reichhold wrote:

> /el-niño.jsp should be sent (per the w3c recommendation) as
> /el-nin%c3%b1o.jsp which is a UTF-8 encoded bytes sequences for any
> characters which aren't in the ~60 characters allowed from ASCII.  The
> encoding used for the byte conversion is not specified in the official
> URI spec (RFC 2396), but the w3c in December recommended UTF-8 should be
> used by all.  IE and Mozilla already appear to encode requests this way.
> The server is technically supposed to attempt to read the bytes as UTF-8
> and decode with the platform default as a fallback.

If UTF8 is sent - we're all happy, and %c3%b1 will be used in the
encoded url ( regardless if the requests came url encoded or with
binary UTF8 in it ). That assuming the char encoding is UTF8 for
the body as well ( which should be in any browser that supports
sending the URL as UTF8).

Having the body and the URL in different encoding is very problematic.
Regardless of W3C recommendations, the servlet spec requires 8859_1
if no encoding is detected ( which is a huge problem ).

The current code can deal with the UTF8 corectly, but it can also
deal with old browsers who will send the URL using the same encoding
as the body ( if you are on a 8859_2 browser, it's likely that will
be used for both, I doubt any browser will send UTF8 ).


> For the record, /el-niño.jsp is /el-nin%f1.jsp if the bytes are encoded
> via iso-latin-1.  Any character >0x7f isn't safe will be encoded as 2-4
> bytes under UTF-8.  Certain byte sequences are also reserved.  I've
> spent a long time with this trying to create truly internationalized
> code.

Great to have you on tomcat-dev !



> If you look at the Java 1.4 Release Candidate you will see that they now
> recognize in URLEncode and URLDecode that this is the correct behaviour.
> URLEncode and URLDecode have deprecated methods that don't pass in the
> encoding.  I think they should default to UTF-8, but the default is the
> platform default.

On java's URLEncode - yes, the default should be utf8 ( but it is the
platform default ). On servlets - no, the spec is clear about that,
the default is 8859_1, and there's little we can do about it ( except
complain, which we did in the last year and so ).

I spent a lot of time making sure all URLEncode/URLDecode are done
with the right charset, i.e. whatever is detected from the request
or session ( since most browsers today are just broken )
You can override the default to UTF8 - but that brakes the servlet
spec and we can't ship with this setting on. And I'm sure
there are many bugs and cases the code can't handle.


> The w3c has a good section on this at
> http://www.w3.org/International/O-URL-and-ident.html

Yes, but what's important for now is the reality that most software
is not designed with internationalization in mind ( and browsers
are the the best example ) :-)

Not sending the charset header when a non-standard encoding is used
is absolutely stupid and against http1.1 spec - but it's what we
have.

Costin


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

DO NOT REPLY [Bug 6228] New: - res.sendError sends blank page.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6228

res.sendError sends blank page.

   Summary: res.sendError sends blank page.
   Product: Tomcat 4
   Version: 4.0.1 Final
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Webapp Connector
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have Tomcat 4.0.1 configured as a JSP/Servlet engin for Apache, using Webapp. 
The http service has been removed from server.xml.  A servlet, not created from 
a JSP, has res.sendError(int, String) calls. When executed, only a blank page 
appears.  Since all else works correctly, this might be a bug.

Mike

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

DO NOT REPLY [Bug 6229] New: - Need way to specify where to write catalina.out

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6229

Need way to specify where to write catalina.out

   Summary: Need way to specify where to write catalina.out
   Product: Tomcat 4
   Version: Nightly Build
  Platform: All
OS/Version: Linux
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Catalina's stdout and stderr streams are currently always written to
$CATALINA_BASE/logs/catalina.out.  This path hardcoding lacks flexibility, and
would be better configurable.  Attached is a patch which allows setting of the
(optional) env var CATALINA_OUT to specify where you want the log file written.
 If no value is specified for CATALINA_OUT, a default of
$CATALINA_BASE/logs/catalina.out (the current path) is used.

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

DO NOT REPLY [Bug 6229] - Need way to specify where to write catalina.out

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6229

Need way to specify where to write catalina.out





--- Additional Comments From [EMAIL PROTECTED]  2002-02-04 19:06 ---
Created an attachment (id=1129)
Adds support for the CATALINA_OUT env var

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

DO NOT REPLY [Bug 6215] - ServletRequest#getRemoteAddr() returns 127.0.0.1 after 2 requests.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6215

ServletRequest#getRemoteAddr() returns 127.0.0.1 after 2 requests.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-02-04 19:07 ---


*** This bug has been marked as a duplicate of 4564 ***

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

DO NOT REPLY [Bug 4564] - request.getRemoteAddr() and AccesLog not working

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4564

request.getRemoteAddr() and AccesLog not working

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2002-02-04 19:07 ---
*** Bug 6215 has been marked as a duplicate of this bug. ***

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

[PATCH] JspC package names

[Mike Schrag]

In 4.0.1, JspC commandline tool is not making package names that correspond to 
subdirectories in my context directory (i.e. I need
"/help/testhelp.jsp" to become "help/testhelp.java" and be "package help;").  There is 
a setOutputInDirs method on the
CommandLineContext that seems like it should toggle this feature.  I think I'm 
patching this in the right place... I don't know for
sure that setOutputInDirs is the correct attribute to "piggy back" on, but regardless 
I think other people may find this capability
useful.

Thanks a lot
Mike Schrag


--- JspC.java.orig  Mon Feb  4 14:24:29 2002
+++ JspC.java   Mon Feb  4 14:51:38 2002
@@ -346,6 +346,30 @@
 if (dirset) {
 clctxt.setOutputInDirs(true);
 }
+
+if (dirset) {
+  String packageName = null;
+  StringBuffer packageNameStrBuf = new StringBuffer();
+  if (targetPackage != null) {
+packageNameStrBuf.append(targetPackage);
+  }
+
+  java.util.StringTokenizer packageTokenizer = new 
+java.util.StringTokenizer(file.toString(), File.separator);
+  while (packageTokenizer.hasMoreTokens()) {
+String token = packageTokenizer.nextToken();
+if (packageTokenizer.hasMoreElements()) {
+  if (packageNameStrBuf.length() > 0) {
+packageNameStrBuf.append(".");
+  }
+  packageNameStrBuf.append(token);
+}
+  }
+  if (packageNameStrBuf.length() > 0) {
+packageName = packageNameStrBuf.toString();
+  }
+  clctxt.setServletPackageName(packageName);
+}
+
ArrayList urls = new ArrayList();
 
 if (new File(clctxt.getRealPath("/")).exists()) {



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

RE: [PATCH] JspC package names

[Steve Downey]

I think this has been fixed with the patch to correct bug 5471. That changes
how package names are generated in CommandLineContext. 

I'm glad to see someone else is using jspc. It's been broken so often, I
thought I was the only one.


> -Original Message-
> From: Mike Schrag [mailto:[EMAIL PROTECTED]]
> Sent: Monday, February 04, 2002 2:12 PM
> To: [EMAIL PROTECTED]
> Subject: [PATCH] JspC package names
> 
> 
> In 4.0.1, JspC commandline tool is not making package names 
> that correspond to subdirectories in my context directory (i.e. I need
> "/help/testhelp.jsp" to become "help/testhelp.java" and be 
> "package help;").  There is a setOutputInDirs method on the
> CommandLineContext that seems like it should toggle this 
> feature.  I think I'm patching this in the right place... I 
> don't know for
> sure that setOutputInDirs is the correct attribute to "piggy 
> back" on, but regardless I think other people may find this capability
> useful.
> 
> Thanks a lot
> Mike Schrag
> 

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

Re: [PATCH] JspC package names

[Mike Schrag]

Cool... Looks like I fell victim to the File.separator vs. URI problem that you 
mention in the bug too :) ... I know what you mean
about poor jspc being left hanging -- I've been using a heavily tweaked/patched 3.2 
version for the longest time.  It seems to be a
little better in 4.0 now, at least.

Mike

- Original Message -
From: "Steve Downey" <[EMAIL PROTECTED]>
To: "'Tomcat Developers List'" <[EMAIL PROTECTED]>
Sent: Monday, February 04, 2002 2:50 PM
Subject: RE: [PATCH] JspC package names


> I think this has been fixed with the patch to correct bug 5471. That changes
> how package names are generated in CommandLineContext.
>
> I'm glad to see someone else is using jspc. It's been broken so often, I
> thought I was the only one.
>
>
> > -Original Message-
> > From: Mike Schrag [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, February 04, 2002 2:12 PM
> > To: [EMAIL PROTECTED]
> > Subject: [PATCH] JspC package names
> >
> >
> > In 4.0.1, JspC commandline tool is not making package names
> > that correspond to subdirectories in my context directory (i.e. I need
> > "/help/testhelp.jsp" to become "help/testhelp.java" and be
> > "package help;").  There is a setOutputInDirs method on the
> > CommandLineContext that seems like it should toggle this
> > feature.  I think I'm patching this in the right place... I
> > don't know for
> > sure that setOutputInDirs is the correct attribute to "piggy
> > back" on, but regardless I think other people may find this capability
> > useful.
> >
> > Thanks a lot
> > Mike Schrag
> >
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>


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

DO NOT REPLY [Bug 6160] - HttpServletResponse.flushBuffer() fails to flush data to client

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6160

HttpServletResponse.flushBuffer() fails to flush data to client





--- Additional Comments From [EMAIL PROTECTED]  2002-02-04 20:17 ---
Sorry about this, but I provided some incorrect information about this problem.  
When I attempted to turn the chunking off, I was working on the wrong copy of 
server.xml.  After correcting this, disabling the chunking in the HTTP/1.1 
connector solved the problem.

I am able to get the flushBuffer() method to work using both 1.3 and 1.4 jvm on 
the client and server side.

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

com.apache.catalina.startup.UserConfig Idea.

[Brian Maher]

Currently, only a single Context (which means a single webapp) can be
deployed per user.

However, here at Western Washington University, we are developing multiple
webapps at a time.  To allow this, I wrote some code which is very similar
to the com.apache.catalina.startup.UserConfig.java code that Craig wrote.

Is there any interest in this by the community?  I have an archive with
the source code located here:
http://brimworks.com/personal/programs/catalina.tar.gz

Thanks,
-Brian

--
 Brian MaherCS Major   WWU
 BrimWorks.com  >> Glory to God <<


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

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans MBeanUtils.java ServerLifecycleListener.java

[amyroh]

amyroh  02/02/04 12:28:50

  Modified:catalina/src/share/org/apache/catalina/mbeans
MBeanUtils.java ServerLifecycleListener.java
  Log:
  Add to create MBeanFactory MBean so it's visible to admin application.
  
  Revision  ChangesPath
  1.18  +52 -4 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java
  
  Index: MBeanUtils.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- MBeanUtils.java   3 Feb 2002 00:56:57 -   1.17
  +++ MBeanUtils.java   4 Feb 2002 20:28:49 -   1.18
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java,v
 1.17 2002/02/03 00:56:57 craigmcc Exp $
  - * $Revision: 1.17 $
  - * $Date: 2002/02/03 00:56:57 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java,v
 1.18 2002/02/04 20:28:49 amyroh Exp $
  + * $Revision: 1.18 $
  + * $Date: 2002/02/04 20:28:49 $
*
* 
*
  @@ -107,7 +107,7 @@
*
* @author Craig R. McClanahan
* @author Amy Roh
  - * @version $Revision: 1.17 $ $Date: 2002/02/03 00:56:57 $
  + * @version $Revision: 1.18 $ $Date: 2002/02/04 20:28:49 $
*/
   
   public class MBeanUtils {
  @@ -425,6 +425,34 @@
   
   }
   
  +
  +/**
  + * Create, register, and return an MBean for this
  + * MBeanFactory object.
  + *
  + * @param factory The MBeanFactory to be managed
  + *
  + * @exception Exception if an MBean cannot be created or registered
  + */
  +public static ModelMBean createMBean(MBeanFactory factory)
  +throws Exception {
  +
  +String mname = createManagedName(factory);
  +ManagedBean managed = registry.findManagedBean(mname);
  +if (managed == null) {
  +return null;
  +}
  +String domain = managed.getDomain();
  +if (domain == null)
  +domain = mserver.getDefaultDomain();
  +ModelMBean mbean = managed.createMBean(factory);
  +ObjectName oname = createObjectName(domain, factory);
  +mserver.registerMBean(mbean, oname);
  +return (mbean);
  +
  +}
  +
  +
   /**
* Create, register, and return an MBean for this
* Realm object.
  @@ -911,6 +939,26 @@
   }
   
   
  +/**
  + * Create an ObjectName for this
  + * MBeanFactory object.
  + *
  + * @param domain Domain in which this name is to be created
  + * @param factory The MBeanFactory to be named
  + *
  + * @exception MalformedObjectNameException if a name cannot be created
  + */
  +public static ObjectName createObjectName(String domain,
  +  MBeanFactory factory)
  +throws MalformedObjectNameException {
  +
  +ObjectName name = new ObjectName(domain + ":type=MBeanFactory");
  +
  +return (name);
  +
  +}
  +
  +
   /**
* Create an ObjectName for this
* Realm object.
  
  
  
  1.19  +23 -4 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java
  
  Index: ServerLifecycleListener.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- ServerLifecycleListener.java  31 Jan 2002 23:02:41 -  1.18
  +++ ServerLifecycleListener.java  4 Feb 2002 20:28:49 -   1.19
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java,v
 1.18 2002/01/31 23:02:41 amyroh Exp $
  - * $Revision: 1.18 $
  - * $Date: 2002/01/31 23:02:41 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java,v
 1.19 2002/02/04 20:28:49 amyroh Exp $
  + * $Revision: 1.19 $
  + * $Date: 2002/02/04 20:28:49 $
*
* 
*
  @@ -105,7 +105,7 @@
*
* @author Craig R. McClanahan
* @author Amy Roh
  - * @version $Revision: 1.18 $ $Date: 2002/01/31 23:02:41 $
  + * @version $Revision: 1.19 $ $Date: 2002/02/04 20:28:49 $
*/
   
   public class ServerLifecycleListener
  @@ -237,6 +237,8 @@
   
   try {
   
  +MBeanFactory factory = new MBeanFactory();
  +createMBeans(factory);
   createMBeans(ServerFactory.getServer());
   
   } catch (MBeanException t) {
  @@ -428,

RE: Issues with Tomcat 4.0.1 and WebAppDeploy

[Donna Molinari]

Hello Punky,

I tried this and I am unable to get to the manager, I get

- HTTP Status 404 - /manager

Now what?

-Original Message-
From: Punky Tse [mailto:[EMAIL PROTECTED]]
Sent: Sunday, February 03, 2002 7:50 PM
To: Donna Molinari
Cc: Tomcat Developers List
Subject: Re: Issues with Tomcat 4.0.1 and WebAppDeploy


Donna,

First, what does access_log and error_log say?  Can you see "Web-application
not yet deployed" in error_log?
Second, can you reach http://papeete:88/manager/ ?

Do you start Tomcat before httpd is started?  Try this sequence.  If you use
webapp-1.0.1 you will encounter such problem.

Regards,
Punky


- Original Message -
From: "Donna Molinari" <[EMAIL PROTECTED]>
To: "'Punky Tse'" <[EMAIL PROTECTED]>
Cc: "Donna Molinari" <[EMAIL PROTECTED]>; "Tomcat Developers
List" <[EMAIL PROTECTED]>
Sent: Saturday, February 02, 2002 12:34 AM
Subject: RE: Issues with Tomcat 4.0.1 and WebAppDeploy


> Hello Punky,
>
> Thank you for your response. I was able to get Tomcat and Apache working
> without no errors, but this is what happens now. It doesn't see the
examples
> under Tomcat's webapps directory. Is there something I need to add more
> to the httpd.conf file to point to the webapps directory that examples is
> the vitural URL?   Like the Context directive:
>
> /examples/  /web/jakarta-tomcat-4.0.1/webapps/examples
>
> Tomcat Connection to Examples: http://papeete:8080/examples/
> Apache Connection to Examples, fails with HTTP 404 :
> http://papeete:88/examples/
> Apache Tomcat Connection to web_Info is Successful:
> http://papeete:88/webapp-info/
>
> #
> # VirtualHost example:
> # Almost any Apache directive may go into a VirtualHost container.
> # The first VirtualHost section is used for requests without a known
> # server name.
> #
> WebAppConnection warpConnection warp papeete:8008
> 
> ServerAdmin [EMAIL PROTECTED]
> DocumentRoot "/web/jakarta-tomcat-4.0.1/webapps"
> ServerName papeete.remedy.com
> ErrorLog /web/apache1.3.23/var/log/error_log
> Transferlog /web/apache1.3.23/var/log/access_log
> 
> WebAppDeploy manager warpConnection /manager
> WebAppDeploy examples warpConnection /examples
> WebAppDeploy ROOT warpConnection /
> WebAppInfo /webapp-info
> 
> 
>
> -Original Message-
> From: Punky Tse [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 31, 2002 6:53 PM
> To: Tomcat Developers List
> Cc: Donna Molinari
> Subject: Re: Issues with Tomcat 4.0.1 and WebAppDeploy
>
>
> This line is wrong:
> WebAppDeploy /web/jakarta-tomcat-4.0.1/webapps/examples warpConnection
> /examples
>
> /web/jakarta-tomcat-4.0.1/webapps/examples is not a web application name.
It
> is a file location. Instead,
>
> WebAppDeploy examples warpConnection /examples
>
> should work.
>
> see the description from INSTALL.txt from mod_webapp:
> ===
> WebAppDeploy [application name] [connection name] [url path]
>
> [application name]
> The application name as present in your "webapps" directory in
> Tomcat. For example, if you want to deploy a WAR-based web
> application, your application name will look something like
> "myApplication.war".
> ===
>
> - Punky
>
> - Original Message -
> From: "Donna Molinari" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: "Donna Molinari" <[EMAIL PROTECTED]>
> Sent: Friday, February 01, 2002 5:23 AM
> Subject: FW: Issues with Tomcat 4.0.1 and WebAppDeploy
>
>
> > > Hello Apache,
> > I really need someone help on the following problems and bugs found
> > when trying to use WebAppDeploy. The procedures caused syntax
> > errors, once syntax was fixed received the errors shown below. Attached
> > are my configuration files, I would appreciate someone letting me know
> > if you where successful in using the WARP Connector :-)
> >
> > >  <>   <>  <>  <>
> > > Subject:  Apache 1.3.23 and Tomcat 4.0.1
> > >
> > > How do I enter a bug on the following error. I am unable to get the
> > > WebAppDeploy
> > > working.  Attached please see my configuration files - your
instructions
> > > caused
> > > syntax errors and now there errors after I fixed the syntax errors in
> the
> > > httpd.conf
> > > file.
> > >
> > > Apache error_log File
> > > [Wed Jan 30 18:09:04 2002] [notice] caught SIGTERM, shutting down
> > > [Wed Jan 30 18:09:34 2002] [error] Connection "warpConnection" cannot
> > > connect
> > > [Wed Jan 30 18:09:34 2002] [error] Cannot open connection
> "warpConnection"
> > > [Wed Jan 30 18:09:34 2002] [notice] Apache/1.3.23 (Unix) configured --
> > > resuming normal operations
> > > [Wed Jan 30 18:09:34 2002] [notice] Accept mutex: fcntl (Default:
fcntl)
> > > [Wed Jan 30 18:09:34 2002] [error] Connection "warpConnection" cannot
> > > connect
> > > [Wed Jan 30 18:09:34 2002] [error] Cannot open connection
> "warpConnection"
> > > [Wed Jan 30 18:09:34 2002] [

cvs commit: jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/service AddServiceAction.java AddServiceForm.java SetUpAddServiceAction.java

[manveen]

manveen 02/02/04 09:59:19

  Modified:webapps/admin server.jsp
   webapps/admin/WEB-INF struts-config.xml
   webapps/admin/WEB-INF/classes/org/apache/webapp/admin
ApplicationResources_en.properties
ApplicationResources_es.properties
  Added:   webapps/admin addService.jsp
   webapps/admin/WEB-INF/classes/org/apache/webapp/admin/service
AddServiceAction.java AddServiceForm.java
SetUpAddServiceAction.java
  Log:
  Intermin checkin for "add service" operation implementation.
  
  Revision  ChangesPath
  1.8   +1 -1  jakarta-tomcat-4.0/webapps/admin/server.jsp
  
  Index: server.jsp
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/server.jsp,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- server.jsp31 Jan 2002 05:25:25 -  1.7
  +++ server.jsp4 Feb 2002 17:59:19 -   1.8
  @@ -31,7 +31,7 @@
 
- 
   
  -   

  +   
  
   
   
  
  
  
  1.1  jakarta-tomcat-4.0/webapps/admin/addService.jsp
  
  Index: addService.jsp
  ===
  
  
  <%@ page language="java" %>
  <%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
  <%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
  <%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %>
  <%@ taglib uri="/WEB-INF/controls.tld" prefix="controls" %>
  
  
  
  <%@ include file="header.jsp" %>
  
  
  
  
  
  
  
  
  

  
 
  
 
  

  

  
<%@ include file="buttons.jsp" %>
  
   <%-- Heading --%>
   
   
  
   
  


  

   
 
  
  
  
   
  
  
  
  :
  
 
  
  
  
  
  
  
  

  
  
  

  
   


   

   
 
  
  
  
   
  
  
  
  :
  

  
  
  
  
  :
  
  
   
   
  
  
  
  
  
  :
  
   
   
  
  
  
  
  
  


  
<%@ include file="buttons.jsp" %>
  

  
  
  <%@ include file="footer.jsp" %>
  
  
  
  
  
  
  
  1.22  +25 -5 jakarta-tomcat-4.0/webapps/admin/WEB-INF/struts-config.xml
  
  Index: struts-config.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/struts-config.xml,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- struts-config.xml 31 Jan 2002 19:35:57 -  1.21
  +++ struts-config.xml 4 Feb 2002 17:59:19 -   1.22
  @@ -23,10 +23,14 @@
   
   
  -
  +
   
   
  +
  +
  +
   
   
  @@ -94,6 +98,10 @@
   path="/deleteService.jsp"
   redirect="false"/>
   
  +
  +
   
  @@ -182,9 +190,14 @@
  type="org.apache.webapp.admin.service.SetUpDeleteServiceAction"
  name="deleteServiceForm"
  scope="session">
  -  
  +
  +
  +
  +
  +
   
   
  
  @@ -315,12 +328,19 @@
 scope="request"
  type="org.apache.webapp.admin.SaveUserAction"/>
   
  - 
  +
   
  +   
  +
  +
  
   
   
  
  
  
  1.19  +3 -0  
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_en.properties
  
  Index: ApplicationResources_en.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_en.properties,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- ApplicationResources_en.properties31 Jan 2002 05:25:25 -  1.18
  +++ ApplicationResources_en.properties4 Feb 2002 17:59:19 -   1.19
  @@ -62,6 +62,7 @@
   service.properties=Service Properties
   service.property=Property
   service.value=Value
  +service.create.new=Create New Service
   actions.available.actions=Available Actions
   actions.services.create=Create New Service
   actions.services.delete=Delete Ser

RE: Issues with Tomcat 4.0.1 and WebAppDeploy

[Donna Molinari]

2002-02-04 09:12:04 [org.apache.catalina.connector.warp.WarpConnector]
Connection from papeete/10.40.47.78:54331 to
Hello Punky,

There are many log files with Tomcat and in this log file, I found an
Java Exception in the apache_log.2002-02-04.txt.  Please see
again my attached configuration files, is there something wrong?


 <>  <> 


papeete/10.40.47.78:8008
2002-02-04 09:12:04 WarpEngine[Apache]: Mapping request
2002-02-04 09:12:04 WarpHost[papeete]: Mapping request for Host
2002-02-04 09:12:04
[org.apache.catalina.connector.warp.WarpConfigurationHandler] 
Filter mappings (0)
2002-02-04 09:12:05
[org.apache.catalina.connector.warp.WarpConfigurationHandler] 
Filter mappings (2)
2002-02-04 09:12:05
[org.apache.catalina.connector.warp.WarpConfigurationHandler] 
Filter mappings (0)
2002-02-04 11:04:54 [org.apache.catalina.connector.warp.WarpConnection] 
Exception on socket java.io.IOException: Premature packet header end
at
org.apache.catalina.connector.warp.WarpConnection.recv(WarpConnection.java:2
37)
at
org.apache.catalina.connector.warp.WarpRequestHandler.handle(WarpRequestHand
ler.java:112)
at
org.apache.catalina.connector.warp.WarpConnection.run(WarpConnection.java:19
4)
at java.lang.Thread.run(Thread.java:484)

2002-02-04 11:04:54 [org.apache.catalina.connector.warp.WarpConnection] 
Exception on socket java.io.IOException: Premature packet header end
at
org.apache.catalina.connector.warp.WarpConnection.recv(WarpConnection.java:2
37)
at
org.apache.catalina.connector.warp.WarpRequestHandler.handle(WarpRequestHand
ler.java:112)
at
org.apache.catalina.connector.warp.WarpConnection.run(WarpConnection.java:19
4)
at java.lang.Thread.run(Thread.java:484)



_
Take Care,
Donna J. Molinari 
Solutions Group (WebQA)
Platform Technologies Engineering
Mid-Tier Performance Benchmark
Peregrine Systems, Inc.
Office:   MTV3, Room #1396
Phone:   650-903-5204
Email:mailto:[EMAIL PROTECTED]



From: Donna Molinari [[EMAIL PROTECTED]]
Sent: Monday, February 04, 2002 11:32 AM
To: undisclosed-recipients

##
## httpd.conf -- Apache HTTP server configuration file
##

#
# Based upon the NCSA server configuration files originally by Rob McCool.
#
# This is the main Apache server configuration file.  It contains the
# configuration directives that give the server its instructions.
# See http://www.apache.org/docs/> for detailed information about
# the directives.
#
# Do NOT simply read the instructions in here without understanding
# what they do.  They're here only as hints or reminders.  If you are unsure
# consult the online docs. You have been warned.  
#
# After this file is processed, the server will look for and process
# /web/apache1.3.23/conf/srm.conf and then /web/apache1.3.23/conf/access.conf
# unless you have overridden these with ResourceConfig and/or
# AccessConfig directives here.
#
# The configuration directives are grouped into three basic sections:
#  1. Directives that control the operation of the Apache server process as a
# whole (the 'global environment').
#  2. Directives that define the parameters of the 'main' or 'default' server,
# which responds to requests that aren't handled by a virtual host.
# These directives also provide default values for the settings
# of all virtual hosts.
#  3. Settings for virtual hosts, which allow Web requests to be sent to
# different IP addresses or hostnames and have them handled by the
# same Apache server process.
#
# Configuration and logfile names: If the filenames you specify for many
# of the server's control files begin with "/" (or "drive:/" for Win32), the
# server will use that explicit path.  If the filenames do *not* begin
# with "/", the value of ServerRoot is prepended -- so "logs/foo.log"
# with ServerRoot set to "/usr/local/apache" will be interpreted by the
# server as "/usr/local/apache/logs/foo.log".
#

### Section 1: Global Environment
#
# The directives in this section affect the overall operation of Apache,
# such as the number of concurrent requests it can handle or where it
# can find its configuration files.
#

#
# ServerType is either inetd, or standalone.  Inetd mode is only supported on
# Unix platforms.
#
ServerType standalone

#
# ServerRoot: The top of the directory tree under which the server's
# configuration, error, and log files are kept.
#
# NOTE!  If you intend to place this on an NFS (or otherwise network)
# mounted filesystem then please read the LockFile documentation
# (available at http://www.apache.org/docs/mod/core.html#lockfile>);
# you will save yourself a lot of trouble.
#
ServerRoot "/web/apache1.3.23"

#
# The LockFile directive sets the path to the lockfile used when Apache
# is compiled with either USE_FCNTL_SERIALIZED_ACCEPT or
# USE_FLOCK_SERIALIZED_ACCEPT. This directive should normally be left at
# its default value. The main reason for changing it is if the logs
# directory is NFS mounted, since the lockfile MUST BE STORED ON A LOCAL
# DISK. The PID of the main server process 

[PATCH] configurable jsp servlet base

[Mike Schrag]

Currently the default base class for a JSP is hardcoded into JspC.  The base class can 
be overridden individually for each JSP, but
there is no way to override the default (i.e. if you have your own standard custom 
base class).  This patch adds:

1) a -jspservletbase XXX option to JspC commandling
2) a getJspServletBase() method onto the Options interface
3) an implementation of getJspServletBase() on JspC and EmbededServletOptions (doesn't 
Embedded have 2 d's?) that defaults to the
original return value (Constants.JSP_SERVLET_BASE)
4) modification to JspParseEventListener to retrieve the JspServletBase from the 
Options in the constructor

Mike


diff -u -r -x *.class 
jakarta-tomcat-4.0.1-src-orig/jasper/src/share/org/apache/jasper/EmbededServletOptions.java
 jakarta-tomcat-4.0.1-src/jasper/src/share/org/apache/jasper/EmbededServletOptions.java
--- 
jakarta-tomcat-4.0.1-src-orig/jasper/src/share/org/apache/jasper/EmbededServletOptions.java
 Mon Nov 12 21:02:50 2001
+++ 
+jakarta-tomcat-4.0.1-src/jasper/src/share/org/apache/jasper/EmbededServletOptions.java
+  Mon Feb  4 16:26:12 2002
@@ -133,6 +133,11 @@
  */
 public String jspCompilerPath = null;
 
+   /**
+ * The base class of the compiled JSP servlet.
+ */
+   public String jspServletBase = null;
+
 /**
  * Cache for the TLD locations
  */
@@ -209,6 +214,13 @@
 return jspCompilerPath;
 }
 
+/**
+ * Returns the base class of the compiled JSP servlet.
+ */
+public String getJspServletBase() {
+  return (jspServletBase == null) ? Constants.JSP_SERVLET_BASE : jspServletBase;
+}
+
 public TldLocationsCache getTldLocationsCache() {
return tldLocationsCache;
 }
@@ -318,6 +330,8 @@
 }
 
 this.javaEncoding = config.getInitParameter("javaEncoding");
+
+this.jspServletBase = config.getInitParameter("jspServletBase");
 
// Setup the global Tag Libraries location cache for this
// web-application.
diff -u -r -x *.class 
jakarta-tomcat-4.0.1-src-orig/jasper/src/share/org/apache/jasper/JspC.java 
jakarta-tomcat-4.0.1-src/jasper/src/share/org/apache/jasper/JspC.java
--- jakarta-tomcat-4.0.1-src-orig/jasper/src/share/org/apache/jasper/JspC.java  Mon 
Nov 12 21:02:50 2001
+++ jakarta-tomcat-4.0.1-src/jasper/src/share/org/apache/jasper/JspC.java   Mon 
+Feb  4 16:24:51 2002
@@ -106,6 +106,7 @@
 public static final String SWITCH_WEBAPP_XML = "-webxml";
 public static final String SWITCH_MAPPED = "-mapped";
 public static final String SWITCH_DIE = "-die";
+public static final String SWITCH_JSP_SERVLET_BASE = "-jspservletbase";
 
 public static final int NO_WEBXML = 0;
 public static final int INC_WEBXML = 10;
@@ -129,6 +130,8 @@
 
 //String classPath;
 
+   String jspServletBase;
+
 String targetPackage;
 
 String targetClassName;
@@ -215,6 +218,10 @@
 return System.getProperty("java.class.path");
 }
 
+   public String getJspServletBase() {
+   return (jspServletBase == null) ? Constants.JSP_SERVLET_BASE : 
+jspServletBase;
+   }
+
 int argPos;
 // value set by beutifully obsfucscated java
 boolean fullstop = false;
@@ -311,6 +318,8 @@
 }
 } else if (tok.equals(SWITCH_MAPPED)) {
 mappedFile = true;
+} else if (tok.equals(SWITCH_JSP_SERVLET_BASE)) {
+jspServletBase = nextArg();
 } else if (tok.startsWith(SWITCH_DIE)) {
 try {
 dieLevel = Integer.parseInt(
diff -u -r -x *.class 
jakarta-tomcat-4.0.1-src-orig/jasper/src/share/org/apache/jasper/Options.java 
jakarta-tomcat-4.0.1-src/jasper/src/share/org/apache/jasper/Options.java
--- jakarta-tomcat-4.0.1-src-orig/jasper/src/share/org/apache/jasper/Options.java  
 Mon Nov 12 21:02:50 2001
+++ jakarta-tomcat-4.0.1-src/jasper/src/share/org/apache/jasper/Options.javaMon 
+Feb  4 16:19:38 2002
@@ -142,4 +142,9 @@
  * page servlet.
  */
 public String getJavaEncoding();
+
+   /**
+   * Returns the base class for compiled JSP's.
+   */
+   public String getJspServletBase();
 }
diff -u -r -x *.class 
jakarta-tomcat-4.0.1-src-orig/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java
 
jakarta-tomcat-4.0.1-src/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java
--- 
jakarta-tomcat-4.0.1-src-orig/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java
Mon Nov 12 21:02:50 2001
+++ 
+jakarta-tomcat-4.0.1-src/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java
+ Mon Feb  4 16:31:13 2002
@@ -103,7 +103,7 @@
 JspCompilationContext ctxt;
 ParserController parserCtl;
 
-String jspServletBase = Constants.JSP_SERVLET_BASE;
+String jspServletBase;
 String serviceMethodName = Constants.

DO NOT REPLY [Bug 6229] - Need way to specify where to write catalina.out

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6229

Need way to specify where to write catalina.out





--- Additional Comments From [EMAIL PROTECTED]  2002-02-04 20:55 ---
What about all of the myriad of log files generated by all of the webapps? 
Wouldn't it be a more general feature to pass a system property via an 
environment variable CATALINA_LOGS or something similar that sets the "logs" 
directory? Then all logs are put in a new location. Just moving a single log file 
to a different place seems a bit limited.

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

DO NOT REPLY [Bug 6214] - Problems on ClientAuth

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6214

Problems on ClientAuth





--- Additional Comments From [EMAIL PROTECTED]  2002-02-04 21:05 ---
It is very difficult to debug problems without detailed information. Please
submit more information (e.g. your configuration files, log files, etc.)

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

Re: Multiple URLs/Single IP

[Bojan Smojver]

Now you have me totally confused :-( I'll tell you what I know, and if
that helps you, good. If not, please disregard.

The fact that www.aa.com and www.bb.com have the same IP address makes
them name based virtual hosts. So, you're telling your TC 3.3.x to be
ready to handle things for both www.aa.com and www.bb.com by creating
virtual hosts withing it. If you have Tomcat running on the same box, it
would usually be connected to Apache via mod_jk and listen to address
127.0.0.1 only. So, I'm not certain how the 'one IP' address plays here
at all...

Inside each virtual host, you define applications (contexts). So, you
can have webapps/aa for www.aa.com and webapps/bb for www.bb.com.

That's at least how I run my machines.

Bojan

On Mon, 2002-02-04 at 18:50, Micael Padraig Og mac Grene wrote:
> I am not trying to make www.aa.com into xx.aa.com and yy.aa.com but rather 
> trying to get www.aa.com and ww.bb.com which have the same IP address to be 
> webapps/aa and webapps/bb.  Isn't the virtual hosts the first solution?  I 
> think I am beginning to see how to do this, but I don't see how virtual 
> hosts are the answer.  I must be missing something here.  I have figured 
> out how to get the different URLs into different  tags, but so far 
> they all encompass the same webapps or none.  I have some further ideas on 
> how to avoid that.  We'll see tomorrow.  But, I still do not see how this 
> solves my problem, Apache notwithstanding.
> 
> Miacel


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

bug in /usr/bin/dtomcat3 script in 3-3.3a-2 rpm (mprotect errors intomcat.log)

[Ray Pitmon]

Hi,

I just installed the 3.3a rpms and when I tried starting tomcat with the
/etc/rc.d/init.d/tomcat3 script, all I got was these in the
/var/log/tomcat3/tomcat.log file:

mprotect: Bad address
mprotect reset: Bad address
mprotect reset: Bad address
EmbededTomcat: Startup time 40


right around line 120, there's an '==' in the TOMCAT_OPTS line.  I
removed one = and tomcat started.

thx,

-Ray



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

DO NOT REPLY [Bug 6229] - Need way to specify where to write catalina.out

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6229

Need way to specify where to write catalina.out





--- Additional Comments From [EMAIL PROTECTED]  2002-02-04 21:28 ---
Indeed it would be very nice if Catalina's output streams were supported as
first class logging citizens in server.xml, just as server, access, and
context-specific logs are now.  Such a change was more extensive than I needed
to make to address my immediate need, but would definitely be much appreciated
for consistant logging configuration in the long term.  The attached patch
addresses the problem of re-locating Catalina's stdout and stderr output streams
with the most minimal change possible, and follows the existing style of dealing
with startup parameters and server output streams (i.e. using env vars and
stream redirection via a Bourne shell script, rather Java code and XML
configuration).

I figured I'm not the only one to run into this deficiency, so I might as well
contribute back something which I have implemented now and know to be working. 
Patrick, if you have time to implement and test your proposed change instead of
integrating this patch, I'm all for it.  If not, committing this improvement
will address the immediate problem.

Thanks, Dan

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

Re: Multiple URLs/Single IP

[Micael Padraig Og mac Grene]

Thank you, Bojan.  I am going to try that, and will try to figure out a 
favor for you if it works.  My father told me to always pay back ten times: 
ten times more for a good turn, and ten times more for a bad. Micael

At 08:06 AM 2/5/02 +1100, you wrote:
>Now you have me totally confused :-( I'll tell you what I know, and if
>that helps you, good. If not, please disregard.
>
>The fact that www.aa.com and www.bb.com have the same IP address makes
>them name based virtual hosts. So, you're telling your TC 3.3.x to be
>ready to handle things for both www.aa.com and www.bb.com by creating
>virtual hosts withing it. If you have Tomcat running on the same box, it
>would usually be connected to Apache via mod_jk and listen to address
>127.0.0.1 only. So, I'm not certain how the 'one IP' address plays here
>at all...
>
>Inside each virtual host, you define applications (contexts). So, you
>can have webapps/aa for www.aa.com and webapps/bb for www.bb.com.
>
>That's at least how I run my machines.
>
>Bojan
>
>On Mon, 2002-02-04 at 18:50, Micael Padraig Og mac Grene wrote:
> > I am not trying to make www.aa.com into xx.aa.com and yy.aa.com but rather
> > trying to get www.aa.com and ww.bb.com which have the same IP address 
> to be
> > webapps/aa and webapps/bb.  Isn't the virtual hosts the first solution?  I
> > think I am beginning to see how to do this, but I don't see how virtual
> > hosts are the answer.  I must be missing something here.  I have figured
> > out how to get the different URLs into different  tags, but so far
> > they all encompass the same webapps or none.  I have some further ideas on
> > how to avoid that.  We'll see tomorrow.  But, I still do not see how this
> > solves my problem, Apache notwithstanding.
> >
> > Miacel
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 



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

Re: Multiple URLs/Single IP

[Bojan Smojver]

On Tue, 2002-02-05 at 08:38, Micael Padraig Og mac Grene wrote:
> Thank you, Bojan.  I am going to try that, and will try to figure out a 
> favor for you if it works.  My father told me to always pay back ten times: 
> ten times more for a good turn, and ten times more for a bad. Micael

Hope I didn't give you bad advice. The 'ten times' thingy sounds really
scary ;-)

Bojan


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

Re: bug in /usr/bin/dtomcat3 script in 3-3.3a-2 rpm (mprotect errors in tomcat.log)

[hgomez]

En réponse à Ray Pitmon <[EMAIL PROTECTED]>:

> Hi,
> 
> I just installed the 3.3a rpms and when I tried starting tomcat with
> the
> /etc/rc.d/init.d/tomcat3 script, all I got was these in the
> /var/log/tomcat3/tomcat.log file:
> 
> mprotect: Bad address
> mprotect reset: Bad address
> mprotect reset: Bad address
> EmbededTomcat: Startup time 40
> 
> 
> right around line 120, there's an '==' in the TOMCAT_OPTS line.  I
> removed one = and tomcat started.
> 

It seems it was in original tomcat.sh, I'll fix in next RPM release 
Thanks for feedback

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

Header handling bug in class org.apache.Ajp13

[Jianliang Zhao]

I enabled AJP 1.3 connector on Tomcat 4.0.1 with Netscape Server and found a 
NumberFormatException thrown for a HTTP request with non-standard headers. I checked 
out the code from module jakarta-tomcat-connectors with tag tomcat_401. After some 
debuging, it seems the following code is causing the problem:

method: Ajp13.decodeRequest
Between // are my comments. Would you please make this fix and 
let me know where to get a patched tomcat_ajp.jar file?

// Header names are encoded as either an integer code starting
// with 0xA0, or as a normal string (in which case the first
// two bytes are the length).
int isc = msg.peekInt();

   /***/
   // MY DEBUG STATEMENT
System.out.println("header ID: " + isc); // It happens to be 8 for a 
non-standard header
   /***/

int hId = isc & 0xFF;

MessageBytes vMB=null;
isc &= 0xFF00;
if(0xA000 == isc) {

   /***/
   // MY DEBUG STATEMENT
System.out.println("Integer coding: 0xA");
   /***/

msg.getInt(); // To advance the read position
hName = headerTransArray[hId - 1];
vMB= headers.addValue(hName);
} else {
   /***/
/* This branch is executed for the normal string encoding(non-standard 
header case)*/
/* The header ID is also set for the normal string encoding case */
/* I added the following line to fix the problem */
hId = -1; // Should we set hId to dummy number here?
System.out.println("Normal String: 0xA");
   /***/

// XXX Not very elegant
vMB = msg.addHeader(headers);
if (vMB == null) {
return 500; // wrong packet
}
}

msg.getMessageBytes(vMB);

// set content length, if this is it...
if (hId == SC_REQ_CONTENT_LENGTH) {
 /***/
 /* Originally the following line was executed for normal string 
encoding if hId happens to be 8 */
 /* It throws NumberFormatException */
 /***/

 int contentLength = (vMB == null) ? -1 : vMB.getInt();

Thanks,

Jianliang

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

RE: Header handling bug in class org.apache.Ajp13

[Kevin Seguin]

the fix for this is already in cvs and will be part of the next 4.0.2 beta
release.

> -Original Message-
> From: Jianliang Zhao [mailto:[EMAIL PROTECTED]]
> Sent: Monday, February 04, 2002 4:26 PM
> To: Tomcat-dev (E-mail)
> Subject: Header handling bug in class org.apache.Ajp13
> 
> 
> I enabled AJP 1.3 connector on Tomcat 4.0.1 with Netscape 
> Server and found a NumberFormatException thrown for a HTTP 
> request with non-standard headers. I checked out the code 
> from module jakarta-tomcat-connectors with tag tomcat_401. 
> After some debuging, it seems the following code is causing 
> the problem:
> 
> method: Ajp13.decodeRequest
> Between // are my comments. Would you 
> please make this fix and let me know where to get a patched 
> tomcat_ajp.jar file?
> 
>   // Header names are encoded as either an integer 
> code starting
>   // with 0xA0, or as a normal string (in which case the first
>   // two bytes are the length).
> int isc = msg.peekInt();
> 
>
> /***/
>// MY DEBUG STATEMENT
>   System.out.println("header ID: " + isc); // It 
> happens to be 8 for a non-standard header
>
> /***/
> 
> int hId = isc & 0xFF;
> 
>   MessageBytes vMB=null;
> isc &= 0xFF00;
> if(0xA000 == isc) {
> 
>
> /***/
>// MY DEBUG STATEMENT
> System.out.println("Integer coding: 0xA");
>
> /***/
> 
> msg.getInt(); // To advance the read position
> hName = headerTransArray[hId - 1];
>   vMB= headers.addValue(hName);
> } else {
>
> /***/
> /* This branch is executed for the normal 
> string encoding(non-standard header case)*/
> /* The header ID is also set for the normal 
> string encoding case */
> /* I added the following line to fix the problem */
> hId = -1; // Should we set hId to dummy number here?
> System.out.println("Normal String: 0xA");
>
> /***/
> 
>   // XXX Not very elegant
>   vMB = msg.addHeader(headers);
>   if (vMB == null) {
> return 500; // wrong packet
> }
> }
> 
> msg.getMessageBytes(vMB);
> 
> // set content length, if this is it...
> if (hId == SC_REQ_CONTENT_LENGTH) {
>  
> /***/
>  /* Originally the following line was 
> executed for normal string encoding if hId happens to be 8 */
>  /* It throws NumberFormatException */
>  
> /***/
> 
>  int contentLength = (vMB == null) ? -1 : 
> vMB.getInt();
> 
> Thanks,
> 
> Jianliang
> 
> --
> To unsubscribe, e-mail:   

For additional commands, e-mail: 

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

Re: Multiple URLs/Single IP

[Micael Padraig Og mac Grene]

Well, I assumed it was good, and even if not, that you were meaning good. 
So, no problem, my friend!  ;-)

At 09:14 AM 2/5/02 +1100, you wrote:
>On Tue, 2002-02-05 at 08:38, Micael Padraig Og mac Grene wrote:
> > Thank you, Bojan.  I am going to try that, and will try to figure out a
> > favor for you if it works.  My father told me to always pay back ten 
> times:
> > ten times more for a good turn, and ten times more for a bad. Micael
>
>Hope I didn't give you bad advice. The 'ten times' thingy sounds really
>scary ;-)
>
>Bojan
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 



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

DO NOT REPLY [Bug 6229] - Need way to specify where to write catalina.out

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6229

Need way to specify where to write catalina.out





--- Additional Comments From [EMAIL PROTECTED]  2002-02-04 23:06 ---
You may also be able to mimic this functionality by creating a softlink before
you start Tomcat the next time. For example:

   cd $CATLINA_HOME/logs
   # Move existing catalina.out to new location
   mv catalina.out /The/desired/catalina.out/file
   # Create softlink to new location
   ln -s /The/desired/catalina.out/file catalina.out

After you do this, all logging to catalina.out will go your custom location even
after repeated startups.

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

DO NOT REPLY [Bug 6234] New: - checkError method of Servlet's PrintWriter is unreliable

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6234

checkError method of Servlet's PrintWriter is unreliable

   Summary: checkError method of Servlet's PrintWriter is unreliable
   Product: Tomcat 3
   Version: 3.3 Final
  Platform: Other
OS/Version: Windows NT/2K
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Servlet
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Tomcat appears to be recycling PrintWriters.  After a particular PrintWriter's
checkError() method returns true, it always returns true (even after it is
recycled).  I submitted this as a minor bug since there is a simple workaround
(just use getOutputStream()).  

The problem can be demonstrated using the following servlet:


/**
 * To use this test:
 *
 * Hit the servlet with a browser.  "Sending Data" messages will be printed to
 * the brower window at a rate of one per second.  Hit the stop button on your
 * browser (causing checkError() to return true).  Repeat this until you get
 * a response where out.checkError() equals true before any data is sent
 * (it should only take about 5 tries).  This is the problem.
 *
 * From looking at the hashCodes, it looks like the PrintWriters are being
 * recycled and the checkError flag on these printWriters are never being
 * reset.
 *
 * Notice that this problem does not occur when using
 * response.getOutputStream().
 */
public class TestServlet extends HttpServlet {
  public void doGet(HttpServletRequest request, HttpServletResponse response)
throws IOException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();

// Simple workaround.  Servlet will work correctly if following line is
// used instead.
//PrintWriter out = new PrintWriter(response.getOutputStream());

out.println("Entering Servlet:");
out.println("out.hashCode(): " + out.hashCode() + "");
out.println("out.checkError(): " + out.checkError() + "");
while (!out.checkError())
{
  try {Thread.currentThread().sleep(1000);} catch (Exception e) {}
  out.println("Sending Data");
}
  }
}

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

DO NOT REPLY [Bug 6229] - Need way to specify where to write catalina.out

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6229

Need way to specify where to write catalina.out





--- Additional Comments From [EMAIL PROTECTED]  2002-02-05 00:03 ---
Your suggestion predicates me actually having a $CATALINA_BASE/logs/ directory
(which I am trying to avoid since my operations folks prefer all of our
application's logs go elsewhere -- Catalina was the only holdout until I patched
the startup script).

Symlinks are known as the goto statement of the file system (with good reason).
 I would prefer not to introduce any more hacks into my production system, which
is why I offered a reasonable interface following the existing conventions.


Thanks, Dan

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

DO NOT REPLY [Bug 6235] New: - tomcat4-4.0.1-1 rpm has wrong owner for /var/tomcat4/webapps

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6235

tomcat4-4.0.1-1 rpm has wrong owner for /var/tomcat4/webapps

   Summary: tomcat4-4.0.1-1 rpm has wrong owner for
/var/tomcat4/webapps
   Product: Tomcat 4
   Version: 4.0.1 Final
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Major
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


The owner for /var/tomcat4/webapps is set to root.  As such tomcat cannot unpack
WARs as it should when started.  The owner for this directory should be tomcat4,
with group tomcat4.

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

Do different virtual hosts have to have different appBase values?

[Micael Padraig Og mac Grene]

[  ]  They do.
Reason:

[  ]   They don't.
Reason:



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

DO NOT REPLY [Bug 6236] New: - [PATCH] BUILDING.txt doesn't mention jaas.jar

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6236

[PATCH] BUILDING.txt doesn't mention jaas.jar

   Summary: [PATCH] BUILDING.txt doesn't mention jaas.jar
   Product: Tomcat 4
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


BUILDING.txt doesn't mention jaas.jar but $ ant dist will fail if jaas.jar is
not moved into the same lib directory as ldap.jar. This patch extends section
(10) of BUILDING.txt to include a note about copying jaas.jar as well.

--- BUILDING.txtMon Feb  4 23:02:41 2002
+++ BUILDING.txt-ldap-patched   Tue Feb  5 00:49:00 2002
@@ -228,9 +228,10 @@
 * Unpack the reference implementation into a convenient location so that
   it resides in its own subdirectory.
 
-* You will also need the "LDAP Provider" (ldap.jar), available on the
-  same download page.  Be sure that you unpack "ldap.jar" into the "lib"
-  subdirectory of the JNDI directory, parallel to "jndi.jar".
+* You will also need the LDAP Service Provider Maintenance package,
+  (version 1.2.3 or later) available on the same download page. Be sure
+  that you unpack "ldap.jar" and "jaas.jar" into the "lib" subdirectory of
+  the JNDI directory, parallel to "jndi.jar".
 
 
 (11) Steps (12)-(23) are optional, but are necessary to build a complete binary

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

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

[larryi]

larryi  02/02/04 17:22:43

  Modified:src/share/org/apache/tomcat/modules/generators
ErrorHandler.java
  Log:
  Fix for Bug 4600.
  
  Make the default status code for the RedirectHandler configurable.  The
  defaultRedirectStatus attribute may be set to "301" or "302".  This
  default will affect directory redirections done by the StaticInterceptor.
  
  Revision  ChangesPath
  1.24  +19 -2 
jakarta-tomcat/src/share/org/apache/tomcat/modules/generators/ErrorHandler.java
  
  Index: ErrorHandler.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/generators/ErrorHandler.java,v
  retrieving revision 1.23
  retrieving revision 1.24
  diff -u -r1.23 -r1.24
  --- ErrorHandler.java 31 Dec 2001 22:23:42 -  1.23
  +++ ErrorHandler.java 5 Feb 2002 01:22:43 -   1.24
  @@ -81,6 +81,7 @@
   public final class ErrorHandler extends BaseInterceptor {
   private Context rootContext=null;
   boolean showDebugInfo=true;
  +int defaultRedirectStatus=301;
   
   public ErrorHandler() {
   }
  @@ -89,6 +90,15 @@
showDebugInfo=b;
   }
   
  +public void setDefaultRedirectStatus( String s ) {
  +if( "302".equals(s) )
  +defaultRedirectStatus=302;
  +else if( "301".equals(s) )
  +defaultRedirectStatus=301;
  +else
  +defaultRedirectStatus=301;
  +}
  +
   public void engineInit(ContextManager cm ) {
   }
   
  @@ -143,7 +153,9 @@
   
// Default status handlers
   // Assume existing error pages are valid.  Don't overwrite with default.
  - ctx.addServlet( new RedirectHandler(this));
  +RedirectHandler rh = new RedirectHandler(this);
  +rh.setDefaultRedirectStatus(defaultRedirectStatus);
  + ctx.addServlet( rh );
   if (ctx.getErrorPage("302") == null)
   ctx.addErrorPage( "302", "tomcat.redirectHandler");
   if (ctx.getErrorPage("301") == null)
  @@ -765,6 +777,7 @@
   static StringManager sm=StringManager.
getManager("org.apache.tomcat.resources");
   int sbNote=0;
  +int defaultRedirectStatus=301;
   
   RedirectHandler(BaseInterceptor bi) {
//setOrigin( Handler.ORIGIN_INTERNAL );
  @@ -772,6 +785,10 @@
setModule( bi );
   }
   
  +public void setDefaultRedirectStatus( int status ) {
  +defaultRedirectStatus=status;
  +}
  +
   // We don't want interceptors called for redirect
   // handler
   public void doService(Request req, Response res)
  @@ -783,7 +800,7 @@
   
if( res.getStatus() != 301 &&
res.getStatus() != 302 ) {
  - res.setStatus( 301 );
  + res.setStatus( defaultRedirectStatus );
}

location = makeAbsolute(req, location);
  
  
  

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

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

[larryi]

larryi  02/02/04 17:30:29

  Modified:src/share/org/apache/tomcat/modules/config AutoWebApp.java
  Log:
  Add a reloadable attribute so auto-served contexts can be easily configured
  to have reloading enabled or disabled.
  
  This was added because the ReloadInterceptor can't be removed when
  running Tomcat under a security manager.  The DependClassLoader it
  creates handles the ProtectionDomain created for each web application.
  Instead, you must disable reloading for each context instead of removing the
  ReloadInterceptor to gain a performance benefit.
  
  Revision  ChangesPath
  1.11  +6 -0  
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/AutoWebApp.java
  
  Index: AutoWebApp.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/AutoWebApp.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- AutoWebApp.java   14 Nov 2001 03:01:16 -  1.10
  +++ AutoWebApp.java   5 Feb 2002 01:30:29 -   1.11
  @@ -89,6 +89,7 @@
   String profile=null;
   boolean trusted=false;
   String prefix="";
  +boolean reloadable=true;
   
   // encoding scheme - XXX review, customize, implement
   char hostSeparator='@'; // if support for vhost configuration is enabled
  @@ -159,6 +160,10 @@
   public void setTrusted( boolean b ) {
trusted=b;
   }
  +
  +public void setReloadable( boolean b ) {
  +reloadable=b;
  +}
   
   // Implementation 
   
  @@ -256,6 +261,7 @@
Context ctx=cm.createContext();
ctx.setContextManager( cm );
ctx.setPath(prefix + path);
  +ctx.setReloadable(reloadable);
if( ! "DEFAULT".equals( host ) )
ctx.setHost( host );
try {
  
  
  

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

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

[larryi]

larryi  02/02/04 17:32:05

  Modified:src/share/org/apache/tomcat/util IntrospectionUtils.java
  Log:
  Update to add the "classes" directory before the jars.
  
  Revision  ChangesPath
  1.17  +2 -2  
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.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- IntrospectionUtils.java   23 Jan 2002 23:26:04 -  1.16
  +++ IntrospectionUtils.java   5 Feb 2002 01:32:05 -   1.17
  @@ -586,11 +586,11 @@
   {
Vector jarsV = new Vector();
if( dir!=null ) {
  - addToClassPath( jarsV, dir );
  - // Add dir/classes, if it exists
  + // Add dir/classes first, if it exists
URL url=getURL( dir, "classes");
if( url!=null )
jarsV.addElement(url);
  + addToClassPath( jarsV, dir );
}

if( cpath != null )
  
  
  

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

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server Http10Interceptor.java

[larryi]

larryi  02/02/04 17:34:02

  Modified:src/share/org/apache/tomcat/modules/server
Http10Interceptor.java
  Log:
  Revert back to the delaySocketClose attribute.  The new code turned out
  not to help.
  
  Revision  ChangesPath
  1.32  +11 -17
jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Http10Interceptor.java
  
  Index: Http10Interceptor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Http10Interceptor.java,v
  retrieving revision 1.31
  retrieving revision 1.32
  diff -u -r1.31 -r1.32
  --- Http10Interceptor.java31 Jan 2002 04:16:47 -  1.31
  +++ Http10Interceptor.java5 Feb 2002 01:34:02 -   1.32
  @@ -100,7 +100,7 @@
   {
   private int  timeout = 30;   // 5 minutes as in Apache HTTPD server
   private String reportedname;
  -private int socketCloseDelay = -1;
  +private boolean delaySocketClose = false;
   
   public Http10Interceptor() {
super();
  @@ -123,8 +123,8 @@
   reportedname = reportedName;
   }
   
  -public void setSocketCloseDelay(int d) {
  -socketCloseDelay=d;
  +public void setDelaySocketClose(boolean b) {
  +delaySocketClose=b;
   }
   
   public void setProperty( String prop, String value ) {
  @@ -208,20 +208,14 @@
log( "Error reading request, ignored", e, Log.ERROR);
} 
finally {
  -// When running tests against Tomcat on the same system,
  -// we may need to add a delay before closing the socket
  -// to give the other end of the connection a chance to run
  -if( socketCloseDelay >= 0 ) {
  -if( socketCloseDelay > 0 ) {
  -// if delay is specified, spin for that amount of time
  -// Note: using Thread.sleep(n) exacerbates the problem on
  -// RH Linux 7.1 and maybe others
  -long target = System.currentTimeMillis() + socketCloseDelay;
  -while( target <= System.currentTimeMillis())
  -;
  -} else {
  -Thread.yield();
  -}
  +// When running tests against Tomcat on the same
  +// system, we may need to force a thread switch
  +// before closing the socket to give the other
  +// end of the connection a chance to run
  +if( delaySocketClose ) {
  +try {
  +Thread.sleep(0);
  +} catch (InterruptedException ie) { /* ignore */ }
   }
   
// recycle kernel sockets ASAP
  
  
  

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

StandardSession: should StandardSession.manager be transient?

[jonathan]

I've just been browsing through the StandardSession
(org.apache.catalina.session.StandardSession) implementation in
TC4.0.2-b2 and noticed that the field manager is not transient.

Is this a mistake?

Won't each session have a different manager every time it is
deserialised?

Or have I lost the plot... ;-} (Highly likely...)

Jonathan.

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

Tomcat with IIS 6.0

[Jones, Stephen]

Has anyone tried using Tomcat with IIS 6.0 (any version of Tomcat)? I am
attempting this using the JNI configuration, and not having any luck so far.

This is the webserver that is coming with the new "Windows .NET Server
Family"-- I think a lot of people will need to deploy Tomcat on it.

Any help appreciated (I'll post what I learn as well).

Thanks,
Stephen Jones


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

cvs commit: jakarta-tomcat/src/doc serverxml.html

[larryi]

larryi  02/02/04 18:06:20

  Modified:src/doc  serverxml.html
  Log:
  Document some recent changes and a little rearranging.
  
  Revision  ChangesPath
  1.18  +40 -34jakarta-tomcat/src/doc/serverxml.html
  
  Index: serverxml.html
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/doc/serverxml.html,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- serverxml.html2 Feb 2002 15:58:05 -   1.17
  +++ serverxml.html5 Feb 2002 02:06:19 -   1.18
  @@ -4,7 +4,7 @@
   
   
   
  -  
  +  
 
 
 
  @@ -800,30 +800,23 @@
   Default
 
 
  -dir
  -
  -Directory from which to load the web applictions. Relative paths
  -  are interpreted as relative to TOMCAT_HOME.
  -
  -webapps
  +dir
   
  +Directory from which to load the web applictions. Relative paths
  +  are interpreted as relative to TOMCAT_HOME.
  +webapps
 
 
  -prefix
  -
  -Prefix to add to the context path for each deployed web application.
  -  The context path will consist of the prefix followed subdirectory name.
  -
  -DEFAULT
  -
  +flat
  +Each dir will be treated as a webapp in the same host. If 
false,
  +  each dir will be treated as a host name and its subdirs as
  +  web applications. You can add apps to multiple virtual hosts. 
  +true
 
 
  -host
  -
  -Virtual host into which each application will be deployed.
  -
  -DEFAULT
  -
  +host
  +Virtual host into which each application will be deployed.
  +DEFAULT
 
 
   ignoreDot
  @@ -831,10 +824,17 @@
   true
 
 
  -flat
  -Each dir will be treated as a webapp in the same host. If 
false,
  -  each dir will be treated as a host name and its subdirs as
  -  web applications. You can add apps to multiple virtual hosts. 
  +prefix[Tomcat 3.3.1]
  +Prefix to add to the context path for each deployed web application.
  +  The context path will consist of the prefix followed subdirectory name.
  +empty string
  +  
  +  
  +reloadable
  +If true, reloading will be enabled by default for each context.  If
  +false, reloading will be disabled by default for each context.  This
  +setting, enabled or disabled, may be overridden in an explicit
  +context declaration.
   true
 
   
  @@ -1023,6 +1023,15 @@
   Default
 
 
  +defaultRedirectStatus
  +Sets the default status code for use by the RedirectHandler if as
  +status code has not already been set.  It may be set to "301"
  +or "302". This primarily affects the status code used
  + when the StaticInterceptor module
  + redirects a 7quot;directory" URL that doesn't end with a '/'
  +301
  +  
  +  
   showDebugInfo
   Enables the inclusion of extra information in the default error output,
 such as stack traces. This extra information can expose data about
  @@ -1064,16 +1073,13 @@
   null, use default Tomcat server string
 
 
  -socketCloseDelay[Tomcat 3.3.1]
  -When set to 0, a Thread.yield() is executed just prior to closing
  -  the socket for a request. When set greater than 0, the thread will
  -  "spin" in a wait loop for the specified number of milliseconds
  -  before closing the socket. If less than 0, no extra action is performed
  -  before closing the socket.
  -  This delay can help when running tests against Tomcat on certain systems
  -  where the normal sequence of thread execution between Tomcat and client
  -  results in a "Socket reset by peer" error.
  --1
  +delaySocketClose[Tomcat 3.3.1]
  +When set true, a Thread.sleep(0) is executed just prior to closing
  +  the socket for a request. This can help when running a test against
  +  Tomcat on a very fast system. Otherwise, thread execution may complete
  +  the socket close before the test thread gets a chance to read the data
  +  resulting in a "Connection aborted by peer" error.
  +false
 
 
   Connection Properties
  
  
  

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

cvs commit: jakarta-tomcat RELEASE-NOTES-3.3.1.txt

[larryi]

larryi  02/02/04 18:11:00

  Modified:.RELEASE-NOTES-3.3.1.txt
  Log:
  Document latest changes
  
  Revision  ChangesPath
  1.30  +24 -7 jakarta-tomcat/RELEASE-NOTES-3.3.1.txt
  
  Index: RELEASE-NOTES-3.3.1.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat/RELEASE-NOTES-3.3.1.txt,v
  retrieving revision 1.29
  retrieving revision 1.30
  diff -u -r1.29 -r1.30
  --- RELEASE-NOTES-3.3.1.txt   3 Feb 2002 03:53:05 -   1.29
  +++ RELEASE-NOTES-3.3.1.txt   5 Feb 2002 02:11:00 -   1.30
  @@ -3,7 +3,7 @@
Release Notes
=
   
  -$Id: RELEASE-NOTES-3.3.1.txt,v 1.29 2002/02/03 03:53:05 billbarker Exp $
  +$Id: RELEASE-NOTES-3.3.1.txt,v 1.30 2002/02/05 02:11:00 larryi Exp $
   
   
   This document describes the changes that have been made since the
  @@ -85,13 +85,12 @@
the locale and character set encoding of the directory listings
are derived.
   
  - Added a socketCloseDelay attribute to Http10Interceptor.  The
  - default is -1, disabled.  If set to 0, a Thread.yield() is executed
  - before the socket is closed.  If set greater than 0, it spins
  - for the specified amount of time in milliseconds.  This was needed
  - by Cactus when run some systems.  This helps insure the client end
  - of the socket gets a chance to read the returned response before the
  - socket is closed.  Otherwise, "Socket reset by peer" errors occur.
  + Added a delaySocketClose attribute to Http10Interceptor.  The
  + default is false.  If set true, a Thread.sleep(0) is executed
  + before the socket is closed.  This was needed by Cactus when
  + run on a high powered Windows XP box.  The sleep(0) helps ensure
  + the test get a chance to receive its input before the socket
  + is closed.  Otherwise, "Socket reset by peer" errors occur.
   
 Make the App-classloader configurable to allow using the 1.1
 loader even when running under Java2.  This should allow for better
  @@ -120,6 +119,17 @@
security manager, otherwise security exceptions will prevent
JSPs from compiling.
   
  + Added "reloadable" attribute to AutoWebApp module.  If true,
  + reloading will be enabled in all added contexts.  If false, reloading
  + will be disabled.  The default is true.
  +
  + Added "defaultRedirectStatus" attribute to ErrorHandler module. It
  + may be set to "301" or "302".  The default is "301".  It determines
  + the status code set by the "redirect" handler if a status code has
  + not already been set.  This primarily affects the status code used
  + when the StaticInterceptor module redirects a "directory" URL that
  + doesn't end with a '/'.
  +
   
   Server:
   
  @@ -133,6 +143,9 @@
path portion of the request URL.  RFC2396 allows '+' in the path
of a URL.
   
  + Modified IntrospectionUtils.getClassPath() to add "classes"
  + directory to the list prior to jars.
  +
   1657 JSPs with tag names that contain '-' or '.' will now compile without
an "Invalid expression" error
   
  @@ -212,6 +225,7 @@
 reported bug, it was mostly a nuisance.  In other cases (see 6143)
 it was causing major problems.
   
  +
   Configuration:
   
   Bug No.  Description
  @@ -226,6 +240,9 @@
 actually a JSP page.
   
   5365  Fixed the JasperMangler to handle Java reserved words correctly.
  +
  +5958 ApacheConfig, IISConfig, and NSConfig were updated so mappings that
  + end with "/*" will write a mapping with and without the ending "/*".
   
   6004 Updated Http10Connector to accept any attribute.  The attributes
without predefined setters will be included with the predefined
  
  
  

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

Re: Issues with Tomcat 4.0.1 and WebAppDeploy

[Punky Tse]

Hey, why do you change the port from 8008 to 8009? In tomcat connector side,
8008 is for mod_webapp while 8009 is for mod_jk.  Please fall back to 8008
and try again  Your httpd.conf looks rights, but this line:

WebAppDeploy ROOT warpConnection /

I don't know if it can work and may cause error as I haven't try it before.
To aviod any error introduced, you should remove this line until everything
gets right.

server.xml should work without any modification, so please use don't modify
it and use the one from distribution.

Hope that help.

Punky

- Original Message -
From: "Donna Molinari" <[EMAIL PROTECTED]>
To: "'Punky Tse'" <[EMAIL PROTECTED]>
Cc: "Tomcat Developers List" <[EMAIL PROTECTED]>; "Donna
Molinari" <[EMAIL PROTECTED]>
Sent: Tuesday, February 05, 2002 1:15 AM
Subject: RE: Issues with Tomcat 4.0.1 and WebAppDeploy


> Hello Punky,
>
> I tried this and I am unable to get to the manager, I get
>
> - HTTP Status 404 - /manager
>
> Now what?
>
> -Original Message-
> From: Punky Tse [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, February 03, 2002 7:50 PM
> To: Donna Molinari
> Cc: Tomcat Developers List
> Subject: Re: Issues with Tomcat 4.0.1 and WebAppDeploy
>
>
> Donna,
>
> First, what does access_log and error_log say?  Can you see
"Web-application
> not yet deployed" in error_log?
> Second, can you reach http://papeete:88/manager/ ?
>
> Do you start Tomcat before httpd is started?  Try this sequence.  If you
use
> webapp-1.0.1 you will encounter such problem.
>
> Regards,
> Punky
>
>
> - Original Message -
> From: "Donna Molinari" <[EMAIL PROTECTED]>
> To: "'Punky Tse'" <[EMAIL PROTECTED]>
> Cc: "Donna Molinari" <[EMAIL PROTECTED]>; "Tomcat Developers
> List" <[EMAIL PROTECTED]>
> Sent: Saturday, February 02, 2002 12:34 AM
> Subject: RE: Issues with Tomcat 4.0.1 and WebAppDeploy
>
>
> > Hello Punky,
> >
> > Thank you for your response. I was able to get Tomcat and Apache working
> > without no errors, but this is what happens now. It doesn't see the
> examples
> > under Tomcat's webapps directory. Is there something I need to add more
> > to the httpd.conf file to point to the webapps directory that examples
is
> > the vitural URL?   Like the Context directive:
> >
> > /examples/  /web/jakarta-tomcat-4.0.1/webapps/examples
> >
> > Tomcat Connection to Examples: http://papeete:8080/examples/
> > Apache Connection to Examples, fails with HTTP 404 :
> > http://papeete:88/examples/
> > Apache Tomcat Connection to web_Info is Successful:
> > http://papeete:88/webapp-info/
> >
> > #
> > # VirtualHost example:
> > # Almost any Apache directive may go into a VirtualHost container.
> > # The first VirtualHost section is used for requests without a known
> > # server name.
> > #
> > WebAppConnection warpConnection warp papeete:8008
> > 
> > ServerAdmin [EMAIL PROTECTED]
> > DocumentRoot "/web/jakarta-tomcat-4.0.1/webapps"
> > ServerName papeete.remedy.com
> > ErrorLog /web/apache1.3.23/var/log/error_log
> > Transferlog /web/apache1.3.23/var/log/access_log
> > 
> > WebAppDeploy manager warpConnection /manager
> > WebAppDeploy examples warpConnection /examples
> > WebAppDeploy ROOT warpConnection /
> > WebAppInfo /webapp-info
> > 
> > 
> >
> > -Original Message-
> > From: Punky Tse [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, January 31, 2002 6:53 PM
> > To: Tomcat Developers List
> > Cc: Donna Molinari
> > Subject: Re: Issues with Tomcat 4.0.1 and WebAppDeploy
> >
> >
> > This line is wrong:
> > WebAppDeploy /web/jakarta-tomcat-4.0.1/webapps/examples
warpConnection
> > /examples
> >
> > /web/jakarta-tomcat-4.0.1/webapps/examples is not a web application
name.
> It
> > is a file location. Instead,
> >
> > WebAppDeploy examples warpConnection /examples
> >
> > should work.
> >
> > see the description from INSTALL.txt from mod_webapp:
> > ===
> > WebAppDeploy [application name] [connection name] [url path]
> >
> > [application name]
> > The application name as present in your "webapps" directory
in
> > Tomcat. For example, if you want to deploy a WAR-based web
> > application, your application name will look something like
> > "myApplication.war".
> > ===
> >
> > - Punky
> >
> > - Original Message -
> > From: "Donna Molinari" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Cc: "Donna Molinari" <[EMAIL PROTECTED]>
> > Sent: Friday, February 01, 2002 5:23 AM
> > Subject: FW: Issues with Tomcat 4.0.1 and WebAppDeploy
> >
> >
> > > > Hello Apache,
> > > I really need someone help on the following problems and bugs found
> > > when trying to use WebAppDeploy. The procedures caused syntax
> > > errors, once syntax was fixed received the errors shown below.
Attached
> > > are my configuration files, I would appreciate someone letting me know
> > > if you where successful in

cvs commit: jakarta-tomcat/src/doc serverxml.html

[larryi]

larryi  02/02/04 18:19:22

  Modified:src/doc  serverxml.html
  Log:
  Forgot to mention welcome files are affected by defaultRedirectStatus.
  
  Revision  ChangesPath
  1.19  +3 -2  jakarta-tomcat/src/doc/serverxml.html
  
  Index: serverxml.html
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/doc/serverxml.html,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- serverxml.html5 Feb 2002 02:06:19 -   1.18
  +++ serverxml.html5 Feb 2002 02:19:22 -   1.19
  @@ -4,7 +4,7 @@
   
   
   
  -  
  +  
 
 
 
  @@ -1028,7 +1028,8 @@
   status code has not already been set.  It may be set to "301"
   or "302". This primarily affects the status code used
when the StaticInterceptor module
  - redirects a 7quot;directory" URL that doesn't end with a '/'
  + redirects a "directory" URL that doesn't end with a '/' and
  + redirects to welcome files.
   301
 
 
  
  
  

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

cvs commit: jakarta-tomcat RELEASE-NOTES-3.3.1.txt

[larryi]

larryi  02/02/04 18:20:25

  Modified:.RELEASE-NOTES-3.3.1.txt
  Log:
  Forgot to mention welcome files are affected by defaultRedirectStatus.
  
  Revision  ChangesPath
  1.31  +2 -2  jakarta-tomcat/RELEASE-NOTES-3.3.1.txt
  
  Index: RELEASE-NOTES-3.3.1.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat/RELEASE-NOTES-3.3.1.txt,v
  retrieving revision 1.30
  retrieving revision 1.31
  diff -u -r1.30 -r1.31
  --- RELEASE-NOTES-3.3.1.txt   5 Feb 2002 02:11:00 -   1.30
  +++ RELEASE-NOTES-3.3.1.txt   5 Feb 2002 02:20:25 -   1.31
  @@ -3,7 +3,7 @@
Release Notes
=
   
  -$Id: RELEASE-NOTES-3.3.1.txt,v 1.30 2002/02/05 02:11:00 larryi Exp $
  +$Id: RELEASE-NOTES-3.3.1.txt,v 1.31 2002/02/05 02:20:25 larryi Exp $
   
   
   This document describes the changes that have been made since the
  @@ -128,7 +128,7 @@
the status code set by the "redirect" handler if a status code has
not already been set.  This primarily affects the status code used
when the StaticInterceptor module redirects a "directory" URL that
  - doesn't end with a '/'.
  + doesn't end with a '/' and redirects to welcome files.
   
   
   Server:
  
  
  

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

DO NOT REPLY [Bug 4600] - Tomcat 3.3 redirect behavior differs from Tomcat 3.2

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4600

Tomcat 3.3 redirect behavior differs from Tomcat 3.2

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-02-05 02:21 ---
This will be configurable in Tomcat 3.3.1 beta1 using the new
defaultRedirectStatus attribute on the ErrorHandler module.  This attribute
will affect the redirections done by the StaticInterceptor, such as the
welcome file redirection you cite.

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

cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt

[larryi]

larryi  02/02/04 18:48:10

  Modified:.RELEASE-PLAN-3.3.1.txt
  Log:
  Update to current status.  Added Bug 6432 since it looks serious enough
  to justify a fix prior to beta1.
  
  Revision  ChangesPath
  1.4   +16 -9 jakarta-tomcat/RELEASE-PLAN-3.3.1.txt
  
  Index: RELEASE-PLAN-3.3.1.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat/RELEASE-PLAN-3.3.1.txt,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- RELEASE-PLAN-3.3.1.txt2 Feb 2002 16:12:19 -   1.3
  +++ RELEASE-PLAN-3.3.1.txt5 Feb 2002 02:48:09 -   1.4
  @@ -22,19 +22,15 @@
   
Issue  Description 
   1  Must be able to compile and run under JDK 1.1.8
  +   FIXED
   2  Address Cactus failures running with Tomcat 3.3
  +   Tried but not 100% successful yet.
   
  - 
  -Bugs to investigate & fix or resolve/leave as LATER:
  -4600  Tomcat 3.3 redirect behavior differs from Tomcat 3.2
  -  (try to make 301 or 302 configurable)
  -
  -4416  URI En/Decoding not working
  -  (investigate and fix if feasible)
  -
  -5958  Wrong mod_jk.conf for path pattern
   
  +Bugs to investigate & fix or resolve/leave as LATER:
  +6234   checkError method of Servlet's PrintWriter is unreliable
   
  + 
   Addressed
   1657  hyphen character '-' in tag name results in "Invalid expression"
 (port fix from Tomcat 4.x Jasper)
  @@ -48,6 +44,14 @@
 (implement suggested fix)
 Resolved as FIXED
   
  +4416  URI En/Decoding not working
  +  (investigate and fix if feasible)
  +  Deal with later, resolution TBD.
  +
  +4600  Tomcat 3.3 redirect behavior differs from Tomcat 3.2
  +  (try to make 301 or 302 configurable)
  +  Resolved as FIXED
  +
   4923  getRealPath().exists() yields security exception
 (investigate and fix if feasible)
 Resolved as FIXED
  @@ -65,6 +69,9 @@
   5722  Forward to a page that have no extension displays a blank page
 (try to fix to do something better than display a blank page)
 Resolved as WORKSFORME
  +
  +5958  Wrong mod_jk.conf for path pattern
  +  Resolved as FIXED
   
   6004  Cannot configure keystoreType
 Resolved as FIXED
  
  
  

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

Re: Do different virtual hosts have to have different appBase values?

[Bojan Smojver]

Quoting Micael Padraig Og mac Grene <[EMAIL PROTECTED]>:

> [ ]  They do.
>  Reason:
> 
> [X ] They don't.
>  Reason:

I hope you mean docBase?

Don't see why they couldn't point to the same repository of files, provided 
that the files aren't open for exclusive use (Windows???). If you run on Unix, 
you could just symlink one directory to another and it would probably still be 
OK. Provided, of course, you're only reading the files from there. Otherwise, 
two applications could be stepping on each other's toes.

There would still be 2 different contexts (i.e. two different applications in 
the sense of the Servlet Spec), from what I understand.

Bojan

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

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

[billbarker]

billbarker02/02/04 19:54:27

  Modified:src/facade22/org/apache/tomcat/facade
HttpServletResponseFacade.java
  Log:
  Make certain that the Writer isn't in the error state.
  
  This is the quickest and safest fix.  We could try for something better in 3.3.2 if 
we want.  However, this almost never happens (since usually an IOException kills the 
entire thread), so there really isn't that much extra garbage to collect.
  
  Fix for bug #6234.
  Reported by: Pete Fischer [EMAIL PROTECTED]
  
  Revision  ChangesPath
  1.25  +7 -4  
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpServletResponseFacade.java
  
  Index: HttpServletResponseFacade.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpServletResponseFacade.java,v
  retrieving revision 1.24
  retrieving revision 1.25
  diff -u -r1.24 -r1.25
  --- HttpServletResponseFacade.java30 Jan 2002 03:37:12 -  1.24
  +++ HttpServletResponseFacade.java5 Feb 2002 03:54:27 -   1.25
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpServletResponseFacade.java,v
 1.24 2002/01/30 03:37:12 billbarker Exp $
  - * $Revision: 1.24 $
  - * $Date: 2002/01/30 03:37:12 $
  + * $Header: 
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpServletResponseFacade.java,v
 1.25 2002/02/05 03:54:27 billbarker Exp $
  + * $Revision: 1.25 $
  + * $Date: 2002/02/05 03:54:27 $
*
* 
*
  @@ -106,7 +106,10 @@
   void recycle() {
usingStream = false;
usingWriter= false;
  - //  writer=null; // fixed ( ? )
  + if( writer.checkError() ) {
  + OutputBuffer oBuffer= response.getBuffer();
  + writer = new ServletWriterFacade( oBuffer, response);
  + }
if( osFacade != null ) osFacade.recycle();
   }
   
  
  
  

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

cvs commit: jakarta-tomcat RELEASE-NOTES-3.3.1.txt

[billbarker]

billbarker02/02/04 19:56:55

  Modified:.RELEASE-NOTES-3.3.1.txt
  Log:
  Document fix for 6234
  
  Revision  ChangesPath
  1.32  +3 -1  jakarta-tomcat/RELEASE-NOTES-3.3.1.txt
  
  Index: RELEASE-NOTES-3.3.1.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat/RELEASE-NOTES-3.3.1.txt,v
  retrieving revision 1.31
  retrieving revision 1.32
  diff -u -r1.31 -r1.32
  --- RELEASE-NOTES-3.3.1.txt   5 Feb 2002 02:20:25 -   1.31
  +++ RELEASE-NOTES-3.3.1.txt   5 Feb 2002 03:56:55 -   1.32
  @@ -3,7 +3,7 @@
Release Notes
=
   
  -$Id: RELEASE-NOTES-3.3.1.txt,v 1.31 2002/02/05 02:20:25 larryi Exp $
  +$Id: RELEASE-NOTES-3.3.1.txt,v 1.32 2002/02/05 03:56:55 billbarker Exp $
   
   
   This document describes the changes that have been made since the
  @@ -225,6 +225,8 @@
 reported bug, it was mostly a nuisance.  In other cases (see 6143)
 it was causing major problems.
   
  +6234  Recycle the Writer in the ResponseFacade if it is the error state when
  +  the facade is recycled.
   
   Configuration:
   
  
  
  

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

DO NOT REPLY [Bug 6234] - checkError method of Servlet's PrintWriter is unreliable

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6234

checkError method of Servlet's PrintWriter is unreliable

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-02-05 04:01 ---
This is fixed now in the CVS HEAD, and will appear in 3.3.1-B1.

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

Re: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt

[Bill Barker]

>Issue  Description
>1  Must be able to compile and run under JDK 1.1.8
>   +   FIXED
>2  Address Cactus failures running with Tomcat 3.3
>   +   Tried but not 100% successful yet.
>From what little I've seen, I've never really understood this one.  The
Request runs under a single thread, so yielding shouldn't do anything at all
(unless the Cactus servlet starts a thread, in which case it is a Cactus
problem).  I can see where increasing SoLinger might help, but 0.1 Sec
should be plenty with an up-to-date machine.  Does the problem appear when
you don't use the HTTP connector?


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