What is the possibility of / interest in a 4.1.31 release?

2004-04-27 Thread Jeff Tulley
For a third time, we have had a defect logged on the fact that I
introduced a bug into JNDIRealm while adding a new filtering feature. 
The fix was very simple and has been made, but post-release of 4.1.30.
That, and the admin application largely does not work due to an
unfortunate tagging problem.

What is the possibility that there will be a 4.1.31 release?  Is there
any interest in that?

I am not a committer and so cannot bring this about, but I wanted to
suggest that it seems to me to be a very good idea.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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



RE: What is the possibility of / interest in a 4.1.31 release?

2004-04-27 Thread Jeff Tulley
So what I've brought up is not a critical security fix, but instead a
critical functionality fix, with a workaround that is quite annoying for
end users.
How does that rate?

Yes, Tomcat 5.x is the way to go, but for instance on support packs
for NetWare we are not at liberty to make such a big move, but instead
need to make the smaller upgrade of 4.1.29 to 4.1.30.  I will pull in
whatever additional fixes I need(JNDIRealm, the Connector to make the
admin work), but the story of Move to 5.x does not fit everybody's
case.

But, the next major release vehicle of NetWare and our Novell Linux
Services will do that move to the 5.x code of course.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

 [EMAIL PROTECTED] 4/27/04 2:49:32 PM 

Hi,
It's unlikely you'll see a 4.1.x release for any one feature, unless
it's a critical security fix.  4.1.x will have bundle releases with
several features, less frequency.  We've been giving the message for a
while now that 5.x is the way to go, not least because less resources
(including release manager resources) are spent on 4.x.

Yoav Shapira
Millennium Research Informatics


-Original Message-
From: Jess Holle [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, April 27, 2004 4:36 PM
To: Tomcat Developers List
Subject: Re: What is the possibility of / interest in a 4.1.31
release?

Parallel question:

How many think that the public messaging should be that more along
the
lines of Tomcat 5 is now at least as stable/mature as Tomcat 4.1.30
and that folk should upgrade to it?

Having asked, I still believe a 4.1.31 for such an issue as that
brought
up here would be appropriate.  I ask the question in terms of
messaging
to users, OEMs, etc, that 4.1.x has been superseded by 5.0.x in terms
of
the best version for production -- if/when the community feels this
is
reality.

Personally, I feel that 5.0.22 is at least as stable as the latest
4.1.x, is faster, and overall is preferable.

--
Jess Holle

Jeff Tulley wrote:

For a third time, we have had a defect logged on the fact that I
introduced a bug into JNDIRealm while adding a new filtering
feature.
The fix was very simple and has been made, but post-release of
4.1.30.
That, and the admin application largely does not work due to an
unfortunate tagging problem.

What is the possibility that there will be a 4.1.31 release?  Is
there
any interest in that?

I am not a committer and so cannot bring this about, but I wanted to
suggest that it seems to me to be a very good idea.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com 

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



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




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


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


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



RE: What is the possibility of / interest in a 4.1.31 release?

2004-04-27 Thread Jeff Tulley
So what I've brought up is not a critical security fix, but instead a
critical functionality fix, with a workaround that is quite annoying
for
end users.
How does that rate?

Below a critical security fix.  Personally, I wouldn't rate the
JNDIRealm as a critical piece of functionality either, but that's a
simple and subjective opinion based solely on its rarity as an issue
on
the tomcat-user list.

Oh, Yoav - I was talking about the admin piece not working as the
critical piece of functionality.  No, the JNDIRealm issue is minor, it
just keeps coming up.


Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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



Spam vulnerability at apache (was: Re: Photo document [TID#4977])

2004-04-13 Thread Jeff Tulley
If I am not mistaken, this email probably results from somebody on the
list having one of the many recent viruses.  An email is being sent from
somebody's computer, with the From or Reply-to being tomcat-dev,
and the To being the Russian place.  The russian site has an
auto-responder, and so it sends back an email to the list.Yes, this
is a mail software problem in that the russian place was automatically
subscribed earlier probably from a similar virus email with a reply-to
being something like tomcat-dev-subscribe at jakarta   

The point is that nobody necessarily has your address.  But, being on
such a large public list, you definitely put yourself at risk at getting
more virus and spam emails.  If this concerns you greatly, I'd advise
getting a secondary, junk email account for posts to this list, one
that you could kill someday and be done with any spam or virus mails
brought to you by participation here.  I myself wish I had done so.
(probably too late to do much good now!)

 [EMAIL PROTECTED] 4/12/04 9:20:31 PM 
Hi,

I extremely apologize for this message, but i think this needs to be 
figured out. I just yesterday registered my new email address with 
tomcat-dev, and i received the spam below almost immediately
thereafter. 
Only a few people are aware of this email address, so the origin of
spam 
info 99% appears to be tomcat-dev registration. Is there any chance
that 
DNS gets resolved to one of several IPs, one of which collects these 
emails and uses them for spam (or perhaps is infected with a virus)? I

would look for any IPs based in russia as the prime suspects, because 
this email contains russian text and appears to be originated there.

What's worse is that 25 minutes after this spam, i received another one

of similar content. Please help save me and others from this plague of

the Internet.
I entrusted apache.org with this address, and hope we can keep it 
between us.

P.S. If there are other people who received similar emails, please let

me, the admins, or the list know. If you let only me know, i will 
accumulate the number of people affected and forward this to an admin.
P.P.S. I see that emails are protected in the archives publicly 
published, and i think this issue is in the same category.

Thanks,
rsa/

[EMAIL PROTECTED] wrote:

russian(win-1251):

!

?? ??? ? ??? ? ? ??  ?? ??

Photo document, ??? . ??? ??   ?? .
?? ?    ??, ? ??? 
?
[TID#4977]. ??, ? ? :

  [TID#4977]

? ? (subject)  ??? ??? ?? ??? . 
??? ? ??? ??? ?? ??? ?? (reply).

C ?,
?? ??? ? 
???  ?-10
http://www.m-10.ru 

english:

Greetings,

This message has been automatically generated in response to your
message
regarding Photo document, the content of which appears below. 
There
is no need to reply to it now. Support has received your message and
it has
been assigned a ticket ID of [TID#4977]. Please include the string:

  [TID#4977]

in the subject line of all future correspondence about this problem. 
To do so, you may reply to this message.
 
WBR,
Support Team
Hosting Operator M-10 
http://www.m-10.ru 
Original
Message-

Please, photo document.
Yours sincerely

+++ X-Attachment-Type: document
+++ X-Attachment-Status: no virus found
+++ Powered by the new F-Secure OnlineAntiVirus
+++ Visit us: www.f-secure.com 



-Headers
Follow--
Received: from [EMAIL PROTECTED] 
  by office.m-10.ru (CommuniGate Pro GROUP 4.1.8)
  with GROUP id 1745058; Mon, 12 Apr 2004 17:13:05 +0400
Received: from [62.5.188.222] (HELO office.m-10.ru)
  by office.m-10.ru (CommuniGate Pro SMTP 4.1.8)
  with ESMTP id 1745042 for [EMAIL PROTECTED]; Mon, 12 Apr
2004 17:12:58 +0400
X-Antivirus: Checked by Dr.Web (http://www.drweb.net)
From: [EMAIL PROTECTED] 
To: [EMAIL PROTECTED] 
Subject: Photo document
Date: Mon, 12 Apr 2004 17:11:48 +0400
MIME-Version: 1.0
Content-Type: multipart/mixed;
   boundary==_NextPart_000_0016=_NextPart_000_0016
X-Priority: 3
X-Msmail-Priority: Normal
Message-Id: [EMAIL PROTECTED]


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


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



Re: Spam vulnerability at apache (was: Re: Photo document [TID#4977])

2004-04-13 Thread Jeff Tulley
Quite correct, though usually it IS the case that they are a subscriber,
and that is why they have the address in their book.  I personally am
quite surprised that a group of individuals technical enough to
participate in these forums would be falling prey to the viruses so
often, so maybe you are correct and they are really non-subscribers.  I
HAVE noticed though a high occurrence of jakarta (tomcat _AND_ Ant) 
email addresses in all of the virus emails that I receive, so it seems
lke they are coming from somebody on these lists.

 [EMAIL PROTECTED] 4/13/04 10:46:46 AM 
Jeff Tulley wrote:

If I am not mistaken, this email probably results from somebody on
the
list having one of the many recent viruses.

Actually, that is not necessary to see messages like this.  All that 
needs to happen is that someone who is infected has both the email 
address of a subscriber and the email address of the mailing list 
visible (in an address book or something).  The infected party does 
*not* have to be a subscriber himself or herself.

Craig


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


Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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



RE: TC evolment

2004-03-31 Thread Jeff Tulley
 -Original Message-
 From: Andy Armstrong
 
   Heretic perhaps, but I'd like to integrate PHP (perhaps even
Perl) 
   directly with TC.
 
 What do you mean by 'integrate'? Have tomcat handle PHP 
 requests by some means?
 

mod_php inside TC.

I found out that TC is only 8% slower the Apache2.x.
So if I need PHP and JSP, the Apache2 is total overhead.

So at last year's JavaOne conference, it was mentioned that Tomcat was
going to support PHP.  I thought that odd, since this community itself
wasn't talking about it necessarily.  I think what it really was getting
to was JSR 223, which deals with interoperability between scripting
languages (PHP being the first candidate) and Java.

I do not know what is happening with JSR 223...

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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



Tomcat 4.1.30 admin application problem

2004-03-31 Thread Jeff Tulley
So a while back we found that the Tomcat admin application does not
function very well in the 4.1.30 release due to a mismatch caused by an
unfortunate CVS tagging problem.

Are there any plans to release a blessed patch - including the files
that should have been released but weren't, or are there plans for a
4.1.31?

We need to know what to do since I need to put a 4.1.30 version in the
next NetWare 6.5 update (support pack, or fixpack).  I know of one
.class file that I could put in common\classes , but I do not want to be
missing any other classes that should be included as well.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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



RE: Tomcat 4.1.30 admin application problem

2004-03-31 Thread Jeff Tulley
Thanks Larry - I'll do that.

Of course, not having an official patch or release or these
instructions visible leaves a lot of users who do not download that LE
version with a broken admin.

 [EMAIL PROTECTED] 3/31/04 1:15:45 PM 
Jeff,

It appears that the 4.1.30-LE-jdk14 versions were built later with
the correct code.  I was only able to duplicate the problem with
the non-LE versions.  So the workaround for now is to use the
4.1.30-LE-jdk14 version if possible, or copy the tomcat-coyote.jar
from an LE version to the non-LE installation's server/lib.  I
documented this in the bug:

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

Cheers,
Larry

 -Original Message-
 From: Jeff Tulley [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, March 31, 2004 2:35 PM
 To: [EMAIL PROTECTED] 
 Subject: Tomcat 4.1.30 admin application problem
 
 
 So a while back we found that the Tomcat admin application does not
 function very well in the 4.1.30 release due to a mismatch 
 caused by an
 unfortunate CVS tagging problem.
 
 Are there any plans to release a blessed patch - including the
files
 that should have been released but weren't, or are there plans for a
 4.1.31?
 
 We need to know what to do since I need to put a 4.1.30 version in
the
 next NetWare 6.5 update (support pack, or fixpack).  I know of
one
 .class file that I could put in common\classes , but I do not 
 want to be
 missing any other classes that should be included as well.
 
 Jeff Tulley  ([EMAIL PROTECTED])
 (801)861-5322
 Novell, Inc., The Leading Provider of Net Business Solutions
 http://www.novell.com 
 

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

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


Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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



Re: allowTrace attribute causing problems inthe adminapplication

2004-03-01 Thread Jeff Tulley
Thanks Guenter.  I'm actually acutely aware of that, being the person
responsible for configuring and installing Tomcat on NetWare 6.5.

I had it in my example steps below, since that is exactly what appears
on a clean install right from the tarball or zip file.

THe problem turned out to be a CVS tagging issue.  My patch worked not
because of the code that I put into it, but since I was effectively
adding the connector part of Larry's fixes to 4.1.30 where they had been
missing before.

 [EMAIL PROTECTED] 2/27/04 4:21:57 PM 
Hi Jeff,
I've not seen the first post from you, so ignore if that isnt your
problem...
 I just did the following steps:
 1) downloaded jakarta-tomcat-4.1.30.zip from jakarta.apache.org
 2) unzipped the zip file
 3) edited conf\tomcat-users.xml, adding the admin and manager
roles
 to the tomcat user
 4) Start up Tomcat (catalina start)
 5) hit http://localhost:8080 
 6) Navigate to the Tomcat Administration link
 7) login as tomcat
 8) Click on the icon that expances Service(Tomcat-Standalone)
 9) Click on Connector(8009)
 10) have the problem
port 8009 isnt free on NetWare but used by RemoteManager, you have to
configure another one for the connector in server.xml

Guenter.



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


Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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



Re: [OT] [FW: Please update your email address...]

2004-02-27 Thread Jeff Tulley
This has happened to a few people in the last few months.  Whomever from
radgametools that is subscribed here needs to unsubscribe out of
curteousy to the rest of the group, or subscribe on of these accepted
addresses they list.

 [EMAIL PROTECTED] 2/27/04 6:33:38 AM 
 
Anyone has a clue why I'm receiving this on each mail send to this
group?

 -Original Message-
 From: Autoresponder [mailto:[EMAIL PROTECTED] 
 Sent: Friday, February 27, 2004 2:17 PM
 To: [EMAIL PROTECTED] 
 Subject: Please update your email address...
 
 Reply-To: Autoresponder [EMAIL PROTECTED]
 X-Loop: [EMAIL PROTECTED] 
 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
 X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N
 
  We're sorry, but the RAD general email addresses have 
 changed recently (to slow the flood of spam sigh).  Please 
 use one of these addresses instead:  Sales: 
 [EMAIL PROTECTED]  RAD Video Tools Support: 
 [EMAIL PROTECTED]  Bink SDK Support: 
 [EMAIL PROTECTED]  Miles SDK Support: 
 [EMAIL PROTECTED]  Granny SDK Support: 
 [EMAIL PROTECTED]  Pixomatic SDK Support: 
 [EMAIL PROTECTED]  Smacker SDK Support: 
 [EMAIL PROTECTED]  Webmaster: 
 [EMAIL PROTECTED]   Sorry for the inconvenience and 
 thanks for your support!  RAD Game Tools 


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


Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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



allowTrace attribute causing problems in the admin application

2004-02-27 Thread Jeff Tulley
When I browse to a Coyote Connector in Tomcat's admin in 4.1.30, I get
an HTTP 500 error - Error retrieving attribute allowTrace.  I know the
allowTrace functionality was added about a month ago, and was not a
required attribute on the connector.

This functionality works in Tomcat 5.0.19, but not 4.1.30

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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



Re: allowTrace attribute causing problems in the admin application

2004-02-27 Thread Jeff Tulley
Actually, if I am not mistaken, the attached txt file patches the
problem.  An IntrospectionHelper.setProperty was needed for allowTrace. 
On 5.0.x this was done automatically by setting a property in the
setAllowTrace setter.  Then the properties were set into
IntrospectionHelper en masse later.

This patch works for me, at least.

Attached: patch.txt

 [EMAIL PROTECTED] 2/27/04 1:13:02 PM 
When I browse to a Coyote Connector in Tomcat's admin in 4.1.30, I get
an HTTP 500 error - Error retrieving attribute allowTrace.  I know
the
allowTrace functionality was added about a month ago, and was not a
required attribute on the connector.

This functionality works in Tomcat 5.0.19, but not 4.1.30

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com 

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


Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com
Index: org/apache/coyote/tomcat4/CoyoteConnector.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteConnector.java,v
retrieving revision 1.34
diff -u -r1.34 CoyoteConnector.java
--- org/apache/coyote/tomcat4/CoyoteConnector.java  24 Feb 2004 08:54:29 - 
 1.34
+++ org/apache/coyote/tomcat4/CoyoteConnector.java  27 Feb 2004 20:45:01 -
@@ -1198,6 +1198,8 @@
 + tomcatAuthentication);
 IntrospectionUtils.setProperty(protocolHandler, compression,
compression);
+IntrospectionUtils.setProperty(protocolHandler, allowTrace,
++ allowTrace);
 if (address != null) {
 IntrospectionUtils.setProperty(protocolHandler, address,
address);

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

RE: allowTrace attribute causing problems in the adminapplication

2004-02-27 Thread Jeff Tulley
Yeah, I saw this on a newly-downloaded Tomcat 4.1.30 on SUSE linux 8.2,
java 1.3.1 (Sun?)  I first saw it on NetWare, JVM 1.4.2.  I thought it
was something I had done wrong on NetWare, so I quickly tried it on
Linux.

Let me try a restart as you suggest, and try it on Windows with a clean
download.

 [EMAIL PROTECTED] 2/27/04 2:42:54 PM 
Hi Jeff,

I tested this before the 4.1.30 release, and just retested it,
and it continues to work for me without your patch.  Since the
protocolHandler doesn't support the allowTrace property, the
setProperty() is unnecessary in Tomcat 5.0.x and shouldn't make
a difference in Tomcat 4.1.30.  It is safer to keep the
setProperty() in Tomcat 5 in case somebody cut  pastes the
setAllowTrace() method for some new property that does need it.

Maybe a restart magically made the problem disappear.  Does
your 4.1.30 consistently show this problem without your patch?

Cheers,
Larry

 -Original Message-
 From: Jeff Tulley [mailto:[EMAIL PROTECTED] 
 Sent: Friday, February 27, 2004 3:48 PM
 To: [EMAIL PROTECTED] 
 Subject: Re: allowTrace attribute causing problems in the 
 adminapplication
 
 
 Actually, if I am not mistaken, the attached txt file patches the
 problem.  An IntrospectionHelper.setProperty was needed for 
 allowTrace. 
 On 5.0.x this was done automatically by setting a property in the
 setAllowTrace setter.  Then the properties were set into
 IntrospectionHelper en masse later.
 
 This patch works for me, at least.
 
 Attached: patch.txt
 
  [EMAIL PROTECTED] 2/27/04 1:13:02 PM 
 When I browse to a Coyote Connector in Tomcat's admin in 4.1.30, I
get
 an HTTP 500 error - Error retrieving attribute allowTrace.  I know
 the
 allowTrace functionality was added about a month ago, and was not a
 required attribute on the connector.
 
 This functionality works in Tomcat 5.0.19, but not 4.1.30
 
 Jeff Tulley  ([EMAIL PROTECTED])
 (801)861-5322
 Novell, Inc., The Leading Provider of Net Business Solutions
 http://www.novell.com 
 

-
 To unsubscribe, e-mail: [EMAIL PROTECTED] 
 For additional commands, e-mail: [EMAIL PROTECTED] 
 
 
 Jeff Tulley  ([EMAIL PROTECTED])
 (801)861-5322
 Novell, Inc., The Leading Provider of Net Business Solutions
 http://www.novell.com 
 

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


Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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



Re: allowTrace attribute causing problems in the adminapplication

2004-02-27 Thread Jeff Tulley
I just did the following steps:
1) downloaded jakarta-tomcat-4.1.30.zip from jakarta.apache.org
2) unzipped the zip file
3) edited conf\tomcat-users.xml, adding the admin and manager roles
to the tomcat user
4) Start up Tomcat (catalina start)
5) hit http://localhost:8080
6) Navigate to the Tomcat Administration link
7) login as tomcat
8) Click on the icon that expances Service(Tomcat-Standalone)
9) Click on Connector(8009)
10) have the problem 

