jerinraj5555 commented on PR #35: URL: https://github.com/apache/sling-org-apache-sling-scripting-core/pull/35#issuecomment-4341448277
Thank you for testing this — the difference comes down to which converter
implementation is on the classpath.
The failure is version-specific to org.osgi.util.converter:1.0.9
When you run locally or on Jenkins, org.apache.felix.converter:1.0.14 (or
a newer osgi.util.converter) is resolved, which handles the null → String[]
conversion correctly. The bug only
manifests with org.osgi.util.converter:1.0.9.
To reproduce the exact failure, force org.osgi.util.converter:1.0.9 onto
the classpath (not felix.converter) and run:
` final String[] engineNames =
Converters.standardConverter().convert(null).to(String[].class);
// → ClassCastException: [Ljava.lang.Object; cannot be cast to
[Ljava.lang.String; (Java 21) `
**Our environment: AEM 6.5 LTS SP2**
AEM 6.5 LTS SP2 ships org.osgi.util.converter:1.0.9 baked directly inside
uber-jar:6.6.2 as embedded classes. In that container 1.0.9 always wins over
any test-scoped felix.converter
because it is inside the fat JAR — not a separate resolvable artifact.
That is the exact environment where this causes 100+ test failures on Java 21 —
every test that initialises a
Sling mock context hits this code path.
Why the null-check still makes sense
The fix bypasses the Converters API entirely when the property is null,
which is the valid and common case for generic BindingsValuesProvider services
that apply to all script engines.
This makes ContextBvpCollector safe regardless of which converter version
is present at runtime — important for AEM and any other container that embeds
1.0.9 and cannot easily replace
it.
--
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]
