1. jaxrs-spec@javaee.groups.io
   Date   
Re: #544: Localization & BeanValidation

Gunnar Morling
 

Hi Christian,

The default implementation basically resolves the locale by parsing the
Accept-Locale request header and resolving the locale with the highest
priority.
This seems very useful, pretty much like what could be useful within
JAX-RS itself. That selected Locale could then be used with a
specifically set up message interpolator, just as JSF defines this
integration with Bean Validation.

Out of curiosity, how is that priority be defined?

--Gunnar



2017-05-28 16:00 GMT+02:00 Christian Kaltepoth <christian@kaltepoth.de>:
Hey Pavel,

The struggle here is with the SupportedLanguagesProvider - it feels like
it should be used for something more than BV - I think it's fair to say that
if localizaiton of BV error messages is the sole purpose of such provider,
it shouldn't be introduced. And I can't think of any other sensible use
right now.

I would like to take the opportunity to describe what MVC did to support
internationalization which relates to the issue we are discussing here. As
MVC builds on top of JAX-RS, this may (or may not) be interesting for you.

For MVC we identified a few locale-dependent aspects which we had to
support:

Data type conversion as part of the data binding mechanism needs to be
locale aware. So something like @FormParam("price") BigDecimal price needs
to be parsed according to the number formatting rules of the specific
locale.
Formatting data according to locale dependent rules when rending the view
(date format / number format). This certainly isn't something relevant for
JAX-RS.
Generating binding and validation errors message in the specific language.
This is basically what we are talking about here.

To support these scenarios we defined the term "request locale" as the
locale which is used for any locale-dependent operation within the lifecycle
of a request. The request locale is resolved for each request using the
following SPI:

public interface LocaleResolver {
Locale resolveLocale(LocaleResolverContext context);
}

The default implementation basically resolves the locale by parsing the
Accept-Locale request header and resolving the locale with the highest
priority.

But developers can customize this by providing their own resolver. So if the
developer wants to support only a specific subset of locales, he could
simply create a custom resolver and match the supported locales against the
Accept-Locale header as described in Pavel's previous mail.

You can see the full SPI here:

https://github.com/mvc-spec/mvc-spec/tree/master/api/src/main/java/javax/mvc/locale

All the details are described in the MVC spec document (pages 37-38):

https://github.com/mvc-spec/mvc-spec/raw/master/spec/spec.pdf

I'm not sure if anything described here could be useful for JAX-RS. Of cause
we (the MVC EG) would be happy to see any of our APIs to be integrated into
JAX-RS.

Christian


--
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal
Re: Providers ordering

Pavel Bucek
 

Hi Christian.

Yes, you are right, that's a "typo".

Thanks for letting us know :)

Regards,
Pavel

On 29/05/2017 10:43, Christian Kaltepoth wrote:
Hi Pavel,

thanks a lot the explanation. I just had a look at the changes and it looks good.

One minor thing. One of the new paragraphs state:

  All application-supplied providers implement interfaces in the JAX-RS API and MAY be annotated with @Priority for automatic discovery purposes

I guess this should be @Provider, correct?

See: https://github.com/jax-rs/spec/commit/817c16fdf8cd8528041b7597bc19f4f7e010ec88#diff-fb6171e05eb9c78a797c6a397ac40a6cR4


Christian


2017-05-29 10:31 GMT+02:00 Pavel Bucek <pavel.bucek@...>:

FYI:

Custom providers without @Provider annotation will have priority value javax.ws.rs.Priorities.USER (value 5000).

Also, Priority(100) > Prority(500), so provider with Priority(100) will be processed before provider with Priority(500).

More details can be found in the updated spec document, see change https://github.com/jax-rs/spec/commit/817c16fdf8cd8528041b7597bc19f4f7e010ec88 .

Regards,
Pavel


On 25/05/2017 16:54, Pavel Bucek wrote:

Hi Sergey, others,

you suggest that the exception mapper would be part of MVC spec (not the implementation, so not in javax.* package but more like org.impl.something.*?). I think that checking package name is fragile concept and should be avoided if possible, not to mention that this setup would be not ideal for MVC implementations.

I believe we shouldn't introduce new annotations whenever there is a need for a marker (which, in this case, can be easily defined without it); we already do have plenty of them..

Also, note that @Priority is not use to control what is excluded. It is used accordingly to what it is supposed to be used - to sort providers. JAX-RS implementation then needs to pick single one in most occasions and it will naturally pick more important one.

Since I believe we have working proposal (backed up by the implementation), let's stick to following:

- clarify what is built-in and user-defined provider using Santiagos definition:
if it is registered using the JAX-RS API or discovered via class scanning (i.e. annotated with @Provider), then it is user-defined regardless of their physical location (library, container, etc.). Built-in ones should not be made available using those mechanisms.
- define that user-defined providers will be sorted by the @Priority with respect to existing, already defined algorithms. That means it will influence which Provider is defined only when other conditions are already applied and more than one provider is equal in terms of the defined algorithm (i.e. exception type distance for ExceptionMappers).

Described change fits well in Java EE environment, since using @Provider is quite common among other specifications thus is already natural for majority of users.

Please let us know whether you have any strong objections or suggestions how to improve proposed rules.

Thanks and regards,
Pavel


On 25/05/2017 11:30, Sergey Beryozkin wrote:
I guess that what I also suggested when we talked with Christian about @DefaultProvider - the only problem from what I understood MVC will've been already released by the time JAX-RS 2.1 gets out.

To be honest, I'm still thinking, checking the origin (package) of the mapper can work. If for ex MVC ships its ExceptionMapper it is still a built-in mapper in context of MVC, and it can be identified to be a built-in one because it will be in a javax. namespace. Such providers should get a lower priority OOB (compared to the otherwise equal competing mappers), without having to depend on @Priority.

@Priority is there to sort the providers, making sure they execute in the right order. Using it as a mechanism to exclude does not seem quite right...Though it can work...

Cheers, Sergey





--
Christian Kaltepoth
Re: Providers ordering

Christian Kaltepoth
 

Hi Pavel,

thanks a lot the explanation. I just had a look at the changes and it looks good.

One minor thing. One of the new paragraphs state:

  All application-supplied providers implement interfaces in the JAX-RS API and MAY be annotated with @Priority for automatic discovery purposes

I guess this should be @Provider, correct?

See: https://github.com/jax-rs/spec/commit/817c16fdf8cd8528041b7597bc19f4f7e010ec88#diff-fb6171e05eb9c78a797c6a397ac40a6cR4


Christian


2017-05-29 10:31 GMT+02:00 Pavel Bucek <pavel.bucek@...>:

FYI:

Custom providers without @Provider annotation will have priority value javax.ws.rs.Priorities.USER (value 5000).

Also, Priority(100) > Prority(500), so provider with Priority(100) will be processed before provider with Priority(500).

More details can be found in the updated spec document, see change https://github.com/jax-rs/spec/commit/817c16fdf8cd8528041b7597bc19f4f7e010ec88 .

Regards,
Pavel


On 25/05/2017 16:54, Pavel Bucek wrote:

Hi Sergey, others,

you suggest that the exception mapper would be part of MVC spec (not the implementation, so not in javax.* package but more like org.impl.something.*?). I think that checking package name is fragile concept and should be avoided if possible, not to mention that this setup would be not ideal for MVC implementations.

I believe we shouldn't introduce new annotations whenever there is a need for a marker (which, in this case, can be easily defined without it); we already do have plenty of them..

Also, note that @Priority is not use to control what is excluded. It is used accordingly to what it is supposed to be used - to sort providers. JAX-RS implementation then needs to pick single one in most occasions and it will naturally pick more important one.

Since I believe we have working proposal (backed up by the implementation), let's stick to following:

- clarify what is built-in and user-defined provider using Santiagos definition:
if it is registered using the JAX-RS API or discovered via class scanning (i.e. annotated with @Provider), then it is user-defined regardless of their physical location (library, container, etc.). Built-in ones should not be made available using those mechanisms.
- define that user-defined providers will be sorted by the @Priority with respect to existing, already defined algorithms. That means it will influence which Provider is defined only when other conditions are already applied and more than one provider is equal in terms of the defined algorithm (i.e. exception type distance for ExceptionMappers).

Described change fits well in Java EE environment, since using @Provider is quite common among other specifications thus is already natural for majority of users.

Please let us know whether you have any strong objections or suggestions how to improve proposed rules.

Thanks and regards,
Pavel


On 25/05/2017 11:30, Sergey Beryozkin wrote:
I guess that what I also suggested when we talked with Christian about @DefaultProvider - the only problem from what I understood MVC will've been already released by the time JAX-RS 2.1 gets out.

To be honest, I'm still thinking, checking the origin (package) of the mapper can work. If for ex MVC ships its ExceptionMapper it is still a built-in mapper in context of MVC, and it can be identified to be a built-in one because it will be in a javax. namespace. Such providers should get a lower priority OOB (compared to the otherwise equal competing mappers), without having to depend on @Priority.

@Priority is there to sort the providers, making sure they execute in the right order. Using it as a mechanism to exclude does not seem quite right...Though it can work...

Cheers, Sergey





--
Christian Kaltepoth
Re: Providers ordering

Pavel Bucek
 

FYI:

Custom providers without @Provider annotation will have priority value javax.ws.rs.Priorities.USER (value 5000).

Also, Priority(100) > Prority(500), so provider with Priority(100) will be processed before provider with Priority(500).

More details can be found in the updated spec document, see change https://github.com/jax-rs/spec/commit/817c16fdf8cd8528041b7597bc19f4f7e010ec88 .

Regards,
Pavel


On 25/05/2017 16:54, Pavel Bucek wrote:

Hi Sergey, others,

you suggest that the exception mapper would be part of MVC spec (not the implementation, so not in javax.* package but more like org.impl.something.*?). I think that checking package name is fragile concept and should be avoided if possible, not to mention that this setup would be not ideal for MVC implementations.

I believe we shouldn't introduce new annotations whenever there is a need for a marker (which, in this case, can be easily defined without it); we already do have plenty of them..

Also, note that @Priority is not use to control what is excluded. It is used accordingly to what it is supposed to be used - to sort providers. JAX-RS implementation then needs to pick single one in most occasions and it will naturally pick more important one.

Since I believe we have working proposal (backed up by the implementation), let's stick to following:

- clarify what is built-in and user-defined provider using Santiagos definition:
if it is registered using the JAX-RS API or discovered via class scanning (i.e. annotated with @Provider), then it is user-defined regardless of their physical location (library, container, etc.). Built-in ones should not be made available using those mechanisms.
- define that user-defined providers will be sorted by the @Priority with respect to existing, already defined algorithms. That means it will influence which Provider is defined only when other conditions are already applied and more than one provider is equal in terms of the defined algorithm (i.e. exception type distance for ExceptionMappers).

Described change fits well in Java EE environment, since using @Provider is quite common among other specifications thus is already natural for majority of users.

Please let us know whether you have any strong objections or suggestions how to improve proposed rules.

Thanks and regards,
Pavel


On 25/05/2017 11:30, Sergey Beryozkin wrote:
I guess that what I also suggested when we talked with Christian about @DefaultProvider - the only problem from what I understood MVC will've been already released by the time JAX-RS 2.1 gets out.

To be honest, I'm still thinking, checking the origin (package) of the mapper can work. If for ex MVC ships its ExceptionMapper it is still a built-in mapper in context of MVC, and it can be identified to be a built-in one because it will be in a javax. namespace. Such providers should get a lower priority OOB (compared to the otherwise equal competing mappers), without having to depend on @Priority.

@Priority is there to sort the providers, making sure they execute in the right order. Using it as a mechanism to exclude does not seem quite right...Though it can work...

Cheers, Sergey


Re: #544: Localization & BeanValidation

Christian Kaltepoth
 

Hey Pavel,

The struggle here is with the SupportedLanguagesProvider - it feels like it should be used for something more than BV - I think it's fair to say that if localizaiton of BV error messages is the sole purpose of such provider, it shouldn't be introduced. And I can't think of any other sensible use right now.

I would like to take the opportunity to describe what MVC did to support internationalization which relates to the issue we are discussing here. As MVC builds on top of JAX-RS, this may (or may not) be interesting for you.

