karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steinar Bang ...@dod.no>
Subject Re: Experiences with karaf and liquibase?
Date Sat, 27 May 2017 06:12:53 GMT
>>>>> Castor <ygorcastor@gmail.com>:

> Exactly! It's a classpath problem, liquibase uses a weird approach to swap
> his crappy log system to use slf4j, it scans a classpath and "swaps" the
> reference.

Yes, I know.  I figured it out eventually with the help of this[1].

Note that in a comment in that article, the liquibase maintainer says
liquibase 4.0 will support slf4j.  However the 4.0 branch of liquibase
hasn't been touched for 2 years[2], so that is probably not going to
happen...?  The most recent work on liquibase has been happening on the
3.5 branch, that still uses the proprietary logging.

> When you install liquibase and liquibase-slf4j as separated bundles,
> the liquibase bundle does not look for the liquibase-slf4j exported
> packages, and when you make the liquibase-slf4j a fragment of
> liquibase, the liquibase bundle can scan the liquibase-slf4j
> classpath.

Hm... but by this description my most recent experiment, which is to add
a package liquibase:ext:logging to the bundle that runs liquibase, and
add my own subclass of AbstractLogger there, should have worked as

And when I've stopped to think about it, and with the above information
I think I know why it didn't work for me:
 - Right now I'm using liquibase as a library bundle
 - I need to expose my code that uses liquibase as an OSGi service, and
   call that service from the other bundles that use liquibase.

Here's what I've done
 - I have a project that uses this interface as an OSGi service, to be
   able to switch between two database implementations[3]
 - The OSGi service is implemented by a derby test database and a
   postgresql production database
 - I have added a new bundle that
    - Embeds the liquibase changeset for the schema
    - Added a class with a single method that takes a PooledConnection
      argument, and updates the database with the schema from the
      embedded changeset
 - In the bundle that implements the database service for the derby
   database, I do the following at startup, after aquiring a database
    - Create an instance of the class from the new bundle (ie. inside
      the derby database bundle), and use it to create the schema
    - Directly use the liquibase code to run liquibase changesets
      containing test data, that have been embedded in the derby
 - In the bundle that implements database service for the postgresql
   database I create an instance of the class from the new bundle and
   use it to create/update the schema

(I haven't pushed any of the above changes yet. I still keep thinkering
with them.  The annyoing bit here is that it actually works, ie. the
hard part, creating the database schema, works.  But the karaf console
is cluttered by the liquibase logs)

Anyway, what I think I need to do is to make my liquibase schema creator an OSGi
service and call that service from the derby and postgresql bundles.

I will try that.

> This happens quite a lot when you work with libraries that works with
> classpaths and weren't created with osgi in mind, a pain in the a** if you
> ask me.

Agreed! :-/

Thanks for your insights.  They were helpful.

[1} <http://www.bennybottema.com/2013/12/29/fixing-liquibase-logging-in-spring/>
[2} <https://github.com/liquibase/liquibase/tree/4.0.x>
[3} <https://github.com/steinarb/ukelonn/blob/master/ukelonn.api/src/main/java/no/priv/bang/ukelonn/UkelonnDatabase.java>

View raw message