Closed DarrellWu closed 2 months ago
Hi, I'd really like to support that, but I'll need to find out how to do it.
WildFly has got its, in my opinion, somewhat weird CDI behavior for EAR archives, where it creates a separate BeanManager for every JAR (it seems that not only for every JAR/WAR in the EAR, but including static modules - basically every CDI-enabled archive that is involved in the app). And when SmallRye GraphQL code wants to perform programmatic injection and calls CDI.current()
, it receives a CDI instance for the BeanManager owned by the JAR that contains this call. Unfortunately, that JAR in our case is smallrye-graphql-cdi.jar
, and its BeanManager does not 'see' the beans contained in the application, hence an attempt to inject will fail. Weirdly, when you deploy a WAR only, then that BeanManager can see those beans, but not with EAR.
I really don't know how to fix the EAR case, it might be a design issue of WildFly, or something that is configurable... somehow.
I rememeber a similar issue with Soteria. See https://issues.redhat.com/browse/WELD-2510 for reference: getting the bean manager instance using JNDI lookup should work as expected.
I've marked EAR deployments explicitly as unsupported in the main README. This is in line with the support policies of the MicroProfile expansion pack for JBoss EAP (see https://access.redhat.com/articles/2026253)
Hi,
I'm trying to get graphql working with an ear deployment package. In Wildfly 20.0.1 the application deploys and runs but when running a graphql query i get the following response
{ "errors": [ { "message": "Server Error", "locations": [ { "line": 1, "column": 2 } ], "path": [ "allMembers" ], "extensions": { "exception": "org.jboss.weld.exceptions.UnsatisfiedResolutionException", "classification": "DataFetchingException", "code": "unsatisfied-resolution" } } ], "data": { "allMembers": null } }
I tried the same app on WildFly 24.0.1 and the application fails to deploy with
Any chance EAR package will be supported