[JBoss JIRA] (WFLY-11858) [Wildfly16] CDI fails to inject InitialContext during startup
by Martin Kouba (Jira)
[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ]
Martin Kouba commented on WFLY-11858:
-------------------------------------
Hm, who should be producing a bean for the required type {{javax.naming.InitialContext}} consumed by https://github.com/jbosstm/narayana/blob/5.9.3.Final/ArjunaJTA/cdi/classe...
> [Wildfly16] CDI fails to inject InitialContext during startup
> -------------------------------------------------------------
>
> Key: WFLY-11858
> URL: https://issues.jboss.org/browse/WFLY-11858
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Transactions
> Affects Versions: 16.0.0.Final
> Reporter: Rakesh K. Cherukuri
> Assignee: Matej Novotny
> Priority: Major
> Attachments: stacktrace.log
>
>
> We are in the process of upgrading from 14.0.1.Final. While Wildfly 15.0.1 works fine, 16.0.0.Final is intermittently (3 out of 5 times) failing to start with following error
> _WELD-001334: Unsatisfied dependencies for type InitialContext with qualifiers_
> In our application, a bootstrap servlet startsup services (Stateless EJBs) during server startup. During this process the server fails to start with above error.
> Basically CDI is not able to find the appropriate InitialContext bean *intermittently*. This is not failing in our application code but in the wildfly libraries itself.
> Any pointers on this will be helpful. Don't want to end up with startup issues in stage/production :)
> Unfortunately my efforts to come up with a simplified maven module to showcase the error didn't succeed. So, please let me know if any further information is required and i will be glad to fill it in.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (WFLY-11858) [Wildfly16] CDI fails to inject InitialContext during startup
by Matej Novotny (Jira)
[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ]
Matej Novotny commented on WFLY-11858:
--------------------------------------
I know that it is supposed to be "caller sensitive" in a way that it operates a bean manager associated with whichever class invoked it (there is some underlying hierarchy of {{BeanManager}}s).
In WildFly there is [{{WeldProvider}}|https://github.com/wildfly/wildfly/blob/master/weld/subsystem/src/main/java/org/jboss/as/weld/WeldProvider.java] which implements this behaviour (how you obtain correct BM) which is then used by {{CDI.current()}}.
If you get "wrong" BM here, then you will not be able to see certain beans, even though they exist somewhere in the deployment.
The hierarchy of BMs is in place to enforce EE umbrella spec visibility limitations.
Maybe [~mkouba] would know more about {{CDI.current()}} in WFLY from the top of his head ;)
But from the exception we have seen here and from the fact that it sometimes fails and sometimes passes, I would rather guess that problem is in some service dependencies/startup order. The error is intermittent and if {{CDI.current()}} is the faulty bit, then _I think_ we would be seeing consistent failures instead.
> [Wildfly16] CDI fails to inject InitialContext during startup
> -------------------------------------------------------------
>
> Key: WFLY-11858
> URL: https://issues.jboss.org/browse/WFLY-11858
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Transactions
> Affects Versions: 16.0.0.Final
> Reporter: Rakesh K. Cherukuri
> Assignee: Matej Novotny
> Priority: Major
> Attachments: stacktrace.log
>
>
> We are in the process of upgrading from 14.0.1.Final. While Wildfly 15.0.1 works fine, 16.0.0.Final is intermittently (3 out of 5 times) failing to start with following error
> _WELD-001334: Unsatisfied dependencies for type InitialContext with qualifiers_
> In our application, a bootstrap servlet startsup services (Stateless EJBs) during server startup. During this process the server fails to start with above error.
> Basically CDI is not able to find the appropriate InitialContext bean *intermittently*. This is not failing in our application code but in the wildfly libraries itself.
> Any pointers on this will be helpful. Don't want to end up with startup issues in stage/production :)
> Unfortunately my efforts to come up with a simplified maven module to showcase the error didn't succeed. So, please let me know if any further information is required and i will be glad to fill it in.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (WFLY-11858) [Wildfly16] CDI fails to inject InitialContext during startup
by Matej Novotny (Jira)
[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ]
Matej Novotny edited comment on WFLY-11858 at 3/18/19 8:38 AM:
---------------------------------------------------------------
[~ochaloup] I know that it is supposed to be "caller sensitive" in a way that it operates a bean manager associated with whichever class invoked it (there is some underlying hierarchy of {{BeanManager}}s).
In WildFly there is [{{WeldProvider}}|https://github.com/wildfly/wildfly/blob/master/weld/subsystem/src/main/java/org/jboss/as/weld/WeldProvider.java] which implements this behaviour (how you obtain correct BM) which is then used by {{CDI.current()}}.
If you get "wrong" BM here, then you will not be able to see certain beans, even though they exist somewhere in the deployment.
The hierarchy of BMs is in place to enforce EE umbrella spec visibility limitations.
Maybe [~mkouba] would know more about {{CDI.current()}} in WFLY from the top of his head ;)
But from the exception we have seen here and from the fact that it sometimes fails and sometimes passes, I would rather guess that problem is in some service dependencies/startup order. The error is intermittent and if {{CDI.current()}} is the faulty bit, then _I think_ we would be seeing consistent failures instead.
was (Author: manovotn):
I know that it is supposed to be "caller sensitive" in a way that it operates a bean manager associated with whichever class invoked it (there is some underlying hierarchy of {{BeanManager}}s).
In WildFly there is [{{WeldProvider}}|https://github.com/wildfly/wildfly/blob/master/weld/subsystem/src/main/java/org/jboss/as/weld/WeldProvider.java] which implements this behaviour (how you obtain correct BM) which is then used by {{CDI.current()}}.
If you get "wrong" BM here, then you will not be able to see certain beans, even though they exist somewhere in the deployment.
The hierarchy of BMs is in place to enforce EE umbrella spec visibility limitations.
Maybe [~mkouba] would know more about {{CDI.current()}} in WFLY from the top of his head ;)
But from the exception we have seen here and from the fact that it sometimes fails and sometimes passes, I would rather guess that problem is in some service dependencies/startup order. The error is intermittent and if {{CDI.current()}} is the faulty bit, then _I think_ we would be seeing consistent failures instead.
> [Wildfly16] CDI fails to inject InitialContext during startup
> -------------------------------------------------------------
>
> Key: WFLY-11858
> URL: https://issues.jboss.org/browse/WFLY-11858
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Transactions
> Affects Versions: 16.0.0.Final
> Reporter: Rakesh K. Cherukuri
> Assignee: Matej Novotny
> Priority: Major
> Attachments: stacktrace.log
>
>
> We are in the process of upgrading from 14.0.1.Final. While Wildfly 15.0.1 works fine, 16.0.0.Final is intermittently (3 out of 5 times) failing to start with following error
> _WELD-001334: Unsatisfied dependencies for type InitialContext with qualifiers_
> In our application, a bootstrap servlet startsup services (Stateless EJBs) during server startup. During this process the server fails to start with above error.
> Basically CDI is not able to find the appropriate InitialContext bean *intermittently*. This is not failing in our application code but in the wildfly libraries itself.
> Any pointers on this will be helpful. Don't want to end up with startup issues in stage/production :)
> Unfortunately my efforts to come up with a simplified maven module to showcase the error didn't succeed. So, please let me know if any further information is required and i will be glad to fill it in.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (WFLY-11858) [Wildfly16] CDI fails to inject InitialContext during startup
by Ondra Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka edited comment on WFLY-11858 at 3/18/19 8:07 AM:
-----------------------------------------------------------------
[~manovotn] I agree that it could be the trouble of the Narayana CDI lookup. There were changes at that code between WFLY 15 and 16 so it's highly possible from that perspective as well.
The code which is used for the lookup is here
https://github.com/jbosstm/narayana/blob/5.9.3.Final/ArjunaJTA/cdi/classe...
Especially when we talk about EAR the classloading the behaviour of {{CDI.current()}} is a bit "strange", from my experience. I think we already discussed this aspect for refactoring of the transaction modules in WFLY.
Could be we need some similar handling which is used here https://github.com/jbosstm/narayana/blob/5.9.3.Final/compensations/src/ma... ? [~manovotn] do you have some more experience with use of the `CDI.current().lookup` for the EARs?
was (Author: ochaloup):
[~manovotn] I agree that it could be the trouble of the Narayana CDI lookup. There were changes at that code between WFLY 15 and 16 so it's highly possible from that perspective as well.
The code which is used for the lookup is here
https://github.com/jbosstm/narayana/blob/5.9.3.Final/ArjunaJTA/cdi/classe...
Especially if this is the EAR the classloading is a bit "strange" with this `CDI.current()`. I think we already discussed this aspect for refactoring of the transaction modules in WFLY.
Could be we need some similar handling which is used here https://github.com/jbosstm/narayana/blob/5.9.3.Final/compensations/src/ma... ? [~manovotn] do you have some more experience with use of the `CDI.current().lookup` for the EARs?
> [Wildfly16] CDI fails to inject InitialContext during startup
> -------------------------------------------------------------
>
> Key: WFLY-11858
> URL: https://issues.jboss.org/browse/WFLY-11858
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Transactions
> Affects Versions: 16.0.0.Final
> Reporter: Rakesh K. Cherukuri
> Assignee: Matej Novotny
> Priority: Major
> Attachments: stacktrace.log
>
>
> We are in the process of upgrading from 14.0.1.Final. While Wildfly 15.0.1 works fine, 16.0.0.Final is intermittently (3 out of 5 times) failing to start with following error
> _WELD-001334: Unsatisfied dependencies for type InitialContext with qualifiers_
> In our application, a bootstrap servlet startsup services (Stateless EJBs) during server startup. During this process the server fails to start with above error.
> Basically CDI is not able to find the appropriate InitialContext bean *intermittently*. This is not failing in our application code but in the wildfly libraries itself.
> Any pointers on this will be helpful. Don't want to end up with startup issues in stage/production :)
> Unfortunately my efforts to come up with a simplified maven module to showcase the error didn't succeed. So, please let me know if any further information is required and i will be glad to fill it in.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (WFLY-11858) [Wildfly16] CDI fails to inject InitialContext during startup
by Ondra Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka commented on WFLY-11858:
----------------------------------------
[~manovotn] I agree that it could be the trouble of the Narayana CDI lookup. There were changes at that code between WFLY 15 and 16 so it's highly possible from that perspective as well.
The code which is used for the lookup is here
https://github.com/jbosstm/narayana/blob/5.9.3.Final/ArjunaJTA/cdi/classe...
Especially if this is the EAR the classloading is a bit "strange" with this `CDI.current()`. I think we already discussed this aspect for refactoring of the transaction modules in WFLY.
Could be we need some similar handling which is used here https://github.com/jbosstm/narayana/blob/5.9.3.Final/compensations/src/ma... ? [~manovotn] do you have some more experience with use of the `CDI.current().lookup` for the EARs?
> [Wildfly16] CDI fails to inject InitialContext during startup
> -------------------------------------------------------------
>
> Key: WFLY-11858
> URL: https://issues.jboss.org/browse/WFLY-11858
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Transactions
> Affects Versions: 16.0.0.Final
> Reporter: Rakesh K. Cherukuri
> Assignee: Matej Novotny
> Priority: Major
> Attachments: stacktrace.log
>
>
> We are in the process of upgrading from 14.0.1.Final. While Wildfly 15.0.1 works fine, 16.0.0.Final is intermittently (3 out of 5 times) failing to start with following error
> _WELD-001334: Unsatisfied dependencies for type InitialContext with qualifiers_
> In our application, a bootstrap servlet startsup services (Stateless EJBs) during server startup. During this process the server fails to start with above error.
> Basically CDI is not able to find the appropriate InitialContext bean *intermittently*. This is not failing in our application code but in the wildfly libraries itself.
> Any pointers on this will be helpful. Don't want to end up with startup issues in stage/production :)
> Unfortunately my efforts to come up with a simplified maven module to showcase the error didn't succeed. So, please let me know if any further information is required and i will be glad to fill it in.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (WFCORE-3891) Cannot create xml-formatter and json-formatter with the same name as existing resources in logging subsystem
by Michal Petrov (Jira)
[ https://issues.jboss.org/browse/WFCORE-3891?page=com.atlassian.jira.plugi... ]
Michal Petrov commented on WFCORE-3891:
---------------------------------------
[~jamezp], I've been looking into this issue. The one case not mentioned here is that if you set up formatters named A and B then you can create handler A and give it named-formatter B (and give A to B) but you cannot give formatter A to handler A.
Seems like the thing to do would be to tweak the logmanager. Since the default formatter can only be assigned to one handler there's no reason to store it with the other manually created formatters and that way there would be no need to check for naming collisions, unless I'm missing something.
> Cannot create xml-formatter and json-formatter with the same name as existing resources in logging subsystem
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3891
> URL: https://issues.jboss.org/browse/WFCORE-3891
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Nikoleta Žiaková
> Assignee: James Perkins
> Priority: Major
>
> When trying to create an {{xml-formatter}} or {{json-formatter}} with the same name as another resource (e.g. a {{file-handler}}), the operation fails:
> {code}
> [standalone@localhost:9990 /] /subsystem=logging/file-handler=test:add(file={path=aaa.log})
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=logging/xml-formatter=test:add
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: No property \"dateFormat\" setter found for formatter \"test\"",
> "rolled-back" => true
> }
> {code}
> Similarly vice-versa, when trying to create another resource in logging subsystem with the same name as an {{xml-formatter}} or a {{json-formatter}}, the operation fails:
> {code}
> [standalone@localhost:9990 /] /subsystem=logging/json-formatter=test:add
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=logging/file-handler=test:add(file={path=test.log})
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: No property \"pattern\" setter found for formatter \"test\"",
> "rolled-back" => true
> }
> {code}
> The same scenario works for e.g. {{pattern-formatter}}:
> {code}
> [standalone@localhost:9990 /] /subsystem=logging/file-handler=test:add(file={path=test.log})
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=logging/pattern-formatter=test:add
> {"outcome" => "success"}
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (DROOLS-3770) Fix generic type retrieval inside SetPropertyHeaderCommand
by Klara Kufova (Jira)
[ https://issues.jboss.org/browse/DROOLS-3770?page=com.atlassian.jira.plugi... ]
Klara Kufova updated DROOLS-3770:
---------------------------------
Attachment: dmn-map.dmn
> Fix generic type retrieval inside SetPropertyHeaderCommand
> ----------------------------------------------------------
>
> Key: DROOLS-3770
> URL: https://issues.jboss.org/browse/DROOLS-3770
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Reporter: Gabriele Cardosi
> Assignee: Gabriele Cardosi
> Priority: Major
> Labels: ScenarioSimulation
> Attachments: dmn-map.dmn
>
>
> The property editing information for a given column (included the DOMELEmentFactory) are set inside SetPropertyHeaderColumn.
> If the property is a collection, its generic type is retrieved with informations from the context.
> Currently, this mechanism uses the "steps" stored inside "elements", that point to full path of the property (and a mapped entry must exists).
> This is broken for top-level collection because are mapped in a different way, so a compatible method for different situations must be implemented
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (DROOLS-3770) Fix generic type retrieval inside SetPropertyHeaderCommand
by Klara Kufova (Jira)
[ https://issues.jboss.org/browse/DROOLS-3770?page=com.atlassian.jira.plugi... ]
Klara Kufova updated DROOLS-3770:
---------------------------------
Component/s: Scenario Simulation and Testing
Tester: Klara Kufova
Labels: ScenarioSimulation (was: )
> Fix generic type retrieval inside SetPropertyHeaderCommand
> ----------------------------------------------------------
>
> Key: DROOLS-3770
> URL: https://issues.jboss.org/browse/DROOLS-3770
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Reporter: Gabriele Cardosi
> Assignee: Gabriele Cardosi
> Priority: Major
> Labels: ScenarioSimulation
>
> The property editing information for a given column (included the DOMELEmentFactory) are set inside SetPropertyHeaderColumn.
> If the property is a collection, its generic type is retrieved with informations from the context.
> Currently, this mechanism uses the "steps" stored inside "elements", that point to full path of the property (and a mapped entry must exists).
> This is broken for top-level collection because are mapped in a different way, so a compatible method for different situations must be implemented
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (WFLY-11859) jax-rs and CDI: FormParam in BeanParam is not injected
by Ivo Studensky (Jira)
Ivo Studensky created WFLY-11859:
------------------------------------
Summary: jax-rs and CDI: FormParam in BeanParam is not injected
Key: WFLY-11859
URL: https://issues.jboss.org/browse/WFLY-11859
Project: WildFly
Issue Type: Bug
Components: CDI / Weld, REST
Reporter: Ivo Studensky
Assignee: Ivo Studensky
RESTEasy with CDI is unable to inject FormParam in BeanParam if BeanParam is with RequestScoped
This issue is not a regression against WF11. But this issue looks like spec violation (cc [~msvehla]). This issue is not present on Payara with Jersey (reference jax-rs implementation)
Example:
{code:java}
@Path("/a")
public class Resource {
@POST
@Consumes(MediaType.APPLICATION_FORM_URLENCODED)
public Integer a(@BeanParam CustomBean customBean) {
return customBean.getParam().length();
}
}
@RequestScoped
public class CustomBean {
@FormParam("param")
private String param;
public String getParam() {
return param;
}
}
{code}
{code:html}
<!DOCTYPE html><html><body>
<form action="http://127.0.0.1:8080/jaxrs-wf/a" method="post" enctype="application/x-www-form-urlencoded">
<input type="text" name="param"><br>
<input type="submit" value="Submit" name="submit">
</form></body></html>
{code}
{noformat}
08:25:18,584 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /jaxrs-wf/a: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:78)
at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:222)
at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:193)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:455)
at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229)
at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135)
at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:215)
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
at io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:364)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1348)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NullPointerException
at org.resteasy.simple.deployment.Resource.a(Resource.java:18)
at org.resteasy.simple.deployment.Resource$Proxy$_$$_WeldClientProxy.a(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:439)
... 55 more
{noformat}
----
* [Forum link|https://developer.jboss.org/thread/279572]
* cc [~asoldano]
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (WFLY-11843) CXF-7994 - NumberFormatException on JDK13 in org.apache.cxf.helpers.JavaUtils
by Richard Opalka (Jira)
[ https://issues.jboss.org/browse/WFLY-11843?page=com.atlassian.jira.plugin... ]
Richard Opalka commented on WFLY-11843:
---------------------------------------
Hi [~ema1], Freeman Fang closed issue as duplicate as it was fixed in 3.3.0.
I know it was fixed in 3.3.0 but the plan is to consume CXF 3.2.9 next AFAICS.
There are two possibilities now:
* either apply my proposal patch from CXF-7994 on 3.2.x branch so it will be available via CXF 3.2.9 upgrade
* or consider upgrading to CXF 3.3.0 instead of CXF 3.2.9
Otherwise WildFly will not work on JDK 13.
> CXF-7994 - NumberFormatException on JDK13 in org.apache.cxf.helpers.JavaUtils
> -----------------------------------------------------------------------------
>
> Key: WFLY-11843
> URL: https://issues.jboss.org/browse/WFLY-11843
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 16.0.0.Final
> Reporter: Richard Opalka
> Assignee: Jim Ma
> Priority: Major
> Labels: jdk13
> Fix For: 17.0.0.Beta1
>
>
> We are getting the following exception when running CXF on top of JDK13:
> —
> Failed to start service jboss.deployment.unit."ws-endpoint-example.war".INSTALL: org.jboss.msc.service.StartExceptio
> <------>at org.jboss.as.server@8.0.1.CR1-SNAPSHOT//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:183)
> <------>at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1738)
> <------>at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1700)
> <------>at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
> <------>at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> <------>at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> <------>at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> <------>at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
> <------>at java.base/java.lang.Thread.run(Thread.java:835)
> Caused by: java.lang.ExceptionInInitializerError
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.WrapperClassGenerator.generateMessagePart(WrapperClassGenerator.java:335)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.WrapperClassGenerator.createWrapperClass(WrapperClassGenerator.java:224)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.WrapperClassGenerator.generate(WrapperClassGenerator.java:122)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:674)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:644)
> <------>at org.apache.cxf.impl//org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:464)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:695)
> <------>at org.apache.cxf.impl//org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:530)
> <------>at org.apache.cxf.impl//org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:263)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
> <------>at org.apache.cxf.impl//org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103)
> <------>at org.apache.cxf.impl//org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:168)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:460)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:338)
> <------>at org.jboss.ws.cxf.jbossws-cxf-server@5.2.4.Final//org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:79)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:255)
> <------>at org.apache.cxf.impl//org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:543)
> <------>at org.jboss.ws.cxf.jbossws-cxf-server@5.2.4.Final//org.jboss.wsf.stack.cxf.configuration.BusHolder.configure(BusHolder.java:235)
> <------>at org.jboss.ws.cxf.jbossws-cxf-server@5.2.4.Final//org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:97)
> <------>at org.jboss.ws.cxf.jbossws-cxf-server@5.2.4.Final//org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:59)
> <------>at org.jboss.as.webservices//org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:73)
> <------>at org.jboss.as.server@8.0.1.CR1-SNAPSHOT//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:176)
> <------>... 8 more
> Caused by: java.lang.NumberFormatException: For input string: "13-ea"
> <------>at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:68)
> <------>at java.base/java.lang.Integer.parseInt(Integer.java:658)
> <------>at java.base/java.lang.Integer.valueOf(Integer.java:989)
> <------>at org.apache.cxf(a)3.2.7//org.apache.cxf.helpers.JavaUtils.<clinit>(JavaUtils.java:65)
> <------>... 31 more
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months