> DS guarantees that activate is called before the service is registered and > thus available to others.
This is not quite correct (although it is correct for immediate components). The service is registered after it becomes satisfied (all of its mandatory service and configuration dependencies are available) but before it is activated. This is because DS is lazy, and won’t instantiate/activate a component until it is needed. Therefore your activate method is not called until someone tries to get your component’s service, at which point the activate method is called and run to successful completion before the service is given to the requesting bundle. You can rely on the activate method having successfully completed before the instance is available to any other bundle. This is the important part of the guarantee from a happens before perspective, and is the reason that using a static policy is both simple and thread safe. Obviously if your component is immediate then it will be activated as soon as it is satisfied. If the immediate component advertises a service then nobody will be able to access the instance until after the activate method returns. Best Regards, Tim > On 14 Aug 2018, at 07:33, Peter Kriens via osgi-dev <osgi-dev@mail.osgi.org> > wrote: > > Your understanding is correct with respect to the _service_. DS guarantees > that activate is called before the service is registered and thus available > to others. The service is unregistered before you deactivate is called. > Nulling fields is generally unnecessary unless you want to ensure an NPE if > an object uses your service after unregistering. > > Kind regards, > > Peter Kriens > >> On 14 Aug 2018, at 05:20, David Leangen via osgi-dev <osgi-dev@mail.osgi.org >> <mailto:osgi-dev@mail.osgi.org>> wrote: >> >> >> Hi! >> >> In a concurrent system, if a class is immutable, the problem is simplified >> and the class can be used without fear by multiple threads because (i) it’s >> state does not change, and (2) it’s state is guaranteed to be visible; >> >> Example: >> >> /** >> * The class is immutable because the fields are both immutable types >> * and are "private + final”. The fields are guaranteed to be visible >> * to all threads after construction. In other words, there is a >> * “happens-before” constraint on the fields. >> */ >> public class SimpleImmutableClass { >> private final String value1; >> private final int value2; >> >> public SimpleImmutableClass( String aString, int anInt ) { >> value1 = aString; >> value2 = anInt; >> } >> >> public String getValue1() { >> return value1; >> } >> >> public int getvalue2() { >> return value2; >> } >> } >> >> My understanding is that DS will provide the same happens-before constraint >> to the fields in the following service, so presuming that there is no method >> exposed to change the field values, the service is effectively immutable and >> can be used without fear in a concurrent context. So in the following, >> value1 and value2 are guaranteed to be visible to all threads thanks to the >> happens-before constraint placed on the fields during activation: >> >> /** >> * The LogService is basically just added to show that the component is used >> * in a static way, as only a static component can be effectively immutable. >> */ >> @Component >> public class EffectivelyImmutableService { >> private String value1; >> private int value2; >> >> @Reference private LogService logger; >> >> @Activate >> void activate( Map<String, Object> properties ) { >> value1 = (String)properties.get( "value1" ); >> value2 = (int)properties.get( "value2" ); >> } >> >> /** >> * Hmmmm, but if an instance is never reused, then wouldn't it be >> completely >> * unnecessary to deactivate()?? >> */ >> void deactivate() { >> value1 = null; >> value2 = -1; >> } >> >> public String getValue1() { >> logger.log( LogService.LOG_INFO, String.format( "Value of String is >> %s", value1 ) ); >> return value1; >> } >> >> public int getvalue2() { >> logger.log( LogService.LOG_INFO, String.format( "Value of int is >> %s", value2 ) ); >> return value2; >> } >> } >> >> >> Is somebody able to confirm my understanding? >> >> Thanks!! >> =David >> >> _______________________________________________ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