These are the exact same steps I did with the tarball on Linux.

I haven't tried out my fix on the Windows install, the steps above are
hot off of the presses.  :)

 [EMAIL PROTECTED] 2/27/04 3:36:02 PM 
I can't reproduce this one either.  Clean install might be the
answer...


 Yeah, I saw this on a newly-downloaded Tomcat 4.1.30 on SUSE linux
8.2,
 java 1.3.1 (Sun?)  I first saw it on NetWare, JVM 1.4.2.  I thought
it
 was something I had done wrong on NetWare, so I quickly tried it on
 Linux.
 
 Let me try a restart as you suggest, and try it on Windows with a
clean
 download.

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


Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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



RE: allowTrace attribute causing problems inthe adminapplication

2004-02-27 Thread Jeff Tulley
I'm wondering if it is fixed in the head of CVS in some manner, then

 [EMAIL PROTECTED] 2/27/04 3:57:05 PM 
Just rebuilt Tomcat 4 from CVS, followed your steps and I do not see
this
problem. (Win XP, JDK1.4.2_03).

 -Original Message-
 From: Jeff Tulley [mailto:[EMAIL PROTECTED] 
 Sent: Friday, February 27, 2004 10:44 PM
 To: [EMAIL PROTECTED] 
 Subject: Re: allowTrace attribute causing problems inthe 
 adminapplication
 
 I just did the following steps:
 1) downloaded jakarta-tomcat-4.1.30.zip from jakarta.apache.org
 2) unzipped the zip file
 3) edited conf\tomcat-users.xml, adding the admin and 
 manager roles
 to the tomcat user
 4) Start up Tomcat (catalina start)
 5) hit http://localhost:8080 
 6) Navigate to the Tomcat Administration link
 7) login as tomcat
 8) Click on the icon that expances Service(Tomcat-Standalone)
 9) Click on Connector(8009)
 10) have the problem 
 
 These are the exact same steps I did with the tarball on Linux.
 
 I haven't tried out my fix on the Windows install, the steps above
are
 hot off of the presses.  :)
 
  [EMAIL PROTECTED] 2/27/04 3:36:02 PM 
 I can't reproduce this one either.  Clean install might be the
 answer...
 
 
  Yeah, I saw this on a newly-downloaded Tomcat 4.1.30 on SUSE linux
 8.2,
  java 1.3.1 (Sun?)  I first saw it on NetWare, JVM 1.4.2.  I
thought
 it
  was something I had done wrong on NetWare, so I quickly tried it
on
  Linux.
  
  Let me try a restart as you suggest, and try it on Windows with a
 clean
  download.
 

-
 To unsubscribe, e-mail: [EMAIL PROTECTED] 
 For additional commands, e-mail: [EMAIL PROTECTED] 
 
 
 Jeff Tulley  ([EMAIL PROTECTED])
 (801)861-5322
 Novell, Inc., The Leading Provider of Net Business Solutions
 http://www.novell.com 
 

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



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


Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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



Re: allowTrace attribute causing problems in the adminapplication

2004-02-27 Thread Jeff Tulley
Yeah, that's what it looked like.  Larry's backport of the allowTrace
stuff in the connector code came after the TOMCAT_4_1_30 tag, whereas in
the admin application, the file that wanted to look for the allowTrace,
in EditConnectorAction.java WAS tagged with 4.1.30

 [EMAIL PROTECTED] 2/27/04 4:03:38 PM 
K.  I can reproduce the problem with 4.1.30 build but not in the
workspace.
Looks like the latest org.apache.coyote.tomcat4.CoyoteConnector with
allowTrace didn't get tagged for 4.1.30.  4.1.30 tag has outdated
o.a.c.tomcat4.CoyoteConnector

Amy


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


Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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



[Proposal] Get our FAQ listed on jakarta.apache.org/site/faqs.html

2004-02-04 Thread Jeff Tulley
I think we need to get Tomcat's FAQ page listed on
http://jakarta.apache.org/site/faqs.html  since that is the place
that the Our FAQS link in the left-side navigation of
http://jakarta.apache.org points to.  I think it would raise the FAQ
visibility a bit, which would be a good thing for the user list.

How do we (really, a committer, probably) go about this?

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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



Re: status of JTA integration

2004-01-16 Thread Jeff Tulley
Last I checked (a while ago, admittedly), JBoss was architected such
that you can deploy only the pieces you need - VERY modular.  So, you
can make it not a monster, but rather just Tomcat + JTA, if I am not
mistaken.  It seemed at the time (early JBoss 3.0 days) that such a
thing was not that hard either.

 [EMAIL PROTECTED] 1/16/04 4:59:26 AM 

I might try that, although currently my patched version of tyrex works

fine and I'm a little reluctant to put in a monster like jboss just for

JTA and connection pooling but if the tyrex people will not accept my 
additions/fixes in CVS tyrex is of course a dead end and jboss might be

the only sensible way to go.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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



Re: Memory leak- yeah I know

2004-01-14 Thread Jeff Tulley
How heavy of a load does this generate, in terms of # of req/s?

 [EMAIL PROTECTED] 1/14/04 3:49:00 PM 
Ok, I know that these emails are usually dismissed with the words:
Gets us some proof from a profiler, and I will...gimme some time, in
the
meanwhile, if anyone else wants to play with it.

well the story is that during heavy load tests of the session
replication my
system my VMs always run out of memory.
What am I doing different than others, well, during my load tests I am
not
using keep alive connections to achieve true round robin. I'm doing
this by
setting method.setHttp11(false) in the Http client.

Running the test (attached, instructions below) I am hitting
http://localhost:8080/index.jsp (home page) and watching the memory
grow and
grow and grow.

I am using a profiler and having somewhat of a hard time reading the
output.
I am gonna download a trial of jprobe, see how that works out for me...
I
will be back with results from that.

in the meantime, for those who want to see their memory grow here are
the
instructions

My env:
Machine: PIII 1.6Ghz, 512MB Ram
OS: Redhat 8
VM: Sun JDK 1.4.2_02 (build 1.4.2_02-b03)

Instructions:
download the attached client.jar

execute:
java -cp testclient.jar;commons-httpclient.jar;commons-logging.jar
org.apache.catalina.cluster.test.client.MemTestClient http
://192.168.0.103:7080/index.jsp 100 10 1000 false (exchange ; for :
on
unix)

Watching the memory grow using Top, although it shouldn't increase at
all.

Filip

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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



Re: Understanding jakarta-tomcat-4.0 cvs source base / jasper

2003-12-17 Thread Jeff Tulley
Kin-man,
   Thank you, that is exactly the answer I was looking for.  That makes
things a lot more clear.  I would suggest removing the j-t-4.0/jasper
directory then, since 4.0.x seems done with.

The source for Jasper in Tomcat 4.1.29 is from j-t-j/jasper2 with
Tomcat_4_branch tag.  The head branch is for Tomcat 5.

A lot of bugs filed against Tomcat 4.1.x has been fixed in Tomcat 5.
Unfortunately I don't have cycles to apply the fixes to 4.1.x.  It
would
be great if someone can do that, and I can help and/or anser questions
if
needed.

The branch jakarta-tomcat-4.0/jasper was used for Tomcat 4.0.x
releases,
and I don't think we are making new releases for Tomcat 4.0.x.

-Kin-man

 Quick question - Does the jasper that ships with Tomcat 4.1.29 come
from
 the source code in jakarta-tomcat-4.0/jasper, or is it from the
 jakarta-tomcat-jasper CVS module?
 
 I am looking at some bugs in Bugzilla against Jasper, where they
 complain about something in j-t-4.0/jasper/src/(some class), and the
bug
 is fixed in j-t-j/jasper2/src   I do not know whether to mark the
bug as
 fixed or investigate further.
 
 If the answer turns out that the source code in j-t-4/jasper is NOT
 being used, what is there against removing it to avoid confusion?


Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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



Understanding jakarta-tomcat-4.0 cvs source base / jasper

2003-12-15 Thread Jeff Tulley
Quick question - Does the jasper that ships with Tomcat 4.1.29 come from
the source code in jakarta-tomcat-4.0/jasper, or is it from the
jakarta-tomcat-jasper CVS module?

I am looking at some bugs in Bugzilla against Jasper, where they
complain about something in j-t-4.0/jasper/src/(some class), and the bug
is fixed in j-t-j/jasper2/src   I do not know whether to mark the bug as
fixed or investigate further.

If the answer turns out that the source code in j-t-4/jasper is NOT
being used, what is there against removing it to avoid confusion?

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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



Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java

2003-12-10 Thread Jeff Tulley
http://jakarta.apache.org/site/getinvolved.html 

 [EMAIL PROTECTED] 12/9/03 5:40:18 AM 
How do I join as Developer...

Basu.

- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Tuesday, December 09, 2003 3:12 PM
Subject: Re: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm
RealmBase.java


 [EMAIL PROTECTED] wrote:
  amyroh  2003/12/08 17:54:33
 
Modified:catalina/src/share/org/apache/catalina/core
  ApplicationFilterFactory.java
 catalina/src/share/org/apache/catalina/realm
RealmBase.java
Log:
Revert the patch.  Seems like this case is already handled in the
Mapper in TC5.

 M, forget my -1 (I should read *all* my email before replying) :-D
 Note that there's an open bug about this: bug 25015
 (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25015). Could you get
 some spec related folk to comment on it ?

 The ex was:
 http://localhost/appname/servlet-name/extra;path/info;here/hi.jsp 

 Looking at the URI RFC, I think this should be changed to:
 http://localhost/appname/servlet-name/extra/info/hi.jsp 

 Rémy



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



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



Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com


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



RE: Any clue on this, please? Uploading large files - out of memory

2003-12-03 Thread Jeff Tulley
Or, configuration.  Consider what I ran into the last few weeks.  We
were doing very high load testing of Tomcat and getting the dreaded
OutOfMemory error simply hitting the Tomcat examples.  I immediately
thought this to be bug as well.  Well, after using OptimizeIt on the
code, I found out that the culprit is that we were creating so many
sessions that we used up all of the memory before we hit the session
timeout.  This is a tuning problem, not a bug.  I could
1) Throw more memory at Tomcat (we had -Xmx256m)
2) Decrease the session timeout.  The default is good in most cases of
not-so-extreme traffic
3) Ponder on whether load testing 500-600 req/s, with each request
being a completely new session is a valid test scenario.  (Sometime it
is:  Think getting slash-dotted)

I also think that a lot of the more bizarre OOM errors being reported
on the user list currently, when reloading contexts for instance, have
to do with the newer GC model of new/old/permanent generation divisions
- the permanent generation is filling even though old and new have room
to spare.  This is also tuning.  (Well, the user did say that Sun is
doing a fix for that, so I guess it could be either)

That all said, OptimizeIt is well worth the money spent.  It vastly
decreased the amount of time spent tracking down my OOM error.  (After 3
or so days of staring at heap dumps, we just got OptimizeIt, and found
the problem almost immediately).

On Wed, 3 Dec 2003, Adam Fisk wrote:

 I've heard mention on this list many times of these
OutOfMemoryErrors
 not being bugs.  I work on a Java app that experiences very high
network
 traffic load, however, and it's been my experience that
 OutOfMemoryErrors are, in fact, always bugs regardless of how
tempting
 it is to chalk it up to something else.

 What makes everyone so certain it's not a bug or multiple bugs?
Since
 you don't get stack traces and at best can pin down the thread name
for
 OutOfMemoryErrors, they take a lot of time to track down.  In my
 experience, though, they tend to result from an unaccounted for
 degenerate request coming that causes the code to, well, consume
all
the
 available memory (i.e., a bug).

 -Adam


 Shapira, Yoav wrote:

  Howdy,
  This belongs on the user, not dev, list.  It's most likely a
simple
  issue (not a bug) with you not allocating enough memory to the
JVM.
  Please pursue this issue on the user list.
 
  Yoav Shapira
  Millennium ChemInformatics


Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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



PGP signature on binary download page has a problem

2003-10-24 Thread Jeff Tulley
I just noticed a small problem on the binary downloads page under the
Tomcat section.  All of the PGP signatures come from the main
distributions site(as they should), not a mirror, EXCEPT the one for
4.1.27 exe - I see it coming from a mirror (using mirror
mirror2.telentente.com).


Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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



[Patch] BaseDirContextTestCase depcrecated junit methods

2003-10-23 Thread Jeff Tulley
Since assert is a reserved keyword, and is now part of the language,
junit moved away from using it for test assertions, opting instead for
things like assertTrue or assertEquals

Here is the patch for BaseDirContextTestCase, to bring it up to par with
junit's and Java's recommended practices.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com
Index: BaseDirContextTestCase.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/test/org/apache/naming/resources/BaseDirContextTestCase.java,v
retrieving revision 1.3
diff -u -r1.3 BaseDirContextTestCase.java
--- BaseDirContextTestCase.java 21 Oct 2001 22:03:34 -  1.3
+++ BaseDirContextTestCase.java 23 Oct 2003 22:16:03 -
@@ -247,7 +247,7 @@
 // Look up the WEB-INF entry
 Object webInfEntry = context.lookup(WEB-INF);
 assertNotNull(Found WEB-INF entry, webInfEntry);
