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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
