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 Tue, 26 Aug 2003 03:56:39 GMT

"Jean-Francois Arcand" <jfarcand@apache.org> wrote in message
news:3F4A6D08.3040501@apache.org...
>
>
> Bill Barker wrote:
>
> >----- 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.
> >
> 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: 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
> >>
> >>
> >>
> >
> >
> >
> >------------------------------------------------------------------------
> >
> >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
> >




Mime
View raw message