For MVC we identified a few locale-dependent aspects which we had to support:
  1. Data type conversion as part of the data binding mechanism needs to be locale aware. So something like @FormParam("price") BigDecimal price needs to be parsed according to the number formatting rules of the specific locale.
  2. Formatting data according to locale dependent rules when rending the view (date format / number format). This certainly isn't something relevant for JAX-RS.
  3. Generating binding and validation errors message in the specific language. This is basically what we are talking about here.
To support these scenarios we defined the term "request locale" as the locale which is used for any locale-dependent operation within the lifecycle of a request. The request locale is resolved for each request using the following SPI:

  public interface LocaleResolver {
    Locale resolveLocale(LocaleResolverContext context);
  }

The default implementation basically resolves the locale by parsing the Accept-Locale request header and resolving the locale with the highest priority. 

But developers can customize this by providing their own resolver. So if the developer wants to support only a specific subset of locales, he could simply create a custom resolver and match the supported locales against the Accept-Locale header as described in Pavel's previous mail.

You can see the full SPI here:


All the details are described in the MVC spec document (pages 37-38):


I'm not sure if anything described here could be useful for JAX-RS. Of cause we (the MVC EG) would be happy to see any of our APIs to be integrated into JAX-RS.

Christian


--
Christian Kaltepoth
Re: Built-in proxy support in Client API?

Pavel Bucek
 

Hi Sergey,

I recall getting a requests for supporting NTLM/Kerberos and maybe one other scheme - something related to ldap..

Regards,
Pavel


On 26/05/2017 11:42, Sergey Beryozkin wrote:
Hi Pavel

While it is indeed the case there are many authentication options against the target, I wonder how many options are there when we are talking about the HTTP proxies ? I've only ever used a name and password :-).

Does anyone know if a scheme other than Basic has ever been used in practice for Proxy-Authentication ?

Thanks, Sergey

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Proxy-Authenticate 
On 26/05/17 07:06, Pavel Bucek wrote:

Hi Sergey, Andy, Dennis, all,

it would definitely make sense, but there are always issues when you need to provide credentials.

Since JAX-RS client is generally an object, which should be retained for a "long time", it doesn't make sense to have credentials stored within it (you can access multiple resources (targets) with it and they could have different security requirements. So we would need to introduce something like credentials provider / store, which would return credentials per request (based on host, port, path, ...).

Then there are multiple authentication mechanisms - which ones should we support? Basic and Digest are no-brainers, but should we have it in the API? It is already very simple to implement those using request filters. Then, when we start with security, OAuth users will start to request OAuth support (which makes perfect sense and I'd like to see it on the client), but that's completely different set of APIs...

I mean - as I mentioned - I'd be all for introducing better security support for the client. But it feels like "just another security api"; ideally, we'd just integrate with something which is already available, unfortunately that's not the case. Look around for other clients from Java EE. Supporting any security (other than certificate based / https) is rare. I would hope that separate security spec would provide guidance and ideally an API to integrate with, but that did not happen yet.

As I don't like to use the phrase "sorry, it's already too late", it almost seems that it is appropriate here.

Best regards,
Pavel


On 25/05/2017 23:48, Sergey Beryozkin wrote:
Hi Andy, Pavel

Would it make sense to consider extending the security related part of the API a bit ?
It already has some methods for setting up HTTPS the portable way.

Cheers, Sergey
On 25/05/17 22:35, Andy McCright wrote:
Hi Pavel,
 
The java properties will specify proxy host/port for the entire JVM.  Some of my customers are using JAX-RS clients in hybrid cloud environments where they may need a proxy server to access certain endpoints but not others - so they really need a per-client solution.  We can provide that per-client solution with a vendor-specific property, but then it is no longer portable.
 
I'm fine if we want to push this out to the next rev of JAX-RS though.  I think it is an important issue, but not worth holding up the spec's release.
 
Thanks,
 
Andy 


J. Andrew McCright
IBM WebSphere Development
+1 507 253 7448
TL 553-7448
andymc@...
 
 
----- Original message -----
From: "Pavel Bucek" <pavel.bucek@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: Re: [jaxrs] Built-in proxy support in Client API?
Date: Thu, May 25, 2017 3:08 PM
 

Hi Andy, Dennis,

proxy port and proxy host can be already be defined by java property (http.proxyHost and http.proxyPort).

I'm not sure whether we can add proxy auth schemes at this point - if we'd start talking about security, wouldn't make sense to add auth support for standard client invocations?

Regards,
Pavel

 
On 25/05/2017 20:36, Andy McCright wrote:
Yeah, I think that makes sense.  So maybe instead of new methods on the Client/ClientBuilder we could add the following properties to Client:
 
public static final String PROXY_HOST_PROPERTY = "javax.ws.rs.client.http.proxy.host";
public static final String PROXY_PORT_PROPERTY = "javax.ws.rs.client.http.proxy.port";
public static final String PROXY_BASIC_AUTH_USERNAME_PROPERTY = "javax.ws.rs.client.http.proxy.auth.username";
public static final String PROXY_BASIC_AUTH_PASSWORD_PROPERTY = "javax.ws.rs.client.http.proxy.auth.password";
 
 
Assuming we have consensus, do we want to add this as part of Dennis's pull request[1], or should I create a new one?
 
Thanks,
 
Andy
 
 


J. Andrew McCright
IBM WebSphere Development
+1 507 253 7448
TL 553-7448
andymc@...
 
 
----- Original message -----
From: "Dennis Kieselhorst" <deki@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: Re: [jaxrs] Built-in proxy support in Client API?
Date: Mon, May 22, 2017 2:01 AM
 

Hi Pavel,

I don't want to hijack the topic, I'm just saying that we can handle both cases in a common way.

Regards
Dennis

 
 
 
Re: Built-in proxy support in Client API?

Sergey Beryozkin
 

Hi Pavel

While it is indeed the case there are many authentication options against the target, I wonder how many options are there when we are talking about the HTTP proxies ? I've only ever used a name and password :-).

Does anyone know if a scheme other than Basic has ever been used in practice for Proxy-Authentication ?

Thanks, Sergey

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Proxy-Authenticate 

On 26/05/17 07:06, Pavel Bucek wrote:

Hi Sergey, Andy, Dennis, all,

it would definitely make sense, but there are always issues when you need to provide credentials.

Since JAX-RS client is generally an object, which should be retained for a "long time", it doesn't make sense to have credentials stored within it (you can access multiple resources (targets) with it and they could have different security requirements. So we would need to introduce something like credentials provider / store, which would return credentials per request (based on host, port, path, ...).

Then there are multiple authentication mechanisms - which ones should we support? Basic and Digest are no-brainers, but should we have it in the API? It is already very simple to implement those using request filters. Then, when we start with security, OAuth users will start to request OAuth support (which makes perfect sense and I'd like to see it on the client), but that's completely different set of APIs...

I mean - as I mentioned - I'd be all for introducing better security support for the client. But it feels like "just another security api"; ideally, we'd just integrate with something which is already available, unfortunately that's not the case. Look around for other clients from Java EE. Supporting any security (other than certificate based / https) is rare. I would hope that separate security spec would provide guidance and ideally an API to integrate with, but that did not happen yet.

As I don't like to use the phrase "sorry, it's already too late", it almost seems that it is appropriate here.

Best regards,
Pavel


On 25/05/2017 23:48, Sergey Beryozkin wrote:
Hi Andy, Pavel

Would it make sense to consider extending the security related part of the API a bit ?
It already has some methods for setting up HTTPS the portable way.

Cheers, Sergey
On 25/05/17 22:35, Andy McCright wrote:
Hi Pavel,
 
The java properties will specify proxy host/port for the entire JVM.  Some of my customers are using JAX-RS clients in hybrid cloud environments where they may need a proxy server to access certain endpoints but not others - so they really need a per-client solution.  We can provide that per-client solution with a vendor-specific property, but then it is no longer portable.
 
I'm fine if we want to push this out to the next rev of JAX-RS though.  I think it is an important issue, but not worth holding up the spec's release.
 
Thanks,
 
Andy 


J. Andrew McCright
IBM WebSphere Development
+1 507 253 7448
TL 553-7448
andymc@...
 
 
----- Original message -----
From: "Pavel Bucek" <pavel.bucek@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: Re: [jaxrs] Built-in proxy support in Client API?
Date: Thu, May 25, 2017 3:08 PM
 

Hi Andy, Dennis,

proxy port and proxy host can be already be defined by java property (http.proxyHost and http.proxyPort).

I'm not sure whether we can add proxy auth schemes at this point - if we'd start talking about security, wouldn't make sense to add auth support for standard client invocations?

Regards,
Pavel

 
On 25/05/2017 20:36, Andy McCright wrote:
Yeah, I think that makes sense.  So maybe instead of new methods on the Client/ClientBuilder we could add the following properties to Client:
 
public static final String PROXY_HOST_PROPERTY = "javax.ws.rs.client.http.proxy.host";
public static final String PROXY_PORT_PROPERTY = "javax.ws.rs.client.http.proxy.port";
public static final String PROXY_BASIC_AUTH_USERNAME_PROPERTY = "javax.ws.rs.client.http.proxy.auth.username";
public static final String PROXY_BASIC_AUTH_PASSWORD_PROPERTY = "javax.ws.rs.client.http.proxy.auth.password";
 
 
Assuming we have consensus, do we want to add this as part of Dennis's pull request[1], or should I create a new one?
 
Thanks,
 
Andy
 
 


J. Andrew McCright
IBM WebSphere Development
+1 507 253 7448
TL 553-7448
andymc@...
 
 
----- Original message -----
From: "Dennis Kieselhorst" <deki@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: Re: [jaxrs] Built-in proxy support in Client API?
Date: Mon, May 22, 2017 2:01 AM
 

Hi Pavel,

I don't want to hijack the topic, I'm just saying that we can handle both cases in a common way.

Regards
Dennis

 
 
 
Re: #544: Localization & BeanValidation

Pavel Bucek
 

On 26/05/2017 10:14, Gunnar Morling via Groups.Io wrote:
> Note that Accept-Language is a list of languages, not a single one

Ah, that's a good point, I wasn't aware of that. My feeling is that JAX-RS should select the right Locale (however that would look like), so it can apply it across all sorts of providers/services it interacts with and then pass that one to Bean Validation.

selecting a right locale might be problematic. Imagine you have two resource method, one serving orders and the other one items. Items can be returned in different set of languages than orders.

Then, if we delegate this selection to JAX-RS, we need to support it per resource method? How would SupportedLanguageProvider do that?

Also, it could be that this information is stored in a database and is even item specific. How would be that provider written then? I'm not saying it is not possible, it would bring additional complexity to something, which can be already handled (in application specific way) without providing any real benefit.

The struggle here is with the SupportedLanguagesProvider - it feels like it should be used for something more than BV - I think it's fair to say that if localizaiton of BV error messages is the sole purpose of such provider, it shouldn't be introduced. And I can't think of any other sensible use right now.

Regards,
Pavel



> one of the main motivations for doing this is to provide support for MVC

I'm not so sure about that, I think JAX-RS itself would benefit from it, too.

--Gunnar

Re: #544: Localization & BeanValidation

Gunnar Morling
 

> Note that Accept-Language is a list of languages, not a single one

Ah, that's a good point, I wasn't aware of that. My feeling is that JAX-RS should select the right Locale (however that would look like), so it can apply it across all sorts of providers/services it interacts with and then pass that one to Bean Validation.

> one of the main motivations for doing this is to provide support for MVC

I'm not so sure about that, I think JAX-RS itself would benefit from it, too.

--Gunnar
Re: Built-in proxy support in Client API?

Pavel Bucek
 

Hi Sergey, Andy, Dennis, all,

it would definitely make sense, but there are always issues when you need to provide credentials.

Since JAX-RS client is generally an object, which should be retained for a "long time", it doesn't make sense to have credentials stored within it (you can access multiple resources (targets) with it and they could have different security requirements. So we would need to introduce something like credentials provider / store, which would return credentials per request (based on host, port, path, ...).

Then there are multiple authentication mechanisms - which ones should we support? Basic and Digest are no-brainers, but should we have it in the API? It is already very simple to implement those using request filters. Then, when we start with security, OAuth users will start to request OAuth support (which makes perfect sense and I'd like to see it on the client), but that's completely different set of APIs...

I mean - as I mentioned - I'd be all for introducing better security support for the client. But it feels like "just another security api"; ideally, we'd just integrate with something which is already available, unfortunately that's not the case. Look around for other clients from Java EE. Supporting any security (other than certificate based / https) is rare. I would hope that separate security spec would provide guidance and ideally an API to integrate with, but that did not happen yet.

As I don't like to use the phrase "sorry, it's already too late", it almost seems that it is appropriate here.

Best regards,
Pavel


On 25/05/2017 23:48, Sergey Beryozkin wrote:
Hi Andy, Pavel

Would it make sense to consider extending the security related part of the API a bit ?
It already has some methods for setting up HTTPS the portable way.

Cheers, Sergey
On 25/05/17 22:35, Andy McCright wrote:
Hi Pavel,
 
The java properties will specify proxy host/port for the entire JVM.  Some of my customers are using JAX-RS clients in hybrid cloud environments where they may need a proxy server to access certain endpoints but not others - so they really need a per-client solution.  We can provide that per-client solution with a vendor-specific property, but then it is no longer portable.
 
I'm fine if we want to push this out to the next rev of JAX-RS though.  I think it is an important issue, but not worth holding up the spec's release.
 
Thanks,
 
Andy 


J. Andrew McCright
IBM WebSphere Development
+1 507 253 7448
TL 553-7448
andymc@...
 
 
----- Original message -----
From: "Pavel Bucek" <pavel.bucek@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: Re: [jaxrs] Built-in proxy support in Client API?
Date: Thu, May 25, 2017 3:08 PM
 

Hi Andy, Dennis,

proxy port and proxy host can be already be defined by java property (http.proxyHost and http.proxyPort).

I'm not sure whether we can add proxy auth schemes at this point - if we'd start talking about security, wouldn't make sense to add auth support for standard client invocations?

Regards,
Pavel

 
On 25/05/2017 20:36, Andy McCright wrote:
Yeah, I think that makes sense.  So maybe instead of new methods on the Client/ClientBuilder we could add the following properties to Client:
 
public static final String PROXY_HOST_PROPERTY = "javax.ws.rs.client.http.proxy.host";
public static final String PROXY_PORT_PROPERTY = "javax.ws.rs.client.http.proxy.port";
public static final String PROXY_BASIC_AUTH_USERNAME_PROPERTY = "javax.ws.rs.client.http.proxy.auth.username";
public static final String PROXY_BASIC_AUTH_PASSWORD_PROPERTY = "javax.ws.rs.client.http.proxy.auth.password";
 
 
Assuming we have consensus, do we want to add this as part of Dennis's pull request[1], or should I create a new one?
 
Thanks,
 
Andy
 
 


J. Andrew McCright
IBM WebSphere Development
+1 507 253 7448
TL 553-7448
andymc@...
 
 
----- Original message -----
From: "Dennis Kieselhorst" <deki@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: Re: [jaxrs] Built-in proxy support in Client API?
Date: Mon, May 22, 2017 2:01 AM
 

Hi Pavel,

I don't want to hijack the topic, I'm just saying that we can handle both cases in a common way.

Regards
Dennis

 
 
 
Re: Built-in proxy support in Client API?

Sergey Beryozkin
 

Hi Andy, Pavel

Would it make sense to consider extending the security related part of the API a bit ?
It already has some methods for setting up HTTPS the portable way.

Cheers, Sergey

On 25/05/17 22:35, Andy McCright wrote:
Hi Pavel,
 
The java properties will specify proxy host/port for the entire JVM.  Some of my customers are using JAX-RS clients in hybrid cloud environments where they may need a proxy server to access certain endpoints but not others - so they really need a per-client solution.  We can provide that per-client solution with a vendor-specific property, but then it is no longer portable.
 
I'm fine if we want to push this out to the next rev of JAX-RS though.  I think it is an important issue, but not worth holding up the spec's release.
 
Thanks,
 
Andy 


J. Andrew McCright
IBM WebSphere Development
+1 507 253 7448
TL 553-7448
andymc@...
 
 
----- Original message -----
From: "Pavel Bucek" <pavel.bucek@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: Re: [jaxrs] Built-in proxy support in Client API?
Date: Thu, May 25, 2017 3:08 PM
 

Hi Andy, Dennis,

proxy port and proxy host can be already be defined by java property (http.proxyHost and http.proxyPort).

I'm not sure whether we can add proxy auth schemes at this point - if we'd start talking about security, wouldn't make sense to add auth support for standard client invocations?

Regards,
Pavel

 
On 25/05/2017 20:36, Andy McCright wrote:
Yeah, I think that makes sense.  So maybe instead of new methods on the Client/ClientBuilder we could add the following properties to Client:
 
public static final String PROXY_HOST_PROPERTY = "javax.ws.rs.client.http.proxy.host";
public static final String PROXY_PORT_PROPERTY = "javax.ws.rs.client.http.proxy.port";
public static final String PROXY_BASIC_AUTH_USERNAME_PROPERTY = "javax.ws.rs.client.http.proxy.auth.username";
public static final String PROXY_BASIC_AUTH_PASSWORD_PROPERTY = "javax.ws.rs.client.http.proxy.auth.password";
 
 
Assuming we have consensus, do we want to add this as part of Dennis's pull request[1], or should I create a new one?
 
Thanks,
 
Andy
 
 


J. Andrew McCright
IBM WebSphere Development
+1 507 253 7448
TL 553-7448
andymc@...
 
 
----- Original message -----
From: "Dennis Kieselhorst" <deki@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: Re: [jaxrs] Built-in proxy support in Client API?
Date: Mon, May 22, 2017 2:01 AM
 

Hi Pavel,

I don't want to hijack the topic, I'm just saying that we can handle both cases in a common way.

Regards
Dennis

 
 
 
Re: Built-in proxy support in Client API?

Andy McCright
 

Hi Pavel,
 
The java properties will specify proxy host/port for the entire JVM.  Some of my customers are using JAX-RS clients in hybrid cloud environments where they may need a proxy server to access certain endpoints but not others - so they really need a per-client solution.  We can provide that per-client solution with a vendor-specific property, but then it is no longer portable.
 
I'm fine if we want to push this out to the next rev of JAX-RS though.  I think it is an important issue, but not worth holding up the spec's release.
 
Thanks,
 
Andy 


J. Andrew McCright
IBM WebSphere Development
+1 507 253 7448
TL 553-7448
andymc@...
 
 

----- Original message -----
From: "Pavel Bucek" <pavel.bucek@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: Re: [jaxrs] Built-in proxy support in Client API?
Date: Thu, May 25, 2017 3:08 PM
 

Hi Andy, Dennis,

proxy port and proxy host can be already be defined by java property (http.proxyHost and http.proxyPort).

I'm not sure whether we can add proxy auth schemes at this point - if we'd start talking about security, wouldn't make sense to add auth support for standard client invocations?

Regards,
Pavel

 
On 25/05/2017 20:36, Andy McCright wrote:
Yeah, I think that makes sense.  So maybe instead of new methods on the Client/ClientBuilder we could add the following properties to Client:
 
public static final String PROXY_HOST_PROPERTY = "javax.ws.rs.client.http.proxy.host";
public static final String PROXY_PORT_PROPERTY = "javax.ws.rs.client.http.proxy.port";
public static final String PROXY_BASIC_AUTH_USERNAME_PROPERTY = "javax.ws.rs.client.http.proxy.auth.username";
public static final String PROXY_BASIC_AUTH_PASSWORD_PROPERTY = "javax.ws.rs.client.http.proxy.auth.password";
 
 
Assuming we have consensus, do we want to add this as part of Dennis's pull request[1], or should I create a new one?
 
Thanks,
 
Andy
 
 


J. Andrew McCright
IBM WebSphere Development
+1 507 253 7448
TL 553-7448
andymc@...
 
 
----- Original message -----
From: "Dennis Kieselhorst" <deki@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: Re: [jaxrs] Built-in proxy support in Client API?
Date: Mon, May 22, 2017 2:01 AM
 

Hi Pavel,

I don't want to hijack the topic, I'm just saying that we can handle both cases in a common way.

Regards
Dennis

 
 
 
Re: Built-in proxy support in Client API?

Pavel Bucek
 

Hi Andy, Dennis,

proxy port and proxy host can be already be defined by java property (http.proxyHost and http.proxyPort).

I'm not sure whether we can add proxy auth schemes at this point - if we'd start talking about security, wouldn't make sense to add auth support for standard client invocations?

Regards,
Pavel


On 25/05/2017 20:36, Andy McCright wrote:
Yeah, I think that makes sense.  So maybe instead of new methods on the Client/ClientBuilder we could add the following properties to Client:
 
public static final String PROXY_HOST_PROPERTY = "javax.ws.rs.client.http.proxy.host";
public static final String PROXY_PORT_PROPERTY = "javax.ws.rs.client.http.proxy.port";
public static final String PROXY_BASIC_AUTH_USERNAME_PROPERTY = "javax.ws.rs.client.http.proxy.auth.username";
public static final String PROXY_BASIC_AUTH_PASSWORD_PROPERTY = "javax.ws.rs.client.http.proxy.auth.password";
 
 
Assuming we have consensus, do we want to add this as part of Dennis's pull request[1], or should I create a new one?
 
Thanks,
 
Andy
 
 


J. Andrew McCright
IBM WebSphere Development
+1 507 253 7448
TL 553-7448
andymc@...
 
 
----- Original message -----
From: "Dennis Kieselhorst" <deki@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: Re: [jaxrs] Built-in proxy support in Client API?
Date: Mon, May 22, 2017 2:01 AM
 

Hi Pavel,

I don't want to hijack the topic, I'm just saying that we can handle both cases in a common way.

Regards
Dennis

 
Re: Built-in proxy support in Client API?

Andy McCright
 

Yeah, I think that makes sense.  So maybe instead of new methods on the Client/ClientBuilder we could add the following properties to Client:
 
public static final String PROXY_HOST_PROPERTY = "javax.ws.rs.client.http.proxy.host";
public static final String PROXY_PORT_PROPERTY = "javax.ws.rs.client.http.proxy.port";
public static final String PROXY_BASIC_AUTH_USERNAME_PROPERTY = "javax.ws.rs.client.http.proxy.auth.username";
public static final String PROXY_BASIC_AUTH_PASSWORD_PROPERTY = "javax.ws.rs.client.http.proxy.auth.password";
 
 
Assuming we have consensus, do we want to add this as part of Dennis's pull request[1], or should I create a new one?
 
Thanks,
 
Andy
 
 


J. Andrew McCright
IBM WebSphere Development
+1 507 253 7448
TL 553-7448
andymc@...
 
 

----- Original message -----
From: "Dennis Kieselhorst" <deki@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: Re: [jaxrs] Built-in proxy support in Client API?
Date: Mon, May 22, 2017 2:01 AM
 

Hi Pavel,

I don't want to hijack the topic, I'm just saying that we can handle both cases in a common way.

Regards
Dennis

 
Re: CDI integration

Arjan Tijms
 

Hi,

I too would greatly love to see this happening. CDI alignment IMHO should have been -the- major theme of Java EE and unfortunately too few steps have been made towards that goal.

Kind regards,
Arjan Tijms



On Thu, May 25, 2017 at 8:04 PM, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi,

Time is quickly running out, and I guess what the plans are regarding CDI alignment. There's an open issue [1] labeled as "2.1-candidate" but it seems no work has been done on that yet.

Given the time and resource limits the EG has, I propose to simply add a note to the spec saying that "when running on a Java EE Application Server/when CDI is available, resources and providers MUST be available for CDI extensions to process it, just like if had a CDI bean defining annotation", e.g.: providers and resources are discovered by the CDI runtime like any other bean, but *they don't need to be treated as beans*. That basically ressembled the behaviour offered by trimmed archives on CDI 2.0 [2].

What we gain with that? Users could easily create an extension to make all the resources @RequestScoped, while maintaining the spec clean (further integration would need more discussion). At the moment it's not possible to do that with CDI [3] and you have to mark all your classes as @Dependent (a practice that is not so uncommon [4]) or mark CDI bean discovery "all"/"trimmed".

How do you see it? Do you think it's viable at this time?
CDI integration

Guillermo González de Agüero
 

Hi,

Time is quickly running out, and I guess what the plans are regarding CDI alignment. There's an open issue [1] labeled as "2.1-candidate" but it seems no work has been done on that yet.

Given the time and resource limits the EG has, I propose to simply add a note to the spec saying that "when running on a Java EE Application Server/when CDI is available, resources and providers MUST be available for CDI extensions to process it, just like if had a CDI bean defining annotation", e.g.: providers and resources are discovered by the CDI runtime like any other bean, but *they don't need to be treated as beans*. That basically ressembled the behaviour offered by trimmed archives on CDI 2.0 [2].

What we gain with that? Users could easily create an extension to make all the resources @RequestScoped, while maintaining the spec clean (further integration would need more discussion). At the moment it's not possible to do that with CDI [3] and you have to mark all your classes as @Dependent (a practice that is not so uncommon [4]) or mark CDI bean discovery "all"/"trimmed".

How do you see it? Do you think it's viable at this time?
Re: Providers ordering

Markus KARG
 

By annotation I mean something like "@UseThisProviderOnlyIfNonIsBuiltIn" attached to an application-provided provider (certainly with a smarter name).

 

It is unrelated to any JIRA issue. I just came into my mind as we had this requirement several times in the past, which always ended up the same: The application provided a fallback provider (just to be sure there will be one), so the potential built-in one always was skipped -- rendering the built-in useless.

 

This annotation is needed whenever an application wants to trust a particular feature to be provided, but the JAX-RS specification does not mandate this feature. Thinks of support for OAuth for example, which is optional currently, but may be mandatory in future. Applications could provide own OAuth now and markt it as "fall-back-only". Or JSON-B. etc.

 

-Markus

 

From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Santiago Pericas-Geertsen
Sent: Donnerstag, 25. Mai 2017 16:02
To: jaxrs-spec@javaee.groups.io
Subject: Re: [jaxrs] Providers ordering

 

 

On May 25, 2017, at 2:41 AM, Markus KARG <markus@...> wrote:

 

I do not see that we cannot change this. If we decide that a new, optional annotation will modify the precedence, this would be perfectly backwards compatible, as all non-annotated code will still work correctly.

 

 By an annotation you mean something like @PreferBuiltinProviders? I don’t see how that addresses the requirements outlined in JIRA 537.

 

— Santiago

 
Re: Providers ordering

Sergey Beryozkin
 

Hi Pavel

Thanks, sorry, your note re having a working implementation was not of the most major concern :-), I was only trying to imply that
well, sometimes we have to be ready to adjust our code, though I know RI has a good code :-).
Either way, as far as I'm concerned, I reckon we can probably won't have a better alternative to using @Priority

Thanks, Sergey

On 25/05/17 16:19, Pavel Bucek wrote:

Hi Sergey,

please see inline.


On 25/05/2017 17:04, Sergey Beryozkin wrote:
Hi Pavel


On 25/05/17 15:54, Pavel Bucek wrote:

Hi Sergey, others,

you suggest that the exception mapper would be part of MVC spec (not the implementation, so not in javax.* package but more like org.impl.something.*?). I think that checking package name is fragile concept and should be avoided if possible, not to mention that this setup would be not ideal for MVC implementations.

I thought that the MVC spec was shipping its own default mapper, that is way I was suggesting checking javax.*.
if it is not the case then I agree it would not work well...

I believe we shouldn't introduce new annotations whenever there is a need for a marker (which, in this case, can be easily defined without it); we already do have plenty of them..

Also, note that @Priority is not use to control what is excluded. It is used accordingly to what it is supposed to be used - to sort providers. JAX-RS implementation then needs to pick single one in most occasions and it will naturally pick more important one.
Leading to the exclusion in the end. With Filters it is obviously not the case, all of them are run.
yes, exactly.

I was trying to offer another point of view on that issue, seemed like you are suggesting that the proposal uses @Priority in a way that contradicts its purpose.


Since I believe we have working proposal (backed up by the implementation),
IMHO that should not be used to affect the discussion given that the proposal is still under the discussion ?

I'm sorry if that statement felt like something too offensive.

All I wanted to say there was "hey, this proposal does work, we know it, since we do have backing implementation. with tests. :)"

I could use the argument that says "we need to have RI implementation for anything we do propose here, because if we don't, the feature cannot be part of the spec", since we have to have everything ready for PFD, but .. it is not the case here.

let's stick to following:

- clarify what is built-in and user-defined provider using Santiagos definition:
if it is registered using the JAX-RS API or discovered via class scanning (i.e. annotated with @Provider), then it is user-defined regardless of their physical location (library, container, etc.). Built-in ones should not be made available using those mechanisms.
- define that user-defined providers will be sorted by the @Priority with respect to existing, already defined algorithms. That means it will influence which Provider is defined only when other conditions are already applied and more than one provider is equal in terms of the defined algorithm (i.e. exception type distance for ExceptionMappers).

Described change fits well in Java EE environment, since using @Provider is quite common among other specifications thus is already natural for majority of users.

Please let us know whether you have any strong objections or suggestions how to improve proposed rules.
Looks like we have no other option but to use @Priority even though it will mean @Priority is used differently when applied to exception mappers (or param converters ?). It feels wrong but I guess we don't have other options (the new annotation will do well but it is just too late for it to be introduced)

I do see it as "contextual" priority and the context is defined by the provider definition. I don't have any examples from Java EE in mind right now, but sorting something (by the priority) and then picking "the best" provider seems to be natural. Also, if a provider is a filter and filter contract defines that all filters have to be executed, then using @Priority for sorting them doesn't feel wrong. I do agree that there is a difference, but the difference is in providers declaration, not in the semantics of @Priority.

Of course, I can be wrong ;) Please let me know what do you think.

Best regards,
Pavel


Sergey


Thanks and regards,
Pavel


On 25/05/2017 11:30, Sergey Beryozkin wrote:
I guess that what I also suggested when we talked with Christian about @DefaultProvider - the only problem from what I understood MVC will've been already released by the time JAX-RS 2.1 gets out.

To be honest, I'm still thinking, checking the origin (package) of the mapper can work. If for ex MVC ships its ExceptionMapper it is still a built-in mapper in context of MVC, and it can be identified to be a built-in one because it will be in a javax. namespace. Such providers should get a lower priority OOB (compared to the otherwise equal competing mappers), without having to depend on @Priority.

@Priority is there to sort the providers, making sure they execute in the right order. Using it as a mechanism to exclude does not seem quite right...Though it can work...

Cheers, Sergey




Re: Providers ordering

Pavel Bucek
 

Hi Sergey,

please see inline.


On 25/05/2017 17:04, Sergey Beryozkin wrote:
Hi Pavel


On 25/05/17 15:54, Pavel Bucek wrote:

Hi Sergey, others,

you suggest that the exception mapper would be part of MVC spec (not the implementation, so not in javax.* package but more like org.impl.something.*?). I think that checking package name is fragile concept and should be avoided if possible, not to mention that this setup would be not ideal for MVC implementations.

