Guillermo González de Agüero
toggle quoted messageShow quoted text
As far as I understand, the module dependency Pavel talked about would just mean that the CDI API would be required to be there, not that it'd require a CDI implementation to work. It wouldn't break applications.
For Java EE application servers, I think it can be safely forced though.
Any CDI expert can confirm the extension with the BeforeBeanDiscovery observer I proposed would work here? It that case, the spec would not need the dependency (only on EE servers implementations would be required to support it).
Guillermo González de Agüero
El sáb., 3 de junio de 2017 10:44, Markus KARG <markus@...
I think this all is a question of the time frame so application programmers and container providers can plan the migration.
* JAX-RS 2.1: Container MAY provide CDI, but MUST be 100% backwards compatible.
* JAX-RS 2.2: Container SHOULD provide CDI, but MUST be 100% backwards compatible.
* JAX-RS 2.3: Container MUST provide CDI, but MUST be 100% backwards compatible; Old DI is marked as deprecated.
* JAX-RS 2.4: Container MUST provide CDI, but MAY still provide old annotations; Old DI is marked as deprecated and pruning date is told (JAX-RS 3.0).
* JAX-RS 3.0: Container MUST provide CDI, but SHOULD NOT still provide old annotations; Old DI is officially pruned.
* JAX-RS 3.1: Container MUST provide CDI, but MUST NOT still provide old annotations; Old DI is finally gone.
On Fri, Jun 2, 2017 at 7:03 PM, Sergey Beryozkin <sberyozkin@...> wrote:
Makes sense as long as CDI is not mandatory for 2.1.
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 better.
We deprecated @ManagedBean for JSF 2.3, and I hope to be able and given permission to totally prune it in a future release. JSF is already big enough and should concentrate on the web framework and UI components part without being slowed down and bloated by also having to maintain its own DI engine.
I can't imagine the same wouldn't hold for JAX-RS to some degree. Why maintain an entire independent DI engine if there's one in the platform that you can just use, or outside the platform can just bundle?
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, I see some won't have a problem at all if JAX-RS becomes owned truly and finally by EE only, I'm not going to keep spending my time any longer on this argument
On 02/06/17 17:43, Markus KARG wrote:
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 conditional, which also means to break things in some cases!
You can still support the old annotations to keep old code running on JAX-RS 2.x, but we should allow to write new applications using latest technology, and we should push people into using latest stuff by _deprecating_ old annotations starting with JAX-RS 3.x.
So lets us just break everything and be happy, how inspiring...
On 02/06/17 17:29, Markus KARG wrote:
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 specification as being mandatory. For me, CDI is such a fundamental API that I even would love to have it being part of Java SE !
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 and it is in our interests to ensure it does not happen.
Lets do the best CDI integration ever but avoid losing the 'independence' of the core JAX-RS API.
On 02/06/17 16:32, Pavel Bucek wrote:
consider this as a subthread :)
On 02/06/2017 16:27, Guillermo González de Agüero wrote:
Ad @Stereotype - I'd need to check whether we can easily do that, since it would create a dependency on javax.enterprise.inject. I don't understand the remark about that annotation not being there in the runtime - it will be there, it has retention runtime (otherwise it wouldn't work)
I meant CDI will only be needed at (JAX-RS implementation) compile time. Applications won't need it as annotations not present on the classpath are just erased at runtime. So people using Spring or wathever non-CDI framework won't see any difference. Hope it clearer now?
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 info, I wasn't aware of this behavior.
There is a little (forward) issue with this - similarly to any other "optional" dependency, there will be issues with this when Java 9 modules are used. Once the dependency on CDI API is declared in JAX-RS API module-info, CDI API will be required on the module path of any JAX-RS enabled app/code (at least for compilation).
Not saying that is a deal breaker, it's just something we need to consider.