Hi Peter, Am Mittwoch, den 18.06.2008, 14:02 +0200 schrieb Peter Kriens: > The spec explicitly forbids calling update on the MS(F) before the > configuration is updated > the first time. This implies that before you call update on the > configuration, the object > logically does not exist. If you persist it or not is irrelevant (I > think) as long as > you do not call update on the MS(F), also not after a restart. > However, if two threads > call createFactoryConfiguration on the same PID they should get back > the same Configuration > object, even if update has not been called yet.
I assume you mean "...call getConfiguration on the same PID..." > > That is, I do not think the persist or not is relevant, it is the > external behavior > of not calling the MS(F) update method before you have a valid > configuration that is the > important behavior. Well, I thought it would be relevant because I misinterpreted the listConfiguration method to return all existing -- that is persisted -- configurations. If so, whether or not createFactoryConfiguration persisted the configuration or not would be relevant, because listConfiguration would only return them if persisted. Now, re-reading listConfiguration I see that only Configurations _with_ properties are returned. That is regardless of their persistent state, no configuration which has just been created but not been updated yet will ever be returned. So in light of this situation, I turn to thinking, that Configuration objects from createFactoryConfiguration must not be persisted. Because, if such an object is created and then abandoned without ever updating it, it will not be accessible anymore: because the actual generated PID of the Configuration might be unknown and the Configuration will not be returned by listConfiguration. Hence for the sake of not creating garbage, the Equinox behaviour of not immediately persisting Configurations from createFactoryConfiguration is probably correct -- less in terms of spec compliance but more for not potentially generating garbage. > > Hope this helps, kind regards, Yes, it helped indirectly... Thanks alot. Regards Felix > > Peter Kriens > > > > > > On 18 jun 2008, at 08:00, Felix Meschberger wrote: > > > Hi all, > > > > I have remarked a difference in the implementation of Equinox DM and > > Apache Felix configadmin with respect to persisting Configuration > > objects created with either of the > > ConfigurationAdmin.createFactoryConfiguration methods: Equinox DM does > > not persist such Configuration objects until their update method is > > called. Apache Felix configadmin on the other hand immediately > > persists > > such Configuration objects adapting from Section 104.7.1: "The > > getConfiguration method must atomically create and persistently > > store an > > object if it does not yet exist." > > > > I cannot find any hint in the specification whether Configuration > > objects created by the createFactoryConfiguration methods should > > actually immediately be persisted or not and would be very thankful > > for > > a quick clarification of Section 104.7.2, Creating a Managed Service > > Factory Configuration Object. > > > > Regards > > Felix > > > > _______________________________________________ > > 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
