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/17 09:40:21 UTC
wire changes
I've checked in a fairly large change involving moving to a single
wire type which has (hopefully) significantly simplified the kernel.
Specifically, the change covered the following:
- The inbound and outbound wire and invocation chain specializationa
have been removed, replaced by a single Wire and InvocationChain
type. Wires are now created by the Connector (as opposed to the
WireService, which will be renamed ProxyService). The Connector still
needs to be refactored further to take a WireDefintion; it current
creates wires from ComponentDefinition, ServiceDefiniton, or
ReferenceDefinition
- Wires are now held on the source. TargetInvokers remain the same.
- Callback chains have been moved to Wire as opposed to being
contained on an InboundWire
- There are only two types of invocation handler,
JDKInvocationHandler and JDKCallbackInvocationHandler; the inbound
variant is no longer needed
- I was able to remove a large amount of code and unit tests as they
verified connecting inbound and outbound wires. Actually, code
coverage went up to 70% in core.
I will continue to refactor the core over the weekend. I'd like to
get the Connector moved to using WireDefinitions when possible. Also,
I'd like to evolve the wire post-processing per my previous note.
This commit will hopefully be the last of the "big" ones".
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: wire changes
Posted by Jeremy Boynes <jb...@apache.org>.
On Feb 21, 2007, at 8:05 AM, Ignacio Silva-Lepe wrote:
> I'm not sure I understand this. Looking at ConnectorImpl,
> attachInvokers
> calls createTargetInvoker on a target, and it is called when a
> source is
> being wired. Since ConnectorImpl performs the wiring in a single pass
> (at least for a non-distributed composite), it seems to me there is no
> guarantee that a target wil have its wire(s) when createTargetInvoker
> is called upon it. Perhaps we are not talking about the same thing?
I think the connector is in still transition and what's there is
leftover from the single VM model. The key operation is:
public void connect(WireDefinition definition) throws
WiringException {
throw new UnsupportedOperationException();
}
which isn't very useful atm :-)
I think there's overlap in where we associate the actual target
instance with the proxy - we seem to be doing it in both the target
invoker and the proxy's invocation handler. This may be a hangover
from support for the old locateService call and we can probably
simplify that now all access goes through references.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: wire changes
Posted by Ignacio Silva-Lepe <is...@gmail.com>.
Hi Jeremy,
Comments inline.
On 2/21/07, Jeremy Boynes <jb...@apache.org> wrote:
>
> I don't see that.
>
> A single-valued reference would work the same way as a singleton
> list. The content of the collection would be established at resolve/
> connect time so the set of wires is known up front. The target
> invoker then gets created at one of two points in time depending on
> the scope relationship:
> 1) when the proxy is created
> 2) when the proxy is invoked
I'm not sure I understand this. Looking at ConnectorImpl, attachInvokers
calls createTargetInvoker on a target, and it is called when a source is
being wired. Since ConnectorImpl performs the wiring in a single pass
(at least for a non-distributed composite), it seems to me there is no
guarantee that a target wil have its wire(s) when createTargetInvoker
is called upon it. Perhaps we are not talking about the same thing?
The first applies when explicit or implicit configuration marks the
> wire as optimizable and/or eager initialized. The second applies when
> there is a lazy association with the target.
>
> In both cases though the proxy is connected to a single wire which is
> connected to the target container which creates the target invoker;
> no iteration should be needed.
>
> --
> Jeremy
>
> On Feb 21, 2007, at 6:50 AM, Ignacio Silva-Lepe wrote:
>
> > What I meant by pre-processing is the kind that LocalTargetInvoker
> > performs by caching the invocation chain for the operation it cares
> > about.
> > If, in general, we have a list of wires for multiplicity *..n, then
> > this
> > could mean being able to work on each wire in the list at the time
> > the target invoker is created. If the target invoker's invoke
> > method is
> > hit with high frequency and it needs to go over the list of wires
> > every time, then it could slow down the invocation.
> >
> >
> > On 2/21/07, Jim Marino <jm...@myromatours.com> wrote:
> >>
> >>
> >> On Feb 21, 2007, at 5:08 AM, Ignacio Silva-Lepe wrote:
> >>
> >> > Hi Jim,
> >> >
> >> > Yes, eliminating local composite services and references certainly
> >> > eliminates the issue for them ... :-)
> >> :-)
> >> > And in general, getting the target invoker to point back at the
> >> ser-
> >> > vice/reference binding should also work even if it means that some
> >> > pre-processing of the wire can't be safely performed at the
> >> point the
> >> > target invoker is created, which also means a certain level of
> >> ineffi-
> >> > ciency.
> >> >
> >> I don't think there should be any inefficiencies here. The
> >> preprocessing will occur on the master node during the normalization
> >> step. In the case of local bindings, since there will be no
> >> LocalServiceBinding or LocalReferenceBinding any more, there won't be
> >> any TargetInvoker subtypes for those; the only subtypes will be for
> >> physical transports (e.g. CFX QPid, Axis, JMS, etc.) and component
> >> implementation types.
> >>
> >> 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: wire changes
Posted by Jeremy Boynes <jb...@apache.org>.
I don't see that.
A single-valued reference would work the same way as a singleton
list. The content of the collection would be established at resolve/
connect time so the set of wires is known up front. The target
invoker then gets created at one of two points in time depending on
the scope relationship:
1) when the proxy is created
2) when the proxy is invoked
The first applies when explicit or implicit configuration marks the
wire as optimizable and/or eager initialized. The second applies when
there is a lazy association with the target.
In both cases though the proxy is connected to a single wire which is
connected to the target container which creates the target invoker;
no iteration should be needed.
--
Jeremy
On Feb 21, 2007, at 6:50 AM, Ignacio Silva-Lepe wrote:
> What I meant by pre-processing is the kind that LocalTargetInvoker
> performs by caching the invocation chain for the operation it cares
> about.
> If, in general, we have a list of wires for multiplicity *..n, then
> this
> could mean being able to work on each wire in the list at the time
> the target invoker is created. If the target invoker's invoke
> method is
> hit with high frequency and it needs to go over the list of wires
> every time, then it could slow down the invocation.
>
>
> On 2/21/07, Jim Marino <jm...@myromatours.com> wrote:
>>
>>
>> On Feb 21, 2007, at 5:08 AM, Ignacio Silva-Lepe wrote:
>>
>> > Hi Jim,
>> >
>> > Yes, eliminating local composite services and references certainly
>> > eliminates the issue for them ... :-)
>> :-)
>> > And in general, getting the target invoker to point back at the
>> ser-
>> > vice/reference binding should also work even if it means that some
>> > pre-processing of the wire can't be safely performed at the
>> point the
>> > target invoker is created, which also means a certain level of
>> ineffi-
>> > ciency.
>> >
>> I don't think there should be any inefficiencies here. The
>> preprocessing will occur on the master node during the normalization
>> step. In the case of local bindings, since there will be no
>> LocalServiceBinding or LocalReferenceBinding any more, there won't be
>> any TargetInvoker subtypes for those; the only subtypes will be for
>> physical transports (e.g. CFX QPid, Axis, JMS, etc.) and component
>> implementation types.
>>
>> 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: wire changes
Posted by Ignacio Silva-Lepe <is...@gmail.com>.
What I meant by pre-processing is the kind that LocalTargetInvoker
performs by caching the invocation chain for the operation it cares
about.
If, in general, we have a list of wires for multiplicity *..n, then this
could mean being able to work on each wire in the list at the time
the target invoker is created. If the target invoker's invoke method is
hit with high frequency and it needs to go over the list of wires
every time, then it could slow down the invocation.
On 2/21/07, Jim Marino <jm...@myromatours.com> wrote:
>
>
> On Feb 21, 2007, at 5:08 AM, Ignacio Silva-Lepe wrote:
>
> > Hi Jim,
> >
> > Yes, eliminating local composite services and references certainly
> > eliminates the issue for them ... :-)
> :-)
> > And in general, getting the target invoker to point back at the ser-
> > vice/reference binding should also work even if it means that some
> > pre-processing of the wire can't be safely performed at the point the
> > target invoker is created, which also means a certain level of ineffi-
> > ciency.
> >
> I don't think there should be any inefficiencies here. The
> preprocessing will occur on the master node during the normalization
> step. In the case of local bindings, since there will be no
> LocalServiceBinding or LocalReferenceBinding any more, there won't be
> any TargetInvoker subtypes for those; the only subtypes will be for
> physical transports (e.g. CFX QPid, Axis, JMS, etc.) and component
> implementation types.
>
> Jim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: wire changes
Posted by Jim Marino <jm...@myromatours.com>.
On Feb 21, 2007, at 5:08 AM, Ignacio Silva-Lepe wrote:
> Hi Jim,
>
> Yes, eliminating local composite services and references certainly
> eliminates the issue for them ... :-)
:-)
> And in general, getting the target invoker to point back at the ser-
> vice/reference binding should also work even if it means that some
> pre-processing of the wire can't be safely performed at the point the
> target invoker is created, which also means a certain level of ineffi-
> ciency.
>
I don't think there should be any inefficiencies here. The
preprocessing will occur on the master node during the normalization
step. In the case of local bindings, since there will be no
LocalServiceBinding or LocalReferenceBinding any more, there won't be
any TargetInvoker subtypes for those; the only subtypes will be for
physical transports (e.g. CFX QPid, Axis, JMS, etc.) and component
implementation types.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: wire changes
Posted by Ignacio Silva-Lepe <is...@gmail.com>.
Hi Jim,
Yes, eliminating local composite services and references certainly
eliminates the issue for them ... :-)
And in general, getting the target invoker to point back at the ser-
vice/reference binding should also work even if it means that some
pre-processing of the wire can't be safely performed at the point the
target invoker is created, which also means a certain level of ineffi-
ciency.
Thanks
On 2/21/07, Jim Marino <jm...@myromatours.com> wrote:
>
>
> On Feb 20, 2007, at 11:26 AM, Ignacio Silva-Lepe wrote:
>
> > Hi Jim,
> >
> > I am not sure I understand one thing, maybe I am missing something.
> > Previously, the wire service was invoked in the build phase, as far as
> > I recall. This meant that by the time the connector needed to ask for
> > a target invoker to get created, any arbitrary component, reference or
> > service would have its wires available.
> > In particular, for (the now called) LocalReferenceBinding, when
> > createTargetInvoker was called on it, it could safely new up a
> > LocalTar-
> > getInvoker passing it its (outbound) wire. Now that the connector is
> > also creating wires in the same phase, it's not clear that a LocalRe-
> > ferenceBinding will always have its wire by the time createTarget-
> > Invoker is called on it.
> > Does this sound right, or is there some (perhaps not so) subtle thing
> > I am missing?
> >
> Yeah. I thought about solving this by just having the TargetInvoker
> point back to the Service/ReferenceBinding to get the wire lazily
> which should be a simple change but then it dawned on me we don't
> need local composite services or references at all and should be able
> to just get rid of them. Similar to how the AutowireResolver works,
> we need to introduce a "normalization" phase that is run over the
> model where intermediate hops are factored out of a wire. Harking
> back to a previous post, it should be the case that /all/ wires in an
> SCA domain are normalized to one of the following:
>
> 1. Atomic Component Reference ---->Atomic Component Service
> 2. Atomic Component Reference ---->to a physical transport (via a
> ReferenceBinding)
> 3. physical transport (via a ServiceBinding)---->Atomic Component
> Service
> 4. physical transport (via a ServiceBinding)---->to a physical
> transport (via a ReferenceBinding)
>
> All local bindings would be nornalized to case 1 and hence exist only
> as component-component interactions. This means that the local
> reference and service bindings should be able to just go away.
>
> Meeraj was working on the slave side of the wire building. We were
> going to start on the master part where this normalization would
> happen (probably) tomorrow.
>
> Does this address the issue you were raising?
>
> Jim
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: wire changes
Posted by Jim Marino <jm...@myromatours.com>.
On Feb 20, 2007, at 11:26 AM, Ignacio Silva-Lepe wrote:
> Hi Jim,
>
> I am not sure I understand one thing, maybe I am missing something.
> Previously, the wire service was invoked in the build phase, as far as
> I recall. This meant that by the time the connector needed to ask for
> a target invoker to get created, any arbitrary component, reference or
> service would have its wires available.
> In particular, for (the now called) LocalReferenceBinding, when
> createTargetInvoker was called on it, it could safely new up a
> LocalTar-
> getInvoker passing it its (outbound) wire. Now that the connector is
> also creating wires in the same phase, it's not clear that a LocalRe-
> ferenceBinding will always have its wire by the time createTarget-
> Invoker is called on it.
> Does this sound right, or is there some (perhaps not so) subtle thing
> I am missing?
>
Yeah. I thought about solving this by just having the TargetInvoker
point back to the Service/ReferenceBinding to get the wire lazily
which should be a simple change but then it dawned on me we don't
need local composite services or references at all and should be able
to just get rid of them. Similar to how the AutowireResolver works,
we need to introduce a "normalization" phase that is run over the
model where intermediate hops are factored out of a wire. Harking
back to a previous post, it should be the case that /all/ wires in an
SCA domain are normalized to one of the following:
1. Atomic Component Reference ---->Atomic Component Service
2. Atomic Component Reference ---->to a physical transport (via a
ReferenceBinding)
3. physical transport (via a ServiceBinding)---->Atomic Component
Service
4. physical transport (via a ServiceBinding)---->to a physical
transport (via a ReferenceBinding)
All local bindings would be nornalized to case 1 and hence exist only
as component-component interactions. This means that the local
reference and service bindings should be able to just go away.
Meeraj was working on the slave side of the wire building. We were
going to start on the master part where this normalization would
happen (probably) tomorrow.
Does this address the issue you were raising?
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: wire changes
Posted by Ignacio Silva-Lepe <is...@gmail.com>.
Hi Jim,
I am not sure I understand one thing, maybe I am missing something.
Previously, the wire service was invoked in the build phase, as far as
I recall. This meant that by the time the connector needed to ask for
a target invoker to get created, any arbitrary component, reference or
service would have its wires available.
In particular, for (the now called) LocalReferenceBinding, when
createTargetInvoker was called on it, it could safely new up a LocalTar-
getInvoker passing it its (outbound) wire. Now that the connector is
also creating wires in the same phase, it's not clear that a LocalRe-
ferenceBinding will always have its wire by the time createTarget-
Invoker is called on it.
Does this sound right, or is there some (perhaps not so) subtle thing
I am missing?
On 2/17/07, Jim Marino <jm...@myromatours.com> wrote:
>
> I've checked in a fairly large change involving moving to a single
> wire type which has (hopefully) significantly simplified the kernel.
> Specifically, the change covered the following:
>
> - The inbound and outbound wire and invocation chain specializationa
> have been removed, replaced by a single Wire and InvocationChain
> type. Wires are now created by the Connector (as opposed to the
> WireService, which will be renamed ProxyService). The Connector still
> needs to be refactored further to take a WireDefintion; it current
> creates wires from ComponentDefinition, ServiceDefiniton, or
> ReferenceDefinition
>
> - Wires are now held on the source. TargetInvokers remain the same.
>
> - Callback chains have been moved to Wire as opposed to being
> contained on an InboundWire
>
> - There are only two types of invocation handler,
> JDKInvocationHandler and JDKCallbackInvocationHandler; the inbound
> variant is no longer needed
>
> - I was able to remove a large amount of code and unit tests as they
> verified connecting inbound and outbound wires. Actually, code
> coverage went up to 70% in core.
>
> I will continue to refactor the core over the weekend. I'd like to
> get the Connector moved to using WireDefinitions when possible. Also,
> I'd like to evolve the wire post-processing per my previous note.
>
> This commit will hopefully be the last of the "big" ones".
>
> Jim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>