Re:[VOTE] Tomcat 4.0.2 b2 release

[Jonathan Pierce]

Since 4.0.2 is already released, shouldn't this be tagged 4.0.3b2 ?

Reply Separator
Subject:[VOTE] Tomcat 4.0.2 b2 release
Author: Tomcat Developers List [EMAIL PROTECTED]
Date:   1/16/2002 3:10 PM

Hi,

I think it would be good to tag Tomcat 4.0.2 b2 at the end of the week (with
the binaries being released by monday). Here's the ballot:

ballot
[ ] +1 Make the release
[ ] +0 Good idea, but I can't help
[ ] -0 Bad idea
[ ] -1 No, because:



/ballot

The release process will be the following:
- Tag j-t-c/webapp with tomcat_402_b2
- Update the Java sources for webapp in the main Tomcat tree to mirror the
changes; I plan to remove the duplication for the next release, and handle
webapp the same way as JK (or Coyote)
- Tag j-t-c/jk with tomcat_402_b2 (it's fine to also tag it with something
else, I just think it's a better way to mark which version went in)
- Tag j-t-c/util with tomcat_402_b2
- Generate binaries for the Java code from the j-t-c components, and update
the binaries in the main Tomcat tree
- Tag the Tomcat tree with tomcat_402_b2
- Build and upload the main Tomcat binaries
- Build and upload the native binaries for JK and webapp
- Build and upload the RPMs

Note: IMO JK should be considered release quality in this release, and
should be enabled by default; of course, the final word on this goes to the
JK developers :)

Thanks,
Remy


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



This email and any files transmitted with it are for the named person's use
only.  It may contain confidential, proprietary or legally privileged
information.  No confidentiality or privilege is waived or lost by any
mistransmission.  If you receive this message in error, please immediately
delete it and all copies of it from your system, destroy any hard copies
of it and notify the sender.  You must not, directly or indirectly, use,
disclose, distribute, print, or copy any part of this message if you
are not the intended recipient.

This email message has been swept by a virus software product for the
presence of computer viruses.
*

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

Re[2]:[VOTE] Tomcat 4.0.2 b2 release

[Jonathan Pierce]

Please ignore my last message, my mailer delivered the last email late to me so
I thought you were planning another release. 
Sorry

Reply Separator
Subject:Re:[VOTE] Tomcat 4.0.2 b2 release
Author: Tomcat Developers List [EMAIL PROTECTED]
Date:   2/22/2002 4:12 PM


Since 4.0.2 is already released, shouldn't this be tagged 4.0.3b2 ?

Reply Separator
Subject:[VOTE] Tomcat 4.0.2 b2 release
Author: Tomcat Developers List [EMAIL PROTECTED]
Date:   1/16/2002 3:10 PM

Hi,

I think it would be good to tag Tomcat 4.0.2 b2 at the end of the week (with
the binaries being released by monday). Here's the ballot:

ballot
[ ] +1 Make the release
[ ] +0 Good idea, but I can't help
[ ] -0 Bad idea
[ ] -1 No, because:



/ballot

The release process will be the following:
- Tag j-t-c/webapp with tomcat_402_b2
- Update the Java sources for webapp in the main Tomcat tree to mirror the
changes; I plan to remove the duplication for the next release, and handle
webapp the same way as JK (or Coyote)
- Tag j-t-c/jk with tomcat_402_b2 (it's fine to also tag it with something
else, I just think it's a better way to mark which version went in)
- Tag j-t-c/util with tomcat_402_b2
- Generate binaries for the Java code from the j-t-c components, and update
the binaries in the main Tomcat tree
- Tag the Tomcat tree with tomcat_402_b2
- Build and upload the main Tomcat binaries
- Build and upload the native binaries for JK and webapp
- Build and upload the RPMs

Note: IMO JK should be considered release quality in this release, and
should be enabled by default; of course, the final word on this goes to the
JK developers :)

Thanks,
Remy


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



This email and any files transmitted with it are for the named person's use
only.  It may contain confidential, proprietary or legally privileged
information.  No confidentiality or privilege is waived or lost by any
mistransmission.  If you receive this message in error, please immediately
delete it and all copies of it from your system, destroy any hard copies
of it and notify the sender.  You must not, directly or indirectly, use,
disclose, distribute, print, or copy any part of this message if you
are not the intended recipient.

This email message has been swept by a virus software product for the
presence of computer viruses.
*

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



This email and any files transmitted with it are for the named person's use
only.  It may contain confidential, proprietary or legally privileged
information.  No confidentiality or privilege is waived or lost by any
mistransmission.  If you receive this message in error, please immediately
delete it and all copies of it from your system, destroy any hard copies
of it and notify the sender.  You must not, directly or indirectly, use,
disclose, distribute, print, or copy any part of this message if you
are not the intended recipient.

This email message has been swept by a virus software product for the
presence of computer viruses.
*

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

Re[2]: Re[2]: cvs commit: jakarta-tomcat-connectors/jk/java/

[Jonathan Pierce]

The nightlies are for the HEAD branch, not the 4.0 branch.
In the HEAD:
- tomcat-jk.jar is JK 1.x; that's equivalent to the current tomcat-ajp.jar
- tomcat-jk2.jar is JK 2.x
The two are independent.
I guess tonight's nightly should pick up the changes.

