Laurent Rieu wrote:
Ok, I'm starting to get it.
So you're saying that Merlin always has a root block addressable via "/", but this root block has no real name, hence my problems trying stuff like "/root" as I expected the root block to be called "root". I actually have no real preference between having this root block unamed or having it always started and referenced as "root". I guess it would probably make it clearer if you always have a root block named "root".
The real question I have here is if we want to be able to add and remove blocks dynamically. If we want to do this them Merlin should be creating the root and any user supplied block should be installed as a subsidiary of the root block. With this approach, the "/" name makes sence.
What makes me think is that #<interface-name> part you can add to a URL to
have access to services exported by a block. Why do you treat blocks
differently from the components it contains, as a block is also a component
?
A block is treated differently because it can isolate services that are part of the implementation and not intended for publication outside of the block.
Maybe could Merlin understand the following url [base-url]/root/myblock as
an access to the block myblock and all the services it exports, meaning the
requester has to cast the returned object to the interface he / she expects,
provided of course that the returned object implements all the interfaces
(services) declared in the descriptors. I guess you're using dynamic proxies
to represent the services exported by a block.
That's correct.
This dynamic proxy could
implement ALL the interfaces that a block export, leaving the cast operation
to the user.
This is how it works now - this enables a block to act as a service provider to other components. The incomming invocations are delegated to the components the actually provide the services - as such - the block simply looks and behaves like a component.
I think this is exactly what is done when you request a "normal" component (ie not a block). A component exports services, and when you get that component from the container, it implements ALL the interfaces that are declared in the component descriptor. Otherwise (to remain coherent), you can proxify EVERY component that are returned by the container and make them implement either ONE interface (the interface beinig specified by the #<interface-name> part of the URL) or ALL interfaces (when nothing is specified in the URL). This would allow the following URL :
[base-url]/root : returns the root block as a component (proxy) implementing all the interfaces it exports.
Yep. Current behaviour.
[base-url]/root#my.package.MyService : returns the root block as a component (proxy) implementing the MyService interface (provided this root block really exports the MyService interface)
This could be done.
Would require some tweaking of the StandardBlock.getVirtualService( Object source, String ref ) implementation.
[base-url]/root/mycomponent : returns mycomponent contained in the root block. This component implements all the interfaces it declares in its deployment descriptor
Currently the implementation is not proxying the component interface because some additional thinking is required on (a) services that are classes as opposed to interfaces, and (b) the resulting need to declare a proxy policy. The issue here is that we cannot create a proxy if a service class is not an interface.
[base-url]/root/mycomponent#my.package.MyOtherService : returns mycomponent contained in the root block. This component implements the MyOtherService interface (provided this component really provides the MyOtherService interface).
This could be done.
Merlin could do some checking to see if a requested component implements the Service interface it is asked for. Proxying component allows returned objects to be narrowed to what the user really expects, hiding the technical / undesirable details Merlin needs in its internals (useful for block component). Proxying components could also allow some technical plumbing, but that is another topic ;-)
What do you think ?
If you can patch the StardardBlock proxy management, I can dig into the root block question and enhance how this is managed (stuff at the kernel, block loader level).
Cheers, Steve.
Laurent
----- Original Message ----- From: "Stephen McConnell" <[EMAIL PROTECTED]> To: "Avalon framework users" <[EMAIL PROTECTED]> Sent: Thursday, June 12, 2003 1:48 PM Subject: Re: [merlin] URL block protocol
Hi Laurent:mature,
The info your requesting:
The root block is addressable via "/" Sub-blocks are addressable via "/<block-name>/<block-name> A service exported by a block is available via appending #<interface-name> to the URL.
Laurent Rieu wrote:
Hi,
I'm guessing that as the JNDI-zed way to access services is not that
oneI have to do with the URL-ized way.
Its a minimal first cut. The better approach is a full JNDI implementation that handles the block protocol without requiring any Merlin API references.
According to the
BlockURLHandler.parseURL() javadoc, Block URL are supposed to conform to
file/root#org.apache.playground.Demoof the following patterns: block://localhost/root#org.apache.playground.Demo block://localhost/root/subcontainer/demo
This is addressing a top level component (or container) named root. This is not the same as addressing the top level container which is named "/".
Well, I'm having a single component deployed twice in two different containers, the root one and a 'test' one, as shown in the following block.xml file:
<block> <info> <name>root</name> </info> <implementation> <component name="resource-manager" class="test.services.resources.ResourceManagerImpl" activation="startup"> </component> <container name="test"> <component name="resource-manager" class="test.services.resources.ResourceManagerImpl" activation="startup"> </component> </container> </implementation> </block>
Fist, what's about this 'root' container ?
The name of a block is only relevant for sub containers. There is an open question here - should Merlin establish a root container by default? In which case your assumptions o9n addressing would have worked. My feeling is that maybe we should do this - i.e. establish a root block automatically then add blocks and componets to the root.
Is it an implicit name (which has
nothing to do with the actual block name as declared in the block.xml
?).Yes.
<snip/>The fact is that trying to use the URL pattern [kernelURL]/root/resource-manager it looks like Merlin doesn't know about the 'root' path as shown in the stack trace below :
Yep - because your now addressing the top level block.This works when I remove the 'root' element in the URL (([kernelURL]/resource-manager).
The following URL don't work either (maybe that is what's expected, but a litte documentation about the URL pattern would help ;-) ) : [kernelURL]/root#test.services.resources.ResourceManager
Because /root addresses a container or component named root containered within the top level container.
:-)(test.services.resources.ResourceManager being the service interface exported by my component) [kernelURL]/root#test.services.resources.ResourceManagerImpl [kernelURL]/#test.services.resources.ResourceManager [kernelURL]/#test.services.resources.ResourceManagerImpl [kernelURL]/test#test.services.resources.ResourceManager [kernelURL]/test#test.services.resources.ResourceManagerImpl
Actually, the only URLs that work seem to be: [kernelURL]/resource-manager [kernelURL]/test/resource-manager
Laurent (who thinks this URL pattern should be clarified !)
Maybe should add an implict block as "/" so that /root makes sence) What are you thoughts on this?
SJM
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
************************************************************************ Ce message a ete inspecte par un anti-virus
Nous vous rappelons que la taille des messages ne doit pas depasser 1.5 Mo ************************************************************************
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
