|
Hey all,
I've quick question. The javadocs of Configuration.getClasses() state:
Get the immutable set of registered JAX-RS component (such as provider or feature) classes to be instantiated, injected and utilized in the scope of the configurable instance. For each component type, there can be only a single class-based or instance-based registration present in the configuration context at any given time. My question is whether the returned set of classes is supposed to contain resource classes or not.
I'm asking this because Jersey seems to return resources but RESTEasy doesn't.
Any thoughts about that?
Thanks
Christian
PS: Congratulations for delivering JAX-RS 2.1!
--
|
|
|
Due to the fact that Jersey is the RI and RESTEasy is not, what Jersey does is inherently correct, and what RESTEasy does is not. ;-) -Markus
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Christian Kaltepoth
Sent: Samstag, 26. August 2017 16:30
To: jaxrs-spec@javaee.groups.io
Subject: [jaxrs] Clarification of Configuration.getClasses() behavior Hey all, I've quick question. The javadocs of Configuration.getClasses() state: Get the immutable set of registered JAX-RS component (such as provider or feature) classes to be instantiated, injected and utilized in the scope of the configurable instance. For each component type, there can be only a single class-based or instance-based registration present in the configuration context at any given time.
My question is whether the returned set of classes is supposed to contain resource classes or not. I'm asking this because Jersey seems to return resources but RESTEasy doesn't. PS: Congratulations for delivering JAX-RS 2.1! --
|
|
|
Putting aside the fact RI is obviously
of high quality, the following may shock you but: RI may also have
bugs, some of them related to the interpretation of the
spec/API...
Sergey
toggle quoted messageShow quoted text
On 27/08/17 10:37, Markus KARG wrote:
Due
to the fact that Jersey is the RI and RESTEasy is not,
what Jersey does is inherently correct, and what RESTEasy
does is not. ;-)
-Markus
Hey all,
I've quick question. The javadocs of Configuration.getClasses()
state:
Get the immutable set of registered
JAX-RS component (such as provider or feature) classes to
be instantiated, injected and utilized in the scope of the
configurable instance. For each component type, there can
be only a single class-based or instance-based
registration present in the configuration context at any
given time.
My question is whether the returned
set of classes is supposed to contain resource classes
or not.
I'm asking this because Jersey seems
to return resources but RESTEasy doesn't.
PS: Congratulations for delivering
JAX-RS 2.1!
--
|
|
|
Thanks Sergey and +1 to that statement ;)
toggle quoted messageShow quoted text
On 28/08/2017 10:56, Sergey Beryozkin
wrote:
Putting aside the fact RI is
obviously of high quality, the following may shock you but: RI
may also have bugs, some of them related to the interpretation
of the spec/API...
Sergey
On 27/08/17 10:37, Markus KARG wrote:
Due
to the fact that Jersey is the RI and RESTEasy is not,
what Jersey does is inherently correct, and what
RESTEasy does is not. ;-)
-Markus
Hey all,
I've quick question. The javadocs of Configuration.getClasses()
state:
Get the immutable set of registered
JAX-RS component (such as provider or feature) classes
to be instantiated, injected and utilized in the scope
of the configurable instance. For each component type,
there can be only a single class-based or instance-based
registration present in the configuration context at any
given time.
My question is whether the returned
set of classes is supposed to contain resource classes
or not.
I'm asking this because Jersey
seems to return resources but RESTEasy doesn't.
PS: Congratulations for delivering
JAX-RS 2.1!
--
|
|
|
Hi Pavel
Thanks
For the record, in Configuration.getClasses(), on the server side,
CXF returns the Application.getClasses() if Application is
available, empty set otherwise. I suspect it may need to be
improved somehow, I found it quite difficult at a time to
implement Configuration API...
Cheers, Sergey
toggle quoted messageShow quoted text
On 28/08/17 10:00, Pavel Bucek wrote:
Thanks Sergey and +1 to that statement ;)
On 28/08/2017 10:56, Sergey Beryozkin
wrote:
Putting aside the fact RI is
obviously of high quality, the following may shock you but: RI
may also have bugs, some of them related to the interpretation
of the spec/API...
Sergey
On 27/08/17 10:37, Markus KARG wrote:
Due
to the fact that Jersey is the RI and RESTEasy is not,
what Jersey does is inherently correct, and what
RESTEasy does is not. ;-)
-Markus
Hey all,
I've quick question. The javadocs
of Configuration.getClasses() state:
Get the immutable set of registered
JAX-RS component (such as provider or feature) classes
to be instantiated, injected and utilized in the scope
of the configurable instance. For each component type,
there can be only a single class-based or
instance-based registration present in the
configuration context at any given time.
My question is whether the
returned set of classes is supposed to contain
resource classes or not.
I'm asking this because Jersey
seems to return resources but RESTEasy doesn't.
PS: Congratulations for
delivering JAX-RS 2.1!
--
|
|
|
I'd guess Configuration#getClasses() needs clarification.
To be honest, for me, it mirrors Application#getClasses(), but on
the runtime side (so I'd say that it can contain more classes than
what Application#getClasses() returns).
But I can't get that info from the javadoc. When I compare
Application#getClasses() and Configuration#getClasses(), it almost
seems that (root) resource classes are excluded, because they are
explicitly mentioned on the Application method, but not mentioned
on the Configuration version of that.
It also seems like this question uncovered possible hole in the
TCK. Too bad that this hasn't arrived two months ago.
Let me discuss that with Santiago and Marek and get back to you
(so we'll know the original intention), but unfortunately I can
advice only to file an issue against the spec
(https://github.com/jax-rs/api/issues), since the answer should be
present in Configuration javadoc.
Regards,
Pavel
toggle quoted messageShow quoted text
On 28/08/2017 13:52, Sergey Beryozkin
wrote:
Hi Pavel
Thanks
For the record, in Configuration.getClasses(), on the server
side, CXF returns the Application.getClasses() if Application is
available, empty set otherwise. I suspect it may need to be
improved somehow, I found it quite difficult at a time to
implement Configuration API...
Cheers, Sergey
On 28/08/17 10:00, Pavel Bucek wrote:
Thanks Sergey and +1 to that statement ;)
On 28/08/2017 10:56, Sergey
Beryozkin wrote:
Putting aside the fact RI is
obviously of high quality, the following may shock you but:
RI may also have bugs, some of them related to the
interpretation of the spec/API...
Sergey
On 27/08/17 10:37, Markus KARG wrote:
Due
to the fact that Jersey is the RI and RESTEasy is
not, what Jersey does is inherently correct, and
what RESTEasy does is not. ;-)
-Markus
Hey all,
I've quick question. The javadocs
of Configuration.getClasses() state:
Get the immutable set of
registered JAX-RS component (such as provider or
feature) classes to be instantiated, injected and
utilized in the scope of the configurable instance.
For each component type, there can be only a single
class-based or instance-based registration present
in the configuration context at any given time.
My question is whether the
returned set of classes is supposed to contain
resource classes or not.
I'm asking this because Jersey
seems to return resources but RESTEasy doesn't.
PS: Congratulations for
delivering JAX-RS 2.1!
--
|
|
|
Santiago Pericas-Geertsen
Pavel, Sergey,
My recollection is that the Configuration#getClasses() is not related to resources, but only providers and features. So I think the results returned by the two #getClasses() mentioned should not intersect.
— Santiago
I'd guess Configuration#getClasses() needs clarification. To be honest, for me, it mirrors Application#getClasses(), but on the runtime side (so I'd say that it can contain more classes than what Application#getClasses() returns). But I can't get that info from the javadoc. When I compare Application#getClasses() and Configuration#getClasses(), it almost seems that (root) resource classes are excluded, because they are explicitly mentioned on the Application method, but not mentioned on the Configuration version of that. It also seems like this question uncovered possible hole in the TCK. Too bad that this hasn't arrived two months ago. Let me discuss that with Santiago and Marek and get back to you (so we'll know the original intention), but unfortunately I can advice only to file an issue against the spec (https://github.com/jax-rs/api/issues), since the answer should be present in Configuration javadoc. Regards,
Pavel
On 28/08/2017 13:52, Sergey Beryozkin wrote:
Hi Pavel
Thanks
For the record, in Configuration.getClasses(), on the server side, CXF returns the Application.getClasses() if Application is available, empty set otherwise. I suspect it may need to be improved somehow, I found it quite difficult at a time to implement Configuration API...
Cheers, Sergey
On 28/08/17 10:00, Pavel Bucek wrote:
Thanks Sergey and +1 to that statement ;)
On 28/08/2017 10:56, Sergey Beryozkin wrote:
Putting aside the fact RI is obviously of high quality, the following may shock you but: RI may also have bugs, some of them related to the interpretation of the spec/API...
Sergey
On 27/08/17 10:37, Markus KARG wrote:
Due to the fact that Jersey is the RI and RESTEasy is not, what Jersey does is inherently correct, and what RESTEasy does is not. ;-) -Markus Hey all, I've quick question. The javadocs of Configuration.getClasses() state: Get the immutable set of registered JAX-RS component (such as provider or feature) classes to be instantiated, injected and utilized in the scope of the configurable instance. For each component type, there can be only a single class-based or instance-based registration present in the configuration context at any given time.
My question is whether the returned set of classes is supposed to contain resource classes or not. I'm asking this because Jersey seems to return resources but RESTEasy doesn't. PS: Congratulations for delivering JAX-RS 2.1! --
|
|
|
Hi Santiago
Thanks, but Application.getClasses can return provider classes...
Cheers, Sergey
toggle quoted messageShow quoted text
On 28/08/17 15:35, Santiago Pericas-Geertsen wrote:
Pavel, Sergey,
My recollection is that the
Configuration#getClasses() is not related to resources, but only
providers and features. So I think the results returned by the
two #getClasses() mentioned should not intersect.
— Santiago
I'd
guess Configuration#getClasses() needs clarification.
To be
honest, for me, it mirrors Application#getClasses(), but
on the runtime side (so I'd say that it can contain more
classes than what Application#getClasses() returns).
But I
can't get that info from the javadoc. When I compare
Application#getClasses() and Configuration#getClasses(),
it almost seems that (root) resource classes are
excluded, because they are explicitly mentioned on the
Application method, but not mentioned on the
Configuration version of that.
It also
seems like this question uncovered possible hole in the
TCK. Too bad that this hasn't arrived two months ago.
Let me
discuss that with Santiago and Marek and get back to you
(so we'll know the original intention), but
unfortunately I can advice only to file an issue against
the spec (https://github.com/jax-rs/api/issues),
since the answer should be present in Configuration
javadoc.
Regards,
Pavel
On 28/08/2017
13:52, Sergey Beryozkin wrote:
Hi Pavel
Thanks
For the record, in Configuration.getClasses(), on the
server side, CXF returns the Application.getClasses()
if Application is available, empty set otherwise. I
suspect it may need to be improved somehow, I found it
quite difficult at a time to implement Configuration
API...
Cheers, Sergey
On 28/08/17 10:00, Pavel Bucek wrote:
Thanks Sergey and +1 to that
statement ;)
On 28/08/2017 10:56,
Sergey Beryozkin wrote:
Putting aside the fact
RI is obviously of high quality, the following may
shock you but: RI may also have bugs, some of them
related to the interpretation of the spec/API...
Sergey
On 27/08/17 10:37, Markus KARG wrote:
Due to the fact that
Jersey is the RI and RESTEasy is not, what
Jersey does is inherently correct, and
what RESTEasy does is not. ;-)
-Markus
Hey all,
I've quick
question. The javadocs of Configuration.getClasses() state:
Get the immutable
set of registered JAX-RS component (such
as provider or feature) classes to be
instantiated, injected and utilized in the
scope of the configurable instance. For
each component type, there can be only a
single class-based or instance-based
registration present in the configuration
context at any given time.
My question is
whether the returned set of classes is
supposed to contain resource classes or
not.
I'm asking this
because Jersey seems to return resources
but RESTEasy doesn't.
PS:
Congratulations for delivering JAX-RS
2.1!
--
|
|
|
Santiago Pericas-Geertsen
On Aug 28, 2017, at 10:42 AM, Sergey Beryozkin < sberyozkin@...> wrote:
Hi Santiago
Thanks, but Application.getClasses can return provider classes…
Yes, sorry, I was thinking only about resources. There is indeed an intersection. Returning resources from the configuration seems a bit strange, though, but ultimately is whatever we define it to be.
I do agree that this needs to be clarified in the docs.
— Santiago
Cheers, Sergey
On 28/08/17 15:35, Santiago Pericas-Geertsen wrote:
Pavel, Sergey,
My recollection is that the Configuration#getClasses() is not related to resources, but only providers and features. So I think the results returned by the two #getClasses() mentioned should not intersect.
— Santiago
I'd guess Configuration#getClasses() needs clarification. To be honest, for me, it mirrors Application#getClasses(), but on the runtime side (so I'd say that it can contain more classes than what Application#getClasses() returns). But I can't get that info from the javadoc. When I compare Application#getClasses() and Configuration#getClasses(), it almost seems that (root) resource classes are excluded, because they are explicitly mentioned on the Application method, but not mentioned on the Configuration version of that. It also seems like this question uncovered possible hole in the TCK. Too bad that this hasn't arrived two months ago. Let me discuss that with Santiago and Marek and get back to you (so we'll know the original intention), but unfortunately I can advice only to file an issue against the spec (https://github.com/jax-rs/api/issues), since the answer should be present in Configuration javadoc. Regards,
Pavel
On 28/08/2017 13:52, Sergey Beryozkin wrote:
Hi Pavel
Thanks
For the record, in Configuration.getClasses(), on the server side, CXF returns the Application.getClasses() if Application is available, empty set otherwise. I suspect it may need to be improved somehow, I found it quite difficult at a time to implement Configuration API...
Cheers, Sergey
On 28/08/17 10:00, Pavel Bucek wrote:
Thanks Sergey and +1 to that statement ;)
On 28/08/2017 10:56, Sergey Beryozkin wrote:
Putting aside the fact RI is obviously of high quality, the following may shock you but: RI may also have bugs, some of them related to the interpretation of the spec/API...
Sergey
On 27/08/17 10:37, Markus KARG wrote:
Due to the fact that Jersey is the RI and RESTEasy is not, what Jersey does is inherently correct, and what RESTEasy does is not. ;-) -Markus Hey all, I've quick question. The javadocs of Configuration.getClasses() state: Get the immutable set of registered JAX-RS component (such as provider or feature) classes to be instantiated, injected and utilized in the scope of the configurable instance. For each component type, there can be only a single class-based or instance-based registration present in the configuration context at any given time.
My question is whether the returned set of classes is supposed to contain resource classes or not. I'm asking this because Jersey seems to return resources but RESTEasy doesn't. PS: Congratulations for delivering JAX-RS 2.1! --
|
|
|
Should automatic discovery play a part in this too? I.e. return the value of Application.getClasses() unless that that returns an empty collection. If empty, return the set of classes marked with JAX-RS component annotations (all root resource and provider classes).
J. Andrew McCright
IBM WebSphere Development
+1 507 253 7448
TL 553-7448
andymc@...
----- Original message -----
From: "Santiago Pericas-Geertsen" <santiago.pericasgeertsen@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: Re: [jaxrs] Clarification of Configuration.getClasses() behavior
Date: Mon, Aug 28, 2017 10:29 AM
On Aug 28, 2017, at 10:42 AM, Sergey Beryozkin < sberyozkin@...> wrote: Hi Santiago
Thanks, but Application.getClasses can return provider classes…
Yes, sorry, I was thinking only about resources. There is indeed an intersection. Returning resources from the configuration seems a bit strange, though, but ultimately is whatever we define it to be.
I do agree that this needs to be clarified in the docs.
— Santiago
Cheers, Sergey
On 28/08/17 15:35, Santiago Pericas-Geertsen wrote:
Pavel, Sergey,
My recollection is that the Configuration#getClasses() is not related to resources, but only providers and features. So I think the results returned by the two #getClasses() mentioned should not intersect.
— Santiago
I'd guess Configuration#getClasses() needs clarification.
To be honest, for me, it mirrors Application#getClasses(), but on the runtime side (so I'd say that it can contain more classes than what Application#getClasses() returns).
But I can't get that info from the javadoc. When I compare Application#getClasses() and Configuration#getClasses(), it almost seems that (root) resource classes are excluded, because they are explicitly mentioned on the Application method, but not mentioned on the Configuration version of that.
It also seems like this question uncovered possible hole in the TCK. Too bad that this hasn't arrived two months ago.
Let me discuss that with Santiago and Marek and get back to you (so we'll know the original intention), but unfortunately I can advice only to file an issue against the spec (https://github.com/jax-rs/api/issues), since the answer should be present in Configuration javadoc.
Regards,
Pavel
On 28/08/2017 13:52, Sergey Beryozkin wrote:
Hi Pavel
Thanks
For the record, in Configuration.getClasses(), on the server side, CXF returns the Application.getClasses() if Application is available, empty set otherwise. I suspect it may need to be improved somehow, I found it quite difficult at a time to implement Configuration API...
Cheers, Sergey
On 28/08/17 10:00, Pavel Bucek wrote:
Thanks Sergey and +1 to that statement ;)
On 28/08/2017 10:56, Sergey Beryozkin wrote:
Putting aside the fact RI is obviously of high quality, the following may shock you but: RI may also have bugs, some of them related to the interpretation of the spec/API...
Sergey
On 27/08/17 10:37, Markus KARG wrote:
Due to the fact that Jersey is the RI and RESTEasy is not, what Jersey does is inherently correct, and what RESTEasy does is not. ;-)
-Markus
Hey all,
I've quick question. The javadocs of Configuration.getClasses() state: Get the immutable set of registered JAX-RS component (such as provider or feature) classes to be instantiated, injected and utilized in the scope of the configurable instance. For each component type, there can be only a single class-based or instance-based registration present in the configuration context at any given time.
My question is whether the returned set of classes is supposed to contain resource classes or not. I'm asking this because Jersey seems to return resources but RESTEasy doesn't. PS: Congratulations for delivering JAX-RS 2.1! --
|
|
|
Sergey, seems you missed the irony smiley at the end of my posting. -Markus
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Sergey Beryozkin
Sent: Montag, 28. August 2017 10:56
To: jaxrs-spec@javaee.groups.io
Subject: Re: [jaxrs] Clarification of Configuration.getClasses() behavior Putting aside the fact RI is obviously of high quality, the following may shock you but: RI may also have bugs, some of them related to the interpretation of the spec/API...
Sergey
On 27/08/17 10:37, Markus KARG wrote: Due to the fact that Jersey is the RI and RESTEasy is not, what Jersey does is inherently correct, and what RESTEasy does is not. ;-) -Markus Hey all, I've quick question. The javadocs of Configuration.getClasses() state: Get the immutable set of registered JAX-RS component (such as provider or feature) classes to be instantiated, injected and utilized in the scope of the configurable instance. For each component type, there can be only a single class-based or instance-based registration present in the configuration context at any given time.
My question is whether the returned set of classes is supposed to contain resource classes or not. I'm asking this because Jersey seems to return resources but RESTEasy doesn't. PS: Congratulations for delivering JAX-RS 2.1! --
|
|
|
IIRC… * Application.getClasses() is implemented by the application developer to let the JAX-RS engine know which components (= resources and providers) are to be loaded. It exists since JAX-RS 2.0 and is the initial content of Configuration. * Since JAX-RS 2.1 Configuration exists to support dynamic Features. A feature can dynamically decide to add more components ( = resources and providers) to the configuration or to remove components from it. * If in JAX-RS 1.0 we would have known that we want dynamic Features later, we would never have invented Application.getClasses(), but simply would have provided the Config to the app. But for backwards compatibility it must stay as it is. To sum up: Configuration returns the actual config at runtime to anything who likes to know, while Application initially fills the Configuration. -Markus
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Santiago Pericas-Geertsen
Sent: Montag, 28. August 2017 17:30
To: jaxrs-spec@javaee.groups.io
Subject: Re: [jaxrs] Clarification of Configuration.getClasses() behavior On Aug 28, 2017, at 10:42 AM, Sergey Beryozkin <sberyozkin@...> wrote: Hi Santiago
Thanks, but Application.getClasses can return provider classes…
Yes, sorry, I was thinking only about resources. There is indeed an intersection. Returning resources from the configuration seems a bit strange, though, but ultimately is whatever we define it to be. I do agree that this needs to be clarified in the docs.
Cheers, Sergey
On 28/08/17 15:35, Santiago Pericas-Geertsen wrote:
Pavel, Sergey, My recollection is that the Configuration#getClasses() is not related to resources, but only providers and features. So I think the results returned by the two #getClasses() mentioned should not intersect. I'd guess Configuration#getClasses() needs clarification. To be honest, for me, it mirrors Application#getClasses(), but on the runtime side (so I'd say that it can contain more classes than what Application#getClasses() returns). But I can't get that info from the javadoc. When I compare Application#getClasses() and Configuration#getClasses(), it almost seems that (root) resource classes are excluded, because they are explicitly mentioned on the Application method, but not mentioned on the Configuration version of that. It also seems like this question uncovered possible hole in the TCK. Too bad that this hasn't arrived two months ago. Let me discuss that with Santiago and Marek and get back to you (so we'll know the original intention), but unfortunately I can advice only to file an issue against the spec (https://github.com/jax-rs/api/issues), since the answer should be present in Configuration javadoc. Regards,
Pavel On 28/08/2017 13:52, Sergey Beryozkin wrote: Hi Pavel
Thanks
For the record, in Configuration.getClasses(), on the server side, CXF returns the Application.getClasses() if Application is available, empty set otherwise. I suspect it may need to be improved somehow, I found it quite difficult at a time to implement Configuration API...
Cheers, Sergey
On 28/08/17 10:00, Pavel Bucek wrote: Thanks Sergey and +1 to that statement ;) On 28/08/2017 10:56, Sergey Beryozkin wrote: Putting aside the fact RI is obviously of high quality, the following may shock you but: RI may also have bugs, some of them related to the interpretation of the spec/API...
Sergey
On 27/08/17 10:37, Markus KARG wrote: Due to the fact that Jersey is the RI and RESTEasy is not, what Jersey does is inherently correct, and what RESTEasy does is not. ;-) I've quick question. The javadocs of Configuration.getClasses() state: Get the immutable set of registered JAX-RS component (such as provider or feature) classes to be instantiated, injected and utilized in the scope of the configurable instance. For each component type, there can be only a single class-based or instance-based registration present in the configuration context at any given time.
My question is whether the returned set of classes is supposed to contain resource classes or not. I'm asking this because Jersey seems to return resources but RESTEasy doesn't. PS: Congratulations for delivering JAX-RS 2.1!
|
|
|
Yes automatic discovery is to be considered for Configuration.get*, so it returns more than Application.getClasses.
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Andy McCright
Sent: Montag, 28. August 2017 17:36
To: jaxrs-spec@javaee.groups.io
Subject: Re: [jaxrs] Clarification of Configuration.getClasses() behavior Should automatic discovery play a part in this too? I.e. return the value of Application.getClasses() unless that that returns an empty collection. If empty, return the set of classes marked with JAX-RS component annotations (all root resource and provider classes).
J. Andrew McCright
IBM WebSphere Development
+1 507 253 7448
TL 553-7448
andymc@...
----- Original message -----
From: "Santiago Pericas-Geertsen" <santiago.pericasgeertsen@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: Re: [jaxrs] Clarification of Configuration.getClasses() behavior
Date: Mon, Aug 28, 2017 10:29 AM
On Aug 28, 2017, at 10:42 AM, Sergey Beryozkin <sberyozkin@...> wrote: Hi Santiago
Thanks, but Application.getClasses can return provider classes…
Yes, sorry, I was thinking only about resources. There is indeed an intersection. Returning resources from the configuration seems a bit strange, though, but ultimately is whatever we define it to be. I do agree that this needs to be clarified in the docs.
Cheers, Sergey
On 28/08/17 15:35, Santiago Pericas-Geertsen wrote:
Pavel, Sergey, My recollection is that the Configuration#getClasses() is not related to resources, but only providers and features. So I think the results returned by the two #getClasses() mentioned should not intersect. I'd guess Configuration#getClasses() needs clarification. To be honest, for me, it mirrors Application#getClasses(), but on the runtime side (so I'd say that it can contain more classes than what Application#getClasses() returns). But I can't get that info from the javadoc. When I compare Application#getClasses() and Configuration#getClasses(), it almost seems that (root) resource classes are excluded, because they are explicitly mentioned on the Application method, but not mentioned on the Configuration version of that. It also seems like this question uncovered possible hole in the TCK. Too bad that this hasn't arrived two months ago. Let me discuss that with Santiago and Marek and get back to you (so we'll know the original intention), but unfortunately I can advice only to file an issue against the spec (https://github.com/jax-rs/api/issues), since the answer should be present in Configuration javadoc. Regards,
Pavel On 28/08/2017 13:52, Sergey Beryozkin wrote: Hi Pavel
Thanks
For the record, in Configuration.getClasses(), on the server side, CXF returns the Application.getClasses() if Application is available, empty set otherwise. I suspect it may need to be improved somehow, I found it quite difficult at a time to implement Configuration API...
Cheers, Sergey
On 28/08/17 10:00, Pavel Bucek wrote: Thanks Sergey and +1 to that statement ;) On 28/08/2017 10:56, Sergey Beryozkin wrote: Putting aside the fact RI is obviously of high quality, the following may shock you but: RI may also have bugs, some of them related to the interpretation of the spec/API...
Sergey
On 27/08/17 10:37, Markus KARG wrote: Due to the fact that Jersey is the RI and RESTEasy is not, what Jersey does is inherently correct, and what RESTEasy does is not. ;-) I've quick question. The javadocs of Configuration.getClasses() state: Get the immutable set of registered JAX-RS component (such as provider or feature) classes to be instantiated, injected and utilized in the scope of the configurable instance. For each component type, there can be only a single class-based or instance-based registration present in the configuration context at any given time.
My question is whether the returned set of classes is supposed to contain resource classes or not. I'm asking this because Jersey seems to return resources but RESTEasy doesn't. PS: Congratulations for delivering JAX-RS 2.1!
|
|
|
I saw a wink there all right, but did
not assume it was there to change the meaning of sentence. Perhaps
it means I lack a sense of humour :-).
Looks like RestEasy got it right after all :-)
Sergey
toggle quoted messageShow quoted text
On 28/08/17 18:35, Markus KARG wrote:
Sergey,
seems
you missed the irony smiley at the end of my posting.
-Markus
Putting aside the fact RI is obviously of
high quality, the following may shock you but: RI may also
have bugs, some of them related to the interpretation of the
spec/API...
Sergey
On 27/08/17 10:37, Markus KARG wrote:
Due
to the fact that Jersey is the RI and RESTEasy is not,
what Jersey does is inherently correct, and what RESTEasy
does is not. ;-)
-Markus
Hey all,
I've quick question. The javadocs of Configuration.getClasses()
state:
Get the immutable set of registered
JAX-RS component (such as provider or feature) classes
to be instantiated, injected and utilized in the scope
of the configurable instance. For each component type,
there can be only a single class-based or instance-based
registration present in the configuration context at any
given time.
My question is whether the returned
set of classes is supposed to contain resource classes
or not.
I'm asking this because Jersey
seems to return resources but RESTEasy doesn't.
PS: Congratulations for delivering
JAX-RS 2.1!
--
|
|
|
Configuration is @since 2.0
Application#getClasses() is @since 1.0
I agree that Configuration#getClasses() should return complete
config state of the app, so including automatically registered
features (opposing to Application#getClasses()).
Seems like Santiago believes that resource classes should not be
present (which seems to be implied in the javadoc, based on its
comparison with Application).
In any way, I filed https://github.com/jax-rs/api/issues/565
Regards,
Pavel
toggle quoted messageShow quoted text
On 28/08/2017 19:42, Markus KARG wrote:
IIRC…
*
Application.getClasses() is implemented by the application
developer to let the JAX-RS engine know which components (=
resources and providers) are to be loaded. It exists since
JAX-RS 2.0 and is the initial content of Configuration.
*
Since JAX-RS 2.1 Configuration exists to support dynamic
Features. A feature can dynamically decide to add more
components ( = resources and providers) to the configuration
or to remove components from it.
*
If in JAX-RS 1.0 we would have known that we want dynamic
Features later, we would never have invented
Application.getClasses(), but simply would have provided the
Config to the app. But for backwards compatibility it must
stay as it is.
To
sum up: Configuration returns the actual config at runtime
to anything who likes to know, while Application initially
fills the Configuration.
-Markus
On Aug 28, 2017, at 10:42 AM, Sergey
Beryozkin <sberyozkin@...>
wrote:
Hi
Santiago
Thanks, but Application.getClasses can return
provider classes…
Yes, sorry, I was thinking only about
resources. There is indeed an intersection. Returning
resources from the configuration seems a bit strange,
though, but ultimately is whatever we define it to be.
I do agree that this needs to be
clarified in the docs.
Cheers, Sergey
On 28/08/17 15:35, Santiago Pericas-Geertsen wrote:
Pavel,
Sergey,
My
recollection is that the Configuration#getClasses()
is not related to resources, but only providers and
features. So I think the results returned by the two
#getClasses() mentioned should not intersect.
I'd
guess Configuration#getClasses() needs
clarification.
To
be honest, for me, it mirrors
Application#getClasses(), but on the runtime
side (so I'd say that it can contain more
classes than what Application#getClasses()
returns).
But
I can't get that info from the javadoc. When I
compare Application#getClasses() and
Configuration#getClasses(), it almost seems that
(root) resource classes are excluded, because
they are explicitly mentioned on the Application
method, but not mentioned on the Configuration
version of that.
It
also seems like this question uncovered possible
hole in the TCK. Too bad that this hasn't
arrived two months ago.
Let
me discuss that with Santiago and Marek and get
back to you (so we'll know the original
intention), but unfortunately I can advice only
to file an issue against the spec (https://github.com/jax-rs/api/issues),
since the answer should be present in
Configuration javadoc.
Regards,
Pavel
On
28/08/2017 13:52, Sergey Beryozkin wrote:
Hi
Pavel
Thanks
For the record, in
Configuration.getClasses(), on the server
side, CXF returns the
Application.getClasses() if Application is
available, empty set otherwise. I suspect
it may need to be improved somehow, I
found it quite difficult at a time to
implement Configuration API...
Cheers, Sergey
On 28/08/17 10:00, Pavel Bucek wrote:
Thanks
Sergey and +1 to that statement ;)
On
28/08/2017 10:56, Sergey Beryozkin
wrote:
Putting
aside the fact RI is obviously of high
quality, the following may shock you
but: RI may also have bugs, some of
them related to the interpretation of
the spec/API...
Sergey
On 27/08/17 10:37, Markus KARG wrote:
Due
to the fact that Jersey is the RI
and RESTEasy is not, what Jersey
does is inherently correct, and what
RESTEasy does is not. ;-)
I've
quick question. The javadocs of Configuration.getClasses() state:
Get
the immutable set of registered
JAX-RS component (such as
provider or feature) classes to
be instantiated, injected and
utilized in the scope of the
configurable instance. For each
component type, there can be
only a single class-based or
instance-based registration
present in the configuration
context at any given time.
My
question is whether the
returned set of classes is
supposed to contain resource
classes or not.
I'm
asking this because Jersey
seems to return resources but
RESTEasy doesn't.
PS:
Congratulations for delivering
JAX-RS 2.1!
|
|
|
I would rather say, we have a charter for JAX-RS 2.2 to provide a more concise phrasing in the spec. :-) -Markus
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Sergey Beryozkin
Sent: Dienstag, 29. August 2017 10:43
To: jaxrs-spec@javaee.groups.io
Subject: Re: [jaxrs] Clarification of Configuration.getClasses() behavior I saw a wink there all right, but did not assume it was there to change the meaning of sentence. Perhaps it means I lack a sense of humour :-).
Looks like RestEasy got it right after all :-)
Sergey
On 28/08/17 18:35, Markus KARG wrote: Sergey, seems you missed the irony smiley at the end of my posting. -Markus Putting aside the fact RI is obviously of high quality, the following may shock you but: RI may also have bugs, some of them related to the interpretation of the spec/API...
Sergey
On 27/08/17 10:37, Markus KARG wrote: Due to the fact that Jersey is the RI and RESTEasy is not, what Jersey does is inherently correct, and what RESTEasy does is not. ;-) -Markus Hey all, I've quick question. The javadocs of Configuration.getClasses() state: Get the immutable set of registered JAX-RS component (such as provider or feature) classes to be instantiated, injected and utilized in the scope of the configurable instance. For each component type, there can be only a single class-based or instance-based registration present in the configuration context at any given time.
My question is whether the returned set of classes is supposed to contain resource classes or not. I'm asking this because Jersey seems to return resources but RESTEasy doesn't. PS: Congratulations for delivering JAX-RS 2.1! --
|
|
|
