avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Fedorenko <ifedore...@thinkdynamics.com>
Subject three improvements to avalon/phoenix
Date Tue, 13 Aug 2002 20:58:10 GMT
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>


Mime
View raw message