Sigi,

I think that is exactly what we are talking about.  I've wanted to be able
to have some sort of object using the Composite pattern where we would just
merge together lots of different types of ServiceManagers.  I pretty much
see them implementing two methods:
public Object lookup(Object key)
public void release(Object object)
public boolean has(Object key)


And pretty much the semantics would be the first one return true to the
has() call would return it.  This to me is a very Turbine specific chunk of
code, so if you get motivated (and I hope you do) lets apply it to o.a.t*
tree.

Henning,
I agree with the static lookups for Fulcrum components.  I think they are a
*smell* as well that was left over from olden times.  I'll go through and
clear them out before calling for a vote.  In many ways *how* you lookup
components is VERY implementation/project specific.

Eric

> -----Original Message-----
> From: Siegfried Goeschl [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 05, 2004 3:16 PM
> To: Turbine Developers List
> Subject: Re: cvs commit:
> jakarta-turbine-fulcrum/mimetype/api/src/java/org/apache/fulcrum/mimetyp
> e MimeTypeServiceFacade.java
>
>
> Hi Henning,
>
> not sure about understanding it correctly but I thought about
> implementing such a thingie a while ago ...
>
> +) lookup a service component in the container, let's say Turbine
> +) if the service component is not found lookup services implementing
> org.apache.avalon.framework.service.ServiceManager (ECM and Merlin)
> +) invoke ServiceManager.hasService() and ServiceManager.lookup() on
> this/these service(s)
>
> this allows looking up services no matter where they are instantiated as
> long as a unique service name is used.
>
> Cheers,
>
> Siegfried Goeschl
>
>
> Henning P. Schmiedehausen wrote:
>
> >"Eric Pugh" <[EMAIL PROTECTED]> writes:
> >
> >Well, we do already have such a method in Turbine:
> >
> >o.a.t.services.ServiceManager::getService(String serviceName)
> >
> >Currently, an implementation of the ServiceManager is retrieved
> by calling
> >TurbineServices.getInstance(). This returns the old service broker.
> >
> >The _cool_ thing here would be to return a service manager, that is
> >able to retrieve the Service from the configured container _and_ the
> >old services system. This would make transition from old/bundled
> >services to Avalon really smooth.
> >
> >For the moment (we are still at milestone level) we can
> >experiment. Getting an "Avalon only" implementation of the
> >ServiceManager interface would IMHO be the way to go. In the end, we
> >can make the whole services system pluggable.
> >
> >     Regards
> >             Henning
> >
> >
> >
> >>I thought about this, and cursed myself as I added it.   The
> reason I added
> >>it was I was happily trying to test the latest -dev version of
> >>fulcrum-mimetype by adding it to Scarab, which was using the old stratum
> >>based version.
> >>
> >>
> >
> >
> >
> >>So, as I added things in, I realized that Scarab every was using a
> >>TurbineMimetypeService, which was a static facade.  And I thought, okay,
> >>instead of looking up the component, I'll just do what
> fulcrum-upload has,
> >>and use a facade.  So I added this.  But, since I didn't like it, I just
> >>gave it a getService() method to highlight that this is just a helper.
> >>Still, icky.
> >>
> >>
> >
> >
> >
> >>My problem with getting directly the component from the servicebroker is
> >>that I am always loading from different containers.  One
> container in unit
> >>testing, another in running as a webapp.
> >>
> >>
> >
> >
> >
> >>One way I worked around this was to add a static ComponentLocator to my
> >>project that was custom to what I needed.
> >>
> >>
> >
> >
> >
> >>So I would do:
> >>ComponentLocator.getMimeTypeService()
> >>
> >>
> >
> >
> >
> >>and that would do the lookup.  If I needed to load up a mock version of
> >>MimeTypeService, well, ComponentLocator has a setMimeTypeService that I
> >>could use, and ComponentLocator.mimeTypeService was a private static
> >>variable...
> >>
> >>
> >
> >
> >
> >>I am now thinking that this is the way I should have gone for Scarab.
> >>Replace all these facades in scarab with a call to
> >>ComponentLocator.getSomeService() that actually would do the lookup if
> >>required and return it..
> >>
> >>
> >
> >
> >
> >>If I do this route, then maybe the other facade guys should be gutted or
> >>removed from Fulcrum?  So, in Turbine, we might have a
> >>TurbineCompoenntLocator static class that we use for all the
> services (like
> >>pool, factory, etc) that turbine needs....
> >>
> >>
> >
> >
> >
> >>What are your opinions?
> >>
> >>
> >
> >
> >
> >>Eric
> >>
> >>
> >
> >
> >
> >>>-----Original Message-----
> >>>From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED]
> >>>Sent: Friday, November 05, 2004 9:06 AM
> >>>To: [EMAIL PROTECTED]
> >>>Subject: Re: cvs commit:
> >>>jakarta-turbine-fulcrum/mimetype/api/src/java/org/apache/fulcru
> m/mimetyp
> >>>e MimeTypeServiceFacade.java
> >>>
> >>>
> >>>[EMAIL PROTECTED] writes:
> >>>
> >>>
> >>>
> >>>> Log:
> >>>> Add a facade helper class
> >>>>
> >>>>
> >>>Personally, I consider the addition of the static facades to the
> >>>Turbine services (yes, I am very guilty of my share) one of the bigger
> >>>mistakes of Turbine.
> >>>
> >>>Is it so hard to get a Service reference from the container?
> >>>
> >>>
> >>>
> >>>> +
> >>>> +    /**
> >>>> +     * Avalon component lifecycle method
> >>>> +     */
> >>>> +    public void service( ServiceManager manager) {
> >>>> +
> >>>> +        MimeTypeServiceFacade.setMimeTypeService(this);
> >>>> +
> >>>> +    }
> >>>>
> >>>>
> >>>Uh; while this looks IoC style, it connects the implementation to the
> >>>facade which is IIRC a violation of the facade pattern (where it
> >>>should be the other way around). And users are in for really nasty
> >>>surprises if their Service implementation forgets to to this setting.
> >>>
> >>>(And while I'm already at it: a "setService()" setter would match the
> >>>getService() getter... :-) )
> >>>
> >>>   Regards
> >>>           Henning
> >>>
> >>>--
> >>>Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
> >>>[EMAIL PROTECTED]        +49 9131 50 654 0   http://www.intermeta.de/
> >>>
> >>>RedHat Certified Engineer -- Jakarta Turbine Development  --
> hero for hire
> >>>   Linux, Java, perl, Solaris -- Consulting, Training, Development
> >>>
> >>>What is more important to you...
> >>>   [ ] Product Security
> >>>or [ ] Quality of Sales and Marketing Support
> >>>              -- actual question from a Microsoft customer survey
> >>>
> >>>---------------------------------------------------------------------
> >>>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]
> >>
> >>
> >
> >
> >
>
>
> --
> Siegfried Goeschl
>
> IT20one GmbH
> Bandgasse 2/22
> 1070 Wien
>
>
>
>
> ---------------------------------------------------------------------
> 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]

Reply via email to