On Feb 26, 2007, at 4:39 PM, Jim Marino wrote:
On Feb 26, 2007, at 2:25 PM, Jeremy Boynes wrote:
Resending a previous reply as my ISP's MTA seems to be acting up...
On 2/26/07, Jim Marino <[EMAIL PROTECTED]> wrote:
FYI,
Now that we have the AutowireResolver in place, I'm going to look
into adding support for full SCA 1.0 autowire semantics in trunk.
This will mean we can get rid of the @Autowire tag (using @Reference
instead).
It might be an idea to deprecate that now so that users know that it
will be going away.
Sure, I just deprecated it and checked it in (r512090). Once we get
the new functionality, I'd like to just get rid of the old way of
doing things if others agree since the impact will be minimal.
Will they need to use @Reference or is default introspection
typically
going to ensure that there is no need for any annotation (which would
even better)?
Good question...We have a couple of options:
1. We use normal heuristics and introspection rules that are
implemented for References. This will mean that in many cases
setters will need to be annotated with @Reference unless it can be
determined from the type that it is a service (e.g. it is decorated
with @Remotable, @Service, or @Conversational).
2. We do something fancy similar to PicoContainer where the the
AutoWireResolver will attempt to resolve any ambiguous complex type
if autowire is true for the reference, component, or composite.
I haven't thought much about the implications of #2 but I've found
PicoContainer incredibly useful, powerful, and concise (not to
mention small) and think we should borrow ideas from it. What do
people think?
Jim
FYI,
I'm going to go in an remove all uses of @Autowire from the runtime
today. In its place, applications can use standard SCA references
and set autowire in the appropriate SCDL locations as defined by the
1.0 assembly spec. With the addition of autowire to the SCA specs and
these changes, the extension and "standard" SCA Java implementation
programming models are pretty much the same, the difference being
implementations of the former are Composite scope by default.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
