[#675] add new disableJaxpLimits configuration parameter

[laurentschoelens]

Fixes #675

[mattrpav]

My initial reaction is this is a bad idea to disable all security settings with one config flag that differs from property keys+values that need to be used at runtime.

If a user needs to generate a classes from schema, will they also not need to update these flags in their runtime environment?

Also, disabling all the flags when only one may be needed seems to be overreaching for security purposes.

I think a better approach would be more clearly document these values and/or add a section for setting these system parameters in the jaxb plugin.

Example:

<systemProperties>
   <systemProperty key="jdk.xml.entityExpansionLimit" value="256" />
   <systemProperty key="jdk.xml.elementAttributeLimit" value="256" />
    ..

Ref: All values

jdk.xml.elementAttributeLimit
jdk.xml.entityExpansionLimit
jdk.xml.entityReplacementLimit
jdk.xml.maxElementDepth
jdk.xml.maxGeneralEntitySizeLimit
jdk.xml.maxOccurLimit
jdk.xml.maxParameterEntitySizeLimit
jdk.xml.totalEntitySizeLimit

[laurentschoelens]

My initial reaction is this is a bad idea to disable all security settings with one config flag that differs from property keys+values that need to be used at runtime.

I think this is not "security" flags but rather performance flags : as you can see in https://bugs.openjdk.org/browse/JDK-8343006 someone thought it should be a good idea to review these settings and lower all values, which was done in jdk24.

If a user needs to generate a classes from schema, will they also not need to update these flags in their runtime environment?

I dont quite know, maybe the user who created #675 could tell us more about that part too ?

Also, disabling all the flags when only one may be needed seems to be overreaching for security purposes.

Since the stacktrace is quite self-explanatory (at least this one is a good one), having settings per property is not worth enough (IMHO). I think having a flag that would disable all limits at once could be more useful or maybe define an enum (default, default_pre_jdk24, nolimit) in order to help users migrating to jdk25 (LTS) and no bother much about that kind of problems.

I think a better approach would be more clearly document these values and/or add a section for setting these system parameters in the jaxb plugin.

Example:

<systemProperties>
   <systemProperty key="jdk.xml.entityExpansionLimit" value="256" />
   <systemProperty key="jdk.xml.elementAttributeLimit" value="256" />
    ..

Ref: All values

jdk.xml.elementAttributeLimit
jdk.xml.entityExpansionLimit
jdk.xml.entityReplacementLimit
jdk.xml.maxElementDepth
jdk.xml.maxGeneralEntitySizeLimit
jdk.xml.maxOccurLimit
jdk.xml.maxParameterEntitySizeLimit
jdk.xml.totalEntitySizeLimit

Maybe the solution would be more a documentation improvment rather than making an evolution of the plugin itself ?

[mattrpav]

I think this is not "security" flags but rather performance flags : as you can see in https://bugs.openjdk.org/browse/JDK-8343006 someone thought it should be a good idea to review these settings and lower all values, which was done in jdk24.

This is a security setting -- prevent bad actors from inflating heap or causing too-many-objects that impact gc.

Maybe the solution would be more a documentation improvment rather than making an evolution of the plugin itself ?

I agree-- best we document and link to the JDK example -- change params via -D or use the jaxb.properties file as described by the JDK docs.

ref: https://docs.oracle.com/en/java/javase/25/docs/api/java.xml/module-summary.html#Conf

[laurentschoelens]

Wont fix since these limits could also show up at runtime and hiding them could be wrong