|
FW: [jersey/jersey] SseEventSink invokes custom WriterInterceptor with wrong type, then throws NPE (#3592)
Experts, I know this is really late to discuss, but in fact, I doubt that it was a good decision to take WriterInterceptor out of the processing chain for SSE events. In fact, today I set up a demo app and needed this, so I actually thought that this is a Jersey bug…! Is there any good technical reason that made us strip WriterInterceptor from the processing chain (see below commit)? Scenario where this is a problem: I wanted to add support for Optional<T> to demonstrate Java 8 support of JAX-RS. So I set up a WriterInterceptor which simply unwraps Optional to produce T, so all existing pre-2.1 EntityWriters for T will still work. Great. But fails with SSE! Hence, one must rewrite all WriterIntercepors if support for Optional<T> is needed with SSE. Very bad thing! Why don't we use WriterInterceptors with SSE events? Thanks -Markus
From: Pavel Bucek [mailto:notifications@...]
Sent: Montag, 26. Juni 2017 09:38
To: jersey/jersey
Cc: Markus KARG; Author
Subject: Re: [jersey/jersey] SseEventSink invokes custom WriterInterceptor with wrong type, then throws NPE (#3592) Please see this: jax-rs/spec@b4b0d91 —
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
|
Re: Proposed Final Draft -- Java 8 Implementation
A target of JAX-RS 2.1 is support for Java 8. So I wonder why still idioms of the pre-8 age are used in the API implementation instead of Java 8 idioms. For example:
default OutboundSseEvent newEvent(String data) {
if (data == null) {
throw new IllegalArgumentException("Parameter 'data' must not be null.");
}
return newEventBuilder().data(String.class, data).build();
}
This rather looks like Java 7 style, because since Java 8 this typically would be done with Objects utility:
default OutboundSseEvent newEvent(String data) {
Objects.requireNonNull(data, "Parameter 'data' must not be null.");
return newEventBuilder().data(String.class, data).build();
}
(BTW It is simply a question of style whether one would even inline the check instead of using two code lines, since requireNonNull actually is function.)
The result not only is a smaller binary but also faster execution, as less custom byte code will get created, verified and loaded. Hence the shared requireNonNull method is much earlier eligible for native compilation.
-Markus
toggle quoted messageShow quoted text
-----Original Message----- From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek Sent: Donnerstag, 22. Juni 2017 13:23 To: jaxrs-spec@javaee.groups.io Subject: [jaxrs] Proposed Final Draft Dear experts, we'd like to announce that Proposed Final Draft was published on JCP JSR 370 page [1]. I'd like to encourage you all to review provided artifacts and let us know if you have any feedback. Thanks and regards, Pavel & Santiago [1] https://jcp.org/en/jsr/detail?id=370
|
|
|
jaxrs-2_1-pfd-api.zip\javax.ws.rs-api-2.1-m09-sources.jar contains module-info.java. Is that by intention? I thought you wanted to omit that due that Java 9 not being final?
-Markus
toggle quoted messageShow quoted text
-----Original Message----- From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek Sent: Donnerstag, 22. Juni 2017 13:23 To: jaxrs-spec@javaee.groups.io Subject: [jaxrs] Proposed Final Draft Dear experts, we'd like to announce that Proposed Final Draft was published on JCP JSR 370 page [1]. I'd like to encourage you all to review provided artifacts and let us know if you have any feedback. Thanks and regards, Pavel & Santiago [1] https://jcp.org/en/jsr/detail?id=370
|
|
|
Dear experts, we'd like to announce that Proposed Final Draft was published on JCP JSR 370 page [1]. I'd like to encourage you all to review provided artifacts and let us know if you have any feedback. Thanks and regards, Pavel & Santiago [1] https://jcp.org/en/jsr/detail?id=370
|
|
|
Re: JAX-RS and @ValidateOnExecution
Gunnar Morling
2017-06-20 13:43 GMT+02:00 Pavel Bucek <pavel.bucek@oracle.com>: Hi Gunnar,
thanks for your response!
please see inline.
On 20/06/2017 13:31, Gunnar Morling via Groups.Io wrote:
2017-06-20 9:34 GMT+02:00 Pavel Bucek <pavel.bucek@oracle.com>:
Do we have BeanValidation expert here? ;) Gunnar?
I believe the implementation should skip the method validation when
@ValidateOnExecution(type = ExecutableType.NONE)
is on the method / class.
That's right. So if Jersey still is executing the validation in this
case, it seems to be a bug.
But what about when
@ValidateOnExecution(type = ExecutableType.CONSTRUCTORS)
is on the resource method? Using this on a method (as opposed to a constructor) equals to
disabling validation as the method isn't a constructor. That setting
doesn't make too much sense on a method, rather one would use
@ValidateOnExecution(type = ExecutableType.CONSTRUCTORS) on a the
class-level or within validation.xml.
So (and allow me to ask a dumb question, I just need to be extra clear on
this) if @ValidateOnExecution(CONSTRUCTORS) is declared on class level, it
enables validation ONLY for constructor and everything else shouldn't be
validated? Yes, right. The @VOE given on the class-level could be overridden by @VOE on a specific method, though. Check out the JavaDocs of @VOE for the exact overriding rules.
And by constructor I mean constructor of the annotated type, not
constructors of types which are instantiated during other class processing
(invoking a resource method).
Yes, exactly, it only applies to this type itself, not any other types referenced by it.
Thanks and regards,
Pavel
Seems like Jersey (and sorry for bringing implementation details here,
but I
believe it is relevant) was using @ValidateOnExecution only for deciding
whether to validate return value of that method. When I fixed it, other
tests are not passing and I'm not sure what should be the correct
behavior
in that case. It definitely should validate both parameter and return value
constraints, or neither, based on the @ValidateOnExecution setting.
But there's no setting for having only method return values validated
but not their parameters.
Thanks and regards,
Pavel
On 20/06/2017 07:48, Pavel Bucek wrote:
Hi Christian,
seems to be a Jersey bug.
Regards,
Pavel
On 19/06/2017 20:39, Christian Kaltepoth wrote:
Hey everyone,
I've a question regarding JAX-RS and @ValidateOnExecution. Please have a
look at the following code:
@GET
@Path("/foobar")
@ValidateOnExecution(type = ExecutableType.NONE)
public String method( @QueryParam("q") @NotNull String query ) {
return "Resource method was invoked!";
}
What is the expected outcome for a request which doesn't contain any
query
parameter and therefore violates the @NotNull constraint?
From my understanding the use of @ValidateOnExecution disables
validation
and therefore the resource method must be called even if there is no
query
parameter in the request URL. That's how RESTEasy handles this case.
But Jersey seems to completely ignore the @ValidateOnExecution annotation
in
this example. Therefore Jersey validates the query parameter and returns
"400 Bad Request" without invoking the resource method.
Any thoughts on this?
Christian
--
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal
|
|
|
Re: JAX-RS and @ValidateOnExecution
Hi Gunnar, thanks for your response! please see inline. On 20/06/2017 13:31, Gunnar Morling via Groups.Io wrote: 2017-06-20 9:34 GMT+02:00 Pavel Bucek <pavel.bucek@oracle.com>:
Do we have BeanValidation expert here? ;) Gunnar?
I believe the implementation should skip the method validation when
@ValidateOnExecution(type = ExecutableType.NONE)
is on the method / class. That's right. So if Jersey still is executing the validation in this
case, it seems to be a bug.
But what about when
@ValidateOnExecution(type = ExecutableType.CONSTRUCTORS)
is on the resource method? Using this on a method (as opposed to a constructor) equals to
disabling validation as the method isn't a constructor. That setting
doesn't make too much sense on a method, rather one would use
@ValidateOnExecution(type = ExecutableType.CONSTRUCTORS) on a the
class-level or within validation.xml. So (and allow me to ask a dumb question, I just need to be extra clear on this) if @ValidateOnExecution(CONSTRUCTORS) is declared on class level, it enables validation ONLY for constructor and everything else shouldn't be validated? And by constructor I mean constructor of the annotated type, not constructors of types which are instantiated during other class processing (invoking a resource method). Thanks and regards, Pavel Seems like Jersey (and sorry for bringing implementation details here, but I
believe it is relevant) was using @ValidateOnExecution only for deciding
whether to validate return value of that method. When I fixed it, other
tests are not passing and I'm not sure what should be the correct behavior
in that case. It definitely should validate both parameter and return value
constraints, or neither, based on the @ValidateOnExecution setting.
But there's no setting for having only method return values validated
but not their parameters.
Thanks and regards,
Pavel
On 20/06/2017 07:48, Pavel Bucek wrote:
Hi Christian,
seems to be a Jersey bug.
Regards,
Pavel
On 19/06/2017 20:39, Christian Kaltepoth wrote:
Hey everyone,
I've a question regarding JAX-RS and @ValidateOnExecution. Please have a
look at the following code:
@GET
@Path("/foobar")
@ValidateOnExecution(type = ExecutableType.NONE)
public String method( @QueryParam("q") @NotNull String query ) {
return "Resource method was invoked!";
}
What is the expected outcome for a request which doesn't contain any query
parameter and therefore violates the @NotNull constraint?
From my understanding the use of @ValidateOnExecution disables validation
and therefore the resource method must be called even if there is no query
parameter in the request URL. That's how RESTEasy handles this case.
But Jersey seems to completely ignore the @ValidateOnExecution annotation in
this example. Therefore Jersey validates the query parameter and returns
"400 Bad Request" without invoking the resource method.
Any thoughts on this?
Christian
--
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal
|
|
|
Re: JAX-RS and @ValidateOnExecution
Gunnar Morling
2017-06-20 9:34 GMT+02:00 Pavel Bucek <pavel.bucek@oracle.com>: Do we have BeanValidation expert here? ;) Gunnar?
I believe the implementation should skip the method validation when
@ValidateOnExecution(type = ExecutableType.NONE)
is on the method / class. That's right. So if Jersey still is executing the validation in this case, it seems to be a bug. But what about when
@ValidateOnExecution(type = ExecutableType.CONSTRUCTORS)
is on the resource method? Using this on a method (as opposed to a constructor) equals to disabling validation as the method isn't a constructor. That setting doesn't make too much sense on a method, rather one would use @ValidateOnExecution(type = ExecutableType.CONSTRUCTORS) on a the class-level or within validation.xml.
Seems like Jersey (and sorry for bringing implementation details here, but I
believe it is relevant) was using @ValidateOnExecution only for deciding
whether to validate return value of that method. When I fixed it, other
tests are not passing and I'm not sure what should be the correct behavior
in that case.
It definitely should validate both parameter and return value constraints, or neither, based on the @ValidateOnExecution setting. But there's no setting for having only method return values validated but not their parameters.
Thanks and regards,
Pavel
On 20/06/2017 07:48, Pavel Bucek wrote:
Hi Christian,
seems to be a Jersey bug.
Regards,
Pavel
On 19/06/2017 20:39, Christian Kaltepoth wrote:
Hey everyone,
I've a question regarding JAX-RS and @ValidateOnExecution. Please have a
look at the following code:
@GET
@Path("/foobar")
@ValidateOnExecution(type = ExecutableType.NONE)
public String method( @QueryParam("q") @NotNull String query ) {
return "Resource method was invoked!";
}
What is the expected outcome for a request which doesn't contain any query
parameter and therefore violates the @NotNull constraint?
From my understanding the use of @ValidateOnExecution disables validation
and therefore the resource method must be called even if there is no query
parameter in the request URL. That's how RESTEasy handles this case.
But Jersey seems to completely ignore the @ValidateOnExecution annotation in
this example. Therefore Jersey validates the query parameter and returns
"400 Bad Request" without invoking the resource method.
Any thoughts on this?
Christian
--
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal
|
|
|
Re: JAX-RS and @ValidateOnExecution
Sergey,
I agree that disabling validation using @ValidateOnExecution is some kind of "special case".
However, the JAX-RS spec explicitly mentions that getter methods aren't validated by default according to the BV spec. Therefore the JAX-RS spec mentions that you can use @ValidateOnExecution to enable validation for such methods.
Christian
Thanks, see it now...
Sergey
On 20/06/17 11:47, Ivar Grimstad wrote:
Hi,
We still want Bean Validation, but we don't want the JAX-RS
runtime to do the validation for us as this will be handled by
the MVC implementation and provided for the application
developer in the for of a BindingResult CDI bean. Which will
allow the application developer to decide what should happen
in that particular case.
Ivar
On Tue, Jun 20, 2017 at 12:30 PM Sergey
Beryozkin < sberyozkin@...>
wrote:
Hi
Thanks for the explanation, though I'm still not
sure why removing @NotNull can not achieve the same
goal ? The controller method will get the control,
check for null/etc ? @NotNull is the 'message' to a
the JAX-RS runtime it needs to validate,
ValidateOnExecution(NONE) sends the message, no,
don't validate, so hence I was curious why get the
runtime deal with ValidateOnExecution if removing
@NotNull works...
Sorry I most likely have got confused....
Cheers, Sergey
On
20/06/17 10:50, Ivar Grimstad wrote:
One use case for this is to allow for
more fine-grained exception handling. As in the
case of MVC 1.0 we want to allow the controller
methods to be handling exceptions in the cases
where the catch-all handling of JAX-RS is not a
great fit.
Ivar
On Tue, Jun 20, 2017 at 11:43
AM Sergey Beryozkin < sberyozkin@...>
wrote:
Sorry,
I was referring to
@ValidateOnException...
On 20/06/17 10:41, Sergey Beryozkin
wrote:
Hi
Pavel, All
CXF ignores this validation completely
which is probably not makes its
BeanVal code very pure (I'll have a
look at the code though), but
just out of curiosity, what is the
practical point of adding a @NotNull
(and some other) BeanVal annotations
and then canceling it with the other
annotation ?
If the validation is not needed then
wouldn't it be cleaner to remove
@NotNull ?
Cheers, Sergey
On 20/06/17 08:34, Pavel Bucek wrote:
Do we have
BeanValidation expert here? ;) Gunnar?
I believe the implementation should
skip the method validation when
@ValidateOnExecution(type = ExecutableType.NONE)
is on the method / class. But what
about when
@ValidateOnExecution(type = ExecutableType.CONSTRUCTORS)
is on the resource method?
Seems like Jersey (and sorry for
bringing implementation details here,
but I believe it is relevant) was
using @ValidateOnExecution
only for deciding whether to validate
return value of that method. When I
fixed it, other tests are not passing
and I'm not sure what should be the
correct behavior in that case.
Thanks and regards,
Pavel
On
20/06/2017 07:48, Pavel Bucek wrote:
Hi Christian,
seems to be a Jersey bug.
Regards,
Pavel
On
19/06/2017 20:39, Christian
Kaltepoth wrote:
Hey everyone,
I've a question regarding
JAX-RS and @ValidateOnExecution.
Please have a look at the
following code:
@GET
@ValidateOnExecution(type
= ExecutableType.NONE)
public String
method( @QueryParam("q")
@NotNull String query ) {
return
"Resource method was
invoked!";
}
What is the expected
outcome for a request which
doesn't contain any query
parameter and therefore
violates the @NotNull
constraint?
From my understanding the
use of @ValidateOnExecution
disables validation and
therefore the resource method
must be called even if there
is no query parameter in the
request URL. That's how
RESTEasy handles this case.
But Jersey seems to
completely ignore the @ValidateOnExecution annotation
in this example. Therefore
Jersey validates the query
parameter and returns "400 Bad
Request" without invoking the
resource method.
Any thoughts on this?
Christian
--
Java Champion, JCP EC/EG Member,
JUG Leader
--
Java Champion, JCP EC/EG Member, JUG Leader
|
|
|
Re: JAX-RS and @ValidateOnExecution
Thanks, see it now...
Sergey
toggle quoted messageShow quoted text
On 20/06/17 11:47, Ivar Grimstad wrote:
Hi,
We still want Bean Validation, but we don't want the JAX-RS
runtime to do the validation for us as this will be handled by
the MVC implementation and provided for the application
developer in the for of a BindingResult CDI bean. Which will
allow the application developer to decide what should happen
in that particular case.
Ivar
On Tue, Jun 20, 2017 at 12:30 PM Sergey
Beryozkin < sberyozkin@...>
wrote:
Hi
Thanks for the explanation, though I'm still not
sure why removing @NotNull can not achieve the same
goal ? The controller method will get the control,
check for null/etc ? @NotNull is the 'message' to a
the JAX-RS runtime it needs to validate,
ValidateOnExecution(NONE) sends the message, no,
don't validate, so hence I was curious why get the
runtime deal with ValidateOnExecution if removing
@NotNull works...
Sorry I most likely have got confused....
Cheers, Sergey
On
20/06/17 10:50, Ivar Grimstad wrote:
One use case for this is to allow for
more fine-grained exception handling. As in the
case of MVC 1.0 we want to allow the controller
methods to be handling exceptions in the cases
where the catch-all handling of JAX-RS is not a
great fit.
Ivar
On Tue, Jun 20, 2017 at 11:43
AM Sergey Beryozkin < sberyozkin@...>
wrote:
Sorry,
I was referring to
@ValidateOnException...
On 20/06/17 10:41, Sergey Beryozkin
wrote:
Hi
Pavel, All
CXF ignores this validation completely
which is probably not makes its
BeanVal code very pure (I'll have a
look at the code though), but
just out of curiosity, what is the
practical point of adding a @NotNull
(and some other) BeanVal annotations
and then canceling it with the other
annotation ?
If the validation is not needed then
wouldn't it be cleaner to remove
@NotNull ?
Cheers, Sergey
On 20/06/17 08:34, Pavel Bucek wrote:
Do we have
BeanValidation expert here? ;) Gunnar?
I believe the implementation should
skip the method validation when
@ValidateOnExecution(type = ExecutableType.NONE)
is on the method / class. But what
about when
@ValidateOnExecution(type = ExecutableType.CONSTRUCTORS)
is on the resource method?
Seems like Jersey (and sorry for
bringing implementation details here,
but I believe it is relevant) was
using @ValidateOnExecution
only for deciding whether to validate
return value of that method. When I
fixed it, other tests are not passing
and I'm not sure what should be the
correct behavior in that case.
Thanks and regards,
Pavel
On
20/06/2017 07:48, Pavel Bucek wrote:
Hi Christian,
seems to be a Jersey bug.
Regards,
Pavel
On
19/06/2017 20:39, Christian
Kaltepoth wrote:
Hey everyone,
I've a question regarding
JAX-RS and @ValidateOnExecution.
Please have a look at the
following code:
@GET
@ValidateOnExecution(type
= ExecutableType.NONE)
public String
method( @QueryParam("q")
@NotNull String query ) {
return
"Resource method was
invoked!";
}
What is the expected
outcome for a request which
doesn't contain any query
parameter and therefore
violates the @NotNull
constraint?
From my understanding the
use of @ValidateOnExecution
disables validation and
therefore the resource method
must be called even if there
is no query parameter in the
request URL. That's how
RESTEasy handles this case.
But Jersey seems to
completely ignore the @ValidateOnExecution annotation
in this example. Therefore
Jersey validates the query
parameter and returns "400 Bad
Request" without invoking the
resource method.
Any thoughts on this?
Christian
--
Java Champion, JCP EC/EG Member,
JUG Leader
--
Java Champion, JCP EC/EG Member, JUG Leader
|
|
|
Re: JAX-RS and @ValidateOnExecution
Ivar Grimstad
Hi,
We still want Bean Validation, but we don't want the JAX-RS runtime to do the validation for us as this will be handled by the MVC implementation and provided for the application developer in the for of a BindingResult CDI bean. Which will allow the application developer to decide what should happen in that particular case.
On Tue, Jun 20, 2017 at 12:30 PM Sergey Beryozkin < sberyozkin@...> wrote:
Hi
Thanks for the explanation, though I'm still not sure why removing
@NotNull can not achieve the same goal ? The controller method
will get the control, check for null/etc ? @NotNull is the
'message' to a the JAX-RS runtime it needs to validate,
ValidateOnExecution(NONE) sends the message, no, don't validate,
so hence I was curious why get the runtime deal with
ValidateOnExecution if removing @NotNull works...
Sorry I most likely have got confused....
Cheers, Sergey
On 20/06/17 10:50, Ivar Grimstad wrote:
One use case for this is to allow for more
fine-grained exception handling. As in the case of MVC 1.0 we
want to allow the controller methods to be handling exceptions
in the cases where the catch-all handling of JAX-RS is not a
great fit.
Ivar
On Tue, Jun 20, 2017 at 11:43 AM Sergey
Beryozkin < sberyozkin@...>
wrote:
Sorry,
I was referring to @ValidateOnException...
On 20/06/17 10:41, Sergey Beryozkin wrote:
Hi
Pavel, All
CXF ignores this validation completely which is
probably not makes its BeanVal code very pure (I'll
have a look at the code though), but
just out of curiosity, what is the practical point
of adding a @NotNull (and some other) BeanVal
annotations and then canceling it with the other
annotation ?
If the validation is not needed then wouldn't it be
cleaner to remove @NotNull ?
Cheers, Sergey
On 20/06/17 08:34, Pavel Bucek wrote:
Do we have BeanValidation
expert here? ;) Gunnar?
I believe the implementation should skip the method
validation when
@ValidateOnExecution(type = ExecutableType.NONE)
is on the method / class. But what about when
@ValidateOnExecution(type = ExecutableType.CONSTRUCTORS)
is on the resource method?
Seems like Jersey (and sorry for bringing
implementation details here, but I believe it is
relevant) was using @ValidateOnExecution
only for deciding whether to validate return value
of that method. When I fixed it, other tests are not
passing and I'm not sure what should be the correct
behavior in that case.
Thanks and regards,
Pavel
On
20/06/2017 07:48, Pavel Bucek wrote:
Hi Christian,
seems to be a Jersey bug.
Regards,
Pavel
On
19/06/2017 20:39, Christian Kaltepoth wrote:
Hey everyone,
I've a question regarding JAX-RS and @ValidateOnExecution.
Please have a look at the following code:
@GET
@ValidateOnExecution(type =
ExecutableType.NONE)
public String method( @QueryParam("q")
@NotNull String query ) {
return "Resource method was invoked!";
}
What is the expected outcome for a
request which doesn't contain any query
parameter and therefore violates the
@NotNull constraint?
From my understanding the use of @ValidateOnExecution
disables validation and therefore the
resource method must be called even if there
is no query parameter in the request URL.
That's how RESTEasy handles this case.
But Jersey seems to completely ignore
the @ValidateOnExecution annotation
in this example. Therefore Jersey validates
the query parameter and returns "400 Bad
Request" without invoking the resource
method.
Any thoughts on this?
Christian
--
Java Champion, JCP EC/EG Member, JUG Leader
--
Java Champion, JCP EC/EG Member, JUG Leader
|
|
|
Re: JAX-RS and @ValidateOnExecution
Hi
Thanks for the explanation, though I'm still not sure why removing
@NotNull can not achieve the same goal ? The controller method
will get the control, check for null/etc ? @NotNull is the
'message' to a the JAX-RS runtime it needs to validate,
ValidateOnExecution(NONE) sends the message, no, don't validate,
so hence I was curious why get the runtime deal with
ValidateOnExecution if removing @NotNull works...
Sorry I most likely have got confused....
Cheers, Sergey
toggle quoted messageShow quoted text
On 20/06/17 10:50, Ivar Grimstad wrote:
One use case for this is to allow for more
fine-grained exception handling. As in the case of MVC 1.0 we
want to allow the controller methods to be handling exceptions
in the cases where the catch-all handling of JAX-RS is not a
great fit.
Ivar
On Tue, Jun 20, 2017 at 11:43 AM Sergey
Beryozkin < sberyozkin@...>
wrote:
Sorry,
I was referring to @ValidateOnException...
On 20/06/17 10:41, Sergey Beryozkin wrote:
Hi
Pavel, All
CXF ignores this validation completely which is
probably not makes its BeanVal code very pure (I'll
have a look at the code though), but
just out of curiosity, what is the practical point
of adding a @NotNull (and some other) BeanVal
annotations and then canceling it with the other
annotation ?
If the validation is not needed then wouldn't it be
cleaner to remove @NotNull ?
Cheers, Sergey
On 20/06/17 08:34, Pavel Bucek wrote:
Do we have BeanValidation
expert here? ;) Gunnar?
I believe the implementation should skip the method
validation when
@ValidateOnExecution(type = ExecutableType.NONE)
is on the method / class. But what about when
@ValidateOnExecution(type = ExecutableType.CONSTRUCTORS)
is on the resource method?
Seems like Jersey (and sorry for bringing
implementation details here, but I believe it is
relevant) was using @ValidateOnExecution
only for deciding whether to validate return value
of that method. When I fixed it, other tests are not
passing and I'm not sure what should be the correct
behavior in that case.
Thanks and regards,
Pavel
On
20/06/2017 07:48, Pavel Bucek wrote:
Hi Christian,
seems to be a Jersey bug.
Regards,
Pavel
On
19/06/2017 20:39, Christian Kaltepoth wrote:
Hey everyone,
I've a question regarding JAX-RS and @ValidateOnExecution.
Please have a look at the following code:
@GET
@ValidateOnExecution(type =
ExecutableType.NONE)
public String method( @QueryParam("q")
@NotNull String query ) {
return "Resource method was invoked!";
}
What is the expected outcome for a
request which doesn't contain any query
parameter and therefore violates the
@NotNull constraint?
From my understanding the use of @ValidateOnExecution
disables validation and therefore the
resource method must be called even if there
is no query parameter in the request URL.
That's how RESTEasy handles this case.
But Jersey seems to completely ignore
the @ValidateOnExecution annotation
in this example. Therefore Jersey validates
the query parameter and returns "400 Bad
Request" without invoking the resource
method.
Any thoughts on this?
Christian
--
Java Champion, JCP EC/EG Member, JUG Leader
|
|
|
Re: JAX-RS and @ValidateOnExecution
Ivar Grimstad
One use case for this is to allow for more fine-grained exception handling. As in the case of MVC 1.0 we want to allow the controller methods to be handling exceptions in the cases where the catch-all handling of JAX-RS is not a great fit.
Ivar
On Tue, Jun 20, 2017 at 11:43 AM Sergey Beryozkin < sberyozkin@...> wrote:
Sorry, I was referring to
@ValidateOnException...
On 20/06/17 10:41, Sergey Beryozkin wrote:
Hi Pavel, All
CXF ignores this validation completely which is probably not
makes its BeanVal code very pure (I'll have a look at the code
though), but
just out of curiosity, what is the practical point of adding a
@NotNull (and some other) BeanVal annotations and then canceling
it with the other annotation ?
If the validation is not needed then wouldn't it be cleaner to
remove @NotNull ?
Cheers, Sergey
On 20/06/17 08:34, Pavel Bucek wrote:
Do we have
BeanValidation expert here? ;) Gunnar?
I believe the implementation should skip the method validation
when
@ValidateOnExecution(type = ExecutableType.NONE)
is on the method / class. But what about when
@ValidateOnExecution(type = ExecutableType.CONSTRUCTORS)
is on the resource method?
Seems like Jersey (and sorry for bringing implementation details
here, but I believe it is relevant) was using @ValidateOnExecution only for
deciding whether to validate return value of that method. When I
fixed it, other tests are not passing and I'm not sure what
should be the correct behavior in that case.
Thanks and regards,
Pavel
On 20/06/2017 07:48, Pavel Bucek
wrote:
Hi Christian,
seems to be a Jersey bug.
Regards,
Pavel
On 19/06/2017 20:39, Christian
Kaltepoth wrote:
Hey everyone,
I've a question regarding JAX-RS and @ValidateOnExecution.
Please have a look at the following code:
@GET
@ValidateOnExecution(type = ExecutableType.NONE)
public String
method( @QueryParam("q") @NotNull String query ) {
return
"Resource method was invoked!";
}
What is the expected outcome for a request which
doesn't contain any query parameter and therefore
violates the @NotNull constraint?
From my understanding the use of @ValidateOnExecution
disables validation and therefore the resource method
must be called even if there is no query parameter in
the request URL. That's how RESTEasy handles this case.
But Jersey seems to completely ignore the @ValidateOnExecution annotation
in this example. Therefore Jersey validates the query
parameter and returns "400 Bad Request" without invoking
the resource method.
Any thoughts on this?
Christian
--
Java Champion, JCP EC/EG Member, JUG Leader
|
|
|
Re: JAX-RS and @ValidateOnExecution
Sorry, I was referring to
@ValidateOnException...
toggle quoted messageShow quoted text
On 20/06/17 10:41, Sergey Beryozkin wrote:
Hi Pavel, All
CXF ignores this validation completely which is probably not
makes its BeanVal code very pure (I'll have a look at the code
though), but
just out of curiosity, what is the practical point of adding a
@NotNull (and some other) BeanVal annotations and then canceling
it with the other annotation ?
If the validation is not needed then wouldn't it be cleaner to
remove @NotNull ?
Cheers, Sergey
On 20/06/17 08:34, Pavel Bucek wrote:
Do we have
BeanValidation expert here? ;) Gunnar?
I believe the implementation should skip the method validation
when
@ValidateOnExecution(type = ExecutableType.NONE)
is on the method / class. But what about when
@ValidateOnExecution(type = ExecutableType.CONSTRUCTORS)
is on the resource method?
Seems like Jersey (and sorry for bringing implementation details
here, but I believe it is relevant) was using @ValidateOnExecution only for
deciding whether to validate return value of that method. When I
fixed it, other tests are not passing and I'm not sure what
should be the correct behavior in that case.
Thanks and regards,
Pavel
On 20/06/2017 07:48, Pavel Bucek
wrote:
Hi Christian,
seems to be a Jersey bug.
Regards,
Pavel
On 19/06/2017 20:39, Christian
Kaltepoth wrote:
Hey everyone,
I've a question regarding JAX-RS and @ValidateOnExecution.
Please have a look at the following code:
@GET
@ValidateOnExecution(type = ExecutableType.NONE)
public String
method( @QueryParam("q") @NotNull String query ) {
return
"Resource method was invoked!";
}
What is the expected outcome for a request which
doesn't contain any query parameter and therefore
violates the @NotNull constraint?
From my understanding the use of @ValidateOnExecution
disables validation and therefore the resource method
must be called even if there is no query parameter in
the request URL. That's how RESTEasy handles this case.
But Jersey seems to completely ignore the @ValidateOnExecution annotation
in this example. Therefore Jersey validates the query
parameter and returns "400 Bad Request" without invoking
the resource method.
Any thoughts on this?
Christian
|
|
|
Re: JAX-RS and @ValidateOnExecution
Hi Pavel, All
CXF ignores this validation completely which is probably not makes
its BeanVal code very pure (I'll have a look at the code though),
but
just out of curiosity, what is the practical point of adding a
@NotNull (and some other) BeanVal annotations and then canceling
it with the other annotation ?
If the validation is not needed then wouldn't it be cleaner to
remove @NotNull ?
Cheers, Sergey
toggle quoted messageShow quoted text
On 20/06/17 08:34, Pavel Bucek wrote:
Do we have BeanValidation expert here? ;) Gunnar?
I believe the implementation should skip the method validation
when
@ValidateOnExecution(type = ExecutableType.NONE)
is on the method / class. But what about when
@ValidateOnExecution(type = ExecutableType.CONSTRUCTORS)
is on the resource method?
Seems like Jersey (and sorry for bringing implementation details
here, but I believe it is relevant) was using @ValidateOnExecution only for
deciding whether to validate return value of that method. When I
fixed it, other tests are not passing and I'm not sure what should
be the correct behavior in that case.
Thanks and regards,
Pavel
On 20/06/2017 07:48, Pavel Bucek
wrote:
Hi Christian,
seems to be a Jersey bug.
Regards,
Pavel
On 19/06/2017 20:39, Christian
Kaltepoth wrote:
Hey everyone,
I've a question regarding JAX-RS and @ValidateOnExecution.
Please have a look at the following code:
@GET
@ValidateOnExecution(type = ExecutableType.NONE)
public String
method( @QueryParam("q") @NotNull String query ) {
return
"Resource method was invoked!";
}
What is the expected outcome for a request which
doesn't contain any query parameter and therefore violates
the @NotNull constraint?
From my understanding the use of @ValidateOnExecution
disables validation and therefore the resource method must
be called even if there is no query parameter in the
request URL. That's how RESTEasy handles this case.
But Jersey seems to completely ignore the @ValidateOnExecution annotation
in this example. Therefore Jersey validates the query
parameter and returns "400 Bad Request" without invoking
the resource method.
Any thoughts on this?
Christian
|
|
|
Re: JAX-RS and @ValidateOnExecution
Do we have BeanValidation expert here? ;) Gunnar?
I believe the implementation should skip the method validation when
@ValidateOnExecution(type = ExecutableType.NONE)
is on the method / class. But what about when
@ValidateOnExecution(type = ExecutableType.CONSTRUCTORS)
is on the resource method?
Seems like Jersey (and sorry for bringing implementation details
here, but I believe it is relevant) was using @ValidateOnExecution only for
deciding whether to validate return value of that method. When I
fixed it, other tests are not passing and I'm not sure what should
be the correct behavior in that case.
Thanks and regards,
Pavel
On 20/06/2017 07:48, Pavel Bucek wrote:
Hi Christian,
seems to be a Jersey bug.
Regards,
Pavel
On 19/06/2017 20:39, Christian
Kaltepoth wrote:
Hey everyone,
I've a question regarding JAX-RS and @ValidateOnExecution.
Please have a look at the following code:
@GET
@ValidateOnExecution(type = ExecutableType.NONE)
public String
method( @QueryParam("q") @NotNull String query ) {
return "Resource
method was invoked!";
}
What is the expected outcome for a request which doesn't
contain any query parameter and therefore violates the
@NotNull constraint?
From my understanding the use of @ValidateOnExecution disables validation
and therefore the resource method must be called even if
there is no query parameter in the request URL. That's how
RESTEasy handles this case.
But Jersey seems to completely ignore the @ValidateOnExecution annotation
in this example. Therefore Jersey validates the query
parameter and returns "400 Bad Request" without invoking the
resource method.
Any thoughts on this?
Christian
|
|
|
Re: JAX-RS and @ValidateOnExecution
Hi Christian,
seems to be a Jersey bug.
Regards,
Pavel
toggle quoted messageShow quoted text
On 19/06/2017 20:39, Christian
Kaltepoth wrote:
Hey everyone,
I've a question regarding JAX-RS and @ValidateOnExecution.
Please have a look at the following code:
@GET
@ValidateOnExecution(type = ExecutableType.NONE)
public String method(
@QueryParam("q") @NotNull String query ) {
return "Resource
method was invoked!";
}
What is the expected outcome for a request which doesn't
contain any query parameter and therefore violates the
@NotNull constraint?
From my understanding the use of @ValidateOnExecution disables validation
and therefore the resource method must be called even if there
is no query parameter in the request URL. That's how RESTEasy
handles this case.
But Jersey seems to completely ignore the @ValidateOnExecution annotation
in this example. Therefore Jersey validates the query
parameter and returns "400 Bad Request" without invoking the
resource method.
Any thoughts on this?
Christian
|
|
|
JAX-RS and @ValidateOnExecution
Hey everyone,
I've a question regarding JAX-RS and @ValidateOnExecution. Please have a look at the following code:
@GET
@ValidateOnExecution(type = ExecutableType.NONE) public String method( @QueryParam("q") @NotNull String query ) { return "Resource method was invoked!"; }
What is the expected outcome for a request which doesn't contain any query parameter and therefore violates the @NotNull constraint?
From my understanding the use of @ValidateOnExecution disables validation and therefore the resource method must be called even if there is no query parameter in the request URL. That's how RESTEasy handles this case.
But Jersey seems to completely ignore the @ValidateOnExecution annotation in this example. Therefore Jersey validates the query parameter and returns "400 Bad Request" without invoking the resource method.
Any thoughts on this?
Christian
|
|
|
Re: Status of JAXB in JAX-RS 2.1
Yes I know that the target platform for Java EE 8 is Java SE 8, but what I talked about solely was the section about Java SE deployment of JAX-RS 2.1 spec, which does *not* say Java 8. So maybe we should simply say "Java SE 8" in the spec, that would be a solution? -Markus
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek
Sent: Freitag, 16. Juni 2017 21:03
To: jaxrs-spec@javaee.groups.io
Subject: Re: [jaxrs] Status of JAXB in JAX-RS 2.1 JAXB dependency cannot be declared optional, that's a fact. Even if everyone from the EG would be for that, it won't be done. Reasons were already stated on this list.
We are not going to say anything about Java 9 either, since it won't be released at the time of writing and we don't want to make any statements, which could turn either way - it may become meaning less very soon, or the message meaning could be changed by some change in the Java 9 SE.
You can check that this is consistent with other specifications, since, as you surely are aware of, the target platform for Java EE 8 is Java SE 8.
Have a nice weekend,
Pavel On 16/06/2017 19:50, Markus KARG wrote: Pavel, it seems you just have a different interpretation of the word "end user". At least I, as a car end user, do neither read the specification of pistons, nor does my car vendor add a note to the car's manual that it is the driver's obligation to look into the motor whether the pistons still work well when driving on streets built after the car had been manufactured. I am pretty sure that even oldtimers work well on latest streets without special care of the driver… ;-) Be assured that our products will come with *separate* instructions for how to run on Java SE 9 vs Java SE 8 - for a very good reason! But that's not the point. I neither want to discuss JDK / Java related issues on the JAX-RS EG list. Waht I want this EG (a group who decided to *neither* declare JAXB optional, *nor* to enable JAXB by default using module-info) is to bear the consequences of the sum of these choices: Clearly add a very short but clear note in JAX-RS 2.1's "Java SE Deployment" chapter about two simple facts: (A) JAX-RS 2.1 needs Java SE 8 or later. (B) On Java 9, the end user MUST explicitly activate all optional modules. At time of writing this at least is java.xml.bind. An implementation MAY enable these modules by default. Then everybody knows how the combination of "JAXB is *still mandatory* in this spec" and "Java SE 9 is *not forbidden* by this spec" is meant to work in field. Votes? -Markus Markus, your description of user definitely doesn't read the spec document, javadocs, etc. So what exactly would be achieved by putting a note into the spec document? My recommendation would be putting this as a warning to release notes of your product and reflect that in your documentation. If you want to discuss JDK/Java related issues, please do it elsewhere, as this is a list for JAX-RS, not Java 9 SE. (I'd recommend jdk9-dev@...). Regards,
Pavel On 16/06/2017 18:34, Markus KARG wrote: Pavel, this complete Jigsaw topic is a mess for the end user and I wonder what the OpenJDK guys wanted to reach with making JAXB optional… In reality no end user knows anything about Jigsaw (end users are not Java licencees, not even programmers, they are simply people who try to startup an application they did not have a source code for and they do not have any interest in the difference from Java 8 to Java 9 but just think "the newer the better"). What will happen in reality is that lots of end users will download JRE 9 and run JAX-RS-containing applications ontop of it and then fail. If we want to let them stand in the rain, we can go on like this. But we should be prepared about the effect… : Angry people hating us for not telling them the truth. Anyways, seems I am the only one who has a problem with the fact that our hotline soon will melt down. I hope that everybody in this EG is clear about the effects of not telling people how to run a JAX-RS 2.1 application on Java 9. Hands up please: Who in this EG thinks it is a good idea to NOT tell anybody in the specification that JAXB *is not* conditional but actually it is technically as soon as an end user replaces JRE 8 by JRE 9? I know that at least my own 10.000+ end users will kill me for this backwards-incompatibility. They don't care who broke it. It's just broken by me or Oracle in their view. -Markus Well.. the spec says nothing about running on Java 9, since Java 9 won't be final when JAX-RS 2.1 is released. When a user want's to run on Java 9, it is expected that he knows what he's doing (i.e. running on unsupported environment). There is plenty of tools provided by jdk to get this kind of information, for example jdeps: $ jdeps ~/.m2/repository/javax/ws/rs/javax.ws.rs-api/2.1-m09/javax.ws.rs-api-2.1-m09.jar
javax.ws.rs-api-2.1-m09.jar -> java.base
javax.ws.rs-api-2.1-m09.jar -> java.logging
javax.ws.rs-api-2.1-m09.jar -> java.xml
javax.ws.rs-api-2.1-m09.jar -> java.xml.bind
javax.ws.rs -> java.lang java.base
javax.ws.rs -> java.lang.annotation java.base
javax.ws.rs -> java.net java.base
javax.ws.rs -> java.util java.base
javax.ws.rs -> javax.ws.rs.core javax.ws.rs-api-2.1-m09.jar
javax.ws.rs -> javax.ws.rs.ext javax.ws.rs-api-2.1-m09.jar
javax.ws.rs.client -> java.io java.base
javax.ws.rs.client -> java.lang java.base
javax.ws.rs.client -> java.lang.annotation java.base
javax.ws.rs.client -> java.lang.invoke java.base
javax.ws.rs.client -> java.lang.reflect java.base
javax.ws.rs.client -> java.net java.base
javax.ws.rs.client -> java.security java.base
javax.ws.rs.client -> java.util java.base
javax.ws.rs.client -> java.util.concurrent java.base
javax.ws.rs.client -> java.util.logging java.logging
javax.ws.rs.client -> javax.net.ssl java.base
javax.ws.rs.client -> javax.ws.rs javax.ws.rs-api-2.1-m09.jar
javax.ws.rs.client -> javax.ws.rs.core javax.ws.rs-api-2.1-m09.jar
javax.ws.rs.container -> java.io java.base
javax.ws.rs.container -> java.lang java.base
javax.ws.rs.container -> java.lang.annotation java.base
javax.ws.rs.container -> java.lang.reflect java.base
javax.ws.rs.container -> java.net java.base
javax.ws.rs.container -> java.util java.base
javax.ws.rs.container -> java.util.concurrent java.base
javax.ws.rs.container -> javax.ws.rs.core javax.ws.rs-api-2.1-m09.jar
javax.ws.rs.core -> java.io java.base
javax.ws.rs.core -> java.lang java.base
javax.ws.rs.core -> java.lang.annotation java.base
javax.ws.rs.core -> java.lang.reflect java.base
javax.ws.rs.core -> java.net java.base
javax.ws.rs.core -> java.security java.base
javax.ws.rs.core -> java.util java.base
javax.ws.rs.core -> javax.ws.rs javax.ws.rs-api-2.1-m09.jar
javax.ws.rs.core -> javax.ws.rs.ext javax.ws.rs-api-2.1-m09.jar
javax.ws.rs.core -> javax.xml.bind.annotation java.xml.bind
javax.ws.rs.core -> javax.xml.bind.annotation.adapters java.xml.bind
javax.ws.rs.core -> javax.xml.namespace java.xml
javax.ws.rs.ext -> java.io java.base
javax.ws.rs.ext -> java.lang java.base
javax.ws.rs.ext -> java.lang.annotation java.base
javax.ws.rs.ext -> java.lang.invoke java.base
javax.ws.rs.ext -> java.lang.reflect java.base
javax.ws.rs.ext -> java.net java.base
javax.ws.rs.ext -> java.security java.base
javax.ws.rs.ext -> java.util java.base
javax.ws.rs.ext -> java.util.logging java.logging
javax.ws.rs.ext -> javax.ws.rs javax.ws.rs-api-2.1-m09.jar
javax.ws.rs.ext -> javax.ws.rs.core javax.ws.rs-api-2.1-m09.jar
javax.ws.rs.sse -> java.io java.base
javax.ws.rs.sse -> java.lang java.base
javax.ws.rs.sse -> java.lang.invoke java.base
javax.ws.rs.sse -> java.lang.reflect java.base
javax.ws.rs.sse -> java.net java.base
javax.ws.rs.sse -> java.security java.base
javax.ws.rs.sse -> java.util java.base
javax.ws.rs.sse -> java.util.concurrent java.base
javax.ws.rs.sse -> java.util.function java.base
javax.ws.rs.sse -> java.util.logging java.logging
javax.ws.rs.sse -> javax.ws.rs.client javax.ws.rs-api-2.1-m09.jar
javax.ws.rs.sse -> javax.ws.rs.core javax.ws.rs-api-2.1-m09.jar Regards,
Pavel On 16/06/2017 17:39, Markus KARG wrote: Pavel, my point is that the application *user* simply does not know that he must use --add-module when running any binary application on Java 9, as the *user* has no knowledge that JAXB is used *inside* of that (at least we as an ISV do not tell our users what APIs we use inside). So as the JAX-RS specification talks about how JAXB is handled, the user could assume that the JAX-RS implementation handles this issue "somehow magically" (like having a module-info). So *because* we decided against a "magic solution" (= module-info), it would be fair if the spec would in turn say that since there is no module-info enforced by JAX-RS, the *user* has to be informed by the application vendor when an application is making use of JAXB. How should the user know otherwise (other than trial-and-error)? -Markus that depends on how the application is ran (on Java 9). If the app is on classpath, the *user* has to --add-module java.xml.bind. Nobody can do that for him. If the app is on module path, there is another set of dependencies: requires transitive java.activation;
requires transitive java.desktop;
requires transitive java.logging;
requires transitive java.management; and maybe others. (some of those are required by Jersey (logger), some of them by JAX-RS (spec mandates that implementation has to support returning java.awt.image.RenderedImage, which is in java.desktop).
Dependency on java.xml.bind could be solved in the API jar, as suggested in the module-info:
https://github.com/jax-rs/api/blob/master/jaxrs-api/src/main/java/module-info.java
but since we agreed on not including it, it's up to the user or the implementation. (both parties can fix the issue by adding runtime switches - your statement about implementation being required to do something is not correct).
So, Markus, I'm not sure whether you are asking for something or .. ?
Regards,
Pavel On 16/06/2017 15:37, Markus KARG wrote: I do not say we should remove JAXB, I just wanted to ask because it was in the JSR 370 charter. I also do not see a big benefit of removing JAXB. The only problem I see is running JAX-RS 2.1 on Java SE 9: Due to project Jigsaw, a JRE will not allow access to JAXB unless the JVM is *explicitly* asked to grant access to JAXB. So we all should be aware what this means for the (reference) implementations: If we do *not* say JAXB is "conditional", and until an implementation *forbids* running Java 9, that implies that JAXB is still a MUST even on Java SE 9 -- so all implementations must take care to grant JAXB access. I assume that all existing implementors already fixed this…? :-) -Markus On Jun 15, 2017, at 11:30 AM, Sergey Beryozkin <sberyozkin@...> wrote: I see no practical point in doing it anyway. It's unlikely that any of the existing JAX-RS implementations will choose to annoy some of its users and just do not ship JAXB-aware providers - they will be needed for the next 10 years at least anyway even though the new services are more likely to use JSON/etc
+1
Sergey
On 15/06/17 16:31, Pavel Bucek wrote:
Hi Markus, we learned that it is not possible to do that in this release. The main issue is that we cannot just deprecate something, there is a strict policy related to making backwards incompatible changes - we'd need to create separate specification, which would replace deprecated/removed functionality. What we could do is to add a note to the JaxbLink javadoc saying "This class will be removed at some point, replaced by FOOBAR"; the problem is that we don't have FOOBAR at the moment.. Regards,
Pavel On 15/06/2017 16:31, Markus KARG wrote: the JSR 370 charter says that with JAX-RS 2.1 the JAXB technology should become conditional. Looking at the last spec draft I cannot find anything about that. Quite contrary is still is rather clear about the fact what an implementation has to do with JAXBElement etc. So I'd like to ask what to do with this issue. Will JAXB stay as it is? Or do you have plans to make it obsolete in JAX-RS 2.1 final draft?
|
|
|
Re: Status of JAXB in JAX-RS 2.1
JAXB dependency cannot be declared optional, that's a fact. Even if
everyone from the EG would be for that, it won't be done. Reasons
were already stated on this list.
We are not going to say anything about Java 9 either, since it won't
be released at the time of writing and we don't want to make any
statements, which could turn either way - it may become meaning less
very soon, or the message meaning could be changed by some change in
the Java 9 SE.
You can check that this is consistent with other specifications,
since, as you surely are aware of, the target platform for Java EE 8
is Java SE 8.
Have a nice weekend,
Pavel
toggle quoted messageShow quoted text
On 16/06/2017 19:50, Markus KARG wrote:
Pavel,
it
seems you just have a different interpretation of the word
"end user". At least I, as a car end user, do neither read
the specification of pistons, nor does my car vendor add a
note to the car's manual that it is the driver's obligation
to look into the motor whether the pistons still work well
when driving on streets built after the car had been
manufactured. I am pretty sure that even oldtimers work well
on latest streets without special care of the driver… ;-)
Be
assured that our products will come with *separate*
instructions for how to run on Java SE 9 vs Java SE 8 - for
a very good reason! But that's not the point. I neither want
to discuss JDK / Java related issues on the JAX-RS EG list.
Waht
I want this EG (a group who decided to *neither* declare
JAXB optional, *nor* to enable JAXB by default using
module-info) is to bear the consequences of the sum of these
choices: Clearly add a very short but clear note in JAX-RS
2.1's "Java SE Deployment" chapter about two simple facts:
(A)
JAX-RS 2.1 needs Java SE 8 or later.
(B)
On Java 9, the end user MUST explicitly activate all
optional modules. At time of writing this at least is
java.xml.bind. An implementation MAY enable these modules by
default.
Then
everybody knows how the combination of "JAXB is
*still mandatory* in this spec" and "Java SE 9 is *not
forbidden* by this spec" is meant to work in field.
Votes?
-Markus
Markus,
your description of user definitely doesn't read the spec
document, javadocs, etc. So what exactly would be achieved by
putting a note into the spec document?
My recommendation would be putting this as a warning to
release notes of your product and reflect that in your
documentation.
If you want to discuss JDK/Java related issues, please do it
elsewhere, as this is a list for JAX-RS, not Java 9 SE. (I'd
recommend jdk9-dev@...).
Regards,
Pavel
On 16/06/2017 18:34, Markus KARG wrote:
Pavel,
this
complete Jigsaw topic is a mess for the end user and I
wonder what the OpenJDK guys wanted to reach with making
JAXB optional… In reality no end user knows anything about
Jigsaw (end users are not Java licencees, not even
programmers, they are simply people who try to startup an
application they did not have a source code for and they
do not have any interest in the difference from Java 8 to
Java 9 but just think "the newer the better"). What will
happen in reality is that lots of end users will download
JRE 9 and run JAX-RS-containing applications ontop of it
and then fail. If we want to let them stand in the rain,
we can go on like this. But we should be prepared about
the effect… : Angry people hating us for not telling them
the truth. Anyways, seems I am the only one who has a
problem with the fact that our hotline soon will melt
down. I hope that everybody in this EG is clear about the
effects of not telling people how to run a JAX-RS 2.1
application on Java 9.
Hands
up please: Who in this EG thinks it is a good idea to NOT
tell anybody in the specification that JAXB *is not*
conditional but actually it is technically as soon as an
end user replaces JRE 8 by JRE 9?
I
know that at least my own 10.000+ end users will kill me
for this backwards-incompatibility. They don't care who
broke it. It's just broken by me or Oracle in their view.
-Markus
Well.. the spec says nothing about running on Java 9, since
Java 9 won't be final when JAX-RS 2.1 is released.
When a user want's to run on Java 9, it is expected that he
knows what he's doing (i.e. running on unsupported
environment). There is plenty of tools provided by jdk to
get this kind of information, for example jdeps:
$ jdeps
~/.m2/repository/javax/ws/rs/javax.ws.rs-api/2.1-m09/javax.ws.rs-api-2.1-m09.jar
javax.ws.rs-api-2.1-m09.jar -> java.base
javax.ws.rs-api-2.1-m09.jar -> java.logging
javax.ws.rs-api-2.1-m09.jar -> java.xml
javax.ws.rs-api-2.1-m09.jar -> java.xml.bind
javax.ws.rs
-> java.lang
java.base
javax.ws.rs
-> java.lang.annotation
java.base
javax.ws.rs
-> java.net
java.base
javax.ws.rs
-> java.util
java.base
javax.ws.rs
-> javax.ws.rs.core
javax.ws.rs-api-2.1-m09.jar
javax.ws.rs
-> javax.ws.rs.ext
javax.ws.rs-api-2.1-m09.jar
javax.ws.rs.client
-> java.io
java.base
javax.ws.rs.client
-> java.lang
java.base
javax.ws.rs.client
-> java.lang.annotation
java.base
javax.ws.rs.client
-> java.lang.invoke
java.base
javax.ws.rs.client
-> java.lang.reflect
java.base
javax.ws.rs.client
-> java.net
java.base
javax.ws.rs.client
-> java.security
java.base
javax.ws.rs.client
-> java.util
java.base
javax.ws.rs.client
-> java.util.concurrent
java.base
javax.ws.rs.client
-> java.util.logging
java.logging
javax.ws.rs.client
-> javax.net.ssl
java.base
javax.ws.rs.client
-> javax.ws.rs
javax.ws.rs-api-2.1-m09.jar
javax.ws.rs.client
-> javax.ws.rs.core
javax.ws.rs-api-2.1-m09.jar
javax.ws.rs.container
-> java.io
java.base
javax.ws.rs.container
-> java.lang
java.base
javax.ws.rs.container
-> java.lang.annotation
java.base
javax.ws.rs.container
-> java.lang.reflect
java.base
javax.ws.rs.container
-> java.net
java.base
javax.ws.rs.container
-> java.util
java.base
javax.ws.rs.container
-> java.util.concurrent
java.base
javax.ws.rs.container
-> javax.ws.rs.core
javax.ws.rs-api-2.1-m09.jar
javax.ws.rs.core
-> java.io
java.base
javax.ws.rs.core
-> java.lang
java.base
javax.ws.rs.core
-> java.lang.annotation
java.base
javax.ws.rs.core
-> java.lang.reflect
java.base
javax.ws.rs.core
-> java.net
java.base
javax.ws.rs.core
-> java.security
java.base
javax.ws.rs.core
-> java.util
java.base
javax.ws.rs.core
-> javax.ws.rs
javax.ws.rs-api-2.1-m09.jar
javax.ws.rs.core
-> javax.ws.rs.ext
javax.ws.rs-api-2.1-m09.jar
javax.ws.rs.core
-> javax.xml.bind.annotation
java.xml.bind
javax.ws.rs.core
-> javax.xml.bind.annotation.adapters
java.xml.bind
javax.ws.rs.core
-> javax.xml.namespace
java.xml
javax.ws.rs.ext
-> java.io
java.base
javax.ws.rs.ext
-> java.lang
java.base
javax.ws.rs.ext
-> java.lang.annotation
java.base
javax.ws.rs.ext
-> java.lang.invoke
java.base
javax.ws.rs.ext
-> java.lang.reflect
java.base
javax.ws.rs.ext
-> java.net
java.base
javax.ws.rs.ext
-> java.security
java.base
javax.ws.rs.ext
-> java.util
java.base
javax.ws.rs.ext
-> java.util.logging
java.logging
javax.ws.rs.ext
-> javax.ws.rs
javax.ws.rs-api-2.1-m09.jar
javax.ws.rs.ext
-> javax.ws.rs.core
javax.ws.rs-api-2.1-m09.jar
javax.ws.rs.sse
-> java.io
java.base
javax.ws.rs.sse
-> java.lang
java.base
javax.ws.rs.sse
-> java.lang.invoke
java.base
javax.ws.rs.sse
-> java.lang.reflect
java.base
javax.ws.rs.sse
-> java.net
java.base
javax.ws.rs.sse
-> java.security
java.base
javax.ws.rs.sse
-> java.util
java.base
javax.ws.rs.sse
-> java.util.concurrent
java.base
javax.ws.rs.sse
-> java.util.function
java.base
javax.ws.rs.sse
-> java.util.logging
java.logging
javax.ws.rs.sse
-> javax.ws.rs.client
javax.ws.rs-api-2.1-m09.jar
javax.ws.rs.sse
-> javax.ws.rs.core
javax.ws.rs-api-2.1-m09.jar
Regards,
Pavel
On 16/06/2017 17:39, Markus KARG wrote:
Pavel,
my
point is that the application *user* simply does not
know that he must use --add-module when running any
binary application on Java 9, as the *user* has no
knowledge that JAXB is used *inside* of that (at least
we as an ISV do not tell our users what APIs we use
inside). So as the JAX-RS specification talks about how
JAXB is handled, the user could assume that the JAX-RS
implementation handles this issue "somehow magically"
(like having a module-info). So *because* we decided
against a "magic solution" (= module-info), it would be
fair if the spec would in turn say that since there is
no module-info enforced by JAX-RS, the *user* has to be
informed by the application vendor when an application
is making use of JAXB. How should the user know
otherwise (other than trial-and-error)?
-Markus
that depends on how the application is ran (on Java 9).
If the app is on classpath, the *user* has to
--add-module java.xml.bind. Nobody can do that for him.
If the app is on module path, there is another set of
dependencies:
requires transitive java.activation;
requires transitive java.desktop;
requires transitive java.logging;
requires transitive java.management;
and maybe
others. (some of those are required by Jersey (logger),
some of them by JAX-RS (spec mandates that implementation
has to support returning java.awt.image.RenderedImage,
which is in java.desktop).
Dependency on java.xml.bind could be solved in the API
jar, as suggested in the module-info:
https://github.com/jax-rs/api/blob/master/jaxrs-api/src/main/java/module-info.java
but since we agreed on not including it, it's up to the
user or the implementation. (both parties can fix the
issue by adding runtime switches - your statement about
implementation being required to do something is not
correct).
So, Markus, I'm not sure whether you are asking for
something or .. ?
Regards,
Pavel
On 16/06/2017 15:37, Markus KARG
wrote:
I
do not say we should remove JAXB, I just wanted to ask
because it was in the JSR 370 charter. I also do not
see a big benefit of removing JAXB. The only problem I
see is running JAX-RS 2.1 on Java SE 9: Due to project
Jigsaw, a JRE will not allow access to JAXB unless the
JVM is *explicitly* asked to grant access to JAXB. So
we all should be aware what this means for the
(reference) implementations: If we do *not* say JAXB
is "conditional", and until an implementation
*forbids* running Java 9, that implies that JAXB is
still a MUST even on Java SE 9 -- so all
implementations must take care to grant JAXB access. I
assume that all existing implementors already fixed
this…? :-)
-Markus
On Jun 15, 2017, at 11:30 AM,
Sergey Beryozkin <sberyozkin@...>
wrote:
I see no practical
point in doing it anyway. It's unlikely that
any of the existing JAX-RS implementations
will choose to annoy some of its users and
just do not ship JAXB-aware providers - they
will be needed for the next 10 years at least
anyway even though the new services are more
likely to use JSON/etc
+1
Sergey
On 15/06/17 16:31, Pavel Bucek wrote:
Hi Markus,
we learned that it is
not possible to do that in this release.
The main issue is that
we cannot just deprecate something, there is a
strict policy related to making backwards
incompatible changes - we'd need to create
separate specification, which would replace
deprecated/removed functionality.
What we could do is to
add a note to the JaxbLink javadoc saying "This
class will be removed at some point, replaced by
FOOBAR"; the problem is that we don't have
FOOBAR at the moment..
Regards,
Pavel
On 15/06/2017 16:31,
Markus KARG wrote:
the
JSR 370 charter says that with JAX-RS 2.1
the JAXB technology should become
conditional.
Looking
at the last spec draft I cannot find
anything about that. Quite contrary is still
is rather clear about the fact what an
implementation has to do with JAXBElement
etc.
So
I'd like to ask what to do with this issue.
Will JAXB stay as it is? Or do you have
plans to make it obsolete in JAX-RS 2.1
final draft?
|
|
|
Re: Status of JAXB in JAX-RS 2.1
Pavel, it seems you just have a different interpretation of the word "end user". At least I, as a car end user, do neither read the specification of pistons, nor does my car vendor add a note to the car's manual that it is the driver's obligation to look into the motor whether the pistons still work well when driving on streets built after the car had been manufactured. I am pretty sure that even oldtimers work well on latest streets without special care of the driver… ;-) Be assured that our products will come with *separate* instructions for how to run on Java SE 9 vs Java SE 8 - for a very good reason! But that's not the point. I neither want to discuss JDK / Java related issues on the JAX-RS EG list. Waht I want this EG (a group who decided to *neither* declare JAXB optional, *nor* to enable JAXB by default using module-info) is to bear the consequences of the sum of these choices: Clearly add a very short but clear note in JAX-RS 2.1's "Java SE Deployment" chapter about two simple facts: (A) JAX-RS 2.1 needs Java SE 8 or later. (B) On Java 9, the end user MUST explicitly activate all optional modules. At time of writing this at least is java.xml.bind. An implementation MAY enable these modules by default. Then everybody knows how the combination of "JAXB is *still mandatory* in this spec" and "Java SE 9 is *not forbidden* by this spec" is meant to work in field. Votes? -Markus
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek
Sent: Freitag, 16. Juni 2017 18:53
To: jaxrs-spec@javaee.groups.io
Subject: Re: [jaxrs] Status of JAXB in JAX-RS 2.1 Markus, your description of user definitely doesn't read the spec document, javadocs, etc. So what exactly would be achieved by putting a note into the spec document? My recommendation would be putting this as a warning to release notes of your product and reflect that in your documentation. If you want to discuss JDK/Java related issues, please do it elsewhere, as this is a list for JAX-RS, not Java 9 SE. (I'd recommend jdk9-dev@...). Regards,
Pavel On 16/06/2017 18:34, Markus KARG wrote: Pavel, this complete Jigsaw topic is a mess for the end user and I wonder what the OpenJDK guys wanted to reach with making JAXB optional… In reality no end user knows anything about Jigsaw (end users are not Java licencees, not even programmers, they are simply people who try to startup an application they did not have a source code for and they do not have any interest in the difference from Java 8 to Java 9 but just think "the newer the better"). What will happen in reality is that lots of end users will download JRE 9 and run JAX-RS-containing applications ontop of it and then fail. If we want to let them stand in the rain, we can go on like this. But we should be prepared about the effect… : Angry people hating us for not telling them the truth. Anyways, seems I am the only one who has a problem with the fact that our hotline soon will melt down. I hope that everybody in this EG is clear about the effects of not telling people how to run a JAX-RS 2.1 application on Java 9. Hands up please: Who in this EG thinks it is a good idea to NOT tell anybody in the specification that JAXB *is not* conditional but actually it is technically as soon as an end user replaces JRE 8 by JRE 9? I know that at least my own 10.000+ end users will kill me for this backwards-incompatibility. They don't care who broke it. It's just broken by me or Oracle in their view. -Markus Well.. the spec says nothing about running on Java 9, since Java 9 won't be final when JAX-RS 2.1 is released. When a user want's to run on Java 9, it is expected that he knows what he's doing (i.e. running on unsupported environment). There is plenty of tools provided by jdk to get this kind of information, for example jdeps: $ jdeps ~/.m2/repository/javax/ws/rs/javax.ws.rs-api/2.1-m09/javax.ws.rs-api-2.1-m09.jar
javax.ws.rs-api-2.1-m09.jar -> java.base
javax.ws.rs-api-2.1-m09.jar -> java.logging
javax.ws.rs-api-2.1-m09.jar -> java.xml
javax.ws.rs-api-2.1-m09.jar -> java.xml.bind
javax.ws.rs -> java.lang java.base
javax.ws.rs -> java.lang.annotation java.base
javax.ws.rs -> java.net java.base
javax.ws.rs -> java.util java.base
javax.ws.rs -> javax.ws.rs.core javax.ws.rs-api-2.1-m09.jar
javax.ws.rs -> javax.ws.rs.ext javax.ws.rs-api-2.1-m09.jar
javax.ws.rs.client -> java.io java.base
javax.ws.rs.client -> java.lang java.base
javax.ws.rs.client -> java.lang.annotation java.base
javax.ws.rs.client -> java.lang.invoke java.base
javax.ws.rs.client -> java.lang.reflect java.base
javax.ws.rs.client -> java.net java.base
javax.ws.rs.client -> java.security java.base
javax.ws.rs.client -> java.util java.base
javax.ws.rs.client -> java.util.concurrent java.base
javax.ws.rs.client -> java.util.logging java.logging
javax.ws.rs.client -> javax.net.ssl java.base
javax.ws.rs.client -> javax.ws.rs javax.ws.rs-api-2.1-m09.jar
javax.ws.rs.client -> javax.ws.rs.core javax.ws.rs-api-2.1-m09.jar
javax.ws.rs.container -> java.io java.base
javax.ws.rs.container -> java.lang java.base
javax.ws.rs.container -> java.lang.annotation java.base
javax.ws.rs.container -> java.lang.reflect java.base
javax.ws.rs.container -> java.net java.base
javax.ws.rs.container -> java.util java.base
javax.ws.rs.container -> java.util.concurrent java.base
javax.ws.rs.container -> javax.ws.rs.core javax.ws.rs-api-2.1-m09.jar
javax.ws.rs.core -> java.io java.base
javax.ws.rs.core -> java.lang java.base
javax.ws.rs.core -> java.lang.annotation java.base
javax.ws.rs.core -> java.lang.reflect java.base
javax.ws.rs.core -> java.net java.base
javax.ws.rs.core -> java.security java.base
javax.ws.rs.core -> java.util java.base
javax.ws.rs.core -> javax.ws.rs javax.ws.rs-api-2.1-m09.jar
javax.ws.rs.core -> javax.ws.rs.ext javax.ws.rs-api-2.1-m09.jar
javax.ws.rs.core -> javax.xml.bind.annotation java.xml.bind
javax.ws.rs.core -> javax.xml.bind.annotation.adapters java.xml.bind
javax.ws.rs.core -> javax.xml.namespace java.xml
javax.ws.rs.ext -> java.io java.base
javax.ws.rs.ext -> java.lang java.base
javax.ws.rs.ext -> java.lang.annotation java.base
javax.ws.rs.ext -> java.lang.invoke java.base
javax.ws.rs.ext -> java.lang.reflect java.base
javax.ws.rs.ext -> java.net java.base
javax.ws.rs.ext -> java.security java.base
javax.ws.rs.ext -> java.util java.base
javax.ws.rs.ext -> java.util.logging java.logging
javax.ws.rs.ext -> javax.ws.rs javax.ws.rs-api-2.1-m09.jar
javax.ws.rs.ext -> javax.ws.rs.core javax.ws.rs-api-2.1-m09.jar
javax.ws.rs.sse -> java.io java.base
javax.ws.rs.sse -> java.lang java.base
javax.ws.rs.sse -> java.lang.invoke java.base
javax.ws.rs.sse -> java.lang.reflect java.base
javax.ws.rs.sse -> java.net java.base
javax.ws.rs.sse -> java.security java.base
javax.ws.rs.sse -> java.util java.base
javax.ws.rs.sse -> java.util.concurrent java.base
javax.ws.rs.sse -> java.util.function java.base
javax.ws.rs.sse -> java.util.logging java.logging
javax.ws.rs.sse -> javax.ws.rs.client javax.ws.rs-api-2.1-m09.jar
javax.ws.rs.sse -> javax.ws.rs.core javax.ws.rs-api-2.1-m09.jar Regards,
Pavel On 16/06/2017 17:39, Markus KARG wrote: Pavel, my point is that the application *user* simply does not know that he must use --add-module when running any binary application on Java 9, as the *user* has no knowledge that JAXB is used *inside* of that (at least we as an ISV do not tell our users what APIs we use inside). So as the JAX-RS specification talks about how JAXB is handled, the user could assume that the JAX-RS implementation handles this issue "somehow magically" (like having a module-info). So *because* we decided against a "magic solution" (= module-info), it would be fair if the spec would in turn say that since there is no module-info enforced by JAX-RS, the *user* has to be informed by the application vendor when an application is making use of JAXB. How should the user know otherwise (other than trial-and-error)? -Markus that depends on how the application is ran (on Java 9). If the app is on classpath, the *user* has to --add-module java.xml.bind. Nobody can do that for him. If the app is on module path, there is another set of dependencies: requires transitive java.activation;
requires transitive java.desktop;
requires transitive java.logging;
requires transitive java.management; and maybe others. (some of those are required by Jersey (logger), some of them by JAX-RS (spec mandates that implementation has to support returning java.awt.image.RenderedImage, which is in java.desktop).
Dependency on java.xml.bind could be solved in the API jar, as suggested in the module-info:
https://github.com/jax-rs/api/blob/master/jaxrs-api/src/main/java/module-info.java
but since we agreed on not including it, it's up to the user or the implementation. (both parties can fix the issue by adding runtime switches - your statement about implementation being required to do something is not correct).
So, Markus, I'm not sure whether you are asking for something or .. ?
Regards,
Pavel On 16/06/2017 15:37, Markus KARG wrote: I do not say we should remove JAXB, I just wanted to ask because it was in the JSR 370 charter. I also do not see a big benefit of removing JAXB. The only problem I see is running JAX-RS 2.1 on Java SE 9: Due to project Jigsaw, a JRE will not allow access to JAXB unless the JVM is *explicitly* asked to grant access to JAXB. So we all should be aware what this means for the (reference) implementations: If we do *not* say JAXB is "conditional", and until an implementation *forbids* running Java 9, that implies that JAXB is still a MUST even on Java SE 9 -- so all implementations must take care to grant JAXB access. I assume that all existing implementors already fixed this…? :-) -Markus On Jun 15, 2017, at 11:30 AM, Sergey Beryozkin <sberyozkin@...> wrote: I see no practical point in doing it anyway. It's unlikely that any of the existing JAX-RS implementations will choose to annoy some of its users and just do not ship JAXB-aware providers - they will be needed for the next 10 years at least anyway even though the new services are more likely to use JSON/etc
+1
Sergey
On 15/06/17 16:31, Pavel Bucek wrote:
Hi Markus, we learned that it is not possible to do that in this release. The main issue is that we cannot just deprecate something, there is a strict policy related to making backwards incompatible changes - we'd need to create separate specification, which would replace deprecated/removed functionality. What we could do is to add a note to the JaxbLink javadoc saying "This class will be removed at some point, replaced by FOOBAR"; the problem is that we don't have FOOBAR at the moment.. Regards,
Pavel On 15/06/2017 16:31, Markus KARG wrote: the JSR 370 charter says that with JAX-RS 2.1 the JAXB technology should become conditional. Looking at the last spec draft I cannot find anything about that. Quite contrary is still is rather clear about the fact what an implementation has to do with JAXBElement etc. So I'd like to ask what to do with this issue. Will JAXB stay as it is? Or do you have plans to make it obsolete in JAX-RS 2.1 final draft?
|
|
|
