Whether Felix's CM implementation "fixes" this issue or not, the fact is a robust ManagedService[Factory] implementation will always have to deal with the possibility of receiving those null configurations.
IMHO it would be better to implement your functionality as a DS component, perhaps setting the "configurationPolicy" attribute set to "require". This will ensure that the component is activated only when configuration data is available for it; also it allows you to avoid using OSGi-specific APIs in your code. Regards, Neil On Tue, Jan 5, 2010 at 10:55 AM, Felix Meschberger <[email protected]> wrote: > Hi, > > On 05.01.2010 11:34, David Bosschaert wrote: >> I was hoping one of the Config Admin authors or implementors would jump >> in here... > > hmm, being one of the Apache Felix Config Admin developers, I assume you > address me ;-) > >> Anyway, you are right, Configuration Admin may call the updated() method >> multiple times, sometimes first with null and then later with a map of >> values. >> The Config Admin service always calls every Configuration target either >> with null or with a map. A call with null indicates that the >> Configuration Admin service is present but it has no configuration for >> the Configuration Target, so that it can start operating with defaults >> if it wants to. >> >> If configuration appears for a certain target after the initial callback >> with null, Config Admin will call back again with the actual map of >> configuration. >> >> Now because of timing issues and implementation details of a certain >> Config Admin implementations the time between having no configuration >> and having configuration could be extremely short. What you'd really >> want in this case is not being called back with null as there is >> actually config information available (the implementation just hasn't >> found it yet). > > I fully agree with your assessment and have nothing more to add ;-) > >> >> So in short: the behaviour is legal, but it's not very pretty. It would >> be nicer if the initial update(null) was skipped if there is actually >> config information available. I think that this issue has been fixed in >> newer versions of the Felix Config Admin impl. Other implementations may >> also differ in this regard... > > Not sure, whether we can talk of a "fix" here: Apache Felix Config Admin > checks configuration at the time of ManagedService[Factory] service > registration (during ServiceEvent handling). If no configuration is > available at that time, null will always be sent before sending the > actual configuration. > > Regards > Felix > >> >> Hope this helps, >> >> David >> >> Miguel wrote: >>> you are right Neil, a jvm property is need. thank you. I read the >>> apache documentation [1] and it seemed not to introduce any >>> configuration property. >>> >>> Now it is running properly but I can see how updated method is called >>> twice. One with a null argument and other with the configuration >>> properties of the file .cfg i have created. Why does it behave this way? >>> >>> >>> >>> >>> >>> >>> >>> [1] >>> http://www.osgilook.com/2009/08/20/apache-felix-file-install-part-2-dynamic-configurations/ >>> >>> >>> Miguel >>> Sent from Madrid, Spain >>> >>> On Mon, Jan 4, 2010 at 2:25 PM, Neil Bartlett <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Miguel, >>> >>> FileInstall by default looks in a directory named "load" relative to >>> the working directory. If you want to change that you can use a >>> system >>> property as follows: >>> -Dfelix.fileinstall.dir=conf/application on the Java command >>> line. It >>> looks like you might be missing the "-D" >>> >>> Regards, >>> Neil >>> >>> On Mon, Jan 4, 2010 at 1:18 PM, Miguel <[email protected] >>> <mailto:[email protected]>> wrote: >>> > umm, yes, that could be one of the problems (I have just changed >>> it to >>> > conf/application), now when fileinstall bundle starts up, I get >>> > >>> > [OSGi Console] DEBUG org.apache.felix.fileinstall - ServiceEvent >>> REGISTERED >>> > [OSGi Console] DEBUG org.apache.felix.fileinstall - ServiceEvent >>> REGISTERED >>> > [OSGi Console] DEBUG org.apache.felix.configadmin - Scheduling task >>> > ManagedServiceFactory Update: >>> factoryPid=org.apache.felix.fileinstall >>> > [Configuration Updater] DEBUG org.apache.felix.configadmin - >>> Running task >>> > ManagedServiceFactory Update: >>> factoryPid=org.apache.felix.fileinstall >>> > >>> > but it seems it doesn't look into the directory >>> conf/application. I am maybe >>> > forgeting something ... >>> > I have also tried with absolute path but nothing changes .. >>> > >>> > regards, >>> > >>> > >>> > Miguel >>> > Sent from Madrid, Spain >>> > >>> > On Mon, Jan 4, 2010 at 1:36 PM, Peter Kriens >>> <[email protected] <mailto:[email protected]>> wrote: >>> >> >>> >> You use both conf/application (in the text) and >>> config/application in the >>> >> configuration file. Is that the problem? >>> >> >>> >> Kind regards, >>> >> >>> >> Peter Kriens >>> >> >>> >> On 4 jan 2010, at 13:30, Miguel wrote: >>> >> >>> >>> Yes, I have already tried pax confman, I have tested it and it >>> works >>> >>> fine. >>> >>> >>> >>> But now, I m having troubles with the apache solution ... I >>> have launched >>> >>> the following framework: >>> >>> >>> >>> 0 ACTIVE org.eclipse.osgi_3.5.1.R35x_v20090827 >>> >>> 1 ACTIVE org.apache.felix.fileinstall_2.0.8 >>> >>> 2 ACTIVE org.eclipse.osgi.services_3.2.0.v20090520-1800 >>> >>> 3 ACTIVE com.as.configuration.provider_1.0.0.SNAPSHOT >>> >>> 5 ACTIVE org.ops4j.pax.logging.pax-logging-api_1.4.0 >>> >>> 6 ACTIVE org.apache.felix.scr_1.0.6 >>> >>> 7 ACTIVE org.ops4j.pax.logging.pax-logging-service_1.4.0 >>> >>> 8 ACTIVE org.apache.commons.logging_1.0.4.v200904062259 >>> >>> 9 ACTIVE org.apache.felix.configadmin_1.2.4 >>> >>> >>> >>> >>> >>> in dropings, I have created a file: >>> >>> >>> >>> ~/opt/eclipse/dropins$ more >>> org.apache.felix.fileinstall-config.cfg >>> >>> felix.fileinstall.dir=config/application >>> >>> #felix.fileinstall.poll=2000 >>> >>> m...@mcm:~/opt/eclipse/dropins$ vim >>> >>> org.apache.felix.fileinstall-config.cfg >>> >>> >>> >>> and inside conf/applicaton I have created a file >>> <pid_name>.cfg which is >>> >>> a >>> >>> properties file: >>> >>> >>> >>> more conf/application/provider.application.cfg >>> >>> hola prueba >>> >>> ip 127.0.0.1 >>> >>> ip2 182.3.3.6 >>> >>> >>> >>> >>> >>> but it seems not to work .... My bundle method updated is >>> called but with >>> >>> a >>> >>> null properties argument. >>> >>> >>> >>> has anybody tried it? >>> >>> >>> >>> >>> >>> Miguel >>> >>> Sent from Madrid, Spain >>> >>> >>> >>> On Mon, Jan 4, 2010 at 1:11 PM, Daniel Bimschas >>> <[email protected] <mailto:[email protected]>> >>> >>> wrote: >>> >>> >>> >>>> Hi Miguel, >>> >>>> >>> >>>> you can try Pax Confman [1], too. It basically does the same, >>> but, as >>> >>>> far >>> >>>> as I know, only for configuration files. >>> >>>> >>> >>>> Kind regards, >>> >>>> Daniel >>> >>>> >>> >>>> [1] http://wiki.ops4j.org/display/ops4j/Pax+ConfMan >>> >>>> >>> >>>> Am 04.01.2010 um 11:52 schrieb Miguel: >>> >>>> >>> >>>>> thank you! I didnt know file installer could manage config >>> files... >>> >>>>> Thank >>> >>>> >>> >>>> you for that! >>> >>>>> >>> >>>>> regards, >>> >>>>> >>> >>>>> Miguel >>> >>>>> Sent from Madrid, Spain >>> >>>>> >>> >>>>> On Mon, Jan 4, 2010 at 10:51 AM, David Bosschaert >>> >>>>> <[email protected] <mailto:[email protected]>> >>> >>>> >>> >>>> wrote: >>> >>>>> >>> >>>>> Hi Miguel, >>> >>>>> >>> >>>>> You may want to have a look at the Felix File Install: >>> >>>> >>> >>>> http://felix.apache.org/site/apache-felix-file-install.html >>> >>>>> >>> >>>>> I think it does exactly what you're looking for: read >>> properties files >>> >>>> >>> >>>> from a directory in disk and push these in the Configuration >>> Admin >>> >>>> service. >>> >>>>> >>> >>>>> Best regards, >>> >>>>> >>> >>>>> David Bosschaert >>> >>>>> >>> >>>>> Miguel wrote: >>> >>>>> yes, but do you mean reading a file and registering all the >>> properties >>> >>>> >>> >>>> using config admin service? Or is there any direct way to do >>> it using >>> >>>> config admin? >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> Miguel >>> >>>>> Sent from Madrid, Spain >>> >>>>> >>> >>>>> On Mon, Jan 4, 2010 at 10:35 AM, Peter Kriens >>> >>>>> <[email protected] <mailto:[email protected]><mailto: >>> >>>> >>> >>>> [email protected] <mailto:[email protected]>>> wrote: >>> >>>>> >>> >>>>> Use Config Admin ... >>> >>>>> >>> >>>>> Kind regards, >>> >>>>> >>> >>>>> Peter Kriens >>> >>>>> >>> >>>>> >>> >>>>> On 29 dec 2009, at 16:24, Miguel wrote: >>> >>>>> >>> >>>>> hello, >>> >>>>> >>> >>>>> I have been reading several ways to configure bundle >>> variables >>> >>>>> usign a >>> >>>>> external file. It seems that PAX confman provides this >>> >>>>> implementation but i >>> >>>>> don't know if it is the best way. >>> >>>>> >>> >>>>> for you, what would be the best way to configure a bundle >>> >>>>> externally? >>> >>>>> >>> >>>>> best regards, >>> >>>>> >>> >>>>> Miguel >>> >>>>> Sent from Madrid, Spain >>> >>>>> _______________________________________________ >>> >>>>> OSGi Developer Mail List >>> >>>>> [email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>> >>> >>>>> >>> >>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >>>>> >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> OSGi Developer Mail List >>> >>>>> [email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>> >>> >>>>> >>> >>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>> ------------------------------------------------------------------------ >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> OSGi Developer Mail List >>> >>>>> [email protected] <mailto:[email protected]> >>> >>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> OSGi Developer Mail List >>> >>>>> [email protected] <mailto:[email protected]> >>> >>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> OSGi Developer Mail List >>> >>>>> [email protected] <mailto:[email protected]> >>> >>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >>>> >>> >>>> _______________________________________________ >>> >>>> OSGi Developer Mail List >>> >>>> [email protected] <mailto:[email protected]> >>> >>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >>>> >>> >>> _______________________________________________ >>> >>> OSGi Developer Mail List >>> >>> [email protected] <mailto:[email protected]> >>> >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >> >>> >> _______________________________________________ >>> >> OSGi Developer Mail List >>> >> [email protected] <mailto:[email protected]> >>> >> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> > >>> > >>> > _______________________________________________ >>> > OSGi Developer Mail List >>> > [email protected] <mailto:[email protected]> >>> > https://mail.osgi.org/mailman/listinfo/osgi-dev >>> > >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> [email protected] <mailto:[email protected]> >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> [email protected] >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
