If you use blueprint in testing set timeouts just very high. That should take
care of most of these problems.
Kind regards,
Peter Kriens
> On 13 jan. 2015, at 03:28, Raymond Auge <[email protected]> wrote:
>
>
>
> On Mon, Jan 12, 2015 at 8:52 PM, Neil Bartlett <[email protected]
> <mailto:[email protected]>> wrote:
> What kind of “friendly” Blueprint behaviour are you looking for? Since you
> specified effective:=active on your R-C header, it will always be ignored by
> the OSGi Framework itself.
>
> Ok got it! I had inkling of that but wasn't 100% sure.
>
> So I assume you’re thinking about tooling, like the resolve panel in Bndtools?
>
> Actually no! I'm thinking runtime.. I'm just suffering some blueprint pains
> and trying to get clever.
>
>
> You can of course write Require-Capability headers exactly like this if you
> wish. Also in theory we could get bnd to generate them by reading the
> blueprint XML files. Currently bnd doesn’t do this, but we once did something
> similar in repoindex for DS-based bundles, the principle being pretty much
> the same.
>
> However this turned out to create more problems than it solved. If we resolve
> the osgi.service namespace then it forces the required service to be provided
> in the *same* framework.
>
> The issue we're having is just blueprint's overall fragility when it comes to
> throwing arbitrary delays into the lifecycle. DS just handles this
> gracefully, but BP is just a very spoiled brat here and screws everything up
> for everyone if it doesn't get exactly what it wants when it wants it.
>
> So integration tests randomly fail unrelated to the tests code simply because
> occasionally the pressure induced by the test causes a delay in blueprint's
> init... some service is delayed beyond it's timeout.
>
> .. just a pain.
>
>
> However we might want to provide it from a remote framework using Remote
> Services Admin. For this reason Bndtools has an option to ignore the
> osgi.service namespace, treating it as non-effective, as follows:
>
> -resolve.effective: active; skip:="osgi.service"
>
> Regards,
> Neil
>
>
> > On 13 Jan 2015, at 00:36, Raymond Auge <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> > Hey All,
> >
> > I have a (hopefully not completely stupid) question about blueprint and
> >
> > Require-Capability: osgi.service;filter:="(...)";effective:=active
> >
> > Could blueprint be made to behave a little more friendly by using a
> > require-cap on a service which the blueprint context depends on?
> >
> > - Ray
> > _______________________________________________
> > OSGi Developer Mail List
> > [email protected] <mailto:[email protected]>
> > https://mail.osgi.org/mailman/listinfo/osgi-dev
> > <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected] <mailto:[email protected]>
> https://mail.osgi.org/mailman/listinfo/osgi-dev
> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>
>
> --
> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
> _______________________________________________
> 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