I thought that the MVC spec was shipping its own default mapper, that is way I was suggesting checking javax.*.
if it is not the case then I agree it would not work well...

I believe we shouldn't introduce new annotations whenever there is a need for a marker (which, in this case, can be easily defined without it); we already do have plenty of them..

Also, note that @Priority is not use to control what is excluded. It is used accordingly to what it is supposed to be used - to sort providers. JAX-RS implementation then needs to pick single one in most occasions and it will naturally pick more important one.
Leading to the exclusion in the end. With Filters it is obviously not the case, all of them are run.
yes, exactly.

I was trying to offer another point of view on that issue, seemed like you are suggesting that the proposal uses @Priority in a way that contradicts its purpose.


Since I believe we have working proposal (backed up by the implementation),
IMHO that should not be used to affect the discussion given that the proposal is still under the discussion ?

I'm sorry if that statement felt like something too offensive.

All I wanted to say there was "hey, this proposal does work, we know it, since we do have backing implementation. with tests. :)"

I could use the argument that says "we need to have RI implementation for anything we do propose here, because if we don't, the feature cannot be part of the spec", since we have to have everything ready for PFD, but .. it is not the case here.

let's stick to following:

- clarify what is built-in and user-defined provider using Santiagos definition:
if it is registered using the JAX-RS API or discovered via class scanning (i.e. annotated with @Provider), then it is user-defined regardless of their physical location (library, container, etc.). Built-in ones should not be made available using those mechanisms.
- define that user-defined providers will be sorted by the @Priority with respect to existing, already defined algorithms. That means it will influence which Provider is defined only when other conditions are already applied and more than one provider is equal in terms of the defined algorithm (i.e. exception type distance for ExceptionMappers).

