You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Dan Murphy <dm...@googlemail.com> on 2007/03/05 15:42:42 UTC
ITest & multiple composites
Hi,
Is there anything planned for iTest to allow one to deploy multiple
composites in the same domain?
As I understand it, currently there is onlya setApplicationSCDL in the
SCATestCase, so whilst I could deploy nested composites, I can't deploy
muliple composites easily to test inter composite commuication.
Anyone working on this ?
Cheers,
Dan
Classloader isloation, was: ITest & multiple composites
Posted by Jeremy Boynes <jb...@apache.org>.
On Mar 6, 2007, at 2:10 AM, Dan Murphy wrote:
> probably due to my j2ee experiences... I was wondering how / if the
> runtime
> would react to different versions of the same component/composite,
> but I'm
> sure we have some for of classloader isolation that would handle
> this...
In 1.x we associated classloaders with composites and the classloader
hierarchy matched the composition tree. Users could add to the
classpath for each composite classloader using <dependency> elements
in the SCDL. There were problems sharing classes between the runtime
and application (e.g. SDO or Spring framework classes).
In 2.x we want to support sparse component trees and so are
decoupling the classloader hierarchy from the composition hierarchy.
ClassLoaders will simply be resources that get created in a physical
runtime and referenced by component containers.
> just use to the j2ee way and had assumed (due to launcher's command
> line
> arguments) that composites needed to be packaged (in a jar or
> similar) so
> that they could be contributed to the domain - obviously got that
> wrong :)
That made sense in 1.x. For 2.0-alpha we wanted to move to a model
where the launcher was given a component to launch (of the "launched"
implmentation type) and would resolve the resources from the domain
(i.e. based on contributed classes). There's still work to be done on
the ContributionService to support that so for now we're still basing
it on the jar. That should change for alpha2.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: ITest & multiple composites
Posted by Dan Murphy <dm...@googlemail.com>.
probably due to my j2ee experiences... I was wondering how / if the runtime
would react to different versions of the same component/composite, but I'm
sure we have some for of classloader isolation that would handle this...
just use to the j2ee way and had assumed (due to launcher's command line
arguments) that composites needed to be packaged (in a jar or similar) so
that they could be contributed to the domain - obviously got that wrong :)
Cheers,
Dan
On 05/03/07, Jeremy Boynes <jb...@apache.org> wrote:
>
> On Mar 5, 2007, at 2:10 PM, Dan Murphy wrote:
>
> >>
> >> There may be some confusion here over "deploy." In SCA you don't
> >> "deploy" applications in the traditional sense - you contribute
> >> implementations to a domain and then assemble component hierarchies
> >> from them.
> >
> >
> > Interesting, I appreciated that there was no deploy (ala J2EE) but had
> > assumed that composites were isolated. I guess I misinterpreted the
> > reasons
> > behind Sebastien's separation to run under different vms...
>
> Not sure what you mean by "isolated" but composites are logical
> groupings (er, compositions :-) ) of components that are orthogonal
> to the physical topology. Unless the composite is specifically marked
> "local" or unless connected by local references, the components in a
> single composite could quite easily be running in different physical
> runtimes. Supporting this core architectural tenet in a federated
> world is one of the changes going on in trunk atm.
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: ITest & multiple composites
Posted by Jeremy Boynes <jb...@apache.org>.
On Mar 5, 2007, at 2:10 PM, Dan Murphy wrote:
>>
>> There may be some confusion here over "deploy." In SCA you don't
>> "deploy" applications in the traditional sense - you contribute
>> implementations to a domain and then assemble component hierarchies
>> from them.
>
>
> Interesting, I appreciated that there was no deploy (ala J2EE) but had
> assumed that composites were isolated. I guess I misinterpreted the
> reasons
> behind Sebastien's separation to run under different vms...
Not sure what you mean by "isolated" but composites are logical
groupings (er, compositions :-) ) of components that are orthogonal
to the physical topology. Unless the composite is specifically marked
"local" or unless connected by local references, the components in a
single composite could quite easily be running in different physical
runtimes. Supporting this core architectural tenet in a federated
world is one of the changes going on in trunk atm.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: ITest & multiple composites
Posted by Dan Murphy <dm...@googlemail.com>.
Hi Jeremy,
Thanks for the clarifications... a few inline one lines responses, but
nothing that really needs an answer :)
WRT the plugin... would be interested in this, but not sure I could commit
to anything at the mo - if things change then I'll post to the list again
Cheers,
Dan
On 05/03/07, Jeremy Boynes <jb...@apache.org> wrote:
>
> On Mar 5, 2007, at 9:08 AM, Dan Murphy wrote:
>
> > Hi Jeremy,
> >
> > I think what you're suggesting is along the lines of the 'whilst I
> > could
> > deploy nested composites' thought (I may have misunderstood you
> > though)...
> > I would have liked to deploy two separate composites as it seemed
> > likely
> > that the code path could be different when using nested composites
> > (which I
> > also planned to do, presuming these would be optimised).... this
> > way I would
> > end up with tests for databindings test for :
> > inter component
> > inter composite (in a nested composite)
> > inter composite (not nested)
> > Does that make sense ?
>
> Not really.
>
> There may be some confusion here over "deploy." In SCA you don't
> "deploy" applications in the traditional sense - you contribute
> implementations to a domain and then assemble component hierarchies
> from them.
Interesting, I appreciated that there was no deploy (ala J2EE) but had
assumed that composites were isolated. I guess I misinterpreted the reasons
behind Sebastien's separation to run under different vms...
The itest plugin is designed for users to test their applications. If
> you want to test the internals of a databinding or how it is
> activated by the fabric, I'd suggest testing that directly. You can
> get much better coverage using the internal SPIs than you can with a
> fairly convoluted multi-vm setup. And that wouldn't involve
> "deploying" anything.
I kept away from the SPIs so that the itests could prove end to end that the
databindings were working as expected. It does mean it will need more tests
and analysis of code coverage etc, but also gave me the chance to get to
grips with SCA better... I guess I'm a bit of a masochist :)
If you look at trunk, we optimize away the implementations of
> composites and just have connections between leaf components so all
> of that would come down to "inter component." There are two forms
> that can take:
> * connection between two components in the same VM
> * binding of component service or reference to a transport
Good news, makes the tests valid for all situations since it'll only need
the one interop suite... had thought I'd end up with one for each of the 3
scenarios.
Each of those only requires a single VM to test.
>
> >
> > Ideally I would like to do the inter composite (not nested) between
> > 2 jvms,
> > Sebastien's did something similar (although in a single JVM) by
> > instantiating a second SCATestCase to deploy additional composites (
> > https://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-
> > java-integration/testing/sca/itest/bindings/bindingsclient/src/test/
> > java/org/apache/tuscany/sca/itest/WSBindingsClientTestCase.java
> > )
> > I was wondering if the there are plans to improve iTest (& plugin if
> > applicable) to facilitate multi-vm / non-nested multiple composite
> > testing.
>
> The itest plugin works by "deploying" a test composite to a local
> domain running inside Maven. With SCA's abstraction of the
> environment from the programming model, that provides quite a lot of
> support for integration testing of a composite.
>
> I think it would be good to support "deployment" to a different
> domain, which really means contributing the composite to a remote
> server through a remote ContributionService - something a bit like
> Cargo would be good to have.
>
> Another improvement would be a mock framework for composites that
> allow the simulation of external references - I've been wondering
> about integrating the itest plugin with EasyMock for that.
>
> Those are both just ideas rather than "plans" - if this is something
> that interests you jump on in.
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: ITest & multiple composites
Posted by Jeremy Boynes <jb...@apache.org>.
On Mar 5, 2007, at 9:08 AM, Dan Murphy wrote:
> Hi Jeremy,
>
> I think what you're suggesting is along the lines of the 'whilst I
> could
> deploy nested composites' thought (I may have misunderstood you
> though)...
> I would have liked to deploy two separate composites as it seemed
> likely
> that the code path could be different when using nested composites
> (which I
> also planned to do, presuming these would be optimised).... this
> way I would
> end up with tests for databindings test for :
> inter component
> inter composite (in a nested composite)
> inter composite (not nested)
> Does that make sense ?
Not really.
There may be some confusion here over "deploy." In SCA you don't
"deploy" applications in the traditional sense - you contribute
implementations to a domain and then assemble component hierarchies
from them.
The itest plugin is designed for users to test their applications. If
you want to test the internals of a databinding or how it is
activated by the fabric, I'd suggest testing that directly. You can
get much better coverage using the internal SPIs than you can with a
fairly convoluted multi-vm setup. And that wouldn't involve
"deploying" anything.
If you look at trunk, we optimize away the implementations of
composites and just have connections between leaf components so all
of that would come down to "inter component." There are two forms
that can take:
* connection between two components in the same VM
* binding of component service or reference to a transport
Each of those only requires a single VM to test.
>
> Ideally I would like to do the inter composite (not nested) between
> 2 jvms,
> Sebastien's did something similar (although in a single JVM) by
> instantiating a second SCATestCase to deploy additional composites (
> https://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-
> java-integration/testing/sca/itest/bindings/bindingsclient/src/test/
> java/org/apache/tuscany/sca/itest/WSBindingsClientTestCase.java
> )
> I was wondering if the there are plans to improve iTest (& plugin if
> applicable) to facilitate multi-vm / non-nested multiple composite
> testing.
The itest plugin works by "deploying" a test composite to a local
domain running inside Maven. With SCA's abstraction of the
environment from the programming model, that provides quite a lot of
support for integration testing of a composite.
I think it would be good to support "deployment" to a different
domain, which really means contributing the composite to a remote
server through a remote ContributionService - something a bit like
Cargo would be good to have.
Another improvement would be a mock framework for composites that
allow the simulation of external references - I've been wondering
about integrating the itest plugin with EasyMock for that.
Those are both just ideas rather than "plans" - if this is something
that interests you jump on in.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: ITest & multiple composites
Posted by Dan Murphy <dm...@googlemail.com>.
Hi Jeremy,
I think what you're suggesting is along the lines of the 'whilst I could
deploy nested composites' thought (I may have misunderstood you though)...
I would have liked to deploy two separate composites as it seemed likely
that the code path could be different when using nested composites (which I
also planned to do, presuming these would be optimised).... this way I would
end up with tests for databindings test for :
inter component
inter composite (in a nested composite)
inter composite (not nested)
Does that make sense ?
Ideally I would like to do the inter composite (not nested) between 2 jvms,
Sebastien's did something similar (although in a single JVM) by
instantiating a second SCATestCase to deploy additional composites (
https://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-integration/testing/sca/itest/bindings/bindingsclient/src/test/java/org/apache/tuscany/sca/itest/WSBindingsClientTestCase.java
)
I was wondering if the there are plans to improve iTest (& plugin if
applicable) to facilitate multi-vm / non-nested multiple composite testing.
Cheers,
Dan
On 05/03/07, Jeremy Boynes <jb...@apache.org> wrote:
>
> I believe the itest plugin already supports this. The harness SCDL
> refers to the test composite that includes/uses the composite-under-
> test and that can in turn include/use nested composites. Classpath
> extension through <dependency> elements can be used to add
> implementation dependencies and inner scdl files can be located using
> scdlResource/scdlLocation attributes.
>
> To just test inter-composite communication you could just have the
> test composite use two other composites as implementations (i.e. two
> components with <implementation.composite>)
>
> HTH
> --
> Jeremy
>
> On Mar 5, 2007, at 6:42 AM, Dan Murphy wrote:
>
> > Hi,
> >
> > Is there anything planned for iTest to allow one to deploy multiple
> > composites in the same domain?
> >
> > As I understand it, currently there is onlya setApplicationSCDL in the
> > SCATestCase, so whilst I could deploy nested composites, I can't
> > deploy
> > muliple composites easily to test inter composite commuication.
> >
> > Anyone working on this ?
> >
> > Cheers,
> > Dan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: ITest & multiple composites
Posted by Jeremy Boynes <jb...@apache.org>.
I believe the itest plugin already supports this. The harness SCDL
refers to the test composite that includes/uses the composite-under-
test and that can in turn include/use nested composites. Classpath
extension through <dependency> elements can be used to add
implementation dependencies and inner scdl files can be located using
scdlResource/scdlLocation attributes.
To just test inter-composite communication you could just have the
test composite use two other composites as implementations (i.e. two
components with <implementation.composite>)
HTH
--
Jeremy
On Mar 5, 2007, at 6:42 AM, Dan Murphy wrote:
> Hi,
>
> Is there anything planned for iTest to allow one to deploy multiple
> composites in the same domain?
>
> As I understand it, currently there is onlya setApplicationSCDL in the
> SCATestCase, so whilst I could deploy nested composites, I can't
> deploy
> muliple composites easily to test inter composite commuication.
>
> Anyone working on this ?
>
> Cheers,
> Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org