That all sounds good. I read the iPOJO Tutorial (.07), but that
doesn't fully explain lifecycle and reference cardinality topics as
addressed by DS, such as the static v. dynamic policy, and whether one
can be notified when optional or multiple references come and go (a la
the DS bind/unbind methods). In short, is there more documentation
available?
Hello,
A more complete documentation on the dependency management is available
at : http://cwiki.apache.org/confluence/display/FELIX/Dependency+Handler
iPOJO component instance have a very simple lifecycle. Once started, an
instance is either INVALID, either VALID. iPOJO Container is composed by
"handlers" (piece of code, plugged at runtime, managing a non-functional
requirement). An instance is VALID <=> all its plugged handlers are valid.
The handler managing service dependency, contained in iPOJO, manages the
service tracking and service objects injection. It manages
"dependencies". A dependency can be optional or mandatory, simple or
aggregate (multiple), filtered or not .... The handler is invalid if at
least one mandatory dependency cannot be resolved. When the handler
becomes invalid, it invalids the component instance too.
A dependency does not declare explicitly that it is an aggregate
dependency. The handler analyzes the POJO field of the dependency.
According to the field type, it discover the required interface, and the
cardinality (array or simple field). When needed, the handler injects
the service object(s) in the field.
Optional dependencies need to be declared explicitly (optional="true").
But to avoid null pointer exception when an unresolved optional
dependency is used, the handler injects a nullable object (mock object).
Once the requirement is resolved, the field receive a "real" service object.
To resume, we can compare DS cardinalities and iPOJO Dependency
management as :
1..1 : dependency attached on a "simple" (not array) field
0..1 : dependency attached on a "simple" (not array) field, with
optional="true"
1..n : dependency attached on an array field (Foo[] m_myFooServices;)
0..n : dependency attached on an array field with optional="true"
The handler does not have binding policy. Only the DS dynamic policy is
provided.
It is possible to declare callbacks on binding / unbinding events.
<dependency field="myservice">
<callback type="Bind" method="mybindMethod"/>
<callback type="Unind" method="myUnbindMethod"/>
</dependency>
Theses callbacks invoke a method contained in the POJO class. The type
describe when to call the method. These method can have three kinds of
arguments :
- without any argument (public void mybindMethod())
- with the service object (public void mybindMethod(Object o))
- with the service reference (public void mybindMethod(ServiceReference ref)
When called, The service object is already injected inside the
dependency field. The method invocation is delayed since the component
instance content (the pojo object) is created.
iPOJO is an extensible service-oriented component model. The semantic of
the service dependency is attached to the actual "handler" managing
these dependencies. It is possible to change it without modifying iPOJO
core code.
Clement
--
Clement Escoffier
Grenoble University
LSR - Bat. C
220, Rue de la Chimie
BP 53
38041 GRENOBLE CEDEX 9
04.76.51.40.24
http://clement.plop-plop.net
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
