Hi
czw., 2 lut 2023 o 09:16 Ephemeris Lappis <ephemeris.lap...@gmail.com>
napisał(a):
> 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.
>
Cool that it worked ;)
>
> Back to Felix connect vs Pax Exam : is there any way to switch to
> another OSGi implementation in CamelBlueprintTestSupport ?
>
No. There are kind of 3 implementations I'd consider:
- full Felix
- full Equinox
- Felix connect (no module layer)
So if you switch to Felix/Equinox (Pax Exam supports them both) you're
effectively switching to Pax Exam.
> 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.
>
"New" FrameworkUtil (from OSGi Core 8) is more clever as it doesn't simply
checks `class.getClassLoader() instanceof BundleReference)` - it uses
/META-INF/services/org.osgi.framework.connect.FrameworkUtilHelper service
discover, so you could hook your own helper.
>
> Anyway I'm going to have a look at Pax Exam and bndrun...
>
Start with Pax Exam and check these sources:
-
https://github.com/apache/karaf/tree/main/itests/test/src/test/java/org/apache/karaf/itests
(pax-exam-container-karaf)
-
https://github.com/ops4j/org.ops4j.pax.web/tree/main/pax-web-itest/pax-web-itest-container/pax-web-itest-container-common/src/main/java/org/ops4j/pax/web/itest/container
(pax-exam-container-native)
regards
Grzegorz Grzybek
> 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.
> > >
>
