-
Notifications
You must be signed in to change notification settings - Fork 9
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
Additional @Decimal annotations generated for xs:int #17
Comments
Hi @Undover , The XSD specifications allow for a lot of numeric types which are not present in java (i.e. Please see the Regards |
I've looked around and want to clarify things further, the generated Numeric class contains two fields |
The parsing of the XSD is done by the XSOM package invoked by JAXWS, for each defined type it fills the |
As for the future it's hard to tell but the XSOM library is very mature and the tests present in here will fail if anything should change. |
Hi, to clarify
according to the int specs:
Because a Java int is a 32 bit signed value (from -2147483648 to 2147483647) it aligns with the XSD int specification so no further constraints are required. Same for xsd:long that is converted into a 64 bit signed Java type. |
Hi @fillumina , I’m encountering the same issue as @Undover . As mentioned, the You mentioned that no further constraints are required, but the problem is that int does have the validation annotations generated, which is causing confusion and, in my case, is problematic. Is there any way to disable these validation annotations for int fields? If this behavior is not toggleable, it could pose significant issues for us. Thanks in advance for your help! |
This is what's confusing to me, as both |
That's right, I have finally understood the inconsistency between int and long (it was a check made only for long), I am fixing it by removing all default constraints and setting an option to add them back if needed. |
Hello,
I'm in the process of migrating a project from javax to jakarta, and I've noticed some changes in how validations are generated for
xs:int
types.This is part of the schema used for testing:
Classes generated with this schema differ between
com.github.krasa:krasa-jaxb-tools:1.5
andcom.fillumina:krasa-jaxb-tools:2.3.3
(among other dependency upgrades required for jakarta migration).Before:
After:
What caught my attention is the generation of
@DecimalMin(value = "-2147483648", inclusive = true)
and@DecimalMax(value = "2147483647", inclusive = true)
whenever a restriction is not specified forxs:int
type, which is not the case forxs:long
type, so if it's not a bug I assume something's wrong with my configuration.Used flags for
org.apache.cxf.tools.wsdlto.WSDLToJava
:In case of trouble with reproducing the issue, I could provide a sample project.
Thanks in advance
The text was updated successfully, but these errors were encountered: