On 5/29/06, Jim Marino <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
