Stephen (and other Avalon guru's)... I have committed the merlin friendly (merlinized?) version of Configuation. I ditched the api section as commons-configuration really provides that. anyone want to review it and let me know?
http://cvs.apache.org/viewcvs/jakarta-turbine-fulcrum/configuration/ Ignore the configuration/src directory.. gotta figure out what I did.. Thought I deleted it, but apparently not.. Eric > -----Original Message----- > From: Stephen McConnell [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 12, 2003 10:49 AM > To: Avalon Developers List > Subject: Re: Merlin Lookup versus ECM Lookup > > > > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
