|
Arjan Tijms
Hi, As requested by Werner, splitting this topic off from the welcome thread. The previous discussion was about the format of the URL pattern and whether Servlet did, or did not define it. As mentioned, it's at least pretty clearly defined by JACC. There's no need to fear JACC, as it's just another Java EE spec that has defined or has helped defined a couple of things in Servlet and EJB pretty well. That said, Servlet does indeed specify it too. The deployment descriptor referenced javaee:url-pattern, which is of url-patterntype. url-patterntype is defined in javaee_7.xsd as follows:
<xsd:complexType name="url-patternType"> <xsd:annotation> <xsd:documentation> The url-patternType contains the url pattern of the mapping.
It must follow the rules specified in Section 11.2 of the Servlet API Specification. This pattern is assumed to be in URL-decoded form and must not contain CR(#xD) or LF(#xA). If it contains those characters, the container must inform the developer with a descriptive error message. The container must preserve all characters including whitespaces. </xsd:documentation>
So this points back to Section 11.2 of the Servet spec, which was already mentioned. In practice the URL pattern is a very well known concept in Java EE, as it's used in Servlet mappings, Filter mappings and the @WebServlet annotation. Kind regards, Arjan Tijms
|
|
|
Arjan Tijms
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
|
|
|
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
|
|
|
Guillermo González de Agüero
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
toggle quoted messageShow quoted text
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
|
|
|
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
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
|
|
|
Arjan Tijms
Hi Will,
Thanks a lot for reconsidering this very important feature! I'm okay with tweaking the JACC language.
Your previous mail and my last response crossed each other because I was working on the PR to address the things you mentioned. If you want to accept the PR feel free to do so for the PRD, but leaving things as-is for now (i.e. not accepting the PR at this point) would also work for me.
Thanks again!
Kind regards, Arjan Tijms
On Fri, May 19, 2017 at 5:25 PM, Will Hopkins <will.hopkins@...> wrote:
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
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
|
|
|
Guillermo González de Agüero
Great to hear, Will, thanks!
Regards,
Guillermo González de Agüero
toggle quoted messageShow quoted text
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
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
|
|
|
