On Tue, Nov 18, 2003 at 02:28:23PM +0100, Stephen McConnell wrote: > > Life is hard, and then you die wrote: [snip] > >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). [snip] > >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 sounds more dynamic than what I had in mind, i.e. more of a run-time than assembly-time resolution. > This is what I've referred to as > finder functionality under earler posts related to the xmlrpc component. Ah, I hadn't noticed the thread "Merlin Lookup versus ECM Lookup" when scouring the archives. However, I couldn't find many details in there - do you have any more info anywhere? > >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. Exactly. > >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). I'm not married to the filter suggestion, and would be interested in how your finder works. Also, if you have any code you think might be useful I'd love to see it. [snip] > >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. I have indeed been in the code, and am slowly starting to get an idea of how/where the filter would best be implemented. But like I said, if your finder stuff solves the problem too, then I'd be happy with that. > One question - concerning selection creitera - what sort of rules were > you thinking of - and were you considering regular expressions? I presume you're talking about the selection of components by the filter, and not the selection of the dependency-directive (containing the filter statement) itself? For the latter I was assuming the current direct key match, but the former would be up to the particular filter implementation - it should be easy to code that one up. Honestly, I'm fairly new to the whole avalon stuff in general and to merlin in particular, so I may well be overlooking various interesting scenarios, and am therefore doubly glad for any pointers/hints/suggestions. Cheers, Ronald --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
