Peter Royal wrote:
> On Wednesday 14 August 2002 10:04 am, Igor Fedorenko wrote:
>
[skiped]
>>>>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"
> class="com.thinkdynamics.proxy.GlueProxy"
> xinfo="resource://com/thinkdynamics/blocks/MyBlock.xinfo"/>
No, this won't do. What if GlueProxy depends on GlueRegistry (as it does
in my prototype)? The only part of xinfo that could change is
<services>. Other parts (<block>, <management-access-points> and
<dependencies>) should always be the same as specified by block
developer. Imagine, when a new version of a block comes out you need to
verify all derived xinfos to make sure that they are still consistent
with the block. If you do not like service declaration inside
assemble.xml we could define another file format for that, to be used like:
<block name="my-block-remote"
class="com.thinkdynamics.proxy.GlueProxy"
service="resource://com/thinkdynamics/blocks/MyBlock.sinfo"/>
but I do not see big advantage of doing this.
--
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]>
