[JBoss JIRA] (WFLY-13475) MP FT Quickstart: Change server startup documentation to reference local installation and standalone-microprofile.xml
by Eduardo Martins (Jira)
[ https://issues.redhat.com/browse/WFLY-13475?page=com.atlassian.jira.plugi... ]
Eduardo Martins updated WFLY-13475:
-----------------------------------
Description:
(1) WildFly pom is used instead of EAP XP one:
{code}
<groupId>org.wildfly.bom</groupId>
<artifactId>wildfly-microprofile</artifactId>
<version>${version.server.bom}</version>
where ${version.server.bom} is the version of your JBoss EAP XP, in our case "1.0".
{code}
This is mentioned in JBEAP-19481 as well.
(2) Unsupported commands for starting and managing EAP:
{code}
mvn wildfly:run &
mvn wildfly:execute-commands -Dwildfly.commands=/extension=org.wildfly.extension.microprofile.fault-tolerance-smallrye:add
mvn wildfly:execute-commands -Dwildfly.commands=/subsystem=microprofile-fault-tolerance-smallrye:add
mvn wildfly:shutdown -Dwildfly.reload=true
{code}
(3) I think there's no need to add the subsystem if using standalone-microprofile.xml config where it is already present.
There might be additional issues I don't see because of JBEAP-19481.
was:
(1) WildFly pom is used instead of EAP XP one:
{code}
<groupId>org.wildfly.bom</groupId>
<artifactId>wildfly-microprofile</artifactId>
<version>${version.server.bom}</version>
where ${version.server.bom} is the version of your JBoss EAP XP, in our case "1.0".
{code}
This is mentioned in JBEAP-19481 as well.
(2) Unsupported commands for starting and managing EAP:
{code}
mvn wildfly:run &
mvn wildfly:execute-commands -Dwildfly.commands=/extension=org.wildfly.extension.microprofile.fault-tolerance-smallrye:add
mvn wildfly:execute-commands -Dwildfly.commands=/subsystem=microprofile-fault-tolerance-smallrye:add
mvn wildfly:shutdown -Dwildfly.reload=true
{code}
(3) I think there's no need to add the subsystem if using standalone-microprofile.xml config where it is already present.
(4) Consider adding standard sections - see other QS
* Use of the EAP_HOME and QUICKSTART_HOME Variables
* Start the JBoss EAP XP Standalone Server
* Build and Deploy the Quickstart
* Access the Application
* Undeploy the Quickstart
* Run the Quickstart in Red Hat JBoss Developer Studio or Eclipse
There might be additional issues I don't see because of JBEAP-19481.
> MP FT Quickstart: Change server startup documentation to reference local installation and standalone-microprofile.xml
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13475
> URL: https://issues.redhat.com/browse/WFLY-13475
> Project: WildFly
> Issue Type: Bug
> Components: MP Fault Tolerance, Quickstarts
> Affects Versions: 19.1.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 20.0.0.Beta1
>
>
> (1) WildFly pom is used instead of EAP XP one:
> {code}
> <groupId>org.wildfly.bom</groupId>
> <artifactId>wildfly-microprofile</artifactId>
> <version>${version.server.bom}</version>
> where ${version.server.bom} is the version of your JBoss EAP XP, in our case "1.0".
> {code}
> This is mentioned in JBEAP-19481 as well.
> (2) Unsupported commands for starting and managing EAP:
> {code}
> mvn wildfly:run &
> mvn wildfly:execute-commands -Dwildfly.commands=/extension=org.wildfly.extension.microprofile.fault-tolerance-smallrye:add
> mvn wildfly:execute-commands -Dwildfly.commands=/subsystem=microprofile-fault-tolerance-smallrye:add
> mvn wildfly:shutdown -Dwildfly.reload=true
> {code}
> (3) I think there's no need to add the subsystem if using standalone-microprofile.xml config where it is already present.
> There might be additional issues I don't see because of JBEAP-19481.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13476) MP FT Quickstart: Missing supported shared-docs sections
by Eduardo Martins (Jira)
[ https://issues.redhat.com/browse/WFLY-13476?page=com.atlassian.jira.plugi... ]
Eduardo Martins updated WFLY-13476:
-----------------------------------
Fix Version/s: (was: 20.0.0.Beta1)
> MP FT Quickstart: Missing supported shared-docs sections
> --------------------------------------------------------
>
> Key: WFLY-13476
> URL: https://issues.redhat.com/browse/WFLY-13476
> Project: WildFly
> Issue Type: Bug
> Components: MP Fault Tolerance, Quickstarts
> Affects Versions: 19.1.0.Final
> Reporter: Eduardo Martins
> Assignee: Radoslav Husar
> Priority: Critical
>
> Consider adding standard sections - see other QS
> * Use of the EAP_HOME and QUICKSTART_HOME Variables
> * Start the JBoss EAP XP Standalone Server
> * Build and Deploy the Quickstart
> * Access the Application
> * Undeploy the Quickstart
> * Run the Quickstart in Red Hat JBoss Developer Studio or Eclipse
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13476) MP FT Quickstart: Missing supported shared-docs sections
by Eduardo Martins (Jira)
[ https://issues.redhat.com/browse/WFLY-13476?page=com.atlassian.jira.plugi... ]
Eduardo Martins updated WFLY-13476:
-----------------------------------
Description:
Consider adding standard sections - see other QS
* Use of the EAP_HOME and QUICKSTART_HOME Variables
* Start the JBoss EAP XP Standalone Server
* Build and Deploy the Quickstart
* Access the Application
* Undeploy the Quickstart
* Run the Quickstart in Red Hat JBoss Developer Studio or Eclipse
was:
(1) WildFly pom is used instead of EAP XP one:
{code}
<groupId>org.wildfly.bom</groupId>
<artifactId>wildfly-microprofile</artifactId>
<version>${version.server.bom}</version>
where ${version.server.bom} is the version of your JBoss EAP XP, in our case "1.0".
{code}
This is mentioned in JBEAP-19481 as well.
(2) Unsupported commands for starting and managing EAP:
{code}
mvn wildfly:run &
mvn wildfly:execute-commands -Dwildfly.commands=/extension=org.wildfly.extension.microprofile.fault-tolerance-smallrye:add
mvn wildfly:execute-commands -Dwildfly.commands=/subsystem=microprofile-fault-tolerance-smallrye:add
mvn wildfly:shutdown -Dwildfly.reload=true
{code}
(3) I think there's no need to add the subsystem if using standalone-microprofile.xml config where it is already present.
(4) Consider adding standard sections - see other QS
* Use of the EAP_HOME and QUICKSTART_HOME Variables
* Start the JBoss EAP XP Standalone Server
* Build and Deploy the Quickstart
* Access the Application
* Undeploy the Quickstart
* Run the Quickstart in Red Hat JBoss Developer Studio or Eclipse
There might be additional issues I don't see because of JBEAP-19481.
> MP FT Quickstart: Missing supported shared-docs sections
> --------------------------------------------------------
>
> Key: WFLY-13476
> URL: https://issues.redhat.com/browse/WFLY-13476
> Project: WildFly
> Issue Type: Bug
> Components: MP Fault Tolerance, Quickstarts
> Affects Versions: 19.1.0.Final
> Reporter: Eduardo Martins
> Assignee: Radoslav Husar
> Priority: Critical
>
> Consider adding standard sections - see other QS
> * Use of the EAP_HOME and QUICKSTART_HOME Variables
> * Start the JBoss EAP XP Standalone Server
> * Build and Deploy the Quickstart
> * Access the Application
> * Undeploy the Quickstart
> * Run the Quickstart in Red Hat JBoss Developer Studio or Eclipse
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13476) MP FT Quickstart: Missing supported shared-docs sections
by Eduardo Martins (Jira)
[ https://issues.redhat.com/browse/WFLY-13476?page=com.atlassian.jira.plugi... ]
Eduardo Martins updated WFLY-13476:
-----------------------------------
Git Pull Request: (was: https://github.com/wildfly/quickstart/pull/423)
> MP FT Quickstart: Missing supported shared-docs sections
> --------------------------------------------------------
>
> Key: WFLY-13476
> URL: https://issues.redhat.com/browse/WFLY-13476
> Project: WildFly
> Issue Type: Bug
> Components: MP Fault Tolerance, Quickstarts
> Affects Versions: 19.1.0.Final
> Reporter: Eduardo Martins
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 20.0.0.Beta1
>
>
> (1) WildFly pom is used instead of EAP XP one:
> {code}
> <groupId>org.wildfly.bom</groupId>
> <artifactId>wildfly-microprofile</artifactId>
> <version>${version.server.bom}</version>
> where ${version.server.bom} is the version of your JBoss EAP XP, in our case "1.0".
> {code}
> This is mentioned in JBEAP-19481 as well.
> (2) Unsupported commands for starting and managing EAP:
> {code}
> mvn wildfly:run &
> mvn wildfly:execute-commands -Dwildfly.commands=/extension=org.wildfly.extension.microprofile.fault-tolerance-smallrye:add
> mvn wildfly:execute-commands -Dwildfly.commands=/subsystem=microprofile-fault-tolerance-smallrye:add
> mvn wildfly:shutdown -Dwildfly.reload=true
> {code}
> (3) I think there's no need to add the subsystem if using standalone-microprofile.xml config where it is already present.
> (4) Consider adding standard sections - see other QS
> * Use of the EAP_HOME and QUICKSTART_HOME Variables
> * Start the JBoss EAP XP Standalone Server
> * Build and Deploy the Quickstart
> * Access the Application
> * Undeploy the Quickstart
> * Run the Quickstart in Red Hat JBoss Developer Studio or Eclipse
> There might be additional issues I don't see because of JBEAP-19481.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13476) MP FT Quickstart: Missing supported shared-docs sections
by Eduardo Martins (Jira)
Eduardo Martins created WFLY-13476:
--------------------------------------
Summary: MP FT Quickstart: Missing supported shared-docs sections
Key: WFLY-13476
URL: https://issues.redhat.com/browse/WFLY-13476
Project: WildFly
Issue Type: Bug
Components: MP Fault Tolerance, Quickstarts
Affects Versions: 19.1.0.Final
Reporter: Eduardo Martins
Assignee: Radoslav Husar
Fix For: 20.0.0.Beta1
(1) WildFly pom is used instead of EAP XP one:
{code}
<groupId>org.wildfly.bom</groupId>
<artifactId>wildfly-microprofile</artifactId>
<version>${version.server.bom}</version>
where ${version.server.bom} is the version of your JBoss EAP XP, in our case "1.0".
{code}
This is mentioned in JBEAP-19481 as well.
(2) Unsupported commands for starting and managing EAP:
{code}
mvn wildfly:run &
mvn wildfly:execute-commands -Dwildfly.commands=/extension=org.wildfly.extension.microprofile.fault-tolerance-smallrye:add
mvn wildfly:execute-commands -Dwildfly.commands=/subsystem=microprofile-fault-tolerance-smallrye:add
mvn wildfly:shutdown -Dwildfly.reload=true
{code}
(3) I think there's no need to add the subsystem if using standalone-microprofile.xml config where it is already present.
(4) Consider adding standard sections - see other QS
* Use of the EAP_HOME and QUICKSTART_HOME Variables
* Start the JBoss EAP XP Standalone Server
* Build and Deploy the Quickstart
* Access the Application
* Undeploy the Quickstart
* Run the Quickstart in Red Hat JBoss Developer Studio or Eclipse
There might be additional issues I don't see because of JBEAP-19481.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13444) Observing High CPU in EPollArrayWrapper.epollCtl default I/O thread
by Srinivas ev (Jira)
[ https://issues.redhat.com/browse/WFLY-13444?page=com.atlassian.jira.plugi... ]
Srinivas ev edited comment on WFLY-13444 at 5/15/20 5:43 AM:
-------------------------------------------------------------
Hi [~flavia.rainone],
Attached new thread dump from my system.
default I/O-77 and default I/O-35 are top consumers.
!default io consuming snapshot.PNG|thumbnail!
!default io consuming.PNG|thumbnail!
[^threaddump-1589514505334.tdump]
"default I/O-77" - Thread t@172
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <7fa22b17> (a sun.nio.ch.Util$3)
- locked <23bbdf60> (a java.util.Collections$UnmodifiableSet)
- locked <751407ac> (a sun.nio.ch.EPollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
Locked ownable synchronizers:
- None
"default I/O-35" - Thread t@129
java.lang.Thread.State: RUNNABLE
at java.lang.Throwable.fillInStackTrace(Native Method)
at java.lang.Throwable.fillInStackTrace(Throwable.java:784)
- locked <1ac6bf12> (a java.nio.channels.ClosedChannelException)
at java.lang.Throwable.<init>(Throwable.java:251)
at java.lang.Exception.<init>(Exception.java:54)
at java.io.IOException.<init>(IOException.java:47)
at java.nio.channels.ClosedChannelException.<init>(ClosedChannelException.java:52)
at org.xnio.ssl.JsseStreamConduit.write(JsseStreamConduit.java:1022)
at org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150)
at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:385)
at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:372)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
at org.xnio.ssl.JsseStreamConduit.run(JsseStreamConduit.java:393)
at org.xnio.ssl.JsseStreamConduit.readReady(JsseStreamConduit.java:547)
at org.xnio.ssl.JsseStreamConduit$2.readReady(JsseStreamConduit.java:319)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:567)
Can you please suggest any workaround for this.
was (Author: ev.srinivas):
Hi [~flavia.rainone],
Attached new thread dump from my system.
default I/O-77 and default I/O-35 are top consumers.
!default io consuming snapshot.PNG|thumbnail!
!default io consuming.PNG|thumbnail!
[^threaddump-1589514505334.tdump]
Can you please suggest any workaround for this.
> Observing High CPU in EPollArrayWrapper.epollCtl default I/O thread
> -------------------------------------------------------------------
>
> Key: WFLY-13444
> URL: https://issues.redhat.com/browse/WFLY-13444
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 10.1.0.Final
> Reporter: Srinivas ev
> Assignee: Flavia Rainone
> Priority: Major
> Attachments: IO thread memory.PNG, IO thread.PNG, Thread consuming high CPU.PNG, ThreadDump1set.zip, ThreadDump2set.zip, default IO thread 73.PNG, default io consuming snapshot.PNG, default io consuming.PNG, stack trace from snapshot.PNG, stack trace in thread dump.PNG, threaddump-1589514505334.tdump, top command output.PNG
>
>
> Facing high CPU by one of the default I/O thread In Wildfly 10.1.0 Final. Looks none of our application component thread is consuming.
> Can somebody check what is triggering this issue? I attached the thread stack to this Jira. This is blocking our releases. When the CPU cores are high in number, multiple default I/O threads will kick in consuming the CPU in 90~100% range continuously.
> Wildfly 10.1.0 Final
> Java -
> openjdk version "1.8.0_232"
> OpenJDK Runtime Environment (build 1.8.0_232-b09)
> OpenJDK 64-Bit Server VM (build 25.232-b09, mixed mode
> ---------------------------------------------------------------------------------------------------
> at java.lang.Throwable.fillInStackTrace(Native Method)
> at java.lang.Throwable.fillInStackTrace(Throwable.java:784)
> at java.lang.Throwable.<init>(Throwable.java:251)
> at java.lang.Exception.<init>(Exception.java:54)
> at java.io.IOException.<init>(IOException.java:47)
> at java.nio.channels.ClosedChannelException.<init>(ClosedChannelException.java:52)
> at org.xnio.ssl.JsseStreamConduit.write(JsseStreamConduit.java:1022)
> at org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:385)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:372)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
> at org.xnio.ssl.JsseStreamConduit.run(JsseStreamConduit.java:393)
> at org.xnio.ssl.JsseStreamConduit.readReady(JsseStreamConduit.java:547)
> at org.xnio.ssl.JsseStreamConduit$2.readReady(JsseStreamConduit.java:319)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:567)
> -------------------------------------------------------------------------------------------
> at sun.nio.ch.EPollArrayWrapper.epollCtl(Native Method)
> at sun.nio.ch.EPollArrayWrapper.updateRegistrations(EPollArrayWrapper.java:299)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:268)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
> -----------------------------------------------------------------------------------
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (REMJMX-168) JMX proxy connection is released sooner than the client asks for closing it
by Ondrej Chaloupka (Jira)
[ https://issues.redhat.com/browse/REMJMX-168?page=com.atlassian.jira.plugi... ]
Ondrej Chaloupka commented on REMJMX-168:
-----------------------------------------
[~dlofthouse] yes, it seems it was fixed in {{3.0.4.Final}} and the all description of REMJMX-166 seems to be matching what I was experiencing and why this issue was created. I'm closing this issue as duplicate to REMJMX-166.
> JMX proxy connection is released sooner than the client asks for closing it
> ---------------------------------------------------------------------------
>
> Key: REMJMX-168
> URL: https://issues.redhat.com/browse/REMJMX-168
> Project: Remoting JMX
> Issue Type: Bug
> Components: Connection
> Affects Versions: 3.0.2.Final, 3.0.3.Final
> Reporter: Ondrej Chaloupka
> Priority: Major
> Fix For: 3.0.4.Final
>
>
> We started to hit the issue on Narayana transaction recovery testing. Reported as JBEAP-18109. It seems to be caused by changes made at REMJMX-160.
> What we hit:
> It seems the JMX connection *is closed* too soon - before the client decides to release it.
> The client creates a JMX proxy. Then it does not use it for a while. And then it runs the JMX calls again. Such attempt then fails.
> Our test does:
> * The transaction recovery test creates the JMX proxy at some point to verify content of object store.
> * Then there is some idle time where the JMX proxy is not utilized.
> * When the testsuite tries to verify the content of object store once again on the same JMX proxy that attempt fails.
> From investigation it seems that it could be caused by the fact that {{Executors.newCachedThreadPool}} (https://github.com/jbossas/remoting-jmx/blob/3.0.3.Final/src/main/java/or...) is used for thread creation. The JMX thread is idle more than 60 seconds and the thread pool may dispose the threads after that time (after 60s, see https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Executors....).
> When I used the {{Executors.newFixedThreadPool}} (https://github.com/ochaloup/remoting-jmx/commit/7ec37c8a09f4d8229ee8263ad...) the issue disappeared.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13461) Jaxrs requires bean-validation when cdi is present
by Jean Francois Denise (Jira)
[ https://issues.redhat.com/browse/WFLY-13461?page=com.atlassian.jira.plugi... ]
Jean Francois Denise commented on WFLY-13461:
---------------------------------------------
[~brian.stansberry], I read https://issues.redhat.com/browse/WFLY-12763. It is clear that the config needs to be updated after this change. bean-validation has now an optional dependency on cdi, so the way to go is to adjust my configuration to be jaxrs,bean-validation instead of jaxrs,cdi.
> Jaxrs requires bean-validation when cdi is present
> --------------------------------------------------
>
> Key: WFLY-13461
> URL: https://issues.redhat.com/browse/WFLY-13461
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 20.0.0.Beta1
> Reporter: Jean Francois Denise
> Assignee: Jean Francois Denise
> Priority: Major
>
> We are provisioning a server containing jaxrs and cdi. The deployment fails with the pasted exception.
> This has been caused by fix for WFLY-13189. bean-validation subsystem used to be provisioned with cdi.
> {quote}
> 12:57:20,521 INFO [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 16) RESTEASY002225: Deploying javax.ws.rs.core.Application: class com.example.demo.rest.RestApplication
> 12:57:20,562 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 16) MSC000001: Failed to start service jboss.deployment.unit."ROOT.war".undertow-deployment: org.jboss.msc.service.StartException in service jboss.deployment.unit."ROOT.war".undertow-deployment: javax.validation.ValidationException: RESTEASY008520: Unable to load Validation support
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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:1377)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: javax.validation.ValidationException: RESTEASY008520: Unable to load Validation support
> at org.jboss.resteasy.plugins.validation.AbstractValidatorContextResolver.getContext(AbstractValidatorContextResolver.java:97)
> at org.jboss.resteasy.plugins.validation.ValidatorContextResolver.getContext(ValidatorContextResolver.java:16)
> at org.jboss.resteasy.core.ResourceMethodInvoker.<init>(ResourceMethodInvoker.java:131)
> at org.jboss.resteasy.core.ResourceMethodRegistry.processMethod(ResourceMethodRegistry.java:351)
> at org.jboss.resteasy.core.ResourceMethodRegistry.register(ResourceMethodRegistry.java:278)
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:229)
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:201)
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:187)
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:164)
> at org.jboss.resteasy.core.ResourceMethodRegistry.addPerRequestResource(ResourceMethodRegistry.java:81)
> at org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:485)
> at org.jboss.resteasy.spi.ResteasyDeployment.startInternal(ResteasyDeployment.java:286)
> at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:92)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:119)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
> at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
> at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:305)
> at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:145)
> at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:585)
> at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:556)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:598)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:97)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:78)
> ... 8 more
> Caused by: javax.validation.NoProviderFoundException: Unable to create a Configuration, because no Jakarta Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath.
> at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:291)
> at org.jboss.resteasy.plugins.validation.AbstractValidatorContextResolver.getConfig(AbstractValidatorContextResolver.java:78)
> at org.jboss.resteasy.plugins.validation.AbstractValidatorContextResolver.getContext(AbstractValidatorContextResolver.java:90)
> ... 34 more
> 12:57:20,567 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "jaxrs.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"ROOT.war\".undertow-deployment" => "javax.validation.ValidationException: RESTEASY008520: Unable to load Validation support
> Caused by: javax.validation.ValidationException: RESTEASY008520: Unable to load Validation support
> Caused by: javax.validation.NoProviderFoundException: Unable to create a Configuration, because no Jakarta Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath."}}
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months