Change By: Grégory Joseph (17/Sep/13 6:15 PM)
Description: When a proxied bean sets a default for some field in its constructor, via a setter method (which is often done especially in subclasses that provide some default/specific behavior), the "manually" configured value gets overriden. The call flow goes like this:

{code}
class Obj = {
  Obj() {
   setFoo("default")
  }
  void setFoo(String) {}
}

obj = new Obj()// sets foo to "default"
obj.setFoo("my configured value")

d = i18nizer.decorate(obj)
// proxy creation involves invoking the constructor of d
assertEquals("my configured value", d.getFoo() // fails, d.getFoo() returns "default"
{code} 


This is a problem inherent to class-based proxies - the constructor of the generated subclass (the proxy) is called when instanciating it. This inherently invokes the original class' constructor, which calls {{setFoo()}} in this example. Since in our case, all methods (thus including {{setFoo}}) are decorating and delegate to the original underlying object, this overwrites the configured value.

One possible pattern against this would be to have a protected constructor which takes the default values as arguments; subclasses which want to set default values for certain properties could have a single public no-arg constructor, which delegates to this super construct with the default values instead of calling the corresponding setters. This has the disadvantage that anything that potentially needs a default value should be exposed in the super constructor; which isn't always practical, since one doesn't always have access to the source code thereof.

Another possibility to investigate is to see if we could somehow "delay" the delegation/decoration until after the subclass/proxy is instanciated. I'm however not sure how that would play with other things such as init() methods and so on.

Currently impacted by this : {{FieldDefinition}} with {{transformerClass}} - see MGNLUI-2102 - and {{ActionDefinition}} with {{implementationClass}} - see MGNLUI-2117 and MGNLUI-2121
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira



----------------------------------------------------------------
For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively, use our forums: http://forum.magnolia-cms.com/
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------

Reply via email to