I agree. Ill stick to ApplicationScope until the practicalities are sorted
out.
Thanks for the deeper clarification.
On Sat, Sep 7, 2013 at 9:42 PM, Mark Struberg <struberg(a)yahoo.de> wrote:
No, I don't expect users to read the TCK - but it's binding
for the
container vendors.
Again: I completely agree with Martin with his advice to not use
@javax.inject.Singleton in CDI projects as it is really underspecified in
JSR-330 already. And JSR-299 does not add any wording to make things more
clear.
But the fuzzyness around @Singleton is mainly about it's lifecycle, etc.
The requirement for @PostConstruct and @PreDestroy support is otoh actually
pretty well defined in atinject imo.
LieGrue,
strub
>________________________________
> From: Kristoffer Sjögren <stoffe(a)gmail.com>
>To: Mark Struberg <struberg(a)yahoo.de>
>Cc: Martin Kouba <mkouba(a)redhat.com>; "weld-dev(a)lists.jboss.org"
<
weld-dev(a)lists.jboss.org>
>Sent: Saturday, 7 September 2013, 21:11
>Subject: Re: [weld-dev] PostConstruct & PreDestroy in Java SE
>
>
>
>http://docs.jboss.org/cdi/spec/1.1/cdi-spec.pdf "1.2.4 Relationship to
Dependency Injection for Java" is what you referring to I suppose? But
there is no telling how to use it. Also, its a bit unfortunate that we have
two Singleton annotations, begging for confusion.
>
>
>Nevermind vagueness, but do you expect users to read the TCK? Not trying
criticize, there may be room for improvement here no?
>
>
>
>
>
>
>On Sat, Sep 7, 2013 at 8:57 PM, Mark Struberg <struberg(a)yahoo.de> wrote:
>
>
>>
>>No, the TCK is part of the deliverable for the specification. As is the
API JavaDoc.
>>
>>Also the spec mentions the 'Injection for Java' specification (==
JSR-330) as reference.
>>
>>
>>LieGrue,
>>strub
>>
>>
>>
>>>________________________________
>>> From: Kristoffer Sjögren <stoffe(a)gmail.com>
>>>To: Mark Struberg <struberg(a)yahoo.de>
>>>Cc: Martin Kouba <mkouba(a)redhat.com>;
"weld-dev(a)lists.jboss.org" <
weld-dev(a)lists.jboss.org>
>>>Sent: Saturday, 7 September 2013, 20:54
>>
>>>Subject: Re: [weld-dev] PostConstruct & PreDestroy in Java SE
>>>
>>>
>>>
>>>Alright, the specification and TCK is inconsistent. But as a user, I
dont care about the TCK and it does not make sense to enforce requirements
on the specification in the TCK. For users, strictly speaking, anything not
stated in the specification is unsupported. Correct?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>On Sat, Sep 7, 2013 at 8:03 PM, Mark Struberg <struberg(a)yahoo.de>
wrote:
>>>
>>>And before there are any questions: it's not directly stated inside the
CDI spec but in the TCK documentation:
>>>>
>>>>
http://docs.jboss.org/cdi/tck/reference/1.0.4.SP1/pdf/jsr299-tck-referenc...
>>>>
>>>>"JSR-330 - CDI builds on JSR-330, and as such JSR-299
implementations
must additionally pass the JSR-330 TCK."
>>>>
>>>>again: I agree with Martin that you should better not use it. But it
should work nontheless.
>>>>
>>>>
>>>>LieGrue,
>>>>strub
>>>>
>>>>
>>>>
>>>>
>>>>----- Original Message -----
>>>>
>>>>> From: Mark Struberg <struberg(a)yahoo.de>
>>>>> To: Martin Kouba <mkouba(a)redhat.com>; Kristoffer Sjögren <
stoffe(a)gmail.com>
>>>>> Cc: "weld-dev(a)lists.jboss.org"
<weld-dev(a)lists.jboss.org>
>>>>> Sent: Saturday, 7 September 2013, 19:22
>>>>> Subject: Re: [weld-dev] PostConstruct & PreDestroy in Java SE
>>>>>
>>>>>T he wording is not correct.
>>>>
>>>>>
>>>>> Each JSR-299 Container must _fully_ implement the JSR-330
specification and pass
>>>>> the JSR-330 TCK. Thus each CDI Container MUST support
javax.inject.Singleton.
>>>>> But it's actually not really defined in detail how this scope
should
behave.
>>>>> And the atinject and EE specs also define that @PostConstruct and
@PreDestroy
>>>>> must work for @Singleton beans. So this is imo a bug. But otoh I
personally
>>>>> would suggest to not use javax.inject.Singleton because of the
aforementioned
>>>>> underspecified behaviout.
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: Martin Kouba <mkouba(a)redhat.com>
>>>>>> To: Kristoffer Sjögren <stoffe(a)gmail.com>
>>>>>> Cc: weld-dev(a)lists.jboss.org
>>>>>> Sent: Friday, 6 September 2013, 14:31
>>>>>> Subject: Re: [weld-dev] PostConstruct & PreDestroy in Java
SE
>>>>>>
>>>>>> Actually there's no singleton scope and corresponding
built-in
context
>>>>>> defined in the CDI spec. Though Weld API contains
>>>>>> org.jboss.weld.context.SingletonContext. Also the docs are
outdated
>>>>>> (chapter 5.4. The singleton pseudo-scope). I think relevant
classes
>>>>>> should be deprecated and the docs updated.
>>>>>>
>>>>>> With regard to lifecycle callbacks - Weld only invalidates
application
>>>>>> context during shutdown right now [1].
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>> [1]
>>>>>>
>>>>>
https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/wel...
>>>>>>
>>>>>> Dne 6.9.2013 14:09, Kristoffer Sjögren napsal(a):
>>>>>>> Hi
>>>>>>>
>>>>>>> We're running Weld 2.0.3.Final in a Java SE
environment and have
>>>>>>> encountered a precarious situation where it seems like
Weld is
not
>>>>>>> consistent in handling the lifecycle of singleton beans.
>>>>>>>
>>>>>>> We have singleton beans with @PostConstruct and
@PreDestroy
methods.
>>>>>>> During Weld.initialize() all @PostConstruct methods are
called.
But
>>>>>>> during @PreDestroy methods are never called during
Weld.shutdown().
>>>>>>> @PreDestroy is only called on beans which are
@ApplicationScoped.
>>>>>>>
>>>>>>> Is this according to specification or a bug?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> -Kristoffer
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> weld-dev mailing list
>>>>>>> weld-dev(a)lists.jboss.org
>>>>>>>
https://lists.jboss.org/mailman/listinfo/weld-dev
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> weld-dev mailing list
>>>>>> weld-dev(a)lists.jboss.org
>>>>>>
https://lists.jboss.org/mailman/listinfo/weld-dev
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> weld-dev mailing list
>>>>> weld-dev(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/weld-dev
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>