Hi Tim, Thank you very much for your detailed explanation.
Best regards, Kim From: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org] On Behalf Of Timothy Ward Sent: Tuesday, May 17, 2016 11:06 PM To: OSGi Developer Mail List Subject: Re: [osgi-dev] Question on dependencies injection and config reading in SCR On 17 May 2016, at 11:46, Chong, Kim Theng <kimtheng.ch...@experian.com<mailto:kimtheng.ch...@experian.com>> wrote: Hi Tim, Thank you very much for your explanation. Yes, we would like to use the standard annotations. and I am in the middle of trying the way that you mentioned in the “dependency injection” and I have some further questions: * Register the other component in the service registry. If it is using a “private” (i.e. not exported) API then nobody else will find it. * Does it means that, for the scenario when we want to inject “serviceRegistry” dependency to “myService”, we need to register both myService and serviceRegistry as @Component, and then use the @Reference annotation to reference “serviceRegistry” in “myService”? Yes - you need to register the “serviceRegistry” and then use @Reference to consume it in “myService”. “myService” does not have to be registered as a service for this to work, but it should be for the reset of your use case. May I know is there any tutorials/sample for “properties attribute”? I seem not able to search any from the web. I have try to use the @Component attribute “configurationPid” and get the properties value in “activate” method through “Map<String, Object> config”, may I know is this the proper way to retrieve configuration value? And what is the different between this and the “properties” attribute? Defining an activate method using @Activate gives you a callback when all of your components dependencies are satisfied, and the component is ready for activation (read up on lazy activation if you’re interested in the difference between these two things). Valid arguments to an activate method are zero or more of: * Map<String, Object> - this will pass in a map of your component’s component properties * A component property type - this is a type safe view of your component’s component properties * BundleContext - this will pass in the BundleContext of the bundle which defines the DS component * ComponentContext - this will pass the SCR ComponentContext for your component Using an Activate method is the only recommended way to retrieve component properties in a DS component. Whey you set the properties attribute on the @Component annotation you are providing a set of default keys and values that will be set in your component’s component properties. The configuration pid that you’ve set is used for integration with configuration admin. Configuration Admin can be used to set or override component properties, and can also be used to limit a component’s activation by using the configurationPolicy. You can see an example of using a type-safe component property type from the OSGi IoT contest here: https://github.com/osgi/osgi.iot.contest.sdk/blob/master/osgi.enroute.trains.track.manager.example.provider/src/osgi/enroute/trains/track/manager/example/provider/ExampleTrackManagerImpl.java#L81<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_osgi_osgi.iot.contest.sdk_blob_master_osgi.enroute.trains.track.manager.example.provider_src_osgi_enroute_trains_track_manager_example_provider_ExampleTrackManagerImpl.java-23L81&d=DQMFaQ&c=BNNF-YNv0CLLslhP2Bcx5Q&r=nkTZHXrJs6ajcdXMiKMBUzIVqz19DiWDyUt7fOV9t7Y&m=H43c8blKhqBk6jrgEl3MddD3LFPmPY1QtQW-N2haxg0&s=sRxXNwCm2vZ76XttnQBDVWPG3BLAsN6o3C40EKmzeJE&e=> https://github.com/osgi/osgi.iot.contest.sdk/blob/master/osgi.enroute.trains.api/src/osgi/enroute/trains/cloud/api/TrackConfiguration.java<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_osgi_osgi.iot.contest.sdk_blob_master_osgi.enroute.trains.api_src_osgi_enroute_trains_cloud_api_TrackConfiguration.java&d=DQMFaQ&c=BNNF-YNv0CLLslhP2Bcx5Q&r=nkTZHXrJs6ajcdXMiKMBUzIVqz19DiWDyUt7fOV9t7Y&m=H43c8blKhqBk6jrgEl3MddD3LFPmPY1QtQW-N2haxg0&s=Y29f4JZv5a3pxQ9v8bXC9pBGREqng_19vQigo-Ahn3k&e=> Note that a component property type is defined as an annotation. This lets you set default values, and ensures that only compatible types are used in the configuration. Best Regards, Tim Ward OSGi IoT Expert Group Chair tim.w...@paremus.com<mailto:tim.w...@paremus.com> Thank you for your time. Best regards, Kim From: osgi-dev-boun...@mail.osgi.org<mailto:osgi-dev-boun...@mail.osgi.org> [mailto:osgi-dev-boun...@mail.osgi.org] On Behalf Of Timothy Ward Sent: Monday, May 16, 2016 6:15 PM To: OSGi Developer Mail List Subject: Re: [osgi-dev] Question on dependencies injection and config reading in SCR Hi Kim, Declarative Services is a great choice, and should give you a simple way to do most of the things that you need. On 16 May 2016, at 04:52, Chong, Kim Theng <kimtheng.ch...@experian.com<mailto:kimtheng.ch...@experian.com>> wrote: Hi all, Previously we were using Spring DM to perform dependencies injections and services declaration, and now we would like to migrate to OSGI declarative services/SCR. May I know is there any ways to perform: 1. bean wiring/dependency injection for SCR like Spring DM does? For example: • @line1: We want to expose “myService” as a service. (This should be achievable by using @Component, @Service, correct me if I am wrong) Which annotation set are you using? The standard annotations do not have an @Service annotation, and I would very strongly suggest that you use the standard annotations. By default using @Component exports all of the directly implemented interfaces of your component class (i.e. the exact list of interfaces after the implements keyword). This can be modified using the service attribute of the annotation. • @line7: We want to inject “serviceRegistry” dependency to “myService”. • Note: “serviceRegistry” is a normal bean class, which does NOT expose as a service. <image002.png> This sort of injection (“private” components) is not supported by Declarative Services, however this isn’t really a problem. You can either: * Register the other component in the service registry. If it is using a “private” (i.e. not exported) API then nobody else will find it. * Just new up the instance in your activate method. If the serviceRegistry component really is a private detail of a single component then it’s just part of its behaviour. The new operator isn’t always evil! 2. Reading properties from a configuration file and binding them into service? For example a. There is a configuration file: service.config with following properties: # service type service.type = A And we are declaring the service such a way in Spring DM: (the service that going to be registered is based on the “service.type” value in the config file). Is this doable in OSGI declarative services? The @Component annotation has exactly this support using the properties attribute. Best of luck, Tim Ward Chief Technology Officer tim.w...@paremus.com<mailto:tim.w...@paremus.com> <image001.png> Thank you so much for your time. Best regards, Kim _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org<mailto:osgi-dev@mail.osgi.org> https://mail.osgi.org/mailman/listinfo/osgi-dev<https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.osgi.org_mailman_listinfo_osgi-2Ddev&d=DQMFaQ&c=BNNF-YNv0CLLslhP2Bcx5Q&r=nkTZHXrJs6ajcdXMiKMBUzIVqz19DiWDyUt7fOV9t7Y&m=cX5_qJ5tc0bDm5GylJHffQXTPGGWRqxn31k-Ekn21vU&s=cu2syswbxnkZ_zyepbVpXX5ieX8HY4XI1Aw6Al8foFQ&e=> _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org<mailto:osgi-dev@mail.osgi.org> https://mail.osgi.org/mailman/listinfo/osgi-dev<https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.osgi.org_mailman_listinfo_osgi-2Ddev&d=DQMFaQ&c=BNNF-YNv0CLLslhP2Bcx5Q&r=nkTZHXrJs6ajcdXMiKMBUzIVqz19DiWDyUt7fOV9t7Y&m=H43c8blKhqBk6jrgEl3MddD3LFPmPY1QtQW-N2haxg0&s=ZbTIUlju4Mjlb_O559yDesh3kRZcJtLX5bEA7aLRgE4&e=>
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
