> Glad to hear I'm not the only one. :-) This is exactly the same
> problem that I've been boring the list with for weeks now.
>
> Is it just my imagination or...well, I don't want to slam on the people
> responsible for the specification--I understand it's a hard thing to get
> right--but in my mind, when you write a specification for *reading* a
> particular object/string/etc. then you are obligated at the same time to
> write the specification for *writing* that same object/string/etc. So
> if the specification mandates a getCallerPrincipal() call, then you as a
> spec. writer must at least *address* the issue of the implied
> setCallerPrincipal() call, even if it's to say, "We considered X
> approach and Y approach and realized that these won't work. Containers
> must provide a well-documented way for setting the caller principal."
> This specification (and the related Servlet specification) seem to be
> missing this symmetry all over the place.
In my opinion container should provide a well-documented + working way
to authenticate a user, so the container can then decide what
principal/roles they are.
Sadly, not well documented and certainly not fully working. Anyway, it's
part of what Servlet 2.3 should address.
arkin
>
> Cheers,
> Laird
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
