Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Steinar Bang :

> Heh... looking at the karaf.log of the integration test, it seems to actually 
> work:
>  
> https://gist.github.com/steinarb/445699fc4277c36a0f9b94a799da69b1#file-karaf-log-L415

> But the "No common superclass" still happens, prior to the place where
> it starts working
>  
> https://gist.github.com/steinarb/445699fc4277c36a0f9b94a799da69b1#file-karaf-log-L325

> And there are lots of stack traces happening during the shutdown...
>  
> https://gist.github.com/steinarb/445699fc4277c36a0f9b94a799da69b1#file-karaf-log-L438

Soo... I've merged all of the successful changes I've made so far, into
master, and have pushed master.

This is because the way it is now, is probably working for a normal
application.

Still, I will keep at it for a while, seeing if it is possible to lose
the stacktraces.

First thing to try is newer versions of liquibase 4.x.

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Steinar Bang :

>>> (I noticed I've added an empty
>>> src\main\resources\META-INF\servicesliquibase.license.LicenseService as
>>> well, maybe that fixes the encryption exception)

>> Ah! Thanks again!  I'll try that!

Heh... looking at the karaf.log of the integration test, it seems to actually 
work:
 
https://gist.github.com/steinarb/445699fc4277c36a0f9b94a799da69b1#file-karaf-log-L415

But the "No common superclass" still happens, prior to the place where
it starts working
 
https://gist.github.com/steinarb/445699fc4277c36a0f9b94a799da69b1#file-karaf-log-L325

And there are lots of stack traces happening during the shutdown...
 
https://gist.github.com/steinarb/445699fc4277c36a0f9b94a799da69b1#file-karaf-log-L438

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Steinar Bang :
> Steven Huypens :

>> (I noticed I've added an empty
>> src\main\resources\META-INF\servicesliquibase.license.LicenseService as
>> well, maybe that fixes the encryption exception)

> Ah! Thanks again!  I'll try that!

Didn't help, unfortunately.  So I'll keep debugging and see if I can
find out which keyAndAliases value that makes the difference.

But as you pointed out there are some liquibase pro classes in the stack
trace, and these classes are in the liquibase-core jar, but look like
obfuscated code and contains no source code in the source jar.

So debugging below AbstractMapConf.getProvidedValue() is hard.

Also things seems to work as expected when debugging (aka "heisenbug"),
so I suspect there are some race condition(s) involved.

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Steven Huypens :

> Hi Steinar,
> May I suggest you re-open/recreate the issue on the Liquibase bugtracker ?

I'd rather create a new issue suggesting a more OSGi-approach:
 1. Define all of the service interfaces in a separate osgi bundle
 2. Instead of using ServiceLoader through the mediator service, create
OSGi components exposing the services that then can be injected into
user components

But I fear that this would sound too drastic to the liquibase people, so
that will be rejected out of hand.

In this scenario the parser(s) would be created inside the liquibase
bundle, and would be able to find the XSD files.

(Hm... can DS components be created in an OSGi fragment bundle? Or are
those code only? If so this could be done outside of the liquibase
project)

> Meanwhile you can build your own liquibase-core bundle using a pom.xml like
> below, you simple add your own version of
> src/main/java/liquibase/parser/core/xml/LiquibaseEntityResolver.java to the
> project

Building my own version of liquibase-core would be the last resort.

And I think that if I build my own version of liquibase-core, it would
be to be able to expose the liquibase services as OSGi services, the way
I've outlined above.

> (I noticed I've added an empty
> src\main\resources\META-INF\servicesliquibase.license.LicenseService as
> well, maybe that fixes the encryption exception)

Ah! Thanks again!  I'll try that!

(I'm pretty close to get it working now... debugging exactly when the
exception happens is what I was doing now. Logging still isn't quite
right, but that is next)

Re: Problems with logging to karaf.log from liquibase >3

[Steven Huypens]

Hi Steinar,

May I suggest you re-open/recreate the issue on the Liquibase bugtracker ?

Meanwhile you can build your own liquibase-core bundle using a pom.xml like
below, you simple add your own version of
src/main/java/liquibase/parser/core/xml/LiquibaseEntityResolver.java to the
project

(I noticed I've added an empty
src\main\resources\META-INF\servicesliquibase.license.LicenseService as
well, maybe that fixes the encryption exception)

--
--

http://maven.apache.org/POM/4.0.0; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="
http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0
your.domain.org.liquibase
liquibase-core
bundle
4.9.1.1-SNAPSHOT




4.9.1




org.liquibase
liquibase-core
${liquibase.version}






org.apache.maven.plugins
maven-release-plugin
3.0.0-M5


org.apache.felix
maven-bundle-plugin
5.1.4
true



liquibase.osgi.Activator
${project.name}

${project.groupId}.${project.artifactId}

javax.activation*;resolution:=optional,

javax.servlet.*;version="[2.6,4)";resolution:=optional,
javax.sql.*,
org.osgi.*,
org.yaml.snakeyaml.*,
*;resolution:=optional


liquibase.*;version="${liquibase.version}",


liquibase-core;inline=true

{maven-resources},
{maven-dependencies},
liquibase=target/classes/liquibase


osgi.serviceloader;
osgi.serviceloader=liquibase.serializer.ChangeLogSerializer,
osgi.serviceloader;
osgi.serviceloader=liquibase.parser.NamespaceDetails,
osgi.serviceloader;
osgi.serviceloader=liquibase.database.Database,
osgi.serviceloader;
osgi.serviceloader=liquibase.change.Change,
osgi.serviceloader;
osgi.serviceloader=liquibase.database.DatabaseConnection,
osgi.serviceloader;
osgi.serviceloader=liquibase.precondition.Precondition,
osgi.serviceloader;
osgi.serviceloader=liquibase.serializer.SnapshotSerializer,
osgi.serviceloader;
osgi.serviceloader=liquibase.configuration.AutoloadedConfigurations,
osgi.serviceloader;
osgi.serviceloader=liquibase.diff.DiffGenerator,
osgi.serviceloader;
osgi.serviceloader=liquibase.lockservice.LockService,
osgi.serviceloader;
osgi.serviceloader=liquibase.changelog.ChangeLogHistoryService,
osgi.serviceloader;
osgi.serviceloader=liquibase.datatype.LiquibaseDataType,
osgi.serviceloader;
osgi.serviceloader=liquibase.configuration.ConfigurationValueProvider,
osgi.serviceloader;
osgi.serviceloader=liquibase.logging.LogService,
osgi.serviceloader;
osgi.serviceloader=liquibase.snapshot.SnapshotGenerator,
osgi.serviceloader;
osgi.serviceloader=liquibase.parser.ChangeLogParser,
osgi.serviceloader;
osgi.serviceloader=liquibase.servicelocator.ServiceLocator,
osgi.serviceloader;
osgi.serviceloader=liquibase.diff.compare.DatabaseObjectComparator,
osgi.serviceloader;
osgi.serviceloader=liquibase.command.LiquibaseCommand,
osgi.serviceloader;
osgi.serviceloader=liquibase.license.LicenseService,
osgi.serviceloader;
osgi.serviceloader=liquibase.diff.output.changelog.ChangeGenerator,
osgi.serviceloader;
osgi.serviceloader=liquibase.executor.Executor,
osgi.serviceloader;
osgi.serviceloader=liquibase.structure.DatabaseObject,
osgi.serviceloader;
osgi.serviceloader=liquibase.parser.SnapshotParser,
osgi.serviceloader;
osgi.serviceloader=liquibase.hub.HubService,
osgi.serviceloader;

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Steven Huypens :

> Hi Steinar,
> The xsd stacktrace can be explained by this liquibase-issue I think :
> https://github.com/liquibase/liquibase/issues/2817

> They closed it incorrectly imho

The "fix" was just changed wording in the exception message...? (unless
I'm missing something...?

If so, then I agree with you.

I know from googling that Nathan Woxland is reluctant to making XML
parsing not requiring validation (a stack overflow answer from 2010, I
think it was), so not requiring XSDs is not an option.

I have managed to make a workaround/hackaround, by slurping the
offending XSD file out of liquibase-core:
 
https://gist.github.com/steinarb/96840701be3aa387f670b191f44ac14d#file-pom-xml-L164
and then adding it to the resource classpath of the bundle liquibase is
executed from
 
https://gist.github.com/steinarb/96840701be3aa387f670b191f44ac14d#file-pom-xml-L157
(liquibase looks in www.liquibase.org/xml/ns/dbchangelog/ on the
classpath, for the XSD files)

But with the additional require-capability
 
https://gist.github.com/steinarb/96840701be3aa387f670b191f44ac14d#file-pom-xml-L127
it does feel to me, like liquibase 4.x isn't very OSGi friendly... all
of this have to be done in the build config for every bundle that is to
run liquibase...

Oh well!

Re: Problems with logging to karaf.log from liquibase >3

[Steven Huypens]

Hi Steinar,

The xsd stacktrace can be explained by this liquibase-issue I think :
https://github.com/liquibase/liquibase/issues/2817

They closed it incorrectly imho

Kind regards,
Steven

On Sun, Aug 14, 2022 at 8:31 AM Steinar Bang  wrote:

> > Steven Huypens :
>
> > 1) The exception "No Common Superclass:javax/crypto/SecretKey
> > javax/crypto/SecretKeyFactory" is from the liquibase pro package, as
> > you can see in the stacktrace. But I do not understand that, because
> > that package is not part of the 4.9.1 liquibase-core.jar. It might be
> > however that we are not seeing that error because we do not use the
> > Liquibase class.
>
> Thanks for the info.
>
> I'd put that one off for later, since it didn't seem to affect the rest
> of the operation.  So I hadn't studied it closesly.
>
> Maybe it'll disappear when I stop using the Liquibase class...? :-)
>
> > 2) The XSDLookUpException is because liquibase cannot find the xsd's
> > located in liquibase-core-4.9.1.jar\www.liquibase.org
> \xml\ns\dbchangelog,
> > it's a classLoader issue I guess.
>
> Yep! The OSGi class loader only loads classes from other bundles. All
> resources are local bundle only.
>
> I've actually used that to good effect in bundles where I've used
> Liquibase, but I've landed on having each project having its own unique
> file naming, when I had to load two liquibase-loading bundles as normal
> jar files in a unit test, and the changelog files suddenly
> overlapping...
>
> > 3) The spifly startlevel seems to be important indeed. Since I lowered
> it's
> > startLevel in our own code, the exception did not occur anymore.
>
> Yep!
>
> > 4) I don't know which approach you're supposed to use, sorry.
>
> I'll figure it out eventually, I'm too stubborn to give up. :-)
>
> > 5) fyi, I'm using this to assert the exception. Maybe it's useful for you
> > as well ..
>
> > Stream lines = Files.lines(Paths.get("data/log/karaf.log"));
> > lines.forEach(l -> System.out.println(l));
> > Assert.assertFalse(lines.anyMatch(line -> line.contains("Exception")));
>
> Ah! Clever! Thanks for the tip!
>
>

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Steven Huypens :

