pjfanning opened a new pull request, #100:
URL: https://github.com/apache/poi-xmlbeans/pull/100
Started as the `StscTranslator.buildBigInt` item — parse the numeric facets
of a schema under the configured limit rather than the hardcoded default.
Tracing it showed `buildBigInt` was never even reached, and two paths on the
way to it threw instead of reporting.
### 1. `buildBigInt` used the default limit — `StscTranslator:1515`
`totalDigits`, `maxLength` and the other numeric facets are numbers in a
schema document, and schemas are input too — in `scomp`, `xsd2inst` and
downloaded imports, not always trusted ones. `StscState.setOptions` already
receives the `XmlOptions` and keeps a handful of fields, so
`_maxNumberOfCharsForNumbers` joins them.
### 2. Schema validation dropped the options — `SchemaTypeSystemCompiler:228`
```java
XmlOptions validateOptions = new XmlOptions().setErrorListener(errorWatcher);
if (options != null && options.isValidateTreatLaxAsSkip()) { ... }
```
A fresh `XmlOptions` carrying the error listener and one flag, so the limit
never reached the validation pass that runs over the schema documents. This is
what made 1 unreachable: validation failed on the facet before compilation
looked at it.
### 3. `validate()` threw instead of reporting — `Validator:1113`
Not schema-specific. `validateAtomicType` parsed the decimal outside the
`ValidationContext`:
```
XmlInteger 2000-digit .validate() -> IllegalArgumentException: Number has
more than 1024 characters
XmlDecimal 2000-digit .validate() -> IllegalArgumentException: Number has
more than 1024 characters
XmlDouble 2000-digit .validate() -> returned false, 1 error
```
`xs:double` behaves correctly because `JavaDoubleHolderEx.validateLexical`
takes the limit and reports through the context. The decimal branch never got
the same treatment: the lexical check preceding it validates characters but not
length, so nothing is reported and the parse throws. `validate()` is the method
that says what is wrong with a document — a number past the limit is bad input
like any other and now comes back as an error.
### 4. `buildBigInt` threw while materialising the facet —
`StscTranslator:1512`
`value.getStringValue()` sat outside the method's own `try`, and it can fail
in its own right: it triggers the lazy `set_text` on the facet's typed value
under the schema document's limit. A schema loaded with a lower limit than the
number it declares threw `XmlValueOutOfRangeException` out of `compileXsd`.
Moved inside.
### Note on raising the limit
The limit is fixed when a document is loaded, so a schema has to be *parsed*
with the raised options as well as compiled with them. Passing raised options
only to `compileXsd` leaves the schema document itself on the default, and the
facet is rejected when its text is materialised — now as a reported error
rather than a thrown one. The tooling paths already pass one `XmlOptions` to
both.
### Tests
`testValidateReportsAnOverLongNumber` covers 3 for `xs:integer` and
`xs:decimal`. `testSchemaCompileHonoursLimit` covers 1 and 2 — a schema whose
`maxLength` facet is 2000 digits compiles under `maxChars(4096)` and is
reported invalid under the default.
Full suite: 3090 tests, 0 failures.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
