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!
|