Hi

On 17.06.2010, at 17:19, Joel Schuster wrote:

> Sorry, I'm not clear here.
> 
> So, a @Property without a set method would be at order 0?

There is a difference between field injection and method injection.
Field injection happen 'just in time' (when the field is used), and so can be 
used inside the constructor.
setter / bind methods are called after the constructor, but those methods can 
obviously access this.

> 
> Why can't 'this' be used if the set method is called after the constructor?

No no you can, I was not clear ! Sorry.


Clement

> 
> - Joel
> 
> -----Original Message-----
> From: Clement Escoffier [mailto:clement.escoff...@gmail.com] 
> Sent: Thursday, June 17, 2010 9:03 AM
> To: users@felix.apache.org
> Subject: Re: Problems with iPOJO / File Install
> 
> Hi,
> 
> On 17.06.2010, at 16:46, Joel Schuster wrote:
> 
>> As a continued question in this vein...
>> 
>> What would the be 'appropriate' way to convert from a *.cfg property to an 
>> Enum?
>> 
>> In this example I use a set method instead of just the member itself:
>> 
>> import gnu.io.SerialPort;
>> 
>> public enum ParityEnum {
>>   EVEN, MARK, NONE, ODD, SPACE;
>>   public static int value(ParityEnum pe) {
>>     switch (pe) {
>>        case EVEN: {
>>          return SerialPort.PARITY_EVEN;
>>       }
>>       case MARK: {
>>         return SerialPort.PARITY_MARK;
>>       }
>>       case NONE: {
>>         return SerialPort.PARITY_NONE;
>>       }
>>       case ODD: {
>>         return SerialPort.PARITY_ODD;
>>       }
>>       case SPACE: {
>>         return SerialPort.PARITY_SPACE;
>>       }
>>       default: {
>>         return -1;
>>       }
>>     }
>>   }
>> };
>> 
>> @Property(name = "parity", value = "NONE")
>> public void setParity(String parity) throws CommunicationsException {
>>   try {
>>     this.parityEnum = ParityEnum.valueOf(parity);
>>   } catch (IllegalArgumentException iae) {
>>     /* ... */
>>   }
>> }
>> 
>> protected ParityEnum parityEnum = ParityEnum.NONE;
>> 
>> What is the order in this case? Does the method get called before the 
>> constructor here too? (I'm not sure how that would happen.)
> 
> No, this is a 'set' method.
> Those methods are called just after the constructor. 
> The callbacks order is described here : 
> http://felix.apache.org/site/ipojo-faq.html#iPOJOFAQ-Callbacksorder.
> Your method will be called in third position : constructor, bind methods, 
> properties. This also mean that you can't use this.parityEnum inside the 
> constructor. If the configuration does not contains 'parity', iPOJO call 
> setParity("NONE").
> 
> Regards,
> 
> Clement
> 
> 
> 
>> 
>> -----Original Message-----
>> From: Clement Escoffier [mailto:clement.escoff...@gmail.com] 
>> Sent: Thursday, June 17, 2010 4:56 AM
>> To: users@felix.apache.org
>> Subject: Re: Problems with iPOJO / File Install
>> 
>> Hello,
>> 
>> On 17.06.2010, at 11:21, Bengt Rodehav wrote:
>> 
>>> Hello!
>>> 
>>> I use iPOJO (1.4.0) and File Install (3.0.0) deployed on Karaf (1.6.0).
>>> 
>>> I use the service factory pattern in OSGi to instantiate services from
>>> configuration files picked up by File Install. Howrver, there seems to be a
>>> startup problem. When the service is originally started, not all properties
>>> (in my newly instantiated service have received their values from the
>>> configuration file). Using Felix web console (the Configuration tab) the
>>> property values are correct. However, when I look under the iPOJO tab on the
>>> created instances the values are wrong. If I do any change in my
>>> configuration file (e g add some whitspace) and save it, File Install picks
>>> up the change and the iPOJO instance is now configured with the correct
>>> value.
>>> 
>>> I've seen a pattern regarding this. It seems like properties that are not
>>> given a default value in my code (initialised to null) will get their
>>> configuration set properly but the properties that are initialised to
>>> another value than null will not get their proper value until I later
>>> re-save my configuration file (which I guess is the next time File Install
>>> will propagate configuration changes).
>>> 
>>> Given the following code in my iPOJO service:
>>> 
>>> ...
>>> @Property(name = "toUri", mandatory = false)
>>> private String mToUri;
>>> 
>>> @Property(name = "delay", mandatory = false)
>>> private long mDelay = 1000;
>>> ...
>>> 
>>> The "toUri" property will be initialised properly when the service is
>>> started but the "delay" property will be initialised to 1000 regardless of
>>> what value I put in the configuration file. When I later re-save the
>>> configuration file, the proper value of the "delay" property will be
>>> propagated.
>> 
>> Your instance receives the configuration from the config admin before that 
>> an 'object' is created. So iPOJO associates mDelay to the correct value 
>> (from the configuration). However, then, an object is created (and so the 
>> constructor is called), and it executes an implicit constructor doing:
>> mDelay = 1000;
>> 
>> This overrides the value received by the configuration. If the configuration 
>> is updated, the instance receives the new value overriding the 1000.
>> 
>> So to avoid such behavior, just do:
>> @Property(name="delay", mandatory=false, value="1000")
>> private long mDelay; // No value here
>> 
>> This will inject 1000 if the property is not set in the configuration, or 
>> inject the value from the configuration.
>> 
>> Regards,
>> 
>> Clement
>> 
>> 
>> 
>> 
>>> 
>>> How can I have a default value but still have it overridden properly?
>>> 
>>> /Bengt
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Reply via email to