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