Liquibase 4.4.3 doesn't work under OSGI (Karaf 4.3.2)

[jherkel]

Environment

Liquibase Version: 4.4.3

Liquibase Integration & Version: OSGI (Fedora 34, Karaf 4.3.3, JDK 11)

Description

We currently use liquibase 3.8.0 and would like to migrate to the latest version (4.4.3). But I found out some problems:

1. Now liquibase uses ServiceLoader for loading their internal/external extensions and it needs special OSG headers (see http://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.loader.html). It can be done via updating of MANIFEST.MF or dynamically within features.xml via wrap protocol.
2. Problem with liquibase.build.properties. It is located under "default" package (root). This a little bit problematic location from OSGI point of view. It can be fixed with bundle.getEntry("liquibase.build.properties");
3. Problem with classloading in CustomChangeWrapper. This also can be fixed with (CustomChange)bundle.loadClass(className).getConstructor().newInstance();

With these changes I was able to load liquibase as bundle and also was able to execute all our migration scripts. I will also prepare PR for these changes so someone can better imagine what I had to change.

Steps To Reproduce

install and try liquibase under karaf 4.3.2

Actual Behavior

Liquibase doesn't work

[jherkel]

I have a running version of liquibase but I can see one problematic point in my patch. As I extended classes/resources loading with OSGI way I also created hard dependency to OSGI what is wrong. What do you think about idea that the classloading stuffs could be separated? I'm thinking about something like OSGIResourceAccessor. Or maybe someone can suggest a better way how to solve problems from points 2 and 3.

[molivasdat]

Hi @jherkel Thanks for creating this issue. Can you add a few more details on how to recreate this? Glad that you have a PR coming. If that is faster to create the PR, that would be great but will still need a re-creatable scenario to test the fix. We can then add it to the list of issues we are processing.

[jherkel]

I will try to prepare a test project based on the latest Karaf. I have source code that works but now it is just an "idea" how problem can be solved and not a "real" PR. But I can create PR (not for merge) because someone could find a better way how to solve problem with classloading under OSGI.

[jherkel]

liquibase-osgi-test.zip
Steps to reproduce:

1. download Apache Karaf 4.3.3
2. copy org.ops4j.datasource-test.cfg to "karaf unpack dir"/etc
3. unpack and build liquibase-osgi-test (mvn clean install)
4. start karaf via ./karaf debug clean
5. execute commands in karaf console:

bundle:install -s mvn:com.h2database/h2/1.4.200
feature:install jdbc (you can check if datasource is ready via service:list DataSource)
feature:install aries-blueprint
bundle:install -s mvn:org.apache.aries.spifly/org.apache.aries.spifly.dynamic.bundle/1.3.4
bundle:install -s mvn:org.liquibase/liquibase-core/4.4.3
bundle:install -s mvn:test.test/liquibase-osgi-test/0.1.0-SNAPSHOT

6. execute command

liquibase-update

After execution of command 6) you can see this error:
Execute liquibase updateError executing command: java.lang.ExceptionInInitializerError
and when you type 'display' you can see exception:

Caused by: liquibase.exception.UnexpectedLiquibaseException: Cannot find default log service
	at liquibase.Scope.getCurrentScope(Scope.java:81) ~[?:?]
	at liquibase.database.DatabaseFactory.<clinit>(DatabaseFactory.java:20) ~[?:?]
	at test.LiquibaseUpdateCommand.executeUpdate(LiquibaseUpdateCommand.java:54) ~[?:?]
	at test.LiquibaseUpdateCommand.execute(LiquibaseUpdateCommand.java:41) ~[?:?]
	at org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.

Now you can stop karaf with 'halt' command

If you want to check my patch you need to change liquibase version in pom.xml (mvn clean install) and change version of liquibase in command 5 (bundle:install -s mvn:org.liquibase/liquibase-core/4.5.0-local-SNAPSHOT)

[driessamyn]

I also ran into the "Cannot find default log service" error in an OSGi project (not using Karaf), and can confirm that the patch in the above PR resolve this issue.