> 1) The exception "No Common Superclass:javax/crypto/SecretKey
> javax/crypto/SecretKeyFactory" is from the liquibase pro package, as
> you can see in the stacktrace. But I do not understand that, because
> that package is not part of the 4.9.1 liquibase-core.jar. It might be
> however that we are not seeing that error because we do not use the
> Liquibase class.

Thanks for the info.

I'd put that one off for later, since it didn't seem to affect the rest
of the operation.  So I hadn't studied it closesly.

Maybe it'll disappear when I stop using the Liquibase class...? :-)

> 2) The XSDLookUpException is because liquibase cannot find the xsd's
> located in liquibase-core-4.9.1.jar\www.liquibase.org\xml\ns\dbchangelog,
> it's a classLoader issue I guess.

Yep! The OSGi class loader only loads classes from other bundles. All
resources are local bundle only.

I've actually used that to good effect in bundles where I've used
Liquibase, but I've landed on having each project having its own unique
file naming, when I had to load two liquibase-loading bundles as normal
jar files in a unit test, and the changelog files suddenly
overlapping...

> 3) The spifly startlevel seems to be important indeed. Since I lowered it's
> startLevel in our own code, the exception did not occur anymore.

Yep!

> 4) I don't know which approach you're supposed to use, sorry.

I'll figure it out eventually, I'm too stubborn to give up. :-)

> 5) fyi, I'm using this to assert the exception. Maybe it's useful for you
> as well ..

> Stream lines = Files.lines(Paths.get("data/log/karaf.log"));
> lines.forEach(l -> System.out.println(l));
> Assert.assertFalse(lines.anyMatch(line -> line.contains("Exception")));

Ah! Clever! Thanks for the tip!

Re: Problems with logging to karaf.log from liquibase >3

[Steven Huypens]

Hi Steinar,

1) The exception "No Common Superclass:javax/crypto/SecretKey
javax/crypto/SecretKeyFactory" is from the liquibase pro package, as you
can see in the stacktrace. But I do not understand that, because that
package is not part of the 4.9.1 liquibase-core.jar. It might be however
that we are not seeing that error because we do not use the Liquibase class.

2) The XSDLookUpException is because liquibase cannot find the xsd's
located in liquibase-core-4.9.1.jar\www.liquibase.org\xml\ns\dbchangelog,
it's a classLoader issue I guess.

3) The spifly startlevel seems to be important indeed. Since I lowered it's
startLevel in our own code, the exception did not occur anymore.

4) I don't know which approach you're supposed to use, sorry.

5) fyi, I'm using this to assert the exception. Maybe it's useful for you
as well ..

Stream lines = Files.lines(Paths.get("data/log/karaf.log"));
lines.forEach(l -> System.out.println(l));
Assert.assertFalse(lines.anyMatch(line -> line.contains("Exception")));

On Sat, Aug 13, 2022 at 12:02 PM Steinar Bang  wrote:

