You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Manu George <ma...@gmail.com> on 2007/04/04 11:12:03 UTC
Regarding dependency injection in interceptors
Hi,
Is dependency injection/annotation processing in Interceptors
working? If so which class is the code in?
Thanks
Manu
Re: Regarding dependency injection in interceptors
Posted by Manu George <ma...@gmail.com>.
Nice. It is a good approach, takes care of all the possibilities.
Great work David.
On 6/2/07, David Blevins <da...@visi.com> wrote:
> Plumbed this one in last night.
>
> Basically what we have now is the JNDI entries for each Interceptor
> are added to the JNDI tree of each and every ejb, so should the EJB
> use that Interceptor it's entries are available. Then come injection
> time, we check each Injection object to see if it applies to the bean
> or the interceptor and include/exclude it appropriately.
>
> -David
>
>
> On May 4, 2007, at 6:17 AM, Manu George wrote:
>
> > Replying after a long time to this thread .sorry abt that :) but some
> > Q's on this
> >
> > On 4/4/07, David Blevins <da...@visi.com> wrote:
> >>
> >> On Apr 4, 2007, at 2:12 AM, Manu George wrote:
> >>
> >> > Hi,
> >> > Is dependency injection/annotation processing in Interceptors
> >> > working? If so which class is the code in?
> >>
> >> It's not working just yet. The trick is that the interceptor shares
> >> the JNDI ENC of the bean, which would mean that the JNDI ENC
> >> resulting from processing the Interceptor's annotations would have to
> >> be added to the JNDI ENC of every bean that that interceptor may be
> >> used on,
> > Is that how it is or is it that from the interceptor i can access the
> > JNDI context of the bean?
> > If I can access the JNDI context I can access via dependency injection
> > all those variables. But If I define a new variable in the interceptor
> > then how will it be linked to a resource in the server. One way will
> > be to give a mapping in openejb-jar.xml (but here it can be currently
> > defined only for a particular EJB) . Is it possible to define a new
> > object in interceptor JNDI that is not visible in EJB JNDI?
> >
> >> only we don't fully process interceptor bindings till far
> >> after the JNDI ENC info objects are created.
> >>
> >> We have two flavors of choices as far as I can see. We either add
> >> some kind of logic to figure out which interceptors apply to a bean
> >> and then process it's annotations over and over again into the jaxb
> >> jndi section of each affected bean -- that would be a real pain and
> >> hard to follow.
> > Yes
> >> Or we just give each Interceptor it's own JNDI ENC
> >> anyway and follow a simple "check the bean's enc first, then check
> >> the interceptors enc if we didn't find it in the bean enc" type of
> >> algorithm when we inject on the interceptor instance.
> >>
> > Here if we define the same interceptor for multiple ejbs the same
> > annotations will refer to different resources. So for this approach
> > also we will need to have copies of the JNDI ENC for each interceptor
> > for each bean. eg Interceptor A for bean1 will have a different ENC
> > than INterceptor A for Bean2. So I am not getting the advantage of
> > this approach over the first.
> >
> > To illustrate the above Consider a bean with an @Resource
> >
> > @Resource
> > private QueueConnectionFactory queueCoonnectionFactory;
> >
> > Now if I have the same thing in interceptor I will get the same
> > connection factory as the ejb. So this object is there in EJB's JNDI
> >
> > Now if I use same interceptor for another bean without the connection
> > factory in JNDI then the reference should be there in Interceptors
> > JNDI. But since we have only 1 JNDI ENC per interceptor and we can
> > define new annotations in interceptors how can we achieve this.
> >
> >> The second one would be my choice. Main reason being one of the
> >> things that will likely be added to the next EJB spec is ejb-jar
> >> scoped JNDI (just as we have in our JIRA) and the injection algorithm
> >> of "first bean-scoped enc, then ejb-jar-scoped enc" will have to be
> >> added anyway.
> > Oh cool so I guess second approach is the way forward but I don't
> > understand it ..Yet!! Duh :).
> >>
> >>
> >> -David
> >>
> >>
> >
>
>
Re: Regarding dependency injection in interceptors
Posted by David Blevins <da...@visi.com>.
Plumbed this one in last night.
Basically what we have now is the JNDI entries for each Interceptor
are added to the JNDI tree of each and every ejb, so should the EJB
use that Interceptor it's entries are available. Then come injection
time, we check each Injection object to see if it applies to the bean
or the interceptor and include/exclude it appropriately.
-David
On May 4, 2007, at 6:17 AM, Manu George wrote:
> Replying after a long time to this thread .sorry abt that :) but some
> Q's on this
>
> On 4/4/07, David Blevins <da...@visi.com> wrote:
>>
>> On Apr 4, 2007, at 2:12 AM, Manu George wrote:
>>
>> > Hi,
>> > Is dependency injection/annotation processing in Interceptors
>> > working? If so which class is the code in?
>>
>> It's not working just yet. The trick is that the interceptor shares
>> the JNDI ENC of the bean, which would mean that the JNDI ENC
>> resulting from processing the Interceptor's annotations would have to
>> be added to the JNDI ENC of every bean that that interceptor may be
>> used on,
> Is that how it is or is it that from the interceptor i can access the
> JNDI context of the bean?
> If I can access the JNDI context I can access via dependency injection
> all those variables. But If I define a new variable in the interceptor
> then how will it be linked to a resource in the server. One way will
> be to give a mapping in openejb-jar.xml (but here it can be currently
> defined only for a particular EJB) . Is it possible to define a new
> object in interceptor JNDI that is not visible in EJB JNDI?
>
>> only we don't fully process interceptor bindings till far
>> after the JNDI ENC info objects are created.
>>
>> We have two flavors of choices as far as I can see. We either add
>> some kind of logic to figure out which interceptors apply to a bean
>> and then process it's annotations over and over again into the jaxb
>> jndi section of each affected bean -- that would be a real pain and
>> hard to follow.
> Yes
>> Or we just give each Interceptor it's own JNDI ENC
>> anyway and follow a simple "check the bean's enc first, then check
>> the interceptors enc if we didn't find it in the bean enc" type of
>> algorithm when we inject on the interceptor instance.
>>
> Here if we define the same interceptor for multiple ejbs the same
> annotations will refer to different resources. So for this approach
> also we will need to have copies of the JNDI ENC for each interceptor
> for each bean. eg Interceptor A for bean1 will have a different ENC
> than INterceptor A for Bean2. So I am not getting the advantage of
> this approach over the first.
>
> To illustrate the above Consider a bean with an @Resource
>
> @Resource
> private QueueConnectionFactory queueCoonnectionFactory;
>
> Now if I have the same thing in interceptor I will get the same
> connection factory as the ejb. So this object is there in EJB's JNDI
>
> Now if I use same interceptor for another bean without the connection
> factory in JNDI then the reference should be there in Interceptors
> JNDI. But since we have only 1 JNDI ENC per interceptor and we can
> define new annotations in interceptors how can we achieve this.
>
>> The second one would be my choice. Main reason being one of the
>> things that will likely be added to the next EJB spec is ejb-jar
>> scoped JNDI (just as we have in our JIRA) and the injection algorithm
>> of "first bean-scoped enc, then ejb-jar-scoped enc" will have to be
>> added anyway.
> Oh cool so I guess second approach is the way forward but I don't
> understand it ..Yet!! Duh :).
>>
>>
>> -David
>>
>>
>
Re: Regarding dependency injection in interceptors
Posted by Manu George <ma...@gmail.com>.
Replying after a long time to this thread .sorry abt that :) but some
Q's on this
On 4/4/07, David Blevins <da...@visi.com> wrote:
>
> On Apr 4, 2007, at 2:12 AM, Manu George wrote:
>
> > Hi,
> > Is dependency injection/annotation processing in Interceptors
> > working? If so which class is the code in?
>
> It's not working just yet. The trick is that the interceptor shares
> the JNDI ENC of the bean, which would mean that the JNDI ENC
> resulting from processing the Interceptor's annotations would have to
> be added to the JNDI ENC of every bean that that interceptor may be
> used on,
Is that how it is or is it that from the interceptor i can access the
JNDI context of the bean?
If I can access the JNDI context I can access via dependency injection
all those variables. But If I define a new variable in the interceptor
then how will it be linked to a resource in the server. One way will
be to give a mapping in openejb-jar.xml (but here it can be currently
defined only for a particular EJB) . Is it possible to define a new
object in interceptor JNDI that is not visible in EJB JNDI?
> only we don't fully process interceptor bindings till far
> after the JNDI ENC info objects are created.
>
> We have two flavors of choices as far as I can see. We either add
> some kind of logic to figure out which interceptors apply to a bean
> and then process it's annotations over and over again into the jaxb
> jndi section of each affected bean -- that would be a real pain and
> hard to follow.
Yes
> Or we just give each Interceptor it's own JNDI ENC
> anyway and follow a simple "check the bean's enc first, then check
> the interceptors enc if we didn't find it in the bean enc" type of
> algorithm when we inject on the interceptor instance.
>
Here if we define the same interceptor for multiple ejbs the same
annotations will refer to different resources. So for this approach
also we will need to have copies of the JNDI ENC for each interceptor
for each bean. eg Interceptor A for bean1 will have a different ENC
than INterceptor A for Bean2. So I am not getting the advantage of
this approach over the first.
To illustrate the above Consider a bean with an @Resource
@Resource
private QueueConnectionFactory queueCoonnectionFactory;
Now if I have the same thing in interceptor I will get the same
connection factory as the ejb. So this object is there in EJB's JNDI
Now if I use same interceptor for another bean without the connection
factory in JNDI then the reference should be there in Interceptors
JNDI. But since we have only 1 JNDI ENC per interceptor and we can
define new annotations in interceptors how can we achieve this.
> The second one would be my choice. Main reason being one of the
> things that will likely be added to the next EJB spec is ejb-jar
> scoped JNDI (just as we have in our JIRA) and the injection algorithm
> of "first bean-scoped enc, then ejb-jar-scoped enc" will have to be
> added anyway.
Oh cool so I guess second approach is the way forward but I don't
understand it ..Yet!! Duh :).
>
>
> -David
>
>
Re: Regarding dependency injection in interceptors
Posted by David Blevins <da...@visi.com>.
On Apr 4, 2007, at 2:12 AM, Manu George wrote:
> Hi,
> Is dependency injection/annotation processing in Interceptors
> working? If so which class is the code in?
It's not working just yet. The trick is that the interceptor shares
the JNDI ENC of the bean, which would mean that the JNDI ENC
resulting from processing the Interceptor's annotations would have to
be added to the JNDI ENC of every bean that that interceptor may be
used on, only we don't fully process interceptor bindings till far
after the JNDI ENC info objects are created.
We have two flavors of choices as far as I can see. We either add
some kind of logic to figure out which interceptors apply to a bean
and then process it's annotations over and over again into the jaxb
jndi section of each affected bean -- that would be a real pain and
hard to follow. Or we just give each Interceptor it's own JNDI ENC
anyway and follow a simple "check the bean's enc first, then check
the interceptors enc if we didn't find it in the bean enc" type of
algorithm when we inject on the interceptor instance.
The second one would be my choice. Main reason being one of the
things that will likely be added to the next EJB spec is ejb-jar
scoped JNDI (just as we have in our JIRA) and the injection algorithm
of "first bean-scoped enc, then ejb-jar-scoped enc" will have to be
added anyway.
-David