Eric Pugh wrote:
I am looking at code that Stephen worked over from Fulcrum. In the past we always had on the API a ROLE. So, like this:
/** Avalon role - used to id the component within the manager */ String ROLE = Config.class.getName();
Confession - I have never liked the ROLE notion. It simply does not make
sense to me. Other Avalon guys disagree with me on the grounds that ROLE
can be changed to be something other than class.getName() and that this
is somehow benefitial.
Is ROLE purely there for use in ECM/Fortress containers? Because in the Merlin testcase, instead of a lookup using ROLE, we use:
config = (Config) this.resolve( "conf" );
This is different. The abstract testcase has an embedded container within it. As such it has access to the appliance managing the component type. To do someting like the lookup of a component by interface name can be done in the abstruct unit test code (and I'm lazy so I just using the existing facilities on block to pull in a component ny name).
However, getting a component relative to a service is something we need to provide where a component is acting as a component and container (whic is the case in the xmlrpc component). Towards that end I'm been doing so refactoring of the block implementation to make it easier to provide different styles of blocks:
* compositional (the current approach) * factory * finder
In the xmlrpc case and in the unit test case the finder style is the most appropriate.
Because we defined this: <component name="conf" class="org.apache.fulcrum.configuration.DefaultConfigurationService"/>
We could have resolved it as FooBAR if we did this:
<component name="FooBAR" class="org.apache.fulcrum.configuration.DefaultConfigurationService"/>
So, should we just leave ROLE on for old users? This code really hasn't been 1.0 released yet, so I would rather ditch anything old. After all you can look up in your code by anything, not just ROLE in ECM..
In the case of the conf sub-project I would dump the entire API. But this gets back to the question - is it actually needed if you run the compoent in ECM or Fortress - I don't know! Berin?
My other question is that in the block.xml we have: <services> <service type="org.apache.fulcrum.configuration.Config"> <source>config</source> </service> </services>
Now, the only reason to have that is to declare that we export this
"service" so that others can use it without writing their own block.xml,
correct?
Yep.
So, as long as you lookup 'config/conf' you get back the right object. So I can, in my code do either of these calls:
config = (Config) this.resolve( "conf" );
or
config = (Config) this.resolve( "config/conf" );
Yes - but only if you code is container-side code.
I just don't quite understand why I could do "conf" versus "config/conf", is it because my default container was already called "config"?
Because the container established by the test case is is named as whatever the name of the block is named. In the stuff I did I typically named the containers with the same name as the project. Secondly, the unit test sets the default block for resolution of names to be the block that was loader to hold the test compoenents - that's just a convinience factor. What actually happens when you do a "/config/conf" is that the request is forwarded to the root container which forwards the request to the child config container which resolved the conf component.
Stephen.
Eric Pugh
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
