Date   

Re: module-info or not module-info..

Pavel Bucek
 

Please see https://github.com/jax-rs/api/commit/f84db6dbb13801411560368deaac7d0d5004db65

Manifest entry "Automatic-Module-Name" was added (based on http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-May/000687.html).

Module name for JAX-RS API is "java.ws.rs". Corresponding module-info is already part of the API sources, but it is ignored when compiling on Java SE 8, which is what we use.

Please let me know if you see any issues. (sooner is better).

Regards,
Pavel



On 04/06/2017 23:11, Pavel Bucek wrote:
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.



Re: CDI integration - decision

Pavel Bucek
 

Hi Guillermo,

I really appreciate your activity around this area, but at this point, I don't think we should consider pursuing any change. We are days from Proposed Final Draft and we still don't have ready everything we HAVE TO deliver. Adding any other (non-trivial) changes like this is like sawing off the branch we’re sitting on..

Thanks and regards,
Pavel


On 06/06/2017 18:38, Guillermo González de Agüero wrote:
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







Subresource locator - return instance or class

Pavel Bucek
 

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




Re: Subresource locator - return instance or class

 

Sounds reasonable. If other vendors agree to support this feature, we should add it to the spec.

 

From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek
Sent: Mittwoch, 7. Juni 2017 17:29
To: jaxrs-spec@javaee.groups.io
Subject: [jaxrs] Subresource locator - return instance or class

 

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

 

 


Re: CDI integration - decision

Guillermo González de Agüero
 

Hi Pavel,

I understand it. We (the community) should have raised this before.

I just hope we have this issue as high priority for the next version.

Thanks for your efforts!


Regards

Guillermo González de Agüero


El mié., 7 de junio de 2017 17:17, Pavel Bucek <pavel.bucek@...> escribió:

Hi Guillermo,

I really appreciate your activity around this area, but at this point, I don't think we should consider pursuing any change. We are days from Proposed Final Draft and we still don't have ready everything we HAVE TO deliver. Adding any other (non-trivial) changes like this is like sawing off the branch we’re sitting on..

Thanks and regards,
Pavel


On 06/06/2017 18:38, Guillermo González de Agüero wrote:
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







Re: CDI integration - decision

Arjan Tijms
 

Hi,

It's indeed a tad too late if the Proposed Final Draft is only days away.

Perhaps in the meantime individual application servers can do a little bit more to integrate with CDI out of the box, like JBoss already does today. I certainly like to see what we can do for this at Payara.

Kind regards,
Arjan Tijms



On Wed, Jun 7, 2017 at 11:05 PM, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi Pavel,

I understand it. We (the community) should have raised this before.

I just hope we have this issue as high priority for the next version.

Thanks for your efforts!


Regards

Guillermo González de Agüero

El mié., 7 de junio de 2017 17:17, Pavel Bucek <pavel.bucek@...> escribió:

Hi Guillermo,

I really appreciate your activity around this area, but at this point, I don't think we should consider pursuing any change. We are days from Proposed Final Draft and we still don't have ready everything we HAVE TO deliver. Adding any other (non-trivial) changes like this is like sawing off the branch we’re sitting on..

Thanks and regards,
Pavel


On 06/06/2017 18:38, Guillermo González de Agüero wrote:
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








Re: CDI integration - decision

 

Is the Payara nightly build already able to execute JAX-RS 2.1 applications?

 

From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Arjan Tijms
Sent: Mittwoch, 7. Juni 2017 23:22
To: jaxrs-spec@javaee.groups.io
Subject: Re: [jaxrs] CDI integration - decision

 

Hi,

 

It's indeed a tad too late if the Proposed Final Draft is only days away.

 

Perhaps in the meantime individual application servers can do a little bit more to integrate with CDI out of the box, like JBoss already does today. I certainly like to see what we can do for this at Payara.

 

Kind regards,

Arjan Tijms

 

 

 

On Wed, Jun 7, 2017 at 11:05 PM, Guillermo González de Agüero <z06.guillermo@...> wrote:

Hi Pavel,

 

I understand it. We (the community) should have raised this before.

 

I just hope we have this issue as high priority for the next version.

 

Thanks for your efforts!

 

 

Regards

 

Guillermo González de Agüero

El mié., 7 de junio de 2017 17:17, Pavel Bucek <pavel.bucek@...> escribió:

Hi Guillermo,

I really appreciate your activity around this area, but at this point, I don't think we should consider pursuing any change. We are days from Proposed Final Draft and we still don't have ready everything we HAVE TO deliver. Adding any other (non-trivial) changes like this is like sawing off the branch we’re sitting on..

