Wow. Number 3 I really really like. I hope it gets added to the CVS tree!!
Marc > -----Original Message----- > From: Igor Fedorenko [mailto:[EMAIL PROTECTED]] > 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:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