Described change fits well in Java EE environment, since using @Provider is quite common among other specifications thus is already natural for majority of users.

Please let us know whether you have any strong objections or suggestions how to improve proposed rules.
Looks like we have no other option but to use @Priority even though it will mean @Priority is used differently when applied to exception mappers (or param converters ?). It feels wrong but I guess we don't have other options (the new annotation will do well but it is just too late for it to be introduced)

I do see it as "contextual" priority and the context is defined by the provider definition. I don't have any examples from Java EE in mind right now, but sorting something (by the priority) and then picking "the best" provider seems to be natural. Also, if a provider is a filter and filter contract defines that all filters have to be executed, then using @Priority for sorting them doesn't feel wrong. I do agree that there is a difference, but the difference is in providers declaration, not in the semantics of @Priority.

Of course, I can be wrong ;) Please let me know what do you think.

Best regards,
Pavel


Sergey


Thanks and regards,
Pavel


On 25/05/2017 11:30, Sergey Beryozkin wrote:
I guess that what I also suggested when we talked with Christian about @DefaultProvider - the only problem from what I understood MVC will've been already released by the time JAX-RS 2.1 gets out.

To be honest, I'm still thinking, checking the origin (package) of the mapper can work. If for ex MVC ships its ExceptionMapper it is still a built-in mapper in context of MVC, and it can be identified to be a built-in one because it will be in a javax. namespace. Such providers should get a lower priority OOB (compared to the otherwise equal competing mappers), without having to depend on @Priority.

