felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil Bartlett <njbartl...@gmail.com>
Subject Re: DS and .. Fragments (not)?
Date Wed, 18 Nov 2015 12:38:08 GMT
Fragments are not allowed to declare the Service-Component header (or
rather, if they do it will be ignored by SCR). It is however possible for
the DS XML and/or classes to be located in fragments, so long as the
Service-Component header is declared on the host bundle. So that may be one
route.

Why not follow a composition approach rather than inheritance? You could
have a single aggregator component that is injected with all the various
services, and is then published as a service. Each of your smaller
components can then inject the aggregate service component.

Neil

On Wed, Nov 18, 2015 at 12:23 PM, Benson Margulies <benson@basistech.com>
wrote:

> Thanks to all of you who educated me yesterday about DS annotation
> inheritance in bnd. I implemented it and it works very well. However,
> I have an incremental challenge.
>
> What I have here is a gaggle of web services. Most of the logic is
> common across them and lives in a base class, which now has @Reference
> injection to pick up things it needs from the larger environment, and
> activate/deactivate to manage lifecycle.
>
> However, I'd like to enable these services to come from disparate
> teams. Given the injunction to avoid cross-bundle inheritance of the
> DS annotations, I can't just export the package containing the base
> class from one bundle and then tell the teams to import and inherit.
>
> It only took about five minutes to think of the idea of putting each
> service in a fragment -- and then discard it, due to the fact that
> fragments can't carry DS metadata (according to Stack Overflow).
>
> Is there another trail to follow here, or is there just an inescapable
> dilemma between repeating DS annotations and decoupling the pieces?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message