Quarkus: Remove illegal refletive access warning for xstream for parameterized tests

[emmanuelbernard]

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.thoughtworks.xstream.core.util.Fields (file:/home/peter/.m2/repository/com/thoughtworks/xstream/xstream/1.4.11.1/xstream-1.4.11.1.jar) to field java.util.TreeMap.comparator
WARNING: Please consider reporting this to the maintainers of com.thoughtworks.xstream.core.util.Fields
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

[emmanuelbernard]

See #10271

[geoand]

This should be mostly fixed in 1.6.0.CR1.

But if it's not, then I can look into fixing it upstream.

[pschyma]

It does not appear in 1.6.0.CR1 for me. In 1.5.x I could observe it immediately after adding any @QuarkusTest to my Gradle projects which use RESTAssured.

[famod]

Hm, I am able to provoke this in 1.6.1.Final via:

public class FooParamResover implements ParameterResolver {

    @Override
    public boolean supportsParameter(final ParameterContext parameterContext, final ExtensionContext extensionContext) throws ParameterResolutionException {
        return parameterContext.getParameter().getType() == Foo.class;
    }

    @Override
    public Foo resolveParameter(final ParameterContext parameterContext, final ExtensionContext extensionContext) throws ParameterResolutionException {
        return new Foo();
    }
}

```java
public class Foo {

public String get() {
    return CDI.current().select(SomeBean.class).get().toString();
}

}

```java
    @Test
    public void test(final Foo foo) {
        System.err.println(foo.get());
    }

PS: The resolver is registered via META-INF/services/org.junit.jupiter.api.extension.Extension.

Reopen XOR new ticket?

[geoand]

Indeed that does provoke the message (it's known).

The problem used to be that the message was shown whether or not the was a parameter resolver.

I'd say reopen the issue but adjust the title.

[famod]

I am not allowed to change the title so I'd kindly ask you @geoand or @emmanuelbernard to do this. Thanks!

Btw, it has nothing to do with the CDI lookup (just checked), but you certainly knew that already. 😉

[famod]

Do we need a reproducer or is it obvious?

[geoand]

Nah, I think it's obvious.

The fix of course needs to be upstream in the xstream project

[famod]

The fix of course needs to be upstream in the xstream project

I fear that route doesn't look very promising: https://github.com/x-stream/xstream/issues/101

[famod]

I took a stab at this upstream: https://github.com/x-stream/xstream/pull/216

This won't help for certain scenarios (e.g. if your parameter class contains a TreeMap) but it removed all warnings for my use case.

Now lets hope it gets merged and released soon.

[geoand]

That's great! Let's see what happens

[famod]

Until a new release of xstream (which might take a long time), we _could_ work around this in Quarkus by registering our own list of converters. Just saying.

[geoand]

Yeah, if the release don't come soon, I'll let you do a PR for that :)

[famod]

Workaround until then:

--add-opens java.base/java.lang.reflect=ALL-UNNAMED
--add-opens java.base/java.util=ALL-UNNAMED
--add-opens java.base/java.text=ALL-UNNAMED
--add-opens java.desktop/java.awt.font=ALL-UNNAMED

(yes, even AWT)

[famod]

_Update_: My changes were merged into xstream master but since 1.5 seems to take more time, I've created another PR against the 1.4 branch.
The maintainer of xstream said he might have time to release another 1.4 (1.4.12.1?) with my workaround at the beginning of September.

[famod]

1.4.13 is out (but not yet on central): https://github.com/x-stream/xstream/releases/tag/XSTREAM_1_4_13
I'll have a look in the next few days but it seems I will have some "fun" with the following comment:

        <dependency>
            <groupId>com.thoughtworks.xstream</groupId>
            <artifactId>xstream</artifactId>
            <!-- Avoid adding this to the BOM / Version has to be kept in sync with what optaplanner uses otherwise the enforcer complains -->
            <version>1.4.11.1</version>
        </dependency>

[geoand]

Good thing is that octaplanner is no longer part of the core, so we shouldn't have any problems