Christoph,
Thanks for clarifying this question against the original version, but I think you still need to state why the third class cannot be created via something like DS.
DS causes components to be published as services, therefore the only way to "get" any component from DS is to access it via the service registry. Unfortunately the service registry can be hard to use correctly using the lower level APIs because it is dynamic, so you have to cope with the possibility of services going away or not being available at precisely the moment you want them to be available, and so on. This is why DS exists: it gives you an abstraction for depending on services and managing the lifecycle of your components based on the availability of services that they reference.
If you really need to access a service without using DS or something like it (and there is quite a choice of "things like it" e.g. Spring-DM, iPOJO, Guice/Peaberry, etc) then you should use ServiceTracker. I agree there is a lot of overhead -- again, this is why DS exists instead.
To answer your suggestion no (2), no you should not create your own registry of services because the service registry already exists. If you created a separate parallel registry then you would still have to handle all the dynamics, but you would have to handle it in two places instead of one. The same applies to suggestion (3).
I hope this helps.
Regards,
Neil
UPDATED: Incidentally, although Spring has the Container.getBean() backdoor, you notice that in all Spring documentation it is strongly recommended not to use that backdoor: to get hold of a Spring bean, just create another bean that references it. The same applies to DS, i.e. the best way to get hold of a DS component is to create another DS component.
Also note that in the OSGi world, even if you're using Spring-DM there is no easy way to just call getBean() because you need to get hold of the Spring ApplicationContext first. That is itself an OSGi service, so how to you get that service?
From Spring Documentation:
The @Repository
annotation is a marker for any class that fulfils the
role or stereotype of a repository (also known as Data Access Object
or DAO). Among the uses of this marker is the automatic translation of
exceptions, as described in Exception Translation.
Spring provides further stereotype annotations: @Component
, @Service
,
and @Controller
. @Component
is a generic stereotype for any
Spring-managed component. @Repository
, @Service
, and @Controller
are
specializations of @Component
for more specific use cases (in the
persistence, service, and presentation layers, respectively).
Therefore, you can annotate your component classes with @Component
,
but, by annotating them with @Repository
, @Service
, or @Controller
instead, your classes are more properly suited for processing by tools
or associating with aspects.
For example, these stereotype annotations
make ideal targets for pointcuts. @Repository
, @Service
, and
@Controller
can also carry additional semantics in future releases of
the Spring Framework. Thus, if you are choosing between using
@Component
or @Service
for your service layer, @Service
is clearly the
better choice. Similarly, as stated earlier, @Repository
is already
supported as a marker for automatic exception translation in your
persistence layer.
Annotation |
Meaning |
@Component |
generic stereotype for any Spring-managed component |
@Repository |
stereotype for persistence layer |
@Service |
stereotype for service layer |
@Controller |
stereotype for presentation layer (spring-mvc) |
Best Answer
This is a very good question so I digged into the specification in search for a definitive answer. It turns out that there is a whole section talking about this problem - see section 5.4 Stale References starting on page 132 of OSGi Service Platform Core Specification, Release 4, Version 4.2.
To answer your question according to the specification:
And to prevent potential problems:
The specification also gives some tips how to minimize the consequences of stale references.