What is the possibility of / interest in a 4.1.31 release?
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?
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?
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])
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])
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
-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
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
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
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...]
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 ?
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
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
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
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 ...
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
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
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
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
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
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?
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?
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
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?
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?
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?
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
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
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
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
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
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.
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)
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)
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)
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)
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)
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)
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
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)
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/PK VT.+ML;Ü Í 7 test/org/apache/tomcat/util/http/AddParametersTest.javaíXÛnÛF}è%rÀй´/IS(Lª$e7d-®¬mxQ¸¤U!È¿÷ìòjYiÆAû`6©Ý33gfgÆ|[EMAIL
PROTECTED],\q²ÖlG-
Ë9MŧtÆs)[EMAIL PROTECTED]
HDV ¤1r.y~Å#³Eõy$dRK#*%'ÌÊ|ÁõÊ
HY¾¥e'Ò (Våú
I²H,ÅBë5HÙ±æyG´Î³+á¥X±¿8â8ÛôY
%$5Lxñ¼5ï¹c¡¤lÙ¶È /e¿
6»È®ÔVMFÁ'Í
kàPátÚµ×MÖEÌDÂsZ{Þ´z{ü4öÀé¨ßÉ$hm`Ô([ O ÖññÉ°SÂ
Ë.:ØlúþtñÌÔùÅÓè2ßÑ!ÒE\öÁàs Ç
±lðYº5*^j© ·Øâ}mb~Éþs¢FA¨Ø©Ølå%2 N÷_ñ8[ÃíÉþÍÝ áª(ÖÏ7Éô13Ë/ÌA`Å
.{ñ¶Ñu;ÁìØzÍÖÝZ%
[EMAIL PROTECTED],yÂâ¸ÁïòC% a ^aïÁhgð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ù¡3O-fsæ6Áp-?vÑÔrNí1:ãB5Ùg¶RpbM§Z³5³Fx´þN¼¹;¶BÇsáqÂFú¬÷ülØo MíÊ Ð0v|{*O»·(ÙÓêª3{äà ³á«å¿6eÀ
ìßæ8M[§Ö± Ððc¤Ï2ûö©ò4ó£ tÂyhÓ±ç Øþ3²4õÀ7Ñ
óÀ6 )´´8÷£yàh^ 7´}S, ÐwÒ`«5WF ªØ¸Úupèù¯ #ÎOl¬ûrÍ¥(
Àà(ì «`|¸ã=ɵ§Î±ílµë)¤s'°V'PJõ¹½ó°ÉMXX½öRØÐ1'gBÖøÌѹZ FªNV59Á|tRA_Û ¬ú· õ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ê ú±TÇÿIjdîßû¨¤P~ ÔORórq]þ#7aÌæ䫵ZÇðyù¸^:ÔÏÚà ɣæ è +9BgGêzíSmX%Õø´@éÒêÍ[wÀ*
x[
Í_¦)ÆѼL7½ÑduZIQb±À¹¾àK.Ý2åÛáö4?^RÊ7½õa
^ å¸úãyÉVÈU-´'¸YÓ°1WLâúØq5
]øT¹d. Í8hÅ0c_pLYÛA§âSóÒk³Ø
)¨0´m\,ᤠí
[Proposal] error page handling on authorization failure
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
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
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
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
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)
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)
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
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
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]
Re: Making an application disabled at startup
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!
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!
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
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.
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
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?
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
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
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
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
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
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
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
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
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
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
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]