@Priority is there to sort the providers, making sure they execute in the right order. Using it as a mechanism to exclude does not seem quite right...Though it can work...

Cheers, Sergey



Re: Providers ordering

Sergey Beryozkin
 

Hi Santiago
On 25/05/17 15:59, Santiago Pericas-Geertsen wrote:

On May 25, 2017, at 10:40 AM, Sergey Beryozkin <sberyozkin@...> wrote:

Hi Santiago

In what other cases, apart from ensuring a mapper shipped with MVC (or other spec APIs depending on JAX-RS), we would want to support sorting two ExceptionMapper<SomeClass> ?

 That is the main use case AFICT. Any library/framework sitting on top of JAX-RS may need finer control over this. @Priority is already used for filters and interceptors, except that in this case the entire set is consider rather than just one —but there is precedence of using this annotation nonetheless.

 Conceptually, this is what I have in mind, for all providers:

 1. Gather list of candidates
 2. Filter list based on provider-specific predicate
 3. Sort resulting list based on priority
 4. Pick one or all depending on provider kind

4. states it well, I agree in the end of the day this is probably the most pragmatic solution

Cheers, Sergey

— Santiago


Cheers, Sergey
 
On 25/05/17 15:01, Santiago Pericas-Geertsen wrote:

On May 25, 2017, at 2:41 AM, Markus KARG <markus@...> wrote:

I do not see that we cannot change this. If we decide that a new, optional annotation will modify the precedence, this would be perfectly backwards compatible, as all non-annotated code will still work correctly.


 By an annotation you mean something like @PreferBuiltinProviders? I don’t see how that addresses the requirements outlined in JIRA 537.

— Santiago
201 - 220 of 266