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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