> > Steinar Bang :
>
> > Hm... I removed the liquibase-slf4j bundle from the feature.xml and then
> > I got a different karaf.log
> >  https://gist.github.com/steinarb/c04967029621509053f0b6c5903f5fcf
>
> The important stack trace here, is:
>
> https://gist.github.com/steinarb/fe342779dfe50b82345e9ac04718f17d#file-karaf-log-L433
>
> This is because of the way I'm using the Liquibase Java API and because
> the Liquibase.update() operation creates a new scope from the root
> scope, when there already is a scope, and that doesn't work.
>
> Possibly releated to this open liquibase issue...? (I googled the error
> message)
>  https://github.com/liquibase/liquibase/issues/2248
>
> My approach worked for liquibase 3.x, but I have to rethink what to do
> for liquibase 4.x (I don't feel like waiting until issue 2248 is fixed).
> Maybe look at Steven's pseudi code?
>
>

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Steinar Bang :

> Hm... I removed the liquibase-slf4j bundle from the feature.xml and then
> I got a different karaf.log
>  https://gist.github.com/steinarb/c04967029621509053f0b6c5903f5fcf

The important stack trace here, is:
 
https://gist.github.com/steinarb/fe342779dfe50b82345e9ac04718f17d#file-karaf-log-L433

This is because of the way I'm using the Liquibase Java API and because
the Liquibase.update() operation creates a new scope from the root
scope, when there already is a scope, and that doesn't work.

Possibly releated to this open liquibase issue...? (I googled the error message)
 https://github.com/liquibase/liquibase/issues/2248

My approach worked for liquibase 3.x, but I have to rethink what to do
for liquibase 4.x (I don't feel like waiting until issue 2248 is fixed).
Maybe look at Steven's pseudi code?

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Steinar Bang :

>> What I was trying to tell you, is that by replacing your
>> spifly-feature with the aries-proxy-feature and a single spifly
>> bundle, the classloading issue might be fixed. Liquibase is able to
>> find the Default Log Service, as far as I can see.

> Ahhh! I see!

I eventually figured out the difference (I think...?): you're starting
the spifly bundle on level 40, which is the same level as the
liquibase-feature is on, and using the spifly feature, the spifly bundle
is started on the default level, which is 80, and possibly isn't present
when liquibase is running?

Other than that it seems the same bundles are started and activated in
both cases (i.e. both using the spifly feature and loading the spifly
bundle directly).

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Steinar Bang :

>> What I was trying to tell you, is that by replacing your
>> spifly-feature with the aries-proxy-feature and a single spifly
>> bundle, the classloading issue might be fixed. Liquibase is able to
>> find the Default Log Service, as far as I can see.

> Ahhh! I see!

>> I got 2 new exceptions, one of which can be ignored.If you manage to
>> fix the other exception, I think you get a little closer to the
>> solution.

> Thanks! I will try!  I'll report back in this (long) thread!

I didn't get any exceptions from liquibase pro, but I got 3 exceptions

"No Common Superclass:javax/crypto/SecretKey javax/crypto/SecretKeyFactory":
 
https://gist.github.com/steinarb/3c3ff4e570bf8c6a380343233ed1e471#file-karaf-log-L342

"liquibase.parser.core.xml.XSDLookUpException: Unable to resolve xml entity 
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.5.xsd locally: 
liquibase.secureParsing is set to 'true' which does not allow remote lookups. 
Set it to 'false' to allow remote lookups of xsd files."
 
https://gist.github.com/steinarb/3c3ff4e570bf8c6a380343233ed1e471#file-karaf-log-L439
(this one is possible fixable by disabling XSD validation...?)

java.lang.NullPointerException
 
https://gist.github.com/steinarb/3c3ff4e570bf8c6a380343233ed1e471#file-karaf-log-L535
(possibly caused by ServiceLoader not finding any services...? But that
 is guessing on my part)

Here's the feature.xml used
 https://gist.github.com/steinarb/22f4ea2e7eda7018bae0af2ad7f774df

Hm... I removed the liquibase-slf4j bundle from the feature.xml and then
I got a different karaf.log
 https://gist.github.com/steinarb/c04967029621509053f0b6c5903f5fcf

Not the "normal" error messages (e.g. "Cannot find default Log
service"), but error messages from the derby shutdown, and no logging
indicating that liquibase is actually doing anything.

Hm... I tried again, and this time it looks like liquibase failing
because the derby database has been shut down...?
 
https://gist.github.com/steinarb/fe342779dfe50b82345e9ac04718f17d#file-karaf-log-L484

And this time I again got the "No Common
Superclass:javax/crypto/SecretKey javax/crypto/SecretKeyFactory" error.

So the behaviour isn't entirely predictable with this setup...?

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Steven Huypens :

> What I was trying to tell you, is that by replacing your spifly-feature
> with the aries-proxy-feature and a single spifly bundle, the classloading
> issue might be fixed. Liquibase is able to find the Default Log Service, as
> far as I can see.

Ahhh! I see!

> I got 2 new exceptions, one of which can be ignored.If you manage to fix
> the other exception, I think you get a little closer to the solution.

Thanks! I will try!  I'll report back in this (long) thread!

Re: Problems with logging to karaf.log from liquibase >3

[Steven Huypens]

Hi Steinar,

What I was trying to tell you, is that by replacing your spifly-feature
with the aries-proxy-feature and a single spifly bundle, the classloading
issue might be fixed. Liquibase is able to find the Default Log Service, as
far as I can see.

I got 2 new exceptions, one of which can be ignored.If you manage to fix
the other exception, I think you get a little closer to the solution.

Kind regards,
Steven

On Tue, Aug 9, 2022 at 12:51 PM Steinar Bang  wrote:

> > Steven Huypens :
>
> > Hi Steinar,
> > As far as I can tell, there is a spifly-issue, which is why Liquibase
> > cannot create the correct Log Services. I tried
>
> >  > version="${liquibase.version}">
> > aries-proxy
>
> >
> mvn:org.apache.aries.spifly/org.apache.aries.spifly.dynamic.bundle/1.3.4
>
> > mvn:org.yaml/snakeyaml/${snakeyaml.version}
>
> > mvn:org.liquibase/liquibase-core/${liquibase.version}
> > 
>
> Yes, I tried to handle this by requiring the
> spifly
>
> This is what I've done in the
> liquibase-karaf-feature/use-liquibase-slf4j-410
> branch.
>
> > which leads to new exceptions. The one from Liquibase Pro can be ignored
> > for now, I guess, and the other one might be related to your
> > ResourceAccessor, Good luck, I hope this helps you a little.
>
> Thanks!
>
> The fact that I know that running liquibase 4.x in OSGi works for you,
> is my hope that it should be possible to solve this. :-)
>
> I think I know what's going on now, but what I don't know is how to fix it.
>
> When debugging the init, I saw that a JavaLogService (which implements
> the LogService interface), was created here (I put a breakpoint in the
> baseclass constructor of JavaLogService, and the breakpoint was
> triggered):
>
> https://github.com/liquibase/liquibase/blob/master/liquibase-core/src/main/java/liquibase/Scope.java#L78
>
> And then LogServiceFactory.getDefaultLogService() failed here
>
> https://github.com/liquibase/liquibase/blob/master/liquibase-core/src/main/java/liquibase/Scope.java#L85
>
> (at this point I was already thinking "possible classloader issue...?")
>
> The LogServiceFactory.getDefaultLogService() method called
> AbstractServiceFactory.getPlugin(), which returns null,
> because the ServiceLocator doesn't find any instances of LogService
>
> https://github.com/liquibase/liquibase/blob/master/liquibase-core/src/main/java/liquibase/plugin/AbstractPluginFactory.java#L98
>
> And StandardServiceLocator.findInstances(Class), used
> java.util.ServiceLoader.load() to find the instances
>
> https://github.com/liquibase/liquibase/blob/master/liquibase-core/src/main/java/liquibase/servicelocator/StandardServiceLocator.java#L21
>
> So, yep, defintely a classloader issue.
>
> The java.util.ServiceLoader is what powers the spring dependency
> injection mechanism, and definitely works best when you have a single
> classloader.
>
> So I googled "ServiceLoader osgi" and immediately found this clarifying
> (but old (february 13 2013)) blog post:
>  https://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html
>
> Liquibase is attempting to use the serviceloader.
>
> They are requiring the necessary capabilities (this is why liquibase now
> needs something like spifly, to load):
>
> https://github.com/liquibase/liquibase/blob/master/liquibase-core/pom.xml#L198
>
> And they are providing the capabilities, which should make it possible
> for a different bundle to have ServiceLoader successfully do a classpath
> scan and find the services.
>
> So to sum it up: the reason LogService isn't found is a classloader
> issue, there is a known fix, and liquibase has implemented the fix.
>
> The only problem is... I haven't been able to make it work...:-/
>
> I have tried the following:
>
> 1. Requiring the LogService feature in the maven-bundle-plugin config,
>based on the example in the feb 2013 blog post:
>   
>osgi.extender;
> filter:="(osgi.extender=osgi.serviceloader.processor)",
>
>  
> osgi.serviceloader;filter:="(osgi.serviceloader=liquibase.logging.LogService)";cardinality:=multiple
>   
>
>but that failed in the karaf feature loader, because the
>osgi.serviceloader.processor capability couldn't be found.
>
> 2. So I copied the entire  from liquibase-core
>
> https://github.com/liquibase/liquibase/blob/master/liquibase-core/pom.xml#L198
>where all of the services are provided by the liquibase-core manifest
>
> https://github.com/liquibase/liquibase/blob/master/liquibase-core/pom.xml#L169
>(the osgi.serviceloader.registrar and osgi.serviceloader.processor
>capabilities would presumably be provided by spifly, same as for the
>osgi-core itself)
>
>And this one have no load failures, but the karaf.log contains the
>dreaded "Cannot find default log service" stack trace
>
> I think that everything created inside the liquibase-core bundle itself,
> using that bundle's classloader(s), would work just fine.
>
> But Liquibase classes I instanciate in my own bundles 

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Steven Huypens :

> Hi Steinar,
> As far as I can tell, there is a spifly-issue, which is why Liquibase
> cannot create the correct Log Services. I tried

>  version="${liquibase.version}">
> aries-proxy

> mvn:org.apache.aries.spifly/org.apache.aries.spifly.dynamic.bundle/1.3.4

> mvn:org.yaml/snakeyaml/${snakeyaml.version}

> mvn:org.liquibase/liquibase-core/${liquibase.version}
> 

Yes, I tried to handle this by requiring the
spifly

This is what I've done in the liquibase-karaf-feature/use-liquibase-slf4j-410
branch.

> which leads to new exceptions. The one from Liquibase Pro can be ignored
> for now, I guess, and the other one might be related to your
> ResourceAccessor, Good luck, I hope this helps you a little.

Thanks!

The fact that I know that running liquibase 4.x in OSGi works for you,
is my hope that it should be possible to solve this. :-)

I think I know what's going on now, but what I don't know is how to fix it.

When debugging the init, I saw that a JavaLogService (which implements
the LogService interface), was created here (I put a breakpoint in the
baseclass constructor of JavaLogService, and the breakpoint was
triggered): 
 
https://github.com/liquibase/liquibase/blob/master/liquibase-core/src/main/java/liquibase/Scope.java#L78

And then LogServiceFactory.getDefaultLogService() failed here
 
https://github.com/liquibase/liquibase/blob/master/liquibase-core/src/main/java/liquibase/Scope.java#L85

(at this point I was already thinking "possible classloader issue...?")

The LogServiceFactory.getDefaultLogService() method called
AbstractServiceFactory.getPlugin(), which returns null,
because the ServiceLocator doesn't find any instances of LogService
 
https://github.com/liquibase/liquibase/blob/master/liquibase-core/src/main/java/liquibase/plugin/AbstractPluginFactory.java#L98

And StandardServiceLocator.findInstances(Class), used
java.util.ServiceLoader.load() to find the instances
 
https://github.com/liquibase/liquibase/blob/master/liquibase-core/src/main/java/liquibase/servicelocator/StandardServiceLocator.java#L21

So, yep, defintely a classloader issue.

The java.util.ServiceLoader is what powers the spring dependency
injection mechanism, and definitely works best when you have a single
classloader.

So I googled "ServiceLoader osgi" and immediately found this clarifying
(but old (february 13 2013)) blog post:
 https://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html

Liquibase is attempting to use the serviceloader.

They are requiring the necessary capabilities (this is why liquibase now
needs something like spifly, to load):
 https://github.com/liquibase/liquibase/blob/master/liquibase-core/pom.xml#L198
 
And they are providing the capabilities, which should make it possible
for a different bundle to have ServiceLoader successfully do a classpath
scan and find the services.

So to sum it up: the reason LogService isn't found is a classloader
issue, there is a known fix, and liquibase has implemented the fix.

The only problem is... I haven't been able to make it work...:-/

I have tried the following:

1. Requiring the LogService feature in the maven-bundle-plugin config,
   based on the example in the feb 2013 blog post:
  
   osgi.extender; filter:="(osgi.extender=osgi.serviceloader.processor)",
   
osgi.serviceloader;filter:="(osgi.serviceloader=liquibase.logging.LogService)";cardinality:=multiple
  

   but that failed in the karaf feature loader, because the
   osgi.serviceloader.processor capability couldn't be found.

2. So I copied the entire  from liquibase-core

https://github.com/liquibase/liquibase/blob/master/liquibase-core/pom.xml#L198
   where all of the services are provided by the liquibase-core manifest

https://github.com/liquibase/liquibase/blob/master/liquibase-core/pom.xml#L169
   (the osgi.serviceloader.registrar and osgi.serviceloader.processor
   capabilities would presumably be provided by spifly, same as for the
   osgi-core itself)

   And this one have no load failures, but the karaf.log contains the
   dreaded "Cannot find default log service" stack trace

I think that everything created inside the liquibase-core bundle itself,
using that bundle's classloader(s), would work just fine.

But Liquibase classes I instanciate in my own bundles will be unable to
find the various services.

I've been thinking of various exotic ideas, such as e.g.
 1. Define a liquibase factory service interface, and make an OSGi
bundle fragment that adds an implementation of this service (can
bundle fragments even provide services...?)

 2. Somehow expose the services created by liquibase init as OSGi
services, and use DS to inject those services into my bundles.
No idea how to go about this, except that it would probably involve
a bundle fragment somehow

But, as I say "exotic ideas". I don't think they will work, and they
feel like a hack. I'm just throwing them out there, to 

Re: Problems with logging to karaf.log from liquibase >3

[Steven Huypens]

Hi Steinar,

As far as I can tell, there is a spifly-issue, which is why Liquibase
cannot create the correct Log Services. I tried


aries-proxy

mvn:org.apache.aries.spifly/org.apache.aries.spifly.dynamic.bundle/1.3.4

mvn:org.yaml/snakeyaml/${snakeyaml.version}

mvn:org.liquibase/liquibase-core/${liquibase.version}


which leads to new exceptions. The one from Liquibase Pro can be ignored
for now, I guess, and the other one might be related to your
ResourceAccessor, Good luck, I hope this helps you a little.

Kind regards,
Steven


On Sun, Aug 7, 2022 at 6:02 PM Steinar Bang  wrote:

> > Steven Huypens :
>
> > Hi Steinar,
> > I tried the liquibase-karaf-feature/use-liquibase-slf4j-410 branch. After
> > changing the liquibase version to 4.9.1 in the pom.xml, the build is
> > successful.
>
> Yes, but if you take a look at
>
>  
> liquibase-karaf-feature/liquibase-integration-test/karaf.liquibase.tests/target/exam//log/karaf.log
> you will see a stacktrace in the log, caused by "Cannot find default log
> service" and no liquibase logging from setting up the schema and
> populating it with data.
>  https://gist.github.com/steinarb/2857d60427d42686299b1d9a388ee420
>
> But if you switch to the master branch and change liquibase.version in
> .m2/settings.xml back to 3.8.0 and re-run "mvn clean install" you will
> find a
>
>  
> liquibase-karaf-feature/liquibase-integration-test/karaf.liquibase.tests/target/exam//log/karaf.log
> that doesn't have the "Cannot find default log service" error, and
> contains the log output from liquibase
>  https://gist.github.com/steinarb/d5902ae12bdcc1f96bd66eaf45f9311b
>
> This is the behaviour that has eluded me in all liquibase versions since
> 3.8.0(*), and the reason I haven't updated the liquibase version of the
> feature.
>
> But I've not given up yet! :-)
>
> (*) in 3.x versions >3.8.0 because of various OSGi and JDK 8 vs 11
> related problems, and in 4.x because the log system has changed and
> I haven't been able to make the liquibase logging work right with
> karaf
>
>

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Steven Huypens :

> Hi Steinar,
> I tried the liquibase-karaf-feature/use-liquibase-slf4j-410 branch. After
> changing the liquibase version to 4.9.1 in the pom.xml, the build is
> successful.

Yes, but if you take a look at
 
liquibase-karaf-feature/liquibase-integration-test/karaf.liquibase.tests/target/exam//log/karaf.log
you will see a stacktrace in the log, caused by "Cannot find default log
service" and no liquibase logging from setting up the schema and
populating it with data.
 https://gist.github.com/steinarb/2857d60427d42686299b1d9a388ee420

But if you switch to the master branch and change liquibase.version in
.m2/settings.xml back to 3.8.0 and re-run "mvn clean install" you will
find a 
 
liquibase-karaf-feature/liquibase-integration-test/karaf.liquibase.tests/target/exam//log/karaf.log
that doesn't have the "Cannot find default log service" error, and
contains the log output from liquibase
 https://gist.github.com/steinarb/d5902ae12bdcc1f96bd66eaf45f9311b

This is the behaviour that has eluded me in all liquibase versions since
3.8.0(*), and the reason I haven't updated the liquibase version of the
feature.

But I've not given up yet! :-)

(*) in 3.x versions >3.8.0 because of various OSGi and JDK 8 vs 11
related problems, and in 4.x because the log system has changed and
I haven't been able to make the liquibase logging work right with
karaf 

Re: Problems with logging to karaf.log from liquibase >3

[Steven Huypens]

Hi Steinar,

I tried the liquibase-karaf-feature/use-liquibase-slf4j-410 branch. After
changing the liquibase version to 4.9.1 in the pom.xml, the build is
successful.

Best regards,
Steven

On Sat, Aug 6, 2022 at 10:44 PM Steinar Bang  wrote:

> > Steven Huypens :
>
> > Hi Steinar,
> > Manually changing the liquibse version to 4.9.1 results in
>
> > ... 15 more
> > Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to
> > resolve org.liquibase.core/4.9.1: missing requirement
> > [org.liquibase.core/4.9.1] osgi.extender;
> > filter:="(osgi.extender=osgi.serviceloader.registrar)"
> > at
> >
> org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341)
> > ... 16 more
>
> This is from the master branch with liquibase.version 4.9.1?
>
> If you switch to the liquibase-karaf-feature/use-liquibase-slf4j-410
> branch, it will pull in the built-in karaf feature "spifly", which
> provides the capability osgi.serviceloader.registrar.
>
> > Isn't there a way to chat online? Otherwise this is going to take a
> > lot of time :-)
>
> Sorry, no, I don't have anything like that.
>
> I used to have some chat services back in the early 00-ies, but they
> gradually died and I never got around to replacing them.
>
>

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Steven Huypens :

