Thanks for the clarifications! Would it be work a JIRA ticket to all for Field injection with Enum types based on the String or Value? Or would that be to complicated?
-----Original Message----- From: Clement Escoffier [mailto:clement.escoff...@gmail.com] Sent: Thursday, June 17, 2010 9:36 AM To: users@felix.apache.org Subject: Re: Problems with iPOJO / File Install 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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
