avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: three improvements to avalon/phoenix
Date Mon, 19 Aug 2002 11:43:39 GMT
On Wed, 14 Aug 2002 06:58, Igor Fedorenko wrote:
> 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).

One thing I have been playing with recently is the following.

<block name="my-block-remote"

Ignoring for the moment that I don't know anything about soap so the above is 
probably wrong way to designate a service. Alternatively you could look at it 
as remote blocks via 

<block name="my-block-remote"

The above would tell the container to load a component via the RMIFactory 
using the key "rmi://brainstem.dyndns.org/kane/ScoreDatabase". The RMIFactory 
would implement an interface like

public interface BlockFactory
  BlockInfo createBlockInfo( String implKey );
  Object createBlock( String implKey );

The RMIFactory would know that it has to look up the component in the RMI 
registry and that the component exposed certain interfaces (basically all its 
remote ones). The BlockInfo would be created to depends on the RMIRegistry 
block and expose the remote services etc.

I have implemented this in another container and it was relatively successful 
if a little bit more complex for the assembler.

Thoughts? Would this suit your needs?


Peter Donald
"All my life I wanted to be someone; I guess I should have been more 
-- Jane Wagner

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