Actually, I've reconsidered. I'll leave it in for now, and we can consider what, if anything, to do with it after the PRD is published. I may tweak or remove some of the JACC-related language (although JACC isn't my issue with the API design).

Will

On 05/19/2017 11:08 AM, Guillermo González de Agüero wrote:

Hi,

While I understand your position, I think removing that method will be a big miss for users. It is clearly a needed feature.

In the unfortunate case that it finally has to be removed, I'd strongly vote for keeping it on the RI as an incubating API.

Given that some other useful things have been moved to the RI due to lack of consensus/time, I think Oracle should do some promotion and marketing about those features on the Glassfish blog, so that people will undertand the limitations of the API and how important is for them to test and provide feedback on those non portable features.

Lots of people (including me) try to use just the standard APIs and tend to ignore the propietary ones in order to maintain portability. Specially in this case, feedback will be needed to evolve these incubating features, and people need to be conscious about it.

This is of course not to blame spec lead work. We all know these are difficult decissions. It's just a thought I wanted to expose.

Regards,

Guillermo González de Agüero

El vie., 19 de mayo de 2017 16:49, Will Hopkins <will.hopkins@...> escribió:

Hi Arjan,

As I said on the other thread:

I feel badly about this, but I'm going to say we need to leave it out. It was added after I made clear statements that we couldn't add any more scope to the API, I'm not convinced the approach is the right one (although, equally, I'm not convinced it's wrong), and we're out of time to have the EG weigh in.

Will

On 05/19/2017 10:30 AM, Arjan Tijms wrote:

p.s.

To address some of the concerns that were raised by Will, I could make the following changes:

* Rename the method to hasCallerAccessToWebResource

* Rename the method's argument from "resource" to "urlPattern"

* Remove the overloaded method that defaults to GET, specify that if no parameters are provided for "methods" that GET is assumed. (addressing the "many methods concern somewhat)

* Clarify that all containers in Java EE are allowed to call the method

* Clarify that is the caller is not authenticated at all, and the resource is non-public a false is returned

* Clarify that Section 11.2 of the Servlet spec is meant, instead of just "the servlet spec"

Kind regards,

Arjan Tijms

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803