> Hi Steinar,
> Manually changing the liquibse version to 4.9.1 results in

> ... 15 more
> Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to
> resolve org.liquibase.core/4.9.1: missing requirement
> [org.liquibase.core/4.9.1] osgi.extender;
> filter:="(osgi.extender=osgi.serviceloader.registrar)"
> at
> org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341)
> ... 16 more

This is from the master branch with liquibase.version 4.9.1?

If you switch to the liquibase-karaf-feature/use-liquibase-slf4j-410
branch, it will pull in the built-in karaf feature "spifly", which
provides the capability osgi.serviceloader.registrar.

> Isn't there a way to chat online? Otherwise this is going to take a
> lot of time :-)

Sorry, no, I don't have anything like that.

I used to have some chat services back in the early 00-ies, but they
gradually died and I never got around to replacing them.

Re: Problems with logging to karaf.log from liquibase >3

[Steven Huypens]

Hi Steinar,

Manually changing the liquibse version to 4.9.1 results in

... 15 more
Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to
resolve org.liquibase.core/4.9.1: missing requirement
[org.liquibase.core/4.9.1] osgi.extender;
filter:="(osgi.extender=osgi.serviceloader.registrar)"
at
org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341)
... 16 more

Isn't there a way to chat online? Otherwise this is going to take a lot of
time :-)

Best regards,
Steven

On Sat, Aug 6, 2022 at 8:03 PM Steinar Bang  wrote:

> > Steven Huypens :
>
> > Hi Steinar,
> > I tried to build the project, but ran into several issues. If you can
> > update it, also updating the liquibase version, I'd be happy to take a
> look.
>
> Ah, right!  Sorry about that!
>
> It was too much work, and too confusing, to update the liquibase-version
> using git commits, especially when I wanted to try different versions
> of liquibase against a set of modifications.
>
> So what I'm doing during development, is set the liquibase.version in
> ~/.m2/settings.xml
>
> Note: the version will be correct, if I make a release with a version
> matching the actual liquibase version I'm making the feature for (which
> is what I have been doing up to liquibase version 3.8.0, which is the
> last version I didn't have any issues with.
>
> (If I mess up and need to release a feature with a different version than
> liquibase, I need to commit the liquibase version explicitly in the
> pom. But that is a problem for the future)
>
> Anyway, as I said: for development it is easiest to adjust the version in
> ~/.m2/settings.xml
>
> To get it to build, use the setting
> 
>  
>   
>non-snapshot-liquibase
>true
> 
>  3.8.0
> 
>   
>  
> 
>
> To get the version you're using, bump liquibase.version in
> ~/.m2/settings.xml to 4.9.1.
>
> With the current master HEAD, this should fail with the "Cannot find
> default log service" error in the pax exam karaf log (it is in
> target/exim//data/log/karaf.log after "mvn clean install" has
> run its course).
>
> I also have locally various experimental branches.
>
> I have pushed the most promising
> liquibase-karaf-feature/use-liquibase-slf4j-410,
> which:
>  1. Removes the rebundling of liquibase-slf4j as a bundle fragment,
> attached to the liquibase-core bundle
>  2. Load liquibase-slf4j 4.1.0 at runtime, see [1] (this version is an
> OSGi bundle fragment that attaches to liquibase-core 4.9.1 and later)
>  3. Load the built-in spifly feature at runtime, which provides the
> osgi.serviceloader.registrar capability (incidentially, the
> serviceloader, is the code that currently fails to find the default
> log service...)
>
> Note: I *think* that the new version of liquibase-slf4j is effectively a
> no-op wrt. to the the way liquibase 4.x finds its logs, but I've left it
> in place for now (as I said: I have various failed experimental branches
> that there is no point in pushing).
>
> References:
>  [1] 
>
>

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Steven Huypens :

> Hi Steinar,
> I tried to build the project, but ran into several issues. If you can
> update it, also updating the liquibase version, I'd be happy to take a look.

Ah, right!  Sorry about that!

It was too much work, and too confusing, to update the liquibase-version
using git commits, especially when I wanted to try different versions
of liquibase against a set of modifications.

So what I'm doing during development, is set the liquibase.version in
~/.m2/settings.xml

Note: the version will be correct, if I make a release with a version
matching the actual liquibase version I'm making the feature for (which
is what I have been doing up to liquibase version 3.8.0, which is the
last version I didn't have any issues with.

(If I mess up and need to release a feature with a different version than
liquibase, I need to commit the liquibase version explicitly in the
pom. But that is a problem for the future)

Anyway, as I said: for development it is easiest to adjust the version in
~/.m2/settings.xml

To get it to build, use the setting

 
  
   non-snapshot-liquibase
   true

 3.8.0

  
 


To get the version you're using, bump liquibase.version in
~/.m2/settings.xml to 4.9.1.

