turbine-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Pugh <ep...@upstate.com>
Subject Re: How to integrate Turbine with other service frameworks such as YAAFI, Fortress, Pico, HiveMind, Spring, you name it ....
Date Wed, 19 Oct 2005 02:21:24 GMT
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: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org


Mime
View raw message