You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jim Marino <jm...@myromatours.com> on 2007/02/11 08:54:54 UTC
Runtime bring-up and next steps
I've finished the final piece to bringing up the base standalone
runtime which Jeremy has been working on to support the SCA 1.0
client APIs. This mostly involved externalizing autowire from
CompositeComponent to an AutowireResolver which is called after the
model is loaded. This had the side-effect of simplifying the runtime
as the connector no longer needs to deal with the autowire case
(autowires will resolve to absolute URIs).
I have also removed the process for connecting artifacts from
CompositeComponent to Deployer.
Below are a few more changes I plan to work on over the next few days:
- I plan to continue refactoring Component to simplify and cleanup
the interface. This will hopefully result in little difference
between atomic and composite components.
- I would like to eliminate the need for outbound and inbound wires,
having the connector create a single Wire which is attached to a
source. In this scenario, targets will not have wires but will
continue to supply TargetInvokers to sources. This will tie in
directly with Meeraj's work on the physical component builders and
wire reconstitution on slaves. It will also further serve to simplify
the connect phase. As we do this, we will need to revisit the SPI for
WirePostProcessors. Following on Meeraj's physical builder work,
policy and wire processing will need to be done on the master against
the model and a portable representation of the wire sent to slaves
where it will be constituted. We will need something akin to an
InterceptorBuilder which will be responsible for helping to
constitute a wire on the slave by supplying interceptors. Thoughts?
- Integrate the autowire changes with Meeraj's federation work which
will give us support for federated/distributed autowire across an SCA
Domain (as well as supporting more of the SCA autowire semantics).
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Runtime bring-up and next steps
Posted by Jim Marino <jm...@myromatours.com>.
On Feb 14, 2007, at 7:59 AM, Ignacio Silva-Lepe wrote:
> Hmm, my questions are simpler than I may have made them sound. From
> your original post, you say that you want to eliminate outbound and
> inbound wires and replace/merge them by/into a single wire attached
> to the
> source.
> Before the merge we used to have, from the perspective of a
> component C,
> an inbound wire per service it exposed and an outbound wire per
> reference
> it used. Each inbound wire had a set of inbound chains (one per opera-
> tion in the forward direction) and a number of callback outbound
> chain sets
> (one set per source component, and each group with one chain per
> callback
> operation). Similarly, each outbound wire had a set of outbound
> chains and
> a set of inbound chains.
> If a single wire is going to merge it all, are both sets of inbound
> chains
> and
> all sets of outbound chains going to be preserved? If not, what's
> the new
> structure that is going to be in place and how does it preserve the
> pre-exis-
> ting behavior?
> Like I said, this may be common knowledge and I may just have
> missed the
> explanation, in which case would someone point me to it?
>
Sorry, maybe I didn't explain clearly enough in previous posts. Both
sets of chains will be preserved. Source components will contain the
wires to a target and targets will no longer have incoming wires. The
Allocator on the master will build up a WireDefinition which will be
marshalled to a slave. The WireDefinition will contain a set of
InterceptorDefinitions which InterceptorBuilders will use to
constitute a Wire. The WireDefinition will also contain source and
target URIs. Hence, the Wire will contain both forward and callback
invocation chains. This will mean the Connector can change to the
following:
public interface Connector {
void connect(WireDefinition wd) throws WiringException;
}
As the Connector has a reference to a ComponentManager, it will be be
able to look up source and target, dispatch to InterceptorBuilders
based on a QName, build forward and callback chains for the wire, and
attach the wire to the source. Meeraj has already checked in
WireDefinition as well as posted on the marshalling format, so it may
be worth checking that out.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Runtime bring-up and next steps
Posted by Ignacio Silva-Lepe <is...@gmail.com>.
Hmm, my questions are simpler than I may have made them sound. From
your original post, you say that you want to eliminate outbound and
inbound wires and replace/merge them by/into a single wire attached to the
source.
Before the merge we used to have, from the perspective of a component C,
an inbound wire per service it exposed and an outbound wire per reference
it used. Each inbound wire had a set of inbound chains (one per opera-
tion in the forward direction) and a number of callback outbound chain sets
(one set per source component, and each group with one chain per callback
operation). Similarly, each outbound wire had a set of outbound chains and
a set of inbound chains.
If a single wire is going to merge it all, are both sets of inbound chains
and
all sets of outbound chains going to be preserved? If not, what's the new
structure that is going to be in place and how does it preserve the
pre-exis-
ting behavior?
Like I said, this may be common knowledge and I may just have missed the
explanation, in which case would someone point me to it?
On 2/12/07, Jim Marino <jm...@myromatours.com> wrote:
>
> >> I see two cases, managed and non-managed code. In the former, where
> >> the source is a component, there would be one set of chains (no
> >> distinction between inbound and outbound) attached to the source
> >> component. For non-managed code, it would be pretty much the same
> >> thing with the chains held in the proxy or CallableReference.
> >
> >
> > Apologies if this has been explained previously and is now common
> > knowledge (if so, could you point me at the explanation?).
> We've always had concepts of managed vs. non-managed code. The
> problem is the specs never made the distinction very well and
> confused the two in places. One of the main goals of the recent spec
> changes was to clarify this (hence the reintroduction of things like
> ComponentContext). The code is now in the 1.0 spec module but Jeremy
> also posted to the wiki on this. I'm not sure, though, if you are
> referring to this.
> > So is the idea that each chain has interceptors (say, databinding and
> > security) that are used for both incoming and outgoing messages? Is
> > there going to be a way to indicate to an interceptor which way is in
> > effect?
> I'm not following and probably missing something. I don't think this
> is any different than what we have today. There would be forward and
> callback chains associated with a Wire. If the interceptor needs to
> know if the invocation is a forward or callback invocation, it would
> be the job of the interceptor "builder" on the slave to provide it
> with that information (or have the builder instantiate different
> interceptors). There is a mail thread on interceptor builders from
> last week which covers the format for serializing a portable wire
> definition from master to slave. The idea is the definition would be
> created on the master and sent to the slave where interceptor
> builders would be responsible for creating interceptors according to
> some extensible wire definition information.
>
> > And would there be a way to indicate the order in each
> > direction? Maybe making the chain a doubly-linked list?
> >
> Could you explain a little further? I think the chain is exactly how
> we have it today except it is one as opposed to two chains for each
> direction.
>
> >
> >>
> >> A --------------\
> >> |-----------------C
> >> B --------------/
> >>
> >> I'm proposing we do the following:
> >>
> >> A ---------------
> >> C
> >> B ---------------
> >>
> >> In the approach connections would be:
> >>
> >> 1. Between components
> >> 2. From a transport to a component
> >> 3. From a component to a transport
> >> 4. From a transport to a transport
> >
> >
> > When you say transport, do you mean a composite reference and/or
> > service implementation for a given binding?
> I think of transport as what a binding provides a "link" to (not a
> composite reference or service since they may have multiple bindings).
> > Even with a single hop, a callback invocation handler at C would still
> > need to be able to choose between A and B depending on where the
> > forward call came from. How do you see it referring to the correspon-
> > ding wire when it needs to make the callback?
> It would be retrieved from the context, basically how it is today. We
> need to be careful here, though, about dealing with context cleanup
> on threads.
>
> Jim
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Runtime bring-up and next steps
Posted by Jim Marino <jm...@myromatours.com>.
>> I see two cases, managed and non-managed code. In the former, where
>> the source is a component, there would be one set of chains (no
>> distinction between inbound and outbound) attached to the source
>> component. For non-managed code, it would be pretty much the same
>> thing with the chains held in the proxy or CallableReference.
>
>
> Apologies if this has been explained previously and is now common
> knowledge (if so, could you point me at the explanation?).
We've always had concepts of managed vs. non-managed code. The
problem is the specs never made the distinction very well and
confused the two in places. One of the main goals of the recent spec
changes was to clarify this (hence the reintroduction of things like
ComponentContext). The code is now in the 1.0 spec module but Jeremy
also posted to the wiki on this. I'm not sure, though, if you are
referring to this.
> So is the idea that each chain has interceptors (say, databinding and
> security) that are used for both incoming and outgoing messages? Is
> there going to be a way to indicate to an interceptor which way is in
> effect?
I'm not following and probably missing something. I don't think this
is any different than what we have today. There would be forward and
callback chains associated with a Wire. If the interceptor needs to
know if the invocation is a forward or callback invocation, it would
be the job of the interceptor "builder" on the slave to provide it
with that information (or have the builder instantiate different
interceptors). There is a mail thread on interceptor builders from
last week which covers the format for serializing a portable wire
definition from master to slave. The idea is the definition would be
created on the master and sent to the slave where interceptor
builders would be responsible for creating interceptors according to
some extensible wire definition information.
> And would there be a way to indicate the order in each
> direction? Maybe making the chain a doubly-linked list?
>
Could you explain a little further? I think the chain is exactly how
we have it today except it is one as opposed to two chains for each
direction.
>
>>
>> A --------------\
>> |-----------------C
>> B --------------/
>>
>> I'm proposing we do the following:
>>
>> A ---------------
>> C
>> B ---------------
>>
>> In the approach connections would be:
>>
>> 1. Between components
>> 2. From a transport to a component
>> 3. From a component to a transport
>> 4. From a transport to a transport
>
>
> When you say transport, do you mean a composite reference and/or
> service implementation for a given binding?
I think of transport as what a binding provides a "link" to (not a
composite reference or service since they may have multiple bindings).
> Even with a single hop, a callback invocation handler at C would still
> need to be able to choose between A and B depending on where the
> forward call came from. How do you see it referring to the correspon-
> ding wire when it needs to make the callback?
It would be retrieved from the context, basically how it is today. We
need to be careful here, though, about dealing with context cleanup
on threads.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Runtime bring-up and next steps
Posted by Ignacio Silva-Lepe <is...@gmail.com>.
Hi Jim,
More comments/questions inline.
On 2/12/07, Jim Marino <jm...@myromatours.com> wrote:
>
> Hi Ignacio,
>
> Comments inline.
>
> Jim
>
> >> - I would like to eliminate the need for outbound and inbound wires,
> >> having the connector create a single Wire which is attached to a
> >> source. In this scenario, targets will not have wires but will
> >> continue to supply TargetInvokers to sources. This will tie in
> >> directly with Meeraj's work on the physical component builders and
> >> wire reconstitution on slaves. It will also further serve to simplify
> >> the connect phase. As we do this, we will need to revisit the SPI for
> >> WirePostProcessors. Following on Meeraj's physical builder work,
> >> policy and wire processing will need to be done on the master against
> >> the model and a portable representation of the wire sent to slaves
> >> where it will be constituted. We will need something akin to an
> >> InterceptorBuilder which will be responsible for helping to
> >> constitute a wire on the slave by supplying interceptors. Thoughts?
> >
> >
> > Not sure what the intended approach is here. I would think that
> > inbound
> > chains for targets would still be needed, where would those live
> > now, in
> > the single wire at the source?
> I see two cases, managed and non-managed code. In the former, where
> the source is a component, there would be one set of chains (no
> distinction between inbound and outbound) attached to the source
> component. For non-managed code, it would be pretty much the same
> thing with the chains held in the proxy or CallableReference.
Apologies if this has been explained previously and is now common
knowledge (if so, could you point me at the explanation?).
So is the idea that each chain has interceptors (say, databinding and
security) that are used for both incoming and outgoing messages? Is
there going to be a way to indicate to an interceptor which way is in
effect? And would there be a way to indicate the order in each
direction? Maybe making the chain a doubly-linked list?
This should simplify the connector a bit more and allow us to fit in
> with the master allocation process described by Meeraj. For example,
> a WireDefinition will be marshalled to a slave node where it will be
> reconstituted.
>
> > Would that also preserve the bridging
> > interceptors at the source wire?
> We would just need the non-blocking variant. There would be no need
> for the synchronous form. If a wire changes, the assembly will be
> mutated on the master and a diff (probably of just the wire) sent to
> the slave.
>
> > Perhaps I am not understanding, but at some point we used to have a
> > similar approach where (at least some of) the chains were co-located
> > in a single wire, but that had to be undone to allow multiple sets of
> > callback source chains at an inbound wire. Could you elaborate on
> > how this would work with a single wire?
>
> I think I'm proposing something different to what we had before,
> essentially collapsing the distinction between inbound and outbound
> wires. For example, what we currently have is:
>
> A --------------\
> |-----------------C
> B --------------/
>
> I'm proposing we do the following:
>
> A ---------------
> C
> B ---------------
>
> In the approach connections would be:
>
> 1. Between components
> 2. From a transport to a component
> 3. From a component to a transport
> 4. From a transport to a transport
When you say transport, do you mean a composite reference and/or
service implementation for a given binding?
Even with a single hop, a callback invocation handler at C would still
need to be able to choose between A and B depending on where the
forward call came from. How do you see it referring to the correspon-
ding wire when it needs to make the callback?
We won't need to have multiple hop wires with the "local" binding
> anymore (e.g. component-->reference-->service-->component) since they
> can be optimized as point-to-point communications (e.g. component--
> >component) on the master. The connector would be responsible for
> just creating wires, populating it with interceptors, and obtaining a
> target invoker from the target.
>
> Callback wires would just be associated on the source side and set as
> context as it is today.
>
> Jim
>
> This is not that much different from what we have today in that we
> are collapsing OutboundWire and InboundWire. Callback
> >
> > - Integrate the autowire changes with Meeraj's federation work which
> >> will give us support for federated/distributed autowire across an SCA
> >> Domain (as well as supporting more of the SCA autowire semantics).
> >>
> >> Jim
> >>
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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: Runtime bring-up and next steps
Posted by Jim Marino <jm...@myromatours.com>.
Hi Ignacio,
Comments inline.
Jim
>> - I would like to eliminate the need for outbound and inbound wires,
>> having the connector create a single Wire which is attached to a
>> source. In this scenario, targets will not have wires but will
>> continue to supply TargetInvokers to sources. This will tie in
>> directly with Meeraj's work on the physical component builders and
>> wire reconstitution on slaves. It will also further serve to simplify
>> the connect phase. As we do this, we will need to revisit the SPI for
>> WirePostProcessors. Following on Meeraj's physical builder work,
>> policy and wire processing will need to be done on the master against
>> the model and a portable representation of the wire sent to slaves
>> where it will be constituted. We will need something akin to an
>> InterceptorBuilder which will be responsible for helping to
>> constitute a wire on the slave by supplying interceptors. Thoughts?
>
>
> Not sure what the intended approach is here. I would think that
> inbound
> chains for targets would still be needed, where would those live
> now, in
> the single wire at the source?
I see two cases, managed and non-managed code. In the former, where
the source is a component, there would be one set of chains (no
distinction between inbound and outbound) attached to the source
component. For non-managed code, it would be pretty much the same
thing with the chains held in the proxy or CallableReference.
This should simplify the connector a bit more and allow us to fit in
with the master allocation process described by Meeraj. For example,
a WireDefinition will be marshalled to a slave node where it will be
reconstituted.
> Would that also preserve the bridging
> interceptors at the source wire?
We would just need the non-blocking variant. There would be no need
for the synchronous form. If a wire changes, the assembly will be
mutated on the master and a diff (probably of just the wire) sent to
the slave.
> Perhaps I am not understanding, but at some point we used to have a
> similar approach where (at least some of) the chains were co-located
> in a single wire, but that had to be undone to allow multiple sets of
> callback source chains at an inbound wire. Could you elaborate on
> how this would work with a single wire?
I think I'm proposing something different to what we had before,
essentially collapsing the distinction between inbound and outbound
wires. For example, what we currently have is:
A --------------\
|-----------------C
B --------------/
I'm proposing we do the following:
A ---------------
C
B ---------------
In the approach connections would be:
1. Between components
2. From a transport to a component
3. From a component to a transport
4. From a transport to a transport
We won't need to have multiple hop wires with the "local" binding
anymore (e.g. component-->reference-->service-->component) since they
can be optimized as point-to-point communications (e.g. component--
>component) on the master. The connector would be responsible for
just creating wires, populating it with interceptors, and obtaining a
target invoker from the target.
Callback wires would just be associated on the source side and set as
context as it is today.
Jim
This is not that much different from what we have today in that we
are collapsing OutboundWire and InboundWire. Callback
>
> - Integrate the autowire changes with Meeraj's federation work which
>> will give us support for federated/distributed autowire across an SCA
>> Domain (as well as supporting more of the SCA autowire semantics).
>>
>> Jim
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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: Runtime bring-up and next steps
Posted by Ignacio Silva-Lepe <is...@gmail.com>.
Hi Jim,
Comments inline.
On 2/11/07, Jim Marino <jm...@myromatours.com> wrote:
>
> I've finished the final piece to bringing up the base standalone
> runtime which Jeremy has been working on to support the SCA 1.0
> client APIs. This mostly involved externalizing autowire from
> CompositeComponent to an AutowireResolver which is called after the
> model is loaded. This had the side-effect of simplifying the runtime
> as the connector no longer needs to deal with the autowire case
> (autowires will resolve to absolute URIs).
>
> I have also removed the process for connecting artifacts from
> CompositeComponent to Deployer.
>
> Below are a few more changes I plan to work on over the next few days:
>
> - I plan to continue refactoring Component to simplify and cleanup
> the interface. This will hopefully result in little difference
> between atomic and composite components.
>
> - I would like to eliminate the need for outbound and inbound wires,
> having the connector create a single Wire which is attached to a
> source. In this scenario, targets will not have wires but will
> continue to supply TargetInvokers to sources. This will tie in
> directly with Meeraj's work on the physical component builders and
> wire reconstitution on slaves. It will also further serve to simplify
> the connect phase. As we do this, we will need to revisit the SPI for
> WirePostProcessors. Following on Meeraj's physical builder work,
> policy and wire processing will need to be done on the master against
> the model and a portable representation of the wire sent to slaves
> where it will be constituted. We will need something akin to an
> InterceptorBuilder which will be responsible for helping to
> constitute a wire on the slave by supplying interceptors. Thoughts?
Not sure what the intended approach is here. I would think that inbound
chains for targets would still be needed, where would those live now, in
the single wire at the source? Would that also preserve the bridging
interceptors at the source wire?
Perhaps I am not understanding, but at some point we used to have a
similar approach where (at least some of) the chains were co-located
in a single wire, but that had to be undone to allow multiple sets of
callback source chains at an inbound wire. Could you elaborate on
how this would work with a single wire?
- Integrate the autowire changes with Meeraj's federation work which
> will give us support for federated/distributed autowire across an SCA
> Domain (as well as supporting more of the SCA autowire semantics).
>
> Jim
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Runtime bring-up and next steps
Posted by Jim Marino <jm...@myromatours.com>.
> FWIW and IIRC, 1.0 supports autowire for composites so adding
> @autowire="true" on the composite should be enough to remove all
> the reference definitions. I don't think that's implemented yet
> though.
>
I plan to get on that ASAP. With the autowire move to the resolver,
it should be easy to implement.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Runtime bring-up and next steps
Posted by Jeremy Boynes <jb...@apache.org>.
On Feb 12, 2007, at 12:18 PM, Raymond Feng wrote:
> Hi,
>
> In the latest calculator sample, it demonstrates the usage of itest
> where we define a harness composite as follows:
>
> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
> xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0"
> name="CalculatorTestHarnessComposite">
> <include name="CalculatorComposite" scdlResource="META-INF/sca/
> default.scdl"/>
> <component name="testComponent">
> <tuscany:junit class="calculator.CalculatorTestComponent"/>
> <reference
> name="calculatorService">CalculatorServiceComponent</reference>
> </component>
> </composite>
>
> I think we might be able to further simplify this by introspecting
> the test cases to create such a harness composite. For example, we
> can create a Junit component if the base class is
> org.junit.TestCase and use autowire to resolve the references to
> the services being tested. Does it make sense?
Something like that, yep. We would need to distinguish unit tests
from integration ones (which test plugins like surefire do through
name patterns), and there's a question if the main composite should
be <include>d or used as an implementation. But the less the user has
to do the better.
--
Jeremy
FWIW and IIRC, 1.0 supports autowire for composites so adding
@autowire="true" on the composite should be enough to remove all the
reference definitions. I don't think that's implemented yet though.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Runtime bring-up and next steps
Posted by Raymond Feng <en...@gmail.com>.
Hi,
In the latest calculator sample, it demonstrates the usage of itest where we
define a harness composite as follows:
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0"
name="CalculatorTestHarnessComposite">
<include name="CalculatorComposite"
scdlResource="META-INF/sca/default.scdl"/>
<component name="testComponent">
<tuscany:junit class="calculator.CalculatorTestComponent"/>
<reference
name="calculatorService">CalculatorServiceComponent</reference>
</component>
</composite>
I think we might be able to further simplify this by introspecting the test
cases to create such a harness composite. For example, we can create a Junit
component if the base class is org.junit.TestCase and use autowire to
resolve the references to the services being tested. Does it make sense?
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@ws.apache.org>
Sent: Monday, February 12, 2007 10:40 AM
Subject: Re: Runtime bring-up and next steps
> On Feb 12, 2007, at 9:46 AM, Jim Marino wrote:
>
>> On Feb 12, 2007, at 8:01 AM, haleh mahbod wrote:
>>> Does bring up of runtime include a successful run of iTest?
>>>
>> I was specifically referring to the standalone runtime but it appears
>> Jeremy also has the itest plugin working with the really neat ability to
>> run a JUnit test as a component. This looks like a big improvement over
>> the old SCATestCase, particularly since it is closer to the 1.0 APIs (we
>> discussed doing this a while back). I'll let Jeremy comment more on
>> it...
>
> I went to work on the proposal for updating the itest framework and have
> the basic framework going. There is a smoketest in the runtime model that
> basically brings up a test component and calls it.
>
> I've started porting the samples from M2 to the 1.0 spec, starting with
> ones that do not use any extensions. I created a new core- samples module
> for this. I've managed to itest the calculator with the plugin.
>
> The launcher and webapp runtime these use don't work yet as they need the
> contribution stuff Luciano is working on - I had to hack local deployment
> into the itest plugin to be able to run things. Until then, I'm going to
> start migrating the old itest to 1.0 using the plugin to test them. If it
> seems to work well, I'll add doco to the plugin to generate the typical
> mini-site.
>
> We could also use a hack similar to the one I used in itest to deploy
> composites locally for the standalone and webapp environments - I can
> give pointers if anyone is interested (see
> MavenEmbeddedRuntime#deployTestScdl).
>
> --
> 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: Runtime bring-up and next steps
Posted by Raymond Feng <en...@gmail.com>.
The itest framework is very neat and easy to use now. Good job!
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@ws.apache.org>
Sent: Monday, February 12, 2007 10:40 AM
Subject: Re: Runtime bring-up and next steps
> On Feb 12, 2007, at 9:46 AM, Jim Marino wrote:
>
>> On Feb 12, 2007, at 8:01 AM, haleh mahbod wrote:
>>> Does bring up of runtime include a successful run of iTest?
>>>
>> I was specifically referring to the standalone runtime but it
>> appears Jeremy also has the itest plugin working with the really
>> neat ability to run a JUnit test as a component. This looks like a
>> big improvement over the old SCATestCase, particularly since it is
>> closer to the 1.0 APIs (we discussed doing this a while back). I'll
>> let Jeremy comment more on it...
>
> I went to work on the proposal for updating the itest framework and
> have the basic framework going. There is a smoketest in the runtime
> model that basically brings up a test component and calls it.
>
> I've started porting the samples from M2 to the 1.0 spec, starting
> with ones that do not use any extensions. I created a new core-
> samples module for this. I've managed to itest the calculator with
> the plugin.
>
> The launcher and webapp runtime these use don't work yet as they need
> the contribution stuff Luciano is working on - I had to hack local
> deployment into the itest plugin to be able to run things. Until
> then, I'm going to start migrating the old itest to 1.0 using the
> plugin to test them. If it seems to work well, I'll add doco to the
> plugin to generate the typical mini-site.
>
> We could also use a hack similar to the one I used in itest to deploy
> composites locally for the standalone and webapp environments - I can
> give pointers if anyone is interested (see
> MavenEmbeddedRuntime#deployTestScdl).
>
> --
> 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: Runtime bring-up and next steps
Posted by Jeremy Boynes <jb...@apache.org>.
On Feb 12, 2007, at 9:46 AM, Jim Marino wrote:
> On Feb 12, 2007, at 8:01 AM, haleh mahbod wrote:
>> Does bring up of runtime include a successful run of iTest?
>>
> I was specifically referring to the standalone runtime but it
> appears Jeremy also has the itest plugin working with the really
> neat ability to run a JUnit test as a component. This looks like a
> big improvement over the old SCATestCase, particularly since it is
> closer to the 1.0 APIs (we discussed doing this a while back). I'll
> let Jeremy comment more on it...
I went to work on the proposal for updating the itest framework and
have the basic framework going. There is a smoketest in the runtime
model that basically brings up a test component and calls it.
I've started porting the samples from M2 to the 1.0 spec, starting
with ones that do not use any extensions. I created a new core-
samples module for this. I've managed to itest the calculator with
the plugin.
The launcher and webapp runtime these use don't work yet as they need
the contribution stuff Luciano is working on - I had to hack local
deployment into the itest plugin to be able to run things. Until
then, I'm going to start migrating the old itest to 1.0 using the
plugin to test them. If it seems to work well, I'll add doco to the
plugin to generate the typical mini-site.
We could also use a hack similar to the one I used in itest to deploy
composites locally for the standalone and webapp environments - I can
give pointers if anyone is interested (see
MavenEmbeddedRuntime#deployTestScdl).
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Runtime bring-up and next steps
Posted by Jim Marino <jm...@myromatours.com>.
Hi,
Comments inline....
On Feb 12, 2007, at 8:01 AM, haleh mahbod wrote:
> Hi Jim,
> Is there a short write-up on all this somewhere? There might be one
> on the
> cwiki that I am not able to find.
Yes, there have been a bunch of mails posted to the list on these
topics over the last couple of weeks. I mentioned in a response to
Raymond's thread on the architecture description he added to the wiki
that I would try to make updates when I have some time, hopefully in
the next few days. If someone also wants to make a pass based on
changes from last week and over the weekend, I'm also happy to help
answer questions.
> I have been trying to cut and paste from several email and add the
> snippets
> to the 'in porgress' architecture document, but it is not clear how
> the
> pieces come together.
Could you post questions to the ML and I will try to answer them?
>
> Does bring up of runtime include a successful run of iTest?
>
I was specifically referring to the standalone runtime but it appears
Jeremy also has the itest plugin working with the really neat ability
to run a JUnit test as a component. This looks like a big improvement
over the old SCATestCase, particularly since it is closer to the 1.0
APIs (we discussed doing this a while back). I'll let Jeremy comment
more on it...
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Runtime bring-up and next steps
Posted by haleh mahbod <hm...@gmail.com>.
Hi Jim,
Is there a short write-up on all this somewhere? There might be one on the
cwiki that I am not able to find.
I have been trying to cut and paste from several email and add the snippets
to the 'in porgress' architecture document, but it is not clear how the
pieces come together.
Does bring up of runtime include a successful run of iTest?
Thanks,
Haleh
On 2/10/07, Jim Marino <jm...@myromatours.com> wrote:
>
> I've finished the final piece to bringing up the base standalone
> runtime which Jeremy has been working on to support the SCA 1.0
> client APIs. This mostly involved externalizing autowire from
> CompositeComponent to an AutowireResolver which is called after the
> model is loaded. This had the side-effect of simplifying the runtime
> as the connector no longer needs to deal with the autowire case
> (autowires will resolve to absolute URIs).
>
> I have also removed the process for connecting artifacts from
> CompositeComponent to Deployer.
>
> Below are a few more changes I plan to work on over the next few days:
>
> - I plan to continue refactoring Component to simplify and cleanup
> the interface. This will hopefully result in little difference
> between atomic and composite components.
>
> - I would like to eliminate the need for outbound and inbound wires,
> having the connector create a single Wire which is attached to a
> source. In this scenario, targets will not have wires but will
> continue to supply TargetInvokers to sources. This will tie in
> directly with Meeraj's work on the physical component builders and
> wire reconstitution on slaves. It will also further serve to simplify
> the connect phase. As we do this, we will need to revisit the SPI for
> WirePostProcessors. Following on Meeraj's physical builder work,
> policy and wire processing will need to be done on the master against
> the model and a portable representation of the wire sent to slaves
> where it will be constituted. We will need something akin to an
> InterceptorBuilder which will be responsible for helping to
> constitute a wire on the slave by supplying interceptors. Thoughts?
>
> - Integrate the autowire changes with Meeraj's federation work which
> will give us support for federated/distributed autowire across an SCA
> Domain (as well as supporting more of the SCA autowire semantics).
>
> Jim
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>