DO NOT REPLY [Bug 12405] New: - Interceptors

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12405>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12405

Interceptors

           Summary: Interceptors
           Product: Avalon
           Version: unspecified
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: Phoenix
        AssignedTo: avalon-phoenix-dev@jakarta.apache.org
        ReportedBy: donaldp@apache.org


Currently Phoenix will Proxy the service interfaces of all components unless 
explicitly asked not to. As a result no client will ever have a direct 
reference on another object. 

This gives us the ability to insert "Interceptors" in the call for every 
method. Interceptors allow us to plug in functionality when making an 
invocation on object. 

In EJB servers, Interceptors are used to decorate the calls with specific 
functionality. You can get Interceptors to
* Manage transaction state (commit, rollback on fail etc).
* Manage security (make sure caller has right permissions, the caller principle 
is set up and that the method is invoked as the correct subject
* Audit calls (make sure all calls are logged)
etc.

Non ejb related interceptors include
* Manage application isolation. (ie make sure the caller context does not 
interfere with calleds context. This involves setting Context ClassLoader etc).
* Make sure that stale references are not used (ie re-aquire service from pool 
for call then put back in pool after use)

Usually each call will pass through a interceptor chain where each interceptor 
is given the opportunity to do something.

Interceptors have to be specially handled as they need to be created before any 
call can be made against the service. They are also unique in that the 
interceptor chain may be different dependending on "who" is making the call and 
what they are making the call on.

For example a component C1, may expose services S1 and S2. When a call is made 
on S1 from component C2 then Interceptor chain I1 is used, while if C2 made a 
call on S2 then chain I2 is used. If another component C3 made a call on S1 
then I3 may be used.

As you can see this gets very complex, very fast. Because of this we need to 
define a simple, yet sufficiently capable enough configuration format for these 
interceptr chains. (If this is even possible).

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>