toggle quoted messageShow quoted text
So lets us just break everything and be
happy, how inspiring...
On 02/06/17 17:29, Markus KARG wrote:
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 :)
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
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
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.