Re: Annotation processing changes

[Simon Nash <na...@hursley.ibm.com>]

Jeremy and Jim,
A number of issues for the spec have been identified in this thread.
Who is going to raise and track them with the spec group?

   Simon

Jeremy Boynes wrote:

> On 5/29/06, Jim Marino <jm...@myromatours.com> wrote:
> 
>> On May 29, 2006, at 9:34 AM, Jeremy Boynes wrote:
>>
> <snip/>
> 
>> >
>> > If a ".componentType" sidefile exists, it provides the definitive list
>> > of the implementation's services, references and properties.
>> >
>> We probably need to clarify the spec here since side files "overlay"
>> the introspected information in the Java C&I spec. This makes sense
>> since having part of the metadata in annotations and part in a side
>> file doesn't really make sense, or is at least very prone to error.
>>
> 
> I think this is one of the most confusing areas of the spec especially
> when you have liberal defaulting rules. For example, the Java spec
> defines introspection rules that allow an unadorned POJO to be the
> implementation but that poses a high risk of conflict with a
> componentType sidefile.
> 
>> > Every operation in every service must be mapped to a public method in
>> > the implementation. The implementation need not implement the service
>> > interface (although if the interface is defined in Java then we would
>> > recommend that it did).
>> One use case where it maybe doesn't besides mediation is a mixin but
>> that may be a bit esoteric for applications
> 
> 
> I think any mixins have to be applied before SCA introspection is done
> - probably worth defining that in the spec as well. That would make
> this bit clear, although a client may still get a runtime problem if
> the mapping is not valid (similar to an AbstractMethodError).
> 
>> >
>> > Every reference and property in the sidefile must be mapped to an
>> > injection site in the implementation. Sites will be located in the
>> > following order:
>> > 1) a public or protected method or field identified in the sidefile
>>
>> > 2) a public or protected method annotated with the applicable
>> > annotation
>> > 3) a public or protected field annotated with the applicable
>> > annotation
>> > 4) a public or protected setter method with the same name
>> > 5) a public or protected field with the same name
>> >
>> For @Reference and @Property we need to be careful to use the name
>> attribute and preserve the mappings to method or field until the
>> point of injection as this was the cause of bugs and hacks in M1.
> 
> 
> Yes - I'm going to add method mapping information to the
> JavaComponentType model object to ensure this is preserved. However,
> unlike M1 where we had Injector information in the model I'm going to
> defer that to build time (this allows JavaComponentType to be in the
> SPI but the actual injection mechanism to remain in the core impl).
> 
>> > If no sidefile exists then the component type will be derived by
>> > introspection of the implementation class.
>> >
>> > If the class or any superclass has an @Service annotation then the
>> > services are explicitly defined by that annotation. The set of
>> > services exposed will be the union of all @Service annotations in the
>> > class hierarchy.
>> >
> 
> 
> For clarity, the service interface will be remotable if the interface
> is annotated @Remotable, otherwise it will only be available to local
> components.
> 
>> > If no @Service annotation is present then the services are defined by
>> > the interfaces that are implemented by the class or its superclass and
>> > any super-interfaces thereof.
>> This follows from below but it may be worth pointing out. If no
>> @Remotable is present, then all services will be local. Conversely,
>> if only @Remotable is present, then the specified interfaces will be
>> remotable.
> 
> 
> The spec is a little ambiguous here: "it is assumed that all
> implemented interfaces that have been annotated as @Remotable are the
> service interfaces provided by the component." This can be read as
> saying that only the annotated interfaces are the service interfaces
> and all others are ignored.
> 
> I used the language in the next paragraph to allow local services to
> be explictly defined and to provide resonable default behaviour for
> the common case where the class implements a single service interface.
> 
>> > If any interface has an @Remotable or
>> > @Service annotation then the set of services is defined as the union
>> > of all such interfaces. If no interface is annotated, then the
>> > component type will define a single service comprising all public
>> > methods that are not reference or property injection sites. If that
>> > service can be exactly mapped to an interface implemented by the class
>> > then the service interface will be defined in terms of that interface.
>> >
> 
> 
> <snip/>
> 
>> >
>> We should also formalize a way to for extenders to have custom
>> property injectors stored somewhere that were created by custom
>> annotation processors. This will allow people to introduce behavior
>> into the assembly process such as injection of resources (I'm
>> thinking about things like JPA PersistenceManager)
>>
> 
> As I said above, I would prefer if the implementation of injection was
> separate from the model of what needed to be injected. For example,
> the model would contain the mapping from a property to an injection
> site but it would not define how the injection would be performed. It
> would be the builder's responsibility to create the injector.
> 
> We do need to define a mechanism for this especially for conflict
> resolution (e.g. how do we handle the case where we have @Property,
> @Reference, @Autowire and @Resource all present, or where @SDOHelper
> defines a property and need to override default property introspection
> rules). I plan doing that as part of the implementation.
> 
> Cheers
> -- 
> Jeremy
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> 
> 
> 

-- 
Simon C Nash   IBM Distinguished Engineer
Hursley Park, Winchester, UK   nash@hursley.ibm.com
Tel. +44-1962-815156   Fax +44-1962-818999


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org