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 > >
