Date   

Re: JAX-RS 2.1 released!

Guillermo González de Agüero
 

+1. For Java EE users, it's a really needed feature of equal importance.


Regards,

Guillermo González de Agüero


El jue., 31 de agosto de 2017 20:12, Ondrej Mihályi <ondrej.mihalyi@...> escribió:

Hi,

 

I would put it this way: alignment with CDI is as important the other major features like reactive and NIO but not more important. All the 3 features have been discussed for a long time, some already have been partially implemented. There's no reason to prefer any of them as there should be enough time for all 3 to be addressed in the next version of JAX-RS.

 

Ondro

 

Od: Sergey Beryozkin
Odesláno:čtvrtek 31. srpna 2017 17:48
Komu: jaxrs-spec@javaee.groups.io
Předmět: Re: [jaxrs] JAX-RS 2.1 released!

 

I have the feeling that all CDI experts in this group want is to go total CDI and spend a good portion of the next cycle's time
on getting everything injected really really well the CDI way, way better then it is already possible now, and ignore (or leave little time for) everything else that can actually inspire application developers do something new and cool in JAX-RS. While I agree that CDI-aware users should have more options to make all the bootstrapping process neater, CDI work is really not something that should take over everything else. It would take months do it right and in the end all JAX-RS users get is that they will probably be able to use JAX-RS with CDI only and no any new major features otherwise...

My preference would be for the group to go totally ballistic on doing better Reactive, Async, NIO. Make it really really well and spend all the time if the needed on this action only.

Sergey
On 24/08/17 20:09, Arjan Tijms wrote:

On Thu, Aug 24, 2017 at 09:09 am, Markus KARG wrote:

Congratulations! When do we start with JAX-RS 2.2? ;-)

Good question indeed. I'd say that even without a JSR we can already discuss our wishlists, can't we?

My nr 1 item; further or even totally integrate with CDI ;)

Kind regards,
Arjan

 

 


Re: JAX-RS 2.1 released!

Ondrej Mihályi
 

Hi,

 

I would put it this way: alignment with CDI is as important the other major features like reactive and NIO but not more important. All the 3 features have been discussed for a long time, some already have been partially implemented. There's no reason to prefer any of them as there should be enough time for all 3 to be addressed in the next version of JAX-RS.

 

Ondro

 

Od: Sergey Beryozkin
Odesláno:čtvrtek 31. srpna 2017 17:48
Komu: jaxrs-spec@javaee.groups.io
Předmět: Re: [jaxrs] JAX-RS 2.1 released!

 

I have the feeling that all CDI experts in this group want is to go total CDI and spend a good portion of the next cycle's time
on getting everything injected really really well the CDI way, way better then it is already possible now, and ignore (or leave little time for) everything else that can actually inspire application developers do something new and cool in JAX-RS. While I agree that CDI-aware users should have more options to make all the bootstrapping process neater, CDI work is really not something that should take over everything else. It would take months do it right and in the end all JAX-RS users get is that they will probably be able to use JAX-RS with CDI only and no any new major features otherwise...

My preference would be for the group to go totally ballistic on doing better Reactive, Async, NIO. Make it really really well and spend all the time if the needed on this action only.

Sergey

On 24/08/17 20:09, Arjan Tijms wrote:

On Thu, Aug 24, 2017 at 09:09 am, Markus KARG wrote:

Congratulations! When do we start with JAX-RS 2.2? ;-)

Good question indeed. I'd say that even without a JSR we can already discuss our wishlists, can't we?

My nr 1 item; further or even totally integrate with CDI ;)

Kind regards,
Arjan

 

 


Re: JAX-RS 2.1 released!

Sergey Beryozkin
 

I have the feeling that all CDI experts in this group want is to go total CDI and spend a good portion of the next cycle's time
on getting everything injected really really well the CDI way, way better then it is already possible now, and ignore (or leave little time for) everything else that can actually inspire application developers do something new and cool in JAX-RS. While I agree that CDI-aware users should have more options to make all the bootstrapping process neater, CDI work is really not something that should take over everything else. It would take months do it right and in the end all JAX-RS users get is that they will probably be able to use JAX-RS with CDI only and no any new major features otherwise...

My preference would be for the group to go totally ballistic on doing better Reactive, Async, NIO. Make it really really well and spend all the time if the needed on this action only.

Sergey

On 24/08/17 20:09, Arjan Tijms wrote:
On Thu, Aug 24, 2017 at 09:09 am, Markus KARG wrote:
Congratulations! When do we start with JAX-RS 2.2? ;-)
Good question indeed. I'd say that even without a JSR we can already discuss our wishlists, can't we?

My nr 1 item; further or even totally integrate with CDI ;)

Kind regards,
Arjan



Re: Clarification of Configuration.getClasses() behavior

 

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

 

 

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

 

 

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!

 

 

--

 

 


Re: Clarification of Configuration.getClasses() behavior

Pavel Bucek
 

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


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

 

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

 

 

 

 

 

 

 

 



Re: Clarification of Configuration.getClasses() behavior

Sergey Beryozkin
 

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

 

 

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

 

 

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

 

 



Re: Clarification of Configuration.getClasses() behavior

 

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. 

 

— 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.ioOn 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

 

 

 

 

 

 

 


Re: Clarification of Configuration.getClasses() behavior

 

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!

 

 

-- 

 

 

 

 

 

 

 


Re: Clarification of Configuration.getClasses() behavior

 

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

 

 

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!

 

 

--

 


Re: Clarification of Configuration.getClasses() behavior

Andy McCright
 

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

 

 

 

 
 


Re: Clarification of Configuration.getClasses() behavior

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

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









Re: Clarification of Configuration.getClasses() behavior

Sergey Beryozkin
 

Hi Santiago

Thanks, but Application.getClasses can return provider classes...

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
 








Re: Clarification of Configuration.getClasses() behavior

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

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







Re: JAX-RS 2.1 released!

Andy McCright
 

I'll do my best!  :-)
 
I was hoping to have at least some of the functionality delivered in our upcoming beta, but due to a build snafu, it didn't make it.  We should have something "tangible" to play with in our next beta - which should be out by the end of September. 
 
FWIW, I'm really enjoying working with SSE.  I hope that technology catches on!
 
Thanks,
 
Andy


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

----- Original message -----
From: "Markus KARG" <markus@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: Re: [jaxrs] JAX-RS 2.1 released!
Date: Fri, Aug 25, 2017 11:06 AM
 

Will you keep us updated on IBM's implementation progress? :-)

-Markus

 

 

From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Andy McCright
Sent: Donnerstag, 24. August 2017 23:03
To: jaxrs-spec@javaee.groups.io
Subject: Re: [jaxrs] JAX-RS 2.1 released!

 

Congratulations All!

 

It has been a pleasure working with you all on this, and I am looking forward to working with you again in the open source.  

 

Now it is time to implement this spec!  :-)

 

Thanks!

 

Andy



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

 

 

----- Original message -----
From: "Pavel Bucek" <pavel.bucek@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: [jaxrs] JAX-RS 2.1 released!
Date: Thu, Aug 24, 2017 8:46 AM
 

Dear experts,

it's our pleasure to announce that JAX-RS 2.1 was officially released,
see https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jcp.org_en_jsr_detail-3Fid-3D370&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=UpdfB_BfG8Sfl9U7cu9zlMnzlZDpNORv4F5g8rYfZJg&m=cZRJPetic6K09SdI_u-Jjc-vHS2H3QnR0SDXEgGOdhk&s=SnEzQLU5tNb8MPU6q7EUqR7Urx_49nRhVFCRTExYWHk&e= .

Thanks everyone for participating!

Feel free to share this message anywhere, write a blog post, speak about
JAX-RS on conferences.. use whatever channel you think is relevant.

Reference implementation is Jersey in version 2.26, currently available
on java.net promoted maven repository [1]; it will be soon released to
maven central.

Best regards,
Pavel & Santiago

[1] https://urldefense.proofpoint.com/v2/url?u=https-3A__maven.java.net_content_repositories_promoted_&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=UpdfB_BfG8Sfl9U7cu9zlMnzlZDpNORv4F5g8rYfZJg&m=cZRJPetic6K09SdI_u-Jjc-vHS2H3QnR0SDXEgGOdhk&s=3nZn6wFCEZLLEl0zfP93CIwMNcsZvlxR8bao3NSDgVc&e= 




 

 

 

 

 


Re: Clarification of Configuration.getClasses() behavior

Pavel Bucek
 

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

 






Re: Clarification of Configuration.getClasses() behavior

Sergey Beryozkin
 

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

 





Re: Clarification of Configuration.getClasses() behavior

Pavel Bucek
 

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

 




Re: Clarification of Configuration.getClasses() behavior

Sergey Beryozkin
 

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

 



Re: Clarification of Configuration.getClasses() behavior

 

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!

 

 

--


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!


--