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 Wed, 14 Aug 2002 14:27:14 GMT
On Wednesday 14 August 2002 10:04 am, Igor Fedorenko wrote:
> 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.

I'd make the interceptor hierarchy be:

System -> App Level -> Block Level

So any per-app interceptors get called before per-block ones.

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

yuk, i'd be -1 on that, smells of flexibility syndrome..

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

that sounds like two log interceptors vs an override... but again.. seems too 
broad up front without any forseeable use (in my eyes)

> Personally, I would start with per-block interceptors and add
> per-application later.

a very sensible way to go. Always best to start small :)

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

What's the core need of this? To have a generic "remoting" block that can 
implement any service, defined by its configuration?

If so, the problem is that you can't have multiple xinfo declarations per 
block since the xinfo is coded to be com.thinkdynamics.proxy.GlueProxy.xinfo

So what you really need is the ability to declare where the xinfo document is, 
vs the automagic discovery? Something like:

  <block name="my-block-remote"


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>

View raw message