Mailing-List: contact turbine-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Turbine Users List" <turbine-user@jakarta.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v734)
In-Reply-To: <434AA429.8030807@it20one.at>
References: <434AA429.8030807@it20one.at>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <53CF03B2-A885-4C7D-B8C1-04BD8E105D66@upstate.com>
Content-Transfer-Encoding: 7bit
From: Eric Pugh <epugh@upstate.com>
Subject: Re: How to integrate Turbine with other service frameworks such as
 YAAFI, Fortress, Pico, HiveMind, Spring, you name it ....
Date: Tue, 18 Oct 2005 22:21:24 -0400
To: "Turbine Users List" <turbine-user@jakarta.apache.org>

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