Peter Royal wrote: > 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). I agree that per-application interceptors would simplify assembly, however such interceptors raise few questions: - let say we have interceptors defined both at application and at block level. What would be an invocation order of interceptors in this case? We can add priority to interceptor configuration and sort them. - it would be nice to be able to define per-application interceptors even if they do not apply to all blocks in the app. For example, JAASInterceptor applies only to blocks with security configuration. To accommodate this we need to extend interceptor interface to add something like "boolean accepts(BlockInfo)". - application assembler might want to "overwrite" an application interceptor at a block level. For example, define per-application log interceptor and another log interceptor for one of the blocks.
Personally, I would start with per-block interceptors and add per-application later. >>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. Yes, I agree with your concerns. What if I add another method to Invocable interface to check if a block implements an interface? Something like "boolean provides(Class interface)". However, I do not know if this method can be plugged into block lifecicle easily. > > 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 :) Ok, I'll send a patch later today or tomorrow -- I need to clean up the code a little bit ;-) -- 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]>
