Micronaut Serialization is too aggressive and breaks old HTTP clients

[musketyr]

Expected Behavior

HTTP clients using new Micronaut Serialization with @Serdable annotation should be able to coexist with the legacy HTTP clients that uses beans that are only annotated with @Introspected annotation.

Actual Behaviour

Whenever the Micronaut Serde library is on the classpath (even as transient dependency) then all HTTP clients not using @Serdable start failing.

In a large codebase with many HTTP clients is this behavior too aggressive.

Steps To Reproduce

1. checkout https://github.com/musketyr/micronaut-serialization-too-aggressive
2. run NormalClientTest

This is a simplified version of having a legacy HTTP client and a transitive dependency on Micronaut Serde.

Environment Information

Java 17

Example Application

https://github.com/musketyr/micronaut-serialization-too-aggressive

Version

4.1.5, 3.10.1

[graemerocher]

probably we need to change bean ordering so that if micronaut-jackson-databind is on the classpath it takes over

[graemerocher]

As a workaround you can specify packages of introspections that are compatible:

micronaut.serde.included-introspection-packages=com.example,io.micronaut

At least this makes the tests pass for me

[sdelamo]

or import the classes with @SerdeImport

[musketyr]

I think this is misunderstanding of the situation @sdelamo. If I understand it properly then @SerdeImport would have to be used for every class used as request or response for any HTTP client and this is exactly the thing I'm trying to avoid as there is too many existing HTTP clients.

[sdelamo]

If you want to use Micronaut serialization, you have to opt-in the classes that are serializable. This is a design decision of Micronaut serialization. It is an opt-in serialization approach.

If you want everything to serializable by default without opt-in you should use Micronaut Jackson Databind via the io.micronaut:micronaut-jackson-datatbind dependency.

[musketyr]

I think we are still on a different page @sdelamo. The point is if you have a library that uses io.micronaut:micronaut-jackson-databind without any Serdeable annotations then the library works as expected. But if you use the very same library in an application that has Micronaut Serialization on the classpath then the library stop working because the Micronaut Serialization wins over the Jackson implementation and starts requiring to have Serdeable annotation everywhere.

[sdelamo]

I think we are still on a different page @sdelamo. The point is if you have a library that uses io.micronaut:micronaut-jackson-databind without any Serdeable annotations then the library works as expected. But if you use the very same library in an application that has Micronaut Serialization on the classpath then the library stop working because the Micronaut Serialization wins over the Jackson implementation and starts requiring to have Serdeable annotation everywhere.

yes, I understand. if you consume a library that it is not prepared for Micronaut serialization and you want some of the types exposed by the library to be serializable by Micronaut Serialization you have to mark those types as serializable. That it is by design. We have done that for example for the AWS Lambda Events Library.

https://github.com/micronaut-projects/micronaut-aws/tree/master/aws-lambda-events-serde/src/main/java/io/micronaut/aws/lambda/events/serde

[musketyr]

hi @sdelamo, sorry for late response but we are still not on the same page. I don't want to make any library to be compatible with Micronaut Serialization. I just want to keep things working as they were (using good old Jackson) even the Micronaut Serializable is on the classpath. We have 100+ HTTP clients in the repository and we can't migrate all of them at once so we need Micronaut Serialization to coexist with the existing clients gracefully to be able to iteratively migrate them without breaking the non-migrated ones.

[sdelamo]

hi @sdelamo, sorry for late response but we are still not on the same page. I don't want to make any library to be compatible with Micronaut Serialization. I just want to keep things working as they were (using good old Jackson) even the Micronaut Serializable is on the classpath. We have 100+ HTTP clients in the repository and we can't migrate all of them at once so we need Micronaut Serialization to coexist with the existing clients gracefully to be able to iteratively migrate them without breaking the non-migrated ones.

what I would recommend you is to use Micronaut Jackson Databind instead of using Micronaut Serialization for your use case.

[musketyr]

Yes, that's what we have done right now.

[xpdota]

I'm running into a similar issue here, but for a different reason. My API project worked fine with Jackson serialization. But then I added the micronaut-object-storage-oracle-cloud dependency, which in turn depends on Micronaut Serialization. I haven't found a way to force it to use Jackson, and excluding the micronaut-serde-api dependency causes Oracle object storage to break in turn.

Edit: figured it out:

	@Singleton
	@Primary
	@Replaces(JsonMapper.class)
	public JsonMapper jsonMapper(JacksonDatabindMapper mapper) {
		return mapper;
	}

[sdelamo]

@xpdota I don't find the dependency of object-storage to serde. Do you have a sample app?