With the current master HEAD, this should fail with the "Cannot find
default log service" error in the pax exam karaf log (it is in
target/exim//data/log/karaf.log after "mvn clean install" has
run its course).

I also have locally various experimental branches.

I have pushed the most promising 
liquibase-karaf-feature/use-liquibase-slf4j-410,
which:
 1. Removes the rebundling of liquibase-slf4j as a bundle fragment,
attached to the liquibase-core bundle
 2. Load liquibase-slf4j 4.1.0 at runtime, see [1] (this version is an
OSGi bundle fragment that attaches to liquibase-core 4.9.1 and later)
 3. Load the built-in spifly feature at runtime, which provides the
osgi.serviceloader.registrar capability (incidentially, the
serviceloader, is the code that currently fails to find the default
log service...)

Note: I *think* that the new version of liquibase-slf4j is effectively a
no-op wrt. to the the way liquibase 4.x finds its logs, but I've left it
in place for now (as I said: I have various failed experimental branches
that there is no point in pushing).

References:
 [1] 

Re: Problems with logging to karaf.log from liquibase >3

[Steven Huypens]

Hi Steinar,

I tried to build the project, but ran into several issues. If you can
update it, also updating the liquibase version, I'd be happy to take a look.

Kind regards,
Steven

On Fri, Aug 5, 2022 at 5:22 PM Steinar Bang  wrote:

> > Steinar Bang :
> > Steven Huypens :
> >> Hi Steinar,
> >> I am not using any scopes indeed, nor any explicit logging
> configuration. I
> >> just realized though, we sometimes see the stacktrace below in our
> >> integration tests, maybe it is related to your problem. It doesn't
> happen a
> >> lot, so I did not have a closer look yet.
>
> >> EventDispatcher: Error during dispatch.
> >> (java.lang.ExceptionInInitializerError)
> >> java.lang.ExceptionInInitializerError
> >> at
> >>
> be.cipal.impl.liquibase.extender.internal.LiquibaseMigrationBundleFactory.loadDatabase(LiquibaseMigrationBundleFactory.java:206)
> >> // skipped part of the trace
> >> Caused by: liquibase.exception.UnexpectedLiquibaseException: Cannot find
> >> default log service
> >> at liquibase.Scope.getCurrentScope(Scope.java:87)
> >> at liquibase.database.DatabaseFactory.(DatabaseFactory.java:20)
> >> ... 21 more
>
> > Ah! That's the exact message I'm currently seeing in karaf.log and what
> > I'm trying to get past.
>
> > I get that message consistently (at least I do, in the pax exam
> > integration test I created for the karaf feature).
>
> FYI, this is the integration test:
>
> https://github.com/steinarb/liquibase-karaf-feature/tree/master/liquibase-integration-test
>
> karaf.liquibase.sample is a bundle project defining, and attaching, two
> karaf features:
>  1. sample-db which is a jdbc-config feature defining a derby in-memory
> datasource
>  2. karaf-liquibase-sample which loads a @Component that exposes a
> PreHook service, that plugs into the datasource and sets up a schema
> and populates with some dummy data
>
>
> karaf.liquibase.sample.datasource.receiver is another bundle project,
> thatcontains a @Component that has a Datasource @Reference and is loaded
> by a the attached feature karaf-liquibase-sample-datasource-receiver,
> that requires feature sample-db.
>
> karaf.liquibase.tests is a pax exam karaf test that loads and asserts
> the feature karaf-liquibase-sample-datasource-receiver
>
> Note that it is also possible to load the features of the test manually,
> by building the project, and in a karaf started as my own user (ie. a
> karaf from a binary tar.gz or .zip distribution file), give the
> commands:
>
>  feature:repo-add
> mvn:no.priv.bang.karaf/karaf.liquibase.sample.datasource.receiver/LATEST/xml/features
>  feature:install karaf-liquibase-sample-datasource-receiver
>
> This is what I have used to debug into the liquibase init code that
> fails to find the log, and give the error messages you've quoted.
>
>

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Steinar Bang :
> Steven Huypens :
>> Hi Steinar,
>> I am not using any scopes indeed, nor any explicit logging configuration. I
>> just realized though, we sometimes see the stacktrace below in our
>> integration tests, maybe it is related to your problem. It doesn't happen a
>> lot, so I did not have a closer look yet.

>> EventDispatcher: Error during dispatch.
>> (java.lang.ExceptionInInitializerError)
>> java.lang.ExceptionInInitializerError
>> at
>> be.cipal.impl.liquibase.extender.internal.LiquibaseMigrationBundleFactory.loadDatabase(LiquibaseMigrationBundleFactory.java:206)
>> // skipped part of the trace
>> Caused by: liquibase.exception.UnexpectedLiquibaseException: Cannot find
>> default log service
>> at liquibase.Scope.getCurrentScope(Scope.java:87)
>> at liquibase.database.DatabaseFactory.(DatabaseFactory.java:20)
>> ... 21 more

> Ah! That's the exact message I'm currently seeing in karaf.log and what
> I'm trying to get past.

> I get that message consistently (at least I do, in the pax exam
> integration test I created for the karaf feature).

FYI, this is the integration test:
https://github.com/steinarb/liquibase-karaf-feature/tree/master/liquibase-integration-test

karaf.liquibase.sample is a bundle project defining, and attaching, two
karaf features:
 1. sample-db which is a jdbc-config feature defining a derby in-memory
datasource
 2. karaf-liquibase-sample which loads a @Component that exposes a
PreHook service, that plugs into the datasource and sets up a schema
and populates with some dummy data


karaf.liquibase.sample.datasource.receiver is another bundle project,
thatcontains a @Component that has a Datasource @Reference and is loaded
by a the attached feature karaf-liquibase-sample-datasource-receiver,
that requires feature sample-db.

karaf.liquibase.tests is a pax exam karaf test that loads and asserts
the feature karaf-liquibase-sample-datasource-receiver

Note that it is also possible to load the features of the test manually,
by building the project, and in a karaf started as my own user (ie. a
karaf from a binary tar.gz or .zip distribution file), give the
commands:

 feature:repo-add 
mvn:no.priv.bang.karaf/karaf.liquibase.sample.datasource.receiver/LATEST/xml/features
 feature:install karaf-liquibase-sample-datasource-receiver

This is what I have used to debug into the liquibase init code that
fails to find the log, and give the error messages you've quoted.

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Steven Huypens :

> Hi Steinar,
> I am not using any scopes indeed, nor any explicit logging configuration. I
> just realized though, we sometimes see the stacktrace below in our
> integration tests, maybe it is related to your problem. It doesn't happen a
> lot, so I did not have a closer look yet.

> EventDispatcher: Error during dispatch.
> (java.lang.ExceptionInInitializerError)
>  java.lang.ExceptionInInitializerError
> at
> be.cipal.impl.liquibase.extender.internal.LiquibaseMigrationBundleFactory.loadDatabase(LiquibaseMigrationBundleFactory.java:206)
> // skipped part of the trace
> Caused by: liquibase.exception.UnexpectedLiquibaseException: Cannot find
> default log service
> at liquibase.Scope.getCurrentScope(Scope.java:87)
> at liquibase.database.DatabaseFactory.(DatabaseFactory.java:20)
> ... 21 more

Ah! That's the exact message I'm currently seeing in karaf.log and what
I'm trying to get past.

I get that message consistently (at least I do, in the pax exam
integration test I created for the karaf feature).

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Steinar Bang :

> PS Do you do any explicit logging configuration inside the bundle, in
> addition the above code?  Specifically: Do you create a LogService
> Java object that is not JavaLogServic, inside the bundle?

For my own part, I see that in December 2020 I introduced a
src/test/resources/logback.xml file in all projects where I used
liquibase in the unit tests, to limit the log noise when doing "mvn
clean install", with the following content:




%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - 
%msg%n








But I have no log configuration for runtime.  There I let karaf provide
whatever it provides.

Re: Problems with logging to karaf.log from liquibase >3

[Steven Huypens]

Hi Steinar,

I am not using any scopes indeed, nor any explicit logging configuration. I
just realized though, we sometimes see the stacktrace below in our
integration tests, maybe it is related to your problem. It doesn't happen a
lot, so I did not have a closer look yet.

EventDispatcher: Error during dispatch.
(java.lang.ExceptionInInitializerError)
 java.lang.ExceptionInInitializerError
at
be.cipal.impl.liquibase.extender.internal.LiquibaseMigrationBundleFactory.loadDatabase(LiquibaseMigrationBundleFactory.java:206)
// skipped part of the trace
Caused by: liquibase.exception.UnexpectedLiquibaseException: Cannot find
default log service
at liquibase.Scope.getCurrentScope(Scope.java:87)
at liquibase.database.DatabaseFactory.(DatabaseFactory.java:20)
... 21 more


Best regards,
Steven



On Fri, Aug 5, 2022 at 2:23 PM Steinar Bang  wrote:

