+1. For Java EE users, it's a really needed feature of equal importance. Regards, Guillermo González de Agüero

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

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

I would rather say, we have a charter for JAX-RS 2.2 to provide a more concise phrasing in the spec. :-) -Markus

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

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

Yes automatic discovery is to be considered for Configuration.get*, so it returns more than Application.getClasses.

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

Sergey, seems you missed the irony smiley at the end of my posting. -Markus

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

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.

Hi Santiago Thanks, but Application.getClasses can return provider classes... Cheers, Sergey

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

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

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

Hi Pavel Thanks For the record, in Configuration.getClasses(), on the server side, CXF returns the Application.getClasses() if Application is available, empty set

Thanks Sergey and +1 to that statement ;)

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

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: My question is whether the returned set of classes is supposed to contain resource classes or not. I'm asking this