Re autowiring, I ran into a issue here trying to separate the Java
Class out of ServiceContract. There are still few places where we
assume that a ServiceContract has a corresponding Java interface - I
can deal with most of those but there are a lot of assumption in the
autowire implementation that this is there.
For now I plan to leave it there and just add the general properties
for class name and contribution to JavaServiceContract. Will this
refactor include changing autowire so that it is able to work on the
general ServiceContract rather than the Java-specific interface type?
If it does, then hopefully we can remove the Java-specific bits from
ServiceContract after.
--
Jeremy
On Jan 29, 2007, at 8:14 AM, Jim Marino wrote:
All,
This week I plan to undertake continued refactoring of the kernel
based on some of the work that was done over the last month.
Specifically, I plan to externalize the management of the component
tree to a service which will be implemented using a flattened
naming scheme. This will do the following:
- Allow us to collapse most of the differences between
CompositeComponent and AtomicComponent
- Allow us to introduce wire optimizations that eliminate the need
to have hops between composite services and references.
Optimizations can be done upfront as a changeset is applied to an
assembly
- Move autowiring to the resolution phase as outlined by Jeremy
- Remove the isSystem from SCAObject as the component manager
service will allow for component namespaces
I'll write-up more once I am further along.
Jim
---------------------------------------------------------------------
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]
