Stereotype inheritance
by Stuart Douglas
Does the spec define what happens in the following situation?
@RequestScoped @Stereotype @Target(TYPE) @Retention(RUNTIME) public @interface Action {}
@ApplicationScoped @Action @Stereotype @Target(TYPE) @Retention(RUNTIME) public @interface Home {}
@Home
public class MyBean{}
As far as I could see the spec does not define what to do when stereotypes declare stereotypes that have conflicting scopes. In this situation it would make sense to have Home's scope override Actions, but we can also get situations like this:
@RequestScoped @Stereotype @Target(TYPE) @Retention(RUNTIME) public @interface Action {}
@ApplicationScoped @Stereotype @Target(TYPE) @Retention(RUNTIME) public @interface Home {}
@Stereotype @Home @Action @Target(TYPE) @Retention(RUNTIME) public @interface HomeAction {}
@Home
public class MyBean{}
I think this should be an error.
Stuart
16 years, 2 months
Question Regarding to Event Qualifier @Any
by Gurkan Erdogdu
Hi;
I want to ask about using @Any in event qualifiers. In TCK ObserverTest # testObserverNotifiedWhenEventTypeAndAllBindingsMatch;
Annotation roleBinding = new RoleBinding("Admin");
// Fire an event that will be delivered to the two above observers
AnEventType anEvent = new AnEventType();
getCurrentManager().fireEvent(anEvent, roleBinding);
With observers;
1* public void observer(@Observes @Any AnEventType event)
2* public void observer(@Observes @Role("Admin") AnEventType event)
And TCK says that both of them are called by the container. I really confused the usage of @Any. AFAIK, @Any is any qualifier like others in Event context. Therefore 1* observer must not be called by the container because fired event does not contain @Any qualifier.
WDYT?
--Gurkan
___________________________________________________________________
Yahoo! Türkiye açıldı! http://yahoo.com.tr
İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!
16 years, 2 months
Applying Interceptors
by Jordan Ganoff
I'd like to intercept a built-in bean's method, specifically
BeanManager.fireEvent(Type, Object, Annotation...). I could not find any
information in the JSR299 Final Draft proposal that details any way of
configuring interceptors for a method or class externally. Is this
possible?
16 years, 2 months
AnnotatedType and the SPI
by Stuart Douglas
Does the spec define what should happen if an AnnotatedType added through the SPI is missing a method/field/parameter etc that is present on the underlying class?
I had a look but I could not see anything in spec, and as far as I can tell weld is inconsistant with regard to how it treats it. If an AnnotatedParameter is missing it uses the Annotations on the underlying class, however if a field definition is missing it treats it as having no annotations (I have not actually tested this, just has a quick look at the code, so I could be wrong).
Stuart
16 years, 2 months
Maintenance release
by Gavin King
Folks, I want to start work on the first CDI maintenance release, and
push it out fairly quickly. We've already discussed a couple of things
that we wanted in CDI 1.0, but had to delay to the maintenance
release:
* Bean declaration at constructor level
* Abstract producer methods
* Injection into static members
I want to discuss these things in separate threads.
I also have a list of enhancements to the portable extension SPI,
which was the least-mature part of the spec, and I would like to
discuss with you guys whether some of those enhancements could/should
be rolled into the maintenance release.
For now, I just want to update the spec with a list of clarifications
that have cropped up. Please read over these items and speak up if you
have an opinion on any of them!
++ Methods of abstract decorators
The CDI 1.0 spec does not define what happens with abstract methods of
an abstract decorator class. This was an oversight. We should probably
say:
* If a decorator class declares an abstract method that is not
declared by one of the decorated types, a definition error results
* All abstract methods have a container-generated implementation
that simply delegates the method call to the delegate object
With this definition, I don't think we need any special-casing for
abstract methods annotated @Inject, @PostConstruct, etc.
++ Clarify that scope types should not have members
The spec should mention that @ScopeType annotations should not have
annotation members. Perhaps this should be a definition error.
javax.inject.Scope already mentions this.
++ Clarify that parameters of producer and disposer methods are
injection points of the producer method bean
We say that "....parameters are injection points." We should be
clearer and say "....parameters are injection points of the producer
method bean."
++ Clarify that not all classes in a bean archive are bean classes
We should be clearer and say that you can put non-bean classes (e.g.
MDBs) in a bean archive.
++ Clarify that there can be multiple AnnotatedType instances per Java class
This is not 100% clear in the spec.
++ Clarify that interceptors/decorators don't apply to producers in
resolution rules
We say this in the preamble, but we should also mention it in the
resolution rules.
++ In lifecycle chapter, clarify creation of interceptors/decorators
Not sure precisely what we need to say, but the note in 11.2 is not
sufficient, I think.
++ Producers and beans that are under construction
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.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
16 years, 2 months
Do we need a Context.destroy() ?
by Mark Struberg
Hi!
I'm currently writing a CDI extension and like to do the 'cleanup' properly.
So, what does happen if a WebApp gets stopped?
One thing is sure: a Context implementation must destroy all contextual instances it still holds (to make sure that e.g @PreDestroy gets called, etc).
But how to do this properly?
My first idea was to use
public void destroy( @Observes BeforeShutdown beforeShutdown)
{
for(allContextualInstances)
contextual.destroy(..)
}
but there is a timing issue with this approach. It is not defined which bean receives the BeforeShutdown event first. Thus if my extension is the first which gets this event and destroys all contextual beans it maintains, then all following beans listening to BeforeShutdown and still referencing some beans with my special context will simply crash.
Do you have an idea what we can do to work around this problem?
If not, I'd prefer to introduce a new destroy() method in the Context interface which gets called by the container after all BeforeShutdown events got fired.
txs and LieGrue,
strub
16 years, 2 months
Re: [weld-dev] Do we need a Context.destroy() ?
by Mark Struberg
to further clarify what I mean:
section 11.5.4 BeforeShutdown event:
"The container must fire a final event _after_ it has finished processing requests and destroyed _all_ contexts."
Obviously this isn't working for Contexts defined as portable extensions, is it? This may state 'built-in contexts'.
txs and LieGrue,
strub
--- On Tue, 1/12/10, Mark Struberg <struberg(a)yahoo.de> wrote:
> From: Mark Struberg <struberg(a)yahoo.de>
> Subject: Do we need a Context.destroy() ?
> To: "Gavin King" <gavin.king(a)gmail.com>
> Cc: "Java Community Process JSR #299 Expert List" <JSR-299-EG(a)jcp.org>, "Weld-Dev" <weld-dev(a)lists.jboss.org>
> Date: Tuesday, January 12, 2010, 3:48 PM
> Hi!
>
> I'm currently writing a CDI extension and like to do the
> 'cleanup' properly.
>
> So, what does happen if a WebApp gets stopped?
> One thing is sure: a Context implementation must destroy
> all contextual instances it still holds (to make sure that
> e.g @PreDestroy gets called, etc).
>
> But how to do this properly?
>
> My first idea was to use
>
> public void destroy( @Observes BeforeShutdown
> beforeShutdown)
> {
> for(allContextualInstances)
> contextual.destroy(..)
> }
>
> but there is a timing issue with this approach. It is not
> defined which bean receives the BeforeShutdown event first.
> Thus if my extension is the first which gets this event and
> destroys all contextual beans it maintains, then all
> following beans listening to BeforeShutdown and still
> referencing some beans with my special context will simply
> crash.
>
> Do you have an idea what we can do to work around this
> problem?
>
> If not, I'd prefer to introduce a new destroy() method in
> the Context interface which gets called by the container
> after all BeforeShutdown events got fired.
>
> txs and LieGrue,
> strub
>
16 years, 2 months
Status of xml descriptor (previously known as webbeans.xml) for CDI ?
by max.andersen＠redhat.com
Hi,
I haven't been able to keep fully up with Weld lately, but I was wondering what is the status of
support for the xml based descriptors/configuration ?
I'm asking since Gavin's latest blogs indicate it is now "less interesting", but from a tooling
perspective the xml based descriptors are the only way I know off where we can know about
about components that are registered programmatically via the SPI and not by standard means.
The related jira from a tooling perspective is https://jira.jboss.org/jira/browse/JBIDE-3120.
Is there a jira in Weld that we can track about the xml schema progress ?
--
/max
16 years, 2 months
[TCK Related] Question on SimpleBeanLifecycleTest
by Gurkan Erdogdu
Hi;
In test SimpleBeanLifecycleTest # testSpecializedBeanExtendsManagedBean, MountainLion specializes the Lion so the managed bean with Lion is never resolved.
So getBeans(Lion.class, TAME_LITERAL) returns bean with MountationLion not bean with Lion.
Therefore assert bean != null; in the test case seems not to be correct!
WDYT?
Thks;
--Gurkan
___________________________________________________________________
Yahoo! Türkiye açıldı! http://yahoo.com.tr
İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!
16 years, 2 months
About @PostActivate and @PrePassivate
by Gurkan Erdogdu
Hi;
@PostActivate and @PrePassivate annotations are defined on
the EJB specification. Those annotations are not defined in the
Interceptor specification. But in CDI specification, chapter 11.1.2
specifices the using of PRE_PASSIVATE and POST_ACTIVATE interception
types.
I think that this is wrong because those annotations must
be defined on ManagedBean with passivating capable not in interceptor
class.
For example;
In TCK , it tests
Interceptor interceptor = get Some Interceptors....
interceptor.intercept(InterceptionType.PRE_PASSIVATE
or POST_ACTIVATE) is not meaningful, because interceptors may not
define PRE_PASSIVATE or POST_ACTIVATE methods.
I think that PRE_PASSIVATE and POST_ACTIVATE must be removed from InterceptionType enum.
--Gurkan
___________________________________________________________________
Yahoo! Türkiye açıldı! http://yahoo.com.tr
İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!
16 years, 2 months
