I tend to agree (actually rather violently) with Neil: ‘new’ for private
objects is perfectly OK in a bundle.
Why did DI frameworks got so popular? I think this was mostly because
applications had grown so large and constituted of so many different parts that
you needed central control to keep things apart and control their
initialization in the right order.
Now back to OSGi. First and foremost, you no longer (should!) have a monolith.
A good bundle is cohesive. This means that everything in that bundle belongs
together. So why should you make a mock if that thing is already coupled? There
is no use to take the cost of abstracting because if anything changes, all its
dependencies are together? I.e. the compiler will immediately tell you if you
use things wrong. So by using ’new’ I get the benefit of readability, no magic,
compiler checks, navigation in the IDE, and full refactoring. Best of all, no
XML programming! For me one of the best things about OSGi is that the
components are often so simple because they look like plain old java.
Usually, in engineering, the ’truth’ is rarely at the extremes. Imho, DS found
the right balance between external (dynamic) dependencies -> injection, for the
rest plain old java since injection does not really provide you with anything
but familiarity.
And if you really absolutely want injection … just use Guice or another DI
container inside your component?
Kind regards,
Peter Kriens
> On 22 mei 2015, at 10:12, Simon Kitching <si...@vonos.net> wrote:
>
> Thanks Pierre and Neil for your replies!
>
> To avoid splitting this thread, I'll also reply to Neil's email here.
>
> I agree with Neil completely about the Blueprint lifecycle (ugly). I much
> prefer the DS lifecycle management - but miss the ability in DS or DM to
> manage bundle-private objects. I find it interesting that OSGi has solved the
> problem of a global class namespace (via Export-Package), but has then
> created a single global service namespace.
>
> Regarding the use of "new":
>
> (a) It would be nice to share code between OSGi and non-OSGi environments. In
> non-OSGi environments, use of dependency injection (rather than explicit use
> of new) is wide-spread.
>
> Do you not have problems when trying to share code between OSGi and non-OSGi
> environments?
>
> (b) DI isn't usually used to inject things that can be created with "new".
> Instead, it is predominantly used to inject singleton objects that are used
> by many other objects. As an example, a common _cache_ may be injected, or a
> serialization-helper. The alternative to DI in this case is not "new", but
> instead the old "static singleton" pattern, or lookup via JNDI or similar. Or
> to retrieve the object from the OSGi service registry - but that leads to
> "polluting" of the global service registry which I am concerned about.
>
> Do you not have problems when sharing a "bundle-private" object between
> multiple DS-managed objects?
>
> (c) One major motivation for using DI is to support unit testing. When a
> class uses DI properly, then a unit test can instantiate that class with
> mocks for the various other objects it interacts with. The test can then
> verify that the class under test interacts with mock objects as expected. It
> can also emulate various failures in the mocked systems, eg returning
> error-codes or throwing exceptions. When a class uses "new" to instantiate a
> helper object, no mocking of the external class is possible.
>
> When you use "new" in your code, does this not cause you problems with unit
> test coverage?
>
> Because of the above, I don't currently see using "new" as an alternative to
> DI for wiring up objects inside a bundle.
>
> Pierre, many thanks for your very detailed reply.
>
> Re link to iPojo - that's next on my list of things to investigate; I've been
> using spring-dm, blueprint and felix-dm up to now but haven't yet taken time
> to investigate ipojo. And thanks for link [1] - Christian Schneider is asking
> exactly the same question as I am, in Feb 2014. Sadly Felix Meshberger's
> reply is clear : not supported in DS. I don't yet understand why some people
> think this is important (Christian, myself for example) while others don't.
> See https://mail.osgi.org/pipermail/osgi-dev/2014-February/004295.html and
> the followup emails.
>
> The Felix-DM CompositionManager example you linked to looks very interesting,
> thanks. Unfortunately javadoc for "Component.setComposition" is pretty
> unhelpful. As far as I can tell, the "composition" feature allows a developer
> to define in DM:
> * a single Component
> * with all the dependencies that need to be injected into it
> except that
> * instead of DM instantiating a single object when the dependencies are met,
> it invokes a factory method that returns a collection of objects, and
> * instead of injection of these dependencies being performed on a single
> object, it is performed on the collection of objects
> Have I understood? If so, that is interesting but not AFAICT what I am
> looking for.
>
> While searching for info on "composition", I came across
> http://de.slideshare.net/mfrancis/the-ultimate-dependency-manager-shoot-out-x-uiterlinden-s-mak
> . In particular, slide 19 talks about support in ipojo for "intra-bundle
> mechanism" and "scoped service registry" which look exactly like what I am
> missing in DS. Sadly, the topic isn't mentioned again in the slideshow.
> However searching for those terms led me to this page:
> *
> http://felix.apache.org/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-composition-tutorial.html
>
> And this section from the ipojo "composition" documentation (which appears to
> be not related to the felix-dm composition feature) is exactly what I think
> is missing from DS/DM:
> > OSGi defines only one service registry, accessible by any bundles. iPOJO
> > splits these two interaction types. Instances receive an iPOJO Bundle
> > Context delegating bundle-related methods to the "regular" bundle context,
> > and service-related methods to a service context. This service context
> > can access to the OSGi service registry or to a new one. Each composition
> > instances have a service registry.
>
> I'm not so concerned about "too many services in the registry" as I am about
> *bundle-private* services being present in the global registry.
>
> Do you see any reason why DM and DS could not adopt the same approach as
> iPojo, ie a per-composition (or at least per-bundle) service registry? I
> could imagine the following enhancement for DS:
> <component>
> <service>
> <provide interface="..." scope="local"/>
> where the new "scope" attribute indicates that this particular component
> should be placed into the per-bundle service registry rather than the global
> one. All <reference> elements would then look first in the per-bundle
> registry before looking in the global one.
>
> For DM, something similar could be done with:
> createComponent().setInterface("..", Scope.LOCAL)
>
> Maybe another solution is to take advantage of felix-dm's ability to define
> "dependency handlers", and add another kind of dependency called "local" or
> similar? [as suggested by Karl Pauls in the email pointed out by Pierre]
>
> All opinions gratefully accepted!
>
> Regards, Simon
>
> On 05/22/2015 08:34 AM, Pierre De Rop wrote:
>> Hello Simon,
>>
>> DM, like DS does not implement a private service registry to intra-bundle
>> components (well, except for optimized DM filter indices, but this is
>> another story).
>>
>> I think Ipojo do support what you are describing, but I prefer to let other
>> people respond about this since I'm not enough experienced in iPojo. See
>> [1] about this, which comes from the osgi mailing list.
>>
>> Now, I tend to agree with Neil, and intra-bundle private services can
>> simply be instantiated with the "new" keyword.
>> Alternatively, with DM, you can also use a composition of service
>> components: this allows you to:
>>
>> - only register one single service for the bundle in the OSGi service
>> registry (or even only one DM component if it does not provide any services
>> at all, but just needs to define some dependencies to external services
>> (outside the bundle).
>>
>> - and define a composition of objects that will get injected with the
>> external services.
>> For example, you can take a look at [2] for a concrete sample code of a
>> bundle which defines a component that is instantiated using a
>> "CompositionManager" pojo that is first injected with a configuration. And
>> from the configuration, the pojo may then create an implementation for the
>> service that the bundle provides, and also, some other pojo objects that
>> are part of the service implementation. The pojos will then be injected
>> with all the external service dependencies defined in the Activator (either
>> using field injection of bind method callbacks).
>>
>> There is also another example which does not use a Factory, but only a
>> service composition in [3].
>>
>> Finally, I would like to say that it's a not a real problem to have many
>> services registered in the Osgi service registry.
>> Registering services is cheap. And DM now supports an actor based thread
>> model which allows to activate, manage, and bind service components
>> concurrently, using a shared threadpool, and there is no startup time
>> degradation (I often start around 20000 services and my Felix Framework
>> starts in few of seconds). The new thread model is descriped in [4].
>>
>> Also, regarding service diagnostics, even if you have thousands of micro
>> services registered in the OSGi registry, then DM gogo shell supports
>> advanced commands that allows you to quickly make some diagnostics (like
>> loop detection, missing service root causes, service lookup using filters,
>> etc ...).
>>
>> [1] https://mail.osgi.org/pipermail/osgi-dev/2014-February/004310.html
>> [2]
>> http://svn.apache.org/viewvc/felix/trunk/dependencymanager/org.apache.felix.dependencymanager.samples/src/org/apache/felix/dependencymanager/samples/compositefactory/
>> [3]
>> http://svn.apache.org/viewvc/felix/trunk/dependencymanager/org.apache.felix.dependencymanager.samples/src/org/apache/felix/dependencymanager/samples/composite/
>> [4]
>> http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager/reference/thread-model.html
>>
>> kind regards;
>> /Pierre
>>
>> On Thu, May 21, 2015 at 4:52 PM, Simon Kitching <si...@vonos.net> wrote:
>>
>>> Hi,
>>>
>>> In blueprint it is possible to define arbitrary objects (beans) which are
>>> not published to the service registry but nevertheless can be injected into
>>> other beans.
>>>
>>> AFAICT, in both declarative-services and felix-dm, the only objects that
>>> can be injected are references to services from the OSGi registry. Is this
>>> correct?
>>>
>>> I understand that with DS and DM, components follow the standard OSGi
>>> lifecycles, in contrast to the Blueprint approach of "hiding" the
>>> lifecycle. In particular, in DS and DM when a component's mandatory
>>> dependency is deregistered then the component is also deregistered (which
>>> can cascade further). And the kind of tracking of dependencies required to
>>> make this happen is exactly what a service registry does.
>>>
>>> However it's common for a bundle to have objects which are purely internal
>>> implementation details of the bundle, and are not for external use. Yet as
>>> far as I can see, in order to manage them with DS or DM, such internal
>>> objects need to be published into the global service registry - just to be
>>> able to then inject them back into components in the same bundle.
>>>
>>> Have I misunderstood something?
>>>
>>> Thanks,
>>> Simon
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
