avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Schier <MSch...@bsquare.com>
Subject RE: three improvements to avalon/phoenix
Date Tue, 13 Aug 2002 21:01:22 GMT
Wow. Number 3 I really really like. I hope it gets added to the CVS tree!!

Marc

> -----Original Message-----
> From: Igor Fedorenko [mailto:ifedorenko@thinkdynamics.com]
> Sent: Tuesday, August 13, 2002 1:58 PM
> To: Avalon-Phoenix Developers List
> Subject: three improvements to avalon/phoenix
> 
> 
> Hi Phoenix developers,
> 
> 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 
> few areas where I needed to extented phoenix a little bit. I 
> would like 
> to hear your opinion about those extentions - do they make sense or 
> there are other ways to solve the problem or suggested solution has 
> problems of its own. So, here is what I did and why I did it.
> 
> 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>
> Basically I want all calls to MyBlockImpl be routed through 
> JAASInterceptor, which verified caller's permissions, and 
> then through 
> LoggingInterceptor, which loggs calls to MyBlockImpl.
> 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.
> 
> 
> 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 
> method.invoke(block).
> 
> 
> 3. Installation of application from file structures other 
> then packaged 
> sar-file.
> I defined new interface 
> org.apache.avalon.phoenix.interfaces.Installer, 
> renamed 
> 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.
> 
> 
> Thank you for reading such long e-mail and I appreciate all 
> your comments.
> 
> -- 
> Igor Fedorenko
> Think smart. Think automated. Think Dynamics.
> www.thinkdynamics.com
> 
> 
> --
> 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>
> 

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


Mime
View raw message