-assert(WEB-INF entry is a DirContext,
+assertTrue(WEB-INF entry is a DirContext,
webInfEntry instanceof DirContext);
 DirContext webInfContext = (DirContext) webInfEntry;
 
@@ -303,7 +303,7 @@
 // Look up the WEB-INF entry
 Object webInfEntry = context.lookup(WEB-INF);
 assertNotNull(Found WEB-INF entry, webInfEntry);
-assert(WEB-INF entry is a DirContext,
+assertTrue(WEB-INF entry is a DirContext,
webInfEntry instanceof DirContext);
 DirContext webInfContext = (DirContext) webInfEntry;
 
@@ -353,20 +353,20 @@
 while (ne.hasMore()) {
 
 Object next = ne.next();
-assert(list() returns NameClassPair instances,
+assertTrue(list() returns NameClassPair instances,
next instanceof NameClassPair);
 NameClassPair ncp = (NameClassPair) next;
 
-assert(Name ' + ncp.getName() + ' is expected,
+assertTrue(Name ' + ncp.getName() + ' is expected,
isListed(ncp.getName(), list));
 
 if (isDirContext(ncp.getName())) {
-assert(Class ' + ncp.getClassName() + ' is ' +
+assertTrue(Class ' + ncp.getClassName() + ' is ' +
contextClassName + ',
contextClassName.equals(ncp.getClassName()));
 }
 
-assert(Relative is 'true', ncp.isRelative());
+assertTrue(Relative is 'true', ncp.isRelative());
 
 }
 
@@ -391,29 +391,29 @@
 while (ne.hasMore()) {
 
 Object next = ne.next();
-assert(listBindings() returns Binding instances,
+assertTrue(listBindings() returns Binding instances,
next instanceof Binding);
 Binding b = (Binding) next;
 
-assert(Name ' + b.getName() + ' is expected,
+assertTrue(Name ' + b.getName() + ' is expected,
isListed(b.getName(), list));
 
 if (isDirContext(b.getName())) {
-assert(Class ' + b.getClassName() + ' is ' +
+assertTrue(Class ' + b.getClassName() + ' is ' +
contextClassName + ',
contextClassName.equals(b.getClassName()));
 }
 
-assert(Relative is 'true', b.isRelative());
+assertTrue(Relative is 'true', b.isRelative());
 
 Object object = b.getObject();
 assertNotNull(Name ' + b.getName() + ' has a non-null object,
   object);
 if (b.getName().equals(web.xml)) {
-assert(Entry ' + b.getName() + ' is a Resource,
+assertTrue(Entry ' + b.getName() + ' is a Resource,
object instanceof Resource);
 } else {
-assert(Entry ' + b.getName() + ' is a DirContext,
+assertTrue(Entry ' + b.getName() + ' is a DirContext,
object instanceof DirContext);
 }
 
@@ -445,35 +445,35 @@
 while (ne.hasMore()) {
 
 Object next = ne.next();
-assert(getAll() returns Attribute instances,
+assertTrue(getAll() returns Attribute instances,
next instanceof Attribute);
 Attribute attr = (Attribute) next;
 String name = attr.getID();
 int index = getIndex(name, webInfAttrs);
-assert(WEB-INF attribute ' + name + ' is expected,
+assertTrue(WEB-INF attribute ' + name + ' is expected,
index = 0);
 Object value = attr.get();
 assertNotNull(get() returned non-null, value);
 
 if (name.equals(creationdate)) {
-assert(Creation date is a date,
+assertTrue(Creation date is a date

Re: jk2 evolution plan

2003-10-21 Thread Jeff Tulley
Sorry for the late reply on this.  I'd also like to help out with
mod_jk2 and this move to apr.  Mostly for the sake of the NetWare
platform, though I need to understand the Linux connectors well as well.

Let me know where I can be of service.  I have a little experience with
the connectors, though mostly mod_jk.  I will do my best to get up to
speed on it though and help out.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com
 [EMAIL PROTECTED] 10/17/03 5:41 AM 
+1

I can help out.

This is a significant change for a minor revision to 2.0.4,
perhaps we should bump it to 2.1 or even 3.0?

Glenn

Henri Gomez wrote:
 Ok, about everybody seems to agree on using apr for jk2
 (still waiting Nacho for IIS).
 
 APR side will be to :
 
 - Update doc to indicate that APR is mandatory
 
 - Remove #idef APR
 
 - Use APR for all OS operation and sus will save us from
   handling all the #include for all the diverses IO operation
   (it's really a pain).
 
 - For now still use_jk pool, but the version using apr_tools.
 
 - Make socket use apr_socket for compatibility.
 
 
 JK to JK2 fonctionnalities backport :
 
 - Check features added in jk and not present in jk2 (ie cping/cpong).
   There was also some specific lb workers settings which should be
   studied.
 
 - After this works, make a 2.0.4 release and start extensive
   testing.
 
 
 On the channel side I added a new method, hasinput which should help
 use determine if there is something to do on 'stream connections'.
 
 For instance, it's used in jk/jk2 by the cping/cpong stage when
 connectTimeout, prepostTimeout and replyTimeout are set.
 
 
 And no the who's who ;)
 
 I'd like to know who could works on jk2 evolution.
 
 BTW, where could we find today the jk/jk2 documentation which is
 regenerated each day  ?


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



Re: New builds ?

2003-10-20 Thread Jeff Tulley
Nothing yet found on the NetWare side, though we have not yet pounded it
hard.  4.1.28 has been only better than 4.1.27 as far as I'm concerned. 
I'd be desirous to see a vote and (hopefully) have it determined to be
stable.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

 [EMAIL PROTECTED] 10/20/03 10:33:55 AM 
So, what do we do with 4.1.28 ? AFAIK, no significant issue has been 
found with this build, with minor tweaks being made since then in the 
connectors.
Is a 4.1.29 needed, or is it simply people forgot about that build ?

OTOH, there has been a few useful fixes and tweaks since 5.0.13 in the

5.0 branch, so I'll tag a new 5.0.14 at the end of the week (these .13

builds are all cursed :-D).

Comments ?

Remy



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


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



Re: Jakarta Tomcat 4.1 XSS vulnerability

2003-09-29 Thread Jeff Tulley
I've found a very good explanation of XSS:
http://www.spidynamics.com/whitepapers/SPIcross-sitescripting.pdf 


Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

 [EMAIL PROTECTED] 9/29/03 2:26:54 PM 
Actually this could be issue on a poorly configured site where the
admin does 
not override the default error pages. It would make it very easy to
steal 
someone's cookies or session.

So while might be an issue (I personally haven't checked), its not an
issue 
if the admin configures custom error pages to show instead of
displaying the 
default.

-Tim

Remy Maucherat wrote:

 David Rees wrote:
 
 Anyone know how serious this is?
 
 
 Lol.
 If you're affected by XSS, then you have a problem (no site in the
world 
 deserves any privilege: *all* need javascript blocking these days).
 
 It also appears to affect Tomcat 4.1.27 when using mod_jk as well. 
Below
 is a sample trace of a HTTP session.
 
 
 Remy 


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


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



CoyoteRequest assumption that breaks UTF-8 support

2003-09-25 Thread Jeff Tulley
I am convinced that Tomcat 4.x has a very real bug when dealing with
character encodings on login form submissions. (maybe elsewhere as
well).

To see what I am observing, watch the flow of code when doing a login
from Tomcat's admin application.  It sets the charset to UTF-8 in the
tag
%@ page language=java contentType=text/html;charset=UTF-8
import=java.util.* %  at the top of the file.  This correctly gets
the browser into unicode mode, and (with all of the browsers I have
tested - IE and NS 7 on windows, and Konqueror on SUSE Linux), they
correctly encode your username / password in UTF-8.

But, in CoyoteRequest, parseRequestParameters(), Tomcat tries to
determine and set the encoding to be used and ends up setting it to be
null.  Why?  It looks like in Request.getCharacterEncoding and
subordinate methods, the header value, content-type is checked.  On
all of the browsers that I have checked if this value is set at all, it
is simply set to application/x-www-form-urlencoded, without mention of
UTF-8 or any other charset.  The browser assumes that since you
requested a certain charset in the first place, that you know how to
deal with a parameter that is sent on encoded in that charset.

Tomcat sees no mention of charsets, so it simply defaults to
ISO-8859-1 (hardcoded constant)

Is there a better way to tie the default value to whatever the JSP
login form originally requested, or even, failing that, can we look up
the system property, file.encoding, and require it to be passed in on
startup.  This is less than ideal though.  Preferrably it would be
something settable context-wide, not tomcat-wide.

Where does this leave applications that wish to support extended
characters in passwords and/or usernames, characters that may not be in
the ISO-8859-1 range?

Or am I missing the correct place to set this?

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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



RE: CoyoteRequest assumption that breaks UTF-8 support

2003-09-25 Thread Jeff Tulley
Yes, in MY application I will do that.  Namely, I will decide on one
type of encoding to use and pull the arguments out in that encoding
using getBytes(encType). That is the correct way of doing it.

What I am talking about is Tomcat's built-in container-managed
security.  When you specify a security constraint of form-based login,
and have a form that submits to j_security_check, and let Tomcat handle
the details using one of its many Realms.

This IS a bug, or at least a severe limit in functionality.  As far as
I can tell, there is no way to handle UTF-8 usernames and passwords
doing container-managed security.  Once again, unless I'm missing some
way to tell the browser to send on the content-type to j_security_check.
 I have thoroughly investigated that, and think that I'm indeed not
missing anything.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

 [EMAIL PROTECTED] 9/25/03 12:09:02 PM 
This is not a bug. Read http://asg.web.cmu.edu/rfc/rfc2070.html#sec-5.
Use this code:
String result = req.getParameter(parm);

if (result == null)
return null;

try
{
return new String(result.getBytes(ISO-8859-1),
UTF-8);
}
catch (UnsupportedEncodingException e)
{
return result;
}

Dave Oxley
[EMAIL PROTECTED] 


 -Original Message-
 From: Jeff Tulley [mailto:[EMAIL PROTECTED] 
 Sent: Thursday, September 25, 2003 6:40 PM
 To: [EMAIL PROTECTED] 
 Subject: CoyoteRequest assumption that breaks UTF-8 support
 
 I am convinced that Tomcat 4.x has a very real bug when dealing with
 character encodings on login form submissions. (maybe elsewhere as
 well).
 
 To see what I am observing, watch the flow of code when doing a
login
 from Tomcat's admin application.  It sets the charset to UTF-8 in
the
 tag
 %@ page language=java contentType=text/html;charset=UTF-8
 import=java.util.* %  at the top of the file.  This correctly
gets
 the browser into unicode mode, and (with all of the browsers I have
 tested - IE and NS 7 on windows, and Konqueror on SUSE Linux), they
 correctly encode your username / password in UTF-8.
 
 But, in CoyoteRequest, parseRequestParameters(), Tomcat tries to
 determine and set the encoding to be used and ends up setting it to
be
 null.  Why?  It looks like in Request.getCharacterEncoding and
 subordinate methods, the header value, content-type is checked. 
On
 all of the browsers that I have checked if this value is set at all,
it
 is simply set to application/x-www-form-urlencoded, without mention
of
 UTF-8 or any other charset.  The browser assumes that since you
 requested a certain charset in the first place, that you know how to
 deal with a parameter that is sent on encoded in that charset.
 
 Tomcat sees no mention of charsets, so it simply defaults to
 ISO-8859-1 (hardcoded constant)
 
 Is there a better way to tie the default value to whatever the JSP
 login form originally requested, or even, failing that, can we look
up
 the system property, file.encoding, and require it to be passed in
on
 startup.  This is less than ideal though.  Preferrably it would be
 something settable context-wide, not tomcat-wide.
 
 Where does this leave applications that wish to support extended
 characters in passwords and/or usernames, characters that may not be
in
 the ISO-8859-1 range?
 
 Or am I missing the correct place to set this?
 
 Jeff Tulley  ([EMAIL PROTECTED])
 (801)861-5322
 Novell, Inc., The Leading Provider of Net Business Solutions
 http://www.novell.com 
 

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


 This e-mail has been scanned for all viruses by Star Internet. The
 service is powered by MessageLabs. For more information on a
proactive
 anti-virus service working around the clock, around the globe,
visit:
 http://www.star.net.uk 





This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk 


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



Re: AW: AW: AW: [5.0] JSP performance ...

2003-09-09 Thread Jeff Tulley
Torsten,
   Your attachment didn't come through. (Common mistake, I've made it dozens of 
times).  Rename the file as .txt, that should work.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

 [EMAIL PROTECTED] 9/9/03 5:55:27 AM 

patched a snapshot to merge template text nodes.

I implement following using a additional visitor in Generator.java
 - char[] arrays for templatetexts
 - same templatetexts - only 1 char array for text, better without merging

good/bad gimmicks: 
  - removing empty templatetexts, example: only \r\n, , null and so
  - removing \r\n after scripting elements

One effect, i see is a lower memory usage from jasper pages 

cu Torsten Fohrer

-Ursprüngliche Nachricht-
Von: Remy Maucherat [mailto:[EMAIL PROTECTED] 
Gesendet: Dienstag, 9. September 2003 11:31
An: Tomcat Developers List
Betreff: Re: AW: AW: [5.0] JSP performance ...


Torsten Fohrer wrote:

 what's about char[] array/string reusing?
 Create only a char array for each unique templatetext node. 
 
 - 
   10 x char[] jspx_text_1 = something\n;
   1  x char[] jspx_text_1 = something\n;

Won't the VM do that internally ?
Since apparently you have examined that issue in detail already, maybe 
you can give more details :)

- What exactly did you implement ?
- What's the code it generates ? Does it also merge the TemplateText nodes ?
- Did it improve performance ? For example, if you try to run the test I 
gave, what kind of performance increase do you see ?

Remy



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





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



Re: [PATCH] CGI Servlet bugs

2003-09-02 Thread Jeff Tulley
I see a few possible issues.
1) Don't append \, instead use File.separatorChar
2) is case sensitivity an issue where you are doing the
command.endsWith(.pl) || command.endsWith(.cgi) commands?
  It seems like getCanonicalPath will, on some platforms, return the
exact case of the file as it is on disk.  I thought Windows does that.
(Well, Sun's JVM 1.3.1 on Windows I think is the exact one, I think).

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

 [EMAIL PROTECTED] 9/2/03 2:51:27 PM 
Below is a patch for bug 22857, bug 22858 and one additional issue I
found 
whilst looking at the other issues. I am concerned that the patch may
only work 
on windows platforms and would appreciate it if someone with
non-Windows 
knowledge could review this patch.

I have included TC5 and TC4 patches.

Mark

Index: catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catali
 
na/servlets/CGIServlet.java,v
retrieving revision 1.5
diff -u -r1.5 CGIServlet.java
---
catalina/src/share/org/apache/catalina/servlets/CGIServlet.java 22
Nov 2002 
22:26:08 -  1.5
+++
catalina/src/share/org/apache/catalina/servlets/CGIServlet.java 2
Sep 2003 
20:31:03 -
@@ -750,7 +750,7 @@
  *
  */
 protected CGIEnvironment(HttpServletRequest req,
- ServletContext context) {
+ ServletContext context) throws
IOException {
 setupFromContext(context);
 setupFromRequest(req);

@@ -946,7 +946,7 @@
  * @return   true if environment was set OK, false if there
  *   was a problem and no environment was set
  */
-protected boolean setCGIEnvironment(HttpServletRequest req) {
+protected boolean setCGIEnvironment(HttpServletRequest req)
throws 
IOException {

 /*
  * This method is slightly ugly; c'est la vie.
@@ -1109,7 +1109,9 @@
 }
 }

-command = sCGIFullPath;
+File fCGIFullPath = new File(sCGIFullPath);
+command = fCGIFullPath.getCanonicalPath();
+
 envp.put(X_TOMCAT_SCRIPT_PATH, command);  //for kicks

 this.env = envp;
@@ -1550,17 +1552,19 @@

 //create query arguments
 Enumeration paramNames = params.keys();
-StringBuffer cmdAndArgs = new StringBuffer(command);
+StringBuffer cmdAndArgs = new StringBuffer(\ + command
+ \);
 if (paramNames != null  paramNames.hasMoreElements()) {
 cmdAndArgs.append( );
 while (paramNames.hasMoreElements()) {
 String k = (String) paramNames.nextElement();
 String v = params.get(k).toString();
 if ((k.indexOf(=)  0)  (v.indexOf(=)  0))
{
+cmdAndArgs.append(\);
 cmdAndArgs.append(k);
 cmdAndArgs.append(=);
 v = java.net.URLEncoder.encode(v);
 cmdAndArgs.append(v);
+cmdAndArgs.append(\);
 cmdAndArgs.append( );
 }
 }
@@ -1573,11 +1577,9 @@
 env.put(CONTENT_LENGTH, new
Integer(contentLength));
 }*/

-if (command.endsWith(.pl) || command.endsWith(.cgi)) {
 StringBuffer perlCommand = new StringBuffer(perl );
 perlCommand.append(cmdAndArgs.toString());
 cmdAndArgs = perlCommand;
-}

 rt = Runtime.getRuntime();
 proc = rt.exec(cmdAndArgs.toString(),
hashToStringArray(env), wd);



Index: catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/se
 
rvlets/CGIServlet.java,v
retrieving revision 1.11
diff -u -r1.11 CGIServlet.java
---
catalina/src/share/org/apache/catalina/servlets/CGIServlet.java 4
Dec 2002 
21:09:07 -  1.11
+++
catalina/src/share/org/apache/catalina/servlets/CGIServlet.java 2
Sep 2003 
19:31:10 -
@@ -750,7 +750,7 @@
  *
  */
 protected CGIEnvironment(HttpServletRequest req,
- ServletContext context) {
+ ServletContext context) throws
IOException {
 setupFromContext(context);
 setupFromRequest(req);

@@ -946,7 +946,7 @@
  * @return   true if environment was set OK, false if there
  *   was a problem and no environment was set
  */
-protected boolean setCGIEnvironment(HttpServletRequest req) {
+protected boolean setCGIEnvironment

Re: [PATCH] CGI Servlet bugs

2003-09-02 Thread Jeff Tulley
Oh, ignore my item #2, I didn't see that you were DELETING the
command.endsWith stuff, not adding it.

Still, I think the item number one - not assuming the separator is a
\ is needed for OS portability, right?  It looks like this was just
committed as-is, not using File.separator or File.separatorChar

Amy?  (I may just be missing something here)

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

 [EMAIL PROTECTED] 9/2/03 2:51:27 PM 
Below is a patch for bug 22857, bug 22858 and one additional issue I
found 
whilst looking at the other issues. I am concerned that the patch may
only work 
on windows platforms and would appreciate it if someone with
non-Windows 
knowledge could review this patch.

I have included TC5 and TC4 patches.

Mark

Index: catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catali
 
na/servlets/CGIServlet.java,v
retrieving revision 1.5
diff -u -r1.5 CGIServlet.java
---
catalina/src/share/org/apache/catalina/servlets/CGIServlet.java 22
Nov 2002 
22:26:08 -  1.5
+++
catalina/src/share/org/apache/catalina/servlets/CGIServlet.java 2
Sep 2003 
20:31:03 -
@@ -750,7 +750,7 @@
  *
  */
 protected CGIEnvironment(HttpServletRequest req,
- ServletContext context) {
+ ServletContext context) throws
IOException {
 setupFromContext(context);
 setupFromRequest(req);

@@ -946,7 +946,7 @@
  * @return   true if environment was set OK, false if there
  *   was a problem and no environment was set
  */
-protected boolean setCGIEnvironment(HttpServletRequest req) {
+protected boolean setCGIEnvironment(HttpServletRequest req)
throws 
IOException {

 /*
  * This method is slightly ugly; c'est la vie.
@@ -1109,7 +1109,9 @@
 }
 }

-command = sCGIFullPath;
+File fCGIFullPath = new File(sCGIFullPath);
+command = fCGIFullPath.getCanonicalPath();
+
 envp.put(X_TOMCAT_SCRIPT_PATH, command);  //for kicks

 this.env = envp;
@@ -1550,17 +1552,19 @@

 //create query arguments
 Enumeration paramNames = params.keys();
-StringBuffer cmdAndArgs = new StringBuffer(command);
+StringBuffer cmdAndArgs = new StringBuffer(\ + command
+ \);
 if (paramNames != null  paramNames.hasMoreElements()) {
 cmdAndArgs.append( );
 while (paramNames.hasMoreElements()) {
 String k = (String) paramNames.nextElement();
 String v = params.get(k).toString();
 if ((k.indexOf(=)  0)  (v.indexOf(=)  0))
{
+cmdAndArgs.append(\);
 cmdAndArgs.append(k);
 cmdAndArgs.append(=);
 v = java.net.URLEncoder.encode(v);
 cmdAndArgs.append(v);
+cmdAndArgs.append(\);
 cmdAndArgs.append( );
 }
 }
@@ -1573,11 +1577,9 @@
 env.put(CONTENT_LENGTH, new
Integer(contentLength));
 }*/

-if (command.endsWith(.pl) || command.endsWith(.cgi)) {
 StringBuffer perlCommand = new StringBuffer(perl );
 perlCommand.append(cmdAndArgs.toString());
 cmdAndArgs = perlCommand;
-}

 rt = Runtime.getRuntime();
 proc = rt.exec(cmdAndArgs.toString(),
hashToStringArray(env), wd);



Index: catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/se
 
rvlets/CGIServlet.java,v
retrieving revision 1.11
diff -u -r1.11 CGIServlet.java
---
catalina/src/share/org/apache/catalina/servlets/CGIServlet.java 4
Dec 2002 
21:09:07 -  1.11
+++
catalina/src/share/org/apache/catalina/servlets/CGIServlet.java 2
Sep 2003 
19:31:10 -
@@ -750,7 +750,7 @@
  *
  */
 protected CGIEnvironment(HttpServletRequest req,
- ServletContext context) {
+ ServletContext context) throws
IOException {
 setupFromContext(context);
 setupFromRequest(req);

@@ -946,7 +946,7 @@
  * @return   true if environment was set OK, false if there
  *   was a problem and no environment was set
  */
-protected boolean setCGIEnvironment(HttpServletRequest req) {
+protected boolean setCGIEnvironment(HttpServletRequest req)
throws 
IOException

Re: [PATCH] CGI Servlet bugs

2003-09-02 Thread Jeff Tulley
Ah,  once again I'm up in the night.  *big sheepish grin*

I run at 1600x1200, and the double set of quotes looked like one quote.
 I guess my clue should have been that you would've put \\ for a
single backslash.

Sorry!  I saw the mention of a need for a review by those who deal with
other OS's and I got carried away, I guess.  :)

I'll go back to something else now

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

 [EMAIL PROTECTED] 9/2/03 5:47:32 PM 
Jeff Tulley wrote:
 Still, I think the item number one - not assuming the separator is a
 \ is needed for OS portability, right?  It looks like this was
just
 committed as-is, not using File.separator or File.separatorChar

You need to use File.separator for escaping double quote on different
OS?


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


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



[Patch] Multiple user patterns in JNDIRealm

2003-09-02 Thread Jeff Tulley
In the current JNDIRealm implementation, you can either have it find(and
authenticate) users via a search or through a user pattern.  Using the
subtree search has security ramifications  -- either you have to grant
public browse access to all containers in the directory where your user
objects are, or you need to grant a particular user those browse rights,
and then place that username and password in server.xml in plaintext. 
Using the user pattern, however if you want to do context-less login,
you are limited to only being able to authenticate users from one
container.

This patch extends the userPattern attribute so that it can have
multiple values.  Backwards compatibility is completely maintained.  The
notation for adding in multiple patterns is to surround each of them in
parentheses, for instance (cn={0},o=myorg)(cn={0},ou=users,o=myorg). 
Standard LDAP OR search syntax also works,
(|(cn={0},o=myorg)(cn={0},ou=users,o=myorg)).  I chose parentheses
because of its similarity to LDAP's search syntax, and also for the fact
that semicolons and commas are used to separate path components, and
colons are valid characters in the directory path.  Parentheses are
valid characters as well, but will be escaped if they are part of an
actual name.  The current syntax of cn={0},o=myorg, no parentheses,
still works.

The use case exactly then is if you want to provide context-less login
in multiple containers without the security ramifications of doing the
sub-tree LDAP search.

I've included some unit test code as well, testing the parsing of the
user pattern.  I attached that file in its entirety since it is new. 
Also attached -- a patch to build.xml to add in support for this unit
test code, and a patch to the realm-howto JNDIRealm section.

I would like this added into the 4.1 branch if possible, since I think
it fills a hole there.

Thanks,


Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com
RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/build.xml,v
retrieving revision 1.132
diff -u -r1.132 build.xml
--- build.xml   12 Mar 2003 21:38:05 -  1.132
+++ build.xml   28 Aug 2003 21:39:12 -
@@ -979,7 +979,7 @@
   !--  TEST: Execute Unit Tests == --
   target name=test if=junit.present
description=Run all unit test cases
-   depends=build-tests,test-dir-context,test-util
+   depends=build-tests,test-dir-context,test-realm,test-util
   /target
 
   target name=test-dir-context if=junit.present
@@ -1004,6 +1004,16 @@
 /java
 delete file=${test.webapp.war}/
 
+  /target
+
+  target name=test-realm if=junit.present
+
+echo message=Running Realm tests/
+java classname=${test.runner} fork=yes
+failonerror=${test.failonerror}
+  arg value=org.apache.catalina.realm.JNDIRealmTestCase/
+  classpath refid=test.classpath/
+/java
   /target
 
   target name=test-util if=junit.present

/*
 * $Header: 
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/test/org/apache/catalina/realm/JNDIRealmTestCase.java
 * $Revision: 1 $
 * $Date: 2003/08/27 00:54:26 $
 *
 * 
 * The Apache Software License, Version 1.1
 *
 * Copyright (c) 2003 The Apache Software Foundation.  All rights
 * reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in
 *the documentation and/or other materials provided with the
 *distribution.
 *
 * 3. The end-user documentation included with the redistribution, if
 *any, must include the following acknowlegement:
 *   This product includes software developed by the
 *Apache Software Foundation (http://www.apache.org/).
 *Alternately, this acknowlegement may appear in the software itself,
 *if and wherever such third-party acknowlegements normally appear.
 *
 * 4. The names The Jakarta Project, Tomcat, and Apache Software
 *Foundation must not be used to endorse or promote products derived
 *from this software without prior written permission. For written
 *permission, please contact [EMAIL PROTECTED]
 *
 * 5. Products derived from this software may not be called Apache
 *nor may Apache appear in their names without prior written
 *permission of the Apache Group.
 *
 * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
 * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
 * ITS

[Patch] Edit field maxlength in admin app's login.jsp

2003-08-27 Thread Jeff Tulley
The admin application needlessly sets the maximum size of the username
and password fields to 16 characters.  It is VERY easy to run into a
problem with some Realm types (like JNDI, if you are using
fully-qualified LDAP names).  I know a password of 16 characters is a
bit pathological, but the limit is arbitrary and needless.

I have attached a simple patch to this to just get rid of the
maximums.

I have seen two or three emails complaining about this and ran into
this myself today.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com
RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/admin/login.jsp,v
retrieving revision 1.7
diff -u -r1.7 login.jsp
--- login.jsp   15 Jan 2003 22:25:17 -  1.7
+++ login.jsp   27 Aug 2003 21:08:24 -
@@ -51,7 +51,7 @@
 font color=#FFlabel for=usernamebean:message 
key=prompt.username//label/font
   /th
   td align=left
-input type=text name=j_username size=16 maxlength=16 id=username/
+input type=text name=j_username size=16 id=username/
   /td
 /tr
 p
@@ -60,7 +60,7 @@
 font color=#FFlabel for=passwordbean:message 
key=prompt.password//label/font
   /th
   td align=left
-input type=password name=j_password size=16 maxlength=16 
id=password/
+input type=password name=j_password size=16 id=password/
   /td
 /tr
 


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

Re: Resend: Tomcat 4.1.24 JVM 1.4.2 security hole?

2003-08-14 Thread Jeff Tulley
I wouldn't be able to try to duplicate this -- I do not use mod_jk2.  On
my system, with mod_jk it seems the problem is gone with the
workaround.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

 [EMAIL PROTECTED] 8/13/03 5:56:31 AM 
Jeff Tulley wrote:

 Verified on Win XP as well.  Using that flag fixes the problem. 
Thanks
 for making that connection!  

I've still got the problem when using the mod_jk2 connector.

I'm using Tomcat 4.1.27 w/ patch on Windows 2000 SP4, behind an Apache

2.0.47 web server, with the J2SE 1.4.2.
The mod_jk2 binary I'm using comes from Tomcat 4.1.24 (I built it from

source).

I added those keys in thr registry for the Tomcat service, and
restarted it:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Apache Tomcat 
4.1\Parameters]
JVM Option Count=dword:0005
JVM Option Number 3=-Dfile.encoding=ISO-8859-1
JVM Option Number 4=-Dsun.io.useCanonCaches=false

When I access Tomcat directly using port 8080, the option does work,
and 
*.jsp%20 returns a 404.

However, when accessing the same through Apache, I still get the JSP
code:
[13/Aug/2003:13:54:16 +0200] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA GET

/myApp/index.jsp%20 HTTP/1.1 1534

Did I miss something?

TIA,

Laurent


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


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



Re: Resend: Tomcat 4.1.24 JVM 1.4.2 security hole?

2003-08-14 Thread Jeff Tulley
Fixes it on NetWare.  I'll go try WinXP

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

 [EMAIL PROTECTED] 8/12/03 7:02:01 PM 
Oups I've missed the discussion . There is a 1.4.2 bug found by Remy 
(and reported in bugtraq as 4895132. I'm not sure you can access the 
bug). The workaround is to add the following property when starting
Tomcat:

-Dsun.io.useCanonCaches=false

Can you try it and see if that fixe the problem (I don't have a winXX)?


-- Jeanfrancois


Jeff Tulley wrote:

The user list has been busy lately discussing a possible security
hole,
but only 1/3 of the people in the thread could see the problem.  I
finally got to where I could see it using Tomcat 4.1.24 and JVM
1.4.2,
but NOT with JVM 1.4.1.

The vulnerability is that if you stick a %20 on the end of a .jsp
url, you get the source.

I forgot to mention the platforms where this has been seen.  I have
seen this with Sun's JVM 1.4.2 on Windows XP, and now I just verified
that it also exists on NetWare's JVM 1.4.2 (built on Sun's source
code
base, so not surprising)  It might exist on other 1.4.2
implementations,
but I am not sure. 

I also just verified this on Tomcat 4.1.18 and 4.1.26 as well.

For some reason I see it better with the example jsp's -
/examples/jsp/num/numbguess.jsp%20 for instance.  But, you can tell
the
problem is going to be there if, when you add the %20 to the .jsp
name, you don't get a 404.  This is all going directly to port 8080,
so
no native connector is involved.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com 

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


  



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


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



Re: Fwd: Re: Tomcat and LDAP Issues

2003-08-14 Thread Jeff Tulley
Tim,
I've attached the diff file for the defect referenced by Jon on the
user list.
I was able to (fortunately) duplicate this going against eDirectory on
NetWare; this one fix seems to solve bug #19864, and bug #11678 as well
(JNDIRealm re-prompting for a password).  Actually, the new code was
already trying to resolve that defect by doing a retry but had that one
NullPointerException throwing a wrench in the works.

My only fear in making this change is if THIS method will also work
among different providers and Directories.  My understanding is that
toString() SHOULD contain at least the same thing as toMessage() and
more in the case of providers that use toMessage().  That and changing
to looking for closed should get both of the types of messages we are
aware of (Socket closed and Connection closed).

I'll look into the other 7.  I've already emailed some of the people
who were discussing them, soliciting more input so I can reproduce them.
 It would be good to get some of those fixed; I did sense some
frustration on the users part in some of the bug reports.  I've
personally seen at least one of them, so I'll start there.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

 Tim Funk [EMAIL PROTECTED] 8/2/03 8:08:59 AM 
Jeff,

I see nine bugs out there for JNDIRealm for tomat 4 and 5, included is
the 
one mentioned below in the previous email.
http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Tomcat+4product=Tomcat+5short_desc=jndirealmshort_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitorder=Reuse+same+sort+as+last+time

I have used JNDIRealm in the past but stopped using it in favor of
other 
solutions for unrelated reasons.

Can you do me a favor?  If you are able, can you update the bugs above
and 
send me a patch for the stuff below (and any applicable bugs above) and
I'll 
try to get 'em in next week.

-Tim

Jeff Tulley wrote:
 Something from the user list of note for development.
 
 The current method does something like this when handling a
 communication exception at authenticate time:
 / If not a Socket closed. error then rethrow.
 if (e.getMessage().indexOf(Socket closed)  0) 
 
 
 throw(e);
 
 This seems to have two problems  1) e.getMessage() is sometimes null
 with some LDAP providers.  2) some LDAP providers set the exception
to
 actually be connection closed (retrieved by e.toString())
 
 Just forwarding this on for the user, since this code currently has
 some problems that ought to be fixed.  (I have a vested interest
being a
 heavy user of JNDIRealm).
 
 For a stopgap measure, one could do the following I guess:
 if (e.toString().indexOf(closed)  0)
 throw(e);
 Though as the bug report points out there may be yet other error
 messages given by other LDAP providers, and I don't know if closed
is
 too general to check on or not.
 
 Jeff Tulley  ([EMAIL PROTECTED])
 (801)861-5322
 Novell, Inc., The Leading Provider of Net Business Solutions
 http://www.novell.com 
 
 
[EMAIL PROTECTED] 8/1/03 2:00:46 PM 
 
 Well, I understand this is now a bug:
 
 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19864 
 
 Was this fixed in the 4.1.27 version? Can't seem to determine if it
was
  
 based on the README in the download.
 
 Jon
 
 On Friday, August 1, 2003, at 12:07  PM, Jon Wynacht wrote:
 
 
Hi,

I have Tomcat 4.1.24 installed on a server that hosts a web  
application. I have set up the container to do authentication via
 
 LDAP  
 
and it works for a bit then just stops working. The only way to get 
 
 
things working again is to restart Tomcat.

I've included the error message below and am wondering if anybody on

 
 
this list has had a similar experience? If so, how did you solve it?

Thanks in advance,

Jon

2003-08-01 10:37:29 JNDIRealm[Standalone]: lookupUser(jwynacht)
2003-08-01 10:37:29 JNDIRealm[Standalone]:   dn=uid=jwynacht,  
ou=active, ou=employees, ou=people, o=cisco.com
2003-08-01 10:37:29 JNDIRealm[Standalone]:   validating credentials
 
 by  
 
binding as the user
2003-08-01 10:37:29 JNDIRealm[Standalone]:   binding as
uid=jwynacht,
 
  
 
ou=active, ou=employees, ou=people, o=cisco.com
2003-08-01 10:37:29 CoyoteAdapter An exception or error occurred in 
 
 
the container during the request processing
java.lang.NullPointerException
  at  
org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:793)
  at  

 

org.apache.catalina.authenticator.BasicAuthenticator.authenticate(Basic
 
 
Authenticator.java:161

Tomcat 4.1.24 JVM 1.4.2 security hole?

2003-08-14 Thread Jeff Tulley
The user list has been busy lately discussing a possible security hole,
but only 1/3 of the people in the thread could see the problem.  I
finally got to where I could see it using Tomcat 4.1.24 and JVM 1.4.2,
but NOT with JVM 1.4.1.  

The vulnerability is that if you stick a %20 on the end of a .jsp
url, you get the source.

I have not tried this with Tomcat versions later than 4.1.24 once I
actually saw the problem. 

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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



Resend: Tomcat 4.1.24 JVM 1.4.2 security hole?

2003-08-14 Thread Jeff Tulley
The user list has been busy lately discussing a possible security hole,
but only 1/3 of the people in the thread could see the problem.  I
finally got to where I could see it using Tomcat 4.1.24 and JVM 1.4.2,
but NOT with JVM 1.4.1.

The vulnerability is that if you stick a %20 on the end of a .jsp
url, you get the source.

I forgot to mention the platforms where this has been seen.  I have
seen this with Sun's JVM 1.4.2 on Windows XP, and now I just verified
that it also exists on NetWare's JVM 1.4.2 (built on Sun's source code
base, so not surprising)  It might exist on other 1.4.2 implementations,
but I am not sure. 

I also just verified this on Tomcat 4.1.18 and 4.1.26 as well.

For some reason I see it better with the example jsp's -
/examples/jsp/num/numbguess.jsp%20 for instance.  But, you can tell the
problem is going to be there if, when you add the %20 to the .jsp
name, you don't get a 404.  This is all going directly to port 8080, so
no native connector is involved.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com 

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



Re: Resend: Tomcat 4.1.24 JVM 1.4.2 security hole?

2003-08-14 Thread Jeff Tulley
Verified on Win XP as well.  Using that flag fixes the problem.  Thanks
for making that connection!  

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

 [EMAIL PROTECTED] 8/12/03 7:02:01 PM 
Oups I've missed the discussion . There is a 1.4.2 bug found by Remy 
(and reported in bugtraq as 4895132. I'm not sure you can access the 
bug). The workaround is to add the following property when starting
Tomcat:

-Dsun.io.useCanonCaches=false

Can you try it and see if that fixe the problem (I don't have a winXX)?


-- Jeanfrancois


Jeff Tulley wrote:

The user list has been busy lately discussing a possible security
hole,
but only 1/3 of the people in the thread could see the problem.  I
finally got to where I could see it using Tomcat 4.1.24 and JVM
1.4.2,
but NOT with JVM 1.4.1.

The vulnerability is that if you stick a %20 on the end of a .jsp
url, you get the source.

I forgot to mention the platforms where this has been seen.  I have
seen this with Sun's JVM 1.4.2 on Windows XP, and now I just verified
that it also exists on NetWare's JVM 1.4.2 (built on Sun's source
code
base, so not surprising)  It might exist on other 1.4.2
implementations,
but I am not sure. 

I also just verified this on Tomcat 4.1.18 and 4.1.26 as well.

For some reason I see it better with the example jsp's -
/examples/jsp/num/numbguess.jsp%20 for instance.  But, you can tell
the
problem is going to be there if, when you add the %20 to the .jsp
name, you don't get a 404.  This is all going directly to port 8080,
so
no native connector is involved.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com 

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


  



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


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



Re: Fwd: Re: Tomcat and LDAP Issues

2003-08-11 Thread Jeff Tulley
I just tested it, and the fix seems to work well.  At first I thought
that your null check would actually cause a problem, in case the
exception is something besides a connection(or socket) closed, and the
provider chose to not to set the message on the exception.  But, I think
the fact that the retry is wrapped in yet another try catch block means
that life will probably go on.  I've been doing all sorts of fun weird
things to my LDAP server to try to get other types of exceptions thrown,
and it behaves as I would expect with your fix.

With defect 20518 -- It does seem innocent, though if the primary LDAP
server is down for an extended period of time, you would constantly be
trying it first, then the alternate.  But, I'm guessing the performance
hit is not huge and the fix seems correct beyond that.  (IE, to assume
the primary is forever gone is a bad idea and it is better to take the
potential performance hit).

You closed the bug regarding the userSubtree not working I see.  I'm
not sure but that there are still issues there, and I'm still
investigating.  I can get it to work if I add the [Public] object as a
trustee to any subcontext that I want searched, but this is by no means
a standard thing to do since it opens up your user containers to
potential security exploits.  Most of the exploits involve social
engineering; with public access to the names of the users in the
container, you can impersonate a user whose name you see and call up and
ask a help desk technician to change their password for you.  What I'm
not sure about is if there is some other acceptable way to grant browse
rights to some other object and then have Tomcat go in as that object. 
If so, then that would need to be documented if it is not already.  If
that is not possible, then the userSubtree feature is fairly useless
since most directory administrators would not take the security risk to
make it work.  Also, there are other bugs with this feature like the
fact that the first level is not searched for users, ONLY the sublevels
are.

I emailed marek about the CLIENT-CERT problem, still no response.  I'm
going to look into it and see what the gist of Mario's objections were,
and if the patch is good.  
I know nothing about the iPlanet issue (except for what is in the bug
report), so that will be great if you have a fix...

Thanks Tim for working on these issues.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

 [EMAIL PROTECTED] 8/5/03 11:42:43 AM 
I got eager and saw you bug update yesterday and applied a patch to 4.1
last 
night. Here's a link to the PATCH email:

http://marc.theaimsgroup.com/?l=tomcat-devm=106004487327965w=2 

The commit also does a null pointer check on the getMessage() to fix a

related bug and also avoids doing the toString().

As for bug 20518 - did this seem right? It seemed like an innocent fix.
(But 
they are the ones that seem to cause the most trouble)

IIRC, the only two bugs left I know of is:
1) The CLIENT-CERT one which I wish not to do but rather leave to
someone to 
Extend JNDIRealm. (But if someone else wants to commit it - I won't
care)
2) Enhancement request for IPlanet since in a non-user binding the SHA1
check 
isn't compatible with the way tomcat generates a hash. I have a patch
on my 
own from another project that might fix this. (If I can find the code)

AFAIK - All other JNDIRealm bugs are fixed or enhancements. If you can
test 
from 4.1 and give me the OK - I can port the patch to 5. (I know I
committed 
in the wrong order :( ,  but did it on the hope that the patch had a
better 
chance of being tested)

-Tim



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


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



Re: Fwd: Re: Tomcat and LDAP Issues

2003-08-05 Thread Jeff Tulley
 From another user's comment, it looked like it was invalid and there
didn't 
seem to be a rebuttal. But I had many windows open at the same time
and may 
have gotten it confused with something else.

Yeah, somebody was nitpicking the snippet of server.xml that he had
there, where the thing they were nitpicking was really just a typo in
the bug report.  I have indeed seen this issue and for a while was
frustrated with the userSubtree functionality.  Like I say, it is a
rights issue, and it may have to still be dealt with in some way or
another.  It might result in a fundamentally different way of doing the
search in JNDIRealm than the current code.  I don't know, I'll
investigate when I get some time.

 I know nothing about the iPlanet issue (except for what is in the
bug
 report), so that will be great if you have a fix...
When pulling the password back - it is SHA1 encrypted. When tomcats
digests 
the browser provided password - it returns the SHA1 in an incompatible

manner. (HEX vs BASE64 IIRC) So the solution here will probably be to
add a 
flag on how to perform SHA1 password checks. (Or similar)

Oh, I was confusing this with bug #11210, also dealing with Netscape. 


Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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



Fwd: Re: Tomcat and LDAP Issues

2003-08-01 Thread Jeff Tulley
Something from the user list of note for development.

The current method does something like this when handling a
communication exception at authenticate time:
/ If not a Socket closed. error then rethrow.
if (e.getMessage().indexOf(Socket closed)  0)   

throw(e);

This seems to have two problems  1) e.getMessage() is sometimes null
with some LDAP providers.  2) some LDAP providers set the exception to
actually be connection closed (retrieved by e.toString())

Just forwarding this on for the user, since this code currently has
some problems that ought to be fixed.  (I have a vested interest being a
heavy user of JNDIRealm).

For a stopgap measure, one could do the following I guess:
if (e.toString().indexOf(closed)  0)
throw(e);
Though as the bug report points out there may be yet other error
messages given by other LDAP providers, and I don't know if closed is
too general to check on or not.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

 [EMAIL PROTECTED] 8/1/03 2:00:46 PM 
Well, I understand this is now a bug:

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

Was this fixed in the 4.1.27 version? Can't seem to determine if it was
 
based on the README in the download.

Jon

On Friday, August 1, 2003, at 12:07  PM, Jon Wynacht wrote:

 Hi,

 I have Tomcat 4.1.24 installed on a server that hosts a web  
 application. I have set up the container to do authentication via
LDAP  
 and it works for a bit then just stops working. The only way to get 

 things working again is to restart Tomcat.

 I've included the error message below and am wondering if anybody on 

 this list has had a similar experience? If so, how did you solve it?

 Thanks in advance,

 Jon

 2003-08-01 10:37:29 JNDIRealm[Standalone]: lookupUser(jwynacht)
 2003-08-01 10:37:29 JNDIRealm[Standalone]:   dn=uid=jwynacht,  
 ou=active, ou=employees, ou=people, o=cisco.com
 2003-08-01 10:37:29 JNDIRealm[Standalone]:   validating credentials
by  
 binding as the user
 2003-08-01 10:37:29 JNDIRealm[Standalone]:   binding as uid=jwynacht,
 
 ou=active, ou=employees, ou=people, o=cisco.com
 2003-08-01 10:37:29 CoyoteAdapter An exception or error occurred in 

 the container during the request processing
 java.lang.NullPointerException
   at  
 org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:793)
   at  

org.apache.catalina.authenticator.BasicAuthenticator.authenticate(Basic

 Authenticator.java:161)
   at  

org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authenticato

 rBase.java:526)
   at  

org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.

 invokeNext(StandardPipeline.java:641)
   at  

org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:

 480)
   at  

org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
   at  

org.apache.catalina.core.StandardContext.invoke(StandardContext.java:24

 15)
   at  

org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.jav

 a:180)
   at  

org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.

 invokeNext(StandardPipeline.java:643)
   at  

org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherV

 alve.java:171)
   at  

org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.

 invokeNext(StandardPipeline.java:641)
   at  

org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.jav

 a:172)
   at  

org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.

 invokeNext(StandardPipeline.java:641)
   at  

org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:

 480)
   at  

org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
   at  

org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve

 .java:174)
   at  

org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.

 invokeNext(StandardPipeline.java:643)
   at  

org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:

 480)
   at  

org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
   at  

org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
   at  

org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:5

 94)
   at  

org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process

 Connection(Http11Protocol.java:392)
   at  

org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:5

 65)
   at  

org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPoo

 l.java:619)
   at java.lang.Thread.run(Thread.java:536)


-
To unsubscribe, e-mail: [EMAIL PROTECTED

Re: [4.1.27] Release [5.0.6] New build

2003-07-31 Thread Jeff Tulley
Remy,
Before you release, can you get that minor typo fix in
/webapps/admin/WEB-INF/struts-config.xml that I sent a patch for a week
or so ago?

It is causing major problems on NetWare, since the JVM is enforcing
case sensitivity of the path, and for some reason the new struts used by
Tomcat 4.1.26 exposed this long-existing error.

Very simple fix, no risk, just getting the case of the package name
part, defaultcontext, correct.
Patch attached.

Thanks,

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

 [EMAIL PROTECTED] 7/31/03 3:51:24 AM 
I'll tag and release Tomcat 4.1.27 Stable today, which includes fixes 
for minor security bugs over 4.1.26.
Please -1 quickly if you don't want that release to happen without more

review.

I'll also tag and release a new 5.0.6 build, ask for a vote on the 
Tomcat 5.0.x release plan, and ask for a stability vote on the build
(to 
get in the mood).

Lots of stuff :)

Remy



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

RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/admin/WEB-INF/struts-config.xml,v
retrieving revision 1.52
diff -u -r1.52 struts-config.xml
--- struts-config.xml   9 Apr 2003 22:36:33 -   1.52
+++ struts-config.xml   18 Jul 2003 17:40:07 -
@@ -85,7 +85,7 @@
 type=org.apache.webapp.admin.defaultcontext.DefaultContextForm/
 
 form-bean  name=defaultContextsForm
-
type=org.apache.webapp.admin.defaultContext.DefaultContextsForm/
+
type=org.apache.webapp.admin.defaultcontext.DefaultContextsForm/
 
 !-- = Connector Module = --
 


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

[Patch] Exceptions being hidden in admin application

2003-07-23 Thread Jeff Tulley
Under User Definition in the /admin application, the Users,
Groups, and Roles functionality does not work with the JNDIRealm. 
While troubleshooting this, I found that the real cause of the problem
was being hidden by a programming error -- an error response was being
sent, but the code did not immediately return, but rather fell through
to the forwarding code, resulting in an error like, unable to forward
after response has been committed.

Patches for this problem for these three items are attached.  I'll keep
digging on the actual problem with JNDIRealm and the manager, now that I
have a real error message.

Thanks,

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com
Index: ListRolesAction.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/users/ListRolesAction.java,v
retrieving revision 1.3
diff -u -r1.3 ListRolesAction.java
--- ListRolesAction.java10 Feb 2002 08:06:20 -  1.3
+++ ListRolesAction.java23 Jul 2003 20:24:10 -
@@ -164,6 +164,7 @@
 (HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
  resources.getMessage
  (locale, users.error.attribute.get, roles));
+return null;
 }
 
 // Stash the results in request scope

Index: ListUsersAction.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/users/ListUsersAction.java,v
retrieving revision 1.3
diff -u -r1.3 ListUsersAction.java
--- ListUsersAction.java10 Feb 2002 08:06:20 -  1.3
+++ ListUsersAction.java23 Jul 2003 20:25:13 -
@@ -164,6 +164,7 @@
 (HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
  resources.getMessage
  (locale, users.error.attribute.get, users));
+return null;
 }
 
 // Stash the results in request scope


Index: ListGroupsAction.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/users/ListGroupsAction.java,v
retrieving revision 1.3
diff -u -r1.3 ListGroupsAction.java
--- ListGroupsAction.java   10 Feb 2002 08:06:20 -  1.3
+++ ListGroupsAction.java   23 Jul 2003 20:25:31 -
@@ -164,6 +164,7 @@
 (HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
  resources.getMessage
  (locale, users.error.attribute.get, groups));
+return null;
 }
 
 // Stash the results in request scope


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

Minor typo stopping 4.1.26 from running on NetWare.

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

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

Thanks,

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


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

Re: Renaming /admin and /manager contexts (from user list)

2003-06-17 Thread Jeff Tulley
Sounds reasonable to me.
Maybe all that's needed is updating the paths in the context
descriptors 
for both webapps.

Cool.  Yeah, it is a very very simple fix.  Diff files attached, if
they are even of any help at all.

I'll let Yoav do the documentation then, since he volunteered.  (Thanks
Yoav!)

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com
Index: manager.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/manager/manager.xml,v
retrieving revision 1.2
diff -u -r1.2 manager.xml
--- manager.xml 8 Apr 2002 17:46:08 -   1.2
+++ manager.xml 17 Jun 2003 15:10:09 -
@@ -7,7 +7,7 @@
 --
 
 
-Context path=/manager docBase=../server/webapps/manager
+Context path=/tomcat/manager docBase=../server/webapps/manager
 debug=0 privileged=true
 
   !-- Link to the user database we will get roles from --

Index: admin.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/admin/admin.xml,v
retrieving revision 1.3
diff -u -r1.3 admin.xml
--- admin.xml   23 Jul 2002 12:12:15 -  1.3
+++ admin.xml   17 Jun 2003 15:11:32 -
@@ -7,7 +7,7 @@
 --
 
 
-Context path=/admin docBase=../server/webapps/admin
+Context path=/tomcat/admin docBase=../server/webapps/admin
 debug=0 privileged=true
 
   !-- Uncomment this Valve to limit access to the Admin app to localhost


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

Renaming /admin and /manager contexts (from user list)

2003-06-16 Thread Jeff Tulley
This is a conversation we are having on the users list.  I propose that
the contexts, /admin, and /manager be renamed to something else, (I
suggest /tomcat/admin, and /tomcat/manager respectively).  Doing so
avoids Tomcat being yet another app, which wants to own
http://(url)/admin

This is very easily modifiable in Tomcat (one string in admin.xml and
manager.xml), and I think it should be done.

Original posts:
(my email)
Tomcat ought to do the same, IMO.  You never know who else wants to own
http://url/admin;, and you do not always have the luxury of renaming
it.

/tomcat/admin and /tomcat/manager are more specific, and can easily be
changed on Tomcat's side.  

Maybe something to bring up on the developer list.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

 [EMAIL PROTECTED] 6/16/03 1:29:52 PM 
That's a good point. There I go again. Always thinking of the Quick
fix!

  - Original Message - 
  From: Phillip Qin 
  To: 'Tomcat Users List' 
  Sent: Monday, June 16, 2003 9:26 PM
  Subject: RE: Can't get to /admin dir of our webapp


  I strongly disagree with all of you.

  Suppose you are upgrading from 4.1.18 to 4.1.24. The unpacked tar
will
  override all of the contents re admin and install its admin app.

  Why don't you guys think of renaming your own admin app to something
like
  myappadmin?

  -Original Message-
  From: Jeff Tulley [mailto:[EMAIL PROTECTED] 
  Sent: June 16, 2003 3:20 PM
  To: [EMAIL PROTECTED] 
  Subject: RE: Can't get to /admin dir of our webapp

  I've moved ours to be /tomcat/admin, so the we still have the admin
  functionality, but in a less generic name.  It is just a simple
change
  in webapps/admin.xml

  Jeff Tulley  ([EMAIL PROTECTED])
  (801)861-5322
  Novell, Inc., The Leading Provider of Net Business Solutions
  http://www.novell.com 



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



Re: [Patch] Coyote losing parameters across form login (wasRe: Connectorissues)

2003-04-04 Thread Jeff Tulley
Which?  All of them?  I had 3 attachments with the extension .patch (I
could rename to .txt, though .patch has worked in the past I thought). 
And, 1 zip file that I renamed to test.zip.txt

Please let me know which if any were visible, and the best way to send
a zip file.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

 [EMAIL PROTECTED] 4/4/03 9:27:05 AM 
Jeff Tulley wrote:
 here is the code, please review
 3 of them are patches for existing source code.  test.zip (.txt, I
 couldn't remember if the mailing list strips off zip files) is a new
 junit TestCase to test my stuff in Parameters.java.  I propose that
be
 put in j-t-c/util/test, unless there is a better place.  I don't know
if
 there is a better way to submit a new directory via CVS since I
cannot
 diff -u it.
 
 CoyoteRequest.java and Request.java fixes are very straightforward,
 just doing the same sort of thing that is done in the rest of the
code. 
 Parameters.java is where I took an already existing (private)
method,
 made a copy of it, renamed and made the copy public, and then adapted
it
 to work with multi-valued parameters.
 
 This seems to do the job correctly.

The attachement doesn't work for me.

Remy


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


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



Re: [Patch] Coyote losing parameters across form login (wasRe: Connectorissues)

2003-04-04 Thread Jeff Tulley
One more try, all files as .txt  What is the best way to send a .zip
file?
Actually, I've attached the file that was in the zip as
AddParametersTest.java  It should go in
j-t-c/util/test/org/apache/tomcat/util/http   Nothing from /test down
currently exists in the util dir.

It looks like my previous submissions on this list also did not show
up.  I should have checked more carefully.

I've also attached my patch for the minor type in SoTask.java

Sorry for the mess.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

 [EMAIL PROTECTED] 4/4/03 12:17:48 PM 
Jeff Tulley wrote:
 Which?  All of them?  I had 3 attachments with the extension .patch
(I
 could rename to .txt, though .patch has worked in the past I
thought). 
 And, 1 zip file that I renamed to test.zip.txt
 
 Please let me know which if any were visible, and the best way to
send
 a zip file.

The .zip is not valid, and the 3 other attachements are not there.

Remy


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

Index: Request.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java,v
retrieving revision 1.15
diff -u -r1.15 Request.java
--- Request.java19 Sep 2002 06:39:43 -  1.15
+++ Request.java3 Apr 2003 17:28:56 -
@@ -385,6 +385,9 @@
 public Parameters getParameters() {
return parameters;
 }
+   public void addParameter(String name, String[] values) {
+  parameters.addParameterValues(name, values);
+   }
 
 
 //  Other attributes 

Index: Parameters.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/Parameters.java,v
retrieving revision 1.8
diff -u -r1.8 Parameters.java
--- Parameters.java 29 Jun 2002 02:15:02 -  1.8
+++ Parameters.java 3 Apr 2003 17:30:39 -
@@ -336,6 +336,26 @@
paramHashStringArray.put(key, values);
 }
 
+   public void addParameterValues( String key, String[] newValues) {
+  if( key==null ) return;
+  String values[];
+  if (paramHashStringArray.containsKey(key)) {
+ String oldValues[] = (String[])paramHashStringArray.
+ get(key);
+ values = new String[oldValues.length + newValues.length];
+ for (int i = 0; i  oldValues.length; i++) {
+values[i] = oldValues[i];
+ }
+ for (int i = 0; i  newValues.length; i++) {
+values[i+ oldValues.length] = newValues[i];
+ }
+  } else {
+ values = newValues;
+  }
+  
+  paramHashStringArray.put(key, values);
+   }
+
 public void setURLDecoder( UDecoder u ) {
urlDec=u;
 }


Index: CoyoteRequest.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteRequest.java,v
retrieving revision 1.28
diff -u -r1.28 CoyoteRequest.java
--- CoyoteRequest.java  24 Nov 2002 11:56:15 -  1.28
+++ CoyoteRequest.java  3 Apr 2003 17:28:09 -
@@ -1262,7 +1262,7 @@
  * @param values Corresponding values for this request parameter
  */
 public void addParameter(String name, String values[]) {
-// Not used
+coyoteRequest.addParameter(name, values);
 }
 

Index: SoTask.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-connectors/jk/jkant/java/org/apache/jk/ant/SoTask.java,v
retrieving revision 1.23
diff -u -r1.23 SoTask.java
--- SoTask.java 9 Jun 2002 00:10:02 -   1.23
+++ SoTask.java 3 Apr 2003 00:19:44 -
@@ -364,7 +364,7 @@
  * (XXX including extension - this should be automatically added )
  */
 public void setModule(String modName) {
-this.module = module;
+this.module = modName;
 }
 
 // XXX Add specific code for Netware, Windows and platforms where libtool



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

Re: [Patch] Coyote losing parameters across form login (wasRe:Connectorissues)

2003-04-04 Thread Jeff Tulley
One more, .java is stripped as well, it appears.
This is the AddParametersTest.java mentioned below.  It is now
AddParametersTest.txt

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

 [EMAIL PROTECTED] 4/4/03 12:33:26 PM 
One more try, all files as .txt  What is the best way to send a .zip
file?
Actually, I've attached the file that was in the zip as
AddParametersTest.java  It should go in
j-t-c/util/test/org/apache/tomcat/util/http   Nothing from /test down
currently exists in the util dir.

It looks like my previous submissions on this list also did not show
up.  I should have checked more carefully.

I've also attached my patch for the minor type in SoTask.java

Sorry for the mess.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com 

 [EMAIL PROTECTED] 4/4/03 12:17:48 PM 
Jeff Tulley wrote:
 Which?  All of them?  I had 3 attachments with the extension
.patch
(I
 could rename to .txt, though .patch has worked in the past I
thought). 
 And, 1 zip file that I renamed to test.zip.txt
 
 Please let me know which if any were visible, and the best way to
send
 a zip file.

The .zip is not valid, and the 3 other attachements are not there.

Remy


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

/*
 * 
 *
 * The Apache Software License, Version 1.1
 *
 * Copyright (c) 2003 The Apache Software Foundation.  All rights 
 * reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer. 
 *
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in
 *the documentation and/or other materials provided with the
 *distribution.
 *
 * 3. The end-user documentation included with the redistribution, if
 *any, must include the following acknowlegement:  
 *   This product includes software developed by the 
 *Apache Software Foundation (http://www.apache.org/).
 *Alternately, this acknowlegement may appear in the software itself,
 *if and wherever such third-party acknowlegements normally appear.
 *
 * 4. The names The Jakarta Project, Tomcat, and Apache Software
 *Foundation must not be used to endorse or promote products derived
 *from this software without prior written permission. For written 
 *permission, please contact [EMAIL PROTECTED]
 *
 * 5. Products derived from this software may not be called Apache
 *nor may Apache appear in their names without prior written
 *permission of the Apache Group.
 *
 * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
 * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
 * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
 * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
 * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 * 
 *
 * This software consists of voluntary contributions made by many
 * individuals on behalf of the Apache Software Foundation.  For more
 * information on the Apache Software Foundation, please see
 * http://www.apache.org/.
 *
 * [Additional notices, if required by prior licensing conditions]
 *
 */ 

package org.apache.tomcat.util.http;

import java.util.Enumeration;

import junit.framework.Assert;
import junit.framework.TestCase;

public class AddParametersTest extends TestCase
{

   /**
* Constructor for AddParametersTest.
* @param arg0
*/
   public AddParametersTest(String arg0)
   {
  super(arg0);
   }

   public static void main(String[] args)
   {
  junit.textui.TestRunner.run(AddParametersTest.class);
   }
   
   public void testAddParameterValuesNullKey()
   {
  Parameters params = new Parameters();
  Enumeration preEnum = params.getParameterNames();
  while (preEnum.hasMoreElements())
  {
 Assert.fail(Should have been empty);
  }
  
  params.addParameterValues(null, new String[] {Some Value});
  Enumeration

Re: [Patch] Coyote losing parameters across form login(was Re: Connectorissues)

2003-04-04 Thread Jeff Tulley
I wondered about that.  But, it seemed that CoyoteRequest used  the same
method throughout the code - for instance on getParameter(String name),
it already does a call to
coyoteRequest.getParameters().getParameter(name), so I figured I should
do the same.   the variable coyoteRequest here is a o.a.coyote.Request
 This same method is also used with getProtocol, get and set ServerName,
ServerPort, and with getAttributes.  

How then do you propose changing this?

Other methods in CoyoteRequest keep such things local, but that is
difficult with the parameters, since they would presumably exist in the
original passed-in Request object.  

Oh, I see your other email.  Yeah, you are seeing the same thing as me.
 There was a bit of a code smell rewriting that private method in
Parameters.java, but it appeared to be the only choice with the way the
current code is written.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

 [EMAIL PROTECTED] 4/4/03 12:42:41 PM 
Jeff Tulley wrote:
 One more try, all files as .txt  What is the best way to send a .zip
 file?
 Actually, I've attached the file that was in the zip as
 AddParametersTest.java  It should go in
 j-t-c/util/test/org/apache/tomcat/util/http   Nothing from /test
down
 currently exists in the util dir.
 
 It looks like my previous submissions on this list also did not show
 up.  I should have checked more carefully.
 
 I've also attached my patch for the minor type in SoTask.java
 
 Sorry for the mess.

Ok, well, I get a chance to review the patch. I don't like it, as it 
forces some hacks needed for FORM auth (which, FYI, I've always 
considered to be a bad hack) down the path to the cleaner Coyote
objects.
I think the patch will need some rework to avoid polluting the API (ie,

the dirty code needs to stay in the facade - aka, CoyoteRequest).

Remy


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


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



Re: Connector issues

2003-04-03 Thread Jeff Tulley
I think I've got a fix for the connector thing, gotta still try it out
to be sure.  I just thought that the mbeans-descriptors fix is low
hanging fruit.  IE, with just a simple little fix, every time somebody
is forced to go back to the old connector for one reason or another,
they won't immediately come back to the list with the complaint of I'm
getting the following exception.  

But if an upgrade to commons-modeler would also fix the problem without
changing deprecated code, I'm all for doing that instead.

Let me go check out my code changes to CoyoteRequest, see how they
work...

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

 [EMAIL PROTECTED] 4/2/03 8:57:09 PM 
Sorry for the delay.

IMO the right solution is to fix #10229 for coyote.

There are a lot of problems in the old connectors - even if mod_jk2
is not yet as stable as mod_jk1, the java side and coyote are far 
better than the old impl.

I'm +0 on fixing the MBean exception - AFAIK upgrading commons-modeler
should fix most of the problems with undeclared mbeans. The real
problem
is that the Ajp13Connector has a lot of problems and it's no longer
supported - all work is on the coyote connector, I don't know anyone
testing or supporting Ajp13.

Costin


Jeff Tulley wrote:

 There are some real problems with the Coyote Connectors right now.
 The main problem biting me (and a few others recently) is bugzilla
bug
 # 10229 - form parameters not being preserved across a login
 redirection.
 The answer given on the user list (by me also) is typically, Use an
 non-Coyote connector.  Unfortunately that is not a good answer.
 If they move back to the deprecated AJP13Connector, they will
 experience MBean exceptions that, among other things, make the
Tomcat
 shutdown not function correctly.
 Beyond that they are stuck with not using a webserver plugin and
 instead going directly to an HTTP connector (non-Coyote).
 
 I would propose two things:
 1) Fix the MBean exception in the Ajp13Connector.  I can provide a
 patch for this, it is very simple.  Even though this is deprecated,
the
 reality is that people might need to use it due to bugs and/or
 unimplemented features in the Coyote connectors.  It may be their
only
 choice, and if we can make it work easily, why not?
 2) Fix this form authentication problem in the Coyote connector.  I
 will look into this and see if it is something that I can do and
submit
 a patch for.
 
 I actually have similar issues with the native side connector story
but
 that is for another day.
 
 Anybody know off hand what needs to happen for item #2 above?
 
 Jeff Tulley  ([EMAIL PROTECTED])
 (801)861-5322
 Novell, Inc., The Leading Provider of Net Business Solutions
 http://www.novell.com 



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


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



[Patch] Coyote losing parameters across form login (was Re:Connector issues)

2003-04-03 Thread Jeff Tulley
here is the code, please review
3 of them are patches for existing source code.  test.zip (.txt, I
couldn't remember if the mailing list strips off zip files) is a new
junit TestCase to test my stuff in Parameters.java.  I propose that be
put in j-t-c/util/test, unless there is a better place.  I don't know if
there is a better way to submit a new directory via CVS since I cannot
diff -u it.

CoyoteRequest.java and Request.java fixes are very straightforward,
just doing the same sort of thing that is done in the rest of the code. 
Parameters.java is where I took an already existing (private) method,
made a copy of it, renamed and made the copy public, and then adapted it
to work with multi-valued parameters.

This seems to do the job correctly.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

 [EMAIL PROTECTED] 4/2/03 8:57:09 PM 
Sorry for the delay.

IMO the right solution is to fix #10229 for coyote.

There are a lot of problems in the old connectors - even if mod_jk2
is not yet as stable as mod_jk1, the java side and coyote are far 
better than the old impl.

I'm +0 on fixing the MBean exception - AFAIK upgrading commons-modeler
should fix most of the problems with undeclared mbeans. The real
problem
is that the Ajp13Connector has a lot of problems and it's no longer
supported - all work is on the coyote connector, I don't know anyone
testing or supporting Ajp13.

Costin


Jeff Tulley wrote:

 There are some real problems with the Coyote Connectors right now.
 The main problem biting me (and a few others recently) is bugzilla
bug
 # 10229 - form parameters not being preserved across a login
 redirection.
 The answer given on the user list (by me also) is typically, Use an
 non-Coyote connector.  Unfortunately that is not a good answer.
 If they move back to the deprecated AJP13Connector, they will
 experience MBean exceptions that, among other things, make the
Tomcat
 shutdown not function correctly.
 Beyond that they are stuck with not using a webserver plugin and
 instead going directly to an HTTP connector (non-Coyote).
 
 I would propose two things:
 1) Fix the MBean exception in the Ajp13Connector.  I can provide a
 patch for this, it is very simple.  Even though this is deprecated,
the
 reality is that people might need to use it due to bugs and/or
 unimplemented features in the Coyote connectors.  It may be their
only
 choice, and if we can make it work easily, why not?
 2) Fix this form authentication problem in the Coyote connector.  I
 will look into this and see if it is something that I can do and
submit
 a patch for.
 
 I actually have similar issues with the native side connector story
but
 that is for another day.
 
 Anybody know off hand what needs to happen for item #2 above?
 
 Jeff Tulley  ([EMAIL PROTECTED])
 (801)861-5322
 Novell, Inc., The Leading Provider of Net Business Solutions
 http://www.novell.com 



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

PK
‚.   test/org/PK
‚.test/org/apache/PK
‚.test/org/apache/tomcat/PK
‚.test/org/apache/tomcat/util/PK
%‚.!test/org/apache/tomcat/util/http/PKVTƒ.+ML;ÜÍ7test/org/apache/tomcat/util/http/AddParametersTest.javaíXÛnÛF}è%rÀй´/IS„–(›­Lª$e7d-®¬mxQ¸¤U!È¿÷ìòjYi“ÆAû`6©Ý33gfgÆ|[EMAIL
 PROTECTED],\q²ÖlG-‹
Ë9Mł§’tÆs)[EMAIL PROTECTED]
H›DV“–‘¤1r.y~Å#³Eõy$d‘‹‹R‰K#*%'‘’ÌÊ|ÁõʅHY¾¥e–'Ò (V”åú™•…†I²H,ÅBë5HÙ±æyŠ‚G´Î³+á¥X±¿8€â8ۈô’Y
%$5ŒLxñ¼5c¡¤l٘¶È/e¿
“6»È®ÔVM–FÁ'Í
kàˆPátÚµ›×MƒÖEÌDÂs“Z{žÞ´z{ü4öÀ騄ßÉ$hm`ԑ([”  OÖññÉ°“SÂ
žË.:€Ølúþt™ñÌÔùÅÓè2ßÑ!ÒE\öÁàsÇ 
±lðYº5*^j©·Øâ}šmb~Éþs¢FŸA¨Ø©Ølå%2 N÷ˆ_ñ8[Ћ­†íÉþÍÝ áª(ÖÏ7›Éô13Ë/ÌA`Å 
.{ñ¶ŽÑu;Áì–Øz͙Š†ÖÝZ%
[EMAIL PROTECTED],‘yÂâ¸Áï‚òC””% a ^aïÁh–gðE10°œ%¸‰xSJ;$46u\ªØ [EMAIL PROTECTED] 
T¥ÈU%H«š ¥®M“ÞzÔí´Ž9“êÖ ãù*F¯ºPuœüh*ç¯Y¶Ï$®ÚǸå-5mÄÁº[EMAIL PROTECTED]
YßrCÇrÜÑtvÜcƒŽæ!¹^HSçÔ  !zôٍhOL£x:µýÑ   
–¬#gꄯµæ‰ºÐJ(µhfù¡3šO-Ÿfsæ6Áp-?v‚ÑÔrNí1:ŽãB5Ùg¶RpbM§Z³5³Fx´þN¼¹;¶BÇsá’q€Fžú¬÷ü€ŽlØoMíÊÐ0v|{*O»·(ƒÙÓêª3{äà³á«å¿6eÀ
ìßæ8ˆM[§Ö±Ððc¤Ï‚2šûö©ò4ó£ tÂyhÓ±çØþ™3²ƒ4õÀ–7Ñ 
óÀ6 )´´€›8‚÷£yàh^7´}S,ЉwÒ`«5WFªØ¸Úupèù¯•Š#ƒÎOl¬ûŠr͜¥(
Àà(ì«`|¸ã‡=ŸÉµ§Î±íŽlµë)¤s'°V'PœJõ¹½ó°ÉMXX½öRØÐ1'gBÖøÌѹZFªNV59Á|tR‡A_ˆÛ¬ú·õC¢-é±á*‹KTtjUUºž0´$´JCô`´ÊRuM\ä¾bñrçï¸TUK²ºÊŠTMU¿ÉÒn+žä•ôOû;ÔÏ]
ycEÕ¬Àâz˜ªí¢(E^µÄªHÅz°¼p½mpQï߃†÷ìRÕûËF]¡ûˆ   
–bSóBÉ:Ëúƒ]±jÇN1äڇkÊTæ2GÉÜdù{ӒŠŸÝ¹,Fð_c¬Ë˜Lv¤$x9cêú±TLjÿ‰ŠIjdîßû¨¤P~ÔORórŠq]þ#7aÌæ䫵ZÇðyù¸^:ÔÏڊ‚ÃÉ£æè“+9BgGêzíSmX%Õø´@ŠéÒêÍ[wÀ*Š
x[
͏_¦)ÆѼL‡7½ÑduZIQ­b­±À¹¾à‹K.Ý2ŽåÛáŽöž4?’^RÊ7½õa­
Ÿ^ å¸úŠã•œyɋVÈU-´'¸Y‰˜Ó°–1WLžâúØq5
šƒ­]øT¹d.™ˆ‡ƒÍ8ŽhÅ0c_pLYÛA§âSóÒk³Ø
†)¨0´—m\‚,á¤í

[Proposal] error page handling on authorization failure

2003-04-03 Thread Jeff Tulley
Right now when a resource is secured, after the user enters their
credentials, if the credentials are not authenticated, a user-specified
error page is shown, specified from web.xml.
But, if the authentication happens correctly and the user is not in the
role so the authorization fails, this same error page is NOT displayed,
but rather a 403 error, Access to the requested resource has been
denied.  At that point, the session already has authenticated
credentials, and it is impossible to hit back and try again.  You either
get j_security_check is unavailable, or repeat 403 errors, depending
on what you try to do.  Your only recourse is to close the browser and
start a new session.

proposals:
1) If possible, on authorization failure, dump the authenticated user
credentials, as if we never tried to authenticate
2) Redirect to the same error page when there is an authorization
failure but authentication success.

The spec says this:

SRV.12.5.3 Form Based Authentication
...
When a user attempts to access a protected web resource, the container
checks
the user's authentication. If the user is authenticated and possesses
authority to
access the resource, the requested web resource is activated and a
reference to it is
returned. If the user is not authenticated, all of the following steps
occur:
1. The login form associated with the security constraint is sent to
the client and
the URL path triggering the authentication is stored by the container.
2. The user is asked to fill out the form, including the username and
password
fields.
3. The client posts the form back to the server.
4. The container attempts to authenticate the user using the
information from the
SECURITY
84
form.
5. If authentication fails, the error page is returned using either a
forward or a redirect,
and the status code of the response is set to 401.
6. If authentication succeeds, the authenticated user's principal is
checked to see
if it is in an authorized role for accessing the resource.
7. If the user is authorized, the client is redirected to the resource
using the stored
URL path.
The error page sent to a user that is not authenticated contains
information
about the failure.
...


So, it is ambiguous, and does not specify what to do.  It also does not
forbid it.  Also, this error is hard to deal with as is, so I do not
think that we would be breaking backwards compatibility to suddenly
start handling it.  At least, if we are, it would probably be greeted as
a welcome change, not a bad one.

This really should be dealt with in the spec, preferrably with a
separate page for each type of failure, or at least outright specifying
that the one page should be used for both cases.

What do you all think?  It seems like this should be an easy fix, as
well, though I could be wrong.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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



[proposal] make parameters available to the login form

2003-04-03 Thread Jeff Tulley
One more proposal regarding form-based authentication:
Right now, if you submit a form to a secured page, and have not
authenticated, you are redirected to a login page.  Any form parameters
that you have submitted are not available to the login page.  For a
seamless / single sign on experience, it would be nice if the submitter
could supply j_username and j_password and have the form decide if
it wants to pick up and use that information for immediate
authentication.  Right now the only form of SingleSignon available is
through cookies.  If the calling application has valid credentials, it
should be able to authenticate with the container.

I cannot see what part of the spec that this violates, but I very well
could be missing something.

Also, am I simply missing a better way to do this?  We have an
application where the user has already been authenticated and this same
user is authorized to use Tomcat's manager and admin applications. 
Tomcat is using the same type of realm, so the credentials pass over
directly.  It would be nice to provide seamless operation between all of
these web applications using standard Tomcat.

Is this possible?  We've made the code changes to make all of this
happen as decribed in the first paragraph, but we want to be sure that
this is a good thing to do, and if so, get our changes submitted back to
Tomcat itself.  (not wanting to patch them in every time Tomcat is
re-released at which time we'll bag our current solution for a
filter-based one).

Thanks,

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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



Simple bug found

2003-04-02 Thread Jeff Tulley
Trying to pull jakarta-tomcat-connectors into eclipse 2.1, it found the
following obvious typo in o.a.jk.ant.SoTask.java, line 367:

   /**
 * The name of the target file.
 * (XXX including extension - this should be automatically added )
 */
public void setModule(String modName) {
this.module = module;
}

This should be 

this.module=modName;

right?

cvs diff -u patch file attached.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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

Connector issues

2003-04-01 Thread Jeff Tulley
There are some real problems with the Coyote Connectors right now.
The main problem biting me (and a few others recently) is bugzilla bug
# 10229 - form parameters not being preserved across a login
redirection.
The answer given on the user list (by me also) is typically, Use an
non-Coyote connector.  Unfortunately that is not a good answer.
If they move back to the deprecated AJP13Connector, they will
experience MBean exceptions that, among other things, make the Tomcat
shutdown not function correctly.
Beyond that they are stuck with not using a webserver plugin and
instead going directly to an HTTP connector (non-Coyote).

I would propose two things:
1) Fix the MBean exception in the Ajp13Connector.  I can provide a
patch for this, it is very simple.  Even though this is deprecated, the
reality is that people might need to use it due to bugs and/or
unimplemented features in the Coyote connectors.  It may be their only
choice, and if we can make it work easily, why not?
2) Fix this form authentication problem in the Coyote connector.  I
will look into this and see if it is something that I can do and submit
a patch for.

I actually have similar issues with the native side connector story but
that is for another day.

Anybody know off hand what needs to happen for item #2 above?

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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



Re: Connector issues

2003-04-01 Thread Jeff Tulley
I actually have similar issues with the native side connector story
but
that is for another day.

I was under the impression that mod_jk2 was not production ready by

most measures -- and that mod_jk was good enough for most purposes
(and 
quite production ready)...

I said those were issues for another day.  :)   Actually yes, mod_jk
works.  And it is good enough for most purposes.

What we want is a lot of the new features that had been slated for
mod_webapp, but there is no further development on it.  Also, mod_jk2 as
you say is not production ready.  It has some coding assumptions that
make it not portable to some other platforms, which is a real problem
(I'd have to look at the code for specifics; this is second-hand from
the person who tried to port it to NetWare).  Yet what I hear time and
time again is encouragement for people moving away from mod_jk and to
mod_jk2.  It makes sense if that is the future direction of the
connectors, but the story is full of holes still.  We have chosen to
stick with mod_jk for now, but would sure like to move on to mod_jk2.

--
Jess Holle



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


Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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



[Patch] mbeans-descriptors.xml (was Re: Connector issues)

2003-04-01 Thread Jeff Tulley
Here is the patch for the Ajp13Connector.  

The one caveat is that this patch allows Tomcat to startup and shutdown
without MBean exceptions, but the Tomcat Admin application still will
not work with this connector enabled.  That is, the admin app functions,
but do not click on Connector in the application, since it is looking
for a Coyote connector and does not find the getters and setters it is
looking for.  When I tried it, I clicked on Connector first and it
seemed like I couldn't get anything else to work after that.  If I
clicked on something else first (Host, for instance), then clicked on
Connector I got the error but the rest of the admin application worked
fine.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

 [EMAIL PROTECTED] 4/1/03 10:12:32 AM 
1) Fix the MBean exception in the Ajp13Connector.  I can provide a
patch for this, it is very simple.  Even though this is deprecated,
the
reality is that people might need to use it due to bugs and/or
unimplemented features in the Coyote connectors.  It may be their only
choice, and if we can make it work easily, why not?
ta.apache.org 


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

Re: [Patch] mbeans-descriptors.xml (was Re: Connector issues)

2003-04-01 Thread Jeff Tulley
I agree.  But, as I said in my earlier email, there are defects in the
Coyote Connector driving people to use something else.  If I absolutely
need bug#10229 fixed, what choice do I have?  I am wondering if the
reality is that people will be forced to use the Ajp13Connector, so we
might as well fix this very simple bug.  Yes there will be other
problems, but at least the connector still works.

The mbean descriptor is not only used with the admin, but also it seems
like Tomcat would not shut down if this connector was enabled.  I think
it was a ServiceLifeCycleException of some sort.

We should also fix the Coyote Connector problem.  I am trying to get
some time to look at that issue.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

 [EMAIL PROTECTED] 4/1/03 11:08:30 AM 
Jeff Tulley wrote:
 Here is the patch for the Ajp13Connector.  
 
 The one caveat is that this patch allows Tomcat to startup and
shutdown
 without MBean exceptions, but the Tomcat Admin application still
will
 not work with this connector enabled.  That is, the admin app
functions,
 but do not click on Connector in the application, since it is
looking
 for a Coyote connector and does not find the getters and setters it
is
 looking for.  When I tried it, I clicked on Connector first and it
 seemed like I couldn't get anything else to work after that.  If I
 clicked on something else first (Host, for instance), then clicked
on
 Connector I got the error but the rest of the admin application
worked
 fine.

It's not a good idea to imply that the old AJP connector is to be used.

It is slow and unreliable, and will not work with Tomcat 5.
Also, it is not compatible with the admin webapp, and the MBean 
descriptor is only used in conjunction with the admin webapp in Tomcat,

so adding the AJP connector there will only lead to problems later.

Remy


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


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



Tomcat security handling spec non-compliance

2003-03-27 Thread Jeff Tulley
I think I've found a fairly important place where Tomcat is not spec
compliant. I think there is code in there to make this work, but the
code must have a bug.
The spec part is: SRV 12.5.3, actually in J2EE.12.5.3.1 Login Form
Notes:
...
If the form based login is invoked because of an HTTP request, the
original
request parameters must be preserved by the container for use if, on
successful
authentication, it redirects the call to the requested resource.
...

I have shown that this is not working using the following process:
Create a simple jsp, formHandler.jsp, put it in a protected app (I
used Tomcat's admin):
html
body
% 
String color = request.getParameter(Color);
%
Your color is: %=color%
/body
/html

Create a simple form somewhere outside of there:
html
body
form action=/admin/formHandler.jsp method=post
input type=text name=Color value=red
input type=submit name=Submit
/form
/body
/html

If you submit the form while there is a current valid login to the
admin application, your formHandler jsp outputs the correct parameter
information.
If you submit the form while not authenticated to the application, you
are redirected to the login page. After you enter valid credentials, you
are redirected to the formHandler.jsp, which outputs Your color is:
null It has lost the original request parameters even though it appears
that org.apache.catalina.authenticator.FormAuthenticator, restoreRequest
tries to restore these.

Can somebody else verify that they see this, and should I submit a bug?
 It seems that this is very important and needs to be fixed.

This is on Tomcat 4.1.18, and I just verified it is still there on
Tomcat 4.1.24

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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



Re: Tomcat security handling spec non-compliance

2003-03-27 Thread Jeff Tulley
More info:
Pre-existing bug in bugzilla, 10229.

It seems to be a connector issue.  As the bug states, I can use the old
org.apache.catalina.connector.http.HttpConnector and get the desired
correct behavior.  Since the Coyote Connector is used widely and is the
default, any chance of getting this fixed soon?  This happens on both
the HTTP and JkHandler of Coyote.

(I'll go vote on the bug now, if it helps...)  :-)

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

 [EMAIL PROTECTED] 3/27/03 3:30:40 PM 
I think I've found a fairly important place where Tomcat is not spec
compliant. I think there is code in there to make this work, but the
code must have a bug.
The spec part is: SRV 12.5.3, actually in J2EE.12.5.3.1 Login Form
Notes:
..
If the form based login is invoked because of an HTTP request, the
original
request parameters must be preserved by the container for use if, on
successful
authentication, it redirects the call to the requested resource.
..

I have shown that this is not working using the following process:
Create a simple jsp, formHandler.jsp, put it in a protected app (I
used Tomcat's admin):
html
body
% 
String color = request.getParameter(Color);
%
Your color is: %=color%
/body
/html

Create a simple form somewhere outside of there:
html
body
form action=/admin/formHandler.jsp method=post
input type=text name=Color value=red
input type=submit name=Submit
/form
/body
/html

If you submit the form while there is a current valid login to the
admin application, your formHandler jsp outputs the correct parameter
information.
If you submit the form while not authenticated to the application, you
are redirected to the login page. After you enter valid credentials,
you
are redirected to the formHandler.jsp, which outputs Your color is:
null It has lost the original request parameters even though it
appears
that org.apache.catalina.authenticator.FormAuthenticator,
restoreRequest
tries to restore these.

Can somebody else verify that they see this, and should I submit a
bug?
 It seems that this is very important and needs to be fixed.

This is on Tomcat 4.1.18, and I just verified it is still there on
Tomcat 4.1.24

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com 

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


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



Making an application disabled at startup

2003-03-27 Thread Jeff Tulley
I'm looking for a way to have an application in the webapps directory,
but stopped by default when Tomcat starts up.  I see in the code
(o.a.c.core.StandardContext.java) the setAvailable method, which
should correspond to an XML attribute 'available=true'.  Setting this
has no effect.

Is this supposed to work this way, or is there another built-in way to
achieve the same results?

It would be ideal if the user could enable these applications through
built-in mechanisms like Tomcat's Manager HTML interface.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

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



Re: Making an application disabled at startup

2003-03-27 Thread Jeff Tulley
Sorry, that was meant for the user list!  Oops.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

 [EMAIL PROTECTED] 3/27/03 4:41:01 PM 
I'm looking for a way to have an application in the webapps directory,
but stopped by default when Tomcat starts up.  I see in the code
(o.a.c.core.StandardContext.java) the setAvailable method, which
should correspond to an XML attribute 'available=true'.  Setting
this
has no effect.

Is this supposed to work this way, or is there another built-in way to
achieve the same results?

It would be ideal if the user could enable these applications through
built-in mechanisms like Tomcat's Manager HTML interface.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com 

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


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



Re: Whee!! It's good to be back!

2003-03-21 Thread Jeff Tulley
Br. Burrus has unsubscribed from this list, and subscribed to
tomcat-users.  If you are also on that list, I'd recommend you rewrite
your reply over there, I don't think he is listening here.  (And
warning, the guy is sometimes quite abrasive in his replies/questions,
just so you know, don't take it personal...)

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com

 [EMAIL PROTECTED] 3/21/03 4:24:22 AM 
How about calling
out.close()

Stefanos

Steve Burrus wrote:

 *It's very good indeed to be back in your midst again, and believe

 me, I will try hard to mind my manners and try to use this list for

 the most knowledgeable insight that I can posssibly get about how to

 execute certain jsp's/servlets with the Tomcat web container!!*

 *Case in point: I am having problems with trying to see this 
 TodayServlet.java servlet of mine. It just flat doesn't show up in

 my browser when I try to look at it, sad to say. It is just the most

 simple and basic servlet, so it shouldn't be too much of a big deal

 to correct whatever problem it has, so I could then see it. I 
 naturally have attached it to my posting, and again, it's good to be

 back in your good graces again. *

 *p.s.: excuse my absolute ignorance about how servlet creation is
done 
 successfully, but I was wondering if I possibly need a HTML file to
go 
 along with this servlet as a helper file.*



import java.io.*;
import java.util.Date;
import javax.servlet.*;
import javax.servlet.http.*;

public class TodayServlet extends HttpServlet {

   public void doGet( HttpServletRequest request, 
  HttpServletResponse response )
 throws IOException, ServletException {
  response.setContentType( text/HTML );
  response.setHeader( Pragma, no cache ); 
  response.setHeader( Cache-Control, no cache );
  response.setHeader( Expires, 0 );
  PrintWriter out = response.getWriter();
  out.println( HTML );
  out.println( head );
  out.println( titleToday/title );
  out.println( /head );
  out.println( body bgcolor='00' text='10' );
 out.println(h1The Date and Time, if u didn't know,is:/h1
);
  Date today = new Date(); 
  out.println( p + today + /p );
  out.flush();
  out.println( /body );
  out.println( /HTML );
   }
}
  



!DOCTYPE web-app PUBLIC
   -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN
   http://java.sun.com/j2ee/dtds/web-app_2.2.dtd;

 web-app

 display-name
 How to program servlet examples 
 /display-name  

 description
this is the web app. in which we show our servlets/jsp's. 
 /description

 servlet
servlet-nametoday/servlet-name
servlet-classTodayServlet/servlet-class
 /servlet

 servlet-mapping
servlet-nametoday/servlet-name
url-pattern/today/url-pattern
 /servlet-mapping
 /web-app

  



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



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


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



Re: Whee!! It's good to be back!

2003-03-19 Thread Jeff Tulley
How are you packaging it?  Are you putting it in a certain context, or
what?
How are you trying to view it?  Through Port 8080, or through a web
server?
It seems that your web.xml is fine.  Where are you putting the compiled
.class file in your web app's directory structure?

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com

 [EMAIL PROTECTED] 3/19/03 12:26:18 PM 

It's very good indeed to be back in your midst again, and believe me,
I will try hard to mind my manners and try to use this list for the
most knowledgeable insight that I can posssibly get about how to execute
certain jsp's/servlets with the Tomcat web container!!

Case in point: I am having problems with trying to see this
TodayServlet.java servlet of mine. It just flat doesn't show up in my
browser when I try to look at it, sad to say. It is just the most simple
and basic servlet, so it shouldn't be too much of a big deal to
correct whatever problem it has, so I could then see it. I naturally
have attached it to my posting, and again, it's good to be back in your
good graces again. 

p.s.: excuse my absolute ignorance about how servlet creation is done
successfully, but I was wondering if I possibly need a HTML file to go
along with this servlet as a helper file.

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



Re: socket errors in catalina.out and mod_jk.log

2003-02-28 Thread Jeff Tulley
So, we had a problem trying to port mod_jk2 to NetWare, and that is why
we decided to stick with mod_jk.  Basically the problem was that mod_jk2
assumed that some data table that existed when Apache does its first
load will still be there when apache unloads mod_jk and reloads it. 
This is not the case on some OS platforms, so this code did not port
well at alll.

Is this still the case?

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com

 [EMAIL PROTECTED] 2/28/03 3:56:59 AM 
[EMAIL PROTECTED] wrote:
 Why not restart work on mod_webapp?  I still wonder why it got
dropped.

Because there was only one developper, Pier, with little help from JF
Clere.

BTW, jk2 is here, it's modular and use solid foundations.

Why not works on it ?




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


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



Re: Proposal to give a web front end to the manager app.

2003-01-23 Thread Jeff Tulley
Have you tried /manager/html/  ???

I also was unaware of its existence until recently, though it is what
you get to if you click on the Tomcat Manager link on the main Tomcat
index.jsp page.

I'm not sure of what version of Tomcat this appeared in.  I think it is
in at least 4.1.12.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com

 [EMAIL PROTECTED] 1/23/03 7:40:57 AM 

I have a proposal wrt to the manager app.
Can we make it a bit more user friendly.
Wouldn't a web interface help? It wont be too much work since
servlets are pretty much there to do the work.One just needs to put the
results into a few htmls.
I also feel it would be nice if one could do a bit of configuration
from the interface.
Adding resources like a database pool etc from the interface would be
great.
If you feel it will be useful I can try to reuse some things I have
already done
one the same lines. 

Comments. .



-
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now

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




Misspelled item in tomcat 3.3.x

2003-01-23 Thread Jeff Tulley
Has anybody ever pointed out that the EmbededTomcat.java of Tomcat
3.3.x is mispelled?  Is this something that should be fixed?  I can
submit a patch, if so.  :)
Maybe at least the debug messages, since those are visible to the
users.

Actually, it looks like this misspelling has been carried forward to
Tomcat 4.x with EmbededServletOptions.java, though there are no messages
logged with the misspelling.

Just doing some due-diligence for a tester who spotted this and logged
a defect.  :)

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com

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




Tomcat 4.1.19 stability?

2003-01-22 Thread Jeff Tulley
Has Tomcat 4.1.19 been voted on as to its stability yet?  Maybe I am too
premature on asking this, how soon does a release typically get voted on
after it is tagged?

I see a few bugs fixed in 4.1.19 that I would like to have in our
release, but also I need to have a stable release.

Thanks,

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com

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




Re: [VOTE] Tomcat 4.1.18 release

2002-12-20 Thread Jeff Tulley
Easier said than done.  An interesting observation is the fact that
everybody thought things were stable, and as far as any reports coming
in, it seemed things were.  However, once Remy declared 4.1.17 as
stable, suddenly people actually started putting Catalina through it's
paces(to see if they wanted to put it into production), and started
finding problems.  I think it was a good move, looking back.

I guess what I'm saying is that, unfortunately, the only way to be sure
a release is really stable, is to convince many non-committers to
stress-test it, and they only do that if they are told it is stable.

Unless you want to come up with a stress / stability test procedure to
be run against every build, that would be nice.

 - Jeff

 [EMAIL PROTECTED] 12/19/02 7:06:21 PM 
Remy,

I checked the cvs and found there are some number of changes in the 
writer and response in coyote starting from 4.1.12.  (See the diff from

4.1.12).  Many of the changes are started at around 4.1.15/16.

I think there is the problem in the roll out procedures, especially
when 
a release is voted by the committer as stable and before the release 
manager declare it as GA.  Stability test and code review should be 
thoroughly run.

May be in 5.0, we could do better on this.

- Punky

P.S. I remember there was discussion in the release procedure or 
numbering guides.  But I cannot find one in tomcat site.  Is it just 
from http project? (http://httpd.apache.org/dev/release.html)


Remy Maucherat wrote:
 A bug exists (unfortunately) in Tomcat 4.1.16 and Tomcat 4.1.17 which

 causes the servlet Writer to stay in an invalid state after an 
 IOException occurs (99% of the time caused by an abrupt client 
 disconnection). After this happens, the processor will never be able
to 
 output data using the Writer, causing blank pages. This is more often

 seen with JSPs.
 
 The bug affects Coyote HTTP/1.1, and may also affect Coyote JK 2, 
 although this is less likely.
 
 It is proposed that Tomcat 4.1.18, based on the Tomcat 4.1.17 code,
with 
 the addition of the patch committed by Bill fixing JK 2 SSL support,
as 
 well as the following patch (which I committed one hour ago):
 


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




Re: JkCoyoteHandler does not respect port attribute inserver.xml

2002-11-21 Thread Jeff Tulley
This has been fixed, I think.  There was a checkin by Costin to 
jk/java/org/apache/jk/server JkMain.java - on 30/Oct/2001

So, I'm guessing that means Catalina 4.1.14 or so?

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com

 [EMAIL PROTECTED] 11/20/02 7:26:52 PM 
Did anyone notice that Tomcat 4.1.12 does not respect the port attribute for
the AJP13 connector

I have a connector defined like this,

Connector className=org.apache.coyote.tomcat4.CoyoteConnector
   port=8010 minProcessors=5 maxProcessors=75
   enableLookups=true redirectPort=8444
   acceptCount=10 debug=0 connectionTimeout=2
   useURIValidationHack=false

protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler/

and yet, tomcat starts the connector on port 8009.
any thoughts?

Filip

~
Namaste - I bow to the divine in you
~
Filip Hanik
Software Architect
www.filip.net 

-Original Message-
From: Tim Funk [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, November 20, 2002 6:19 PM
To: [EMAIL PROTECTED] 
Subject: [PATCH] Disable access log rotation


Is anyone opposed to looking at bug 14724? It replaces a similiar
enhancment [bug 12145](with patch) logged a few months ago.

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

The patch also enables writing out Cookies, incoming headers, Session
attributes, and HttpServletRequest attributes in a syntax similar
to apache.

If this functionality is added to the admin app, I believe the following
needs added to mbeans-descriptors.xml in the AccessLogValve section.
 attribute   name=rotatable
   description=Rotate log
is=true
  type=boolean/

-Tim


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




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



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




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

2002-10-30 Thread Jeff Tulley
Thanks, Costin.  I'll pull this down and see if it works for the problem
I was seeing.  I have this vain imagination that I'm actually going to
get some time to try tackling the bigger problem (single-sourced config
on all of this), but with the way things are going at work, it probably
won't happen.  It seems like it would be a good problem to solve
though.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com

 [EMAIL PROTECTED] 10/30/02 5:56:36 PM 
costin  2002/10/30 16:56:36

  Modified:jk/java/org/apache/jk/server JkMain.java
  Log:
  Added support for coyote properties and 'shortcuts'.
  
  This should solve a number of problems where information
  was not passed from server.xml to jk.
  
  Long term we should just consolidate all the config - but that'll
  take a bit more time.
  
  PR: 12686
  

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




Re: MBeanException w/AJP13Connector and (hopefully)itssolution

2002-10-22 Thread Jeff Tulley
Yeah there are a miriad of solutions to this problem.

First off, the immediate solutions is to add the patch I posted to the list - that is, 
to add in the MBean tags to the mbean descriptor XML file, describing the AJP 13 
connector.  That gets rid of the exception right away.  This, of course, keeps you 
using the deprecated AJP 13 Connector.  We had resisted moving since we did not 
realize that the new Coyote connector does work with the old mod_jk Apache mod.  I've 
attached that patch.

Now, the options if you move to the Coyote JkHandler:
1) Easiest, immediate fix to the problem:
   AddIntrospectionUtils.setProperty(protocolHandler, 
channelSocket.port,  + port);  to the file 
coyote/src/java/org/apache/coyote/tomcat4/CoyoteConnector.java, in the 
jakarta-tomcat-connectors project.  Add this in the initialize method, right after the 
line that sets the port.
What this does is take whatever port you have set in your server.xml and also sets 
that port for the channelSocket.  If you also have a value in jk2.properties, this 
value will over-ride that one.
I've attached a patch that has the unified diff of this fix.

2) What really needs to happen is some way of associating the connector instances in 
server.xml with the connector properties in jk2.properties that allows you to have 
multiple instances of Tomcat.  This would take a bit more work, though a lot of the 
support is already there in jk2.properties.  (IE, instead of channelSocket.port=8009 
in jk2.properties, you can have channelSocketPort.instance1.port=8009.  The only 
thing left to do is associate the connector in server.xml with instance1, maybe with 
a new attribute in the Connector XML tag).   This would be a bit more involved, and I 
do not have a patch for this problem (yet?).
With this solution, all of the configuration information that is common between the 
java Connector and the C-based Apache Mods can come from one file instead of two as in 
the past.  I think this is the design the committers want ultimately.


Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com

 Richard Doorduin [EMAIL PROTECTED] 10/22/02 4:57:20 AM 
Dear Jeff,

It seems that we are sharing the same problem that is if you still haven't
found the solution for it.
That is why I am emailing you.

Because it would make it less difficult if you found the solution for it.

I hope you can reply to me!

Greetings,


Richard Doorduin




mbeans-descriptors.patch
Description: Binary data


CoyoteConnector.patch
Description: Binary data
--
To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org


Re: Vote results + Security Audit redirection

2002-10-18 Thread Jeff Tulley
It sounds like there is already a closed forum for discussing security, CC'ing all 
who might be interested.  Making it a list just makes lives easier for all involved, 
and the whole thread is not lost and always exclusive only to those CC'd.  (If the 
messages are eventually forwarded to the dev list or archived).

People are saying that they are worried about something that is already going on, in a 
slightly different form.  As long as the committers are responsible with this other 
list, things should only be better.  Maybe the automatic forward (with a delay) will 
serve to keep everybody responsible on into the future.  How hard is that to set up??

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com

 [EMAIL PROTECTED] 10/17/02 8:14:59 AM 

The nice thing about your current way of dicussing security issues
(CC e-mail threads) is that it's a real pain in the butt.  In other
words, likely only to be used in the cases of necessity.


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




Re: MBeanException w/AJP13Connector and (hopefully) itssolution

2002-10-15 Thread Jeff Tulley

So I'm barking up the wrong tree?  I thought somebody had told me that the Coyote JK 2 
connector only worked with mod_jk2.  I'll go play around with the Coyote / mod_jk 
combo on NetWare, and see how it works.

Thanks.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com

 [EMAIL PROTECTED] 10/15/02 1:08:06 AM 
Jeff Tulley wrote:
 When I uncomment the AJP13 Connector, I get the following exception on startup:
 ServerLifecycleListener: createMBeans: MBeanException   
 java.lang.Exception: ManagedBean is not found with Ajp13Connector   
 at org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:225)
   
 at 
org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:369)

 at 
org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:777)

 at 
org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:751)

 at 
org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:339)

 at 
org.apache.catalina.mbeans.ServerLifecycleListener.lifecycleEvent(ServerLifecycleListener.java:206)
  
 at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166)
  
 at org.apache.catalina.core.StandardServer.start(StandardServer.java:2182)   
   
 at org.apache.catalina.startup.Catalina.start(Catalina.java:510)
 at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)  
 at org.apache.catalina.startup.Catalina.process(Catalina.java:180)  
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)  
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 
   
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 
   
 at java.lang.reflect.Method.invoke(Method.java:324) 
 at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) 
 
 I'm wondering if the fix is simply to add a section into 
catalina/src/share/o/a/c/mbeans/mbeans-descriptors.xml, describing the AJP 13 
connector?
 
 I've attached my naive fix to this, which is to copy the Coyote connector section, 
removing only the protocolHandler attribute, since that is unique to Coyote(if I'm 
not mistaken, I very well could be).
 
 Could I get one of the committers to review this please and submit the change?  We 
need this for NetWare, which does not have a port of mod_jk2 yet.

Either Coyote JK 2 or the old AJP 1.3 connector can be used with mod_jk 
(that's why the AJP 1.3 connector is deprecated).

Remy


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



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




Re: MBeanException w/AJP13Connector and (hopefully)itssolution

2002-10-15 Thread Jeff Tulley

So I find that works on NetWare with our mod_jk, as you said.  The only thing that 
worries me is that the port value set in server.xml is not honored, on Windows or on 
NetWare.  Is there somewhere else it is pulling its configuration from?  I cannot have 
shifting ajp ports, since I might have two catalina instances running simultaneously, 
and I need to control what port Apache sends requests to, so that I can route them 
right.

What I saw was that I set the port to 9010, but Catalina still comes up with ajp13 
listening on tcp port 8009.  When I fire up the second instance of Catalina, it comes 
up listening on 8010, after unsuccessfully trying to get port 8009.  I cannot just use 
8009 and 8010, due to both port conflicts on NetWare(with 8009), and because I do not 
want to rely on startup order of the two Catalina instances.

Is this a bug, or is there some part of the design that I'm missing?

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com

 [EMAIL PROTECTED] 10/15/02 9:44:57 AM 
So I'm barking up the wrong tree?  I thought somebody had told me that the Coyote JK 2 
connector only worked with mod_jk2.  I'll go play around with the Coyote / mod_jk 
combo on NetWare, and see how it works.

Thanks.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com 

 [EMAIL PROTECTED] 10/15/02 1:08:06 AM 
Jeff Tulley wrote:
 When I uncomment the AJP13 Connector, I get the following exception on startup:
 ServerLifecycleListener: createMBeans: MBeanException   
 java.lang.Exception: ManagedBean is not found with Ajp13Connector   
 at org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:225)
   
 at 
org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:369)

 at 
org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:777)

 at 
org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:751)

 at 
org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:339)

 at 
org.apache.catalina.mbeans.ServerLifecycleListener.lifecycleEvent(ServerLifecycleListener.java:206)
  
 at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166)
  
 at org.apache.catalina.core.StandardServer.start(StandardServer.java:2182)   
   
 at org.apache.catalina.startup.Catalina.start(Catalina.java:510)
 at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)  
 at org.apache.catalina.startup.Catalina.process(Catalina.java:180)  
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)  
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 
   
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 
   
 at java.lang.reflect.Method.invoke(Method.java:324) 
 at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) 
 
 I'm wondering if the fix is simply to add a section into 
catalina/src/share/o/a/c/mbeans/mbeans-descriptors.xml, describing the AJP 13 
connector?
 
 I've attached my naive fix to this, which is to copy the Coyote connector section, 
removing only the protocolHandler attribute, since that is unique to Coyote(if I'm 
not mistaken, I very well could be).
 
 Could I get one of the committers to review this please and submit the change?  We 
need this for NetWare, which does not have a port of mod_jk2 yet.

Either Coyote JK 2 or the old AJP 1.3 connector can be used with mod_jk 
(that's why the AJP 1.3 connector is deprecated).

Remy


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



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


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




Re: MBeanException w/AJP13Connector and (hopefully)itssolution

2002-10-15 Thread Jeff Tulley

Thanks Costin.  I can look into the patch for the port number in server.xml not being 
honored.  I'm not too JMX savvy, so I probably won't be much help with the MBeans 
extension mechanism.  I see the need though, after going through changing it myself.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com

 [EMAIL PROTECTED] 10/15/02 10:44:05 AM 
Jeff Tulley wrote:

 So I find that works on NetWare with our mod_jk, as you said.  The only
 thing that worries me is that the port value set in server.xml is not
 honored, on Windows or on NetWare.  Is there somewhere else it is pulling
 its configuration from?  I cannot have shifting ajp ports, since I might
 have two catalina instances running simultaneously, and I need to control
 what port Apache sends requests to, so that I can route them right.
 
 What I saw was that I set the port to 9010, but Catalina still comes up
 with ajp13 listening on tcp port 8009.  When I fire up the second
 instance of Catalina, it comes up listening on 8010, after unsuccessfully
 trying to get port 8009.  I cannot just use 8009 and 8010, due to both
 port conflicts on NetWare(with 8009), and because I do not want to rely on
 startup order of the two Catalina instances.
 
 Is this a bug, or is there some part of the design that I'm missing?

Most likely a bug.

The problem is that we're using 2 configs - one is jk2.properties,
and the other is server.xml.

The original intention was that both mod_jk and the java side use the
same config file/format. Xml in C was considered too complex and too
big change. Unfortunately that wasn't implemented, but there is still
hope for 5.0, if the new config mechanism happens.

Regarding 8009, 8010, etc - that can be disabled ( set maxPort==port ),
it is intended to simplify load-balanced setup ( no need for multiple
configs - at least if you disable the shutdown and http ports which may
create conflicts ).

I'm pretty sure that if you set the port in jk2.properties it'll work,
I'll try to find out why the information is not passed from server.xml.
( if you can send a patch - it would be great ).

Regarding jk1/jk2 - the protocol is identical. The java side ( coyote-based) 
is stable for jk2, and it seems much better than the original connector,
so that's the default. The old one can be considered as deprecated. On the
C side, jk2 is getting there - but most people consider jk1 as more stable
and it's the only one to support netscape or aol - we only implemented the 
apache and iis adapters so far for jk2. Hopefully mod_jk2 will be released 
at the same time with 5.0.

We certainly need a mechanism to extend the mbeans.xml for thrid party
and other modules, again - a patch would be great :-)


Costin





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



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




MBeanException w/AJP13Connector and (hopefully) its solution

2002-10-14 Thread Jeff Tulley

When I uncomment the AJP13 Connector, I get the following exception on startup:
ServerLifecycleListener: createMBeans: MBeanException   
java.lang.Exception: ManagedBean is not found with Ajp13Connector   
at org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:225)  
 
at 
org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:369)

