Hi Eric,
I committed my source code surgery using the TurbineServiceProvider
approach and all tests are okay - now you can lookup services no matter
in which container they are located.
Cheers,
Siegfried Goeschl
Eric Pugh wrote:
Hi Sigi,
Just made my first Turbine 2.4 commit in a while.. Just updating the
commons-email to 1.0 (yay!).
At any rate, I to lean to #1. Less magic seems to be a good
thing. We've talked about some sort of wrapper that would return a
service from the first IOC container that found it.
If it really is backwards compatible, which I guess it is, then that
sounds great... Just as a question, have we checked if anyone is
dynamically calling methods on a Service? Like to start it up or
anything? If not, then I like #1. Worst came to worse you could
always do an instanceof Service check....
Eric
On Oct 10, 2005, at 1:26 PM, Siegfried Goeschl wrote:
Hi folks,
one of the lesser elegant things to do when migrating existing
Turbine services to Fulcrum components is the fact that you have to
know where you get the service from - we are actually violating the
service location transparency which is not utterly unimportant.
I'm currently working my way through the latest SVN version of
Turbine and I think the following things could work
1) TurbineServiceProvider approach
============================================================
*) changing org.apache.turbine.services.ServiceBroker to return
Object instead of Service
*) define a generic TurbineServiceProvider interfaces exposing
methods to lookup and release services
*) change the existing Turbine service lookup to delegate service
lookups (regarding unknown services) to Turbine services
implementing TurbineServiceProvider interface
+) this would allow transparent service lookup for many IOC
containers to come .... ;-)
+) this approach actually works with Turbine since callers of
Turbine services are usually not casting to Service
+) it is backward compatible for clients casting to the desired
service interface
+) it is rather straightforward to implement
-) it changes the existing ServiceBroker interface and is highly
visible
2) Dynamic Proxy approach
============================================================
It is possible to wrap the interfaces of an arbitrary object into an
dynamic proxy which could also expose the existing Service interface
+) would not change the current interfaces
-) tricky, overengineered and a little bit fragile (btw, we call
that "edelhack" ... awesome but futile in the long run)
-) in the general case the is no meaningful implementation for many
of the Service methods.
IMHO 1) would be the way to go but before I invest too much time I
would like to ask for some opinions out there ... any PMCs alive and
kicking are especially welcome ... :-)
Thanks in advance
Siegfried Goeschl
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
