Re: default interceptor

[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

[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

[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.