The fix for the ajp connector authentication issue is in the 4.0 branch
tomcat-ajp.jar. When do these changes get merged back into the head branch
tomcat-jk.jar? The nightly build of tomcat-jk.jar still has the bug in
Ajp13Request so the JK1.x solution latest build won't support authentication
through the connector if jk1.x is used.

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

Jonathan


This email and any files transmitted with it are for the named person's use
only.  It may contain confidential, proprietary or legally privileged
information.  No confidentiality or privilege is waived or lost by any
mistransmission.  If you receive this message in error, please immediately
delete it and all copies of it from your system, destroy any hard copies
of it and notify the sender.  You must not, directly or indirectly, use,
disclose, distribute, print, or copy any part of this message if you
are not the intended recipient.

This email message has been swept by a virus software product for the
presence of computer viruses.
*

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

Updated Fix for AJP13 Connector Authentication Bug !!!

[Jonathan Pierce]

I looked over the patch I supplied yesterday and realized that this original
line (String remoteUser = ajp.remoteUser().toString();) could cause a null
pointer exception if the ajp.remoteUser() returns null. Since the original code
checked for null, it is probably safer to check for null on ajp.remoteUser ()
before calling toString just in case the RemoteUser is supplied as null.

Please replace the patch I supplied yesterday with the following code to support
this possibility. I've tested this updated version and it works as well.

In org.apache.ajp.tomcat4.Ajp13Request.setAjpRequest 
Replace from line 115:

//String remoteUser = ajp.remoteUser().toString();
//if ((remoteUser != null)  (! remoteUser.equals ()))
//{
//setUserPrincipal(new Ajp13Principal(remoteUser));
//}
 //   else
//{
// setUserPrincipal(null);
//}

Ajp13Principal theUserPrincipal = null;
MessageBytes theRemoteUser = ajp.remoteUser ();
if (theRemoteUser != null)
{
String theRemoteUserName = theRemoteUser.toString ();
if (! theRemoteUserName.equals ())
{
theUserPrincipal = new Ajp13Principal (theRemoteUserName);
}
}
setUserPrincipal(theUserPrincipal);


Here is an explanation of the rational behind the patch:

The request is providing and empty string for the remote user parameter rather
than null. The unpatched code was setting the user principal to a non-null empty
user instead of null. Subsequent code calling getUserPrincipal assumed that a
user had already been authenticated when the non-null getUserPrincipal value was
seen, and denied access to the empty user. The patched code treats a specified
user of  the same as an unspecified user header of null, and stores the user
principal in the request to null when the supplied userid is empty or null, and
to a valid Ajp13Principal  when the userid is non-null, non-empty.

Jonathan

Reply Separator
Subject:Fix for AJP13 Connector Authentication Bug !!!
Author: Tomcat Developers List [EMAIL PROTECTED]
Date:   2/14/2002 7:39 PM


I've confirmed the fix for the AJP13 Connector / Authentication problem in
4.0.2.
This solves high priority bugs 5647 and 6219.

Please have one of the committers confirm the fix and check it in to cvs. 

The issue was reported in Bug 6219.

I tested the following modification and it seems to resolve the problem.

The problem is in org.apache.ajp.tomcat4.Ajp13Request.setAjpRequest The fix is
below:
Replace from line 115:

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

String remoteUser = ajp.remoteUser().toString();
if ((remoteUser != null)  (! remoteUser.equals ()))
{
setUserPrincipal(new Ajp13Principal(remoteUser));
}
else
{
 setUserPrincipal(null);
}

After making this modification, I am able to successfully serve the protected
example url through the IIS connector and get properly challenged by the login
screen and am able to login and logout as expected.

http://localhost/examples/jsp/security/protected/index.jsp

-Jonathan


This email and any files transmitted with it are for the named person's use
only.  It may contain confidential, proprietary or legally privileged
information.  No confidentiality or privilege is waived or lost by any
mistransmission.  If you receive this message in error, please immediately
delete it and all copies of it from your system, destroy any hard copies
of it and notify the sender.  You must not, directly or indirectly, use,
disclose, distribute, print, or copy any part of this message if you
are not the intended recipient.

This email message has been swept by a virus software product for the
presence of computer viruses.
*

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



This email and any files transmitted with it are for the named person's use
only.  It may contain confidential, proprietary or legally privileged
information.  No confidentiality or privilege is waived or lost by any
mistransmission.  If you receive this message in error, please immediately
delete it and all copies of it from your system, destroy any hard copies
of it and notify the sender.  You must not, directly or indirectly, use,
disclose, distribute, print, or copy any part of this message if you
are not the intended recipient.

This email message has been swept by a virus software product for the
presence of computer viruses.
*

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

Re:cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/

[Jonathan Pierce]

It looks like you accidently removed the empty string check needed here for
ajp.RemoteUser ().
ajp.RemoteUser () should probably also be checked whether it is null before
calling toString.


//if ((!(((Ajp13Connector) connector).getTomcatAuthentication())) 
 // (ajp.remoteUser() != null)) {
 //setUserPrincipal(new
//Ajp13Principal(ajp.remoteUser().toString()));
//   } else {
 //  setUserPrincipal(null);
 //  }

should be:

Ajp13Principal theUserPrincipal = null;
if ((Ajp13Connector) connector).getTomcatAuthentication())
{   
MessageBytes theRemoteUser = ajp.remoteUser ();
if (theRemoteUser != null)
{
String theRemoteUserName = theRemoteUser.toString ();
if (! theRemoteUserName.equals ())
{
theUserPrincipal = new Ajp13Principal (theRemoteUserName);
}
}
}
setUserPrincipal(theUserPrincipal);

