Again, fantastic information. Reminds me just how much more I need to learn about OSGi. :-)
I'd like to have the central/common configuration be configurable through the configuration admin console. Should I have a ManagedService for the common config but also have it implement ManagedServiceFactory? How do I get a reference in my service consumer to the custom configured service from a ManagedServiceFactory? The examples I see create services that don't require a reference (port listeners, etc). Is this where you suggest using a regular java factory to create the custom versions of the service? Does that mean the services would not be managed by OSGi but just regular objects handed out by my factory? As an aside, can you suggest any examples where I can learn the proper contexts for each of these magical OSGi factories? On Sat, Apr 17, 2010 at 3:03 PM, Felix Meschberger <[email protected]>wrote: > > My situation is this: I would like to have a single place to configure > LDAP > > connection configuration information and have various bundles be able to > use > > that, but if a bundle wanted to provide it's own configuration (not use > the > > central/default) it should be able to do so. I expect the connections to > > come from an LDAP bundle. Suggestions? > > Your use case sounds like a combination of both approaches: factory > configuration for the central/default ones and ComponentFactory for the > special ones. > > I would suggest you choose a third approach (which sounds a bit hacky at > first), but probably comes closest to your requirement: > > (1) Your component is actually a factory (in the regular Java sense) > for connection objects (right?). > (2) The component implements the ManagedServiceFactory interface and > is declared to register as such (@Service annotation). To not > interfere with SCR, the configuration policy on the @Component > annotation should be set to ConfigurationPolicy.IGNORE. Also, > ensure the properly set the service.pid and service.factoryPid > service registration properties as component properties. > (3) Add factory methods to create (and delete) connection objects > on demand. Have these methods be part of a service under which > the component is registered, too. (The component is thus > actually registered with two service names. > > Now, if a central/default configuration is managed with Configuration > Admin, the respective updated and deleted methods are called. If a > bundle wants to manage on-demand connnections, the factory service (from > step 3) is used. > > Hope this helps. > > Regards > Felix > > > > > > > On Fri, Apr 9, 2010 at 4:41 PM, Carl Hall <[email protected]> wrote: > > > >> Thanks again for the fantastic information! It sounds like a component > >> factory is what I'll want to go with. I'll get to work on this and see > what > >> I can come up with. > >> > >> > >> On Fri, Apr 9, 2010 at 4:22 PM, Felix Meschberger <[email protected] > >wrote: > >> > >>> Hi, > >>> > >>> On 09.04.2010 22:11, Carl Hall wrote: > >>>> Hi Felix, Thanks for the fast response! > >>>> > >>>> If the component in question has @Reference fields in it, are they > >>> carried > >>>> over to the new instances from the factory? > >>> > >>> Yes, references are bound at component activation time just like for > >>> non-service factory components. > >>> > >>>> > >>>> Is it possible for the requesting component to send up information > that > >>> can > >>>> be used to configure new instances from the factory? > >>> > >>> No, all instances of service factory components are configured the > same. > >>> Same as all components. Actually to the service consumers service > >>> factory services look exactly the same as regular services. > >>> > >>> If you want your service (or component consumers) to be able to create > >>> specially crafted objects, you might want to consider using a component > >>> factory or register a factory service the consumers may call to get the > >>> actual object. > >>> > >>> As for component factory: you declare the component as a component > >>> factory by setting factory attribute to the @Component annotation. Then > >>> SCR registers a ComponentFactory service on behalf of the component. > >>> Consumers then call the newInstance(Dictionary) method on the > >>> ComponentFactory to actually create an instance of the real component > >>> which is configured according to the dictionary. > >>> > >>> But beware: consumers of the ComponentFactory components must make sure > >>> to call the ComponentInstance.dispose() method when done using the > >>> component. > >>> > >>> Regards > >>> Felix > >>> > >>>> > >>>> > >>>> On Fri, Apr 9, 2010 at 4:03 PM, Felix Meschberger <[email protected] > >>>> wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> On 09.04.2010 21:54, Carl Hall wrote: > >>>>>> When using the @Service annotation and specifying > serviceFactory=true, > >>>>>> should I also implement the ServiceFactory interface to make sure > the > >>>>>> (get|unget)Service methods are found or are there more annotations > to > >>>>> mark > >>>>>> such methods without implementing the interface? > >>>>> > >>>>> No, if you mark a component as being a service factory component the > >>>>> Service Component Runtime registers a ServiceFactory implementation > on > >>>>> behalf of the component and when a bundle requests the actual > service, > >>>>> the runtime instantiates the component class and activates it to hand > >>> it > >>>>> out. > >>>>> > >>>>> In short, this is all take care of for the component. > >>>>> > >>>>> Regards > >>>>> Felix > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: [email protected] > >>>>> For additional commands, e-mail: [email protected] > >>>>> > >>>>> > >>>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >>> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
