You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Eric Pugh <ep...@upstate.com> on 2003/11/12 10:21:57 UTC
Merlin Lookup versus ECM Lookup
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();
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" );
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..
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? 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" );
I just don't quite understand why I could do "conf" versus "config/conf", is
it because my default container was already called "config"?
Eric Pugh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Merlin Lookup versus ECM Lookup
Posted by Eric Pugh <ep...@upstate.com>.
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:mcconnell@apache.org]
> 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: dev-unsubscribe@avalon.apache.org
> >For additional commands, e-mail: dev-help@avalon.apache.org
> >
> >
> >
> >
>
> --
>
> Stephen J. McConnell
> mailto:mcconnell@apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Merlin Lookup versus ECM Lookup
Posted by Stephen McConnell <mc...@apache.org>.
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: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org