I don't know whether the "service.target" property can be taken from the configuration created by ConfigurationAdmin. If yes, you may create a component by creating a factory configuration. But that component should be declared as immediate/delay component instead of factory component.
Regards, Agemo On Tue, Jun 15, 2010 at 3:33 PM, Sangjin Lee <[email protected]> wrote: > What I am suspecting is that this might be an issue of timing. If I > understood the specification correctly, ComponentFactory.newInstance() will > try to satisfy the constraints when invoked, and if it is unable to do so it > *at that time* it will throw a ComponentException. I think it follows then > that this is not a blocking call. If there is no service that can satisfy > the binding at the time of invocation, the call will "fail fast". Is this > understanding correct? Then I don't think this can be made to work. > > What I was hoping for is a way to produce a component definition > dynamically so they can stay unsatisfied until the service they're looking > for comes online. > > Regards, > Sangjin > > > On Mon, Jun 14, 2010 at 9:13 AM, Sangjin Lee <[email protected]> wrote: > >> Thanks. With the equinox DS (1.1.1.R35x_v20090806), however, I do get a >> ComponentException saying that it is unable to resolve a service instance >> (haven't tried felix yet). >> >> I have a complete proof-of-concept example that shows what I'm trying to >> do, and hopefully you'd be able to see for yourself: http://bit.ly/dhnyfK >> . >> >> Thanks! >> >> Sangjin >> >> >> On Mon, Jun 14, 2010 at 6:42 AM, BJ Hargrave <[email protected]> wrote: >> >>> I don't see why this should not work. All you can do is refine one of the >>> target reference which must exist for the ComponentFactory to be satisfied. >>> So a service.target property passed to newInstance can further refine the >>> bound reference. >>> >>> It may be that the current implementations do not handle this, but from a >>> spec point of view, it should be supported. >>> -- >>> >>> *BJ Hargrave* >>> Senior Technical Staff Member, IBM >>> OSGi Fellow and CTO of the *OSGi Alliance* <http://www.osgi.org/>* >>> **[email protected]* <[email protected]> >>> >>> office: +1 386 848 1781 >>> mobile: +1 386 848 3788 >>> >>> >>> >>> >>> >>> >>> From: Sangjin Lee <[email protected]> >>> To: OSGi Developer Mail List <[email protected]> >>> Date: 2010/06/10 14:01 >>> Subject: [osgi-dev] [DS] ComponentFactory.newInstance with a >>> dynamic property >>> Sent by: [email protected] >>> ------------------------------ >>> >>> >>> >>> I have a question on the behavior of ComponentFactory.newInstance() when >>> you inject a reference target dynamically. >>> >>> I have a factory component that has a unary mandatory reference to some >>> service, but the target is intentionally left blank (so I can provide it >>> dynamically). When I instantiate a specific instance, I want to pass in a >>> particular type so this specific instance can bind to the right service >>> instance. The code snippet is at >>> *http://bit.ly/dy8kFy*<http://bit.ly/dy8kFy> >>> . >>> >>> I am basically adding a property for "service.target" = "(type=foo)", so >>> at runtime this binds specifically to a service instance of type=foo. Will >>> this pattern work? Also, if so, how does ComponentFactory.newInstance() >>> behave if that service is not registered yet? Will it fail immediately or >>> will it block/wait until that particular service is registered? >>> >>> In a bigger context, I'm trying to see if I can use this pattern as a way >>> to "compel" a specific service with a type dynamically at runtime. Is there >>> a better pattern to compel a specific service type dynamically? Thanks much! >>> >>> Regards, >>> Sangjin_______________________________________________ >>> >>> 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
