I'm happy to say that I've made the first release of my liquibase karaf
feature in nearly three years (the previous release was liquibase 3.8.0
in November 2019).
The current version is 4.15.0
https://github.com/steinarb/liquibase-karaf-feature#release-history
I've summarized the things needed
> 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
>
> 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
> 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
> 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
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
> 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...?
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
> 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
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
> 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:
> 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
> 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
> 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
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
> 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
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}
> 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
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,
> >
> 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;
>
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;
> 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
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 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
> 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
> 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
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
> 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
Hi Steinar,
Some pseudo-code :
JdbcConnection connection = new JdbcConnection(myConnection);
Database database =
DatabaseFactory.getInstance().findCorrectDatabaseImplementation(connection);
ChangeLogParameters changeLogParameters = new ChangeLogParameters(database);
String liquibaseFilePath =
> 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
> 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
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
> 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:
> 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!
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é :
>
>
> 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
> 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?
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
> 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:
>
>
> 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
> 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
> 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
> 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:
>
> 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
> 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!
> 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
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
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
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
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
50 matches
Mail list logo
