Life is hard, and then you die wrote:
Hi,
I'm building an app-server around rpc calls, I decided to use the
avalon framework and merlin, and the fulcrum-xmlrpc and apache-xmlrpc
stuff. However, I've run into a slight problem.
So do I.
For those unfamiliar with the fulcrum-xmlrpc component here's a sample of the relevant part of the config in the block.xml:
<component name="xmlrpc-server" class="org.apache.fulcrum.xmlrpc.DefaultXmlRpcComponent"> <configuration> <handlers> <handler> <name>rcp1</name> <role>rpc.api.1</role> </handler> <handler> <name>rcp2</name> <role>rpc.api.2</role> </handler> </handlers> </configuration> </component>
This configures the handlers for the incoming rpc calls - there may be
any number of them. The problem now is that the <role>s specify the keys
the component uses to look up the handlers in the service-manager. I.e.
I have a quasi-dynamic set of dependencies (the list is known at
assembly time, but not at component compilation time). Now while I can
obviously adjust the dependency declarations in the
DefaultXmlRpcComponent.xinfo to match those specified in the block.xml,
that would equally obviously be somewhat contrary to the idea of
components and their meta-data.
Correct.
Furthermore, while I could use a single handler which delegates to the real handlers, those handlers would then be outside the component framework, unless I also (re)implement all the container functionality in the single handler - neither is a particularly satisfying solution.
In effect - the rpc component is acting as a container and what is really needed here is for the service manager to delegate requests back to the block when lookup is invoked. This is what I've referred to as finder functionality under earler posts related to the xmlrpc component.
Instead, I'd really like a way to "extend" or "map" the dependencies at
assembly time. Note that I'm not talking about full run-time component
lookup, as for example talked about in the "Dependencies meta data in
Merlin" thread, http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread&from=475728&to=475728&first=1&count=10
, as I like and want the type checking that merlin can do for me during
assembly.
Yep - in this scenario we can preassemble all of the candidates in the container. What this means is that if your RPC component contains an invalid child component we can catch that at assembly time. Then at runtime we are just reaching in a grabbing a reference to the appropriate component.
To this end, we've come up with a suggestion for extending the dependency directives in the component declaration in the block.xml. An example syntax would be something along the lines of the following:
<component ...> ... <dependencies> <dependency key="..."> <filter class="..."> ... filter-specific configs </filter> </dependency> </dependencies> </component>
(maybe there's a better expression than 'filter'). As an example, the recently added select stuff could be modeled and implemented as a filter:
<dependency key="..."> <filter class="org.apache.avalon.composition.data.Select"> <select feature="blah" value="42" match="equals"/> <select feature="foo" match="exists"/> </filter> </dependency>
And of course folks could define their own filters.
This is perfectly viable - in fact there are some hooks for doing this sort of thing (even the work hooks is too stong). More specifically I did some work on this and ended up putting it on the side pending a moment when I could take a look at how to resolve filtering using regual expressions. What your describing is basically what I had in mind - defintion of a dependency with a set of selection criteria.
Although I not convinced that this is the baest approach with repspect to the xmlrpc component - still think the right way to solve that liettle chanlenge is a finder based block (but maybe thats just because I've just gone off in that direction).
Now the point of the filter would be to generate a list of dependency models, i.e. the interface would possibly be something along the lines of
public interface DependencyFilter { DependencyModel[] filter(Configuration config, DeploymentContext context, DependencyDescriptor descriptor) throws FilterException; }
The interesting thing, and what I'm really clamoring for, is that this can generate more than one DependencyModel for a given DependencyDescriptor. This means I could solve my original problem by using a (new) filter with something like this:
<component name="xmlrpc-server" class="org.apache.fulcrum.xmlrpc.DefaultXmlRpcComponent" <configuration> <handlers> <handler> <name>rcp1</name> <role>rpc.api.1</role> </handler> <handler> <name>rcp2</name> <role>rpc.api.2</role> </handler> </handlers> </configuration>
<dependencies> <dependency key="handler"> <filter class="org.apache.avalon.composition.data.MultiMatch"> <match key="rpc.api.1" type="com.acme.rpc.Api1"/> <match key="rpc.api.2" type="com.acme.rpc.Api2"/> </filter> </dependency> </dependencies> </component>
and the DefaultXmlRpcComponent.xinfo could then contain a generic dependency declaration:
<type> ... <dependencies> <dependency key="handler" type="org.apache.xmlrpc.XmlRpcHandler"/> </dependencies> ... </type>
The MultiMatch above would generate two DependencyModels in this case, with the keys "rpc.api.1" and "rpc.api.2", and hence there would be two components in the ServiceManager under the desired keys. The rest of the dependency resolution rules would stay the same as they are currently.
Before I go and code this up, I was wondering if this sounds reasonable, or if there is other work already in progress to solve this sort of problem. I think this suggestion still follows the philosophy of merlin, as outlined by Stephen McConnell in the above thread, and I'd like to stick to merlin if possible.
Honestly - go ahead and code it up - I'm presuming you have already been deep inside the composition apis and have figured out that depeednecy slectionis a fiable approach. I think it also makes sence for me to continue with the finder based block semantics - because at the end of the day I think both are important core additions.
One question - concerning selection creitera - what sort of rules were you thinking of - and were you considering regular expressions?
Cheers, Steve.
Cheers,
Ronald
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/ | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