Jonathan


Reply Separator
Subject:cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp
Author: Tomcat Developers List [EMAIL PROTECTED]
Date:   2/15/2002 9:13 PM

remm02/02/15 13:13:19

  Modified:jk/java/org/apache/ajp/tomcat4 Ajp13Connector.java
Ajp13Request.java
  Log:
  - Add a 'tomcatAuthentication' flag, which defaults to true.
  - If the flag is true, Tomcat is 100% responsible of the authentication. If
false,
the user authenticated by the native webserver will be used.
  - This new flag will be added in the docs, after reviewing.
  - I didn't know I would end up contributing stuff to JK ;-)
  
  Revision  ChangesPath
  1.13  +31 -4
jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Connector.java
  
  Index: Ajp13Connector.java
  ===
  RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Connecto
r.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- Ajp13Connector.java   7 Feb 2002 00:44:40 -   1.12
  +++ Ajp13Connector.java   15 Feb 2002 21:13:19 -  1.13
  @@ -1,7 +1,7 @@
   /*
  - * $Header:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Connecto
r.java,v 1.12 2002/02/07 00:44:40 costin Exp $
  - * $Revision: 1.12 $
  - * $Date: 2002/02/07 00:44:40 $
  + * $Header:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Connecto
r.java,v 1.13 2002/02/15 21:13:19 remm Exp $
  + * $Revision: 1.13 $
  + * $Date: 2002/02/15 21:13:19 $
*
* 
*
  @@ -93,7 +93,7 @@
* Implementation of an Ajp13 connector.
*
* @author Kevin Seguin
  - * @version $Revision: 1.12 $ $Date: 2002/02/07 00:44:40 $
  + * @version $Revision: 1.13 $ $Date: 2002/02/15 21:13:19 $
*/
   
   
  @@ -273,6 +273,14 @@
   
   private String secret = null;
   
  +
  +/**
  + * Tomcat authentication flag. If true, the authnetication is done by
  + * Tomcat, otherwise, it is done by the native webserver.
  + */
  +private boolean tomcatAuthentication = true;
  +
  +
   // -
Properties
   
   
  @@ -623,6 +631,7 @@
   
   }
   
  +
   /**
* Returns the codeService/code with which we are associated.
*/
  @@ -630,12 +639,30 @@
return service;
   }
   
  +
   /**
* Set the codeService/code with which we are associated.
*/
   public void setService(Service service) {
this.service = service;
   }
  +
  +
  +/**
  + * Get the value of the tomcatAuthentication flag.
  + */
  +public boolean getTomcatAuthentication() {
  +return tomcatAuthentication;
  +}
  +
  +
  +/**
  + * Set the value of the tomcatAuthentication flag.
  + */
  +public void setTomcatAuthentication(boolean tomcatAuthentication) {
  +this.tomcatAuthentication = tomcatAuthentication;
  +}
  +
   
   // - Public
Methods
   
  
  
  
  1.8   +3 -3 
jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Request.java
  
  Index: Ajp13Request.java
  ===
  RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Request.
