Hello !
Thanks a lot for the very detailed explanation.
FYI, I finally found a rather simple way to trick Liquibase behavior,
excluding it from the activated bundles :
@Override
protected String getBundleFilter() {
// Avoid executing Liquibase as a bundle and fails after on
FrameworkUtil.
return "(!(Bundle-SymbolicName=org.liquibase.core))";
}
This way, Liquibase is running as a simple jar in the classpath and it
seems to work as expected in unit tests.
Back to Felix connect vs Pax Exam : is there any way to switch to
another OSGi implementation in CamelBlueprintTestSupport ? As I said,
the calls to FrameworkUtil in our code are not critical and do not
make our tests fail, but perhaps someday another dependency like
Liquibase may actually expect a bundle and can't be excluded as I did.
Anyway I'm going to have a look at Pax Exam and bndrun...
Thanks again.
Regards.
Le jeu. 2 févr. 2023 à 06:52, Grzegorz Grzybek <gr.grzy...@gmail.com> a écrit :
>
> Hello
>
> CamelBlueprintTestSupport is a class to support with OSGi/Blueprint tests,
> but in quite limited manner.
>
> The most important thing is that the bundles available during the test are
> not installed in normal OSGi framework and none of the bundles has its own
> classloader.
> Historically something called PojoSR (Plain Old Java Object Service
> Registry) was used and now it's something called Felix Connect - an
> implementation of OSGi Connect specification
> <https://docs.osgi.org/specification/osgi.core/8.0.0/framework.connect.html>
> .
>
> When thinking about proper OSGi framework as two crucial parts:
> - module layer dealing with bundles, headers, isolation, classloaders,
> revisions, wirings, wires, capabilities, requirements
> - service layer dealing with service registry, service registrations,
> service references, service trackers
>
> you should think about Felix Connect (and in consequence also
> CamelBlueprintTestSupport tests) as OSGi runtime without module layer.
>
> That's why FrameworkUtil.getBundle doesn't work because the classloader of
> given class is not an implementation of BundleReference - it's usually
> AppClassLoader from system.
>
> Why? Because if you want to properly test actual, complex (relying on
> module layer) bundles (like liquibase or even JPA/Aries/Hibernate), you
> HAVE TO use Pax Exam or bndrun.
>
> So this is indeed a limitation, but as you can see, it's quite powerful -
> lots of blueprint based (thus the name) tests work, because Blueprint
> relies more on the service layer.
>
> I hope this helps.
>
> regards
> Grzegorz Grzybek
>
> śr., 1 lut 2023 o 17:19 Ephemeris Lappis <ephemeris.lap...@gmail.com>
> napisał(a):
>
> > Hello.
> >
> > I've observed that tests based on CamelBlueprintTestSupport have a
> > strange OSGi context : the "FrameworkUtil" class doesn't work as
> > expected and returns null.
> >
> > For some parts of our application code, where optional information is
> > not required, we can handle the null value. But we can't do it for
> > example for Liquibase that detects the OSGi context, but fails reading
> > bundle information.
> >
> > Here is the code of Liquibase that fails :
> >
> > Boolean osgiPlatform =
> > Scope.getCurrentScope().get(Scope.Attr.osgiPlatform, Boolean.class);
> > if (Boolean.TRUE.equals(osgiPlatform)) {
> > Bundle bundle =
> > FrameworkUtil.getBundle(LiquibaseUtil.class);
> > URL propURL =
> > bundle.getEntry("liquibase.build.properties");
> >
> > As the returned bundle is null, Liquibase fails, and all the
> > application code too.
> >
> > Could someone explain why the OSGi context of the test fails
> > retrieving bundles, while it seems to work for all the rest ?
> >
> > Can we do something in the test setting to enable the expected behavior ?
> >
> > Thanks in advance for explanations and help !
> >
> > Regards.
> >
