On May 29, 2006, at 9:34 AM, Jeremy Boynes wrote:
In M1 we do not have a consistent approach on how the component type
information is derived for a component implemented by a Java class.
This, combined with some poor wording in the spec itself
(inconsistencies, fragmentation), led to a number of bugs in the run
up to M1 and I think the probability of more lurking. In an effort to
resolve this I think we should change the introspection process as
follows:
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 CI 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.
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
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.
The method or field may be defined in the class or in any superclass.
Private members are no longer valid injection sites (per resolution of
issue-35 in the spec group).
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.
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.
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.
The class need not implement the specified interfaces (although we
would recommend that it should) but all methods in all interfaces must
be present.
If the class or any superclass has a @Property or @Reference
annotation on any public or protected field or setter method, then the
properties and references of the component type are defined by those
annotations; no un-annotated fields and properties will be included.
In absense of any @Property or @Reference annotation, the properties
and references will be defined by the public and protected fields and
setter methods of the class and all superclasses as follows:
1) public setter methods that are not included in any service
interface
2) protected setter methods
3) public or protected fields unless there is a setter method for
the same name
If the type associated with the member is an array or a
java.util.Collection, then the basetype will be the element type of
the array or the parameterized type of the Collection, otherwise the
basetype will be the member type. If the basetype is an interface with
an @Remotable or @Service annotation then the member will be defined
as a reference, otherwise it will be defined as a property.
Yes this is good. We should also propose this as modified language to
the Java CI spec
Again, private members are not considered per issue-35
In M1 we captured some of this information during introspection and
included it as extension elements in the component type definition.
For M2, I'm going to formalize this by creating a JavaComponentType
model object that allows the mapping information for the Java class to
be included in the model definition.
We should also formalize a way to for extenders to have custom
property injectors stored
