On 18 jun 2008, at 14:41, Felix Meschberger wrote:
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..."
yup :-(
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.
Yup. :-)
Kind regards,
Peter Kriens
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
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
