Re: How to integrate Turbine with other service frameworks such as YAAFI, Fortress, Pico, HiveMind, Spring, you name it ....

[Siegfried Goeschl <si...@it20one.at>]

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: 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
>
>


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