Thanks and regards,
Pavel

 

On 06/06/2017 18:38, Guillermo González de Agüero wrote:

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



 

 

 


Re: CDI integration - decision

Arjan Tijms
 

Hi,

On Thursday, June 8, 2017, Markus KARG <markus@...> wrote:

Is the Payara nightly build already able to execute JAX-RS 2.1 applications?

Not at the moment, but pieces of work for it have been done (PRs pending) and I hope to be able to work on that ASAP, so should be sooner rather than later.

Kind regards,
Arjan Tijms



 

 

From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Arjan Tijms
Sent: Mittwoch, 7. Juni 2017 23:22
To: jaxrs-spec@javaee.groups.io
Subject: Re: [jaxrs] CDI integration - decision

 

Hi,

 

It's indeed a tad too late if the Proposed Final Draft is only days away.

 

Perhaps in the meantime individual application servers can do a little bit more to integrate with CDI out of the box, like JBoss already does today. I certainly like to see what we can do for this at Payara.

 

Kind regards,

Arjan Tijms

 

 

 

On Wed, Jun 7, 2017 at 11:05 PM, Guillermo González de Agüero <z06.guillermo@...> wrote:

Hi Pavel,

 

I understand it. We (the community) should have raised this before.

 

I just hope we have this issue as high priority for the next version.

 

Thanks for your efforts!

 

 

Regards

 

Guillermo González de Agüero

El mié., 7 de junio de 2017 17:17, Pavel Bucek <pavel.bucek@...> escribió:

Hi Guillermo,

I really appreciate your activity around this area, but at this point, I don't think we should consider pursuing any change. We are days from Proposed Final Draft and we still don't have ready everything we HAVE TO deliver. Adding any other (non-trivial) changes like this is like sawing off the branch we’re sitting on..

Thanks and regards,
Pavel

 

On 06/06/2017 18:38, Guillermo González de Agüero wrote:

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



 

 

 


Re: CDI integration - decision

Sebastian Daschner
 

Hi Pavel,

Totally understandable.

However, let me raise an issue that is related to the CDI topic -- I think the whole CDI integration contains several, different concerns at once:

For developers it would be very helpful to @Inject JAX-RS managed objects -- mainly UriInfo -- into other (CDI) managed beans. We stumbled across this several times and I think it is an easy thing to require in the spec, something like: If the container supports JAX-RS and CDI/JSR 330, then UriInfo (maybe among others) must be injectable with an appropriate scope (here request scoped I guess). Wouldn't involve any other changes in the API.

WDYT?

Cheers,
Sebastian
   


On 06/08/2017 12:21 AM, Pavel Bucek wrote:

Hi Guillermo,

I really appreciate your activity around this area, but at this point, I don't think we should consider pursuing any change. We are days from Proposed Final Draft and we still don't have ready everything we HAVE TO deliver. Adding any other (non-trivial) changes like this is like sawing off the branch we’re sitting on..

Thanks and regards,
Pavel


On 06/06/2017 18:38, Guillermo González de Agüero wrote:
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








Re: CDI integration - decision

Pavel Bucek
 

Hi Sebastian,

that's easy to write in the spec, the consequences are not so simple to consider and implement. Most of the CDI changes won't be in the API at all - its not about the produced API JAR, that's only a tip of the iceberg - don't forget that RI and TCK have to be ready for PFD submission. The sentence you've presented would easily take >2 weeks to implement.

Also, from my experience, doing irreversible changes at the last moment is generally not a good idea, especially when we need to make sure everything else is done in acceptable quality.

Thanks and regards,
Pavel


On 09/06/2017 03:53, Sebastian Daschner wrote:

Hi Pavel,

Totally understandable.

However, let me raise an issue that is related to the CDI topic -- I think the whole CDI integration contains several, different concerns at once:

For developers it would be very helpful to @Inject JAX-RS managed objects -- mainly UriInfo -- into other (CDI) managed beans. We stumbled across this several times and I think it is an easy thing to require in the spec, something like: If the container supports JAX-RS and CDI/JSR 330, then UriInfo (maybe among others) must be injectable with an appropriate scope (here request scoped I guess). Wouldn't involve any other changes in the API.

WDYT?

Cheers,
Sebastian
   


On 06/08/2017 12:21 AM, Pavel Bucek wrote:

Hi Guillermo,

I really appreciate your activity around this area, but at this point, I don't think we should consider pursuing any change. We are days from Proposed Final Draft and we still don't have ready everything we HAVE TO deliver. Adding any other (non-trivial) changes like this is like sawing off the branch we’re sitting on..