java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- Ajp13Request.java 15 Feb 2002 00:54:43 -  1.7
  +++ Ajp13Request.java 15 Feb 2002 21:13:19 -  1.8
  @@ -112,9 +112,9 @@
   setServerName(ajp.serverName().toString());
   setServerPort(ajp.getServerPort());
   
  -String remoteUser = ajp.remoteUser().toString();
  -if ((remoteUser != null)  (!(remoteUser.equals( {
  -

Re[2]:cvs commit: jakarta-tomcat-connectors/jk/java/org/apac

[Jonathan Pierce]

No, I did it on purpose.
It's a lot better to have the user set the behavior of the connector here.

I don't understand what you mean here. If you want tomcat to authenticate, and
the userid is passed in, your code doesn't call setUserPrincipal.

When the userid passed in is the empty string (not null) and you don't want
Tomcat authentication, your code will set the user principal to an
Ajp13Principal wrapping the empty string and Tomcat will generate the access
denied (403) error when the user hits the page through the connector since the
user principal will not be null, but will also be an invalid empty string
userid.

Did you test this code with the connector?

//if ((!(((Ajp13Connector) connector).getTomcatAuthentication())) 
 // (ajp.remoteUser() != null)) {
 //setUserPrincipal(new
//Ajp13Principal(ajp.remoteUser().toString()));
//   } else {
 //  setUserPrincipal(null);
 //  }




Reply Separator
Subject:Re:cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/
Author: Tomcat Developers List [EMAIL PROTECTED]
Date:   2/15/2002 2:20 PM

 It looks like you accidently removed the empty string check needed here
for
 ajp.RemoteUser ().
 ajp.RemoteUser () should probably also be checked whether it is null
before
 calling toString.

No, I did it on purpose.
It's a lot better to have the user set the behavior of the connector here.
Since you want TC to authenticate the users, you don't have to do anything.
OTOH, if you want the native webserver to authenticate, you should set the
'tomcatAuthentication' attribute to 'false' on the Connector element.

As pointed out by Nacho, it makes the connector predictable.

Also, the check for ajp.remoteUser() being equal to null is there (but
obviously, it's only needed when 'tomcatAuthentication' is false).

Remy


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



This email and any files transmitted with it are for the named person's use
only.  It may contain confidential, proprietary or legally privileged
information.  No confidentiality or privilege is waived or lost by any
mistransmission.  If you receive this message in error, please immediately
delete it and all copies of it from your system, destroy any hard copies
of it and notify the sender.  You must not, directly or indirectly, use,
disclose, distribute, print, or copy any part of this message if you
are not the intended recipient.

This email message has been swept by a virus software product for the
presence of computer viruses.
*

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

Re[2]: cvs commit: jakarta-tomcat-connectors/jk/java/org/apa

[Jonathan Pierce]

Ok, I understand now.

I tested the case through the connector where you do want tomcat authentication
and the user principal is always set to null and everything worked fine with the
/examples/jsp/security/protected/index.html example. I was able to login and
logout as expected and see the user principal.

Thanks for being so thorough.

Also, when I looked today at the nightly builds for 4.0.2, I noticed that the
tomcat-ajp.jar file had been broken up into multiple jar files. The build of
tomcat-jk.jar from 2:42AM last night did not include the changes you checked in
yesterday. When do the connector libraries used in tomcat 4.0.2 nightly builds
get rebuilt?

Jonathan

Reply Separator
Subject:Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache
Author: Tomcat Developers List [EMAIL PROTECTED]
Date:   2/15/2002 3:07 PM

 I don't understand what you mean here. If you want tomcat to authenticate,
and
 the userid is passed in, your code doesn't call setUserPrincipal.

If you want Tomcat to authenticate, you set 'tomcatAuthentication' to true
(that's the default), in which case the connector will always set the user
pricipal to null, regardless of what was set by the connector.

 When the userid passed in is the empty string (not null) and you don't
want
 Tomcat authentication, your code will set the user principal to an
 Ajp13Principal wrapping the empty string and Tomcat will generate the
access
 denied (403) error when the user hits the page through the connector since
the
 user principal will not be null, but will also be an invalid empty string
 userid.

If you don't want Tomcat to authenticate, you set 'tomcatAuthentication' to
false, and the fact of whether or not the pricipal is valid is irrelevant,
since Tomcat is never supposed to authenticate in the first place.

Note the (ajp.remoteUser() != null) which prevents calling toString on the
possibly null field.

I think I implemented what Nacho recommended (and which seems more
consistent).

Remy


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



This email and any files transmitted with it are for the named person's use
only.  It may contain confidential, proprietary or legally privileged
information.  No confidentiality or privilege is waived or lost by any
mistransmission.  If you receive this message in error, please immediately
delete it and all copies of it from your system, destroy any hard copies
of it and notify the sender.  You must not, directly or indirectly, use,
disclose, distribute, print, or copy any part of this message if you
are not the intended recipient.

This email message has been swept by a virus software product for the
presence of computer viruses.
*

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

Fix for AJP13 Connector Authentication Bug !!!

[Jonathan Pierce]

I've confirmed the fix for the AJP13 Connector / Authentication problem in
4.0.2.
This solves high priority bugs 5647 and 6219.

Please have one of the committers confirm the fix and check it in to cvs. 

The issue was reported in Bug 6219.

I tested the following modification and it seems to resolve the problem.

The problem is in org.apache.ajp.tomcat4.Ajp13Request.setAjpRequest The fix is
below:
Replace from line 115:

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

String remoteUser = ajp.remoteUser().toString();
if ((remoteUser != null)  (! remoteUser.equals ()))
{
setUserPrincipal(new Ajp13Principal(remoteUser));
}
else
{
 setUserPrincipal(null);
}

After making this modification, I am able to successfully serve the protected
example url through the IIS connector and get properly challenged by the login
screen and am able to login and logout as expected.

http://localhost/examples/jsp/security/protected/index.jsp

-Jonathan


This email and any files transmitted with it are for the named person's use
only.  It may contain confidential, proprietary or legally privileged
information.  No confidentiality or privilege is waived or lost by any
mistransmission.  If you receive this message in error, please immediately
delete it and all copies of it from your system, destroy any hard copies
of it and notify the sender.  You must not, directly or indirectly, use,
disclose, distribute, print, or copy any part of this message if you
are not the intended recipient.

This email message has been swept by a virus software product for the
presence of computer viruses.
*

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

Re[2]: Native Connector problems

[Jonathan Pierce]

Where are the binary builds of the native connectors for 4.0.2? When can we
expect them? Can you quantify the term shortly?

Jonathan

Reply Separator
Subject:Re: Native Connector problems
Author: Tomcat Developers List [EMAIL PROTECTED]
Date:   2/13/2002 1:17 AM

 The problem is that the default cache size is one and in the ajp_init
 function
 in jk_ajp_common.c we return from inside of an if when we initialize
 the cache
 so the secrect member of the structure never gets initialized.  This
 caused
 some GPFs in certain cases on some of my builds.
 
 I've checked in the fix.  All I did was move the line that initializes
 secret up above
 the if statement.
 
 Remy, would it be possible to relabel jk_ajp_common.c
 rev. 1.24 as the rev for tomcat_402?  I've built and tested this fix on
 NetWare
 and the resolved my GPFs and bad behavior talking to older
 installations
 of Tomcat (i.e. 3.3).  I was able to use the same module to talk to 
 Tomcat 4.0.2 and Tomcat 3.3 from the same instance of the web server.
 I love it when a plan comes together :-)

I've retagged the file.

Thanks,
Remy


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



This email and any files transmitted with it are for the named person's use
only.  It may contain confidential, proprietary or legally privileged
information.  No confidentiality or privilege is waived or lost by any
mistransmission.  If you receive this message in error, please immediately
delete it and all copies of it from your system, destroy any hard copies
of it and notify the sender.  You must not, directly or indirectly, use,
disclose, distribute, print, or copy any part of this message if you
are not the intended recipient.

This email message has been swept by a virus software product for the
presence of computer viruses.
*

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

Re:Tomcat 4 JDBCRealm Connection Pooling

[Jonathan Pierce]

It would be nice to reference the JDBC data source rather than configuring the
realm seperately. The problem I see is that the Realm is global in server.xml
and the data sources are specific to individual contexts. Should the realm be
moved into the context so that different contexts could be configured with
different realms?

Jonathan

Reply Separator
Subject:Tomcat 4 JDBCRealm Connection Pooling
Author: Tomcat Developers List [EMAIL PROTECTED]
Date:   2/13/2002 10:25 AM

Currently the JDBCRealm does not use db Connection Pooling, instead
it maintains an open connection and synchronizes use of the connection.

I have been using the new Tomcat 4.1-dev DBCP for creating
a JNDI named JDBC DataSource and it has been working well.

The easiest way to implement db connection pooling may be by 
providing a JDBC Realm which uses a JNDI named JDBC DataSource.

Should this support be added to the current JDBCRealm, or should a new
realm be created which uses a JNDI named JDBC DataSource?

Regards,

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



This email and any files transmitted with it are for the named person's use
only.  It may contain confidential, proprietary or legally privileged
information.  No confidentiality or privilege is waived or lost by any
mistransmission.  If you receive this message in error, please immediately
delete it and all copies of it from your system, destroy any hard copies
of it and notify the sender.  You must not, directly or indirectly, use,
disclose, distribute, print, or copy any part of this message if you
are not the intended recipient.

This email message has been swept by a virus software product for the
presence of computer viruses.
*

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

Re:native connectors for iis and netscape/solaris available

[Jonathan Pierce]

 i've uploaded native jk1 connectors for iis and netscape/solaris.

1. How did you build it? There were files referenced by the Visual Studio
projects that were missing in the jakarta-tomcat-connectors-4.0.2-src.zip. When
I tried to build it, I needed to add some files from the cvs. You might want to
make sure all the needed files are included. These files were referenced in the
project, but missing from the /native/common directory. They do exist in the
/native2/common directory but introduce other errors if you use these versions.
I had to use the versions from the Tomcat3.3a distribution.

jk_registry.c
jk_channel_socket.c
jk_env.c


2. I downloaded the iisapi connector build and it seems to work fine with 4.0.2
with the exception of high priority Bug: 5647 (AJP13 connector will not pass
authentication requests). 

This bug is forcing me to disable the use of Realms in my production application
since I need the connector.

Does anyone have an estimate on when this bug will be fixed? It is a show
stopper for me.

-Jonathan

Reply Separator
Subject:native connectors for iis and netscape/solaris available
Author: Tomcat Developers List [EMAIL PROTECTED]
Date:   2/13/2002 2:00 PM

fyi - i've uploaded native jk1 connectors for iis and netscape/solaris.

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



This email and any files transmitted with it are for the named person's use
only.  It may contain confidential, proprietary or legally privileged
information.  No confidentiality or privilege is waived or lost by any
mistransmission.  If you receive this message in error, please immediately
delete it and all copies of it from your system, destroy any hard copies
of it and notify the sender.  You must not, directly or indirectly, use,
disclose, distribute, print, or copy any part of this message if you
are not the intended recipient.

This email message has been swept by a virus software product for the
presence of computer viruses.
*

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

Native Connector Builds - When?

[Jonathan Pierce]

Note: RPMs and binaries of native connectors will be made available shortly.

When can we expect to see builds of native connectors? 

I'm waiting for the build of the iisapi native connector for IIS. My attempts to
build it from the 4.0.2 connector source required me to copy some missing files
from the cvs.

Jonathan


This email and any files transmitted with it are for the named person's use
only.  It may contain confidential, proprietary or legally privileged
information.  No confidentiality or privilege is waived or lost by any
mistransmission.  If you receive this message in error, please immediately
delete it and all copies of it from your system, destroy any hard copies
of it and notify the sender.  You must not, directly or indirectly, use,
disclose, distribute, print, or copy any part of this message if you
are not the intended recipient.

This email message has been swept by a virus software product for the
presence of computer viruses.
*

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

Re:Connectors, Realms, 4.0.2b2 - 403 Access Denied

[Jonathan Pierce]

I'm posting this question a second time since I am not sure if mailer problems
on my end prevented it from reaching the list and I got no responses on the
issue.

The security implementation in Tomcat 4.0.2b2 and earlier seems to depend on
using redirect urls. This doesn't seem to work correctly with connectors such as
the IISAPI IIS connector.

What is the strategy for supporting basic or form based authentication through
connectors? Should this be implemented without using redirect?




I've configured Tomcat4.0.2b2 with the AJP 1.3 Connector and successfully
installed the iisapi dll from Tomcat3.3 into IIS. I am attempting to serve a
protected page through the connector using the protected realm example.

When I hit the page directly on port 8080, I get the expected login form
challenge behavior. When I hit the page through the connector, I get a 403
access denied error.

Is serving protected pages through connectors supposed to be supported in 4.0.2?

http://localhost:8080/examples/jsp/security/protected/index.jsp redirects to the
login screen as expected.

http://localhost/examples/jsp/security/protected/index.jsp
returns 403 - Access to the requested resource has been denied


-Jonathan

*
This email and any files transmitted with it are for the named person's use only.  It 
may contain confidential, proprietary or legally privileged information.  No 
confidentiality or privilege is waived or lost by any mistransmission. If you receive 
this message in error, please immediately delete it and all copies of it from your 
system, destroy any hard copies of it and notify the sender.  You must not, directly 
or indirectly, use, disclose, distribute, print, or copy any part of this message if 
you are not the intended recipient. 

This email message has been swept by a virus software product for the presence of 
computer viruses. 
*

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

Connectors, Realms, 4.0.2b2 - 403 Access Denied

[Jonathan Pierce]

I've configured Tomcat4.0.2b2 with the AJP 1.3 Connector and successfully
installed the iisapi dll from Tomcat3.3 into IIS. I am attempting to serve a
protected page through the connector using the protected realm example.

When I hit the page directly on port 8080, I get the expected login form
challenge behavior. When I hit the page through the connector, I get a 403
access denied error.

Is serving protected pages through connectors supposed to be supported in 4.0.2?

http://localhost:8080/examples/jsp/security/protected/index.jsp redirects to the
login screen as expected.

http://localhost/examples/jsp/security/protected/index.jsp
returns 403 - Access to the requested resource has been denied


-Jonathan

*
This email and any files transmitted with it are for the named person's use only.  It 
may contain confidential, proprietary or legally privileged information.  No 
confidentiality or privilege is waived or lost by any mistransmission. If you receive 
this message in error, please immediately delete it and all copies of it from your 
system, destroy any hard copies of it and notify the sender.  You must not, directly 
or indirectly, use, disclose, distribute, print, or copy any part of this message if 
you are not the intended recipient. 

This email message has been swept by a virus software product for the presence of 
computer viruses. 
*

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

why - jaxp.jar two places in Tomcat4.0b7 dist

[Jonathan Pierce]

Two copies of the jaxp.jar file are in the 4.0b7 dist. Shouldn't they be moved
in /common/lib/ so that only one copy exists in the class path?

/jasper/jaxp.jar
/server/lib/jaxp.jar

Re[2]: why - jaxp.jar two places in Tomcat4.0b7 dist

[Jonathan Pierce]

Thanks, I see it now in the notes.

Another build question -

There are javax classes referenced by Catalina classes in the dist build that
are not included. This could lead to class not found errors for users who
reference the catalina classes without adding them to the /lib directory.
Shouldn't versions of these be included in the dist?

These include the following and maybe a few more:
jmx-1_0_1-ri
jsse1.0.2

 

Reply Separator
Subject:Re: why - jaxp.jar two places in Tomcat4.0b7 dist
Author: [EMAIL PROTECTED]
Date:   8/17/2001 9:50 AM



On Fri, 17 Aug 2001, Jonathan Pierce wrote:

 
 Two copies of the jaxp.jar file are in the 4.0b7 dist. Shouldn't they be moved
 in /common/lib/ so that only one copy exists in the class path?
 
 /jasper/jaxp.jar
 /server/lib/jaxp.jar
 

See the RELEASE-NOTES-4.0-B7.txt (or whatever for your version) for more
details, but moving the parser into /common/lib is the right answer *only*
if you want internal Catalina classes and *all* web apps to use the same
parser.  The current organization allows web apps to use something
different (such as Xerces) without messing up Catalina.

Craig

Servlet Forward to Self? 4.0b7

[Jonathan Pierce]

I'm not sure whether it is legal, but Tomcat 4.0b7 doesn't like it very much. 

I'm trying to forward a request back to the same servlet with a different query
string that dispatches the way the request is handled within the servlet.

Tomcat4.0b7 gets an error trying to allocate the servlet again from the invoker.

In my servlet service handler:

String theNewURL = /servlet/ + getClass ().getName () + ?GOTO=NextScreen;
theNewURL = theResponse.encodeUrl (theNewURL);
ServletContext theServletContext = theDBServlet.getServletContext ();
theServletContext.getRequestDispatcher (theNewURL).forward (theRequest,
theResponse);

Re[2]: Servlet Forward to Self? 4.0b7

[Jonathan Pierce]

why are you encoding the url?  DOing that will cause ? and = to be encoded
as %whatever; so the query string wont be interpreted as you
intend. 

Not true, I am encoding the URL because I sometimes include quotes. It's not the
issue here though, since it behaves the same way without encoding the URL.

Having said that I'm not sure if it would work anyway (o:  Why
not set an attribute in the request and then forward the request as is and
have the servlet look for that attribute and act accordingly?

The dispatching code that handles the request expects a parameter to be set. The
same problem would still occur if I used an attribute anyway. I could also
implement my own request wrapper but that's what forward is designed to do so
why not use the servlet API?

 btw - isn't this a tomcat-user question?  

Not really, I don't think the spec is clear on this question, and it should be
made visible whether Tomcat4.0b7 support it or not. In any event, Tomcat4.0b7
throws the following exception when I try to do it.

Unexpected Error Encountered...
Cannot allocate servlet instance for path
/frn/servlet/FRNServlet.FRNServletInnerFrame
javax.servlet.ServletException: Cannot allocate servlet instance for path
/frn/servlet/FRNServlet.FRNServletInnerFrame at
org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java:406
) at org.apache.catalina.servlets.InvokerServlet.doGet(InvokerServlet.java:180)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:1125) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:1264) at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java
:672) at org.apache.catalina.core.ApplicationDispatcher.doForward


cheesr
dim

4.0b7 war/context Base Directory problem

[Jonathan Pierce]

  In 4.0b7, I can't get war files to expand at startup in time for a context in
the server.xml directory to not complain.

I'm trying to put a war file in the webapps directory and define a context that
references the expanded version of the war but Tomcat 4.0b7 complains at startup
that the document base directory doesn't exist. The documentation implies that
this should work and it worked fine in Tomcat 3.2.3.

What do I need to do to make this work in Tomcat 4.0b7?

My Host entry has unpackWARs = true

 Host name=localhost debug=0 appBase=webapps unpackWARs=true
...
/Host

The war file is: /webapps/foo.war

The server.xml context entry is:

Context path=/foo docBase=foo debug=0
 reloadable=true
 ...
/Context



The error message I get at startup is:

java.lang.IllegalArgumentException: Document base ..\webapps\foo does not exist
or is not a readable directory

Re[2]: 4.0b7 war/context Base Directory problem

[Jonathan Pierce]

Oh, because at this point your docBase needs to be changed to foo.war.

Thanks Pier, That solved the problem. 

Maybe an example war file could be added to the distribution that reflects this,
or at least the documentation updated to show it. 

Should the examples directory be distributed as examples.war in the dist build?

#2:

Is it possible to make Tomcat to include the webapps directory when loading
servlets at startup? 

I added an entry to the web.xml file for my servlet to load at startup, but it
couldn't find my class: foo.class in my foo.jar file from the expanded war file
foo.war in my context /foo

In web.xml:

servlet
 servlet-namefoo servlet/servlet-name
 servlet-classfoo/servlet-class
 load-on-startup7/load-on-startup
   /servlet

In server.xml:

Host name=localhost debug=0 appBase=webapps unpackWARs=true ...
/Host

Context path=/foo docBase=foo.war debug=0
reloadable=true
...
/Context

In /webapps/foo.war:

/webapps/frn/WEB-INF/lib/foo.jar which contains: foo.class

Reply Separator
Subject:Re: 4.0b7 war/context Base Directory problem
Author: [EMAIL PROTECTED]
Date:   8/13/2001 4:06 PM

Jonathan Pierce at [EMAIL PROTECTED] wrote:
 
 In 4.0b7, I can't get war files to expand at startup in time for a context in
 the server.xml directory to not complain.
 
 I'm trying to put a war file in the webapps directory and define a context
 that
 references the expanded version of the war but Tomcat 4.0b7 complains at
 startup
 that the document base directory doesn't exist. The documentation implies that
 this should work and it worked fine in Tomcat 3.2.3.
 
 What do I need to do to make this work in Tomcat 4.0b7?
 
 My Host entry has unpackWARs = true
 
 Host name=localhost debug=0 appBase=webapps unpackWARs=true
 ...
 /Host
 
 The war file is: /webapps/foo.war
 
 The server.xml context entry is:
 
 Context path=/foo docBase=foo debug=0
reloadable=true
...
   /Context
 
 The error message I get at startup is:
 
 java.lang.IllegalArgumentException: Document base ..\webapps\foo does not
 exist or is not a readable directory

Oh, because at this point your docBase needs to be changed to foo.war.
It'll be later on expanded by Tomcat, and all will be handled correctly
(yeah, I know, the attribute name is kinda misleading)...

Or, at least, it works for me using examples.war :)

Pier

JDBC Realm Questions Tomcat 3.2.2

[Jonathan Pierce]

This may be a stupid question but I've found hundreds of messages from confused
users on the subject of JDBC Realms and Tomcat and no good explanation or
example. There is a documentation file JDBCRealm.howto but it doesn't describe
how to instantiate the datasource with a code example or what additional
property files need to be included to configure jndi properties.

Like lots of other people, I'm trying to use the release Tomcat 3.2.2, configure
multiple jdbc datasources in the server.xml file, and reference it in my
servlet. I am only interested in using a shared database ID to connect to the
database for all users of my servlet. The database connect info needs to be in
Tomcat conf files since the passwords need to be reconfigured at deployment time
outside my war file.

1. Is this behavior supported by Tomcat 3.2.2? How do I configure multiple
database datasources and instantiate them in my code?

2. Assuming I setup the datasources like below, what properties do I use to
assign a name to the datasource so I can reference it?

RequestInterceptor 
className=org.apache.tomcat.request.JDBCRealm 
debug=99 
driverName=oracle.jdbc.driver.OracleDriver
connectionURL=jdbc:oracle:thin:@ntserver:1521:ORCL
connectionName=scott
connectionPassword=tiger
/

RequestInterceptor 
className=org.apache.tomcat.request.JDBCRealm 
debug=99 
driverName=oracle.jdbc.driver.OracleDriver
connectionURL=jdbc:oracle:thin:@ntserver2:1521:ORCL
connectionName=scott
connectionPassword=tiger
/


3. What do I need to add to a config file in order to access the initial context
so I can retrieve the datasource?

import javax.servlet.*;
import javax.servlet.http.*;
import javax.naming.*;
import javax.sql.*;

String  theDataSourceName = ???;
String  theNamingProviderURL = ???;
String  theInitialContextNamingFactory = ???;
Properties theProperties = new Properties (); 
theProperties.put(java.naming.provider.url, theNamingProviderURL);
theProperties.put(java.naming.factory.initial,theInitialContextNamingFactory);

Context theInitialContext = new InitialContext(theProperties);
DataSource theDataSource = (DataSource) theInitialContext.lookup
(theDatasourceName);

Loading Libraries from Tomcat lib folder

[Jonathan Pierce]

In tomcat-3.2.2b5 and earlier, the tomcat.bat and tomcat.sh have inconsistent
behavior as tomcat.sh loads all files in the tomcat lib folder and tomcat.bat
only loads the ones with .jar extension. I think they should be changed to
behave consistently so lib files don't need to be renamed when added to the lib
folder on Windows.

The line in tomcat.bat should probably be changed from *.jar to *.* unless the
spec says otherwise in which case the line in tomcat.sh should be changed to be
consistent.

Change:

for %%i in (%TOMCAT_HOME%\lib\*.jar) do call %TOMCAT_HOME%\bin\cpappend.bat %%i

to:

for %%i in (%TOMCAT_HOME%\lib\*.*) do call %TOMCAT_HOME%\bin\cpappend.bat %%i

.zip lib files

[Jonathan Pierce]

All,

In tomcat.bat, there is logic that dynamically loads .jar files from the lib
directory. Should this be extended to include .zip files as well, since some
vendors distribute libs with the .zip extension?
 For example, Oracle distributes their jdbc thin client driver as:
classes12_01.zip

I don't believe it would be a standards issue, since the lib directory is Tomcat
specific.

:dynClasspath
set _LIBJARS=
for %%i in (%TOMCAT_HOME%\lib\*.jar) do call %TOMCAT_HOME%\bin\cpappend.bat %%i
if not %_LIBJARS% ==  goto gotLibJars

Any objection to adding the following line?

set _LIBJARS=%_LIBJARS%
for %%i in (%TOMCAT_HOME%\lib\*.zip) do call %TOMCAT_HOME%\bin\cpappend.bat %%i

Jonathan

Re:Enterprise Tomcat

[Jonathan Pierce]

I am using Tomcat as the enterprise servlet container in production for our B2B
E-Commerce servlet and several intranet applications at Joseph E. Seagram 
Sons, Inc. I'm using the ISAPI filter and an SSL connection to IIS.

The URL is only for our distributors to use, but you can hit the login servlet
page to see the servlet running at: http://www.custserv.seagram.com/

Jonathan

Reply Separator
Subject:Enterprise Tomcat 
Author: [EMAIL PROTECTED]
Date:   12/8/00 11:41 AM

Hello all, 

Does anyone know of Corperate (Fortune 500) companies using Tomcat as their
enterprise servlet container? 
Anything like that at all? Links would be great.

We (tech types) want to use it, but have to prove mgmt. that it's in use in
the big companies.

(Our mandate is no unproven technologies)
Don't flame me, that's not my definition of proven technology...

I've been trying to find _anything_ about Tomcat and enterprise usage and am
having no luck.

What percentage of core coders on TC are from Sun? (guesses?) I think this
would argue my case...

Any help is appreciated.
Cheers,
mk



Michael R. Kuz
Developer
Service Intelligence
(403) 261-5000 ext. 363
[EMAIL PROTECTED]



!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"
HTML
HEAD
META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"
META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12"
TITLEEnterprise Tomcat /TITLE
/HEAD
BODY

PFONT SIZE=2 FACE="Arial"Hello all, /FONT
/P

PFONT SIZE=2 FACE="Courier New"Does anyone know of Corperate (Fortune 500)
companies using Tomcat as their enterprise servlet container? /FONT
BRFONT SIZE=2 FACE="Courier New"Anything like that at all? Links would be
great./FONT
/P

PFONT SIZE=2 FACE="Courier New"We (tech types) want to use it, but have to
prove mgmt. that it's in use in the big companies./FONT
/P

PFONT SIZE=2 FACE="Courier New"(Our mandate is no unproven
technologies)/FONT
BRFONT SIZE=2 FACE="Courier New"Don't flame me, that's not my definition of
proven technology.../FONT
/P

PFONT SIZE=2 FACE="Courier New"I've been trying to find _anything_ about
Tomcat and enterprise usage and am having no luck./FONT
/P

PFONT SIZE=2 FACE="Courier New"What percentage of core coders on TC are from
Sun? (guesses?) I think this would argue my case.../FONT
/P

PFONT SIZE=2 FACE="Courier New"Any help is appreciated./FONT
BRFONT SIZE=2 FACE="Courier New"Cheers,/FONT
BRFONT SIZE=2 FACE="Courier New"mk/FONT
/P
BR
BR

PFONT SIZE=2 FACE="Arial"Michael R. Kuz/FONT
BRFONT SIZE=2 FACE="Arial"Developer/FONT
BRFONT SIZE=2 FACE="Arial"Service Intelligence/FONT
BRFONT SIZE=2 FACE="Arial"(403) 261-5000 ext. 363/FONT
BRFONT SIZE=2 FACE="Arial"[EMAIL PROTECTED]/FONT
/P
BR

/BODY
/HTML