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/fulcrum/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]
