avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Royal <pro...@apache.org>
Subject Re: three improvements to avalon/phoenix
Date Tue, 13 Aug 2002 21:08:09 GMT
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).

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

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.

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

Ooh! Send a patch for this :)
-pete

-- 
peter royal -> proyal@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