LiquiBase bundle and the OSGi extender model

Liquibase Development
1

Hello list,

I’m new here in the forum, but not new to LiquiBase. I’m already using it in some of my projects, always sucessfully. Now I’m starting a new project, using the OSGi Framework, and I saw some work done already in this path, here: http://liquibase.jira.com/browse/CORE-433.

I would like to suggest a new approach, maybe a new way to run the changelogs: the OSGi extender model: http://www.osgi.org/blog/2007/02/osgi-extender-model.html. I want to know if there is interest in this approach and if anyone already did something alike.

Probably I will try to implement this model for my project, and then, post here the results. But first I would like to hear the community experience.

Thanks in advance!

2

Welcome!

I have not really looked at OSGi much, including the extender model.  I don’t know of anyone else looking into it, if you get a chance to we would love to hear your results.

Nathan

3

Hello,

Unfortunately Liquibase 2 doesn’t work correct on OSGi, see http://liquibase.jira.com/browse/CORE-504
There is problem with code looking for extensions - it tries to translate classpath url to file (to get entries from jar or list files from directory) which is not possible using OSGi.
So ServiceLocator.findClasses should recognize protocol “bundle:” and in such case get correct Bundle and scan it using Bundle.getEntryPaths(String)

Actually, current ServiceLocator implementation use something like Extender Model - it reads “LiquiBase-Package” header from Manifest.mf and load classes from given packages.
For completness:

  • Liquibase should detect new installed bundles (as (Synchronous)BundleListener)
  • some classloading issues should be fixed (for example in OSGi calls to Class.forName should pass classloader). Also static singletons are not recommended.
  • all packages with classes loaded by ServiceLocator - including core extensions, should be declared in Manifest.mf

I’m not sure if extender model would be good for reading changeset files.

There is also possibility to create OSGi service with liquibase instance exported for other bundles (something like spring bean). It may use (import) DataSource exported as a service.

Another issue using OSGi is that the same packages (package names) should not occur in many bundles. It is so called “split-packages” and is difficult to use.
So any non-core Liquibase extensions should not be in liquibase.* packages - its  opposite to curent recommendations in documentation.

I have no time to code functionality mentioned above, but gladly help with any OSGI related issues or questions.

4

Hi Damian,

As Nathan I haven’t looked too much to OSGI and before looking to do something I’ve avery newbie question:

If we try to implement a ServiceLocator as you mention then that code will also be able to run outside a OSGI container or we need to have “duplicated” to solve the case when running inside or outside an OSGI container?