Re: Welcome to the new JSR-375 mailing list
On 05/12/2017 04:45 PM, Arjan Tijms wrote:
I understand that, and my intent is to publish javadoc corresponding to the PR draft, for exactly that reason.
My point is that we hadn't previously published the API code or javadoc. API code did exist at the time the EDR was published, but, although it existed, it was not published with the EDR, or incorporated by reference in any of the EDR materials. My assumption at the time, perhaps mistaken, was that it was therefore not part of "the EDR spec". (For that matter, I don't believe we labeled the API code prior to publishing the EDR spec, so it's not clear which version of the code would correspond to the EDR.)
For the PDR, I'd like to fix that by publishing javadoc. To that end I started looking more closely at the API code, and noticed a number of significant interfaces that were not mentioned in the text of the EDR, and had not been discussed by the EG during the time I have been spec lead. Consequently, I hadn't spent much time thinking about them, and I don't think they've been very visible in the community at large, although the NLJUG does appear to have looked at the code.
Some of those APIs may be reasonable to keep in the spec, but I don't think all of them are. On the plus side, the ones that don't stay in the API can become part of the RI, which may actually be the best status for them, as it means they'll get real world exposure to developers -- and to server vendors -- and can potentially be standardized in a follow-on JSR on the basis of real world experience.
The form, custom form, and basic authentication mechanisms are part of what I think belongs in the RI. The servlet spec already requires support for form, custom form, basic, etc. -- these seem to me to be implementations of specific authentication mechanisms, not part of an API. Not only that, but containers already have to implement those mechanisms, so it's not clear what the value is in forcing a different implementation of the same feature. I'm fine with keeping these in the RI, but the API should be reserved for general-purpose APIs, rather than implementation details of for specific mechanisms. The real value of HttpAuthenticationMechanism is to allow applications to provide their own authentication mechanisms.
It could be tricky in some platforms. For example, I'm actually not sure the WebLogic code behaves precisely that way -- it may also map user principals to roles by default. But I agree that it's good to have precision about the expected default, and that 1:1 mapping group->role seems like a good default rule.