|
Hi Guillermo,
The only caveat is that the implementation
will need to know the classes by that point, which is before
ServletContainerInitializer is fired
that certainly is a problem, we do rely on servlet scanning..
Regards,
Pavel
On 02/06/2017 19:11, Guillermo González
de Agüero wrote:
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 http://www.next-presso.com/2017/02/nobody-expects-the-cdi-portable-extensions/):
public class JaxRsExtension implements Extension {
public void addClasses(@Observes BeforeBeanDiscovery
bbd) {
bbd.addAnnotatedType(RestResource.class,
RestResource.class.getName()).
add(RequestScoped.Literal.INSTANCE);
}
}
The only caveat is that the implementation will need to know
the classes by that point, which is before
ServletContainerInitializer is fired (I'm not sure that's a
problem; just stating so implementers may comment on it). That
prevents the hard dependency on CDI, making everyone happy.
Thoughts?
Regards,
Guillermo González de Agüero
|
|
|
Hi Dennis,
I can't even if I wanted to - you are not on the OCA page
(http://www.oracle.com/technetwork/community/oca-486395.html), so
I cannot accept any code contribution from you.
I'm still not sure whether we want to add these as client builder
methods or as a properties and if latter, where the properties
should be defined. The issue is on my list, but I cannot promise
that it will be part of the next milestone build.
Regards,
Pavel
toggle quoted messageShow quoted text
|
|
|
Re: module-info or not module-info..
I'm waiting for the implementation (since I'd like to test it before
the actual commit), but the problem is that I do have some
experience with "breaking" changes between jdk 9 builds, so I'm not
sure whether the header name is final or not :)
I guess we can ask around about this - as you say, introducing
manifest entry is not a problem.
Thanks,
Pavel
toggle quoted messageShow quoted text
On 03/06/2017 12:39, Gunnar Morling via
Groups.Io wrote:
One option to consider is to add the
"Automatic-Module-Name" header to the spec JAR's MANIFEST.MF.
This header entry is foreseen by JPMS (some background)
to specify a module name, should a non-modularized JAR be used as
an automatic module (instead of deriving a module name from the
JAR file name). The change for this hasn't landed int the latest
JDK 9 preview release yet (b172 at the time of writing), but once
it will, we'd make use of this for Bean Validation. I don't think
there's any risk of adding this header, esp. it can be done while
building with Java 8.
|
|
|
Re: module-info or not module-info..
toggle quoted messageShow quoted text
On 03/06/2017 08:11, Ivar Grimstad
wrote:
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 include it now as it may
change then depending on how that goes.
Ivar
On Fri, Jun 2, 2017 at 6:55 PM Andy McCright
< andymc@...>
wrote:
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 whether
to include a module-info for a 2.1.1 maintenance
release. If JPMS is on by default when Java 9 ships,
I would be in favor of including it in the maintenance
release.
Thanks,
-----
Original message -----
From: "Markus KARG" <markus@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: Re: [jaxrs] module-info or not module-info..
Date: Fri, Jun 2, 2017 11:26 AM
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 Java SE still will
be 8. Target platforms for JAX-RS 2.1 are Java SE
8 and Java EE 8. So I do neither see a need nor
any real benefit for prematurely supporting Java
SE 9. It would imply a risk, even if a small one,
so we should abstain from that.
It think it would be wise also, not to include
Java SE 9 support in JAX-RS 2.1.1. Instead, we
should plan to provide Java 9 support in JAX-RS 3,
but right now start to work on that once JAX-RS
2.1 is released.
-Markus
-----Original Message-----
From: jaxrs-spec@javaee.groups.io
[mailto:jaxrs-spec@javaee.groups.io]
On Behalf Of Pavel Bucek
Sent: Freitag, 2. Juni 2017 16:38
To: jaxrs-spec@javaee.groups.io
Subject: [jaxrs] module-info or not module-info..
Dear experts,
we originally intended to include compiled
module-info to JAX-RS API jar. Original plan was
to prepare a release on final or "almost" final
Java SE 9 compliant JDK.
As you might know, Java SE 9 was postponed and the
JAX-RS release will most likely happen before that
date.
Should we include compiled module-info, even when
the compilation was done by early access build of
JDK 9? I would believe that there won't be any
change in the bytecode format, but it could
happen..
From my point of view, it might be better to NOT
include compiled module-info now and (if
demanded), release JAX-RS 2.1.1 (or something like
that) with updated API jar.
Any thoughts/comments?
Thanks,
Pavel
--
Java Champion, JCP EC/EG Member, JUG Leader
|
|
|
Re: module-info or not module-info..
Gunnar Morling
One option to consider is to add the "Automatic-Module-Name" header to the spec JAR's MANIFEST.MF. This header entry is foreseen by JPMS ( some background) to specify a module name, should a non-modularized JAR be used as an automatic module (instead of deriving a module name from the JAR file name). The change for this hasn't landed int the latest JDK 9 preview release yet (b172 at the time of writing), but once it will, we'd make use of this for Bean Validation. I don't think there's any risk of adding this header, esp. it can be done while building with Java 8.
|
|
|
Guillermo González de Agüero
Hi,
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).
Regards,
Guillermo González de Agüero
El sáb., 3 de junio de 2017 10:44, Markus KARG < markus@...> escribió: 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% 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. -Markus Hi, 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.
Cheers, Sergey
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.
Regards,
Pavel
|
|
|
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% 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. -Markus
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Arjan Tijms
Sent: Freitag, 2. Juni 2017 21:17
To: jaxrs-spec@javaee.groups.io
Subject: Re: [jaxrs] CDI integration Hi, 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.
Cheers, Sergey
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.
Regards,
Pavel
|
|
|
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 Java SE 8 and Java EE 8).
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Sergey Beryozkin
Sent: Freitag, 2. Juni 2017 19:04
To: jaxrs-spec@javaee.groups.io
Subject: Re: [jaxrs] 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, 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.
Cheers, Sergey
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.
Regards,
Pavel
|
|
|
Dennis Kieselhorst
|
|
|
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 module-info.
Christian
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 include it now as it may change then depending on how that goes.
Ivar On Fri, Jun 2, 2017 at 6:55 PM Andy McCright < andymc@...> wrote: 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 whether to include a module-info for a 2.1.1 maintenance release. If JPMS is on by default when Java 9 ships, I would be in favor of including it in the maintenance release.
Thanks,
----- Original message -----
From: "Markus KARG" <markus@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: Re: [jaxrs] module-info or not module-info..
Date: Fri, Jun 2, 2017 11:26 AM
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 Java SE still will be 8. Target platforms for JAX-RS 2.1 are Java SE 8 and Java EE 8. So I do neither see a need nor any real benefit for prematurely supporting Java SE 9. It would imply a risk, even if a small one, so we should abstain from that.
It think it would be wise also, not to include Java SE 9 support in JAX-RS 2.1.1. Instead, we should plan to provide Java 9 support in JAX-RS 3, but right now start to work on that once JAX-RS 2.1 is released.
-Markus
-----Original Message-----
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek
Sent: Freitag, 2. Juni 2017 16:38
To: jaxrs-spec@javaee.groups.io
Subject: [jaxrs] module-info or not module-info..
Dear experts,
we originally intended to include compiled module-info to JAX-RS API jar. Original plan was to prepare a release on final or "almost" final Java SE 9 compliant JDK.
As you might know, Java SE 9 was postponed and the JAX-RS release will most likely happen before that date.
Should we include compiled module-info, even when the compilation was done by early access build of JDK 9? I would believe that there won't be any change in the bytecode format, but it could happen..
From my point of view, it might be better to NOT include compiled module-info now and (if demanded), release JAX-RS 2.1.1 (or something like that) with updated API jar.
Any thoughts/comments?
Thanks,
Pavel
--
Java Champion, JCP EC/EG Member, JUG Leader
|
|
|
Re: module-info or not module-info..
Ivar Grimstad
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 include it now as it may change then depending on how that goes.
Ivar
On Fri, Jun 2, 2017 at 6:55 PM Andy McCright < andymc@...> wrote: 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 whether to include a module-info for a 2.1.1 maintenance release. If JPMS is on by default when Java 9 ships, I would be in favor of including it in the maintenance release.
Thanks,
----- Original message -----
From: "Markus KARG" <markus@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: Re: [jaxrs] module-info or not module-info..
Date: Fri, Jun 2, 2017 11:26 AM
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 Java SE still will be 8. Target platforms for JAX-RS 2.1 are Java SE 8 and Java EE 8. So I do neither see a need nor any real benefit for prematurely supporting Java SE 9. It would imply a risk, even if a small one, so we should abstain from that.
It think it would be wise also, not to include Java SE 9 support in JAX-RS 2.1.1. Instead, we should plan to provide Java 9 support in JAX-RS 3, but right now start to work on that once JAX-RS 2.1 is released.
-Markus
-----Original Message-----
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek
Sent: Freitag, 2. Juni 2017 16:38
To: jaxrs-spec@javaee.groups.io
Subject: [jaxrs] module-info or not module-info..
Dear experts,
we originally intended to include compiled module-info to JAX-RS API jar. Original plan was to prepare a release on final or "almost" final Java SE 9 compliant JDK.
As you might know, Java SE 9 was postponed and the JAX-RS release will most likely happen before that date.
Should we include compiled module-info, even when the compilation was done by early access build of JDK 9? I would believe that there won't be any change in the bytecode format, but it could happen..
From my point of view, it might be better to NOT include compiled module-info now and (if demanded), release JAX-RS 2.1.1 (or something like that) with updated API jar.
Any thoughts/comments?
Thanks,
Pavel
--
Java Champion, JCP EC/EG Member, JUG Leader
|
|
|
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.
That said CDI / JSR 330 is (and IMO should be) the way of how to
@Inject any managed objects into anywhere the developers like. JSF
is a good example. Another one is @EJB vs @Inject.
Cheers,
Sebastian
toggle quoted messageShow quoted text
On 06/03/2017 06:56 AM, Arjan Tijms
wrote:
Hi,
|
|
|
Arjan Tijms
|
|
|
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 dependency. I know many do use CDI with CXF, RI
for sure, and very likely RestEasy, which I'm happy with. This
relentless push to get CDI as a required dep won't help with the
cause of spreading JAX-RS beyond EE boundaries. I've no more
energy left to continue this discussion, sorry, glad I'm away for
the next week and a bit
Have fun
Sergey
toggle quoted messageShow quoted text
On 02/06/17 22:12, Arjan Tijms wrote:
-1
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
release process, so if we announce it to be pruned for JSF 2.4 (or
whatever the new version will be), it will not be actually made
optional until JSF 2.5.
|
|
|
Arjan Tijms
-1
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 release process, so if we announce it to be pruned for JSF 2.4 (or whatever the new version will be), it will not be actually made optional until JSF 2.5.
|
|
|
toggle quoted messageShow quoted text
On 02/06/17 20:16, Arjan Tijms wrote:
Hi,
|
|
|
Arjan Tijms
|
|
|
Guillermo González de Agüero
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 http://www.next-presso.com/2017/02/nobody-expects-the-cdi-portable-extensions/): public class JaxRsExtension implements Extension {
public void addClasses(@Observes BeforeBeanDiscovery bbd) {
bbd.addAnnotatedType(RestResource.class, RestResource.class.getName()).
add(RequestScoped.Literal.INSTANCE);
}
}The only caveat is that the implementation will need to know the classes by that point, which is before ServletContainerInitializer is fired (I'm not sure that's a problem; just stating so implementers may comment on it). That prevents the hard dependency on CDI, making everyone happy.
Thoughts?
Regards,
Guillermo González de Agüero
On Fri, Jun 2, 2017 at 5:32 PM, Pavel Bucek <pavel.bucek@...> wrote:
consider this as a subthread :)
On 02/06/2017 16:27, Guillermo González de Agüero wrote:
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.
Regards,
Pavel
|
|
|
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, 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
toggle quoted messageShow quoted text
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.
Cheers, Sergey
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.
Regards,
Pavel
|
|
|
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 whether to include a module-info for a 2.1.1 maintenance release. If JPMS is on by default when Java 9 ships, I would be in favor of including it in the maintenance release.
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] module-info or not module-info..
Date: Fri, Jun 2, 2017 11:26 AM
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 Java SE still will be 8. Target platforms for JAX-RS 2.1 are Java SE 8 and Java EE 8. So I do neither see a need nor any real benefit for prematurely supporting Java SE 9. It would imply a risk, even if a small one, so we should abstain from that.
It think it would be wise also, not to include Java SE 9 support in JAX-RS 2.1.1. Instead, we should plan to provide Java 9 support in JAX-RS 3, but right now start to work on that once JAX-RS 2.1 is released.
-Markus
-----Original Message-----
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek
Sent: Freitag, 2. Juni 2017 16:38
To: jaxrs-spec@javaee.groups.io
Subject: [jaxrs] module-info or not module-info..
Dear experts,
we originally intended to include compiled module-info to JAX-RS API jar. Original plan was to prepare a release on final or "almost" final Java SE 9 compliant JDK.
As you might know, Java SE 9 was postponed and the JAX-RS release will most likely happen before that date.
Should we include compiled module-info, even when the compilation was done by early access build of JDK 9? I would believe that there won't be any change in the bytecode format, but it could happen..
From my point of view, it might be better to NOT include compiled module-info now and (if demanded), release JAX-RS 2.1.1 (or something like that) with updated API jar.
Any thoughts/comments?
Thanks,
Pavel
|
|
|