> > Steven Huypens :
>
> > Hi Steinar,
> > Some pseudo-code :
>
> Thanks!
>
> It immediately answers one of my questions, which was what
> resourceaccessor you use, and you use the OsgiResourceAccessor.
>
> Back in 2017 I landed on the ClassLoaderResourceAccessor, based on the
> class using the and it has worked as I expected it to, and wanted it to
> (scan the class path for resources inside the OSGi bundle liquibase is
> run from).
>
> I've tried OsgiResourceAccessor now, to see if that helped with the
> unable to find log issue.
>
> Unfortunately, switching the ResourceAccsessor didn't help.  But I have
> debugged through the init, and the two aren't very different
> (ClassLoaderResourceAccessor gets the class loader of the current class,
> which is an OSGi class loader for the current bundle and the
> OSGiResourceAccessor gets a Bundle argument, gets the class loader from
> the bundle and uses it to create a ClassLoaderResourceAccessor), so I
> didn't really expect it to make a difference... but one can hope! :-)
>
> > JdbcConnection connection = new JdbcConnection(myConnection);
> > Database database =
> >
> DatabaseFactory.getInstance().findCorrectDatabaseImplementation(connection);
> > ChangeLogParameters changeLogParameters = new
> ChangeLogParameters(database);
>
> > String liquibaseFilePath = "OSGI-INF/liquibase/master.xml";
> > ResourceAccessor resourceAccessor = new OSGiResourceAccessor(myBundle);
> > DatabaseChangeLog databaseChangeLog =
> ChangeLogParserFactory.getInstance()
> > .getParser(liquibaseFilePath, resourceAccessor)
> > .parse(liquibaseFilePath, changeLogParameters,
> > resourceAccessor);
>
>
> > for (final ChangeSet changeSet : databaseChangeLog.getChangeSets()) {
> >   if (database.getRanChangeSet(changeSet) == null) {
> > changeSet.execute(databaseChangeLog, database);
> > database.markChangeSetExecStatus(changeSet,
> > ChangeSet.ExecType.EXECUTED);
> >   }
> > }
>
> Hm... doesn't look like you make a child Scope like in the examples
> here...?
>
> https://docs.liquibase.com/workflows/liquibase-community/using-liquibase-java-api.html
>
> That was my second question, because when debugging, I can see a
> JavaLogService be created, and then later not be found by the
> ServiceLocator class.
>
> So I wondered if you had any Scope magic I didn't have, but it looks
> like if you don't.
>
> > I'm sure there are better ways nowadays, but this is how we got it to
> work
> > so many years ago.
>
> Amen to that! :-)
>
> I myself have just continued the way I got working in when I started
> using liquibase in 2017.
>
> Thanks!
>
> I'll keep on debugging the init to see if I can figure out where the log
> service scan fails and why it fails.
>
> And I may also try to change my approach with yours to see if that
> magically makes the logger be found.
>
> PS Do you do any explicit logging configuration inside the bundle, in
> addition the above code?  Specifically: Do you create a LogService Java
> object that is not JavaLogServic, inside the bundle?
>
>

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Steven Huypens :

> Hi Steinar,
> Some pseudo-code :

Thanks!

It immediately answers one of my questions, which was what
resourceaccessor you use, and you use the OsgiResourceAccessor.

Back in 2017 I landed on the ClassLoaderResourceAccessor, based on the
class using the and it has worked as I expected it to, and wanted it to
(scan the class path for resources inside the OSGi bundle liquibase is
run from).

I've tried OsgiResourceAccessor now, to see if that helped with the
unable to find log issue.

Unfortunately, switching the ResourceAccsessor didn't help.  But I have
debugged through the init, and the two aren't very different
(ClassLoaderResourceAccessor gets the class loader of the current class,
which is an OSGi class loader for the current bundle and the
OSGiResourceAccessor gets a Bundle argument, gets the class loader from
the bundle and uses it to create a ClassLoaderResourceAccessor), so I
didn't really expect it to make a difference... but one can hope! :-)

> JdbcConnection connection = new JdbcConnection(myConnection);
> Database database =
> DatabaseFactory.getInstance().findCorrectDatabaseImplementation(connection);
> ChangeLogParameters changeLogParameters = new ChangeLogParameters(database);

> String liquibaseFilePath = "OSGI-INF/liquibase/master.xml";
> ResourceAccessor resourceAccessor = new OSGiResourceAccessor(myBundle);
> DatabaseChangeLog databaseChangeLog = ChangeLogParserFactory.getInstance()
> .getParser(liquibaseFilePath, resourceAccessor)
> .parse(liquibaseFilePath, changeLogParameters,
> resourceAccessor);


> for (final ChangeSet changeSet : databaseChangeLog.getChangeSets()) {
>   if (database.getRanChangeSet(changeSet) == null) {
> changeSet.execute(databaseChangeLog, database);
> database.markChangeSetExecStatus(changeSet,
> ChangeSet.ExecType.EXECUTED);
>   }
> }

Hm... doesn't look like you make a child Scope like in the examples here...?
 
https://docs.liquibase.com/workflows/liquibase-community/using-liquibase-java-api.html

That was my second question, because when debugging, I can see a
JavaLogService be created, and then later not be found by the
ServiceLocator class.

So I wondered if you had any Scope magic I didn't have, but it looks
like if you don't.

> I'm sure there are better ways nowadays, but this is how we got it to work
> so many years ago.

Amen to that! :-)

I myself have just continued the way I got working in when I started
using liquibase in 2017.

Thanks!

I'll keep on debugging the init to see if I can figure out where the log
service scan fails and why it fails.

And I may also try to change my approach with yours to see if that
magically makes the logger be found.

PS Do you do any explicit logging configuration inside the bundle, in
addition the above code?  Specifically: Do you create a LogService Java
object that is not JavaLogServic, inside the bundle?

Re: Problems with logging to karaf.log from liquibase >3

[Steven Huypens]

Hi Steinar,

Some pseudo-code :

JdbcConnection connection = new JdbcConnection(myConnection);
Database database =
DatabaseFactory.getInstance().findCorrectDatabaseImplementation(connection);
ChangeLogParameters changeLogParameters = new ChangeLogParameters(database);

String liquibaseFilePath = "OSGI-INF/liquibase/master.xml";
ResourceAccessor resourceAccessor = new OSGiResourceAccessor(myBundle);
DatabaseChangeLog databaseChangeLog = ChangeLogParserFactory.getInstance()
.getParser(liquibaseFilePath, resourceAccessor)
.parse(liquibaseFilePath, changeLogParameters,
resourceAccessor);


for (final ChangeSet changeSet : databaseChangeLog.getChangeSets()) {
  if (database.getRanChangeSet(changeSet) == null) {
changeSet.execute(databaseChangeLog, database);
database.markChangeSetExecStatus(changeSet,
ChangeSet.ExecType.EXECUTED);
  }
}

I'm sure there are better ways nowadays, but this is how we got it to work
so many years ago.

Steven

On Wed, Aug 3, 2022 at 3:25 PM Steinar Bang  wrote:

