|
Re: CDI integration
consider this as a subthread :)
To be absolutely honest, I'd expect CNFE or something like that. I already wrote a test, which corresponds to what you wrote ;) So thanks for that
consider this as a subthread :)
To be absolutely honest, I'd expect CNFE or something like that. I already wrote a test, which corresponds to what you wrote ;) So thanks for that
|
By
Pavel Bucek
·
#118
·
|
|
Re: CDI integration
IMHO it would be a deal breaker, please do not make strong deps on CDI in JAX-RS API.
It will affect non-EE and non-CDI RI, CXF, RestEasy users who will get annoyed and move elsewhere
IMHO it would be a deal breaker, please do not make strong deps on CDI in JAX-RS API.
It will affect non-EE and non-CDI RI, CXF, RestEasy users who will get annoyed and move elsewhere
|
By
Sergey Beryozkin
·
#119
·
|
|
Re: module-info or not module-info..
Looking at all the trouble I had with diverse Java 9 pre-releases in the past months, I really think it would be wise to completely ignore Java 9 for now. At the time of releasing JAX-RS 2.1 current
Looking at all the trouble I had with diverse Java 9 pre-releases in the past months, I really think it would be wise to completely ignore Java 9 for now. At the time of releasing JAX-RS 2.1 current
|
By
Markus KARG
·
#120
·
|
|
Re: CDI integration
I would really love to see everything replaced by CDI which is duplicated in any Java EE API. If this means that a JAX-RS implementation has to provide CDI, then we should add this to the
I would really love to see everything replaced by CDI which is duplicated in any Java EE API. If this means that a JAX-RS implementation has to provide CDI, then we should add this to the
|
By
Markus KARG
·
#121
·
|
|
Re: CDI integration
So lets us just break everything and be happy, how inspiring...
So lets us just break everything and be happy, how inspiring...
|
By
Sergey Beryozkin
·
#122
·
|
|
Re: CDI integration
I do not say we have to break everything. I said we should mandate to _bundle_ CDI if needed. This does not break anything, it provides additional features.
Also please remember that JAXB became
I do not say we have to break everything. I said we should mandate to _bundle_ CDI if needed. This does not break anything, it provides additional features.
Also please remember that JAXB became
|
By
Markus KARG
·
#123
·
|
|
Re: module-info or not module-info..
I agree that we should not ship the module-info in 2.1.
I do think it is important that JAX-RS 2.1 should function in Java 9 out-of-the-box though. So, I would advise a wait-and-see approach for
I agree that we should not ship the module-info in 2.1.
I do think it is important that JAX-RS 2.1 should function in Java 9 out-of-the-box though. So, I would advise a wait-and-see approach for
|
By
Andy McCright
·
#124
·
|
|
Re: CDI integration
Makes sense as long as CDI is not mandatory for 2.1.
I'm not sure you've heard what I was trying to say about the importance of keeping the core JAX-RS as neutral as possible,
Makes sense as long as CDI is not mandatory for 2.1.
I'm not sure you've heard what I was trying to say about the importance of keeping the core JAX-RS as neutral as possible,
|
By
Sergey Beryozkin
·
#125
·
|
|
Re: CDI integration
Hi,
I've checked it and adding a new bean with CDI 2.0 is just as simple as creating an extension like this (taken from
Hi,
I've checked it and adding a new bean with CDI 2.0 is just as simple as creating an extension like this (taken from
|
By
Guillermo González de Agüero
·
#126
·
|
|
Re: CDI integration
Hi,
IMHO it would be best to just commit and make CDI mandatory. This is exactly what we've been in doing in JSF as well. There's a transition period, sure, but in the end things should be a lot
Hi,
IMHO it would be best to just commit and make CDI mandatory. This is exactly what we've been in doing in JSF as well. There's a transition period, sure, but in the end things should be a lot
|
By
Arjan Tijms
·
#127
·
|
|
Re: CDI integration
-1
By
Sergey Beryozkin
·
#128
·
|
|
Re: CDI integration
Can you give me any good reason why we should keep @ManagedBean? It has been deprecated already and everything in and around it has been superseded by CDI. Also remember that pruning is a multi
Can you give me any good reason why we should keep @ManagedBean? It has been deprecated already and everything in and around it has been superseded by CDI. Also remember that pruning is a multi
|
By
Arjan Tijms
·
#129
·
|
|
Re: CDI integration
Why are we talking about JSF ? All JAX-RS stacks have been doing very well so far as far taking care of their users, and somehow they have managed to do it without CDI being a required
Why are we talking about JSF ? All JAX-RS stacks have been doing very well so far as far taking care of their users, and somehow they have managed to do it without CDI being a required
|
By
Sergey Beryozkin
·
#130
·
|
|
Re: CDI integration
Hi,
Because it's another Java EE spec that had its own DI engine and gave it up for the platform one.
I'm really not sure why the REST API of Java EE should have its own DI engine.
Does Spring MVC
Hi,
Because it's another Java EE spec that had its own DI engine and gave it up for the platform one.
I'm really not sure why the REST API of Java EE should have its own DI engine.
Does Spring MVC
|
By
Arjan Tijms
·
#131
·
|
|
Re: CDI integration
Fully agree that we should try to align JAX-RS into Java EE (i.e. CDI here) as much as possible. IMO one of the biggest advantages of EE is how the different specs integrate with eachother.
Fully agree that we should try to align JAX-RS into Java EE (i.e. CDI here) as much as possible. IMO one of the biggest advantages of EE is how the different specs integrate with eachother.
|
By
Sebastian Daschner
·
#132
·
|
|
Re: module-info or not module-info..
As I recall there were some discussion on the javaee-spec mailinglist (java.net) in May regarding standardzing the module names for the Java EE specs in Java EE 9.
So it may be a bit premature to
As I recall there were some discussion on the javaee-spec mailinglist (java.net) in May regarding standardzing the module names for the Java EE specs in Java EE 9.
So it may be a bit premature to
|
By
Ivar Grimstad
·
#133
·
|
|
Re: module-info or not module-info..
I fully agree to the comments already posted. Including a compiled module-info now seems to be too risky. JAX-RS should wait for some recommendation from the umbrella spec before integrating
I fully agree to the comments already posted. Including a compiled module-info now seems to be too risky. JAX-RS should wait for some recommendation from the umbrella spec before integrating
|
By
Christian Kaltepoth
·
#134
·
|
|
Re: Status update
Hi Pavel,
could you merge my PR before the next milestone release? https://github.com/jax-rs/api/pull/555
Cheers
Dennis
Hi Pavel,
could you merge my PR before the next milestone release? https://github.com/jax-rs/api/pull/555
Cheers
Dennis
|
By
Dennis Kieselhorst
·
#135
·
|
|
Re: CDI integration
CDI must not be mandatory for the application programmer (so old code does not break), but it is OK for me to make it mandatory to be provided by the container (so new code can safely use it on both
CDI must not be mandatory for the application programmer (so old code does not break), but it is OK for me to make it mandatory to be provided by the container (so new code can safely use it on both
|
By
Markus KARG
·
#136
·
|
|
Re: CDI integration
I think this all is a question of the time frame so application programmers and container providers can plan the migration.
Proposal:
* JAX-RS 2.1: Container MAY provide CDI, but MUST be 100%
I think this all is a question of the time frame so application programmers and container providers can plan the migration.
Proposal:
* JAX-RS 2.1: Container MAY provide CDI, but MUST be 100%
|
By
Markus KARG
·
#137
·
|