Dear experts,

we are in a stage when we are re-reading spec document and javadoc (you're welcomed to help us - if you have some favorite typo anywhere in JAX-RS and you wan't to get rid of it, now is the time to report it) and one particular thing was noticed:

specification supports only returning an instance as a subresource, thus:

@Path("sub1")

public SubResource getSubResourceLocator1() {

    return new SubResource();

}

is supported and

@Path("sub2")

public Class<SubResource> getSubResourceLocator2() {

    return SubResource.class;

}

is not.

RI currently supports both cases and I'm wondering whether we should add that into the specification.

There is obvious advantage of the latter approach, since the instance will be managed (in a correct scope) by the JAX-RS runtime and more importantly, it will be injected, so application developer don't have to inject evertyhing required in a root resource and pass injected values in a constructor of returned instance.

What do you think?

Thanks and regards,
Pavel

Hi,

I invited Antoine Sabot Durand (CDI Spec lead) to join the conversation and he replied me today that he and the Weld team will have a look at the issue as they have already been helping other spec integrate with CDI.

CDI 2.0 is already final but maybe they have some ideas that could help here going some step foward. I ask you and Santiago and the rest of the EG please to wait a little for them to comment here before taking a definitive decission.

Regards,

Guillermo González de Agüero

On Tue, Jun 6, 2017 at 5:47 PM, Pavel Bucek <pavel.bucek@...> wrote:

Dear experts,

Thank you for a productive discussion about CDI integration. We now have a good understanding of what can be achieved when using the new CDI 2.0 API.

Our recent analysis has concluded that providing a better CDI integration would require more experimentation than what we can do in this minor release. We also don't want to introduce "hard" dependency on CDI API to the JAX-RS API as many JAX-RS developers rely on running JAX-RS outside of CDI context.

We agree that CDI can be used as the "glue" of the whole Java EE platform and JAX-RS can do more in terms of the CDI integration when running in a Java EE container. Currently, such enhancements are NOT forbidden at the spec level and JAX-RS providers are free to introduce support that goes beyond what JAX-RS spec mandates. Further experiment in this area can help to gather more feedback for any future re-evaluation of improved CDI/JAX-RS integration story. Also, this feedback may help CDI owners to provide public API enhancements to enable full JAX-RS /CDI integration in a portable way.

Thanks again for the discussion on the mailing list.

Best regards,
Pavel & Santiago

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

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.

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

Even it wouldn't be a problem, if @Path annotation isn't a bean defining annotation, the event wouldn't be fired at all in the "annotated" discovery mode if there are no other CDI beans (possible if resources only want to inject beans from other modules).

The approach of turning @Path into a stereotype is very nice and it doesn't require a runtime dependency on CDI at all. CDI API would be needed only to compile JAX-RS API because annotations not found on the classpath are ignored by the JVM, CDI impl wouldn't be needed at all. If we specify @RequestScoped in the stereotype, it would just specify what I believe all implementations do anyway -> create a resource instance per request, which is the default behavior mandated by the previous JAX-RS 2.0
It would be possible to override the scope for each class in a standard way by providing a scope annotation along with @Path.

Furthermore, if @Path is a stereotype, it would also become a bean-defining annotation and turn on CDI by default, even if there are no other CDI beans in the module, which is what most people would expect.

Ondro

Hey Pavel,

thanks a lot. It is great to finally see this feature in the spec.

Just one minor typo: "withing" should be "within". See:

https://github.com/jax-rs/api/blob/9097eb290b3ba96201d4286034963e6236af5595/jaxrs-api/src/main/java/javax/ws/rs/client/ClientBuilder.java#L296

Christian

2017-06-05 21:13 GMT+02:00 Pavel Bucek <pavel.bucek@...>:

please see https://github.com/jax-rs/api/commit/d18207327468870ab885120c3790e36a741af26d

On 04/06/2017 23:15, Pavel Bucek wrote:

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

On 03/06/2017 10:22, Dennis Kieselhorst wrote:

Hi Pavel,

could you merge my PR before the next milestone release? https://github.com/jax-rs/api/pull/555

Cheers
Dennis

--

Christian Kaltepoth

Blog: http://blog.kaltepoth.de/

Twitter: http://twitter.com/chkal

GitHub: https://github.com/chkal

please see https://github.com/jax-rs/api/commit/d18207327468870ab885120c3790e36a741af26d

On 04/06/2017 23:15, Pavel Bucek wrote:

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

On 03/06/2017 10:22, Dennis Kieselhorst wrote:

Hi Pavel,

could you merge my PR before the next milestone release? https://github.com/jax-rs/api/pull/555

Cheers
Dennis

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

On 03/06/2017 10:22, Dennis Kieselhorst wrote:

Hi Pavel,

could you merge my PR before the next milestone release? https://github.com/jax-rs/api/pull/555

Cheers
Dennis

Hi Pavel,

Any chance for considering the latest proposal for passing the
(highest-quality) request locale to Bean Validation?

Thanks,

--Gunnar


2017-06-02 14:48 GMT+02:00 Pavel Bucek <pavel.bucek@oracle.com>:

Dear experts,

as you might have noticed, we dealt with several small issues in the past
couple of weeks. Notable ones:

- @Priority for providers
- JSON-B integration update
- Introduction of JSON-P integration
- HTTP PATCH support on the server (client side was just reverted)
- CompletionStage can be returned from the resource method
- Response API: AutoCloseable + Status#asEnum
- Support for new HTTP Status codes

Etc.

Complete list of closed issues:

https://github.com/jax-rs/api/issues?q=is%3Aissue+is%3Aclosed+sort%3Aupdated-desc

API commits:

https://github.com/jax-rs/api/commits/master

Spec commits:

https://github.com/jax-rs/spec/commits/master

If you have any questions or suggestions about changes we've made, please
let us know.

We are going to release another API milestone build soon and it will be most
likely last milestone before submitting Proposed Final Draft.

Thanks and regards,
Pavel

Dear experts,

as you might have noticed, we dealt with several small issues in the past
couple of weeks. Notable ones:

- @Priority for providers
- JSON-B integration update
- Introduction of JSON-P integration
- HTTP PATCH support on the server (client side was just reverted)
- CompletionStage can be returned from the resource method
- Response API: AutoCloseable + Status#asEnum
- Support for new HTTP Status codes

Etc.

Complete list of closed issues:

https://github.com/jax-rs/api/issues?q=is%3Aissue+is%3Aclosed+sort%3Aupdated-desc

API commits:

https://github.com/jax-rs/api/commits/master

Spec commits:

https://github.com/jax-rs/spec/commits/master

If you have any questions or suggestions about changes we've made, please
let us know.

We are going to release another API milestone build soon and it will be most
likely last milestone before submitting Proposed Final Draft.

Thanks and regards,
Pavel