You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by is_maximum <mn...@gmail.com> on 2009/03/09 08:20:18 UTC
default interceptor
Hello
I have defined a default interceptor as follows but there is a warning that
says :
WARN - InterceptorBinding references non-existent (undeclared) interceptor:
com.foo.interceptor.RequestDataInterceptor
and this interceptor never being executed.
<interceptor-binding>
<ejb-name>*</ejb-name>
<interceptor-order>
<interceptor-class>com.foo.interceptor.RequestDataInterceptor</interceptor-class>
</interceptor-order>
</interceptor-binding>
can anyone help me out this problem?
-----
--
Regards
Mohammad Norouzi
Help each other to reach the future faster
http://pixelshot.wordpress.com Pixelshot Photoblog
http://brainable.blogspot.com Brainable Blog
--
View this message in context: http://www.nabble.com/default-interceptor-tp22408000p22408000.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: default interceptor
Posted by David Blevins <da...@visi.com>.
On Aug 9, 2009, at 6:29 AM, is_maximum wrote:
> David Blevins wrote:
>>
>> Thanks again for bringing this up, you've had a direct impact on the
>> EJB 3.1 spec!
>>
>> -David
>
> Thanks David
> Recently we encountered another issue regarding interceptors. Before
> I get
> into it let me explain the situation. We are developing banking
> systems.
> There are lots of services we provided and each use case developed
> by one or
> two poeple depending on the use case. Now consider I as a developer
> of use
> case 1 (UC1) in my service method S1, need a service (S2) which is
> provided
> by UC2. This S2 also provided as webservice or RMI to the clients.
> We have
> defined some interceptors that each service method MUST use them.
> Now the
> problem is if a request from the client calls service S1 and this
> service
> invokes the S2 because both service methods have interceptor I1 then
> I1 will
> be invoked twice and this cause some problem depending on the logic
> used in
> it.
>
> Currently to get around this issue we have defined two service
> methods one
> has internal use and the other provided for the clients and of
> course one of
> them will call the another. This seems very good idea but in case of
> having
> many methods like this we will end up with millions of codes and the
> number
> of methods will be doubled
>
> another way to get around this problem is using a ThreadLocal
> (actually we
> need InheritableThreadLocal) to check if this is first method call
> and then
> set a variable to true so in next invocation of the interceptor we can
> prevent executing that but we need to place a finally block to set
> the value
> of thread local to false to be reset for the next time of calling the
> service
>
> I post this if you can engage a way to resolve this problem or maybe a
> feature that can be enabled through config files ejb-jar.xml
>
> I am interested to know your idea on this and perhaps you may have a
> third
> way for this problem
>
The ThreadLocal approach is the best option with the current APIs.
All app servers use them quite extensively to solve the kinds of
functionality you describe.
We actually only have one thread local for the most part and
everything hinges on it and can be made unaware of the thread local
concept at all. The best way to describe how we do it would be to
imagine that the javax.interceptor.InvocationContext object had an
additional method on it called "getPreviousContext" or
"getCallingContext" which gave you the InvocationContext of the person
who called you. With this you can move state from the old
InvocationContext.getContextData() to the new
InvocationContext.getContextData() or even just call
getCallingContext() recursively to look as many calls back as you
wish. With that you can do an infinite amount of state tracking as
well as write some pretty impressive diagnostic tools.
To write that yourself you'd simply need an global interceptor like
this: http://gist.github.com/168153
With that you're good to go.
-David
Re: default interceptor
Posted by is_maximum <mn...@gmail.com>.
David Blevins wrote:
>
>
>
> Thanks again for bringing this up, you've had a direct impact on the
> EJB 3.1 spec!
>
>
> -David
>
>
>
Thanks David
Recently we encountered another issue regarding interceptors. Before I get
into it let me explain the situation. We are developing banking systems.
There are lots of services we provided and each use case developed by one or
two poeple depending on the use case. Now consider I as a developer of use
case 1 (UC1) in my service method S1, need a service (S2) which is provided
by UC2. This S2 also provided as webservice or RMI to the clients. We have
defined some interceptors that each service method MUST use them. Now the
problem is if a request from the client calls service S1 and this service
invokes the S2 because both service methods have interceptor I1 then I1 will
be invoked twice and this cause some problem depending on the logic used in
it.
Currently to get around this issue we have defined two service methods one
has internal use and the other provided for the clients and of course one of
them will call the another. This seems very good idea but in case of having
many methods like this we will end up with millions of codes and the number
of methods will be doubled
another way to get around this problem is using a ThreadLocal (actually we
need InheritableThreadLocal) to check if this is first method call and then
set a variable to true so in next invocation of the interceptor we can
prevent executing that but we need to place a finally block to set the value
of thread local to false to be reset for the next time of calling the
service
I post this if you can engage a way to resolve this problem or maybe a
feature that can be enabled through config files ejb-jar.xml
I am interested to know your idea on this and perhaps you may have a third
way for this problem
Thanks
-----
--
Regards
Mohammad Norouzi
Help each other to reach the future faster
http://pixelshot.wordpress.com Pixelshot Photoblog
http://brainable.blogspot.com Brainable Blog
--
View this message in context: http://www.nabble.com/default-interceptor-tp22408000p24887176.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: default interceptor
Posted by David Blevins <da...@visi.com>.
On Mar 10, 2009, at 3:02 AM, David Blevins wrote:
>
> On Mar 10, 2009, at 12:25 AM, is_maximum wrote:
>
>> For example one important thing that we were always in need
>> is ability to passing parameter from a business method to its
>> declared
>> interceptors.
>
> One trick that will work for non-singletons is to put an
> AroundInvoke method in your bean and then simply save the
> InvocationContext or InvocationContext.getContextData() map as a
> variable which you can then access in your business method and use
> to get data from and pass data to your interceptors.
>
> For singletons it's not possible as they're multithreaded. That
> definitely is an issue. I've raised it in the EJB 3.1 Expert Group,
> we'll see what happens. It'd be nice to expose the
> InvocationContext or InvocationContext.getContextData() map through
> the SessionContext/MessageDrivenContext interfaces so that they can
> be easily accessed in a business method.
Just an update. I did raise this issue in the EJB 3.1 Expert Group.
Looks like based on recent discussion that we will be able to get a
getContextData() method added to the SessionContext interface for the
case described above.
Thanks again for bringing this up, you've had a direct impact on the
EJB 3.1 spec!
-David
Re: default interceptor
Posted by David Blevins <da...@visi.com>.
On Mar 10, 2009, at 12:25 AM, is_maximum wrote:
> For example one important thing that we were always in need
> is ability to passing parameter from a business method to its declared
> interceptors.
One trick that will work for non-singletons is to put an AroundInvoke
method in your bean and then simply save the InvocationContext or
InvocationContext.getContextData() map as a variable which you can
then access in your business method and use to get data from and pass
data to your interceptors.
For singletons it's not possible as they're multithreaded. That
definitely is an issue. I've raised it in the EJB 3.1 Expert Group,
we'll see what happens. It'd be nice to expose the InvocationContext
or InvocationContext.getContextData() map through the SessionContext/
MessageDrivenContext interfaces so that they can be easily accessed in
a business method.
Thanks again for posting. Keep the feedback coming!
-David
Re: default interceptor
Posted by is_maximum <mn...@gmail.com>.
Thanks for creating that issue in JIRA. Unfortunately this is ruled by Sun's
spec and there are many uncomfortable things in EJB3. The only hope we, me
and my colleagues, have is that all or at least most of them being removed
in EJB3.1 Spec. For example one important thing that we were always in need
is ability to passing parameter from a business method to its declared
interceptors. However this might seem a little weird or wrong in terms of
software design, in that case it is reasonable not to do that.
David Blevins wrote:
>
>
> On Mar 9, 2009, at 6:19 AM, is_maximum wrote:
>
>> Thanks David for your complete reply.
>> Yes it was helpful and it works fine. I thought that by declaring
>> class
>> interceptor the container would understand it but he is really
>> dummy ;)
>
> Agreed and thanks for posting. We love it when people post about
> minor annoyances as they are usually so easy to clear up and make a
> big difference collectively.
>
> Went ahead and added that feature:
> https://issues.apache.org/jira/browse/OPENEJB-1007
>
> Definitely if you run into anything else that makes you scratch your
> head, don't hesitate to post.
>
> Thank you!
>
> -David
>
>
>>
>> David Blevins wrote:
>>>
>>>
>>> On Mar 9, 2009, at 12:20 AM, is_maximum wrote:
>>>
>>>>
>>>> Hello
>>>>
>>>> I have defined a default interceptor as follows but there is a
>>>> warning that
>>>> says :
>>>>
>>>> WARN - InterceptorBinding references non-existent (undeclared)
>>>> interceptor:
>>>> com.foo.interceptor.RequestDataInterceptor
>>>>
>>>> and this interceptor never being executed.
>>>>
>>>>
>>>> <interceptor-binding>
>>>> <ejb-name>*</ejb-name>
>>>> <interceptor-order>
>>>>
>>>> <interceptor-class>com.foo.interceptor.RequestDataInterceptor</
>>>> interceptor-class>
>>>> </interceptor-order>
>>>> </interceptor-binding>
>>>>
>>>> can anyone help me out this problem?
>>>
>>>
>>> Sure. It's a little strange, but per spec interceptors are declared
>>> independently like ejbs are and then the two are bound together in
>>> the
>>> assembly descriptor. Here's a small example off an all annotation
>>> version and the equivalent in xml:
>>>
>>> The app:
>>>
>>> @Stateful
>>> @Interceptors(OrangeInterceptor.class)
>>> public class OrangeBean implements OrangeLocal {
>>>
>>> public int echo(int i) {
>>> return i;
>>> }
>>> }
>>>
>>> public interface OrangeLocal {
>>> int echo(int i);
>>> }
>>>
>>> public class OrangeInterceptor {
>>>
>>> @PostConstruct
>>> public void construct(InvocationContext context){}
>>>
>>> @AroundInvoke
>>> public Object invoke(InvocationContext context) throws
>>> Exception {
>>> return context.proceed();
>>> }
>>> }
>>>
>>> The resulting ejb-jar.xml:
>>>
>>> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
>>> <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee">
>>> <enterprise-beans>
>>> <session id="OrangeBean">
>>> <ejb-name>OrangeBean</ejb-name>
>>> <business-local>org.superbiz.OrangeLocal</business-local>
>>> <ejb-class>org.superbiz.OrangeBean</ejb-class>
>>> <session-type>Stateful</session-type>
>>> <transaction-type>Container</transaction-type>
>>> </session>
>>> </enterprise-beans>
>>> <interceptors>
>>> <interceptor>
>>> <interceptor-class>org.superbiz.OrangeInterceptor</
>>> interceptor-class>
>>> <around-invoke>
>>> <class>org.superbiz.OrangeInterceptor</class>
>>> <method-name>invoke</method-name>
>>> </around-invoke>
>>> <post-construct>
>>> <lifecycle-callback-class>org.superbiz.OrangeInterceptor
>>> </lifecycle-callback-class>
>>> <lifecycle-callback-method>construct</lifecycle-callback-
>>> method>
>>> </post-construct>
>>> </interceptor>
>>> </interceptors>
>>> <assembly-descriptor>
>>> <interceptor-binding>
>>> <ejb-name>OrangeBean</ejb-name>
>>> <interceptor-class>org.superbiz.OrangeInterceptor</
>>> interceptor-class>
>>> </interceptor-binding>
>>> </assembly-descriptor>
>>> </ejb-jar>
>>>
>>> So your binding is correct, you just need to declare your
>>> interceptor. At the very least a minimal declaration like so:
>>>
>>> <interceptors>
>>> <interceptor>
>>> <interceptor-class>org.superbiz.OrangeInterceptor</
>>> interceptor-class>
>>> </interceptor>
>>> </interceptors>
>>>
>>> This would assume that the interceptor class is using the
>>> @AroundInvoke annotation, if not you would need to add the <around-
>>> invoke> tag as shown above.
>>>
>>> Hope this helps!
>>>
>>> -David
>>>
>>>
>>>
>>
>>
>> -----
>> --
>> Regards
>>
>> Mohammad Norouzi
>>
>> Help each other to reach the future faster
>>
>> http://pixelshot.wordpress.com Pixelshot Photoblog
>>
>> http://brainable.blogspot.com Brainable Blog
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/default-interceptor-tp22408000p22412957.html
>> Sent from the OpenEJB User mailing list archive at Nabble.com.
>>
>>
>
>
>
-----
--
Regards
Mohammad Norouzi
Help each other to reach the future faster
http://pixelshot.wordpress.com Pixelshot Photoblog
http://brainable.blogspot.com Brainable Blog
--
View this message in context: http://www.nabble.com/default-interceptor-tp22408000p22429192.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: default interceptor
Posted by David Blevins <da...@visi.com>.
On Mar 9, 2009, at 6:19 AM, is_maximum wrote:
> Thanks David for your complete reply.
> Yes it was helpful and it works fine. I thought that by declaring
> class
> interceptor the container would understand it but he is really
> dummy ;)
Agreed and thanks for posting. We love it when people post about
minor annoyances as they are usually so easy to clear up and make a
big difference collectively.
Went ahead and added that feature: https://issues.apache.org/jira/browse/OPENEJB-1007
Definitely if you run into anything else that makes you scratch your
head, don't hesitate to post.
Thank you!
-David
>
> David Blevins wrote:
>>
>>
>> On Mar 9, 2009, at 12:20 AM, is_maximum wrote:
>>
>>>
>>> Hello
>>>
>>> I have defined a default interceptor as follows but there is a
>>> warning that
>>> says :
>>>
>>> WARN - InterceptorBinding references non-existent (undeclared)
>>> interceptor:
>>> com.foo.interceptor.RequestDataInterceptor
>>>
>>> and this interceptor never being executed.
>>>
>>>
>>> <interceptor-binding>
>>> <ejb-name>*</ejb-name>
>>> <interceptor-order>
>>>
>>> <interceptor-class>com.foo.interceptor.RequestDataInterceptor</
>>> interceptor-class>
>>> </interceptor-order>
>>> </interceptor-binding>
>>>
>>> can anyone help me out this problem?
>>
>>
>> Sure. It's a little strange, but per spec interceptors are declared
>> independently like ejbs are and then the two are bound together in
>> the
>> assembly descriptor. Here's a small example off an all annotation
>> version and the equivalent in xml:
>>
>> The app:
>>
>> @Stateful
>> @Interceptors(OrangeInterceptor.class)
>> public class OrangeBean implements OrangeLocal {
>>
>> public int echo(int i) {
>> return i;
>> }
>> }
>>
>> public interface OrangeLocal {
>> int echo(int i);
>> }
>>
>> public class OrangeInterceptor {
>>
>> @PostConstruct
>> public void construct(InvocationContext context){}
>>
>> @AroundInvoke
>> public Object invoke(InvocationContext context) throws
>> Exception {
>> return context.proceed();
>> }
>> }
>>
>> The resulting ejb-jar.xml:
>>
>> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
>> <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee">
>> <enterprise-beans>
>> <session id="OrangeBean">
>> <ejb-name>OrangeBean</ejb-name>
>> <business-local>org.superbiz.OrangeLocal</business-local>
>> <ejb-class>org.superbiz.OrangeBean</ejb-class>
>> <session-type>Stateful</session-type>
>> <transaction-type>Container</transaction-type>
>> </session>
>> </enterprise-beans>
>> <interceptors>
>> <interceptor>
>> <interceptor-class>org.superbiz.OrangeInterceptor</
>> interceptor-class>
>> <around-invoke>
>> <class>org.superbiz.OrangeInterceptor</class>
>> <method-name>invoke</method-name>
>> </around-invoke>
>> <post-construct>
>> <lifecycle-callback-class>org.superbiz.OrangeInterceptor
>> </lifecycle-callback-class>
>> <lifecycle-callback-method>construct</lifecycle-callback-
>> method>
>> </post-construct>
>> </interceptor>
>> </interceptors>
>> <assembly-descriptor>
>> <interceptor-binding>
>> <ejb-name>OrangeBean</ejb-name>
>> <interceptor-class>org.superbiz.OrangeInterceptor</
>> interceptor-class>
>> </interceptor-binding>
>> </assembly-descriptor>
>> </ejb-jar>
>>
>> So your binding is correct, you just need to declare your
>> interceptor. At the very least a minimal declaration like so:
>>
>> <interceptors>
>> <interceptor>
>> <interceptor-class>org.superbiz.OrangeInterceptor</
>> interceptor-class>
>> </interceptor>
>> </interceptors>
>>
>> This would assume that the interceptor class is using the
>> @AroundInvoke annotation, if not you would need to add the <around-
>> invoke> tag as shown above.
>>
>> Hope this helps!
>>
>> -David
>>
>>
>>
>
>
> -----
> --
> Regards
>
> Mohammad Norouzi
>
> Help each other to reach the future faster
>
> http://pixelshot.wordpress.com Pixelshot Photoblog
>
> http://brainable.blogspot.com Brainable Blog
>
>
> --
> View this message in context: http://www.nabble.com/default-interceptor-tp22408000p22412957.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
>
Re: default interceptor
Posted by is_maximum <mn...@gmail.com>.
Thanks David for your complete reply.
Yes it was helpful and it works fine. I thought that by declaring class
interceptor the container would understand it but he is really dummy ;)
thanks again
David Blevins wrote:
>
>
> On Mar 9, 2009, at 12:20 AM, is_maximum wrote:
>
>>
>> Hello
>>
>> I have defined a default interceptor as follows but there is a
>> warning that
>> says :
>>
>> WARN - InterceptorBinding references non-existent (undeclared)
>> interceptor:
>> com.foo.interceptor.RequestDataInterceptor
>>
>> and this interceptor never being executed.
>>
>>
>> <interceptor-binding>
>> <ejb-name>*</ejb-name>
>> <interceptor-order>
>>
>> <interceptor-class>com.foo.interceptor.RequestDataInterceptor</
>> interceptor-class>
>> </interceptor-order>
>> </interceptor-binding>
>>
>> can anyone help me out this problem?
>
>
> Sure. It's a little strange, but per spec interceptors are declared
> independently like ejbs are and then the two are bound together in the
> assembly descriptor. Here's a small example off an all annotation
> version and the equivalent in xml:
>
> The app:
>
> @Stateful
> @Interceptors(OrangeInterceptor.class)
> public class OrangeBean implements OrangeLocal {
>
> public int echo(int i) {
> return i;
> }
> }
>
> public interface OrangeLocal {
> int echo(int i);
> }
>
> public class OrangeInterceptor {
>
> @PostConstruct
> public void construct(InvocationContext context){}
>
> @AroundInvoke
> public Object invoke(InvocationContext context) throws
> Exception {
> return context.proceed();
> }
> }
>
> The resulting ejb-jar.xml:
>
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee">
> <enterprise-beans>
> <session id="OrangeBean">
> <ejb-name>OrangeBean</ejb-name>
> <business-local>org.superbiz.OrangeLocal</business-local>
> <ejb-class>org.superbiz.OrangeBean</ejb-class>
> <session-type>Stateful</session-type>
> <transaction-type>Container</transaction-type>
> </session>
> </enterprise-beans>
> <interceptors>
> <interceptor>
> <interceptor-class>org.superbiz.OrangeInterceptor</
> interceptor-class>
> <around-invoke>
> <class>org.superbiz.OrangeInterceptor</class>
> <method-name>invoke</method-name>
> </around-invoke>
> <post-construct>
> <lifecycle-callback-class>org.superbiz.OrangeInterceptor
> </lifecycle-callback-class>
> <lifecycle-callback-method>construct</lifecycle-callback-
> method>
> </post-construct>
> </interceptor>
> </interceptors>
> <assembly-descriptor>
> <interceptor-binding>
> <ejb-name>OrangeBean</ejb-name>
> <interceptor-class>org.superbiz.OrangeInterceptor</
> interceptor-class>
> </interceptor-binding>
> </assembly-descriptor>
> </ejb-jar>
>
> So your binding is correct, you just need to declare your
> interceptor. At the very least a minimal declaration like so:
>
> <interceptors>
> <interceptor>
> <interceptor-class>org.superbiz.OrangeInterceptor</
> interceptor-class>
> </interceptor>
> </interceptors>
>
> This would assume that the interceptor class is using the
> @AroundInvoke annotation, if not you would need to add the <around-
> invoke> tag as shown above.
>
> Hope this helps!
>
> -David
>
>
>
-----
--
Regards
Mohammad Norouzi
Help each other to reach the future faster
http://pixelshot.wordpress.com Pixelshot Photoblog
http://brainable.blogspot.com Brainable Blog
--
View this message in context: http://www.nabble.com/default-interceptor-tp22408000p22412957.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: default interceptor
Posted by David Blevins <da...@visi.com>.
On Mar 9, 2009, at 12:20 AM, is_maximum wrote:
>
> Hello
>
> I have defined a default interceptor as follows but there is a
> warning that
> says :
>
> WARN - InterceptorBinding references non-existent (undeclared)
> interceptor:
> com.foo.interceptor.RequestDataInterceptor
>
> and this interceptor never being executed.
>
>
> <interceptor-binding>
> <ejb-name>*</ejb-name>
> <interceptor-order>
>
> <interceptor-class>com.foo.interceptor.RequestDataInterceptor</
> interceptor-class>
> </interceptor-order>
> </interceptor-binding>
>
> can anyone help me out this problem?
Sure. It's a little strange, but per spec interceptors are declared
independently like ejbs are and then the two are bound together in the
assembly descriptor. Here's a small example off an all annotation
version and the equivalent in xml:
The app:
@Stateful
@Interceptors(OrangeInterceptor.class)
public class OrangeBean implements OrangeLocal {
public int echo(int i) {
return i;
}
}
public interface OrangeLocal {
int echo(int i);
}
public class OrangeInterceptor {
@PostConstruct
public void construct(InvocationContext context){}
@AroundInvoke
public Object invoke(InvocationContext context) throws
Exception {
return context.proceed();
}
}
The resulting ejb-jar.xml:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee">
<enterprise-beans>
<session id="OrangeBean">
<ejb-name>OrangeBean</ejb-name>
<business-local>org.superbiz.OrangeLocal</business-local>
<ejb-class>org.superbiz.OrangeBean</ejb-class>
<session-type>Stateful</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
<interceptors>
<interceptor>
<interceptor-class>org.superbiz.OrangeInterceptor</
interceptor-class>
<around-invoke>
<class>org.superbiz.OrangeInterceptor</class>
<method-name>invoke</method-name>
</around-invoke>
<post-construct>
<lifecycle-callback-class>org.superbiz.OrangeInterceptor
</lifecycle-callback-class>
<lifecycle-callback-method>construct</lifecycle-callback-
method>
</post-construct>
</interceptor>
</interceptors>
<assembly-descriptor>
<interceptor-binding>
<ejb-name>OrangeBean</ejb-name>
<interceptor-class>org.superbiz.OrangeInterceptor</
interceptor-class>
</interceptor-binding>
</assembly-descriptor>
</ejb-jar>
So your binding is correct, you just need to declare your
interceptor. At the very least a minimal declaration like so:
<interceptors>
<interceptor>
<interceptor-class>org.superbiz.OrangeInterceptor</
interceptor-class>
</interceptor>
</interceptors>
This would assume that the interceptor class is using the
@AroundInvoke annotation, if not you would need to add the <around-
invoke> tag as shown above.
Hope this helps!
-David