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

Illegal reflective access because of partial implementation of ProxyServices? #5326

Closed
oliviercailloux opened this issue Sep 25, 2020 · 7 comments

Comments

@oliviercailloux
Copy link

Jetty version
9.4.32-SNAPSHOT

Java version
OpenJDK 11

OS type/version
Debian stable

Description
Following the new instructions for setting up CDI with Weld leads to an “illegal reflective access” (according to the log). Looking up the Weld source code, it mentions that the reason could be that “the integrator does not fully implement ProxyServices”. Is this something that jetty can solve, or due to me not having properly understood the instructions for setting up Weld + Jetty?

Details
I built the new version of the doc from source. I used the jetty-snapshot available in maven, contrary to instructions, I hope that is okay.

The log is the following when my application starts.

19:28:25.524 [main] INFO  org.eclipse.jetty.util.log - Logging initialized @713ms to org.eclipse.jetty.util.log.Slf4jLog
19:28:25.724 [main] INFO  io.github.oliviercailloux.jetty.App - Set handler: HandlerList@11a9e7c8{STOPPED}.
19:28:25.736 [main] INFO  org.eclipse.jetty.server.Server - jetty-9.4.32-SNAPSHOT; built: 2020-09-18T11:03:24.291Z; git: e3ed05fc1c1dca35add2ff5da29f910c693e23e2; jvm 11.0.8+10-post-Debian-1deb10u1
19:28:25.890 [main] INFO  o.j.w.environment.servletWeldServlet - WELD-ENV-001008: Initialize Weld using ServletContainerInitializer
19:28:25.927 [main] INFO  org.jboss.weld.Version - WELD-000900: 3.1.5 (SP1)
19:28:26.208 [main] INFO  org.jboss.weld.Bootstrap - WELD-ENV-000020: Using jandex for bean discovery
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.jboss.weld.util.bytecode.ClassFileUtils$1 (file:/home/olivier/.m2/repository/org/jboss/weld/weld-core-impl/3.1.5.SP1/weld-core-impl-3.1.5.SP1.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int)
WARNING: Please consider reporting this to the maintainers of org.jboss.weld.util.bytecode.ClassFileUtils$1
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
19:28:26.497 [main] INFO  org.jboss.weld.Bootstrap - WELD-000101: Transactional services not available. Injection of @Inject UserTransaction not available. Transactional observers will be invoked synchronously.
19:28:26.814 [main] INFO  o.j.weld.environment.servletJetty - WELD-ENV-001200: Jetty 7.2+ detected, CDI injection will be available in Servlets and Filters. Injection into Listeners should work on Jetty 9.1.1 and newer.
19:28:27.152 [main] INFO  o.e.j.c.CdiServletContainerInitializer - CdiDecoratingListener enabled in [email protected]@1dd0e7c4{/api,null,STARTING}
19:28:27.162 [main] INFO  o.e.j.server.handler.ContextHandler - Started o.e.j.s.ServletContextHandler@1dd0e7c4{/api,null,AVAILABLE}
19:28:27.185 [main] INFO  o.e.jetty.server.AbstractConnector - Started ServerConnector@4461c7e3{HTTP/1.1, (http/1.1)}{0.0.0.0:8080}
19:28:27.185 [main] INFO  org.eclipse.jetty.server.Server - Started @2381ms

The full application is here, with the main content here.

The illegal reflective access happens in this class, where the quote above about ProxyServices is taken from.

(I posted this here already, but I figured out that this probably deserves a new issue, I hope this is adequate.)

Possibly related questions

  1. The log is not exactly as documented, letting me wonder whether I am unwillingly using some deprecated access instead of the recommended one. I get “Jetty 7.2+ detected, CDI injection will be available in Servlets and Filters. Injection into Listeners should work on Jetty 9.1.1 and newer.” whereas according to the doc, I should get “INFO: WELD-ENV-001212: Jetty CdiDecoratingListener support detected, CDI injection will be available in Listeners, Servlets and Filters.”
  2. I use org.jboss.weld.servlet:weld-servlet-core:3.1.5.SP1 as Weld dependency, whereas the documentation mentions org.jboss.weld.servlet:weld-servlet (which seems unmaintained since 2014), is this the recommended dependency to use with jetty embedded?
  3. I use the jetty-cdi Maven dependency, and not cdi-decorate as documented (which I can’t find in Maven central), is this all right?
@joakime
Copy link
Contributor

joakime commented Sep 25, 2020

Our CDI integration is vendor neutral ATM.

It supports both Weld and OpenWebBeans.
Looks like org.jboss.weld.serialization.spi.ProxyServices would be weld specific.

If we implemented it, then wouldn't that mean CDI is no longer a Server level feature?

As an implementation of ProxyServices expects to be registered at each individual WebAppClassLoader, which the server level one is not responsible for, right?

Since weld Services register at the WeldStartup time that means the ProxyServices implementation would be loaded far too soon to have any impact on the WebAppClassLoader (where the ProxyServices would need to be). We would need to delay ServicLoader lookup of the ProxyServices for when the specific WebAppClassLoader is started. ugh.

@oliviercailloux
Copy link
Author

I understand the concern that Jetty should be vendor neutral.

Could you confirm that my sample code implemented Jetty CDI integration in the recommended way (i.e. that I made no mistake in interpreting the documentation), considering my three “related questions” in particular?

@gregw
Copy link
Contributor

gregw commented Sep 26, 2020

@oliviercailloux there are actually a lot of different ways to integrate weld into Jetty! See: https://github.com/eclipse/jetty.project/blob/jetty-9.4.x/jetty-cdi/src/test/java/org/eclipse/jetty/embedded/EmbeddedWeldTest.java

Very hard to say what is the preferred. Personally like the CdiServletContainerInitializer+EnhancedListener as that is using the SPI, which is meant to be the way to integrate any CDI implementation.
However the Weld folks say that somethings might not work that way.... not sure what they are.

So 2nd best is probably CdiServletContainerInitializer(CdiDecoratingListener)+EnhancedListener

I think you code looks close... except I think you have the order wrong: ie add the EnhancedListener after the CdiServletContainerInitializer. So your code is trying to init CDI before Jetty has initialised it's CDI support.

@gregw
Copy link
Contributor

gregw commented Sep 26, 2020

oh yes our documentation does need to catch up a bit with some recent changes to how this is done embedded.

@oliviercailloux
Copy link
Author

Thanks for the answer. The point of my issue is that I did my best to follow the instructions as the current (9.4.32-SNAPSHOT) documentation states. If the order is wrong, then the documentation should certainly be updated.

Very hard to say what is the preferred.

The documentation does indicate a preferred mode, which is the one I (tried to) implement.

@oliviercailloux
Copy link
Author

Thanks for the replies. I suppose this bug can be closed, as it does not seem desirable to solve the illegal reflective access on the Jetty side rather than on the WELD side, if I understand correctly.

I have voted for the related WELD bug.

@gregw
Copy link
Contributor

gregw commented Oct 26, 2020

thanks

@gregw gregw closed this as completed Oct 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants