Clarification on auto-discovery of singletons #605
Comments
|
Markus,
Aren’t you describing an implementation bug rather than an spec issue? If @singleton is used, why should the JAX-RS spec say anything else? Semantics seem pretty clear to me.
Back to the issue, do you think this was in any way related to implementing Feature?
— Santiago
… On Mar 24, 2018, at 2:03 PM, Markus KARG ***@***.***> wrote:
A JAX-RS application can explicitly declare singleton instances by implementing Application#getSingletons. There should be an unambiguous way to also declare singletons when not implementing this method, i. e. when using auto-discovery and annotations.
Example: One class is annotated as @javax.inject.Singleton and it implements Feature, ContainerRequestFilter and ContainerResponseFilter. A short test using Payara/Jersey discovered that actually two (not one, not three, but really two) instances of that class had been created. This is "near" to a singleton, but not exactly a singleton.
Implementors of JAX-RS extensions need a clear API-level way to ensure that their extension is always exactly one class at runtime, on any JAX-RS implementation, being used by any JAX-RS application. For example, a filter which gets configured (hence is a Feature) once and that puts infos at requests and analyzes this infos at responses MUST be exactly one single instance.
This clearly cannot be solved by the API but in fact is a spec issue. As there is no spec issue tracker right now, I put it here. My proposal is that we agree upon adding a sentence like: "A compliant implementation guarantees that for a class annotated with javax.inject.Singleton exactly one single instance is created, and that particular instance is treated as if it would have been returned by Application#getSingletons".
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#605>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFU9N31jLM7CbXvpdOSN7xehR9c02a0xks5thopZgaJpZM4S51dH>.
|
|
@spericas The problem is that the JAX-RS spec does not say how to declare a singleton using annotations. So we both share the intention that it is a bug, but "formally" it is not. The spec completely leaves this question open to EJB and CDI. But what if neither is used? Also I would not say that it is clearly a bug that Jersey / Payara created two instances instead of one -- maybe this is by intention due to a good reason we simply do not see (I doubt that)? What we should do in JAX-RS 2.2 is to explicitly say in the spec that |
|
I agree with @mkarg on this. There is currently no way to declare a singleton using annotations in the JAX-RS component model. Using |
|
On Mar 26, 2018, at 1:51 PM, Markus KARG ***@***.***> wrote:
@spericas <https://github.com/spericas> The problem is that the JAX-RS spec does not say how to declare a singleton using annotations. So we both share the intention that it is a bug, but "formally" it is not. The spec completely leaves this question open to EJB and CDI. But what if neither is used? Also I would not say that it is clearly a bug that Jersey / Payara created two instances instead of one -- maybe this is by intention due to a good reason we simply do not see (I doubt that)?
What we should do in JAX-RS 2.2 is to explicitly say in the spec that @javax.inject.Singleton MUST produce exactly one single instance, even when neither EJB nor CDI is not used. Using this phrase, it is 100% clear that Jersey / Payara's current behaviour is definitively a bug and MUST fail the TCK.
I see, I thought you were talking about a runtime with EJBs. If neither CDI nor EJBs are used, there is no way to declare this, I agree.
However, extending the JAX-RS component model to support @singleton seems like a step in the wrong direction. I believe we should not extend that component model anymore, but rather as discussed elsewhere, move away from it and focus on CDI.
— Santiago
|
|
On Mar 26, 2018, at 2:12 PM, Christian Kaltepoth ***@***.***> wrote:
I agree with @mkarg <https://github.com/mkarg> on this. There is currently no way to declare a singleton using annotations in the JAX-RS component model. Using @javax.inject.Singleton would be a way to solve this.
I disagree. I don’t think we should extend that model any longer. Any future work in the DI area should be focused on CDI, in my opinion. It is complicated as it is now.
— Santiago
|
|
@spericas I really do share the vision to use CDI in 3.0 for the singleton topic, but I dislike the idea to wait for long time until we come up with a clear solution for the issue. In fact I want a solution for 2.2, and for non-CDI applications, too. Adding an annotation is not breaking compatibility, so there is no other technical force to wait for 3.0 besides you personally not wanting to invest the effort. Also you might call me nitpicking, but there is no singleton annotation in CDI, but only |
|
Markus,
There is certainly no breaking compatibility issue, of course. By default, providers are singletons in JAX-RS already. Thus, I just don’t see the urgency justifying all JAX-RS implementations to do more work in the DI area when clearly JAX-RS should have never been in that business.
As for @singleton vs. @ApplicationScoped, I’m not certain you can guarantee that they are always the same, but they should be the same for most applications which makes the discussion mostly academic IMO.
— Santiago
… On Mar 26, 2018, at 5:41 PM, Markus KARG ***@***.***> wrote:
@spericas <https://github.com/spericas> I really do share the vision to use CDI in 3.0 for the singleton topic, but I dislike the idea to wait for long time until we come up with a clear solution for the issue. In fact I want a solution for 2.2, and for non-CDI applications, too. Adding an annotation is not breaking compatibility, so there is no other technical force to wait for 3.0 besides you personally not wanting to invest the effort. Also you might call me nitpicking, but there is no singleton annotation in CDI, but only ApplicationScoped, which does not explicitly enforce exactly one single instance. IMHO the CDI spec does not say that it is forbidden to have more than one instance in the same scope (maybe I'm wrong here)?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#605 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFU9N2x5V42FR2svfidHBBcbk1OWqlFAks5tiWCbgaJpZM4S51dH>.
|
|
There is |
|
Another option is to rewrite the example if @singleton is not really
supported.
El mar., 27 mar. 2018 16:20, jansupol <[email protected]> escribió:
… There is @singleton used in Section 9.4 of the Spec., on a resource.
Having this precedence, it make sense to clarify. From the example, it is
not clear whether it could be used on any resource, in general, whether it
has a connection just to SSE (obviously not, but it is confusing), or
whether the annotation makes sense on other JAX-RS classes, not just on a
resource. It is possible that the example only expressed that the resource
was defined in the Application#getSingletons().
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#605 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACAucJCg5UHfcuB8c1ZQUEwOuBEp_mqvks5tikrAgaJpZM4S51dH>
.
|
|
For WebSphere (both Traditional and Liberty), we document our support of
integration with CDI and EJB here:
https://www.ibm.com/support/knowledgecenter/SS7K4U_liberty/com.ibm.websphere.wlp.zseries.doc/ae/rwlp_jaxrs2.0_ejbcdi.html
Hope this helps,
Andy
…On Tue, Mar 27, 2018 at 9:20 AM, jansupol ***@***.***> wrote:
There is @singleton used in Section 9.4 of the Spec., on a resource.
Having this precedence, it make sense to clarify. From the example, it is
not clear whether it could be used on any resource, in general, whether it
has a connection just to SSE (obviously not, but it is confusing), or
whether the annotation makes sense on other JAX-RS classes, not just on a
resource. It is possible that the example only expressed that the resource
was defined in the Application#getSingletons().
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#605 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AUYCM8aFRoWEepQpknhYTOE0wkn5_2dUks5tikrBgaJpZM4S51dH>
.
|
|
Note that here we are talking about JSR 330 @singleton, not EJB one.
I'm unsure CDI even specifies javax.inject.Singleton behavior...
El mar., 27 mar. 2018 16:25, Andy McCright <[email protected]>
escribió:
… For WebSphere (both Traditional and Liberty), we document our support of
integration with CDI and EJB here:
https://www.ibm.com/support/knowledgecenter/SS7K4U_liberty/com.ibm.websphere.wlp.zseries.doc/ae/rwlp_jaxrs2.0_ejbcdi.html
Hope this helps,
Andy
On Tue, Mar 27, 2018 at 9:20 AM, jansupol ***@***.***>
wrote:
> There is @singleton used in Section 9.4 of the Spec., on a resource.
> Having this precedence, it make sense to clarify. From the example, it is
> not clear whether it could be used on any resource, in general, whether
it
> has a connection just to SSE (obviously not, but it is confusing), or
> whether the annotation makes sense on other JAX-RS classes, not just on a
> resource. It is possible that the example only expressed that the
resource
> was defined in the Application#getSingletons().
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <
#605 (comment)
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/AUYCM8aFRoWEepQpknhYTOE0wkn5_2dUks5tikrBgaJpZM4S51dH
>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#605 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACAucJGr9RRUAJpbjYSKJlwfOtU9c5noks5tiku9gaJpZM4S51dH>
.
|
Can you please point me to the place where this is mandated by the JAX-RS specification document and / or API? I just can't find that. It would actually solve this issue, because if it is explicitly told, then Jersey is definitively broken, as it creates one instance per interface, not one instance per class. |
|
@andymc12 Actually this does not help. The question of this issue is: How to annotate singletons without CDI and without EJB. Your link is the reverse of what this thread tries to clarify. |
|
On Mar 27, 2018, at 12:45 PM, Markus KARG ***@***.***> wrote:
@spericas <https://github.com/spericas>
By default, providers are singletons in JAX-RS already.
Can you please point me to the place where this is mandated by the JAX-RS specification document and / or API? I just can't find that. It would actually solve this issue, because if it is explicitly told, then Jersey is definitively broken, as it creates one instance per interface, not one instance per class.
First sentence of Section 4.1 (Lifecycle and Environment).
— Santiago
|
|
@spericas You mean @chkal As my question is resolved, I would close this issue. You voted +1, so do you want to keept this issue open? |
|
Closing as requested clarification is already part of the spec. |
A JAX-RS application can explicitly declare singleton instances by implementing
Application#getSingletons. There should be an unambiguous way to also declare singletons when not implementing this method, i. e. when using auto-discovery and annotations.Example: One class is annotated as
@javax.inject.Singletonand it implementsFeature,ContainerRequestFilterandContainerResponseFilter. A short test using Payara/Jersey discovered that actually two (not one, not three, but really two) instances of that class had been created. This is "near" to a singleton, but not exactly a singleton.Implementors of JAX-RS extensions need a clear API-level way to ensure that their extension is always exactly one class at runtime, on any JAX-RS implementation, being used by any JAX-RS application. For example, a filter which gets configured (hence is a
Feature) once and that puts infos at requests and analyzes this infos at responses MUST be exactly one single instance.This clearly cannot be solved by the API but in fact is a spec issue. As there is no spec issue tracker right now, I put it here. My proposal is that we agree upon adding a sentence like: "A compliant implementation guarantees that for a class annotated with javax.inject.Singleton exactly one single instance is created, and that particular instance is treated as if it would have been returned by Application#getSingletons".
The text was updated successfully, but these errors were encountered: