-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove XMLGregorianCalendar in favor of java.time.* #36
Comments
I've just commented the reason in #34 The migration of XMLGregorianCalendar to java.time is a good idea. Will find some time to explore it and include it in the code generation with backward compatibility (deprecation of existing code, if possible). |
Cool! 👍 The Also, I guess backwards compatibility for setters would be possible with method overloading, but not for the getters. |
…/unmarshalling (#44) * Added adapters for date time, time, and date in the model via annotations * Added default adapters implementations with different options to customize * Added default adapters for jaxb when no other is set * Refactored the xml and message serialization methods with a DTO parameter
In release 9.2.6 I've added a way to customize the date time, time and date elements with custom adapters. The model is annotated with a default implementation for the IsoDateTime, IsoTime and IsoDate types. Where the default adapter classes are actually a wrapper. Then a default implementation is provided for each type, but anyone can tweak the default or inject its own class. The way to configure this is by some new parameters in the marshaling and unmarshalling API. For example:
Default adapters use zoned local time (offset always present) for date time and time. Since these days that's what most infrastructures and CUGs require (for example CBPR+). I think the wrapper approach is is quite flexible, and should cover most of the use cases for now. Changing the XMLGregorianCalendar in the model for new java time classes would be a compile breaking change, so that will need to wait for a major release, probably along a SRU yearly update. Regards |
XMLGregorianCalendar is a pain to use and nowadays, it is much more common to bind JAXB classes to some type of java.time.* variant.
For example, including this in the JAXB code generation:
Is there any reason the JAXB generation is not included in the source code so that others could manipulate the generated code as well (for example, to add in a builder pattern, etc.)?
The text was updated successfully, but these errors were encountered: