avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Fedorenko <ifedore...@thinkdynamics.com>
Subject Re: three improvements to avalon/phoenix
Date Wed, 14 Aug 2002 14:04:12 GMT
Peter Royal wrote:
> On Tuesday 13 August 2002 04:58 pm, Igor Fedorenko wrote:
>>During last few days I was investigating avalon/phoenix to see if it can
>>be used in our project. I really liked what phoenix does but there were
> excellent!
>>1. Block invocation interceptors.
>>Consider following <block> element of modified assemble.xml file
>>   <block name="my-block" class="com.thinkdynamics.blocks.MyBlockImpl">
>>     <invocation-interceptors>
>>       <interceptor
>>            class="com.thinkdynamics.interceptors.JAASInterceptor"/>
>>       <interceptor
>>            class="com.thinkdynamics.interceptors.LoggingInterceptor"/>
>>     </invocation-interceptors>
>>   </block>
> <snip/>
>>To achieve this I've replaced BlockInvocationHandler with a chain of
>>interceptors, first interceptor (dynamic proxy, created by
>>BlockInvocationHandler) calls second interceptor, second calls third and
>>so on until last interceptor in the chain which calls the block. Of
>>course, if <block> does not have any interceptors configured the block
>>is called directly from the dynamic proxy.
> very cool. the only suggestion i would have on this is perhaps sometimes it 
> might be useful to have an interceptor per-application (such as the logging 
> interceptor, define in once place to log all calls for all blocks).
I agree that per-application interceptors would simplify assembly, 
however such interceptors raise few questions:
- let say we have interceptors defined both at application and at block 
level. What would be an invocation order of interceptors in this case? 
We can add priority to interceptor configuration and sort them.
- it would be nice to be able to define per-application interceptors 
even if they do not apply to all blocks in the app. For example, 
JAASInterceptor applies only to blocks with security configuration. To 
accommodate this we need to extend interceptor interface to add 
something like "boolean accepts(BlockInfo)".
- application assembler might want to "overwrite" an application 
interceptor at a block level. For example, define per-application log 
interceptor and another log interceptor for one of the blocks.

Personally, I would start with per-block interceptors and add 
per-application later.

>>2. Assemble-time configuration of services provided by a block
>>An example of a block that needs assemble-time service configuration
>>would be generic soap proxy block that implements whatever service is
>>provided by a soap service the block is connected to. Here is an example
>>configuration for such block
>>   <block name="my-block-remote"
>>              class="com.thinkdynamics.proxy.GlueProxy">
>>     <services>
>>       <service name="com.thinkdynamics.blocks.MyBlock"/>
>>     </services>
>>   </block>
>>To support this I needed to change two things. First I needed to allow
>>service definition in assemble.xml file. This change has a value of its
>>own, for example, application assembler might want limit services
>>provided by a block. Second change was to allow definition of blocks
>>that support any service, to do that I defined
>>org.apache.avalon.phoenix.Invocable interface which extends
>>java.lang.reflect.InvocationHandler. If a block implements Invocable
>>BlockInvocationHandler calls block.invoke method instead of
> I'm a little unsure if this is the best way to implement this, namely if 
> introducing service declarations into assembly.xml is a good idea.
Yes, I agree with your concerns. What if I add another method to 
Invocable interface to check if a block implements an interface? 
Something like "boolean provides(Class interface)". However, I do not 
know if this method can be plugged into block lifecicle easily.

> I do see the value in it though, as it would be a very easy way to pull in 
> remote interfaces (be it SOAP, XML-RPC, RMI, AltRMI, IIOP..)
>>3. Installation of application from file structures other then packaged
>>I defined new interface org.apache.avalon.phoenix.interfaces.Installer,
>>org.apache.avalon.phoenix.components.deployer.installer.Installer to
>>DefaultInstaller and change DefaultDeployer to locate Installer through
>>serviceManager.lookup call.
>>This way I can, for example, provide an installer that installs
>>applications directly from file structures maintained by Eclipse IDE
>>thus eliminating need for application packaging during development.
> Ooh! Send a patch for this :)

Ok, I'll send a patch later today or tomorrow -- I need to clean up the 
code a little bit ;-)

Igor Fedorenko
Think smart. Think automated. Think Dynamics.

To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>

View raw message