at 
org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:777)

at 
org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:751)

at 
org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:339)

at 
org.apache.catalina.mbeans.ServerLifecycleListener.lifecycleEvent(ServerLifecycleListener.java:206)
  
at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166)
  
at org.apache.catalina.core.StandardServer.start(StandardServer.java:2182) 
 
at org.apache.catalina.startup.Catalina.start(Catalina.java:510)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)  
at org.apache.catalina.startup.Catalina.process(Catalina.java:180)  
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)  
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)  
  
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)  
  
at java.lang.reflect.Method.invoke(Method.java:324) 
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) 

I'm wondering if the fix is simply to add a section into 
catalina/src/share/o/a/c/mbeans/mbeans-descriptors.xml, describing the AJP 13 
connector?

I've attached my naive fix to this, which is to copy the Coyote connector section, 
removing only the protocolHandler attribute, since that is unique to Coyote(if I'm not 
mistaken, I very well could be).

Could I get one of the committers to review this please and submit the change?  We 
need this for NetWare, which does not have a port of mod_jk2 yet.

Thanks,

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com




mbeans-descriptors.patch
Description: Binary data

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


Re: JBoss 3.0 and Tomcat 4.1

2002-09-24 Thread Jeff Tulley

It would require a bit of integration, due to the fact that Tomcat 4.1
changed how it was doing it's XML parsing.  Excuse me if I get the
details wrong, I haven't looked at this for a few months, but it seems
that Tomcat 4.0 used its own XML parser (digester??), then moved to
using the commons version.  JBoss's integration uses the old versions of
the classes and would have to be updated to use the same new commons
classes.

It wouldn't be TOO dificult, but it's not just replaceable
automatically.  To me, it seemed as if the JBoss developers do the
integration once there is a stable, official release of Tomcat, so they
were just waiting for that with the 4.1.x code base.  You might want to
ping Scott Stark on the JBoss development list (or online forum), he is
usually the one who has done the integration.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com

 [EMAIL PROTECTED] 9/23/02 3:13:06 PM 
Is there any particular reason why I could not configure Tomcat 4.1
instead 
of 4.0 to the JBoss 3.0 j2ee server setup?

Micael



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