[JBoss JIRA] (WFLY-11603) Intermittent NPE from MP config SubsystemDeploymentProcessor
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFLY-11603?page=com.atlassian.jira.plugin... ]
Jeff Mesnil commented on WFLY-11603:
------------------------------------
[~jstourac] yes, the deprecated API is the only way to make sure the service is properly installed for the next phase.
> Intermittent NPE from MP config SubsystemDeploymentProcessor
> ------------------------------------------------------------
>
> Key: WFLY-11603
> URL: https://issues.jboss.org/browse/WFLY-11603
> Project: WildFly
> Issue Type: Bug
> Components: MP Config
> Affects Versions: 15.0.1.Final
> Environment: Windows
> JDK-11
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Major
> Fix For: 16.0.0.Beta1
>
>
> In our automation tests, we can see intermittent NPE with following stack trace:
> {code}
> 20:01:38,985 ERROR [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0043: Deployment unit processor org.wildfly.extension.microprofile.config.smallrye.deployment.SubsystemDeploymentProcessor@54fd99c3 unexpectedly threw an exception during undeploy phase POST_MODULE of deployment "org.jboss.qa.management.ws.WebservicesWsdlHostIT.war": java.lang.NullPointerException
> at org.wildfly.extension.microprofile.config-smallrye@7.2.0.GA-redhat-00004//org.wildfly.extension.microprofile.config.smallrye.deployment.SubsystemDeploymentProcessor.undeploy(SubsystemDeploymentProcessor.java:102)
> at org.jboss.as.server@6.0.11.Final-redhat-00001//org.jboss.as.server.deployment.DeploymentUnitPhaseService.safeUndeploy(DeploymentUnitPhaseService.java:211)
> at org.jboss.as.server@6.0.11.Final-redhat-00001//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:149)
> at org.jboss.msc@1.4.5.Final-redhat-00001//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1738)
> at org.jboss.msc@1.4.5.Final-redhat-00001//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1700)
> at org.jboss.msc@1.4.5.Final-redhat-00001//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
> at org.jboss.threads@2.3.2.Final-redhat-1//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.2.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads@2.3.2.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads@2.3.2.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1364)
> at java.base/java.lang.Thread.run(Thread.java:834)
> 20:01:38,986 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."org.jboss.qa.management.ws.WebservicesWsdlHostIT.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."org.jboss.qa.management.ws.WebservicesWsdlHostIT.war".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment "org.jboss.qa.management.ws.WebservicesWsdlHostIT.war"
> at org.jboss.as.server@6.0.11.Final-redhat-00001//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:151)
> at org.jboss.msc@1.4.5.Final-redhat-00001//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1738)
> at org.jboss.msc@1.4.5.Final-redhat-00001//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1700)
> at org.jboss.msc@1.4.5.Final-redhat-00001//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
> at org.jboss.threads@2.3.2.Final-redhat-1//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.2.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads@2.3.2.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads@2.3.2.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1364)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.IllegalStateException: No ConfigProviderResolver implementation found!
> at org.eclipse.microprofile.config.api@1.3.0.redhat-00001//org.eclipse.microprofile.config.spi.ConfigProviderResolver.instance(ConfigProviderResolver.java:122)
> at org.wildfly.extension.microprofile.config-smallrye@7.2.0.GA-redhat-00004//org.wildfly.extension.microprofile.config.smallrye.deployment.SubsystemDeploymentProcessor.deploy(SubsystemDeploymentProcessor.java:67)
> at org.jboss.as.server@6.0.11.Final-redhat-00001//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:144)
> ... 8 more
> {code}
> further on, there is also following error in the server.log (it has been dealt in WFWIP-64, although in different circumstances, I guess):
> {code}
> 20:01:39,164 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "org.jboss.qa.management.ws.WebservicesWsdlHostIT.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"org.jboss.qa.management.ws.WebservicesWsdlHostIT.war\".POST_MODULE" => "WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"org.jboss.qa.management.ws.WebservicesWsdlHostIT.war\"
> Caused by: java.lang.IllegalStateException: No ConfigProviderResolver implementation found!"}}
> 20:01:39,169 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0010: Deployed "org.jboss.qa.management.ws.WebservicesWsdlHostIT.war" (runtime-name : "org.jboss.qa.management.ws.WebservicesWsdlHostIT.war")
> 20:01:39,171 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0186: Services which failed to start: service jboss.deployment.unit."org.jboss.qa.management.ws.WebservicesWsdlHostIT.war".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment "org.jboss.qa.management.ws.WebservicesWsdlHostIT.war"
> {code}
> The NPE itself goes from the 'undeploy' method in SubsystemDeploymentProcessor. Although, according to the surrounding log messages (longer test log is attached [^NPE-server.log]), the server is still in the boot process by that time.
> This NPE happens quite rarely so it looks like some kind of a race-condition is in place. So far we have seen this only on Windows with JDK-11 combination but cannot say it does not affect other platforms for sure.
> Also, we have not seen it with latest WildFly nightly builds too (WildFly revision 353b95ef201c18dbd465087f520392c8525a2213) (yet?).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-10261) @Startup, @WebListener and (@Observes @Initialized(ApplicationScoped.class) are triggered before some components has started
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-10261?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFLY-10261:
---------------------------------------
Component/s: CDI / Weld
Assignee: Brian Stansberry (was: Jason Greene)
Is this still a problem with WildFly 15? If it is can you provide a reproducer app?
> @Startup, @WebListener and (@Observes @Initialized(ApplicationScoped.class) are triggered before some components has started
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10261
> URL: https://issues.jboss.org/browse/WFLY-10261
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 12.0.0.Final
> Reporter: Daniel Fb
> Assignee: Brian Stansberry
> Priority: Major
>
> We are migrating our applications from Wildfly 10 to Wildfly 12 and sometimes Wildfly 12 trigger {{@Startup (with @PostContruct)}} or {{@WebListener}} or {{(@Observes @Initialized(ApplicationScoped.class)}} before some components has started.
> Ex:
> - At these moments we can't inject remote EJBs (simple {{new InitialContext().lookup(jndi)}})
> - Sometimes these {{@Observes}} is fired with null parameter
> {code}
> public void observesContext(@Observes @Initialized(ApplicationScoped.class) ServletContext context){
> this.context = context;
> }
> {code}
> *These behavior olny occurs when the server is starting with the application deployed*.
> When the application is deployed after the server is up and running, all goes fine a work.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-11646) Upgrade antlr to more current release
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11646?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-11646:
------------------------------------
Summary: Upgrade antlr to more current release (was: Upgrade a third party library)
> Upgrade antlr to more current release
> -------------------------------------
>
> Key: WFLY-11646
> URL: https://issues.jboss.org/browse/WFLY-11646
> Project: WildFly
> Issue Type: Component Upgrade
> Components: JPA / Hibernate
> Reporter: Zabee Ulla
> Assignee: Scott Marlow
> Priority: Minor
>
> As per the bug that was reported here - https://hibernate.atlassian.net/browse/HHH-10028, Hibernate stays in-step with Wildfly and EAP dependency versions to ensure compatibility.
> This task is a request to upgrade antlr to its latest version available against WildFly so that Hibernate also can pick the latest to be in synch with WildFly.
> Hibernate (hibernate-core to be more specific) latest version is still using antlr version 2.7.7 released on Jan 13, 2007. The latest available, built and maintained version is antlr-4-Runtime 4.7.2. Another reason for going with latest of antlr is to avoid any security vulnerabilities that the library is exposed to.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-11619) HA Singleton will not stop the service or deployment after merge the cluster-view if the elected node rejected by FullGC or suspended
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-11619?page=com.atlassian.jira.plugin... ]
Radoslav Husar edited comment on WFLY-11619 at 1/25/19 9:55 AM:
----------------------------------------------------------------
[~spyrkob] Make sure you wait long enough for the infinispan cache operation to timeout – that should reproduce the issue.
was (Author: rhusar):
[~spyrkob] Make sure you wait long enough for the infinispan cache operation to timeout.
> HA Singleton will not stop the service or deployment after merge the cluster-view if the elected node rejected by FullGC or suspended
> -------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11619
> URL: https://issues.jboss.org/browse/WFLY-11619
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 16.0.0.Beta1
> Reporter: Wolf-Dieter Fink
> Assignee: Paul Ferraro
> Priority: Critical
> Attachments: node1.log, node2.log
>
>
> If a 2 node cluster has a HA Singleton deployment (no matter whether it is a service or deployment) a merge after a split caused by FullGC will end in running two nodes as a Singleton provider.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFCORE-4297) Add constant to Phase for jaxrs
by R Searls (Jira)
R Searls created WFCORE-4297:
--------------------------------
Summary: Add constant to Phase for jaxrs
Key: WFCORE-4297
URL: https://issues.jboss.org/browse/WFCORE-4297
Project: WildFly Core
Issue Type: Enhancement
Components: Server
Affects Versions: 8.0.0.Beta3
Reporter: R Searls
Assignee: R Searls
A new Processor class is being added to jaxrs deployment process. A new constant
is needed for this.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-11651) Add method parameter check in jaxrs apps
by R Searls (Jira)
R Searls created WFLY-11651:
-------------------------------
Summary: Add method parameter check in jaxrs apps
Key: WFLY-11651
URL: https://issues.jboss.org/browse/WFLY-11651
Project: WildFly
Issue Type: Enhancement
Components: REST
Affects Versions: 16.0.0.Beta1
Reporter: R Searls
Assignee: R Searls
Attachments: RESTEASY-2062.zip
The jaxrs 2.1 spec section 3.2 require resource method parameters be checked at deployment time of errors handling @DefaultValue annotations. This must be added in wfly because
resteasy is not called until the first client request.
Testing
Build and deploy attached app to wildfly.
Before code fix deployment should be successful.
Running app with cmd: curl "http://localhost:8080/jaxrs-wf/a?param=2"
should fail.
After code fix deployment should fail with detailed msg.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months