[
https://issues.apache.org/jira/browse/FELIX-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clement Escoffier updated FELIX-227:
------------------------------------
Attachment: patch_method_plugin.patch
patch_method_core.patch
These patch allow for a POJO to be notified when a property is updated.
<properties>
<property name="my.property" method="myUpdateMethod"/>
</properties>
At each time, the POJO is reconfigured, the myUpdateMethod is invoked with the
new value in argument.
A property can now be a field, a method or a field and a method.
It allows service dependencies to have no field (bind / unbind method only).
patch_method_core.patch needs to be applied on the core project.
patch_method_plugin.patch needs to be applied on the plugin project.
> 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
> Attachments: patch_method_core.patch, patch_method_plugin.patch
>
>
> 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.
