Hi Florian,
It's the SCR which picks up those XML files when the bundle containing
them is installed, and therefore knows what service interfaces it should
be listening for and which components need to be injected with those
services when they appear (and to "de-inject" them when they disappear).
The use cases where you cannot use DS are typically those where either1)
you don't have an SCR or 2) there is an SCR some other entity is
responsible for creating components and the SCR has no insight into this.
(Worse still there can be two versions of the component, one managed by
SCR and one by the other framework - aaargh).
The bundleContext object is used to talk to the OSGi framework, and the
OSGi framework doesn't know anything about DS so it cannot do anything
with your injectMembers() call. This separation of concerns ("extender
pattern") is part of the beauty of DS, and I think any proposal to make
the framework "DS-aware" would be greeted with much shaking of wise heads.
There may be scope for the various component/injection mechanisms which
are currently supported by OSGi to work better with one another, or even
with the anti-modular, anti-dynamic, reflection-infested frameworks(*)
widely used in the industry, but that is something else.
All the best
Chris
(*) Of course I love them really. Right?
> Hey,
>
> i got an idea for a nice DS enhancement. I am using DS a lot. And
> sometimes
> google.Guice too. And indeed there are some usecases where these features
> can be combined.
>
> Using DS i sometimes a miss a method, that injects (wires) all references
> according the component definition xml for classes instantiated by "new".
>
> Like this:
> *class Service {*
>
> * @Reference(...)*
> * protected void bindTransactionManager(TransactionManager tm) {*
> * .....*
> * }*
> *}*
>
> A different piece of code:
> *Service s = new Service();*
> *bundleContext.injectMembers(s);*
>
> The call #injectMembers(s) will use the component definition (there is
> generated xml file based on the annotations of Service.java) to wire up
> all
> references for the given instance.
>
> Usecase:
> There are usecases where you can not use DS. And for these ones a
> possibility to inject required services based on the component definition
> would be great.
>
> Are there any plans for such a specification change?
>
> Thanks
> Florian
>
> --
> Florian Pirchner
> Lunifera GmbH
> Marchfelder StraÃe 2
> 2301 Groà Enzersdorf
> Austria
> _______________________________________________
> 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
