Panache adding @XmlTransient to fields breaks (de)serialization in RestAssured

[yrodiere]

Describe the bug

If I define an entity like so:

@Entity
@XmlRootElement(name = "myentity")
public class MyEntity extends PanacheEntity {
    public String field;

    public String getField() {
        return field;
    }

    public void setField(String field) {
        this.field = field;
    }
}

And use RestEasy classic with Jackson serialization in my resource:

    @GET
    @Path("/{id}")
    @Produces(MediaType.APPLICATION_JSON)
    public MyEntity get(@PathParam("id") Long id) {
        return MyEntity.findById(id);
    }

And try to use RestAssured's serialization in my tests:

        MyEntity deserializedEntity = given()
                .when().get("/hello/1")
                .then()
                .statusCode(200)
                .extract().body().as(MyEntity.class);
        assertThat(deserializedEntity).isNotNull();
        assertThat(deserializedEntity.getField()).isEqualTo("field-1");

Then everything on the server side will work fine, but RestAssured's serialization will always return an empty instance (all fields null).

NOTE: This example is admittedly contrived, but relevant because we have similar code in our integration tests that starts failing because of this bug in another PR of mine (#32876, that PR attempts to make Panache work on private fields as well).

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

See https://github.com/yrodiere/quarkus-playground/tree/panache-xml-transient

Output of uname -a or ver

No response

Output of java -version

No response

GraalVM version (if different from Java)

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

I have reasons to believe the problem is related to Panache adding @XmlTransient automatically to public fields it transforms:

@Entity
@XmlRootElement(
   name = "myentity"
)
@EnhancementInfo(
   version = "6.2.1.Final"
)
public class MyEntity extends PanacheEntity implements ManagedEntity, PersistentAttributeInterceptable, SelfDirtinessTracker {
   @XmlTransient
   protected String field;

   // [...]

   public String getField() {
      return this.$$_hibernate_read_field();
   }

   public void setField(String field) {
      this.$$_hibernate_write_field(field);
   }

   // [...]
}

Maybe the serialization that RestAssured relies on does not handle @XmlTransient correctly... Regardless, I think @XmlAccessorType(PROPERTY) would better fit Panache's intent, and may not cause this bug?

I'll try that and send a PR.

[quarkus-bot]

/cc @FroMage (panache), @loicmathieu (panache)

[yrodiere]

That being said, thinking about this, Panache probably shouldn't try to add or move annotations when the user defines both the field and getter already? I mean if they define it, let them configure it correctly...

[FroMage]

Maybe the serialization that RestAssured relies on does not handle @XmlTransient correctly...

I honestly don't know what it uses underneath. I've never used that.

Regardless, I think @XmlAccessorType(PROPERTY) would better fit Panache's intent, and may not cause this bug?

Perhaps? I think we have tests for that, but better make sure we do :)

That being said, thinking about this, Panache probably shouldn't try to add or move annotations when the user defines both the field and getter already? I mean if they define it, let them configure it correctly...

This sounds very reasonable, honestly.