Load XSD files under OSGI

[jherkel]

A few months ago Liquibase changed default policy for loading XSD files (global option "secureParsing"). But there is a problem with loading XSD files from jar archive under OSGI via existing solution. Probably a better way for this case would be trying to load resources via existing ResourceAccessor and in case that openStreams() returns empty InputStreamList we would try to load a resource directly via getEntry for liquibase-core bundle.

Copy javadoc for Bundle.getEntry :

Returns a URL to the entry at the specified path in this bundle. This bundle's classloader is not used to search for the entry. Only the contents of this bundle are searched for the entry.

The specified path is always relative to the root of this bundle and may begin with "/". A path value of "/" indicates the root of this bundle.

Environment : Liquibase 4.9.1, Java 17, Karaf 4.3.6

[nvoxland]

Fixed by #2830

[ponziani]

@nvoxland, I think you may have misunderstood the exact issue here. As far as I can tell the issue was not fixed by #2830

@jherkel, can you confirm this ?

[jherkel]

I also think that this problem wasn't fixed by #2830. By I have a workaround for this via disabling "secureParsing" option.

[nvoxland]

Are either of you able to tell what the actual fix would be?

I'm not super knowledgable with osgi to know the right solution without a bit of research

[ponziani]

A fix was proposed by @jherkel in his initial post, but the solution we are using right now is the replacement of this code

ResourceAccessor resourceAccessor = Scope.getCurrentScope().getResourceAccessor();
InputStreamList streams = resourceAccessor.openStreams(null, path);

By this code

ResourceAccessor currentScopeResourceAccessor = Scope.getCurrentScope().getResourceAccessor();
ClassLoaderResourceAccessor classLoaderResourceAccessor = new ClassLoaderResourceAccessor(getClass().getClassLoader());
InputStreamList streams = new CompositeResourceAccessor(currentScopeResourceAccessor, classLoaderResourceAccessor).openStreams(null, path);

in class LiquibaseEntityResolver.

#3378

[GeertZondervan]

Are either of you able to tell what the actual fix would be?

I'm not super knowledgable with osgi to know the right solution without a bit of research

I think the correct solution would be to simply export the package containing the XSD's in the OSGI bundle, this must be specified in the MANIFEST.MF.

The problem is that XSD files can not be loaded from the liquibase-core.jar in an OSGI environment (using the OSGiResourceAccessor).

Currently the liquibase-core.jar contains two directories (packages). liquibase and www.liquibase.org. ONLY the liquibase package and it's sub-packages are being exported in the MANIFEST.MF. This means the XSD files, which are all under www.liquibase.org.xml.ns.dbchangelog, can not be accessed in an OSGI environment.

If we simply tell the maven-bundle-plugin (in the liquibase-core pom.xml) to also export the www.liquibase.org.xml.ns.dbchangelog package, the bundle-plugin will include this in the Export-Package header of the MANIFEST.MF file.

The reason why the XSD's are not exported in the MANIFEST.MF right now is because currently no Export-Package tag is specified in the maven-bundle-plugin instructions. This means the default behavior of the maven-bundle-plugin is used:

Export-Package> is now assumed to be the set of packages in your local Java sources, excluding the default package '.' and any packages containing 'impl' or 'internal'. (before version 2 of the bundleplugin it was based on the symbolic name)

See: https://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html#_default_behavior

The XSD's have been moved to /src/main/recources, so they are not automatically included in the export.

I've added a pull request with the solution.

[nvoxland]

Thanks for the info and the additional PR. I'll move this issue along and see about getting a combined PR that pulls together the various PRs into something complete that we can get feedback on.