Skip to content

Conversation

@lilgallon
Copy link
Member

@lilgallon lilgallon commented Sep 28, 2025

Migration guide

To keep the same behavior as before (after merging this), add:

// runtimeClasspath is enough, you probably should not need it directly in your code
// if it's the case, it either means our API has flaws (you can open an issue if it's
// the case) or because you are not using the right `OcpiSerializer` method for your
// use case (see below)
runtimeClasspath("com.izivia:ocpi-2-2-1-jackson:<version>")

And mapper package changed

import com.izivia.ocpi.toolkit.common.mapper // before
import com.izivia.ocpi.toolkit.serialization.mapper // after

And its functions changed, because it's generic now

// before
mapper.writeValueAsString(value)
// after
import com.izivia.ocpi.toolkit.serialization.serialize
mapper.serialize(value) 

// before
mapper.writeValueAsString(value, class)
// after
mapper.serializeObject(value, class) 

// before
mapper.readValue(value, class)
// after
mapper.deserializeObject(value, class) 

// before
mapper.readValue<XX>(value)
// after
mapper.deserializeObject<XX>(value) 

// before
mapper.readValue<XX>(value, jacksonTypeDef)
// after
import com.izivia.ocpi.toolkit.serialization.serialize
mapper.deserializeOcpiResponse<XX>(value) // use the right specific method

Otherwise, no breaking change is expected. The mapper behavior stays the same.

Use your own mapper (serializer implementation)

Add a file in: META-INF/services/com.izivia.ocpi.toolkit.serialization.OcpiSerializer specifying where your OcpiSerializer implementation is located, and don't import com.izivia:ocpi-2-2-1-jackson

Description

I added plenty of mapping tests for each OCPI data structure, and made sure exception were taken into account:

  • Enums.OTHER: deserialized as OTHER if unknown enum
  • Connector.tariffIds: ignore null values

closes #168

@lilgallon lilgallon force-pushed the feat/#168-pluggable-serialization-support branch 3 times, most recently from 0338499 to c47cd77 Compare September 28, 2025 18:52
@lilgallon lilgallon changed the title feat #168: create serialization interfaces feat #168: pluggable serialization support (with jackson for now) Sep 28, 2025
@lilgallon lilgallon changed the base branch from main to chore/#171-bump-libs-and-gradle September 28, 2025 18:53
@lilgallon lilgallon force-pushed the chore/#171-bump-libs-and-gradle branch from 92abbc8 to 17d6980 Compare September 30, 2025 09:03
@lilgallon lilgallon force-pushed the feat/#168-pluggable-serialization-support branch from c47cd77 to a8bd369 Compare September 30, 2025 09:06
@lilgallon
Copy link
Member Author

Testing internally, this feature did not introduce any regression according to our tests. It's ready for final review

@lilgallon lilgallon linked an issue Oct 1, 2025 that may be closed by this pull request
@lilgallon lilgallon force-pushed the feat/#168-pluggable-serialization-support branch 5 times, most recently from 61d0d16 to 3210380 Compare October 8, 2025 19:28
@lilgallon lilgallon changed the base branch from chore/#171-bump-libs-and-gradle to main October 22, 2025 17:51
@lilgallon lilgallon force-pushed the feat/#168-pluggable-serialization-support branch from 3210380 to 574f410 Compare October 22, 2025 17:51
@lilgallon lilgallon merged commit 5035a39 into main Oct 22, 2025
1 check failed
@sonarqubecloud
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add pluggable serialization support

3 participants