> > Steinar Bang :
> > Steven Huypens :
>
> >> I had a brief look at your repo and I see you are creating an actual
> >> Liquibase instance, which we are not, possibly because of certain
> >> issues in the past. But I don't think that should make a difference
> >> wrt logging.
>
> > No, I don't think that should make a difference either.
>
> Actually, this could make a big difference, because I think how I'm
> creating the Liquibase instance and the resource locator I'm using,
> could effect the log-finding problems I'm seeing.
>
> I'm curious: if you're not creating an actual Liquibase instance, how do
> you use liquibase?
>
> (I'm using Liquibase the only way I was able to figure out it could be
> used, back when I started using liquibse in 2017, and if there is a
> different and better way, I'm open to that)
>
> Thanks!
>
>

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Steinar Bang :
> Steven Huypens :

>> I had a brief look at your repo and I see you are creating an actual
>> Liquibase instance, which we are not, possibly because of certain
>> issues in the past. But I don't think that should make a difference
>> wrt logging.

> No, I don't think that should make a difference either.

Actually, this could make a big difference, because I think how I'm
creating the Liquibase instance and the resource locator I'm using,
could effect the log-finding problems I'm seeing.

I'm curious: if you're not creating an actual Liquibase instance, how do
you use liquibase?

(I'm using Liquibase the only way I was able to figure out it could be
used, back when I started using liquibse in 2017, and if there is a
different and better way, I'm open to that)

Thanks!

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Steven Huypens :

> I finally found some time to check our setup. We are currently using
> liquibase-core 4.9.1 (be it with some patches we required) on Karaf 4.3.7
> and logging is working fine with Pax Logging, nothing special required,
> only the correct Slf4j configuration.

This is very interesting information, because that was how I hoped it
would work, from the description of the changes made to logging in
liquibase (except it didn't, for me...).

> I had a brief look at your repo and I see you are creating an actual
> Liquibase instance, which we are not, possibly because of certain
> issues in the past. But I don't think that should make a difference
> wrt logging.

No, I don't think that should make a difference either.

Note1: The core of the old approach was to put the new adapter "inside" the
Liquibse OSGi bundle, so that a classpath scan would find it and use
it.

Note2: with the new logging approach of liquibase, the whole need for
such an adapter should go away.

> I'm not sure how this is helping you, but at least you now know it can
> work.

Yep, thanks! Good information! :-)

> If you're interested, we could get in touch to discuss the code in
> more detail.

I'm not working on this right now, but when I finally get back to it, I
may take you up on this. Thanks!


- Steinar

Re: Problems with logging to karaf.log from liquibase >3

[Steven Huypens]

Hi Steinar,

I finally found some time to check our setup. We are currently using
liquibase-core 4.9.1 (be it with some patches we required) on Karaf 4.3.7
and logging is working fine with Pax Logging, nothing special required,
only the correct Slf4j configuration.

I had a brief look at your repo and I see you are creating an actual
Liquibase instance, which we are not, possibly because of certain issues in
the past. But I don't think that should make a difference wrt logging.

I'm not sure how this is helping you, but at least you now know it can
work. If you're interested, we could get in touch to discuss the code in
more detail.

Kind regards,
Steven

On Thu, Jun 9, 2022 at 8:39 PM Steinar Bang  wrote:

> > Steinar Bang :
>
> > So I've tried the newest liquibase release: 4.11.0
>
> > Version 4.11.0 failed because the MANIFEST.MF was missing OSGi headers.
> > I've filed an issue for the missing headers:
> https://github.com/liquibase/liquibase/issues/2922
>
> FYI, this have been fixed:
>  https://github.com/liquibase/liquibase/issues/2922#event-6780035990
>
>

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Steinar Bang :

> So I've tried the newest liquibase release: 4.11.0

> Version 4.11.0 failed because the MANIFEST.MF was missing OSGi headers.
> I've filed an issue for the missing headers: 
> https://github.com/liquibase/liquibase/issues/2922

FYI, this have been fixed:
 https://github.com/liquibase/liquibase/issues/2922#event-6780035990

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Jakub Herkel :

> your problem with loading XSD files is probably this issue
> https://github.com/liquibase/liquibase/issues/2817.  I solved it
> temporary with set liquibase.secureParsing to false.

Thanks! 

Re: Problems with logging to karaf.log from liquibase >3

[Jakub Herkel]

your problem with loading XSD files is probably this issue
https://github.com/liquibase/liquibase/issues/2817.  I solved it
temporary with set liquibase.secureParsing to false.

Jakub

On Tue, Jun 7, 2022 at 9:14 PM Steinar Bang  wrote:
>
> > Steinar Bang :
> > Jean-Baptiste Onofré :
>
> >> Depending of the Karaf version, you can use either spifly or loader
> >> directly.
>
> > I'm targeting karaf-4.4.0.  Which one should I use there?
>
> Probably spifly...?
>
> "feature:install spifly" works, while "feature:install loader" finds
> nothing to install.
>
> But I get the following error in karaf.log on "feature:install spifly":
>  2022-06-07T21:06:04,050 | ERROR | FelixDispatchQueue | Framework 
>| 52 - org.apache.aries.spifly.dynamic.bundle - 1.3.4 | 
> FrameworkEvent ERROR
>  java.lang.RuntimeException: No Common Superclass:javax/crypto/SecretKey 
> javax/crypto/SecretKeyFactory
>
> Is this significant?
>
> It does seem to help with the loading of liquibse 4.10.0 (which now
> fails because it can't find dbchangelog-3.5.xsd, but that should be
> fixable).
>

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Steinar Bang :
> Jean-Baptiste Onofré :

>> Depending of the Karaf version, you can use either spifly or loader
>> directly.

> I'm targeting karaf-4.4.0.  Which one should I use there?

Probably spifly...?

"feature:install spifly" works, while "feature:install loader" finds
nothing to install.

But I get the following error in karaf.log on "feature:install spifly":
 2022-06-07T21:06:04,050 | ERROR | FelixDispatchQueue | Framework   
 | 52 - org.apache.aries.spifly.dynamic.bundle - 1.3.4 | FrameworkEvent 
ERROR
 java.lang.RuntimeException: No Common Superclass:javax/crypto/SecretKey 
javax/crypto/SecretKeyFactory

Is this significant?

It does seem to help with the loading of liquibse 4.10.0 (which now
fails because it can't find dbchangelog-3.5.xsd, but that should be
fixable). 

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Jean-Baptiste Onofré :

> Hi
> Depending of the Karaf version, you can use either spifly or loader
> directly.

I'm targeting karaf-4.4.0.  Which one should I use there?

Re: Problems with logging to karaf.log from liquibase >3

[Jean-Baptiste Onofré]

Hi

Depending of the Karaf version, you can use either spifly or loader
directly.

Regards
JB

Le lun. 6 juin 2022 à 22:20, Steinar Bang  a écrit :

> > Steinar Bang :
>
> > The project now has an integration test, and the karaf.log of the
> > integration test shows liquibase output, for version 3.8.0 of liquibase,
> > so I can use this to debug liquibase logging for 4.x versions:
> >
> https://github.com/steinarb/liquibase-karaf-feature/tree/master/liquibase-integration-test/karaf.liquibase.tests
>
> So I've tried the newest liquibase release: 4.11.0
>
> Version 4.11.0 failed because the MANIFEST.MF was missing OSGi headers.
> I've filed an issue for the missing headers:
> https://github.com/liquibase/liquibase/issues/2922
>
> Version 4.10.0 has OSGi headers in the MANIFEST.MF.
>
> But version 4.10.0 fails because it can't find
> osgi.serviceloader.registrar:
>
> testLoadFeature(no.priv.bang.karaf.liquibase.tests.LiquibaseKarafFeatureIntegrationTest):
> Unable to resolve org.liquibase.core/4.10.0: missing requirement
> [org.liquibase.core/4.10.0] osgi.extender;
> filter:="(osgi.extender=osgi.serviceloader.registrar)"
>
> I've googled and osgi.serviceloader.registrar seems to be part of
> something called the OSGi service loader mediator:
>  https://stackoverflow.com/a/43781701
>
> Is the OSGi service loader mediator easily available in karaf?
> I.e. loadable by a feature?
>
>
>
>

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Steinar Bang :

> The project now has an integration test, and the karaf.log of the
> integration test shows liquibase output, for version 3.8.0 of liquibase,
> so I can use this to debug liquibase logging for 4.x versions:
>  
> https://github.com/steinarb/liquibase-karaf-feature/tree/master/liquibase-integration-test/karaf.liquibase.tests

So I've tried the newest liquibase release: 4.11.0

Version 4.11.0 failed because the MANIFEST.MF was missing OSGi headers.
I've filed an issue for the missing headers: 
https://github.com/liquibase/liquibase/issues/2922

Version 4.10.0 has OSGi headers in the MANIFEST.MF.

But version 4.10.0 fails because it can't find osgi.serviceloader.registrar:
  
testLoadFeature(no.priv.bang.karaf.liquibase.tests.LiquibaseKarafFeatureIntegrationTest):
 Unable to resolve org.liquibase.core/4.10.0: missing requirement 
[org.liquibase.core/4.10.0] osgi.extender; 
filter:="(osgi.extender=osgi.serviceloader.registrar)"

I've googled and osgi.serviceloader.registrar seems to be part of
something called the OSGi service loader mediator:
 https://stackoverflow.com/a/43781701

Is the OSGi service loader mediator easily available in karaf?
I.e. loadable by a feature?

 

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Steinar Bang :

> (rookie copy/paste mistake!  I forgot to match the name in the
> @Component annotation with the ops4j.preHook config value in
> jdbc-config)

Correcting myself: in addition to the mistake above, I do need a
Datasource consumer, i.e. an SCR component that receives a Datasource
injection.

If not, the liquibase actions are not run.

The project now has an integration test, and the karaf.log of the
integration test shows liquibase output, for version 3.8.0 of liquibase,
so I can use this to debug liquibase logging for 4.x versions:
 
https://github.com/steinarb/liquibase-karaf-feature/tree/master/liquibase-integration-test/karaf.liquibase.tests

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Steinar Bang :

> So I created a bundle project with a PreHook java class, and in the
> feature.xml added a jdbc-config feature that creates the datasource and
> requires the PreHook feature.

> And then I created an integration test that loads the jdbc-config
> feature.

> And according to the karaf.log this just loads all features and then
> stops.

> What's needed to actually run the PreHook?

> Do I need to create another feature that requires the jdbc-config
> feature and expects a DatataSource service?

(rookie copy/paste mistake!  I forgot to match the name in the
@Component annotation with the ops4j.preHook config value in
jdbc-config)

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Steinar Bang :

> Note: this project is currently in flux, I'm in the process of
> reorganizing the project to be able to have a karaf integration test
> that loads the feature (and sets up a simple schema and populates the
> schema with some data).

So I created a bundle project with a PreHook java class, and in the
feature.xml added a jdbc-config feature that creates the datasource and
requires the PreHook feature.

And then I created an integration test that loads the jdbc-config
feature.

And according to the karaf.log this just loads all features and then
stops.

What's needed to actually run the PreHook?

Do I need to create another feature that requires the jdbc-config
feature and expects a DatataSource service?

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Steinar Bang :

>> I can try your feature to check and eventually create a bundle at SMX and
>> corresponding Karaf in enterprise feature.

> The source for the feature (and the bundle fragment shimsing in logging
> for liquibase 3), is here:
>  https://github.com/steinarb/liquibase-karaf-feature

Note: this project is currently in flux, I'm in the process of
reorganizing the project to be able to have a karaf integration test
that loads the feature (and sets up a simple schema and populates the
schema with some data).

That should cut down the round trips for testing new features and also
give me a way to debug a regular unit test to see if I can figured out
how logging is called and used.  If I can figure out how liquibase tries
to find the logs, I can hopefully figure out a way to provide it in an
OSGi setting.

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Jean-Baptiste Onofré :

> Hi Steinar,
> I'm sorry, I never tried liquidbase in Karaf.

> JUL is supported by pax-logging, so I think your approach wrapping core and
> slf4j in a bundle makes sense.

Yes, but unfortunately I haven't been able to make it work for liquibase 4.

At least not yet.

> I can try your feature to check and eventually create a bundle at SMX and
> corresponding Karaf in enterprise feature.

The source for the feature (and the bundle fragment shimsing in logging
for liquibase 3), is here:
 https://github.com/steinarb/liquibase-karaf-feature

Note: I haven't written the shimsing code. The maven project just
rebundles it and turns it into an OSGi fragment.
 
https://github.com/steinarb/liquibase-karaf-feature/tree/master/com.mattbertolini.liquibase-slf4j-osgi

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Jakub Herkel :

> I prepared some fixes for liquibase 3.7 but there was an another osgi
> related error.

Yes I remember, I think? We had two different fixes if I remember
correctly...? 

> So maybe you can check liquibase 4.8.1 when it is released

Will do! Thanks!

Re: Problems with logging to karaf.log from liquibase >3

[Steinar Bang]

> Steven Huypens :

> Hi Steinar,
> We're using liquibase 3.8.0 in Karaf, higher 3.x versions are missing
> 'javax.activation' import. We have no liquibase-logging like you mention.

Ah, but I do have logging on version 3.8.0 (3.0.8 was a typo, sorry!).

Try adding this dependency to your maven bundle project for the bundle
that uses liquibase:
 
https://github.com/steinarb/liquibase-karaf-feature#using-liquibase-from-a-generated-karaf-feature

The dependency will add a feature dependency that will pull in liquibase
as a runtime dependency, together with an OSGi fragment bundle that adds
karaf logging.

Unfortunately this doesn't work for later version 3 liquibases, because
of the javax.activation issue.

And the approach doesn't work for liquibase 4.x unfortunately. :-/

> Waiting for Liquibase 4.8.1 with Jakub's fix..

I will check this out, thanks!

Sorry about the late reply!  I got sidetracked.

Re: Problems with logging to karaf.log from liquibase >3

[Steven Huypens]

Hi Steinar,

We're using liquibase 3.8.0 in Karaf, higher 3.x versions are missing
'javax.activation' import. We have no liquibase-logging like you mention.

Waiting for Liquibase 4.8.1 with Jakub's fix..

Kind regards,
Steven

On Wed, Mar 9, 2022 at 10:38 PM Steinar Bang  wrote:

> I've been stuck on liquibase 3.0.8 since November 2019 (heh! Since
> before corona...!), because I've been unable to make later versions log
> to karaf.log.
>
> But now I'm getting security warnings for liquibase 3, and the only way
> out is to upgrade.
>
> Does anyone else have a working setup for a recent version of liquibase?
>
> In particular: does logging to karaf.log work?
>
> Thanks!
>
> The full story:
>
> Liquibase originally had an extra adapter for logging, that used
> reflection to scan for an adapter implementation. And that posed a
> problem when using OSGi classloader.
>
> Thanks to help from the karaf user mailing list[1], I was able to make
> an existing project[2] into a bundle fragment and attach it to my
> liquibase bundles.
>
> I improved that approach into a handwritten karaf feature and a
> repacking of [2], in[3].
>
> And this worked find for me until I came to liquibase 3.1.1[4], and then it
> started failing for me.  It failed in a funny way, because the snapshots
> I built myself worked fine, but the releases from maven central failed.
>
> I eventually traced this down to an issue caused by the releases being
> built by java8 and me running with java11[5].
>
> I provided a PR to fix this issue[6], but that was never accepted, since
> there would be no more releases to version 3[7].
>
> The liquibase-slf4j package[4] has an upgrade to liquibase 4.
>
> What I have tried, so far, is:
>  1. Bump liquibase to 4.x and bump the liquibase-slf4j package to a
> version supporting liquibase 4
>  2. Bump liquibase to 4.x and drop liquibase-slf4j altogether (hoping
> the java.util.logging (that is the liquibase 4.x default) would
> automagically find its way to karaf.log
>
> But in neither case logging from liquibase appeared in karaf.log.
>
> All ideas for how to debug this further would be welcome.
>
> A ready made solution for using liquibase 4.x would be even more
> welcome! :-)
>
> Thanks again!
>
>
> - Steinar
>
>
> REFERENCES:
> [1] 
> [2] 
> [3] 
> [4] <
> https://github.com/liquibase/liquibase/releases/tag/liquibase-parent-3.1.1
> >
> [5] 
> [6] <
> https://github.com/liquibase/liquibase/issues/1254#issuecomment-699611630>
> [7] <
> https://github.com/liquibase/liquibase/issues/1254#issuecomment-985743534>
>
>

Re: Problems with logging to karaf.log from liquibase >3

[Jakub Herkel]

I prepared some fixes for liquibase 3.7 but there was an another osgi
related error. So maybe you can check liquibase 4.8.1 when it is
released

Jakub

On Thu, Mar 10, 2022 at 6:23 AM Jean-Baptiste Onofré  wrote:
>
> Hi Steinar,
>
> I'm sorry, I never tried liquidbase in Karaf.
>
> JUL is supported by pax-logging, so I think your approach wrapping core and 
> slf4j in a bundle makes sense.
>
> I can try your feature to check and eventually create a bundle at SMX and 
> corresponding Karaf in enterprise feature.
>
> Regards
> JB
>
> On Wed, Mar 9, 2022 at 9:59 PM Steinar Bang  wrote:
>>
>> I've been stuck on liquibase 3.0.8 since November 2019 (heh! Since
>> before corona...!), because I've been unable to make later versions log
>> to karaf.log.
>>
>> But now I'm getting security warnings for liquibase 3, and the only way
>> out is to upgrade.
>>
>> Does anyone else have a working setup for a recent version of liquibase?
>>
>> In particular: does logging to karaf.log work?
>>
>> Thanks!
>>
>> The full story:
>>
>> Liquibase originally had an extra adapter for logging, that used
>> reflection to scan for an adapter implementation. And that posed a
>> problem when using OSGi classloader.
>>
>> Thanks to help from the karaf user mailing list[1], I was able to make
>> an existing project[2] into a bundle fragment and attach it to my
>> liquibase bundles.
>>
>> I improved that approach into a handwritten karaf feature and a
>> repacking of [2], in[3].
>>
>> And this worked find for me until I came to liquibase 3.1.1[4], and then it
>> started failing for me.  It failed in a funny way, because the snapshots
>> I built myself worked fine, but the releases from maven central failed.
>>
>> I eventually traced this down to an issue caused by the releases being
>> built by java8 and me running with java11[5].
>>
>> I provided a PR to fix this issue[6], but that was never accepted, since
>> there would be no more releases to version 3[7].
>>
>> The liquibase-slf4j package[4] has an upgrade to liquibase 4.
>>
>> What I have tried, so far, is:
>>  1. Bump liquibase to 4.x and bump the liquibase-slf4j package to a
>> version supporting liquibase 4
>>  2. Bump liquibase to 4.x and drop liquibase-slf4j altogether (hoping
>> the java.util.logging (that is the liquibase 4.x default) would
>> automagically find its way to karaf.log
>>
>> But in neither case logging from liquibase appeared in karaf.log.
>>
>> All ideas for how to debug this further would be welcome.
>>
>> A ready made solution for using liquibase 4.x would be even more
>> welcome! :-)
>>
>> Thanks again!
>>
>>
>> - Steinar
>>
>>
>> REFERENCES:
>> [1] 
>> [2] 
>> [3] 
>> [4] 
>> 
>> [5] 
>> [6] 
>> 
>> [7] 
>> 
>>

