Hi, On 17.06.2010, at 17:43, Joel Schuster wrote:
> Thanks for the clarifications! You're welcome. > > 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? So, yes it is possible. The only concern is to not introduce Java 5 code in the iPOJO core... But after a quick investigation about Enum and there 'class' mapping is sounds like it is possible :-) Can you create a Jira issue for that ? Clement > > -----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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
