[JBoss JIRA] (DROOLS-3181) java.lang.IllegalArgumentException: object is not an instance of declaring class" error in the server.log file when BPMS 6.4.11 is installed on EAP 6.4.21
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-3181?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-3181:
-------------------------------------
A better version of this fix (not using eap internal API) has been provided with this commit https://github.com/kiegroup/drools/commit/47a69813fdb58bd178f5924848a1781...
> java.lang.IllegalArgumentException: object is not an instance of declaring class" error in the server.log file when BPMS 6.4.11 is installed on EAP 6.4.21
> ----------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-3181
> URL: https://issues.jboss.org/browse/DROOLS-3181
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.13.0.Final
> Environment: Red Hat BPM Suite (BPMS) 6.4.11
> Red Hat Enterprise Application Platform (EAP) 6.4.21
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Priority: Major
> Labels: support
> Fix For: 7.14.0.Final
>
>
> The following error is logged in the server.log file when BPMS is installed on EAP 6.4.21:
> {noformat}
> ERROR [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (MSC service thread 1-7) Error when reading virtual file from vfs:/home/user/6411/jboss-eap-6.4/standalone/deployments/business-central.war/WEB-INF/lib/drools-pmml-6.5.0.Final-redhat-25.jar/META-INF/kmodule.xml: java.lang.IllegalArgumentException: object is not an instance of declaring class
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_181]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_181]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_181]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_181]
> at org.drools.compiler.kie.builder.impl.ClasspathKieProject.getPathForVFS(ClasspathKieProject.java:426) [drools-compiler-6.5.0.Final-redhat-25.jar:6.5.0.Final-redhat-25]
> at org.drools.compiler.kie.builder.impl.ClasspathKieProject.fixURLFromKProjectPath(ClasspathKieProject.java:371) [drools-compiler-6.5.0.Final-redhat-25.jar:6.5.0.Final-redhat-25]
> at org.drools.compiler.kie.builder.impl.ClasspathKieProject.fetchKModule(ClasspathKieProject.java:141) [drools-compiler-6.5.0.Final-redhat-25.jar:6.5.0.Final-redhat-25]
> at org.drools.compiler.kie.builder.impl.ClasspathKieProject.discoverKieModules(ClasspathKieProject.java:112) [drools-compiler-6.5.0.Final-redhat-25.jar:6.5.0.Final-redhat-25]
> at org.drools.compiler.kie.builder.impl.ClasspathKieProject.init(ClasspathKieProject.java:84) [drools-compiler-6.5.0.Final-redhat-25.jar:6.5.0.Final-redhat-25]
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.<init>(KieContainerImpl.java:141) [drools-compiler-6.5.0.Final-redhat-25.jar:6.5.0.Final-redhat-25]
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieClasspathContainer(KieServicesImpl.java:131) [drools-compiler-6.5.0.Final-redhat-25.jar:6.5.0.Final-redhat-25]
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieClasspathContainer(KieServicesImpl.java:118) [drools-compiler-6.5.0.Final-redhat-25.jar:6.5.0.Final-redhat-25]
> at org.drools.compiler.cdi.KieCDIExtension.init(KieCDIExtension.java:90) [drools-compiler-6.5.0.Final-redhat-25.jar:6.5.0.Final-redhat-25]
> {noformat}
> Does not occur on EAP 6.4.20
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (WFLY-11833) Stateful Session Bean affinity URI instead of cluster
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-11833?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz edited comment on WFLY-11833 at 4/30/19 9:34 AM:
---------------------------------------------------------------------
I've been looking at this and it may be tricky to fix. A client makes a remote invocation on a SLSB. That SLSB contains an injected reference to a SFSB home interface. The SLSB method uses the home interface to create an instance of the SFSB and return the proxy as a result of the invocation by the client.
The proxy returned by calling create() on the home interface has (strong affinity, weak affinity) = (LOCAL, LOCAL). By the time the proxy gets back to the client, as a return value, it has (strong affinity, weak affinity) = (URI, URI).
Affinity.LOCAL is defined as "the (affinity) specification for the local EJB environment". URIAffinity is defined as "the affinity specification corresponding to the given URI".
So, if a proxy has its affinity set to LOCAL, then it should not be able to invoke on any bean instances outside of its local EJB environment; which I would understand to the the EJB container it is invoked from (if any). That kind of makes sense, if we create a proxy within a deployment on a server which also has a SFSB deployed; in that case, the proxy is limited to making invocations on that local SFSB. Should this also apply if the bean is clustered? Perhaps. Why? We support fail-over behavior of proxies created from remote clients and created from deployments involving server-to-server clients. Need to clarify.
Certainly, if the proxy created is returned to the client, the affinity needs to be modified; if it were not, the proxy could not be used on the client to invoke on anything as the client does not have a local EJB environment. But how? Should it keep its affinity to that particular bean on that particular server, respecting *the context* in which it was created? Or should it respect the configuration of the bean (say clustered) that it references?
Investigating. Maybe the spec has something to say.
was (Author: rachmato):
I've been looking at this and it may be tricky to fix. A client makes a remote invocation on a SLSB. That SLSB contains an injected reference to a SFSB home interface. The SLSB method uses the home interface to create an instance of the SFSB and return the proxy as a result of the invocation by the client.
The proxy returned by calling create() on the home interface has (strong affinity, weak affinity) = (LOCAL, LOCAL). By the time the proxy gets back to the client, as a return value, it has (strong affinity, weak affinity) = (URI, URI).
Affinity.LOCAL is defined as "the (affinity) specification for the local EJB environment". URIAffinity is defined as "the affinity specification corresponding to the given URI".
So, if a proxy has its affinity set to LOCAL, then it should not be able to invoke on any beans outside of its local EJB environment; which I would understand to the the EJB container it is invoked from (if any). That kind of makes sense, if we create a proxy within a deployment on a server which also has a SFSB deployed; in that case, the proxy is limited to making invocations on that local SFSB. Should this also apply if the bean is clustered? Perhaps. Why? We support fail-over behavior of proxies created from remote clients and created from deployments involving server-to-server clients. Need to clarify.
Certainly, if the proxy created is returned to the client, the affinity needs to be modified; if it were not, the proxy could not be used on the client to invoke on anything as the client does not have a local EJB environment. But how? Should it keep its affinity to that particular bean on that particular server, respecting *the context* in which it was created? Or should it respect the configuration of the bean (say clustered) that it references?
Investigating. Maybe the spec has something to say.
> Stateful Session Bean affinity URI instead of cluster
> -----------------------------------------------------
>
> Key: WFLY-11833
> URL: https://issues.jboss.org/browse/WFLY-11833
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 16.0.0.Final
> Environment: WildFly cluster having SFSB deployed.
> Reporter: Joerg Baesner
> Assignee: Richard Achmatowicz
> Priority: Major
> Labels: downstream_dependency
> Attachments: stateful-timeout.zip
>
>
> Deployed is an application with the following setup:
> * Containing a SFSB (_with passivationCapable="true"_)
> * A SLSB exposing a _remote_ method to a standalone client returning an instance of the SFSB
> Scenario:
> A standalone client is invoking the _remote_ method on the Stateless Session Bean and a new instance of the Stateful Session Bean is returned.
> The issue is that the affinity of the returned Stateful Session Bean is URI instead of Cluster.
> See the attached Gradle reproducer application
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (WFLY-11833) Stateful Session Bean affinity URI instead of cluster
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-11833?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz edited comment on WFLY-11833 at 4/30/19 9:33 AM:
---------------------------------------------------------------------
I've been looking at this and it may be tricky to fix. A client makes a remote invocation on a SLSB. That SLSB contains an injected reference to a SFSB home interface. The SLSB method uses the home interface to create an instance of the SFSB and return the proxy as a result of the invocation by the client.
The proxy returned by calling create() on the home interface has (strong affinity, weak affinity) = (LOCAL, LOCAL). By the time the proxy gets back to the client, as a return value, it has (strong affinity, weak affinity) = (URI, URI).
Affinity.LOCAL is defined as "the (affinity) specification for the local EJB environment". URIAffinity is defined as "the affinity specification corresponding to the given URI".
So, if a proxy has its affinity set to LOCAL, then it should not be able to invoke on any beans outside of its local EJB environment; which I would understand to the the EJB container it is invoked from (if any). That kind of makes sense, if we create a proxy within a deployment on a server which also has a SFSB deployed; in that case, the proxy is limited to making invocations on that local SFSB. Should this also apply if the bean is clustered? Perhaps. Why? We support fail-over behavior of proxies created from remote clients and created from deployments involving server-to-server clients. Need to clarify.
Certainly, if the proxy created is returned to the client, the affinity needs to be modified; if it were not, the proxy could not be used on the client to invoke on anything as the client does not have a local EJB environment. But how? Should it keep its affinity to that particular bean on that particular server, respecting *the context* in which it was created? Or should it respect the configuration of the bean (say clustered) that it references?
Investigating. Maybe the spec has something to say.
was (Author: rachmato):
I've been looking at this and it may be tricky to fix. A client makes a remote invocation on a SLSB. That SLSB contains an injected reference to a SFSB home interface. The SLSB method uses the home interface to create an instance of the SFSB and return the proxy as a result of the invocation by the client.
The proxy returned by calling create() on the home interface has (strong affinity, weak affinity) = (LOCAL, LOCAL). By the time the proxy gets back to the client, as a return value, it has (string affinity, weak affinity) = (URI, URI).
Affinity.LOCAL is defined as "the (affinity) specification for the local EJB environment". URIAffinity is defined as "the affinity specification corresponding to the given URI".
So, if a proxy has its affinity set to LOCAL, then it should not be able to invoke on any beans outside of its local EJB environment; which I would understand to the the EJB container it is invoked from (if any). That kind of makes sense, if we create a proxy within a deployment on a server which also has a SFSB deployed; in that case, the proxy is limited to making invocations on that local SFSB. Should this also apply if the bean is clustered? Perhaps. Why? We support fail-over behavior of proxies created from remote clients and created from deployments involving server-to-server clients. Need to clarify.
Certainly, if the proxy created is returned to the client, the affinity needs to be modified; if it were not, the proxy could not be used on the client to invoke on anything as the client does not have a local EJB environment. But how? Should it keep its affinity to that particular bean on that particular server, respecting *the context* in which it was created? Or should it respect the configuration of the bean (say clustered) that it references?
Investigating. Maybe the spec has something to say.
> Stateful Session Bean affinity URI instead of cluster
> -----------------------------------------------------
>
> Key: WFLY-11833
> URL: https://issues.jboss.org/browse/WFLY-11833
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 16.0.0.Final
> Environment: WildFly cluster having SFSB deployed.
> Reporter: Joerg Baesner
> Assignee: Richard Achmatowicz
> Priority: Major
> Labels: downstream_dependency
> Attachments: stateful-timeout.zip
>
>
> Deployed is an application with the following setup:
> * Containing a SFSB (_with passivationCapable="true"_)
> * A SLSB exposing a _remote_ method to a standalone client returning an instance of the SFSB
> Scenario:
> A standalone client is invoking the _remote_ method on the Stateless Session Bean and a new instance of the Stateful Session Bean is returned.
> The issue is that the affinity of the returned Stateful Session Bean is URI instead of Cluster.
> See the attached Gradle reproducer application
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (WFLY-11833) Stateful Session Bean affinity URI instead of cluster
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-11833?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz commented on WFLY-11833:
--------------------------------------------
I've been looking at this and it may be tricky to fix. A client makes a remote invocation on a SLSB. That SLSB contains an injected reference to a SFSB home interface. The SLSB method uses the home interface to create an instance of the SFSB and return the proxy as a result of the invocation by the client.
The proxy returned by calling create() on the home interface has (strong affinity, weak affinity) = (LOCAL, LOCAL). By the time the proxy gets back to the client, as a return value, it has (string affinity, weak affinity) = (URI, URI).
Affinity.LOCAL is defined as "the (affinity) specification for the local EJB environment". URIAffinity is defined as "the affinity specification corresponding to the given URI".
So, if a proxy has its affinity set to LOCAL, then it should not be able to invoke on any beans outside of its local EJB environment; which I would understand to the the EJB container it is invoked from (if any). That kind of makes sense, if we create a proxy within a deployment on a server which also has a SFSB deployed; in that case, the proxy is limited to making invocations on that local SFSB. Should this also apply if the bean is clustered? Perhaps. Why? We support fail-over behavior of proxies created from remote clients and created from deployments involving server-to-server clients. Need to clarify.
Certainly, if the proxy created is returned to the client, the affinity needs to be modified; if it were not, the proxy could not be used on the client to invoke on anything as the client does not have a local EJB environment. But how? Should it keep its affinity to that particular bean on that particular server, respecting *the context* in which it was created? Or should it respect the configuration of the bean (say clustered) that it references?
Investigating. Maybe the spec has something to say.
> Stateful Session Bean affinity URI instead of cluster
> -----------------------------------------------------
>
> Key: WFLY-11833
> URL: https://issues.jboss.org/browse/WFLY-11833
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 16.0.0.Final
> Environment: WildFly cluster having SFSB deployed.
> Reporter: Joerg Baesner
> Assignee: Richard Achmatowicz
> Priority: Major
> Labels: downstream_dependency
> Attachments: stateful-timeout.zip
>
>
> Deployed is an application with the following setup:
> * Containing a SFSB (_with passivationCapable="true"_)
> * A SLSB exposing a _remote_ method to a standalone client returning an instance of the SFSB
> Scenario:
> A standalone client is invoking the _remote_ method on the Stateless Session Bean and a new instance of the Stateful Session Bean is returned.
> The issue is that the affinity of the returned Stateful Session Bean is URI instead of Cluster.
> See the attached Gradle reproducer application
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (DROOLS-3953) DMN UX - error highlight in boxed expression.
by Elizabeth Clayton (Jira)
Elizabeth Clayton created DROOLS-3953:
-----------------------------------------
Summary: DMN UX - error highlight in boxed expression.
Key: DROOLS-3953
URL: https://issues.jboss.org/browse/DROOLS-3953
Project: Drools
Issue Type: Task
Components: Scenario Simulation and Testing
Reporter: Elizabeth Clayton
Assignee: Tao Zhu
Attachments: Error reporting after test run-different kinds.png, Error reporting after test run-different kinds2.png, Error reporting after test run-popup.png, Error reporting after test run-popup.png, Error reporting after test run.png
As user after a test run, I want see not only the cell that are not correct (red background) but also the reason.
For instance have the possibility to see the actual value that is different from the expected or the error message.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (DROOLS-3953) DMN UX - error highlight in boxed expression.
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3953?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton reassigned DROOLS-3953:
-----------------------------------------
Assignee: Elizabeth Clayton (was: Tao Zhu)
> DMN UX - error highlight in boxed expression.
> ---------------------------------------------
>
> Key: DROOLS-3953
> URL: https://issues.jboss.org/browse/DROOLS-3953
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Elizabeth Clayton
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: UX, UXTeam, drools-tools
> Attachments: Error reporting after test run-different kinds.png, Error reporting after test run-different kinds2.png, Error reporting after test run-popup.png, Error reporting after test run-popup.png, Error reporting after test run.png
>
>
> As user after a test run, I want see not only the cell that are not correct (red background) but also the reason.
> For instance have the possibility to see the actual value that is different from the expected or the error message.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (DROOLS-3953) DMN UX - error highlight in boxed expression.
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3953?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton updated DROOLS-3953:
--------------------------------------
Labels: UX UXTeam drools-tools (was: ScenarioSimulation UXTeam)
> DMN UX - error highlight in boxed expression.
> ---------------------------------------------
>
> Key: DROOLS-3953
> URL: https://issues.jboss.org/browse/DROOLS-3953
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Elizabeth Clayton
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: UX, UXTeam, drools-tools
> Attachments: Error reporting after test run-different kinds.png, Error reporting after test run-different kinds2.png, Error reporting after test run-popup.png, Error reporting after test run-popup.png, Error reporting after test run.png
>
>
> As user after a test run, I want see not only the cell that are not correct (red background) but also the reason.
> For instance have the possibility to see the actual value that is different from the expected or the error message.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (DROOLS-3953) DMN UX - error highlight in boxed expression.
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3953?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton updated DROOLS-3953:
--------------------------------------
Component/s: DMN Editor
(was: Scenario Simulation and Testing)
> DMN UX - error highlight in boxed expression.
> ---------------------------------------------
>
> Key: DROOLS-3953
> URL: https://issues.jboss.org/browse/DROOLS-3953
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Elizabeth Clayton
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: UX, UXTeam, drools-tools
> Attachments: Error reporting after test run-different kinds.png, Error reporting after test run-different kinds2.png, Error reporting after test run-popup.png, Error reporting after test run-popup.png, Error reporting after test run.png
>
>
> As user after a test run, I want see not only the cell that are not correct (red background) but also the reason.
> For instance have the possibility to see the actual value that is different from the expected or the error message.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (WFLY-10813) OutOfMemory error when trying to display resource adapters in web console
by Helena Knyttlová (Jira)
[ https://issues.jboss.org/browse/WFLY-10813?page=com.atlassian.jira.plugin... ]
Helena Knyttlová commented on WFLY-10813:
-----------------------------------------
Our resource adapter configuration looks like this:
{panel:title=My title}
<subsystem xmlns="urn:jboss:domain:resource-adapters:5.0">
<resource-adapters>
<resource-adapter id="App">
<archive>
App-ear-1.11.ear#App-rar-1.11.rar
</archive>
<connection-definitions>
<connection-definition class-name="some.package.ManagedConnectionFactory" jndi-name="java:/eis/app" enabled="true" pool-name="app">
<pool>
<max-pool-size>100</max-pool-size>
</pool>
<timeout>
<idle-timeout-minutes>5</idle-timeout-minutes>
</timeout>
<validation>
<background-validation>false</background-validation>
</validation>
</connection-definition>
</connection-definitions>
</resource-adapter>
....
{panel}
If you cannot reproduce it, you can probably close this. It can be some problem only on our server.
> OutOfMemory error when trying to display resource adapters in web console
> -------------------------------------------------------------------------
>
> Key: WFLY-10813
> URL: https://issues.jboss.org/browse/WFLY-10813
> Project: WildFly
> Issue Type: Bug
> Components: Management, Web Console
> Affects Versions: 10.0.0.Final, 13.0.0.Final
> Reporter: Helena Knyttlová
> Assignee: Harald Pehl
> Priority: Minor
> Attachments: standalone-full-ha.xml
>
>
> We have about 25 resource adapters set through CLI. When I want to display them in web administration console it kills the whole wildfly server - server is not responding and after several minutes it ends up with OutOfMemory error and server must be restarted. We've seen this issue since wildfly 10 (it was the first version we used). With only a few resource adapters it is not happening.
> Memory settings: JAVA_OPTS="-Xms512m -Xmx1024m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
> The error which appeared on WidlFly 13.0.0.Final:
> {panel:title=Log}
> ERROR [org.jboss.as.controller.management-operation] (External Management Request Threads -- 1) WFLYCTL0013: Operation ("read-resource-description") failed - address: ([
> ("subsystem" => "resource-adapters"),
> ("resource-adapter" => "AppAdapter"),
> ("connection-definitions" => "cp-host")
> ]): java.lang.OutOfMemoryError: Java heap space
> at java.util.HashMap.resize(HashMap.java:704)
> at java.util.HashMap.putVal(HashMap.java:629)
> at java.util.HashMap.put(HashMap.java:612)
> at org.jboss.dmr.ObjectModelValue.copy(ObjectModelValue.java:180)
> at org.jboss.dmr.ObjectModelValue.copy(ObjectModelValue.java:169)
> at org.jboss.dmr.ModelNode.clone(ModelNode.java:1867)
> at org.jboss.dmr.ObjectModelValue.copy(ObjectModelValue.java:180)
> at org.jboss.dmr.ObjectModelValue.copy(ObjectModelValue.java:169)
> at org.jboss.dmr.ModelNode.clone(ModelNode.java:1867)
> at org.jboss.dmr.ObjectModelValue.copy(ObjectModelValue.java:180)
> at org.jboss.dmr.ObjectModelValue.copy(ObjectModelValue.java:169)
> at org.jboss.dmr.ModelNode.clone(ModelNode.java:1867)
> at org.jboss.dmr.ObjectModelValue.copy(ObjectModelValue.java:180)
> at org.jboss.dmr.ObjectModelValue.copy(ObjectModelValue.java:169)
> at org.jboss.dmr.ModelNode.set(ModelNode.java:693)
> at org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler$ReadResourceDescriptionAssemblyHandler.execute(ReadResourceDescriptionHandler.java:618)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1404)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:423)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
> at org.jboss.as.controller.ModelControllerImpl$$Lambda$490/414756260.run(Unknown Source)
> at org.wildfly.security.auth.server.SecurityIdentity$$Lambda$491/367363594.run(Unknown Source)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
> at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:93)
> at org.jboss.as.domain.http.server.security.ElytronIdentityHandler.lambda$handleRequest$0(ElytronIdentityHandler.java:62)
> at org.jboss.as.domain.http.server.security.ElytronIdentityHandler$$Lambda$790/1228674018.run(Unknown Source)
> {panel}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months