Re: Problems with logging to karaf.log from liquibase >3

[Jean-Baptiste Onofré]

Hi Steinar,

I'm sorry, I never tried liquidbase in Karaf.

JUL is supported by pax-logging, so I think your approach wrapping core and
slf4j in a bundle makes sense.

I can try your feature to check and eventually create a bundle at SMX and
corresponding Karaf in enterprise feature.

Regards
JB

On Wed, Mar 9, 2022 at 9:59 PM Steinar Bang  wrote:

> I've been stuck on liquibase 3.0.8 since November 2019 (heh! Since
> before corona...!), because I've been unable to make later versions log
> to karaf.log.
>
> But now I'm getting security warnings for liquibase 3, and the only way
> out is to upgrade.
>
> Does anyone else have a working setup for a recent version of liquibase?
>
> In particular: does logging to karaf.log work?
>
> Thanks!
>
> The full story:
>
> Liquibase originally had an extra adapter for logging, that used
> reflection to scan for an adapter implementation. And that posed a
> problem when using OSGi classloader.
>
> Thanks to help from the karaf user mailing list[1], I was able to make
> an existing project[2] into a bundle fragment and attach it to my
> liquibase bundles.
>
> I improved that approach into a handwritten karaf feature and a
> repacking of [2], in[3].
>
> And this worked find for me until I came to liquibase 3.1.1[4], and then it
> started failing for me.  It failed in a funny way, because the snapshots
> I built myself worked fine, but the releases from maven central failed.
>
> I eventually traced this down to an issue caused by the releases being
> built by java8 and me running with java11[5].
>
> I provided a PR to fix this issue[6], but that was never accepted, since
> there would be no more releases to version 3[7].
>
> The liquibase-slf4j package[4] has an upgrade to liquibase 4.
>
> What I have tried, so far, is:
>  1. Bump liquibase to 4.x and bump the liquibase-slf4j package to a
> version supporting liquibase 4
>  2. Bump liquibase to 4.x and drop liquibase-slf4j altogether (hoping
> the java.util.logging (that is the liquibase 4.x default) would
> automagically find its way to karaf.log
>
> But in neither case logging from liquibase appeared in karaf.log.
>
> All ideas for how to debug this further would be welcome.
>
> A ready made solution for using liquibase 4.x would be even more
> welcome! :-)
>
> Thanks again!
>
>
> - Steinar
>
>
> REFERENCES:
> [1] 
> [2] 
> [3] 
> [4] <
> https://github.com/liquibase/liquibase/releases/tag/liquibase-parent-3.1.1
> >
> [5] 
> [6] <
> https://github.com/liquibase/liquibase/issues/1254#issuecomment-699611630>
> [7] <
> https://github.com/liquibase/liquibase/issues/1254#issuecomment-985743534>
>
>