Thanks and regards,
Pavel


On 06/06/2017 18:38, Guillermo González de Agüero wrote:
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









Re: Subresource locator - return instance or class

Sergey Beryozkin
 

Hi Pavel

As far as I understand that is what the idea behind ResourceContext.getResource(Class<T>) was ?

Thanks, Sergey

On 07/06/17 16:29, Pavel Bucek wrote:

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





doc property for all JAX-RS annotations

Sergey Beryozkin
 

Hi

I created an issue awhile back to get something like

@Path(value="/", doc="the path")

supported for all of the JAX-RS annotations.

The idea is to come up with a single well known property that the future code or service api info generation tools can use.

For example, some use JavaDocs - which overloads it a bit because what is documented at the Java level and what is visible to the HTTP service consumer may not always make sense to keep in sync.
Then we have Swagger2 annotations related to the docs, in CXF we also have @Description annotations that can be used by the WADL filter.

Having a 'doc' would be a simple improvement which can help to minimize the 'noise' related to everyone using their own annotations/approaches to documenting JAX-RS API...

Sergey


Re: Subresource locator - return instance or class

Pavel Bucek
 

Hi Sergey,

that's true, but does that contradict what we did?

(I do see that as a shortcut, which makes sense to have, nothing more).

Regards,
Pavel


On 13/06/2017 13:33, Sergey Beryozkin wrote:
Hi Pavel

As far as I understand that is what the idea behind ResourceContext.getResource(Class<T>) was ?

Thanks, Sergey

On 07/06/17 16:29, Pavel Bucek wrote:

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






Re: doc property for all JAX-RS annotations

Pavel Bucek
 

Hi Sergey,

I believe that javadoc is the right place for documentation like this. Not to mention that writing the documentation to the annotation string literal is not very convenient, especially when the text would span multiple lines.

I think I get what usecase addressed here, but seems like the proposed solution would not provide solution of related issues. It would reduce "documentation" annotations, but various doc tools would still require additional annotations.

Thanks and regards,
Pavel

On 13/06/2017 14:17, Sergey Beryozkin wrote:
Hi

I created an issue awhile back to get something like

@Path(value="/", doc="the path")

supported for all of the JAX-RS annotations.

The idea is to come up with a single well known property that the future code or service api info generation tools can use.

For example, some use JavaDocs - which overloads it a bit because what is documented at the Java level and what is visible to the HTTP service consumer may not always make sense to keep in sync.
Then we have Swagger2 annotations related to the docs, in CXF we also have @Description annotations that can be used by the WADL filter.

Having a 'doc' would be a simple improvement which can help to minimize the 'noise' related to everyone using their own annotations/approaches to documenting JAX-RS API...

Sergey



Re: Subresource locator - return instance or class

Sergey Beryozkin
 

Hi Pavel

You are right, makes sense

Sergey

On 13/06/17 18:57, Pavel Bucek wrote:

Hi Sergey,

that's true, but does that contradict what we did?

(I do see that as a shortcut, which makes sense to have, nothing more).

Regards,
Pavel


On 13/06/2017 13:33, Sergey Beryozkin wrote:
Hi Pavel

As far as I understand that is what the idea behind ResourceContext.getResource(Class<T>) was ?

Thanks, Sergey

On 07/06/17 16:29, Pavel Bucek wrote:

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







Re: doc property for all JAX-RS annotations

Sergey Beryozkin
 

Hi Pavel

I agree (2nd time in a row :-))

Cheers, Sergey

On 14/06/17 08:18, Pavel Bucek wrote:
Hi Sergey,

I believe that javadoc is the right place for documentation like this. Not to mention that writing the documentation to the annotation string literal is not very convenient, especially when the text would span multiple lines.

I think I get what usecase addressed here, but seems like the proposed solution would not provide solution of related issues. It would reduce "documentation" annotations, but various doc tools would still require additional annotations.

Thanks and regards,
Pavel


On 13/06/2017 14:17, Sergey Beryozkin wrote:
Hi

I created an issue awhile back to get something like

@Path(value="/", doc="the path")

supported for all of the JAX-RS annotations.

The idea is to come up with a single well known property that the future code or service api info generation tools can use.

For example, some use JavaDocs - which overloads it a bit because what is documented at the Java level and what is visible to the HTTP service consumer may not always make sense to keep in sync.
Then we have Swagger2 annotations related to the docs, in CXF we also have @Description annotations that can be used by the WADL filter.

