You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Siegfried Goeschl <si...@it20one.at> on 2005/10/10 19:26:01 UTC
How to integrate Turbine with other service frameworks such as YAAFI,
Fortress, Pico, HiveMind, Spring, you name it ....
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
Re: How to integrate Turbine with other service frameworks such as
YAAFI, Fortress, Pico, HiveMind, Spring, you name it ....
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Eric,
I go than for #1 and see how it works ....
Cheers,
Siegfried Goeschl
PS: I'm glad that you are back again .... :-)
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
Re: How to integrate Turbine with other service frameworks such as
YAAFI, Fortress, Pico, HiveMind, Spring, you name it ....
Posted by 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-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: How to integrate Turbine with other service frameworks such as
YAAFI, Fortress, Pico, HiveMind, Spring, you name it ....
Posted by 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
Re: How to integrate Turbine with other service frameworks such as
YAAFI, Fortress, Pico, HiveMind, Spring, you name it ....
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Eric,
I go than for #1 and see how it works ....
Cheers,
Siegfried Goeschl
PS: I'm glad that you are back again .... :-)
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-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: How to integrate Turbine with other service frameworks such as YAAFI, Fortress, Pico, HiveMind, Spring, you name it ....
Posted by Eric Pugh <ep...@upstate.com>.
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