Re: [VOTE] 5.0.9 stability rating
Resend. It's been almost 3 hours since I sent the original email. wonder if it's my mail server or apache... Amy Roh wrote: Remy Maucherat wrote: Amy Roh wrote: Remy Maucherat wrote: Amy Roh wrote: I'll update the mbean-descriptor.xml and admin page for Connector soon. Thanks. Sorry for the trouble. No Problem. I just committed the updates. Let me know if there is additional updates or if I missed/overlooked anything. The changes are a bit more complex than what you did. The new syntax is: HTTP/1.1: Connector port=8080 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 disableUploadTimeout=true / (the thread pool configuration changed, basically) AJP/1.3: Connector port=8009 enableLookups=false redirectPort=8443 debug=0 protocol=AJP/1.3 / (ie, no thread pool configuration here) Please don't add get/set on the CoyoteConnector class itself (we're trying to avoid that, as it's protocol dependent; you can look at Bill's patch - which I reverted for performance reasons, but which did the right thing on principle). IMO, you should add those to the ConnectorMBean, and use get/setProperty. What do you think ? I thought we're moving away from using *MBean classes and instead using the actual class for management implementation. But I see that why we want to avoid the getters and setters from the class due to protocol dependency. We can definitely move the getters/setters into a ConnectorMBean as long as modeler keeps supporting extending class mbean. I can either update o.a.c.mbeans.ConnectorMBean and use it or put the ConnectorMBean in the coyote directory with the mbean-descriptor and the Connector class. I'll need to update admin to represent thread pool configuration changes. Amy 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]
[Fwd: Re: [VOTE] 5.0.9 stability rating]
resend again. my email's been getting lost for some reason. Original Message Subject: Re: [VOTE] 5.0.9 stability rating Date: Tue, 26 Aug 2003 16:11:35 -0700 From: Amy Roh [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] btw, why does Http11Protocol.getAttribute always return null? Is it on purpose or just not implement yet since no usage? Amy Roh wrote: Resend. It's been almost 3 hours since I sent the original email. wonder if it's my mail server or apache... Amy Roh wrote: Remy Maucherat wrote: Amy Roh wrote: Remy Maucherat wrote: Amy Roh wrote: I'll update the mbean-descriptor.xml and admin page for Connector soon. Thanks. Sorry for the trouble. No Problem. I just committed the updates. Let me know if there is additional updates or if I missed/overlooked anything. The changes are a bit more complex than what you did. The new syntax is: HTTP/1.1: Connector port=8080 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 disableUploadTimeout=true / (the thread pool configuration changed, basically) AJP/1.3: Connector port=8009 enableLookups=false redirectPort=8443 debug=0 protocol=AJP/1.3 / (ie, no thread pool configuration here) Please don't add get/set on the CoyoteConnector class itself (we're trying to avoid that, as it's protocol dependent; you can look at Bill's patch - which I reverted for performance reasons, but which did the right thing on principle). IMO, you should add those to the ConnectorMBean, and use get/setProperty. What do you think ? I thought we're moving away from using *MBean classes and instead using the actual class for management implementation. But I see that why we want to avoid the getters and setters from the class due to protocol dependency. We can definitely move the getters/setters into a ConnectorMBean as long as modeler keeps supporting extending class mbean. I can either update o.a.c.mbeans.ConnectorMBean and use it or put the ConnectorMBean in the coyote directory with the mbean-descriptor and the Connector class. I'll need to update admin to represent thread pool configuration changes. Amy 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [VOTE] 5.0.9 stability rating]
- Original Message - From: Amy Roh [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, August 26, 2003 5:15 PM Subject: [Fwd: Re: [VOTE] 5.0.9 stability rating] resend again. my email's been getting lost for some reason. Well, at least SOBIG is only around for another two weeks :). Original Message Subject: Re: [VOTE] 5.0.9 stability rating Date: Tue, 26 Aug 2003 16:11:35 -0700 From: Amy Roh [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] btw, why does Http11Protocol.getAttribute always return null? Is it on purpose or just not implement yet since no usage? I believe that it is simply not implemented yet. Amy Roh wrote: Resend. It's been almost 3 hours since I sent the original email. wonder if it's my mail server or apache... Amy Roh wrote: Remy Maucherat wrote: Amy Roh wrote: Remy Maucherat wrote: Amy Roh wrote: I'll update the mbean-descriptor.xml and admin page for Connector soon. Thanks. Sorry for the trouble. No Problem. I just committed the updates. Let me know if there is additional updates or if I missed/overlooked anything. The changes are a bit more complex than what you did. The new syntax is: HTTP/1.1: Connector port=8080 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 disableUploadTimeout=true / (the thread pool configuration changed, basically) AJP/1.3: Connector port=8009 enableLookups=false redirectPort=8443 debug=0 protocol=AJP/1.3 / (ie, no thread pool configuration here) Please don't add get/set on the CoyoteConnector class itself (we're trying to avoid that, as it's protocol dependent; you can look at Bill's patch - which I reverted for performance reasons, but which did the right thing on principle). IMO, you should add those to the ConnectorMBean, and use get/setProperty. What do you think ? I thought we're moving away from using *MBean classes and instead using the actual class for management implementation. But I see that why we want to avoid the getters and setters from the class due to protocol dependency. We can definitely move the getters/setters into a ConnectorMBean as long as modeler keeps supporting extending class mbean. I can either update o.a.c.mbeans.ConnectorMBean and use it or put the ConnectorMBean in the coyote directory with the mbean-descriptor and the Connector class. I'll need to update admin to represent thread pool configuration changes. Amy 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
Remy Maucherat wrote: Amy Roh wrote: Remy Maucherat wrote: Amy Roh wrote: I'll update the mbean-descriptor.xml and admin page for Connector soon. Thanks. Sorry for the trouble. No Problem. I just committed the updates. Let me know if there is additional updates or if I missed/overlooked anything. The changes are a bit more complex than what you did. The new syntax is: HTTP/1.1: Connector port=8080 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 disableUploadTimeout=true / (the thread pool configuration changed, basically) AJP/1.3: Connector port=8009 enableLookups=false redirectPort=8443 debug=0 protocol=AJP/1.3 / (ie, no thread pool configuration here) Please don't add get/set on the CoyoteConnector class itself (we're trying to avoid that, as it's protocol dependent; you can look at Bill's patch - which I reverted for performance reasons, but which did the right thing on principle). IMO, you should add those to the ConnectorMBean, and use get/setProperty. What do you think ? I thought we're moving away from using *MBean classes and instead using the actual class for management implementation. But I see that why we want to avoid the getters and setters from the class due to protocol dependency. We can definitely move the getters/setters into a ConnectorMBean as long as modeler keeps supporting extending class mbean. I can either update o.a.c.mbeans.ConnectorMBean and use it or put the ConnectorMBean in the coyote directory with the mbean-descriptor and the Connector class. I'll need to update admin to represent thread pool configuration changes. Amy 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: [VOTE] 5.0.9 stability rating
- Original Message - From: Amy Roh [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, August 26, 2003 12:11 PM Subject: Re: [VOTE] 5.0.9 stability rating Remy Maucherat wrote: Amy Roh wrote: Remy Maucherat wrote: Amy Roh wrote: I'll update the mbean-descriptor.xml and admin page for Connector soon. Thanks. Sorry for the trouble. No Problem. I just committed the updates. Let me know if there is additional updates or if I missed/overlooked anything. The changes are a bit more complex than what you did. The new syntax is: HTTP/1.1: Connector port=8080 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 disableUploadTimeout=true / (the thread pool configuration changed, basically) AJP/1.3: Connector port=8009 enableLookups=false redirectPort=8443 debug=0 protocol=AJP/1.3 / (ie, no thread pool configuration here) Please don't add get/set on the CoyoteConnector class itself (we're trying to avoid that, as it's protocol dependent; you can look at Bill's patch - which I reverted for performance reasons, but which did the right thing on principle). IMO, you should add those to the ConnectorMBean, and use get/setProperty. What do you think ? I thought we're moving away from using *MBean classes and instead using the actual class for management implementation. But I see that why we want to avoid the getters and setters from the class due to protocol dependency. We can definitely move the getters/setters into a ConnectorMBean as long as modeler keeps supporting extending class mbean. I can either update o.a.c.mbeans.ConnectorMBean and use it or put the ConnectorMBean in the coyote directory with the mbean-descriptor and the Connector class. I'll need to update admin to represent thread pool configuration changes. Amy Yeah, I know that this is a six-hour-stale message ;-). The Connector has become somewhat of a special case, so it probably merits getting it's own intelligent MBean. There are properties that make sense on one Connector (e.g. maxKeepAliveRequest on HTTP/1.1, but not on AJP), and default values that are wildly different (e.g. connectionTimeout, which should be enabled to a short value on HTTP/1.1, and disabled on AJP). I attempted to implement this in the Connector class, but as Remy pointed out, it's not practical given the need to access attributes in the critical path. So, the Connectors need a custom MBean to allow JMX to be able to configure them correctly. If you need help in implementation, I'm more than happy to lend a hand ;-). Point of fact was that I was assuming that I would be making the changes you've made myself. 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] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
btw, why does Http11Protocol.getAttribute always return null? Is it on purpose or just not implement yet since no usage? Amy Roh wrote: Resend. It's been almost 3 hours since I sent the original email. wonder if it's my mail server or apache... Amy Roh wrote: Remy Maucherat wrote: Amy Roh wrote: Remy Maucherat wrote: Amy Roh wrote: I'll update the mbean-descriptor.xml and admin page for Connector soon. Thanks. Sorry for the trouble. No Problem. I just committed the updates. Let me know if there is additional updates or if I missed/overlooked anything. The changes are a bit more complex than what you did. The new syntax is: HTTP/1.1: Connector port=8080 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 disableUploadTimeout=true / (the thread pool configuration changed, basically) AJP/1.3: Connector port=8009 enableLookups=false redirectPort=8443 debug=0 protocol=AJP/1.3 / (ie, no thread pool configuration here) Please don't add get/set on the CoyoteConnector class itself (we're trying to avoid that, as it's protocol dependent; you can look at Bill's patch - which I reverted for performance reasons, but which did the right thing on principle). IMO, you should add those to the ConnectorMBean, and use get/setProperty. What do you think ? I thought we're moving away from using *MBean classes and instead using the actual class for management implementation. But I see that why we want to avoid the getters and setters from the class due to protocol dependency. We can definitely move the getters/setters into a ConnectorMBean as long as modeler keeps supporting extending class mbean. I can either update o.a.c.mbeans.ConnectorMBean and use it or put the ConnectorMBean in the coyote directory with the mbean-descriptor and the Connector class. I'll need to update admin to represent thread pool configuration changes. Amy 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
Bill Barker wrote: - Original Message - From: Amy Roh [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, August 26, 2003 12:11 PM Subject: Re: [VOTE] 5.0.9 stability rating Remy Maucherat wrote: Amy Roh wrote: Remy Maucherat wrote: Amy Roh wrote: I'll update the mbean-descriptor.xml and admin page for Connector soon. Thanks. Sorry for the trouble. No Problem. I just committed the updates. Let me know if there is additional updates or if I missed/overlooked anything. The changes are a bit more complex than what you did. The new syntax is: HTTP/1.1: Connector port=8080 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 disableUploadTimeout=true / (the thread pool configuration changed, basically) AJP/1.3: Connector port=8009 enableLookups=false redirectPort=8443 debug=0 protocol=AJP/1.3 / (ie, no thread pool configuration here) Please don't add get/set on the CoyoteConnector class itself (we're trying to avoid that, as it's protocol dependent; you can look at Bill's patch - which I reverted for performance reasons, but which did the right thing on principle). IMO, you should add those to the ConnectorMBean, and use get/setProperty. What do you think ? I thought we're moving away from using *MBean classes and instead using the actual class for management implementation. But I see that why we want to avoid the getters and setters from the class due to protocol dependency. We can definitely move the getters/setters into a ConnectorMBean as long as modeler keeps supporting extending class mbean. I can either update o.a.c.mbeans.ConnectorMBean and use it or put the ConnectorMBean in the coyote directory with the mbean-descriptor and the Connector class. I'll need to update admin to represent thread pool configuration changes. Amy Yeah, I know that this is a six-hour-stale message ;-). The Connector has become somewhat of a special case, so it probably merits getting it's own intelligent MBean. There are properties that make sense on one Connector (e.g. maxKeepAliveRequest on HTTP/1.1, but not on AJP), and default values that are wildly different (e.g. connectionTimeout, which should be enabled to a short value on HTTP/1.1, and disabled on AJP). I attempted to implement this in the Connector class, but as Remy pointed out, it's not practical given the need to access attributes in the critical path. So, the Connectors need a custom MBean to allow JMX to be able to configure them correctly. I think only a subset of the attributes are needed in the critical path. IMO we should handle them as special cases (ie, cache them as local fields) and reapply your patch (it looked like a really good idea before I did some profiling). If you need help in implementation, I'm more than happy to lend a hand ;-). Point of fact was that I was assuming that I would be making the changes you've made myself. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
Bill Barker wrote: If you need help in implementation, I'm more than happy to lend a hand ;-). Point of fact was that I was assuming that I would be making the changes you've made myself. Cool. So I looked at your reverted patch. I think it makes sense to put similar implemntation into ConnectorMBean class then. Would you like to do it or do you want me to use your patch and apply it? Thanks, Amy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
Jean-Francois Arcand [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Bill Barker wrote: - Original Message - From: Jean-Francois Arcand [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, August 25, 2003 6:20 AM Subject: Re: [VOTE] 5.0.9 stability rating Bill Barker wrote: - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, August 25, 2003 12:32 AM Subject: Re: [VOTE] 5.0.9 stability rating Bill Barker wrote: Tim Funk wrote: Installed 5.0.9 from exe (win2k) 1) startup.bat worked fine, but the icon which calls tomcatw.exe //GT//Tomcat5 fails will some Current Thread not owner error 2) Race conditions and connection handling in JDBCRealm - plus a whole host of other JDBCRealm bugs in Bugzilla applicable to 4 and 5. I hope early next week to have a patch which will close many of the JDBCRealm bugs. 3) Need to reinvestigate the JNDIRealm bug reopened. For the first error - I am sure I just need to look through bugzilla, or the archives and just need to add something to the README. (User error) This works for me, Bill, and presumably others. There are reports on tomcatw in BZ, so it must be at least an uncommon error (given the code have stayed stable for a few releases). Even if the bug is mildly common, the old shell scripts are still there. I can put a note stating that they can be used in case the new .exe wrapper somehow fails. I'm staying by my beta rating. Again, we cannot continue releasing alphas just because there could be some non obvious bugs in the build. In the current system, the period before the vote is meant to check if there are no showstoppers. If the build is mostly clean, it must be a beta, otherwise, it merely delays wider testing and finding bugs, which is *bad*. Ok. I'm willing to vote for a (weak) Beta in exchange for a release-note that Tomcat doesn't implement the current-draft's Authentication requirements. What is your plan, BTW ? Wait a bit more for the deadline to see what the final specification will say ? (IMO, the old auth matching rules were not very good) I was hoping for a pfd4, but it doesn't look like it's coming out anytime soon :-(. It's a pretty big change to conform to pfd3 (which is a completely nonsensical requirement :), so I was playing the wait-and-see game. Of course, I'm more than happy to do the grunt work to bring Tomcat into compliance with pfd3. However, if the spec changes to something sensible, then that means two big (e.g. changing interfaces in o.a.c) API changes. The spec should'nt change now. I don't really understand why you think we aren't complinat right nowI tough your last change was to bring back compatibility with PFD 3. Do you have an example I can use to demonstrate the problem? Thanks, The following doesn't work correctly according to pfd3: security-constraint web-resource-collection url-pattern/*/url-pattern /web-resource-collection auth-constraint role-name*/role-name /auth-constraint /security-constraint security-constraint web-resource-collection url-pattern/product1/*/url-pattern /web-resource-collection auth-constraint role-nameproduct1/role-name /auth-constraint /security-constraint security-constraint web-resource-collection url-pattern/product2/*/url-pattern /web-resource-collection auth-constraint role-nameproduct2/role-name /auth-constraint /security-constraint With Tomcat, you need role 'product1' to access /myapp/product1, role 'product2' to access /myapp/product2, and must be authenticated to access anything else. The correct behavior is that any authenticated user can access anything. My understanding of the spec is that is the proper behaviour (just discussed the issue with the spec lead). Having role-name equals to * doesn't means you have access to /product1/* etc. The spec will be clarified (but the required behaviour will stay the same) +1 for clarification (although somewhat meaningless, since I'm not a servlet-api committer :). It currently reads too much like it was modeled after 'grant'. I guess that gets rid of my excuses to not re-visit the code and see if I can't get rid of some of the garbage. -- Jeanfrancois -- Jeanfrancois Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may
Re: [VOTE] 5.0.9 stability rating
Amy Roh wrote: Remy Maucherat wrote: Amy Roh wrote: I'll update the mbean-descriptor.xml and admin page for Connector soon. Thanks. Sorry for the trouble. No Problem. I just committed the updates. Let me know if there is additional updates or if I missed/overlooked anything. The changes are a bit more complex than what you did. The new syntax is: HTTP/1.1: Connector port=8080 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 disableUploadTimeout=true / (the thread pool configuration changed, basically) AJP/1.3: Connector port=8009 enableLookups=false redirectPort=8443 debug=0 protocol=AJP/1.3 / (ie, no thread pool configuration here) Please don't add get/set on the CoyoteConnector class itself (we're trying to avoid that, as it's protocol dependent; you can look at Bill's patch - which I reverted for performance reasons, but which did the right thing on principle). IMO, you should add those to the ConnectorMBean, and use get/setProperty. What do you think ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
Doh! http://jakarta.apache.org/tomcat/faq/windows.html#illegal -Tim Remy Maucherat wrote: Tim Funk wrote: Installed 5.0.9 from exe (win2k) 1) startup.bat worked fine, but the icon which calls tomcatw.exe //GT//Tomcat5 fails will some Current Thread not owner error This works for me, Bill, and presumably others. There are reports on tomcatw in BZ, so it must be at least an uncommon error (given the code have stayed stable for a few releases). Even if the bug is mildly common, the old shell scripts are still there. I can put a note stating that they can be used in case the new .exe wrapper somehow fails. I'm staying by my beta rating. Again, we cannot continue releasing alphas just because there could be some non obvious bugs in the build. In the current system, the period before the vote is meant to check if there are no showstoppers. If the build is mostly clean, it must be a beta, otherwise, it merely delays wider testing and finding bugs, which is *bad*. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Sunday, August 24, 2003 11:25 AM Subject: Re: [VOTE] 5.0.9 stability rating Tim Funk wrote: Installed 5.0.9 from exe (win2k) 1) startup.bat worked fine, but the icon which calls tomcatw.exe //GT//Tomcat5 fails will some Current Thread not owner error 2) Race conditions and connection handling in JDBCRealm - plus a whole host of other JDBCRealm bugs in Bugzilla applicable to 4 and 5. I hope early next week to have a patch which will close many of the JDBCRealm bugs. 3) Need to reinvestigate the JNDIRealm bug reopened. For the first error - I am sure I just need to look through bugzilla, or the archives and just need to add something to the README. (User error) This works for me, Bill, and presumably others. There are reports on tomcatw in BZ, so it must be at least an uncommon error (given the code have stayed stable for a few releases). Even if the bug is mildly common, the old shell scripts are still there. I can put a note stating that they can be used in case the new .exe wrapper somehow fails. I'm staying by my beta rating. Again, we cannot continue releasing alphas just because there could be some non obvious bugs in the build. In the current system, the period before the vote is meant to check if there are no showstoppers. If the build is mostly clean, it must be a beta, otherwise, it merely delays wider testing and finding bugs, which is *bad*. Ok. I'm willing to vote for a (weak) Beta in exchange for a release-note that Tomcat doesn't implement the current-draft's Authentication requirements. For the last 2 errors - tomcat can be considered beta or stable with the buggy JNDIRealm and JDBCRealms since the tomcat4.1 version of the same code was part of a stable release. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
Bill Barker wrote: Tim Funk wrote: Installed 5.0.9 from exe (win2k) 1) startup.bat worked fine, but the icon which calls tomcatw.exe //GT//Tomcat5 fails will some Current Thread not owner error 2) Race conditions and connection handling in JDBCRealm - plus a whole host of other JDBCRealm bugs in Bugzilla applicable to 4 and 5. I hope early next week to have a patch which will close many of the JDBCRealm bugs. 3) Need to reinvestigate the JNDIRealm bug reopened. For the first error - I am sure I just need to look through bugzilla, or the archives and just need to add something to the README. (User error) This works for me, Bill, and presumably others. There are reports on tomcatw in BZ, so it must be at least an uncommon error (given the code have stayed stable for a few releases). Even if the bug is mildly common, the old shell scripts are still there. I can put a note stating that they can be used in case the new .exe wrapper somehow fails. I'm staying by my beta rating. Again, we cannot continue releasing alphas just because there could be some non obvious bugs in the build. In the current system, the period before the vote is meant to check if there are no showstoppers. If the build is mostly clean, it must be a beta, otherwise, it merely delays wider testing and finding bugs, which is *bad*. Ok. I'm willing to vote for a (weak) Beta in exchange for a release-note that Tomcat doesn't implement the current-draft's Authentication requirements. What is your plan, BTW ? Wait a bit more for the deadline to see what the final specification will say ? (IMO, the old auth matching rules were not very good) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, August 25, 2003 12:32 AM Subject: Re: [VOTE] 5.0.9 stability rating Bill Barker wrote: Tim Funk wrote: Installed 5.0.9 from exe (win2k) 1) startup.bat worked fine, but the icon which calls tomcatw.exe //GT//Tomcat5 fails will some Current Thread not owner error 2) Race conditions and connection handling in JDBCRealm - plus a whole host of other JDBCRealm bugs in Bugzilla applicable to 4 and 5. I hope early next week to have a patch which will close many of the JDBCRealm bugs. 3) Need to reinvestigate the JNDIRealm bug reopened. For the first error - I am sure I just need to look through bugzilla, or the archives and just need to add something to the README. (User error) This works for me, Bill, and presumably others. There are reports on tomcatw in BZ, so it must be at least an uncommon error (given the code have stayed stable for a few releases). Even if the bug is mildly common, the old shell scripts are still there. I can put a note stating that they can be used in case the new .exe wrapper somehow fails. I'm staying by my beta rating. Again, we cannot continue releasing alphas just because there could be some non obvious bugs in the build. In the current system, the period before the vote is meant to check if there are no showstoppers. If the build is mostly clean, it must be a beta, otherwise, it merely delays wider testing and finding bugs, which is *bad*. Ok. I'm willing to vote for a (weak) Beta in exchange for a release-note that Tomcat doesn't implement the current-draft's Authentication requirements. What is your plan, BTW ? Wait a bit more for the deadline to see what the final specification will say ? (IMO, the old auth matching rules were not very good) I was hoping for a pfd4, but it doesn't look like it's coming out anytime soon :-(. It's a pretty big change to conform to pfd3 (which is a completely nonsensical requirement :), so I was playing the wait-and-see game. Of course, I'm more than happy to do the grunt work to bring Tomcat into compliance with pfd3. However, if the spec changes to something sensible, then that means two big (e.g. changing interfaces in o.a.c) API changes. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
Bill Barker wrote: - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, August 25, 2003 12:32 AM Subject: Re: [VOTE] 5.0.9 stability rating Bill Barker wrote: Tim Funk wrote: Installed 5.0.9 from exe (win2k) 1) startup.bat worked fine, but the icon which calls tomcatw.exe //GT//Tomcat5 fails will some Current Thread not owner error 2) Race conditions and connection handling in JDBCRealm - plus a whole host of other JDBCRealm bugs in Bugzilla applicable to 4 and 5. I hope early next week to have a patch which will close many of the JDBCRealm bugs. 3) Need to reinvestigate the JNDIRealm bug reopened. For the first error - I am sure I just need to look through bugzilla, or the archives and just need to add something to the README. (User error) This works for me, Bill, and presumably others. There are reports on tomcatw in BZ, so it must be at least an uncommon error (given the code have stayed stable for a few releases). Even if the bug is mildly common, the old shell scripts are still there. I can put a note stating that they can be used in case the new .exe wrapper somehow fails. I'm staying by my beta rating. Again, we cannot continue releasing alphas just because there could be some non obvious bugs in the build. In the current system, the period before the vote is meant to check if there are no showstoppers. If the build is mostly clean, it must be a beta, otherwise, it merely delays wider testing and finding bugs, which is *bad*. Ok. I'm willing to vote for a (weak) Beta in exchange for a release-note that Tomcat doesn't implement the current-draft's Authentication requirements. What is your plan, BTW ? Wait a bit more for the deadline to see what the final specification will say ? (IMO, the old auth matching rules were not very good) I was hoping for a pfd4, but it doesn't look like it's coming out anytime soon :-(. It's a pretty big change to conform to pfd3 (which is a completely nonsensical requirement :), so I was playing the wait-and-see game. Of course, I'm more than happy to do the grunt work to bring Tomcat into compliance with pfd3. However, if the spec changes to something sensible, then that means two big (e.g. changing interfaces in o.a.c) API changes. The spec should'nt change now. I don't really understand why you think we aren't complinat right nowI tough your last change was to bring back compatibility with PFD 3. Do you have an example I can use to demonstrate the problem? Thanks, -- Jeanfrancois Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - 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: [VOTE] 5.0.9 stability rating
Howdy, ballot [ ] Alpha [ X ] Beta /ballot I don't think it really matters, except I'd like to say Beta to get more users to download and test it. I think we've reached the point where more user testing of the 5.0.x branch is highly desirable. Yoav Shapira 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]
Re: [VOTE] 5.0.9 stability rating
Bill Barker wrote: I was hoping for a pfd4, but it doesn't look like it's coming out anytime soon :-(. It's a pretty big change to conform to pfd3 (which is a completely nonsensical requirement :), so I was playing the wait-and-see game. Of course, I'm more than happy to do the grunt work to bring Tomcat into compliance with pfd3. However, if the spec changes to something sensible, then that means two big (e.g. changing interfaces in o.a.c) API changes. I vote don't bother, and wait for a more finalized version :) However, I think you'll agree that we can't wait until that happens to release a beta. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
Shapira, Yoav wrote: Howdy, ballot [ ] Alpha [ X ] Beta /ballot I don't think it really matters, except I'd like to say Beta to get more users to download and test it. I think we've reached the point where more user testing of the 5.0.x branch is highly desirable. Ok, so there are more people in favor of a beta than people against. This seems logical to me, and the build looks decent enough (the Tomcat 5 alphas seem to be d/led quite a bit already, and the last time there was a major problem in one build - the IAE compling some JSPs - we heard about it quite a bit in BZ). I plan to announce the beta tomorrow (wednesday). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
1) The admin webapp lies about Connector properties. I'll update the mbean-descriptor.xml and admin page for Connector soon. Amy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] 5.0.9 stability rating
On Mon, 25 Aug 2003, Shapira, Yoav wrote: I don't think it really matters, except I'd like to say Beta to get more users to download and test it. I think we've reached the point where more user testing of the 5.0.x branch is highly desirable. On an unnamed blog the attitude was exactly that: I won't download anymore until that thing is beta. Since I'm not fully aware of Apache's definition of 'beta' (or even 'voter') I don't vote. Matthias -- Matthias Ernst Software Engineer CoreMedia - Smart Content Technology - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
Amy Roh wrote: 1) The admin webapp lies about Connector properties. I'll update the mbean-descriptor.xml and admin page for Connector soon. Thanks. Sorry for the trouble. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
- Original Message - From: Jean-Francois Arcand [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, August 25, 2003 6:20 AM Subject: Re: [VOTE] 5.0.9 stability rating Bill Barker wrote: - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, August 25, 2003 12:32 AM Subject: Re: [VOTE] 5.0.9 stability rating Bill Barker wrote: Tim Funk wrote: Installed 5.0.9 from exe (win2k) 1) startup.bat worked fine, but the icon which calls tomcatw.exe //GT//Tomcat5 fails will some Current Thread not owner error 2) Race conditions and connection handling in JDBCRealm - plus a whole host of other JDBCRealm bugs in Bugzilla applicable to 4 and 5. I hope early next week to have a patch which will close many of the JDBCRealm bugs. 3) Need to reinvestigate the JNDIRealm bug reopened. For the first error - I am sure I just need to look through bugzilla, or the archives and just need to add something to the README. (User error) This works for me, Bill, and presumably others. There are reports on tomcatw in BZ, so it must be at least an uncommon error (given the code have stayed stable for a few releases). Even if the bug is mildly common, the old shell scripts are still there. I can put a note stating that they can be used in case the new .exe wrapper somehow fails. I'm staying by my beta rating. Again, we cannot continue releasing alphas just because there could be some non obvious bugs in the build. In the current system, the period before the vote is meant to check if there are no showstoppers. If the build is mostly clean, it must be a beta, otherwise, it merely delays wider testing and finding bugs, which is *bad*. Ok. I'm willing to vote for a (weak) Beta in exchange for a release-note that Tomcat doesn't implement the current-draft's Authentication requirements. What is your plan, BTW ? Wait a bit more for the deadline to see what the final specification will say ? (IMO, the old auth matching rules were not very good) I was hoping for a pfd4, but it doesn't look like it's coming out anytime soon :-(. It's a pretty big change to conform to pfd3 (which is a completely nonsensical requirement :), so I was playing the wait-and-see game. Of course, I'm more than happy to do the grunt work to bring Tomcat into compliance with pfd3. However, if the spec changes to something sensible, then that means two big (e.g. changing interfaces in o.a.c) API changes. The spec should'nt change now. I don't really understand why you think we aren't complinat right nowI tough your last change was to bring back compatibility with PFD 3. Do you have an example I can use to demonstrate the problem? Thanks, The following doesn't work correctly according to pfd3: security-constraint web-resource-collection url-pattern/*/url-pattern /web-resource-collection auth-constraint role-name*/role-name /auth-constraint /security-constraint security-constraint web-resource-collection url-pattern/product1/*/url-pattern /web-resource-collection auth-constraint role-nameproduct1/role-name /auth-constraint /security-constraint security-constraint web-resource-collection url-pattern/product2/*/url-pattern /web-resource-collection auth-constraint role-nameproduct2/role-name /auth-constraint /security-constraint With Tomcat, you need role 'product1' to access /myapp/product1, role 'product2' to access /myapp/product2, and must be authenticated to access anything else. The correct behavior is that any authenticated user can access anything. -- Jeanfrancois Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
Re: [VOTE] 5.0.9 stability rating
Bill Barker wrote: - Original Message - From: Jean-Francois Arcand [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, August 25, 2003 6:20 AM Subject: Re: [VOTE] 5.0.9 stability rating Bill Barker wrote: - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, August 25, 2003 12:32 AM Subject: Re: [VOTE] 5.0.9 stability rating Bill Barker wrote: Tim Funk wrote: Installed 5.0.9 from exe (win2k) 1) startup.bat worked fine, but the icon which calls tomcatw.exe //GT//Tomcat5 fails will some Current Thread not owner error 2) Race conditions and connection handling in JDBCRealm - plus a whole host of other JDBCRealm bugs in Bugzilla applicable to 4 and 5. I hope early next week to have a patch which will close many of the JDBCRealm bugs. 3) Need to reinvestigate the JNDIRealm bug reopened. For the first error - I am sure I just need to look through bugzilla, or the archives and just need to add something to the README. (User error) This works for me, Bill, and presumably others. There are reports on tomcatw in BZ, so it must be at least an uncommon error (given the code have stayed stable for a few releases). Even if the bug is mildly common, the old shell scripts are still there. I can put a note stating that they can be used in case the new .exe wrapper somehow fails. I'm staying by my beta rating. Again, we cannot continue releasing alphas just because there could be some non obvious bugs in the build. In the current system, the period before the vote is meant to check if there are no showstoppers. If the build is mostly clean, it must be a beta, otherwise, it merely delays wider testing and finding bugs, which is *bad*. Ok. I'm willing to vote for a (weak) Beta in exchange for a release-note that Tomcat doesn't implement the current-draft's Authentication requirements. What is your plan, BTW ? Wait a bit more for the deadline to see what the final specification will say ? (IMO, the old auth matching rules were not very good) I was hoping for a pfd4, but it doesn't look like it's coming out anytime soon :-(. It's a pretty big change to conform to pfd3 (which is a completely nonsensical requirement :), so I was playing the wait-and-see game. Of course, I'm more than happy to do the grunt work to bring Tomcat into compliance with pfd3. However, if the spec changes to something sensible, then that means two big (e.g. changing interfaces in o.a.c) API changes. The spec should'nt change now. I don't really understand why you think we aren't complinat right nowI tough your last change was to bring back compatibility with PFD 3. Do you have an example I can use to demonstrate the problem? Thanks, The following doesn't work correctly according to pfd3: security-constraint web-resource-collection url-pattern/*/url-pattern /web-resource-collection auth-constraint role-name*/role-name /auth-constraint /security-constraint security-constraint web-resource-collection url-pattern/product1/*/url-pattern /web-resource-collection auth-constraint role-nameproduct1/role-name /auth-constraint /security-constraint security-constraint web-resource-collection url-pattern/product2/*/url-pattern /web-resource-collection auth-constraint role-nameproduct2/role-name /auth-constraint /security-constraint With Tomcat, you need role 'product1' to access /myapp/product1, role 'product2' to access /myapp/product2, and must be authenticated to access anything else. The correct behavior is that any authenticated user can access anything. My understanding of the spec is that is the proper behaviour (just discussed the issue with the spec lead). Having role-name equals to * doesn't means you have access to /product1/* etc. The spec will be clarified (but the required behaviour will stay the same) -- Jeanfrancois -- Jeanfrancois Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through
Re: [VOTE] 5.0.9 stability rating
- Original Message - From: Tim Funk [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Saturday, August 23, 2003 7:50 AM Subject: Re: [VOTE] 5.0.9 stability rating Installed 5.0.9 from exe (win2k) 1) startup.bat worked fine, but the icon which calls tomcatw.exe //GT//Tomcat5 fails will some Current Thread not owner error This is weird, since the Installer configures tomcatw to use the fork option. Tomcat gets run as java -classpath %CATALINA_HOME%\bin\bootstrap.jar -Xrs org.apache.catalina.startup.Bootstrap start 2) Race conditions and connection handling in JDBCRealm - plus a whole host of other JDBCRealm bugs in Bugzilla applicable to 4 and 5. I hope early next week to have a patch which will close many of the JDBCRealm bugs. 3) Need to reinvestigate the JNDIRealm bug reopened. For the first error - I am sure I just need to look through bugzilla, or the archives and just need to add something to the README. (User error) For the last 2 errors - tomcat can be considered beta or stable with the buggy JNDIRealm and JDBCRealms since the tomcat4.1 version of the same code was part of a stable release. -Tim Remy Maucherat wrote: ballot [X] Alpha [ ] Beta /ballot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
Tim Funk wrote: Installed 5.0.9 from exe (win2k) 1) startup.bat worked fine, but the icon which calls tomcatw.exe //GT//Tomcat5 fails will some Current Thread not owner error 2) Race conditions and connection handling in JDBCRealm - plus a whole host of other JDBCRealm bugs in Bugzilla applicable to 4 and 5. I hope early next week to have a patch which will close many of the JDBCRealm bugs. 3) Need to reinvestigate the JNDIRealm bug reopened. For the first error - I am sure I just need to look through bugzilla, or the archives and just need to add something to the README. (User error) This works for me, Bill, and presumably others. There are reports on tomcatw in BZ, so it must be at least an uncommon error (given the code have stayed stable for a few releases). Even if the bug is mildly common, the old shell scripts are still there. I can put a note stating that they can be used in case the new .exe wrapper somehow fails. I'm staying by my beta rating. Again, we cannot continue releasing alphas just because there could be some non obvious bugs in the build. In the current system, the period before the vote is meant to check if there are no showstoppers. If the build is mostly clean, it must be a beta, otherwise, it merely delays wider testing and finding bugs, which is *bad*. For the last 2 errors - tomcat can be considered beta or stable with the buggy JNDIRealm and JDBCRealms since the tomcat4.1 version of the same code was part of a stable release. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
Bill Barker wrote: 1) The admin webapp lies about Connector properties. Yes, I mentioned that. To be accurate, I don't think the admin webapp has ever been glitch free in any release. 2) Authorization isn't spec-compliant (I mis-read the spec when I did it). However, I heard a rumor that the spec may move closer to what Tomcat is currently doing (what's in pfd3 is pretty nonsensical :), so I haven't been in a rush to fix this. Given that the final behavior is unclear, I do not quite see how this is a major problem. If this build becomes a beta, I'll add a note about that also. We're not going to get anywhere IMO by trying to release a bug free *first* beta. For example, I don't know right now any bugs or issues I should work on, so I'm wasting my time. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
Remy Maucherat wrote: ballot [ ] Alpha [X] Beta /ballot Unlike 5.0.8, I haven't found any problems with this build, other than the two issues I mentioned. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
Installed 5.0.9 from exe (win2k) 1) startup.bat worked fine, but the icon which calls tomcatw.exe //GT//Tomcat5 fails will some Current Thread not owner error 2) Race conditions and connection handling in JDBCRealm - plus a whole host of other JDBCRealm bugs in Bugzilla applicable to 4 and 5. I hope early next week to have a patch which will close many of the JDBCRealm bugs. 3) Need to reinvestigate the JNDIRealm bug reopened. For the first error - I am sure I just need to look through bugzilla, or the archives and just need to add something to the README. (User error) For the last 2 errors - tomcat can be considered beta or stable with the buggy JNDIRealm and JDBCRealms since the tomcat4.1 version of the same code was part of a stable release. -Tim Remy Maucherat wrote: ballot [X] Alpha [ ] Beta /ballot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
Remy Maucherat wrote: ballot [ ] Alpha [X ] Beta /ballot Except for validation (which I'm still investigating (try to create smaller test case for the Xerces folks) -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, August 22, 2003 10:20 AM Subject: [VOTE] 5.0.9 stability rating ballot [ ] Alpha [X] Beta /ballot 1) The admin webapp lies about Connector properties. 2) Authorization isn't spec-compliant (I mis-read the spec when I did it). However, I heard a rumor that the spec may move closer to what Tomcat is currently doing (what's in pfd3 is pretty nonsensical :), so I haven't been in a rush to fix this. This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
