> On 17 May 2016, at 11:46, Chong, Kim Theng <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://github.com/osgi/osgi.iot.contest.sdk/blob/master/osgi.enroute.trains.api/src/osgi/enroute/trains/cloud/api/TrackConfiguration.java 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 > Thank you for your time. > Best regards, > Kim > > > > From: 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://mail.osgi.org/mailman/listinfo/osgi-dev>
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
