BTW I really like the SCA specification, though coming from a POJO /
Spring background the distinction between @Reference and @Property
seems a little surprising at first - I just wanted to describe my
initial confusion and see if I'm on the right track to their intended
differences and how they should be used.
Can you use @Property for services and @Reference for configuration
values?
=============================================================
The specification seems to imply @Property is used to mark "a
configuration property value" and @Reference is used to inject "a
service that resolves the reference". For the moment lets ignore the
difference between property injection by value versus by reference
(we'll come on to that in a moment).
What is the real difference, from the perspective of an application
programmer - between a service and a configuration property? It seems
a fairly vague distinction - are there some rules the application
developer can know when writing a POJO on what the difference between
the two are. e.g. a JMS ConnectionFactory and a JDBC DataSource are
probably configuration properties right?.
Is a "service" in this case something which is @Remotable or has
@Service? If either of those two are the case then can't the runtime
figure out the difference based on the type without the application
developer having to keep services & non-services in sync? Is the
difference between the two really just that of by-value rather than
by-reference configuration (and I was reading too much into the
description of the annotations)?
e.g. in Spring we can configure a service by name and inject it into
a beans property whether it has no annotation, @Property or
@Reference; so I'm wondering if the distinction between @Property and
@Reference makes sense WRT configuration property value versus
service - other than @Reference acts as a hint to the runtime to
auto-wire the property value by using a named reference.
So I guess I'm wondering; what is a service in this context and can
@Reference be used for non-services (like JDBC connections and other
properties you may wish to configure by-reference rather than by
value). I wonder if Im just being picky and @Reference is usually
used for configure-by-reference properties which usually are
services, but could in fact be any property?
IoC of values versus references
========================
In IoC containers like Spring there is no difference between
configuration by value or by reference at the POJO level; a POJO just
has bean properties (which may or may not be annotated by @Property);
the 'reference' only really exists in the XML configuration file.
e.g. in Spring we'd do
<bean id="myBean" class="Foo">
<!-- regular property injection -->
<property name="foo" value="1234"/>
<!-- named reference injection of a property -->
<property name="bar" ref="someName"/>
</bean>
In this case it is the author of the XML config file who decides
which properties are configured by value or by reference.
So at first it seems a little surprising as to why a POJO needs to
understand whether a property is set via direct property
configuration (@Property) or via looking up some named reference
(@Reference). It kinda feels wrong to make the POJO developer choose
how its going to be configured - especially when one of SCA's goals
is to hide middleware (which includes configuration).
I guess one effect of @Reference is that the container can
automatically inject the named POJO without it explicitly being
configured in some XML file. Maybe - considering Spring for a moment
here - if we don't explicitly configure a property then the runtime
would automatically inject it for us.
e.g.
public class Foo {
@Reference(name="myBar")
private Something bar;
...
}
the container would know how to inject the "bar" property by looking
up myBar - so in Spring we could just do...
<bean id="myBean" class="Foo">
<!-- runtime automatically injects "bar" property -->
</bean>
Though I guess there's nothing to stop someone reusing Foo and
explicitly configuring it in some runtime if they really want to...
<bean id="myBean" class="Foo">
<!-- lets override the name used... ->
<property name="bar" ref="aDifferentBar"/>
</bean>
Required defaults for @Reference and @Property
========================================
Since that @Reference & @Property are both optional; my main use case
for using @Property would be to mark mandatory properties (as
properties with no @Property annotation can still be injected). So
why not make @Property required default to true like it is for
@Reference? Then the default use of @Property adds some value -
denoting mandatory properties - without having to specify
(required=true)?
e.g.
public class Cheese {
public void setFoo(Something) {}
@Property
public void setBar(Something) {}
}
so that "foo" is optional and "bar" mandatory?
Then we'd have a little less clutter in our POJOs.
James
-------
http://radio.weblogs.com/0112098/
