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.<clinit>(DatabaseFactory.java:20)
... 21 more
Best regards,
Steven
On Fri, Aug 5, 2022 at 2:23 PM Steinar Bang <[email protected]> wrote:
> >>>>> Steven Huypens <[email protected]>:
>
> > 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?
>
>
