[JBoss JIRA] (CDI-58) Clarify that there can be multiple AnnotatedType instances per Java class
by Mark Struberg (Commented) (JIRA)
[ https://issues.jboss.org/browse/CDI-58?page=com.atlassian.jira.plugin.sys... ]
Mark Struberg commented on CDI-58:
----------------------------------
I fear the wording doesn't clarify the problem far enough.
There are 2 different parts involved, and we have to distinct the 'cause' from the 'effect'.
cause: a Class with all Java bytecode and later added/removed/modified annotations, ct, members, fields, parameters, etc via modifications of it's AnnotatedType
effect: multiple Bean<T> created based upon AnnotatedTypes.
In fact, the linked seam wishlist discussion is based on a (imo) misuse of AnnotatedType! The multiple Bean<T> would be much better done with a dynamically added producer method, thus no multiple AnnotatedTypes per Class are needed!
This also introduces another problem:
11.3.8 Obtaining an AnnotatedType for a class
> If the AnnotatedType for the class has been wrapped or replaced by ProcessAnnotatedType
> then the wrapped or replaced AnnotatedType should be returned BeanManager.createAnnoatedType().
this is completely broken now. Because _which_ of the n AnnotatedType impls do you return?
The whole idea of AnnotatedType in the spec originally afaik was that you always get the same instance for a class in all the various stages of the Extension mechanism where they get used and can subsequently get 'modified' while the boot process advances.
* BeforeBeanDiscovery
* ProcessAnnotatedType
* ProcessInjectionTarget
* ProcessModule
* ProcessBean
* ProcessProducer
Of course we can change this now, but this would considerably change the spec (see 11.3.8) and we would think about how to make this unambiguous (who gets which instance).
I'd just get back to the very beginning and check what we need it for and only afterwards think about possible solutions.
> Clarify that there can be multiple AnnotatedType instances per Java class
> -------------------------------------------------------------------------
>
> Key: CDI-58
> URL: https://issues.jboss.org/browse/CDI-58
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Beans, Portable Extensions
> Affects Versions: 1.0
> Reporter: Pete Muir
> Assignee: Pete Muir
> Fix For: 1.1 (Confirmed)
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (CDI-61) Producers and beans that are under construction
by Mark Struberg (Commented) (JIRA)
[ https://issues.jboss.org/browse/CDI-61?page=com.atlassian.jira.plugin.sys... ]
Mark Struberg commented on CDI-61:
----------------------------------
found it. This behaviour is defined in JSR-250:
> The PostConstruct annotation is used on a method that needs to be
> executed after dependency injection is done to perform any
> initialization. This method MUST be invoked before the class
> is put into service.
And as JSR-330/299 define that @Inject fields and methods must get called _before_ @PostConstruct methods, we must therefor initialise our beans completely _before_ they are "put into service".
> Producers and beans that are under construction
> -----------------------------------------------
>
> Key: CDI-61
> URL: https://issues.jboss.org/browse/CDI-61
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Affects Versions: 1.0
> Reporter: Pete Muir
> Fix For: 1.1 (Proposed)
>
>
> I think we need the spec to say something about cases where an injection point of a bean resolves to a producer method of the same bean. The implementation should detect that this is a definition error. It shouldn't try to call a producer method on a non-fully-initialized bean.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
@PostConstruct and @Inject methods in superclasses
by Mark Struberg
Hi!
JSR-250 common annotations is pretty thin about having @PostConstruct in multiple class hierarchies. It just says that there must only be one single method annotated with @PostConstruct in a class. Thus my question:
If I have
public class Animal {
@PostConstruct
public void doInit() {..}
..
}
and
public class Horse extends Animal {
@PostConstruct
public void doSomeOtherInit() {..}
..
}
1.) for a contextual instance of Horse, will Animal#doInit() get executed or only the one from the 'effective' class?
2.) if 1.) was yes, then In which order do they get executed? Is this specced somewhere?
3.) Same scenario with @Inject methods. Do we specify an order?
4.) Both classes have @Inject methods and @PostConstruct. Again: which order of invocaition?
Just that you understand my intention: we had a @PostConstruct method in Horse which did set a 'cached' flag in Animal. Turned out that this was a random generator depending on the intsalled server ;)
LieGrue,
strub
13 years
[JBoss JIRA] Created: (CDI-159) overly strict final check on proxyable methods
by Mark Struberg (JIRA)
overly strict final check on proxyable methods
----------------------------------------------
Key: CDI-159
URL: https://issues.jboss.org/browse/CDI-159
Project: CDI Specification Issues
Issue Type: Bug
Components: Interceptors
Affects Versions: 1.0
Reporter: Mark Struberg
Fix For: 1.1 (Proposed)
CDI-1.0 currently specifies:
5.4.1. Unproxyable bean types
Certain legal bean types cannot be proxied by the container:
...
• classes which are declared final or have final methods,
But actually this is overly strict, since this criteria should only apply to non-static and non-private methods.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
Re: [cdi-dev] Antw.: @PostConstruct and @Inject methods in superclasses
by Mark Struberg
Yes, imo the things which are not yet clear are the order between @Inject and @PostConstruct, and wha happens if we have a class hierarchy.
LieGrue,
strub
--- On Fri, 9/30/11, Arne Limburg <arne.limburg(a)openknowledge.de> wrote:
From: Arne Limburg <arne.limburg(a)openknowledge.de>
Subject: Antw.: [cdi-dev] @PostConstruct and @Inject methods in superclasses
To: "stuart.w.douglas(a)gmail.com" <stuart.w.douglas(a)gmail.com>, "struberg(a)yahoo.de" <struberg(a)yahoo.de>
Cc: "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
Date: Friday, September 30, 2011, 10:18 PM
Hi,
for @Inject there is an order specified in JSR 330. Imho we should specify that same order for @Postconstruct if we have specification for it yet.
Regards,
Arne
----- Reply message -----
Von: "Stuart Douglas" <stuart.w.douglas(a)gmail.com>
Datum: Fr., Sep. 30, 2011 23:58
Betreff: [cdi-dev] @PostConstruct and @Inject methods in superclasses
An: "Mark Struberg" <struberg(a)yahoo.de>
Cc: "cdi-dev" <cdi-dev(a)lists.jboss.org>
This is actually covered by the interceptors specification, from memory I am pretty sure the base class method is mean't to be called first, but the spec gives you the full order.
@Inject methods are called before @PostConstuct (the are called in InjectionTarget.inject, which gets called before InjectionTarget.postConstruct).
I don't think we specify an order for @Inject methods.
Stuart
On 01/10/2011, at 5:47 AM, Mark Struberg wrote:
> Hi!
>
> JSR-250 common annotations is pretty thin about having @PostConstruct in multiple class hierarchies. It just says that there must only be one single method annotated with @PostConstruct in a class. Thus my question:
>
> If I have
>
>
> public class Animal {
> @PostConstruct
>
> public void doInit() {..}
> ..
>
> }
>
> and
>
> public class Horse extends Animal {
> @PostConstruct
>
> public void doSomeOtherInit() {..}
> ..
>
> }
>
>
> 1.) for a contextual instance of Horse, will Animal#doInit() get executed or only the one from the 'effective' class?
> 2.) if 1.) was yes, then In which order do they get executed? Is this specced somewhere?
>
> 3.) Same scenario with @Inject methods. Do we specify an order?
>
> 4.) Both classes have @Inject methods and @PostConstruct. Again: which order of invocaition?
>
>
> Just that you understand my intention: we had a @PostConstruct method in Horse which did set a 'cached' flag in Animal. Turned out that this was a random generator depending on the intsalled server ;)
>
>
> LieGrue,
> strub
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
13 years
