[JBoss JIRA] (WFCORE-1680) Tab completion for echo-dmr command is broken
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1680?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise edited comment on WFCORE-1680 at 8/1/16 9:16 AM:
----------------------------------------------------------------------
Looking at the src code, it seems that deployment-overlay, echo-dmr, batch-edit-line, if commands are passing a cursor value of 0.
OperationRequestCompleter and CommandCompleter are possibly impacted too.
was (Author: jdenise):
Looking at the src code, it seems that deployment-overlay, echo-dmr, batch-edit-line, if commands are passing a cursor value of 0.
OperationRequestCompleter is possibly impacted too.
> Tab completion for echo-dmr command is broken
> ---------------------------------------------
>
> Key: WFCORE-1680
> URL: https://issues.jboss.org/browse/WFCORE-1680
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Petr Kremensky
> Assignee: Jean-Francois Denise
>
> Tab completion for echo-dmr command doesn't work.
> To reproduce, start the standalone server and connect with CLI
> *actual 3.0.0.Alpha5-SNAPSHOT 77673c5*
> {noformat}
> [standalone@localhost:9990 /] echo-dmr /sub[TAB]
> core-service deployment deployment-overlay extension interface path socket-binding-group subsystem system-property
> [standalone@localhost:9990 /] echo-dmr /subsystem=log[TAB]
> core-service deployment deployment-overlay extension interface path socket-binding-group subsystem system-property
> {noformat}
> *expected*
> {noformat}
> [standalone@localhost:9990 /] echo-dmr /sub[TAB]
> [standalone@localhost:9990 /] echo-dmr /subsystem=
> [standalone@localhost:9990 /] echo-dmr /subsystem=log[TAB]
> [standalone@localhost:9990 /] echo-dmr /subsystem=logging
> {noformat}
> The issue is not reproducible with 2.2.0.CR7 (EAP 7.1.0.DR1).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (WFCORE-1680) Tab completion for echo-dmr command is broken
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1680?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1680:
----------------------------------------------
Looking at the src code, it seems that deployment-overlay, echo-dmr, batch-edit-line, if commands are passing a cursor value of 0.
OperationRequestCompleter is possibly impacted too.
> Tab completion for echo-dmr command is broken
> ---------------------------------------------
>
> Key: WFCORE-1680
> URL: https://issues.jboss.org/browse/WFCORE-1680
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Petr Kremensky
> Assignee: Jean-Francois Denise
>
> Tab completion for echo-dmr command doesn't work.
> To reproduce, start the standalone server and connect with CLI
> *actual 3.0.0.Alpha5-SNAPSHOT 77673c5*
> {noformat}
> [standalone@localhost:9990 /] echo-dmr /sub[TAB]
> core-service deployment deployment-overlay extension interface path socket-binding-group subsystem system-property
> [standalone@localhost:9990 /] echo-dmr /subsystem=log[TAB]
> core-service deployment deployment-overlay extension interface path socket-binding-group subsystem system-property
> {noformat}
> *expected*
> {noformat}
> [standalone@localhost:9990 /] echo-dmr /sub[TAB]
> [standalone@localhost:9990 /] echo-dmr /subsystem=
> [standalone@localhost:9990 /] echo-dmr /subsystem=log[TAB]
> [standalone@localhost:9990 /] echo-dmr /subsystem=logging
> {noformat}
> The issue is not reproducible with 2.2.0.CR7 (EAP 7.1.0.DR1).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (WFCORE-1682) Missleading tab completion for edit-batch-line command
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1682?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1682:
----------------------------------------------
WFCORE-1487 was logged and fixed in order to change the behaviour of completion to expose unnamed internal property name. So what you are observing seems the new expected behaviour.
I also think that it is misleading.
> Missleading tab completion for edit-batch-line command
> ------------------------------------------------------
>
> Key: WFCORE-1682
> URL: https://issues.jboss.org/browse/WFCORE-1682
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Petr Kremensky
> Assignee: Alexey Loubyansky
>
> Tab completion for edit-batch-list command suggest to use --line-number as a command option, but that is not how the command works.
> *command usage*
> {noformat}
> [standalone@localhost:9990 /] batch
> [standalone@localhost:9990 / #] :read-resource
> [standalone@localhost:9990 / #] list-batch
> #1 /:read-resource
> [standalone@localhost:9990 / #] edit-batch-line 1 :read-attribute(name=launch-type)
> #1 :read-attribute(name=launch-type)
> [standalone@localhost:9990 / #] list-batch
> #1 :read-attribute(name=launch-type)
> {noformat}
> *actual*
> {noformat}
> [standalone@localhost:9990 / #] edit-batch-line <TAB>
> [standalone@localhost:9990 / #] edit-batch-line --<TAB>
> --help --line-number
> [standalone@localhost:9990 / #] edit-batch-line --line-number=1 :read-attribute(name=launch-type)
> Failed to parse line number '--line-number=1': For input string: "--line-number=1"
> {noformat}
> {{--line-number}} shouldn't be offered by tab completion for the command.
> Misleading tab completion ends up with syntax error.
> *expected*
> {noformat}
> [standalone@localhost:9990 / #] edit-batch-line <TAB>
> --help
> {noformat}
> The issue is a regression against EAP 7.0.0 release.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (DROOLS-414) Queries do not work with chained accessors as arguments
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-414?page=com.atlassian.jira.plugin... ]
Mario Fusco updated DROOLS-414:
-------------------------------
Priority: Critical (was: Major)
> Queries do not work with chained accessors as arguments
> -------------------------------------------------------
>
> Key: DROOLS-414
> URL: https://issues.jboss.org/browse/DROOLS-414
> Project: Drools
> Issue Type: Feature Request
> Affects Versions: 5.5.0.Final, 6.0.1.Final
> Reporter: Davide Sottara
> Assignee: Mario Fusco
> Priority: Critical
>
> When processing a query CE that uses chained property accessors:
> when
> $x : Foo()
> myQuery( $x.bar ; )
> then
> the QueryElementBuilder considers the whole expression $x.bar as a variable. Since no variable with that name has been bound, it is taken to be a new declaration, and thus an output. This results in an inconsistent behavior, since an obvious constraint will be ignored.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (WFLY-2845) On WildFly clean shutdown: failed marshalling rsp (UnsuccessfulResponse)
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2845?page=com.atlassian.jira.plugin.... ]
Radoslav Husar closed WFLY-2845.
--------------------------------
Resolution: Out of Date
> On WildFly clean shutdown: failed marshalling rsp (UnsuccessfulResponse)
> ------------------------------------------------------------------------
>
> Key: WFLY-2845
> URL: https://issues.jboss.org/browse/WFLY-2845
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.0.0.CR1
> Environment: RHEL6 x86_64; Oracle JDK 7
> Reporter: Michal Karm Babacek
> Assignee: Paul Ferraro
> Labels: clustering
> Fix For: 10.1.0.Final
>
>
> I've got two standalone-ha instances running on a one box. Each of these instances has {{<distributable/>}} [clusterbench|https://github.com/Karm/clusterbench/tree/simplified-and-pure] app deployed. When I start to shut the instances down via CLI command, one of them throws:
> {noformat}
> 08:59:33,341 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-4,shared=udp) ISPN000094: Received new cluster view: [jboss-eap-8.0/web|4] (1) [jboss-eap-8.0/web]
> 08:59:33,368 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000082: Stopping the RpcDispatcher
> 08:59:33,379 ERROR [org.jgroups.blocks.RequestCorrelator] (remote-thread-0) failed marshalling rsp (UnsuccessfulResponse): java.lang.NullPointerException
> 08:59:33,380 ERROR [org.jgroups.blocks.RequestCorrelator] (remote-thread-1) failed marshalling rsp (UnsuccessfulResponse): java.lang.NullPointerException
> 08:59:33,392 INFO [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.0.0.Final-SNAPSHOT "WildFly" stopped in 558ms
> {noformat}
> In the log. It's a non-deterministic problem and it does not emerge always.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (WFCORE-1682) Missleading tab completion for edit-batch-line command
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1682?page=com.atlassian.jira.plugi... ]
Petr Kremensky commented on WFCORE-1682:
----------------------------------------
Tab completion for {{if}} command is affected as well
{noformat}
[domain@10.16.179.18:9990 /] if --<TAB>
--condition --help
{noformat}
however {{--condition}} is a not valid argument for the command
{noformat}
ARGUMENTS
--help - prints this description.
command_line - CLI command or an operation whose response
should be evaluated to determine which
block of the if-else should be executed next;
condition_expression - an expression that evaluates the response
and based on which the next block of the
if-else control flow to be executed is chosen.
{noformat}
> Missleading tab completion for edit-batch-line command
> ------------------------------------------------------
>
> Key: WFCORE-1682
> URL: https://issues.jboss.org/browse/WFCORE-1682
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Petr Kremensky
> Assignee: Alexey Loubyansky
>
> Tab completion for edit-batch-list command suggest to use --line-number as a command option, but that is not how the command works.
> *command usage*
> {noformat}
> [standalone@localhost:9990 /] batch
> [standalone@localhost:9990 / #] :read-resource
> [standalone@localhost:9990 / #] list-batch
> #1 /:read-resource
> [standalone@localhost:9990 / #] edit-batch-line 1 :read-attribute(name=launch-type)
> #1 :read-attribute(name=launch-type)
> [standalone@localhost:9990 / #] list-batch
> #1 :read-attribute(name=launch-type)
> {noformat}
> *actual*
> {noformat}
> [standalone@localhost:9990 / #] edit-batch-line <TAB>
> [standalone@localhost:9990 / #] edit-batch-line --<TAB>
> --help --line-number
> [standalone@localhost:9990 / #] edit-batch-line --line-number=1 :read-attribute(name=launch-type)
> Failed to parse line number '--line-number=1': For input string: "--line-number=1"
> {noformat}
> {{--line-number}} shouldn't be offered by tab completion for the command.
> Misleading tab completion ends up with syntax error.
> *expected*
> {noformat}
> [standalone@localhost:9990 / #] edit-batch-line <TAB>
> --help
> {noformat}
> The issue is a regression against EAP 7.0.0 release.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (WFLY-6731) Problem with cluster, org.wildfly.clustering.web.undertow.session.DistributableSession
by Bruno Silva (JIRA)
[ https://issues.jboss.org/browse/WFLY-6731?page=com.atlassian.jira.plugin.... ]
Bruno Silva commented on WFLY-6731:
-----------------------------------
<subsystem xmlns="urn:jboss:domain:infinispan:4.0">
<cache-container name="server" aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server">
<transport lock-timeout="60000"/>
<replicated-cache name="default" mode="SYNC">
<transaction mode="BATCH"/>
</replicated-cache>
</cache-container>
<cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
<transport lock-timeout="60000"/>
<distributed-cache name="dist" mode="ASYNC" l1-lifespan="0" owners="2">
<locking isolation="REPEATABLE_READ"/>
<transaction mode="BATCH"/>
<file-store/>
</distributed-cache>
<distributed-cache name="concurrent" mode="SYNC" l1-lifespan="0" owners="2">
<file-store/>
</distributed-cache>
</cache-container>
<cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
<transport lock-timeout="60000"/>
<distributed-cache name="dist" mode="ASYNC" l1-lifespan="0" owners="2">
<locking isolation="REPEATABLE_READ"/>
<transaction mode="BATCH"/>
<file-store/>
</distributed-cache>
</cache-container>
<cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan">
<transport lock-timeout="60000"/>
<local-cache name="local-query">
<eviction strategy="LRU" max-entries="10000"/>
<expiration max-idle="100000"/>
</local-cache>
<invalidation-cache name="entity" mode="SYNC">
<transaction mode="NON_XA"/>
<eviction strategy="LRU" max-entries="10000"/>
<expiration max-idle="100000"/>
</invalidation-cache>
<replicated-cache name="timestamps" mode="ASYNC"/>
</cache-container>
</subsystem>
> Problem with cluster, org.wildfly.clustering.web.undertow.session.DistributableSession
> --------------------------------------------------------------------------------------
>
> Key: WFLY-6731
> URL: https://issues.jboss.org/browse/WFLY-6731
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Bruno Silva
> Assignee: Paul Ferraro
>
> {noformat}
> ay0uwkDSnTKoZNLMN9atwQhHB4KiZ url:/autenticacaosso/login.jsf;jsessionid=vrQfTnf0X0ZbbWAOEHUd-BXtb8Oa1TsfMjfqhh1C.node3
> 2016-04-08 08:41:14,766 ERROR [io.undertow.request] (default task-137) UT005023: Exception handling request to /autenticacaosso/login: java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429)
> at java.util.HashMap$KeyIterator.next(HashMap.java:1453)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.changeSessionId(DistributableSession.java:197)
> at io.undertow.servlet.spec.HttpServletRequestImpl.changeSessionId(HttpServletRequestImpl.java:329)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler$SecurityNotificationReceiver.handleNotification(CachedAuthenticatedSessionHandler.java:95)
> at io.undertow.security.impl.AbstractSecurityContext.sendNoticiation(AbstractSecurityContext.java:127)
> at io.undertow.security.impl.AbstractSecurityContext.authenticationComplete(AbstractSecurityContext.java:85)
> at io.undertow.security.impl.AbstractSecurityContext.authenticationComplete(AbstractSecurityContext.java:78)
> at io.undertow.security.impl.SingleSignOnAuthenticationMechanism.authenticate(SingleSignOnAuthenticationMechanism.java:103)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:257)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$2(SecurityContextImpl.java:231)
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:123)
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:98)
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:91)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
> 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 io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (WFLY-6731) Problem with cluster, org.wildfly.clustering.web.undertow.session.DistributableSession
by Bruno Silva (JIRA)
[ https://issues.jboss.org/browse/WFLY-6731?page=com.atlassian.jira.plugin.... ]
Bruno Silva edited comment on WFLY-6731 at 8/1/16 7:53 AM:
-----------------------------------------------------------
{noformat}
<subsystem xmlns="urn:jboss:domain:infinispan:4.0">
<cache-container name="server" aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server">
<transport lock-timeout="60000"/>
<replicated-cache name="default" mode="SYNC">
<transaction mode="BATCH"/>
</replicated-cache>
</cache-container>
<cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
<transport lock-timeout="60000"/>
<distributed-cache name="dist" mode="ASYNC" l1-lifespan="0" owners="2">
<locking isolation="REPEATABLE_READ"/>
<transaction mode="BATCH"/>
<file-store/>
</distributed-cache>
<distributed-cache name="concurrent" mode="SYNC" l1-lifespan="0" owners="2">
<file-store/>
</distributed-cache>
</cache-container>
<cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
<transport lock-timeout="60000"/>
<distributed-cache name="dist" mode="ASYNC" l1-lifespan="0" owners="2">
<locking isolation="REPEATABLE_READ"/>
<transaction mode="BATCH"/>
<file-store/>
</distributed-cache>
</cache-container>
<cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan">
<transport lock-timeout="60000"/>
<local-cache name="local-query">
<eviction strategy="LRU" max-entries="10000"/>
<expiration max-idle="100000"/>
</local-cache>
<invalidation-cache name="entity" mode="SYNC">
<transaction mode="NON_XA"/>
<eviction strategy="LRU" max-entries="10000"/>
<expiration max-idle="100000"/>
</invalidation-cache>
<replicated-cache name="timestamps" mode="ASYNC"/>
</cache-container>
</subsystem>
{noformat}
was (Author: bcampolina):
<subsystem xmlns="urn:jboss:domain:infinispan:4.0">
<cache-container name="server" aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server">
<transport lock-timeout="60000"/>
<replicated-cache name="default" mode="SYNC">
<transaction mode="BATCH"/>
</replicated-cache>
</cache-container>
<cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
<transport lock-timeout="60000"/>
<distributed-cache name="dist" mode="ASYNC" l1-lifespan="0" owners="2">
<locking isolation="REPEATABLE_READ"/>
<transaction mode="BATCH"/>
<file-store/>
</distributed-cache>
<distributed-cache name="concurrent" mode="SYNC" l1-lifespan="0" owners="2">
<file-store/>
</distributed-cache>
</cache-container>
<cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
<transport lock-timeout="60000"/>
<distributed-cache name="dist" mode="ASYNC" l1-lifespan="0" owners="2">
<locking isolation="REPEATABLE_READ"/>
<transaction mode="BATCH"/>
<file-store/>
</distributed-cache>
</cache-container>
<cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan">
<transport lock-timeout="60000"/>
<local-cache name="local-query">
<eviction strategy="LRU" max-entries="10000"/>
<expiration max-idle="100000"/>
</local-cache>
<invalidation-cache name="entity" mode="SYNC">
<transaction mode="NON_XA"/>
<eviction strategy="LRU" max-entries="10000"/>
<expiration max-idle="100000"/>
</invalidation-cache>
<replicated-cache name="timestamps" mode="ASYNC"/>
</cache-container>
</subsystem>
> Problem with cluster, org.wildfly.clustering.web.undertow.session.DistributableSession
> --------------------------------------------------------------------------------------
>
> Key: WFLY-6731
> URL: https://issues.jboss.org/browse/WFLY-6731
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Bruno Silva
> Assignee: Paul Ferraro
>
> {noformat}
> ay0uwkDSnTKoZNLMN9atwQhHB4KiZ url:/autenticacaosso/login.jsf;jsessionid=vrQfTnf0X0ZbbWAOEHUd-BXtb8Oa1TsfMjfqhh1C.node3
> 2016-04-08 08:41:14,766 ERROR [io.undertow.request] (default task-137) UT005023: Exception handling request to /autenticacaosso/login: java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429)
> at java.util.HashMap$KeyIterator.next(HashMap.java:1453)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.changeSessionId(DistributableSession.java:197)
> at io.undertow.servlet.spec.HttpServletRequestImpl.changeSessionId(HttpServletRequestImpl.java:329)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler$SecurityNotificationReceiver.handleNotification(CachedAuthenticatedSessionHandler.java:95)
> at io.undertow.security.impl.AbstractSecurityContext.sendNoticiation(AbstractSecurityContext.java:127)
> at io.undertow.security.impl.AbstractSecurityContext.authenticationComplete(AbstractSecurityContext.java:85)
> at io.undertow.security.impl.AbstractSecurityContext.authenticationComplete(AbstractSecurityContext.java:78)
> at io.undertow.security.impl.SingleSignOnAuthenticationMechanism.authenticate(SingleSignOnAuthenticationMechanism.java:103)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:257)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$2(SecurityContextImpl.java:231)
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:123)
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:98)
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:91)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
> 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 io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months