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. 

 

— 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

 

On Aug 28, 2017, at 8:05 AM, Pavel Bucek <pavel.bucek@...> wrote:

 

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

 

 

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.

 

Any thoughts about that?

 

Thanks 

 

Christian

 

PS: Congratulations for delivering JAX-RS 2.1!

 

 

-- 

Christian Kaltepoth

Blog: http://blog.kaltepoth.de/

Twitter: http://twitter.com/chkal

GitHub: https://github.com/chkal