Having a 'doc' would be a simple improvement which can help to minimize the 'noise' related to everyone using their own annotations/approaches to documenting JAX-RS API...

Sergey





Status of JAXB in JAX-RS 2.1

 

Dear Spec Leads,

 

the JSR 370 charter says that with JAX-RS 2.1 the JAXB technology should become conditional.

 

Looking at the last spec draft I cannot find anything about that. Quite contrary is still is rather clear about the fact what an implementation has to do with JAXBElement etc.

 

So I'd like to ask what to do with this issue. Will JAXB stay as it is? Or do you have plans to make it obsolete in JAX-RS 2.1 final draft?

 

Thanks

-Markus


Re: Status of JAXB in JAX-RS 2.1

Pavel Bucek
 

Hi Markus,

we learned that it is not possible to do that in this release.

The main issue is that we cannot just deprecate something, there is a strict policy related to making backwards incompatible changes - we'd need to create separate specification, which would replace deprecated/removed functionality.

What we could do is to add a note to the JaxbLink javadoc saying "This class will be removed at some point, replaced by FOOBAR"; the problem is that we don't have FOOBAR at the moment..

Regards,
Pavel


On 15/06/2017 16:31, Markus KARG wrote:

Dear Spec Leads,

 

the JSR 370 charter says that with JAX-RS 2.1 the JAXB technology should become conditional.

 

Looking at the last spec draft I cannot find anything about that. Quite contrary is still is rather clear about the fact what an implementation has to do with JAXBElement etc.

 

So I'd like to ask what to do with this issue. Will JAXB stay as it is? Or do you have plans to make it obsolete in JAX-RS 2.1 final draft?

 

Thanks

-Markus



Re: Status of JAXB in JAX-RS 2.1

Sergey Beryozkin
 

I see no practical point in doing it anyway. It's unlikely that any of the existing JAX-RS implementations will choose to annoy some of its users and just do not ship JAXB-aware providers - they will be needed for the next 10 years at least anyway even though the new services are more likely to use JSON/etc

Sergey

On 15/06/17 16:31, Pavel Bucek wrote:

Hi Markus,

we learned that it is not possible to do that in this release.

The main issue is that we cannot just deprecate something, there is a strict policy related to making backwards incompatible changes - we'd need to create separate specification, which would replace deprecated/removed functionality.

What we could do is to add a note to the JaxbLink javadoc saying "This class will be removed at some point, replaced by FOOBAR"; the problem is that we don't have FOOBAR at the moment..

Regards,
Pavel


On 15/06/2017 16:31, Markus KARG wrote:

Dear Spec Leads,

 

the JSR 370 charter says that with JAX-RS 2.1 the JAXB technology should become conditional.

 

Looking at the last spec draft I cannot find anything about that. Quite contrary is still is rather clear about the fact what an implementation has to do with JAXBElement etc.

 

So I'd like to ask what to do with this issue. Will JAXB stay as it is? Or do you have plans to make it obsolete in JAX-RS 2.1 final draft?

 

Thanks

-Markus




Re: Status of JAXB in JAX-RS 2.1

Santiago Pericas-Geertsen
 


On Jun 15, 2017, at 11:30 AM, Sergey Beryozkin <sberyozkin@...> wrote:

I see no practical point in doing it anyway. It's unlikely that any of the existing JAX-RS implementations will choose to annoy some of its users and just do not ship JAXB-aware providers - they will be needed for the next 10 years at least anyway even though the new services are more likely to use JSON/etc

 +1

— Santiago


Sergey 
On 15/06/17 16:31, Pavel Bucek wrote:

Hi Markus,

we learned that it is not possible to do that in this release.

The main issue is that we cannot just deprecate something, there is a strict policy related to making backwards incompatible changes - we'd need to create separate specification, which would replace deprecated/removed functionality.

What we could do is to add a note to the JaxbLink javadoc saying "This class will be removed at some point, replaced by FOOBAR"; the problem is that we don't have FOOBAR at the moment..

Regards,
Pavel


On 15/06/2017 16:31, Markus KARG wrote:
Dear Spec Leads,
 
the JSR 370 charter says that with JAX-RS 2.1 the JAXB technology should become conditional.
 
Looking at the last spec draft I cannot find anything about that. Quite contrary is still is rather clear about the fact what an implementation has to do with JAXBElement etc.
 
So I'd like to ask what to do with this issue. Will JAXB stay as it is? Or do you have plans to make it obsolete in JAX-RS 2.1 final draft?
 
Thanks
-Markus