You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jeremy Boynes <jb...@apache.org> on 2007/02/16 07:08:45 UTC
Factoring out common calculator composite
I have the new webapp runtime going but ran into an issue with the
structure of the calculator sample. In M2, the web calculator used
the same composite definition as the standalone version - it included
the client classes but that code was never executed. With the 1.0
model, there are specific components that bridge from the unmanaged
to managed environments (tuscany:webapp and tuscany:launched
respectively). The issue comes if we use the simplest form of SCDL
for the calculator composite as it contains a :launched component
that is rejected by the webapp runtime.
I'd like to propose separating the common composite out from the
standalone sample. This would give us 3 modules rather than 2:
* common composite
* standalone client
* webapp client
I think this shows the type of structure we would recommend to users.
An alternative would be to duplicate the implementation code in the
two samples, which makes each one a little simpler but drifts away
from what seems like best practice.
I plan on starting this refactor tomorrow.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Factoring out common calculator composite
Posted by Jeremy Boynes <jb...@apache.org>.
It looks like Meeraj was running into the same issues in standaline
as I was in webapp so I went ahead and did this.
In core-samples:
common/calculator is the common composite (with itests)
standalone/calculator is the standalone client (with unit tests for
the client code)
webapp/webcalc is the webapp version
--
Jeremy
On Feb 16, 2007, at 1:37 AM, Dan Murphy wrote:
> Hi Jeremy,
>
> Makes good sense to me... reuse though component isolation is a
> good thing
> to promote so makes more sense than duplication... also seperates
> better the
> service provider and consumer...
>
> On 16/02/07, Jeremy Boynes <jb...@apache.org> wrote:
>>
>> I have the new webapp runtime going but ran into an issue with the
>> structure of the calculator sample. In M2, the web calculator used
>> the same composite definition as the standalone version - it included
>> the client classes but that code was never executed. With the 1.0
>> model, there are specific components that bridge from the unmanaged
>> to managed environments (tuscany:webapp and tuscany:launched
>> respectively). The issue comes if we use the simplest form of SCDL
>> for the calculator composite as it contains a :launched component
>> that is rejected by the webapp runtime.
>>
>> I'd like to propose separating the common composite out from the
>> standalone sample. This would give us 3 modules rather than 2:
>> * common composite
>> * standalone client
>> * webapp client
>>
>> I think this shows the type of structure we would recommend to users.
>>
>> An alternative would be to duplicate the implementation code in the
>> two samples, which makes each one a little simpler but drifts away
>> from what seems like best practice.
>>
>> I plan on starting this refactor tomorrow.
>> --
>> Jeremy
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Factoring out common calculator composite
Posted by Dan Murphy <dm...@googlemail.com>.
Hi Jeremy,
Makes good sense to me... reuse though component isolation is a good thing
to promote so makes more sense than duplication... also seperates better the
service provider and consumer...
On 16/02/07, Jeremy Boynes <jb...@apache.org> wrote:
>
> I have the new webapp runtime going but ran into an issue with the
> structure of the calculator sample. In M2, the web calculator used
> the same composite definition as the standalone version - it included
> the client classes but that code was never executed. With the 1.0
> model, there are specific components that bridge from the unmanaged
> to managed environments (tuscany:webapp and tuscany:launched
> respectively). The issue comes if we use the simplest form of SCDL
> for the calculator composite as it contains a :launched component
> that is rejected by the webapp runtime.
>
> I'd like to propose separating the common composite out from the
> standalone sample. This would give us 3 modules rather than 2:
> * common composite
> * standalone client
> * webapp client
>
> I think this shows the type of structure we would recommend to users.
>
> An alternative would be to duplicate the implementation code in the
> two samples, which makes each one a little simpler but drifts away
> from what seems like best practice.
>
> I plan on starting this refactor tomorrow.
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>