tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: [VOTE] 5.0.9 stability rating
Date Mon, 25 Aug 2003 18:23:38 GMT

----- Original Message -----
From: "Jean-Francois Arcand" <jfarcand@apache.org>
To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Sent: Monday, August 25, 2003 6:20 AM
Subject: Re: [VOTE] 5.0.9 stability rating


>
>
> Bill Barker wrote:
>
> >----- Original Message -----
> >From: "Remy Maucherat" <remm@apache.org>
> >To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
> >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 now....I 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-name>product1</role-name>
  </auth-constraint>
 </security-constraint>
<security-constraint>
  <web-resource-collection>
     <url-pattern>/product2/*</url-pattern>
  </web-resource-collection>
  <auth-constraint>
     <role-name>product2</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: tomcat-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >>
> >>
> >>
> >
> >
> >
> >------------------------------------------------------------------------
> >
> >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: tomcat-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>


Mime
View raw message