[Bug] Java callbacks are not logged to console - but they do run

[pyrocks]

Hi,

java callbacks run correctly but are never logged to console like SQL callbacks, not even in debug mode.
Here's a minimalistic reproduction:

#src/main/java/db/callback/AfterMigrate__Test.java

package db.callback;

import org.flywaydb.core.api.callback.Callback;
import org.flywaydb.core.api.callback.Context;
import org.flywaydb.core.api.callback.Event;
import org.flywaydb.core.api.logging.Log;
import org.flywaydb.core.api.logging.LogFactory;

public class AfterMigrate__Test implements Callback {
    private static final Log LOG = LogFactory.getLog(AfterMigrate__Test.class);

    @Override
    public boolean supports(Event event, Context context) {
        return event == Event.AFTER_MIGRATE;
    }

    @Override
    public boolean canHandleInTransaction(Event event, Context context) {
        return true;
    }

    @Override
    public void handle(Event event, Context context) {
        LOG.info("In java callback AfterMigrate__Test");
    }

    @Override
    public String getCallbackName() {
        return "Test";
    }
}

#src/main/resources/db/migration/afterMigrate__SQLTest.sql

DO $$ BEGIN RAISE NOTICE 'In SQL callback afterMigrate__SQLTest'; END $$;

#pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.example</groupId>
    <artifactId>flyway-java-callback-repro</artifactId>
    <version>1.0-SNAPSHOT</version>

    <properties>
        <flyway.version>12.6.1</flyway.version>
        <maven.compiler.source>17</maven.compiler.source>
        <maven.compiler.target>17</maven.compiler.target>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.flywaydb</groupId>
            <artifactId>flyway-core</artifactId>
            <version>${flyway.version}</version>
            <scope>provided</scope>
        </dependency>
    </dependencies>
</project>

#flyway.conf

flyway.locations=filesystem:src/main/resources/db/migration

Versions: OSS 11.15.0 and latest 12.6.1

Actual result:

> mvn package
... 
>flyway -jarDirs=target migrate
Flyway OSS Edition 12.6.1 by Redgate

See release notes here: https://help.red-gate.com/help/flyway-cli12/help_6.aspx?topic=release-notes-and-older-versions/release-notes-for-flyway-engine
Database: jdbc:postgresql://localhost:5432/test (PostgreSQL 16.8)
Successfully validated 0 migrations (execution time 00:00.047s)
WARNING: No migrations found. Are your locations set up correctly?
Current version of schema "public": << Empty Schema >>
Schema "public" is up to date. No migration necessary.
Executing SQL callback: afterMigrate - SQLTest
DB: In SQL callback afterMigrate__SQLTest
In java callback AfterMigrate__Test
>

Expected result:

...
Executing SQL callback: afterMigrate - SQLTest
DB: In SQL callback afterMigrate__SQLTest
Executing Java callback: afterMigrate - Test      // this line is missing
In java callback AfterMigrate__Test

[pyrocks]

I let claude analyze the source code and this is what it found:

Found it. The culprit is in DefaultCallbackExecutor.java — handleEvent():

SQL callbacks (SqlScriptCallbackFactory.java, inner class SqlScriptCallback.handle()):

LOG.info("Executing SQL callback: " + event.getId()
+ (description == null ? "" : " - " + description) ...);
Java callbacks (DefaultCallbackExecutor.java, handleEvent()):

// Sets up a telemetry span, then immediately calls:
callback.handle(event, context);
// No LOG.info before it — nothing is emitted
So this is a deliberate asymmetry in Flyway's source: SQL and script callbacks both get a LOG.info("Executing ... callback: ...") line before execution; the Java callback dispatcher has no such call. To get parity you'd need a LOG.info("Executing Java callback: " + event.getId() + " - " + callback.getCallbackName()) added before the callback.handle() call in DefaultCallbackExecutor.handleEvent(). That would be a Flyway upstream contribution.