[
https://issues.apache.org/jira/browse/FELIX-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478118
]
Clement Escoffier commented on FELIX-227:
-----------------------------------------
[ "..." part are citation of previous messages]
"Your "method" attribute on <property> is almost exactly what I was asking for,
but I would expect that the "field" attribute would be mutually exclusive with
the "method" attribute. If I want iPOJO to call on my methods, I probably don't
want it actually touching my fields."
It makes sense, invoking method instead of injecting field is a possibility. It
just cause a performence effect : method invocations are based on reflection.
"Should an updated factory-based Configuration still cause an instance to be
killed and recreated, or should you assume that an instance can tolerate being
updated dynamically if it requests these "method" callbacks? Note that DS
deactivates and reactivates an factory-created instance when its Configuration
changes. I'm not sure which is the right way to go. "
The problem, by dynamically reconfigured instances, is that handlers need to be
ware of these reconfiguration. Today, handlers are configured only one times
(receiving both component-type metadata and instance configuration), then
started and stopped. By allowing dynamic reconfiguration of the instance, it
implies that handler can be re-configured. I don't have an example on the top
of my head, but perhaps this reconfiguration is not possible without an
invalidation (stopping) of the instance.
"Also, what about constructors? Would these property callbacks be called after
the constructor runs? In my report above, I noted that initializing these bound
fields in the constructor mistakenly overwrites the iPOJO-property-bound
values. What I'd prefer is to allow the default constructor (or one taking a
BundleContext) to run, with its fields initialized by the constructor code,
unmolested by iPOJO, and then have the fresh instance be called on with each of
its "method" property callbacks."
To invoke callback, I need an object. This object is received when the
constructor has finish to execute. So these, callbacks will be called after the
constructor (as dependency callback). Moreover, these callbacks need to be
delayed, if the handler received an property value but no instance are needed
right now. The methods will be invoked just after the first call of the
constructor.
> iPOJO should allow configuration and service properties to be bound via
> setter/getter methods, not just via direct fields
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: FELIX-227
> URL: https://issues.apache.org/jira/browse/FELIX-227
> Project: Felix
> Issue Type: Improvement
> Components: iPOJO
> Environment: Not relevant.
> Reporter: Steven E. Harris
>
> iPOJO's binding of configuration properties and service properties directly
> to component fields causes a few difficult situations that could be eased by
> optionally binding the reading and writing to getter and setter methods
> instead.
> First, consider a component class with invariants that span multiple fields.
> iPOJO can change the value of a field without the owning class knowing,
> depriving it the chance to update dependent fields that participate in the
> invariant. Examples include recalculating and caching an expensive result
> whenever some input field changes, or validating a changed value and updating
> other fields in response.
> Second, at present iPOJO sets the value of bound fields before the component
> class constructor runs. If the constructor attempts to initialize some
> fields, it may be inadvertantly overwriting the initial values supplied by
> iPOJO. Writing the constructor to deliberately ignore values that might be
> bound by iPOJO flies in the face of the very name of the project: a POJO
> isn't supposed to know that it's being silently manipulated like this, and
> hence a POJO should be written in standard form: Initialize variables to sane
> defaults, including constructor parameters, expecting them to be overwritten
> later.
> Take for example a class that has two fields, one of which is bound to a
> configuration property:
> public class Example {
> private String bound;
> private String dependent;
> public Example() {
> bound = null;
> dependent = "empty";
> }
> public void setBound(String s) {
> bound = s;
> dependent = null == s || 0 == s.length() ? "empty" : "full";
> }
> public String getDependent() {
> return dependent;
> }
> }
> If written in this manner, the constructor mistakenly overwrites the initial
> iPOJO-provided value for "bound" by initializing it to null. But to resist
> initializing "bound' is also dangerous; how would one reading this code have
> any idea that "bound" might get set to a different value before the
> constructor runs, or while the instance is live?
> Also, consider that if "bound' changes silently once the instance is live,
> "dependent" will fall out of step, as the invariant maintained in setBound()
> can be violated.
> If iPOJO would allow property binding to optionally work by way of getter and
> setter methods, one and a half of these problems could be avoided. The
> missing half relates to construction. If we ask iPOJO to defer setting the
> "initial values" until the constructor completes, we may have to defer some
> initialization that would use the values not yet available.
> Trying to write a POJO class that gets manipulated on the sly by iPOJO is
> proving to be more tricky than just writing some of the ManagedServiceFactory
> code myself, as I'm forced to adjust my would-be POJO service class to deal
> with these weird initialization and invariant maintenance problems normally
> solved by member variable encapsulation. Perhaps we should look at Spring's
> example that better acknowledges not just the technical possibilities, but
> the logical difficulties in iPOJO's kind of silent injection and manipulation.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
