[JBoss JIRA] (WFLY-2859) Treating all JAX-RS components as CDI Beans has some negative consequences
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-2859?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-2859:
-------------------------------------
[~mkopecky] this seems like it might be resolved in WildFly 17.0.0.Beta1 as it's upgraded to RESTEasy 3.7.0.Final. Can you please confirm?
> Treating all JAX-RS components as CDI Beans has some negative consequences
> --------------------------------------------------------------------------
>
> Key: WFLY-2859
> URL: https://issues.jboss.org/browse/WFLY-2859
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, REST
> Affects Versions: 8.0.0.CR1, 16.0.0.Beta1
> Reporter: Matt Drees
> Assignee: Stuart Douglas
> Priority: Major
>
> It seems that wildfly is now treating all jax-rs Providers and Resources as CDI Beans. This is probably fine most of the time, but there are some Provider classes that cause UnproxyableResolutionException (WELD-001437) errors, due to the fact that resteasy-cdi attempts to get bean reference whose type is identical to the bean class.
> See the forum link for a specific instance of this.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFLY-11680) jax-rs and CDI: FormParam in BeanParam is not injected
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11680?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-11680:
---------------------------------
Fix Version/s: 17.0.0.Beta1
> jax-rs and CDI: FormParam in BeanParam is not injected
> ------------------------------------------------------
>
> Key: WFLY-11680
> URL: https://issues.jboss.org/browse/WFLY-11680
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, REST
> Reporter: Marek Kopecky
> Assignee: Ivo Studensky
> Priority: Critical
> Fix For: 17.0.0.Beta1
>
>
> 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)
6 years, 11 months
[JBoss JIRA] (WFLY-11793) JPA EntityManager merge infinite loop - java.lang.StackOverflowError
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11793?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-11793:
---------------------------------
Steps to Reproduce:
Perform the following mapping with JPA:
{code:java}
public class Papel{
....
@OneToMany(mappedBy = "id.papel", cascade = { CascadeType.ALL }, orphanRemoval = true)
private List<PermissaoAtribuida> permissoesAtribuidas = new ArrayList<>();
....
}
{code}
{code:java}
public class Permissao{
....
@Id
@Getter
@Setter
@GeneratedValue(strategy = GenerationType.IDENTITY)
@Column(name = "PK", insertable = false, updatable = false)
private Integer id;
....
}
{code}
{code:java}
public class PermissaoAtribuida{
....
@EmbeddedId
private Id id;
@Embeddable
@EqualsAndHashCode(of = { "permissao", "papel" })
public static class Id{
@ManyToOne(optional = false, fetch = FetchType.LAZY)
@JoinColumn(name = "FK_PERMISSAO", nullable = false)
private Permissao permissao;
@ManyToOne(optional = false, fetch = FetchType.LAZY)
@JoinColumn(name = "FK_PAPEL", nullable = false)
private Papel papel;
}
....
}
{code}
And invoke the following code snippet, whereas papelServico is an EJB abstracting the DAO layer:
{code:java}
Papel papel = new Papel();
papel.setNome("Insert");
papelServico.insert(papel);
Permissao permissao = ...
List<PermissaoAtribuida> l = new ArrayList<>();
l.add(new PermissaoAtribuida(permissao, papel));
papel.setPermissoesAtribuidas(l);
papel.setNome("Update");
papelServico.update(papel);
{code}
This problem only occurs if the permissaoAtribuida properties of class Papel are mapped with cascade = {CascadeType.ALL}.
was:
Perform the following mapping with JPA:
public class Papel{
....
@OneToMany(mappedBy = "id.papel", cascade = { CascadeType.ALL }, orphanRemoval = true)
private List<PermissaoAtribuida> permissoesAtribuidas = new ArrayList<>();
....
}
public class Permissao{
....
@Id
@Getter
@Setter
@GeneratedValue(strategy = GenerationType.IDENTITY)
@Column(name = "PK", insertable = false, updatable = false)
private Integer id;
....
}
public class PermissaoAtribuida{
....
@EmbeddedId
private Id id;
@Embeddable
@EqualsAndHashCode(of = { "permissao", "papel" })
public static class Id{
@ManyToOne(optional = false, fetch = FetchType.LAZY)
@JoinColumn(name = "FK_PERMISSAO", nullable = false)
private Permissao permissao;
@ManyToOne(optional = false, fetch = FetchType.LAZY)
@JoinColumn(name = "FK_PAPEL", nullable = false)
private Papel papel;
}
....
}
And invoke the following code snippet, whereas papelServico is an EJB abstracting the DAO layer:
Papel papel = new Papel();
papel.setNome("Insert");
papelServico.insert(papel);
Permissao permissao = ...
List<PermissaoAtribuida> l = new ArrayList<>();
l.add(new PermissaoAtribuida(permissao, papel));
papel.setPermissoesAtribuidas(l);
papel.setNome("Update");
papelServico.update(papel);
This problem only occurs if the permissaoAtribuida properties of class Papel are mapped with cascade = {CascadeType.ALL}.
> JPA EntityManager merge infinite loop - java.lang.StackOverflowError
> --------------------------------------------------------------------
>
> Key: WFLY-11793
> URL: https://issues.jboss.org/browse/WFLY-11793
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 15.0.1.Final
> Environment: MAC OS Mojave
> Java 11
> Wildfly 15.0.1-Final
> Data Base Postgresql
> Reporter: Bruno Maioli Martins
> Assignee: Scott Marlow
> Priority: Critical
> Attachments: jstack.txt, server+querys.log, server-1.log, teste.zip
>
>
> Dear,
> When executing the update of a record invoking getEntityManager().merge(obj) the application goes into infinite loop. This behavior only occurs when there is a OneToMany bidirectional mapping of the entity Papel -> PermissaoAtribuida.
> If the same code runs outside of the Wildfly server context its execution occurs normally.
> Apparently the call getEntityManager.().merge(obj) attempts infinite selects to sync the object with transaction context before doing the merge.
> Attach the source code of my test classes.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFLY-11983) Unify line-endings of bat scripts (regression against WF15)
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11983?page=com.atlassian.jira.plugin... ]
James Perkins commented on WFLY-11983:
--------------------------------------
This seems like something that would be difficult to enforce. Is this needed for a specific reason?
> Unify line-endings of bat scripts (regression against WF15)
> -----------------------------------------------------------
>
> Key: WFLY-11983
> URL: https://issues.jboss.org/browse/WFLY-11983
> Project: WildFly
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 16.0.0.Final
> Reporter: Marek Kopecky
> Assignee: James Perkins
> Priority: Critical
>
> Line-endings of bat scripts should be unified. This is regression against WF15.
> Some files in WF16 uses CRLF, another LF only. We need to clarify the recommended line ending and use this line ending in all Windows scripts.
> WF16:
> {noformat}
> $ find | grep bat$ | xargs file
> ./wsprovide.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./jboss-cli.bat: DOS batch file, ASCII text
> ./elytron-tool.bat: DOS batch file, ASCII text
> ./domain.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./wsconsume.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./standalone.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./vault.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./domain.conf.bat: ASCII text, with CRLF line terminators
> ./common.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./jdr.bat: DOS batch file, ASCII text
> ./jconsole.bat: DOS batch file, ASCII text
> ./appclient.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./appclient.conf.bat: ASCII text, with CRLF line terminators
> ./standalone.conf.bat: ASCII text, with CRLF line terminators
> ./add-user.bat: DOS batch file, ASCII text
> $
> {noformat}
> WF15:
> {noformat}
> $ find | grep bat$ | xargs file
> ./wsprovide.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./jboss-cli.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./elytron-tool.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./domain.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./wsconsume.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./standalone.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./vault.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./domain.conf.bat: ASCII text, with CRLF line terminators
> ./common.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./jdr.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./jconsole.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./appclient.bat: DOS batch file, ASCII text, with CRLF line terminators
> ./appclient.conf.bat: ASCII text, with CRLF line terminators
> ./standalone.conf.bat: ASCII text, with CRLF line terminators
> ./add-user.bat: DOS batch file, ASCII text, with CRLF line terminators
> $
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFLY-12031) Memory leak in wildfly transaction client
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-12031?page=com.atlassian.jira.plugin... ]
James Perkins commented on WFLY-12031:
--------------------------------------
[~cfang] What is the status of this?
> Memory leak in wildfly transaction client
> -----------------------------------------
>
> Key: WFLY-12031
> URL: https://issues.jboss.org/browse/WFLY-12031
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 15.0.1.Final
> Environment: wildfly-transaction-client-1.1.3.Final
> wildfly.15.0.1.Final
> Windows 10
> Reporter: Joachim Petrich
> Assignee: Cheng Fang
> Priority: Critical
>
> After a volume run of our system we recognized millions of entries in the openFilePaths Object of class FileSystemXAResourceRegistry. When enabling traces for org.wildfly.transaction it seems that for adding an entry a xid string is used
> {code:java}
> XAResourceRegistryFile(Xid xid) throws SystemException {
> xaRecoveryPath.toFile().mkdir(); // create dir if non existent
> final String xidString = SimpleXid.of(xid).toHexString('_');
> this.filePath = xaRecoveryPath.resolve(xidString);
> openFilePaths.add(*xidString*);
> {code}
> and for removing the entire file path:
> {code:java}
> protected void removeResource(XAResource resource) throws XAException {
> if (resources.remove(resource)) {
> if (resources.isEmpty()) {
> // delete file
> try {
> if (fileChannel != null) {
> fileChannel.close();
> }
> Files.delete(filePath);
> // deleting using the filepath as key caused a memory leak,
> // if xid string have been added, therefore build the xid string for removing
> openFilePaths.remove(*filePath.toString()*);
> {code}
> We didn't find any code where this xid are cleaned up.
> As workaround we additionally extract the xid String from the file path and remove the corresponding entry.
> {code:java}
> String xidString = filePath.toString().substring(filePath.toString().indexOf(
> xaRecoveryPath.toString()) + xaRecoveryPath.toString().length() + 1);
> openFilePaths.remove(xidString);
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFLY-11720) Cannot invoke EJB over HTTP on JDK 11
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11720?page=com.atlassian.jira.plugin... ]
James Perkins resolved WFLY-11720.
----------------------------------
Resolution: Done
> Cannot invoke EJB over HTTP on JDK 11
> -------------------------------------
>
> Key: WFLY-11720
> URL: https://issues.jboss.org/browse/WFLY-11720
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Remoting
> Affects Versions: 16.0.0.Beta1
> Environment: JDK 11
> Reporter: Jan Kasik
> Assignee: Cheng Fang
> Priority: Critical
> Fix For: 17.0.0.Alpha1
>
> Attachments: classes.zip, client-app.zip
>
>
> Run of client app calling EJB over HTTP fails on JDK 11 with following log:
> {noformat}
> Feb 14, 2019 12:49:30 PM org.wildfly.naming.client.Version <clinit>
> INFO: WildFly Naming version 1.0.6.Final
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.wildfly.security.manager.GetAccessibleDeclaredFieldAction (file:/home/hudson/hudson_workspace/mod_cluster/client/wildfly-elytron-1.1.3.Final.jar) to field java.security.AccessControlContext.context
> WARNING: Please consider reporting this to the maintainers of org.wildfly.security.manager.GetAccessibleDeclaredFieldAction
> 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
> Feb 14, 2019 12:49:30 PM org.wildfly.security.Version <clinit>
> INFO: ELY00001: WildFly Elytron version 1.1.3.Final
> Feb 14, 2019 12:49:30 PM org.jboss.ejb.client.EJBClient <clinit>
> INFO: JBoss EJB Client version 4.0.2.Final
> Feb 14, 2019 12:49:30 PM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.6.5.Final
> Feb 14, 2019 12:49:30 PM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.6.5.Final
> Feb 14, 2019 12:49:30 PM org.jboss.threads.Version <clinit>
> INFO: JBoss Threads version 2.3.0.Beta2
> Feb 14, 2019 12:49:30 PM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 5.0.0.Final
> Feb 14, 2019 12:49:30 PM org.jboss.threads.LoggingUncaughtExceptionHandler uncaughtException
> ERROR: Thread Thread[XNIO-1 task-1,5,main] threw an uncaught exception
> java.lang.ExceptionInInitializerError
> at org.jboss.marshalling.river.RiverMarshaller.<clinit>(RiverMarshaller.java:1335)
> at org.jboss.marshalling.river.RiverMarshallerFactory.createMarshaller(RiverMarshallerFactory.java:54)
> at org.wildfly.httpclient.common.HttpTargetContext.createMarshaller(HttpTargetContext.java:132)
> at org.wildfly.httpclient.ejb.HttpEJBReceiver.marshalEJBRequest(HttpEJBReceiver.java:367)
> at org.wildfly.httpclient.ejb.HttpEJBReceiver.lambda$processInvocation$1(HttpEJBReceiver.java:185)
> at org.wildfly.httpclient.common.HttpTargetContext$1.lambda$completed$0(HttpTargetContext.java:338)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1871)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1400)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.IllegalStateException: No standard field found for reverse order comparator!
> at org.jboss.marshalling.river.Protocol.<clinit>(Protocol.java:287)
> ... 9 more
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months