The weld extensions stuff is a bit of a hack, but I can't see any other way of doing
it. The issue is just to do with object identity, i.e. will the object returned from
getTarget() == the instance that is passed into InjectionTarget.inject().
Currently all that is provided is the AnnotatedType, which I think is probably going to be
more relevant to interceptor writers than the actual bean object, as they most probably
want to inspect the annotations.
At the moment it is something of a manual lookup, you inject an AnnotatedTypeIdentifier
that you can then use to get the AnnotatedType. Once again this is not ideal, it would be
better to inject the AnnotatedType information directly, however I don't think it is
possible at the moment.
Stuart
________________________________________
From: Marius Bogoevici [marius.bogoevici(a)gmail.com]
Sent: Thursday, 22 April 2010 2:38 PM
To: Stuart Douglas
Cc: Pete Muir; seam-dev(a)lists.jboss.org
Subject: Re: [seam-dev] Retrieving the Bean object for an interceptor
On 10-04-21 10:36 PM, Stuart Douglas wrote:
I have attempted to add a temporary fix for this issue to
weld-extensions to allow interceptors to get at the AnnotatedType of the object being
intercepted.
The extension wraps the InjectionTarget of Beans that need this functionality, and the
inject method of the InjectionTarget stores a mapping from the instance to the
AnnotatedType in a WeakHashMap.
I have a few questions:
- Is InvocationContext.getTarget() guaranteed to return the instance of the bean or can
it return a proxy? If it can return a proxy this technique is not going to work.
The Interceptor specification says just that "getTarget() returns the
associated target instance", so that would normally mean "the original
intercepted instance". The introduction of decorators made things more
complicated, and in the current implementation (1.0.1), getTarget() will
return the decorator proxy if the bean has both interceptors and
decorators. However, once we move to subclassing (1.0.2), the call will
return the single instrumented instance, which is essentially a subclass
of the bean class. It would be necessary to retrieve the original bean
class from that. But I can see a few options for doing that, one being a
mixin interface with methods that can retrieve information about the
original type of the target object.
As well, it should be possible to provide the metadata information in a
similar way to which the InjectionPoint is provided to Dependent beans
(given how Interceptors are dependent on the beans that they intercept),
except that in this case it would be more something like
InterceptedMetadata mentioned before.
Are we looking at something like this?
public interface InterceptionMetadata<T>
{
Bean<T> getInterceptedBean()
}
and then @Inject InterceptionMetadata interceptionMetadata;
(Sorry, I haven't checked your weld-extensions stuff yet :) ).
Marius
- Can I add a dependency on google collections to weld-extensions?
Currently it stores the references in a syncronized WeakHashMap, but really what I need is
a Concurrent Weak Identity hashmap.
Hopefully this is just a temporary workaround that can be removed after the next release
of the spec, but currently I can't see any other way to accomplish this.
Stuart
________________________________________
From: Pete Muir [pmuir(a)redhat.com]
Sent: Friday, 9 April 2010 9:24 PM
To: Nicklas Karlsson
Cc: Stuart Douglas; seam-dev(a)lists.jboss.org
Subject: Re: [seam-dev] Retrieving the Bean object for an interceptor
No, I think you are right Stuart. Sounds like something the MR should address.
On 6 Apr 2010, at 07:38, Nicklas Karlsson wrote:
> In the Good Old Days, say late 2008, when the spec was a draft for WebBeans, it said
>
> "If any class-level interceptor binding type is specified in XML, the
interceptor binding annotations appearing on the implementation
> class are ignored. The class-level interceptor bindings for the Web Bean include all
interceptor bindings declared
> using XML, together with all interceptor bindings of all stereotypes declared by the
Web Bean.
>
> Otherwise, if no class-level interceptor binding types are specified in XML, the
interceptor binding annotations that appear
> on the implementation class are used. The class-level interceptor bindings for the
Web Bean include all interceptor bindings
> declared by annotating the implementation class, together with all interceptor
bindings of all stereotypes declared by
> the Web Bean.
>
> If any method-level interceptor binding type is specified in XML, the interceptor
binding annotations appearing on that
> method are ignored. The method-level interceptor bindings for that method include
only the interceptor bindings declared
> using XML.
>
> Otherwise, if no method-level interceptor binding types are specified in XML, the
interceptor binding annotations that appear
> on that method are used. The method-level interceptor bindings for that method
include all the interceptor bindings
> declared by annotating the method."
>
>
>
> On Tue, Apr 6, 2010 at 7:56 AM, Stuart Douglas<stuart(a)baileyroberts.com.au>
wrote:
> I can't see any way to get information about the actual Bean that an interceptor
is bound to.
>
> For example say I have a class:
>
> @Security("#{true}")
> class SomeClass
> {
> ...
> }
>
> Another bean with the same class is wired up with XML:
>
> <t:SomeClass>
> <se:Security>#{false}</se:Security>
> ....
> </t:SomeClass>
>
> I cannot see any way for a security interceptor to know which Bean it is
intercepting, and therefore figure out which annotation to use. Is there something I am
missing here?
>
> Stuart
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/seam-dev
>
>
>
> --
> ---
> Nik
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/seam-dev
>
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev