[JBoss JIRA] (DROOLS-5341) ExecutionResultImpl not properly serialized in JSon Response
by Steve Davidson (Jira)
[ https://issues.redhat.com/browse/DROOLS-5341?page=com.atlassian.jira.plug... ]
Steve Davidson updated DROOLS-5341:
-----------------------------------
Description:
When a Drools Batch command has been processed, the conversion of the Kie ServiceResponse to JSON incorrectly serializes the ExecutionResponseImple. The resulting message looks like:
{code:json}
{
"org.kie.server.api.model.ServiceResponse" : {
"type" : "SUCCESS",
"msg" : "Container Kie Demo: kie-server successfully called.",
"result" : {
"ExecutionResultImpl" : {
"results" : [ ],
"facts" : [ ]
}
}
}
}
{code}
This results in deserialization failure of the client side as the type of the result can not be determined. The correct response should be:
{code:json}
{
"org.kie.server.api.model.ServiceResponse" : {
"type" : "SUCCESS",
"msg" : "Container Kie Demo: kie-server successfully called.",
"result" : {
"execution-results" : {
"results" : [ ],
"facts" : [ ]
}
}
}
}
{code}
was:
When a Drools Batch command has been processed, the conversion of the Kie ServiceResponse to JSON incorrectly serializes the ExecutionResponseImple. The resulting message looks like:
{code:json}
{
"org.kie.server.api.model.ServiceResponse" : {
"type" : "SUCCESS",
"msg" : "Container Kie Demo: kie-server successfully called.",
"result" : {
"ExecutionResultImpl" : {
"results" : [ ],
"facts" : [ ]
}
}
}
}
{code}
This results in deserialization failure of the client side as the type of the result can not be determined. The correct response should be:
{code:json}
{
"org.kie.server.api.model.ServiceResponse" : {
"type" : "SUCCESS",
"msg" : "Container Kie Demo: kie-server successfully called.",
"result" : {
"execution-results" : {
"results" : [ ],
"facts" : [ ]
}
}
}
}
{code:json}
> ExecutionResultImpl not properly serialized in JSon Response
> ------------------------------------------------------------
>
> Key: DROOLS-5341
> URL: https://issues.redhat.com/browse/DROOLS-5341
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.29.0.Final
> Reporter: Steve Davidson
> Assignee: Mario Fusco
> Priority: Major
> Labels: drools, kie, kie-server
> Attachments: KieIssueDemo.tbz
>
>
> When a Drools Batch command has been processed, the conversion of the Kie ServiceResponse to JSON incorrectly serializes the ExecutionResponseImple. The resulting message looks like:
> {code:json}
> {
> "org.kie.server.api.model.ServiceResponse" : {
> "type" : "SUCCESS",
> "msg" : "Container Kie Demo: kie-server successfully called.",
> "result" : {
> "ExecutionResultImpl" : {
> "results" : [ ],
> "facts" : [ ]
> }
> }
> }
> }
> {code}
> This results in deserialization failure of the client side as the type of the result can not be determined. The correct response should be:
> {code:json}
> {
> "org.kie.server.api.model.ServiceResponse" : {
> "type" : "SUCCESS",
> "msg" : "Container Kie Demo: kie-server successfully called.",
> "result" : {
> "execution-results" : {
> "results" : [ ],
> "facts" : [ ]
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5341) ExecutionResultImpl not properly serialized in JSon Response
by Steve Davidson (Jira)
Steve Davidson created DROOLS-5341:
--------------------------------------
Summary: ExecutionResultImpl not properly serialized in JSon Response
Key: DROOLS-5341
URL: https://issues.redhat.com/browse/DROOLS-5341
Project: Drools
Issue Type: Bug
Affects Versions: 7.29.0.Final
Reporter: Steve Davidson
Assignee: Mario Fusco
Attachments: KieIssueDemo.tbz
When a Drools Batch command has been processed, the conversion of the Kie ServiceResponse to JSON incorrectly serializes the ExecutionResponseImple. The resulting message looks like:
{code:json}
{
"org.kie.server.api.model.ServiceResponse" : {
"type" : "SUCCESS",
"msg" : "Container Kie Demo: kie-server successfully called.",
"result" : {
"ExecutionResultImpl" : {
"results" : [ ],
"facts" : [ ]
}
}
}
}
{code}
This results in deserialization failure of the client side as the type of the result can not be determined. The correct response should be:
{code:json}
{
"org.kie.server.api.model.ServiceResponse" : {
"type" : "SUCCESS",
"msg" : "Container Kie Demo: kie-server successfully called.",
"result" : {
"execution-results" : {
"results" : [ ],
"facts" : [ ]
}
}
}
}
{code:json}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5106) Local/Internal Maven Repos can not be accessed
by Steve Davidson (Jira)
[ https://issues.redhat.com/browse/DROOLS-5106?page=com.atlassian.jira.plug... ]
Steve Davidson edited comment on DROOLS-5106 at 5/15/20 3:00 PM:
-----------------------------------------------------------------
Do you have an artifact for this in your local repo? I'm also using a proxied repo with artifact, and running into the same issue. Note that the artifact in question is NOT in the main repos -- and probably won't be. It will only be in local repos.
Should have added, Kie is what's not downloading the updates. Item is in local repo, but Kie is apparently ignoring the configured local repos with current version and going for the main repo's which don't have the object.
Note that for version 7.29.0.Final, Kie does go to the local repo. It's only for 7.33 that it only goes to the central repo and ignores local/configured repo. Another way of putting this - when running 7.29.0.Final, artifacts in local repo are found and loaded, but just by switching the version of Kie to 7.33.0 w/o any other changes, local artifacts can no longer be loaded.
was (Author: northgorky):
Do you have an artifact for this in your local repo? I'm also using a proxied repo with artifact, and running into the same issue. Note that the artifact in question is NOT in the main repos -- and probably won't be. It will only be in local repos.
Should have added, Kie is what's not downloading the updates. Item is in local repo, but Kie is apparently ignoring the configured local repos with current version and going for the main repo's which don't have the object.
> Local/Internal Maven Repos can not be accessed
> ----------------------------------------------
>
> Key: DROOLS-5106
> URL: https://issues.redhat.com/browse/DROOLS-5106
> Project: Drools
> Issue Type: Bug
> Components: Artifact Repository
> Affects Versions: 7.33.0.Final
> Reporter: Steve Davidson
> Assignee: Luca Molteni
> Priority: Major
> Labels: Drools, drools-compiler, maven
> Attachments: settings.xml
>
>
> Attempting to use an internal Nexus Repository, unable to load Drools KIE Modules using Maven. This works with 7.29.Final. Changing to 7.33.Final fails with the following stack trace;
> {code:java}
> WARNING: Environment variable M2_HOME is not set
> Feb 24, 2020 5:12:30 PM org.kie.server.services.impl.KieServerImpl createContainer
> SEVERE: Error creating container 'JUnit Test: kie-server' for module 'com.j2eeguys.demo:KieIssueDemo:0.1.0-SNAPSHOT'
> java.lang.RuntimeException: Cannot find KieModule: com.j2eeguys.demo:KieIssueDemo:0.1.0-SNAPSHOT
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:186)
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:176)
> at org.kie.server.services.impl.KieServerImpl.createContainer(KieServerImpl.java:281)
> at org.kie.server.remote.rest.common.resource.KieServerRestImpl.createContainer(KieServerRestImpl.java:157)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140)
> 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:358)
> 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:443)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:233)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:139)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
> at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:142)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:219)
> 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:790)
> at org.eclipse.jetty.servlet.ServletHolder$NotAsyncServlet.service(ServletHolder.java:1401)
> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:760)
> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1617)
> at org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:226)
> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1604)
> at org.kie.server.services.impl.security.web.CaptureHttpRequestFilter.doFilter(CaptureHttpRequestFilter.java:42)
> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:501)
> at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1592)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1296)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1562)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1211)
> at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:386)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:562)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:378)
> at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:270)
> at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
> at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:388)
> at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
> at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13480) MP FT QS: Corrections in English language README.md write-up
by Radoslav Husar (Jira)
Radoslav Husar created WFLY-13480:
-------------------------------------
Summary: MP FT QS: Corrections in English language README.md write-up
Key: WFLY-13480
URL: https://issues.redhat.com/browse/WFLY-13480
Project: WildFly
Issue Type: Bug
Components: MP Fault Tolerance, Quickstarts
Affects Versions: 19.1.0.Final
Reporter: Radoslav Husar
Assignee: Radoslav Husar
Fix For: 20.0.0.Beta1
There are a couple of items that needs improving grammar, formatting and stylization.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13476) MP FT QS: Missing supported shared-docs sections
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13476?page=com.atlassian.jira.plugi... ]
Radoslav Husar updated WFLY-13476:
----------------------------------
Fix Version/s: 20.0.0.Beta1
> MP FT QS: 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
>
>
> 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-13459) Remote Naming bind / rebind / unbind / rename / createSubcontext / destroySubcontext does not throw exception back to client
by Brad Maxwell (Jira)
[ https://issues.redhat.com/browse/WFLY-13459?page=com.atlassian.jira.plugi... ]
Brad Maxwell updated WFLY-13459:
--------------------------------
Steps to Reproduce:
Add a user: ./bin/add-user.sh -a -u admin -p redhat1!
Start JBoss ./bin/standalone.sh
javac Client.java
java -cp $JBOSS_HOME/bin/client/jboss-cli-client.jar:$JBOSS_HOME/bin/client/jboss-client.jar:. Client
or
./client.sh [path to jboss]
./client.sh [path to jboss] -Dhost=... -Dport=... -Duser=... -Dpass=... -Dtest=... -Dverbose=true
It will test remoting and http. -Dtest=http or -Dtest=remoting to just run a single test
java -cp $JBOSS_HOME/bin/client/jboss-cli-client.jar:$JBOSS_HOME/bin/client/jboss-client.jar:. -Dtest=http Client
-Dpass=null will set the user/pass to null so that it will not be set inside of the InitialContext.
-Dhost= , -Dport , -Duser, -Dpass can all be passed to use a different value from the default localhost , 8080, admin , redhat1!
Will log:
{code}
Starting test: Remote Naming / Remoting
==================
Failed to catch exception for method bind
Failed to catch exception for method rebind
Failed to catch exception for method unbind
Failed to catch exception for method rename
Failed to catch exception for method createSubcontext
Failed to catch exception for method destroySubcontext
Failed to catch exception for method destroySubcontext
Finished test: Remote Naming / Remoting
==================
Starting test: Remote Http Naming
==================
Success catch exception javax.naming.NamingException for method bind
Success catch exception javax.naming.NamingException for method rebind
Success catch exception javax.naming.CommunicationException for method unbind
Success catch exception javax.naming.CommunicationException for method rename
Success catch exception javax.naming.CommunicationException for method createSubcontext
Success catch exception javax.naming.CommunicationException for method destroySubcontext
Success catch exception javax.naming.CommunicationException for method destroySubcontext
Finished test: Remote Http Naming
==================
{code}
Expected result is success where the client is catching a NamingException (which ever is most specific to the method).
The implementation down in the org.wildfly.naming.client.WildFlyInitialContextFactory for these methods must just not be throwing the exception back, since the server side is logging a warning
was:
Add a user: ./bin/add-user.sh -a -u admin -p redhat1!
Start JBoss ./bin/standalone.sh
javac Client.java
java -cp $JBOSS_HOME/bin/client/jboss-cli-client.jar:$JBOSS_HOME/bin/client/jboss-client.jar:. Client
It will test remoting and http. -Dtest=http or -Dtest=remoting to just run a single test
java -cp $JBOSS_HOME/bin/client/jboss-cli-client.jar:$JBOSS_HOME/bin/client/jboss-client.jar:. -Dtest=http Client
-Dpass=null will set the user/pass to null so that it will not be set inside of the InitialContext.
-Dhost= , -Dport , -Duser, -Dpass can all be passed to use a different value from the default localhost , 8080, admin , redhat1!
Will log:
{code}
Starting test: Remote Naming / Remoting
==================
Failed to catch exception for method bind
Failed to catch exception for method rebind
Failed to catch exception for method unbind
Failed to catch exception for method rename
Failed to catch exception for method createSubcontext
Failed to catch exception for method destroySubcontext
Failed to catch exception for method destroySubcontext
Finished test: Remote Naming / Remoting
==================
Starting test: Remote Http Naming
==================
Success catch exception javax.naming.NamingException for method bind
Success catch exception javax.naming.NamingException for method rebind
Success catch exception javax.naming.CommunicationException for method unbind
Success catch exception javax.naming.CommunicationException for method rename
Success catch exception javax.naming.CommunicationException for method createSubcontext
Success catch exception javax.naming.CommunicationException for method destroySubcontext
Success catch exception javax.naming.CommunicationException for method destroySubcontext
Finished test: Remote Http Naming
==================
{code}
Expected result is success where the client is catching a NamingException (which ever is most specific to the method).
The implementation down in the org.wildfly.naming.client.WildFlyInitialContextFactory for these methods must just not be throwing the exception back, since the server side is logging a warning
> Remote Naming bind / rebind / unbind / rename / createSubcontext / destroySubcontext does not throw exception back to client
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13459
> URL: https://issues.redhat.com/browse/WFLY-13459
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Affects Versions: 19.1.0.Final
> Reporter: Brad Maxwell
> Assignee: Sudeshna Sur
> Priority: Minor
> Attachments: Client.java, client.sh, server.log.gz
>
>
> The Remote Naming (JNDI) is Read-Only, remote clients cannot bind or rebind objects into it. Only applications running in the same JVM can bind values into JNDI.
> It looks like the server side logs the warning, but the client does not get an exception thrown back, bind and rebind should throw some javax.naming.NamingException since the bind/rebind operations are failing.
> {code}
> public static void main(String[] args) throws Exception {
> Context ctx = getInitialContext("localhost", 8080, "admin", "redhat1!");
> ctx.bind("java:/reproducer", "reproducer");
> ctx.rebind("java:/reproducer", "reproducer");
> }
> public static Context getInitialContext(String host, Integer port, String username, String password) throws NamingException {
> Properties props = new Properties();
> props.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
> props.put(Context.PROVIDER_URL, String.format("%s://%s:%d", "remote+http", host, port));
> if(username != null && password != null) {
> props.put(Context.SECURITY_PRINCIPAL, username);
> props.put(Context.SECURITY_CREDENTIALS, password);
> }
> return new InitialContext(props);
> }
> {code}
> {code}
> 13:20:22,804 WARN [org.wildfly.naming] (default task-2) WFNAM00036: Unexpected internal error: java.lang.UnsupportedOperationException: WFLYNAM0043: Naming context is read-only
> at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:160)
> at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(WritableServiceBasedNamingStore.java:66)
> at org.jboss.as.naming.NamingContext.bind(NamingContext.java:262)
> at org.jboss.as.naming.NamingContext.bind(NamingContext.java:289)
> at org.wildfly.naming.client.remote.RemoteServerTransport.handleBind(RemoteServerTransport.java:238)
> at org.wildfly.naming.client.remote.RemoteServerTransport$1.handleMessage(RemoteServerTransport.java:126)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:991)
> 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)
> 13:20:22,813 WARN [org.wildfly.naming] (default task-2) WFNAM00036: Unexpected internal error: java.lang.UnsupportedOperationException: WFLYNAM0043: Naming context is read-only
> at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:160)
> at org.jboss.as.naming.WritableServiceBasedNamingStore.rebind(WritableServiceBasedNamingStore.java:108)
> at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:301)
> at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:309)
> at org.wildfly.naming.client.remote.RemoteServerTransport.handleBind(RemoteServerTransport.java:236)
> at org.wildfly.naming.client.remote.RemoteServerTransport$1.handleMessage(RemoteServerTransport.java:129)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:991)
> 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)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months