[JBoss JIRA] (DROOLS-1715) Running DMN evaluation in parallel causes a ConcurrentModificationException
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1715?page=com.atlassian.jira.plugi... ]
Edson Tirelli reassigned DROOLS-1715:
-------------------------------------
Assignee: Matteo Mortari (was: Edson Tirelli)
> Running DMN evaluation in parallel causes a ConcurrentModificationException
> ---------------------------------------------------------------------------
>
> Key: DROOLS-1715
> URL: https://issues.jboss.org/browse/DROOLS-1715
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.2.0.Final
> Reporter: David Le Moing
> Assignee: Matteo Mortari
>
> When launching some Parameterized tests in parallel, I noticed that I was not getting any answer (it works with only 1 thread). When I started digging, I found that the cause was a ConcurrentModificationException thrown when iterating over events in the processEvents method of DMNDTExpressionEvaluator.
> {code}
> at java.util.ConcurrentModificationException.<init>(ConcurrentModificationException.java:78)
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> at java.util.ArrayList$Itr.next(ArrayList.java:851)
> at org.kie.dmn.core.ast.DMNDTExpressionEvaluator.processEvents(DMNDTExpressionEvaluator.java:101)
> at org.kie.dmn.core.ast.DMNDTExpressionEvaluator.evaluate(DMNDTExpressionEvaluator.java:92)
> at org.kie.dmn.core.impl.DMNRuntimeImpl.evaluateDecision(DMNRuntimeImpl.java:337)
> at org.kie.dmn.core.impl.DMNRuntimeImpl.evaluateAll(DMNRuntimeImpl.java:92)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFLY-9262) adding undertow using the cli requires a batch
by Alexey Loubyansky (JIRA)
Alexey Loubyansky created WFLY-9262:
---------------------------------------
Summary: adding undertow using the cli requires a batch
Key: WFLY-9262
URL: https://issues.jboss.org/browse/WFLY-9262
Project: WildFly
Issue Type: Feature Request
Components: Web (Undertow)
Affects Versions: 11.0.0.Beta1
Reporter: Alexey Loubyansky
Assignee: Tomaz Cerar
Undertow appears to be the only subsystem now requiring a composite operation when it is added to the domain management model using management operations from a management client, e.g. cli.
The exact error is
{quote}
[standalone@embedded /] /subsystem=undertow:add
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0369: Required capabilities are not available:
org.wildfly.undertow.host.default-server.default-host; Possible registration points for this capability:
/subsystem=undertow/server=*/host=*
org.wildfly.undertow.server.default-server; Possible registration points for this capability:
/subsystem=undertow/server=*
org.wildfly.undertow.servlet-container.default; Possible registration points for this capability:
/subsystem=undertow/servlet-container=*",
"rolled-back" => true,
"response-headers" => {"process-state" => "reload-required"}
}
{quote}
The sequence that actually works is
{quote}
batch
/subsystem=undertow:add
/subsystem=undertow/buffer-cache=default:add
/subsystem=undertow/configuration=filter:add
/subsystem=undertow/configuration=handler:add
/subsystem=undertow/server=default-server:add
/subsystem=undertow/server=default-server/host=default-host:add(alias=["localhost"])
/subsystem=undertow/server=default-server/http-listener=default:add(socket-binding="http",redirect-socket="https",enable-http2="true")
/subsystem=undertow/servlet-container=default:add
run-batch
{quote}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFLY-6882) A client is not able to invoke EJB's deployed as "HASingleton deployment"
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/WFLY-6882?page=com.atlassian.jira.plugin.... ]
Wolf-Dieter Fink commented on WFLY-6882:
----------------------------------------
Even if this is working as designed - I would say this is a design problem.
>From a user perspective an EJB which can be called remote and is deployed as a ha-singleton in the cluster the expectation is that the client will automatically updated if the cluster-view changes and is able to invoke the EJB no matter which node is actually elected for the service.
It is not aceptable that the client need to know one of the following
- the (dynamic) address of the node driving the service
- all node addresses of a cluster; as this can change if new nodes are added/removed for performance or maintenance
The point which can be discussed is whether this is a bug or an enhancement.
> A client is not able to invoke EJB's deployed as "HASingleton deployment"
> -------------------------------------------------------------------------
>
> Key: WFLY-6882
> URL: https://issues.jboss.org/browse/WFLY-6882
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.Final, 11.0.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Enrique González Martínez
>
> Given that an application contains a SLSB and is clustered, any EJB client will be updated to have a view off all cluster members and is able to use and failover to any node in the cluster no matter whether it is in the initial list of servers.
> Now if the application is marked as "singleton-deployment" via jboss-all.xml and deployed to all servers only one server in a cluster will pick it and make it active.
> Now the expectation is that a client is routed to that server no matter whether this special server is included in the clients initial connection list.
> The interesting thing is that the client.log show that both servers are connected it the application is NOT marked as singleton
> But only the initial server is connected if the app is marked as singleton!
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFLY-6882) A client is not able to invoke EJB's deployed as "HASingleton deployment"
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/WFLY-6882?page=com.atlassian.jira.plugin.... ]
Wolf-Dieter Fink reopened WFLY-6882:
------------------------------------
> A client is not able to invoke EJB's deployed as "HASingleton deployment"
> -------------------------------------------------------------------------
>
> Key: WFLY-6882
> URL: https://issues.jboss.org/browse/WFLY-6882
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.Final, 11.0.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Enrique González Martínez
>
> Given that an application contains a SLSB and is clustered, any EJB client will be updated to have a view off all cluster members and is able to use and failover to any node in the cluster no matter whether it is in the initial list of servers.
> Now if the application is marked as "singleton-deployment" via jboss-all.xml and deployed to all servers only one server in a cluster will pick it and make it active.
> Now the expectation is that a client is routed to that server no matter whether this special server is included in the clients initial connection list.
> The interesting thing is that the client.log show that both servers are connected it the application is NOT marked as singleton
> But only the initial server is connected if the app is marked as singleton!
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFLY-9261) Cluster connection receives a "consumer created" message from the rebooting node but it has no corresponding binding for it locally
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9261?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-9261:
---------------------------------
Component/s: JMS
(was: Clustering)
> Cluster connection receives a "consumer created" message from the rebooting node but it has no corresponding binding for it locally
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9261
> URL: https://issues.jboss.org/browse/WFLY-9261
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Flavia Rainone
> Assignee: Martyn Taylor
>
> When rebooting a cluster node that uses singleton cluster mdbs, we get this error message:
> {noformat}
> 2017-07-25 16:08:54,426 ERROR [org.apache.activemq.artemis.core.server] (Thread-3 (ActiveMQ-client-global-threads)) AMQ224037: cluster connection Failed to handle message: java.lang.IllegalStateException: Cannot find binding for jms.queue.HelloWorldMDBQueuedea3e995-713c-11e7-85f2-b8f6b112daf7 on ClusterConnectionImpl@1129705701[nodeUUID=dabaa1fa-713c-11e7-8f3a-b8f6b112daf7, connector=TransportConfiguration(name=http-connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=http-acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=9080&host=localhost, address=jms, server=ActiveMQServerImpl::serverUUID=dabaa1fa-713c-11e7-8f3a-b8f6b112daf7]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.doConsumerCreated(ClusterConnectionImpl.java:1294)
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.handleNotificationMessage(ClusterConnectionImpl.java:1029)
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.onMessage(ClusterConnectionImpl.java:1004)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1001)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:49)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1124)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:101)
> 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
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (DROOLS-1715) Running DMN evaluation in parallel causes a ConcurrentModificationException
by David LE MOING (JIRA)
David LE MOING created DROOLS-1715:
--------------------------------------
Summary: Running DMN evaluation in parallel causes a ConcurrentModificationException
Key: DROOLS-1715
URL: https://issues.jboss.org/browse/DROOLS-1715
Project: Drools
Issue Type: Bug
Components: dmn engine
Affects Versions: 7.2.0.Final
Reporter: David LE MOING
Assignee: Edson Tirelli
When launching some Parameterized tests in parallel, I noticed that I was not getting any answer (it works with only 1 thread). When I started digging, I found that the cause was a ConcurrentModificationException thrown when iterating over events in the processEvents method of DMNDTExpressionEvaluator.
{code}
at java.util.ConcurrentModificationException.<init>(ConcurrentModificationException.java:78)
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
at java.util.ArrayList$Itr.next(ArrayList.java:851)
at org.kie.dmn.core.ast.DMNDTExpressionEvaluator.processEvents(DMNDTExpressionEvaluator.java:101)
at org.kie.dmn.core.ast.DMNDTExpressionEvaluator.evaluate(DMNDTExpressionEvaluator.java:92)
at org.kie.dmn.core.impl.DMNRuntimeImpl.evaluateDecision(DMNRuntimeImpl.java:337)
at org.kie.dmn.core.impl.DMNRuntimeImpl.evaluateAll(DMNRuntimeImpl.java:92)
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (ELY-1240) Attribute security-domain from Elytron authentication-configuration does not propagate credentials with OAUTHBEARER mechanism
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1240?page=com.atlassian.jira.plugin.s... ]
Jan Kalina closed ELY-1240.
---------------------------
Fix Version/s: 1.1.0.Beta53
Resolution: Duplicate Issue
Labels: (was: eap7.1-rfe-blocker)
Resolved in ELY-559
> Attribute security-domain from Elytron authentication-configuration does not propagate credentials with OAUTHBEARER mechanism
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1240
> URL: https://issues.jboss.org/browse/ELY-1240
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta47
> Reporter: Ondrej Lukas
> Priority: Blocker
> Fix For: 1.1.0.Beta53
>
>
> When client-server schema as 'Client -> Server A -> Server B' is used and intermediate server (server A) uses authentication-configuration.security-domain and OAUTHBEARER mechanism is used then application (i.e. EJB) from intermediate server cannot authenticate to server B. It seems that OAUTHBEARER mechanism cannot be chosen by SASL mechanism selector when bearer token is not explicitly provided.
> Intermediate server should be able to obtain credentials for OAuth from given security domain and use them for authentication [1].
> See reproducer for more details.
> We request blocker flag since this issue breaks feature in RFE EAP7-284 Client / Server Security Context Propagation for Remoting and Running As a given user and RFE EAP7-568 Server side configuration for Elytron Client.
> Exception from intermediate server:
> {code}
> ERROR [org.jboss.as.ejb3.invocation] (default task-5) WFLYEJB0034: EJB Invocation failed on component Intermediate for method public abstract java.lang.String example.ejb.WhoAmIBeanRemote.whoAmI(): javax.ejb.EJBException: java.lang.IllegalStateException: EJBCLIENT000024: Not able to find EJB matching "StatelessEJBLocator for "/server-side/WhoAmIBean", view is interface example.ejb.WhoAmIBeanRemote, affinity is None"
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:188)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:332)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:240)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:327)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.security.IdentityOutflowInterceptor.processInvocation(IdentityOutflowInterceptor.java:73)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.security.RolesAllowedInterceptor.processInvocation(RolesAllowedInterceptor.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.security.SecurityDomainInterceptor.processInvocation(SecurityDomainInterceptor.java:44)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:256)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:380)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:460)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:455)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:165)
> 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)
> Caused by: java.lang.IllegalStateException: EJBCLIENT000024: Not able to find EJB matching "StatelessEJBLocator for "/server-side/WhoAmIBean", view is interface example.ejb.WhoAmIBeanRemote, affinity is None"
> at org.jboss.ejb.client.EJBClientContext.discoverAffinityNone(EJBClientContext.java:719)
> at org.jboss.ejb.client.EJBClientContext.performLocatedAction(EJBClientContext.java:701)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:162)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:112)
> at com.sun.proxy.$Proxy47.whoAmI(Unknown Source)
> at example.ejb.Intermediate.whoAmI(Intermediate.java:21)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:327)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:90)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:101)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> ... 46 more
> Suppressed: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (OAUTHBEARER) are supported
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:438)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:246)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:567)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:545)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:513)
> at org.jboss.remoting3.ConnectionInfo$None.getConnection(ConnectionInfo.java:84)
> at org.jboss.remoting3.ConnectionInfo.getConnection(ConnectionInfo.java:57)
> at org.jboss.remoting3.EndpointImpl.doGetConnection(EndpointImpl.java:464)
> at org.jboss.remoting3.EndpointImpl.getConnectedIdentity(EndpointImpl.java:410)
> at org.jboss.remoting3.Endpoint.getConnectedIdentity(Endpoint.java:126)
> at org.jboss.remoting3.Endpoint.getConnectedIdentity(Endpoint.java:139)
> at org.jboss.remoting3.Endpoint.getConnection(Endpoint.java:216)
> at org.jboss.ejb.protocol.remote.RemotingEJBDiscoveryProvider.lambda$discover$0(RemotingEJBDiscoveryProvider.java:103)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.ejb.protocol.remote.RemotingEJBDiscoveryProvider.discover(RemotingEJBDiscoveryProvider.java:103)
> at org.wildfly.discovery.impl.AggregateDiscoveryProvider.discover(AggregateDiscoveryProvider.java:58)
> at org.wildfly.discovery.Discovery.discover(Discovery.java:94)
> at org.jboss.ejb.client.EJBClientContext.discover(EJBClientContext.java:442)
> at org.jboss.ejb.client.EJBClientContext.discoverAffinityNone(EJBClientContext.java:714)
> ... 76 more
> {code}
> [1] https://issues.jboss.org/browse/JBEAP-11377?focusedCommentId=13416866&pag...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (ELY-1171) Access with empty username is not logged in Elytron audit log
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1171?page=com.atlassian.jira.plugin.s... ]
Jan Kalina closed ELY-1171.
---------------------------
Resolution: Rejected
>From JBEAP-10997: blank username cannot lead to successful authentication - no audit log event is correct - closing.
> Access with empty username is not logged in Elytron audit log
> -------------------------------------------------------------
>
> Key: ELY-1171
> URL: https://issues.jboss.org/browse/ELY-1171
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Audit
> Affects Versions: 1.1.0.Beta42
> Reporter: Ondrej Lukas
> Priority: Blocker
>
> When empty user name is used for authentication then there is no audit log related to this event. It does not appear in syslog nor audit file. Empty username should be logged since it can be valid configuration for some systems.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months