You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Steven E. Harris (JIRA)" <ji...@apache.org> on 2007/03/05 01:05:50 UTC
[jira] Created: (FELIX-227) iPOJO should allow configuration and
service properties to be bound via setter/getter methods, not just via
direct fields
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.
Are iPOJO objects really POJOs
Posted by an...@orange-ftgroup.com.
Hi everybody,
Having played a little with iPojo, at a first glance I think that objects manipulated by iPOJO are no plain objects at all ! Playing with private fields simply prevents the code of a so-called POJO to be tested by JUNIT or to be used without the iPOJO container. The object must be designed to be used in the iPojo container, this is in my view contrary to the orginal definition of a POJO !
Moreover, if you have a security manager, I don't think changing methods or fields accessibility, or manipulating bytecode would generally be considered acceptable.
Apparently field and method injection is only a feature in iPojo. Are you thinking of providing a version of iPojo without this feature, or is it considered essential ?
Best regards,
Anne
-----Message d'origine-----
De : Richard S. Hall (JIRA) [mailto:jira@apache.org]
Envoyé : mardi 24 avril 2007 16:27
À : felix-dev@incubator.apache.org
Objet : [jira] Resolved: (FELIX-227) iPOJO should allow configuration andservice properties to be bound via setter/getter methods, not just viadirect fields
[ https://issues.apache.org/jira/browse/FELIX-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall resolved FELIX-227.
-----------------------------------
Resolution: Fixed
Assignee: Richard S. Hall
I have applied the patch, please verify and close this issue.
> 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
> Assigned To: Richard S. Hall
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
[jira] Commented: (FELIX-227) iPOJO should allow configuration and
service properties to be bound via setter/getter methods, not just via
direct fields
Posted by "Steven E. Harris (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478112 ]
Steven E. Harris commented on FELIX-227:
----------------------------------------
I've used Spring, and maybe I missed some of its features, but its dependency injection worked by way of supplying constructor parameters to or calling methods on my classes, so its interaction with my class always respected the encapsulation boundary.
When you write, "you don't have to focus on which value a container-managed field has", this requires one to know which fields are container-managed. Maybe that's what I'm struggling with. I was trying to take an existing class and use it with iPOJO's property-injected fields, and I obviously ran into a lot of trouble. If I had started with the assumptions you're describing, I could have written the class differently.
But consider what would happen if I decided to change which fields should be bound to service properties. The class itself keeps on compiling just fine, but now it may be broken, failing to initialize fields no longer managed by the container. It's hard to be comfortable with this kind of code.
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.
However, a few other questions arise:
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.
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.
> 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.
[jira] Commented: (FELIX-227) iPOJO should allow configuration and
service properties to be bound via setter/getter methods, not just via
direct fields
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478062 ]
Richard S. Hall commented on FELIX-227:
---------------------------------------
I am not sure I totally agree with your second issue above. iPOJO's approach tells components not to worry about the values of fields managed by the container, but just to use them assuming that the values will be correct at runtime.
Regardless, you raise some valid points and I think supporting method invocations too could be worthwhile when setting properties.
> 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.
[jira] Resolved: (FELIX-227) iPOJO should allow configuration and
service properties to be bound via setter/getter methods, not just via
direct fields
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall resolved FELIX-227.
-----------------------------------
Resolution: Fixed
Assignee: Richard S. Hall
I have applied the patch, please verify and close this issue.
> 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
> Assigned To: Richard S. Hall
> 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.
[jira] Commented: (FELIX-227) iPOJO should allow configuration and
service properties to be bound via setter/getter methods, not just via
direct fields
Posted by "Clement Escoffier (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478110 ]
Clement Escoffier commented on FELIX-227:
-----------------------------------------
iPOJO follow the dependency injection pattern (as Spring). So when you read your code, you don't have to focus on which value a container-managed field has. You should guess : "it will have a consistent value". The JEE annotation are another good (and famous) example of dependency injections. But the advantages, is that these annotation are in the code. So user know that the field will be container-managed. iPOJO does not provide annotations because it brings compilation dependency that I don't want (it implies that each handler must provide its annotation classes and be in the classpath). A parser using "doclet" is currently under study. Doctlet have the advantage to not create compilation dependency but cannot be checked statically.
However, you point up an interisting limitation. There is no way in the POJO to be notified of the injection of a value in a property. Perhaps callback can help.
Imagine something like :
<property name="foo.bound" field="bound" method="setBound'>
and in your code
setBound(String newvalue) { ...}
When the container injects a value inside the "bound" property, it should notify the pojo by invoking the setBound method. What do you think of this solution ?
> 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.
[jira] Commented: (FELIX-227) iPOJO should allow configuration and
service properties to be bound via setter/getter methods, not just via
direct fields
Posted by "Steven E. Harris (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478095 ]
Steven E. Harris commented on FELIX-227:
----------------------------------------
Richard, which one is my second issue, the multiple-field-invariant problem or the constructor-field-initialization problem? I think you mean to say that one should not worry about initializing "container-managed" fields. I see this kind of programming in JEE's annotated "resource" fields, but there the code is actually marked with an annotation to hint that the value will come from somewhere else. In fairness, I recognize that JEE also allows these annotations to be omitted in favor of external XML descriptors like iPOJO.
Have you tried writing classes that work in this manner? Do you establish a convention for commenting the declaration of fields that are "managed by the container"?
> 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.
[jira] Commented: (FELIX-227) iPOJO should allow configuration and
service properties to be bound via setter/getter methods, not just via
direct fields
Posted by "Clement Escoffier (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (FELIX-227) iPOJO should allow configuration and
service properties to be bound via setter/getter methods, not just via
direct fields
Posted by "Clement Escoffier (JIRA)" <ji...@apache.org>.
[ 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.