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.
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.
Hope this helps, kind regards,
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
