[JBoss JIRA] (WFCORE-5062) Bootable JAR doesn't create install directories
by Jean Francois Denise (Jira)
Jean Francois Denise created WFCORE-5062:
--------------------------------------------
Summary: Bootable JAR doesn't create install directories
Key: WFCORE-5062
URL: https://issues.redhat.com/browse/WFCORE-5062
Project: WildFly Core
Issue Type: Bug
Reporter: Jean Francois Denise
Assignee: Jeff Mesnil
The issue occurs with --install-dir Bootable JAR option,
In case the first entry to be unzipped is not a directory, the unzip fails because the install dir doesn't exist.
This issue is hidden on some platforms where the first entries are directories, in such case, directories hierarchy is created.
This issue blocks Arquilian container for Bootable JAR.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFLY-13697) JBoss CLI can't find java:app/AppName
by Jean Francois Denise (Jira)
[ https://issues.redhat.com/browse/WFLY-13697?page=com.atlassian.jira.plugi... ]
Jean Francois Denise commented on WFLY-13697:
---------------------------------------------
CLI calls into the management interface to send requests to the server. Some server operations that the CLI should send are perhaps missing? I don't see how the CLI could disable a server feature.
> JBoss CLI can't find java:app/AppName
> -------------------------------------
>
> Key: WFLY-13697
> URL: https://issues.redhat.com/browse/WFLY-13697
> Project: WildFly
> Issue Type: Bug
> Components: CLI
> Affects Versions: JBoss AS7 7.2.0.Final
> Reporter: José Fernando Tepedino Martins
> Assignee: Jean Francois Denise
> Priority: Minor
> Labels: CLI, JNDI
>
> With a JEE aplication in a WAR package, when starting a functionality, as a Batch Job, via CLI, CDI injection and JNDI lookup fail to find resources 'java:app/AppName' and 'java:module/ModuleName'.
> For example, a job listener or other job artifact with the following code
> {code:java}
> @Resource(lookup="java:app/AppName")
> private String applicationName;{code}
> or
> {code:java}
> private String applicationName;
> @PostConstruct
> protected void initialize() throws NamingException {
> applicationName = InitialContext.doLookup("java:app/AppName");
> }{code}
> when the batch job is started from JBoss CLI, the following error will be logged:
> {code:java}
> javax.naming.NameNotFoundException: java:app/AppName
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFLY-13697) JBoss CLI can't find java:app/AppName
by Michal Petrov (Jira)
[ https://issues.redhat.com/browse/WFLY-13697?page=com.atlassian.jira.plugi... ]
Michal Petrov commented on WFLY-13697:
--------------------------------------
[~jdenise], how does CLI talk to WidlFly? What is happening here is that the quickstart webapp creates a {{HttpServerExchange}} and Undertow will push {{InjectedEENamespaceContextSelector}} into {{NamespaceContextSelector}}. But with CLI this doesn't happen and {{NamespaceContextSelector}} will return the default selector (from {{DefaultNamespaceContextSelectorService}}) which cannot resolve "java:app".
> JBoss CLI can't find java:app/AppName
> -------------------------------------
>
> Key: WFLY-13697
> URL: https://issues.redhat.com/browse/WFLY-13697
> Project: WildFly
> Issue Type: Bug
> Components: CLI
> Affects Versions: JBoss AS7 7.2.0.Final
> Reporter: José Fernando Tepedino Martins
> Assignee: Jean Francois Denise
> Priority: Minor
> Labels: CLI, JNDI
>
> With a JEE aplication in a WAR package, when starting a functionality, as a Batch Job, via CLI, CDI injection and JNDI lookup fail to find resources 'java:app/AppName' and 'java:module/ModuleName'.
> For example, a job listener or other job artifact with the following code
> {code:java}
> @Resource(lookup="java:app/AppName")
> private String applicationName;{code}
> or
> {code:java}
> private String applicationName;
> @PostConstruct
> protected void initialize() throws NamingException {
> applicationName = InitialContext.doLookup("java:app/AppName");
> }{code}
> when the batch job is started from JBoss CLI, the following error will be logged:
> {code:java}
> javax.naming.NameNotFoundException: java:app/AppName
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFLY-13691) Ajax call causes exception: Target Unreachable, 'null' returned null
by erick leal (Jira)
[ https://issues.redhat.com/browse/WFLY-13691?page=com.atlassian.jira.plugi... ]
erick leal commented on WFLY-13691:
-----------------------------------
it is a different issue, present since mojarra 2.3 initial release, but is related to viewParam + INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL as the other problem. I couldn't reduce it to a reproducer not using PrimeFaces. But the issue is not present in Wildfly 13 (JSF 2.2)
The exception is
{code:java}
// 2020-07-21 20:03:59,246 WARNING [javax.enterprise.resource.webcontainer.jsf.lifecycle] (default task-2) /paginas/mudancaCelaConsulta.xhtml @12,70 value="#{testView.testClass.id}": Target Unreachable, 'null' returned null: javax.el.PropertyNotFoundException: /paginas/mudancaCelaConsulta.xhtml @12,70 value="#{testView.testClass.id}": Target Unreachable, 'null' returned null2020-07-21 20:03:59,246 WARNING [javax.enterprise.resource.webcontainer.jsf.lifecycle] (default task-2) /paginas/mudancaCelaConsulta.xhtml @12,70 value="#{testView.testClass.id}": Target Unreachable, 'null' returned null: javax.el.PropertyNotFoundException: /paginas/mudancaCelaConsulta.xhtml @12,70 value="#{testView.testClass.id}": Target Unreachable, 'null' returned null at com.sun.jsf-impl@2.3.9.SP11//com.sun.faces.facelets.el.TagValueExpression.getType(TagValueExpression.java:64) at com.sun.jsf-impl@2.3.9.SP11//com.sun.faces.renderkit.html_basic.HtmlBasicInputRenderer.getConvertedValue(HtmlBasicInputRenderer.java:71) at javax.faces.api@3.0.0.SP04//javax.faces.component.UIViewParameter.getConvertedValue(UIViewParameter.java:439) at javax.faces.api@3.0.0.SP04//javax.faces.component.UIInput.validate(UIInput.java:992) at javax.faces.api@3.0.0.SP04//javax.faces.component.UIInput.executeValidate(UIInput.java:1322) at javax.faces.api@3.0.0.SP04//javax.faces.component.UIInput.processValidators(UIInput.java:733) at javax.faces.api@3.0.0.SP04//javax.faces.component.UIViewParameter.processValidators(UIViewParameter.java:271) at javax.faces.api@3.0.0.SP04//javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:921) at javax.faces.api@3.0.0.SP04//javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:921) at javax.faces.api@3.0.0.SP04//javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:1310) at com.sun.jsf-impl@2.3.9.SP11//com.sun.faces.lifecycle.ProcessValidationsPhase.execute(ProcessValidationsPhase.java:53) at com.sun.jsf-impl@2.3.9.SP11//com.sun.faces.lifecycle.Phase.doPhase(Phase.java:76) at com.sun.jsf-impl@2.3.9.SP11//com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:177) at javax.faces.api@3.0.0.SP04//javax.faces.webapp.FacesServlet.executeLifecyle(FacesServlet.java:707) at javax.faces.api@3.0.0.SP04//javax.faces.webapp.FacesServlet.service(FacesServlet.java:451) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) at deployment.siapenweb.war//org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:89) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at io.undertow.websocket@2.1.3.Final//io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:173) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at io.opentracing.contrib.opentracing-jaxrs2//io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:52) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at deployment.siapenweb.war//filtro.AuthFilter.doFilter(AuthFilter.java:56) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at deployment.siapenweb.war//org.omnifaces.filter.GzipResponseFilter.doFilter(GzipResponseFilter.java:181) at deployment.siapenweb.war//org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:108) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.core@2.1.3.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.core@2.1.3.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.core@2.1.3.Final//io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.core@2.1.3.Final//io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.core@2.1.3.Final//io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.core@2.1.3.Final//io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.core@2.1.3.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.core@2.1.3.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68) at io.undertow.core@2.1.3.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) at org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530) at org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530) at org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530) at org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530) at org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78) at io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99) at io.undertow.core@2.1.3.Final//io.undertow.server.Connectors.executeRootHandler(Connectors.java:370) at io.undertow.core@2.1.3.Final//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830) 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:1377) at java.base/java.lang.Thread.run(Thread.java:834)Caused by: javax.el.PropertyNotFoundException: Target Unreachable, 'null' returned null at org.glassfish.jakarta.el@3.0.3.jbossorg-2//com.sun.el.parser.AstValue.getTarget(AstValue.java:165) at org.glassfish.jakarta.el@3.0.3.jbossorg-2//com.sun.el.parser.AstValue.getType(AstValue.java:62) at org.glassfish.jakarta.el@3.0.3.jbossorg-2//com.sun.el.ValueExpressionImpl.getType(ValueExpressionImpl.java:160) at org.jboss.weld.core@3.1.4.Final//org.jboss.weld.module.web.el.WeldValueExpression.getType(WeldValueExpression.java:93) at org.jboss.weld.core@3.1.4.Final//org.jboss.weld.module.web.el.WeldValueExpression.getType(WeldValueExpression.java:93) at com.sun.jsf-impl@2.3.9.SP11//com.sun.faces.facelets.el.TagValueExpression.getType(TagValueExpression.java:62) ... 75 more
{code}
> Ajax call causes exception: Target Unreachable, 'null' returned null
> --------------------------------------------------------------------
>
> Key: WFLY-13691
> URL: https://issues.redhat.com/browse/WFLY-13691
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 20.0.1.Final
> Reporter: erick leal
> Priority: Major
>
> I still have a problem with JSF 2.3 related to ViewParam, I tested it with WildFly 20.0.1 and the bug is still there. I tried to reduce the code, but I was only able to simulate the error using PrimeFaces. The code is in the repository [https://github.com/erickdeoliveiraleal/primefaces-test/tree/v...
> Note that Wildfly already incorporated all the fixes recently done by [@soul2zimate|https://github.com/soul2zimate]
> When you click on button the second time a exception happens, this is not the case when using mojarra 2.2, myfaces 2.2 or myfaces 2.3
> XHTML:
>
> {code:java}
> <f:metadata> <f:viewParam id="id" name="id" value="#{testView.testClass.id}" /> </f:metadata> <h:form> <p:commandButton update="@form" /> <p:dataTable var="m" selectionMode="single" selection="#{testView.testClass}" rowKey="#{m.id}" value="#{testView.testClasses}"> </p:dataTable> </h:form>{code}
> beans
> {code:java}
> import java.io.Serializable; import java.util.List; import javax.annotation.PostConstruct; import javax.faces.view.ViewScoped; import javax.inject.Named; @Named @ViewScoped public class TestView implements Serializable { private TestClass testClass; private List<TestClass> testClasses; @PostConstruct public void init() { testClass = new TestClass(); } public TestClass getTestClass() { return testClass; } public void setTestClass(TestClass testClass) { this.testClass = testClass; } public List<TestClass> getTestClasses() { return testClasses; } public void setTestClasses(List<TestClass> testClasses) { this.testClasses = testClasses; } }{code}
> model
> {code:java}
> public class TestClass { Integer id; public Integer getId() { return id; } public void setId(Integer id) { this.id = id; } }{code}
> You also need to set in web.xml the following param
> {code:java}
> <context-param> <param-name>javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL</param-name> <param-value>true</param-value> </context-param>{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFLY-13607) "SSL read loop detected" during remote EJB call; remote call blocks forever
by Victor Langelo (Jira)
[ https://issues.redhat.com/browse/WFLY-13607?page=com.atlassian.jira.plugi... ]
Victor Langelo commented on WFLY-13607:
---------------------------------------
We're seeing this same issue with WildFly 19.1.0.Final jboss-client.jar with java client running in java 11.0.6. We started noticing this after placing the server behind a nginx reverse proxy which terminates the SSL connection and forwards the http request to the WildFly server. The Wildfly server also have multiple virtual hosts. Let me know if the client messages would be useful.
> "SSL read loop detected" during remote EJB call; remote call blocks forever
> ---------------------------------------------------------------------------
>
> Key: WFLY-13607
> URL: https://issues.redhat.com/browse/WFLY-13607
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 19.1.0.Final
> Reporter: Kyle MacLeod
> Assignee: Flavia Rainone
> Priority: Major
>
> Summary: "SSL read loop detected" during remote EJB call; remote call blocks forever
> h3. Problem Description
> We are transferring data over an EJB request. The data returned from the EJB call ranges from 1-4MB in size.
> During one of these transfers, we are hitting some sort of race/timing condition which results in a "UT005076: SSL read loop detected" ERROR log.
> After the read loop detected log, the remote call blocks forever. Something is broken with the cleanup.
> Unfortunately, this is only happening on some of our servers. It's difficult to reproduce - and I don't have a test case for it.
> Other notes:
> * The issue is seen on the client side. The client is a java standalone client. All are running in docker containers. The issue is seen both running under docker-compose and under kubernetes.
> * The issue is seen with the 19.0.1.Final wildfly-client-all jar. It is NOT seen when we revert back to 18.0.0.Final wildfly-client-all jar.* It looks to me like an issue in either SslConduit or WildflyClientInputStream. There were commits post-18.0.0.Final which hit code in this area.
> h3. Logs
> What we see in the log file is these two back-to-back errors from the same thread:
> {code:language=|borderStyle=solid|theme=RDark|linenumbers=true|collapse=false}
> 2020-06-09 15:04:30,378 ERROR [io.undertow.request] [AgentServerModelRegistrationStateChangeNotification-pool-21-thread-1] UT005076: SSL read loop detected. This should not happen, please report this to the Undertow developers. Current state SslConduit{state=4, outstandingTasks=0, wrappedData=null, dataToUnwrap=null, unwrappedData=null}
> 2020-06-09 15:04:30,552 ERROR [io.undertow.request] [AgentServerModelRegistrationStateChangeNotification-pool-21-thread-1] UT005076: SSL read loop detected. This should not happen, please report this to the Undertow developers. Current state SslConduit{state=30692, outstandingTasks=0, wrappedData=null, dataToUnwrap=null, unwrappedData=null}
> {code}
> And then that same thread gets blocked forever, stuck waiting for the lock at org.wildfly.httpclient.common.WildflyClientInputStream.read(WildflyClientInputStream.java:147)
> {code:language=|borderStyle=solid|theme=RDark|linenumbers=true|collapse=true}
> "AgentServerModelRegistrationStateChangeNotification-pool-21-thread-1" #40 prio=5 os_prio=0 tid=0x00007f5cac9f8000 nid=0x47 in Object.wait() [0x00007f5c8b1d5000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:502)
> at org.wildfly.httpclient.common.WildflyClientInputStream.read(WildflyClientInputStream.java:147)
> - locked <0x00000000ed9475a8> (a java.lang.Object)
> at java.io.FilterInputStream.read(FilterInputStream.java:133)
> at org.jboss.marshalling.SimpleDataInput.readFully(SimpleDataInput.java:175)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadByteArray(RiverUnmarshaller.java:1622)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadArray(RiverUnmarshaller.java:1690)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:355)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:231)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1864)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1778)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1406)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:283)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:216)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.wildfly.httpclient.ejb.HttpEJBReceiver$2.getResult(HttpEJBReceiver.java:207)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:613)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:544)
> at org.jboss.ejb.protocol.remote.RemotingEJBClientInterceptor.handleInvocationResult(RemotingEJBClientInterceptor.java:57)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:615)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:544)
> at org.jboss.ejb.client.TransactionPostDiscoveryInterceptor.handleInvocationResult(TransactionPostDiscoveryInterceptor.java:148)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:615)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:544)
> at org.jboss.ejb.client.DiscoveryEJBClientInterceptor.handleInvocationResult(DiscoveryEJBClientInterceptor.java:137)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:615)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:544)
> at org.jboss.ejb.client.NamingEJBClientInterceptor.handleInvocationResult(NamingEJBClientInterceptor.java:87)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:615)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:544)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:212)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:615)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:544)
> at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:986)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:191)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:125)
> at com.sun.proxy.$Proxy24.getAdapterArchive(Unknown Source)
> at com.nakina.agent.application.adaptermanager.internal.dataservice.AgentRemoteAdapterArchiveRepositoryImpl$FakeRemoteIterator.next(AgentRemoteAdapterArchiveRepositoryImpl.java:226)
> at com.nakina.agent.application.adaptermanager.internal.dataservice.AgentRemoteAdapterArchiveRepositoryImpl$FakeRemoteIterator.next(AgentRemoteAdapterArchiveRepositoryImpl.java:189)
> at com.nakina.adaptermanager.AdapterManagerImpl.addToLocalRepository(AdapterManagerImpl.java:506)
> at com.nakina.adaptermanager.AdapterManagerImpl.synchronizeLocalRepository(AdapterManagerImpl.java:617)
> at com.nakina.adaptermanager.AdapterManagerImpl.initialize(AdapterManagerImpl.java:373)
> at com.nakina.agent.application.adaptermanager.internal.dataservice.AdapterManagerFactoryImpl.getAdapterManager(AdapterManagerFactoryImpl.java:66)
> - locked <0x00000000c07fa748> (a java.lang.Object)
> at com.nakina.agent.application.adaptermanager.internal.action.StartAdapterManagerAction.execute(StartAdapterManagerAction.java:54)
> at com.nakina.oss.server.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
> ...
> at com.nakina.oss.server.af.app.message.DefaultMessageReceiver.execute(DefaultMessageReceiver.java:65)
> at com.nakina.oss.server.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
> at com.nakina.oss.server.af.app.message.DefaultMessageReceiver.onMessage(DefaultMessageReceiver.java:154)
> at com.nakina.oss.server.af.app.impl.LocalMessageSenderImpl$SenderRunnable.run(LocalMessageSenderImpl.java:189)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> h3. Other information:
> Java version:
> {code:language=|borderStyle=solid|theme=RDark|linenumbers=true|collapse=false}
> $ java -version
> openjdk version "1.8.0_252"
> OpenJDK Runtime Environment (build 1.8.0_252-b09)
> OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode)
> {code}
> Wildfly server version:
> {code:language=|borderStyle=solid|theme=RDark|linenumbers=true|collapse=false}
> WFLYSRV0049: WildFly Full 19.1.0.Final (WildFly Core 11.1.1.Final) starting
> {code}
> wildfly-client-all version:
> * 19.0.1.Final wildfly-client-all jar.
> * NOT seen when we revert back to 18.0.0.Final wildfly-client-all jar
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months