Skip to content
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

Remove illegal refletive access warning for xstream for parameterized tests #10303

Closed
emmanuelbernard opened this issue Jun 26, 2020 · 20 comments · Fixed by #11956
Closed

Remove illegal refletive access warning for xstream for parameterized tests #10303

emmanuelbernard opened this issue Jun 26, 2020 · 20 comments · Fixed by #11956
Assignees
Labels
area/testing kind/bug Something isn't working
Milestone

Comments

@emmanuelbernard
Copy link
Member

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 emmanuelbernard added the kind/bug Something isn't working label Jun 26, 2020
@emmanuelbernard
Copy link
Member Author

See #10271

@geoand
Copy link
Contributor

geoand commented Jun 26, 2020

This should be mostly fixed in 1.6.0.CR1.

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

@pschyma
Copy link

pschyma commented Jun 26, 2020

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.

@jaikiran jaikiran added this to the 1.6.0.CR1 milestone Jul 24, 2020
@famod
Copy link
Member

famod commented Jul 28, 2020

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();
    }
}
public class Foo {

    public String get() {
        return CDI.current().select(SomeBean.class).get().toString();
    }
}
    @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
Copy link
Contributor

geoand commented Jul 28, 2020

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
Copy link
Member

famod commented Jul 28, 2020

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 famod reopened this Jul 28, 2020
@famod
Copy link
Member

famod commented Jul 28, 2020

Do we need a reproducer or is it obvious?

@geoand geoand changed the title Remove illegal refletive access warning for xstream Remove illegal refletive access warning for xstream for paremeterized tests Jul 29, 2020
@geoand geoand changed the title Remove illegal refletive access warning for xstream for paremeterized tests Remove illegal refletive access warning for xstream for parameterized tests Jul 29, 2020
@geoand
Copy link
Contributor

geoand commented Jul 29, 2020

Nah, I think it's obvious.

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

@famod
Copy link
Member

famod commented Jul 29, 2020

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

I fear that route doesn't look very promising: x-stream/xstream#101

@famod
Copy link
Member

famod commented Jul 29, 2020

I took a stab at this upstream: x-stream/xstream#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
Copy link
Contributor

geoand commented Jul 30, 2020

That's great! Let's see what happens

@famod
Copy link
Member

famod commented Jul 30, 2020

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
Copy link
Contributor

geoand commented Jul 30, 2020

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

@famod
Copy link
Member

famod commented Jul 30, 2020

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
Copy link
Member

famod commented Aug 13, 2020

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 famod self-assigned this Aug 13, 2020
@famod
Copy link
Member

famod commented Sep 6, 2020

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
Copy link
Contributor

geoand commented Sep 6, 2020

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

@gsmet gsmet modified the milestones: 1.6.0.CR1, 1.8.0.Final Sep 8, 2020
gsmet pushed a commit to gsmet/quarkus that referenced this issue Sep 8, 2020
Fixes quarkusio#10303 for some cases when using JUnit5 ParameterResolver.

Includes x-stream/xstream#218 that tries to avoid such warnings at XStream creation time.

Also adds xstream to dependabot. Comment regardings optaplanner was outdated.
@perasmena
Copy link

Does xstream work with native mode quarkus? Because i had classloading issues with its own custom class loader ....

@wzzc-dev
Copy link

Does xstream work with native mode quarkus? Because i had classloading issues with its own custom class loader ....

Is that the problem? I met it, too. How did you solve it?

Caused by: java.lang.ClassNotFoundException: com.thoughtworks.xstream.core.util.TypedNull
Caused by: java.lang.NoClassDefFoundError

@perasmena
Copy link

perasmena commented Jun 28, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/testing kind/bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants