Section 5.5.2
by Rick Hightower
Is section 5.5.2 trying to say this:
•CDI ensures:
–All fields are injected (of superclasses and current class) before
initializer methods are called
–Injected fields include Java EE resource dependencies
–@PostConstruct are called after initializers
–Java EE: servlet init() method after initializers
It says....
The container must ensure that:
• Initializer methods declared by a class X in the type hierarchy of the
bean are called after all injected fields declared by X or by superclasses
of X have been initialized, and after all Java EE component environment
resource dependencies declared by X or by superclasses of X have been
injected.
• Any @PostConstruct callback declared by a class X in the type hierarchy of
the bean is called after all initializer meth- ods declared by X or by
superclasses of X have been called, after all injected fields declared by X
or by superclasses of X have been initialized, and after all Java EE
component environment resource dependencies declared by X or by su-
perclasses of X have been injected.
• Any servlet init() method is called after all initializer methods have
been called, all injected fields have been initial- ized and all Java EE
component environment resource dependencies have been injected.
--
*Rick Hightower*
(415) 968-9037
Profile <http://www.google.com/profiles/RichardHightower>
13 years, 2 months
ServletContext Lifecycle and CDI Lifecycle Events
by Jens Schumann
Hi All!
While creating a simple CDI demo application I have been using a
ServletContextListener to create test data in a database (using CDI and
JPA). Works as expected. While doing so I have noticed that Glassfish
3.1.1 fires the ServletContext contextInitialized event way before my CDI
AfterDeploymentValidation Extension was initialized. As far I understand
this touches an unspecified area. However I would expect that the CDI
runtime has to be initialized before issuing the context initialized event.
What do you think?
(The demo application is a simple .war application)
Jens
13 years, 2 months
Inconsistent specialization
by Rick Hightower
*5.1.3. Inconsistent specialization*
Suppose an enabled bean X specializes a second bean Y. If there is another
enabled bean that specializes Y we say that *in- consistent
specialization *exists.
The container automatically detects inconsistent specialization and treats
it as a deploy- ment problem.
So it is trying to say.
Two enabled beans cannot specialize the same bean or the CDI container
throws a DefinitionException.
Every sentence that has if X does this to Y and then Z comes over to the
side and does this can almost always be rewritten to a sentence that is more
clear and much more terse. I would either add the more clear and more terse
sentence first with the long drawn out example or just have the clear terse
sentence.
Anyway... low priority. Give some book author some revenue stream for
explaining the spec.
--
*Rick Hightower*
(415) 968-9037
Profile <http://www.google.com/profiles/RichardHightower>
13 years, 2 months
Veto and Requires
by Rick Hightower
"Any class or package may be prevented from providing bean definitions based
on the availability of other classes by adding the @Requires annotation on
the class or package."
@Requires({Customer.class, Supplier.class}) public class Order { ...
}
Spring has something similar called @Required with some different behavior.
But now that I think on it... it is different enough....
I'd prefer explicit names for these annotations. @ExcludeFromCDI and @
ExcludeFromCDIIfMissing.
I know those are horrible names too. Not a big fan of @Veto and @Requires.
How about @ExcludeAsSource, and it has an optional attribute called requires
that takes an array of class types?
I really really hate @Veto and @Requires. I guess I should search the mail
list and see if I missed this conversation.
--
*Rick Hightower*
(415) 968-9037
Profile <http://www.google.com/profiles/RichardHightower>
13 years, 2 months
Section 4.2, worst worded section yet.... holy moly... really?
by Rick Hightower
I think the gist of it is as follows:
Inheritance of Member-level inheritance...
•Injected fields are inherited
•Initializer methods, non-static observers, @PostConstruct and @PreDestroy
are inherited, but can be overridden
•Interceptors are inherited can be overridden
•Producers, consumers are not inherited
Check out this working from Section 4.2....
"If X is a generic type, and an injection point, producer method, producer
field, disposer method or observer method de- clared by X is inherited by Y,
and the declared type of the injection point, producer method, producer
field, disposed para- meter or event parameter contains type variables
declared by X, the type of the injection point, producer method, producer
field, disposed parameter or event parameter inherited in Y is the declared
type, after substitution of actual type arguments declared by Y or any
intermediate class that is a subclass of X and a superclass of Y."
That is not a paragraph... that is one sentence.
*Rick Hightower*
(415) 968-9037
Profile <http://www.google.com/profiles/RichardHightower>
13 years, 2 months
ProcessAnnotatedType question related to Seam-Config
by Mark Struberg
Hi!
Currently tracking down why seam-config sometimes does not work work OWB.
Seems that the issue is that OWB and Weld does tread AnnotatedTypes registered with BeforeBeanDiscovery in a different way.
Assume we have the following class in a BDA:
@RequestScoped
public class Doodings {
...
}
and you have a seam-beans.xml config for it too
Then seam-xml will add an AnnotatedType for it in @Observes BeforeBeanDiscovery. So far so good.
Later in the class scanning, when scanning Coodings.class, we (Apache OpenWebBeans) recognizes that the class already has a prepared AnnotatedType and use that for the system event. Apparently Weld does things different and creates a fresh AnnotatedType purely based on the native class!
That's the reason why seam-config in weld has to veto the freshly scanned type to prevent double existence of Bean<Doodings>, and in OWB this hack causes a problem...
I think there is room for improvement in the specification of AnnotatedTypes in the CDI spec ...
The behaviour must get clarified imo, wdyt?
LieGrue,
strub
13 years, 2 months
