[JBoss JIRA] (WFLY-4844) When Wildfly EJB timer finishes, the transaction is not fully committed.
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4844?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-4844.
----------------------------
> When Wildfly EJB timer finishes, the transaction is not fully committed.
> -------------------------------------------------------------------------
>
> Key: WFLY-4844
> URL: https://issues.jboss.org/browse/WFLY-4844
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.2.0.Final
> Environment: Ubuntu and Mac
> Reporter: xiaodong xie
> Assignee: Stuart Douglas
> Priority: Critical
> Fix For: 10.0.0.Alpha6
>
>
> When a Singleton EJB timer finishes, if the next run has already started but waiting on the write lock of Singleton EJB, the next run won't see the changes committed by the current run. So I assume when the EJB timers finishes, the transaction is not fully committed, or it's the next run that starts too early.
> Here is a test case that should be able to reproduce the issue we are facing.
> https://github.com/xiaodong-xie/wildfly-singleton-timer
> Here is my analysis of this issue:
> The CMTTxInterceptor is applied before ContainerManagedConcurrencyInterceptor.
> So when waiting for the write lock of EJBReadWriteLock, we've already started the transaction, which IMHO is earlier than necessary.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-4978) unable to define excluded-connectors attribute for colocated replicated HA topology
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4978?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-4978.
----------------------------
> unable to define excluded-connectors attribute for colocated replicated HA topology
> ------------------------------------------------------------------------------------
>
> Key: WFLY-4978
> URL: https://issues.jboss.org/browse/WFLY-4978
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Alpha5
> Reporter: Ondřej Kalman
> Assignee: Jeff Mesnil
> Fix For: 10.0.0.Alpha6
>
>
> When list of connectors is defined in excluded-connectors atribute EAP throws this exception:
> WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "messaging-activemq"),
> ("server" => "default")
> ]): java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:136) [jboss-dmr-1.3.0.Final.jar:1.3.0.Final]
> at org.jboss.dmr.ModelNode.keys(ModelNode.java:1373) [jboss-dmr-1.3.0.Final.jar:1.3.0.Final]
> at org.wildfly.extension.messaging.activemq.ha.ReplicationColocatedDefinition.buildConfiguration(ReplicationColocatedDefinition.java:114)
> at org.wildfly.extension.messaging.activemq.ha.HAPolicyConfigurationBuilder.addHAPolicyConfiguration(HAPolicyConfigurationBuilder.java:71)
> at org.wildfly.extension.messaging.activemq.ServerAdd.transformConfig(ServerAdd.java:390)
> at org.wildfly.extension.messaging.activemq.ServerAdd.access$100(ServerAdd.java:139)
> at org.wildfly.extension.messaging.activemq.ServerAdd$3.execute(ServerAdd.java:195)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:820) [wildfly-controller-2.0.0.Alpha9.jar:2.0.0.Alpha9]
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:611) [wildfly-controller-2.0.0.Alpha9.jar:2.0.0.Alpha9]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:355) [wildfly-controller-2.0.0.Alpha9.jar:2.0.0.Alpha9]
> at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359) [wildfly-controller-2.0.0.Alpha9.jar:2.0.0.Alpha9]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05]
> at org.jboss.threads.JBossThread.run(JBossThread.java:320) [jboss-threads-2.2.1.Final.jar:2.2.1.Final]
> cli command: ":write-attribute(name=excluded-connectors, value=["http-connector"])"
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-4625) EJB SecurityContextInterceptor attempts JAAS login which doesn't work for JASPIC authentications
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4625?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-4625.
----------------------------
> EJB SecurityContextInterceptor attempts JAAS login which doesn't work for JASPIC authentications
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-4625
> URL: https://issues.jboss.org/browse/WFLY-4625
> Project: WildFly
> Issue Type: Feature Request
> Reporter: arjan tijms
> Assignee: Stefan Guilhen
> Labels: authentication, ejb, jaspi, jaspic, security, security-context
> Fix For: 9.0.0.CR2, 10.0.0.Alpha2
>
>
> After a user has successfully authenticated with JASPIC it's not possible to access any method in a secured EJB bean, irrespective of the actual security constraints.
> The problem is that when an EJB is "secured" an extra interceptor is added to the chain: {{org.jboss.as.ejb3.security.SecurityContextInterceptor.SecurityContextInterceptor}}.
> This interceptor calls {{org.jboss.as.security.service.SimpleSecurityManager.push}}, which tries to establish a new stacked security context by attempting a login to a JAAS login module associated with the security domain.
> However, when the caller authenticated via a JASPIC auth module, there isn't necessarily such a JAAS login module (the JASPIC auth module is not required to call a JAAS login module, and even if it did it may not be the JAAS login module JBoss knows about).
> The problematic part in {{SimpleSecurityManager}}:
> {code}
> public void push(final String securityDomain, final String runAs, final String runAsPrincipal, final Set<String> extraRoles) {
> boolean contextPushed = false;
> boolean securityContextEstablished = false;
> final SecurityContext previous = SecurityContextAssociation.getSecurityContext();
> try {
> contexts.push(previous);
> contextPushed = true;
> SecurityContext current = establishSecurityContext(securityDomain);
> securityContextEstablished = true;
> if (previous != null) {
> current.setSubjectInfo(previous.getSubjectInfo());
> current.setIncomingRunAs(previous.getOutgoingRunAs());
> }
> RunAs currentRunAs = current.getIncomingRunAs();
> boolean trusted = currentRunAs != null && currentRunAs instanceof RunAsIdentity;
> if (trusted == false) {
>
> boolean authenticated = false;
> if (SecurityActions.remotingContextIsSet()) {
> // ...
> }
> // If we have a trusted identity no need for a re-auth.
> if (authenticated == false) {
> // THIS WILL EVENTUALLY ATTEMPT A JAAS LOGIN WHICH FAILS
> authenticated = authenticate(current, null);
> }
> {code}
> The (condensed) stack that will lead to an exception is the following:
> {noformat}
> javax.security.auth.login.FailedLoginException: PBOX000070: Password invalid/Password required
> org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(Principal, Object)
> org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(Principal, Object, Subject)
> org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(Principal, Object, Subject)
> org.jboss.as.security.service.SimpleSecurityManager.authenticate(SecurityContext, Subject)
> org.jboss.as.security.service.SimpleSecurityManager.push(String, String, String, Set<String>)
> org.jboss.as.ejb3.security.SecurityContextInterceptor.SecurityContextInterceptor(SecurityContextInterceptorHolder)
> {noformat}
> Since the {{SimpleSecurityManager}} is already doing a check to see if the call is remote or not, I wonder if it could not simply accept the existing security context as-is for local calls (not even start a new context) or just consider the existing security context as trusted for local calls just like a {{RunAS}} identity.
> Note that this depends on SECURITY-744 and SECURITY-745, since otherwise there is no valid security context at all.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-3355) MDB fails to deploy on reload
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3355?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-3355.
----------------------------
> MDB fails to deploy on reload
> -----------------------------
>
> Key: WFLY-3355
> URL: https://issues.jboss.org/browse/WFLY-3355
> Project: WildFly
> Issue Type: Bug
> Components: EJB, JMS
> Affects Versions: 10.0.0.Alpha4
> Environment: Windows 7, 64bit
> Reporter: Bart Van Dosselaer
> Assignee: Jeff Mesnil
> Fix For: 10.0.0.Beta1
>
> Attachments: leak-0.0.1-SNAPSHOT.jar
>
>
> When an MDB is deployed and a :reload command is issues, the application server fails to deploy this MDB.
> Stacktrace:
> {noformat}
> 2014-05-14 16:11:22,284 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 57) MSC000001: Failed to start service jboss.deployment.unit."wildfly-helloworld-mdb.war".component.HelloWorldQueueMDB.START: org.jboss.msc.service.StartException in service jboss.deployment.unit."wildfly-helloworld-mdb.war".component.HelloWorldQueueMDB.START: java.lang.RuntimeException: javax.resource.spi.work.WorkRejectedException: IJ000263: WorkManager is shutting down
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57) [wildfly-ee-8.1.0.CR2.jar:8.1.0.CR2]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_55]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_55]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.RuntimeException: javax.resource.spi.work.WorkRejectedException: IJ000263: WorkManager is shutting down
> at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.activate(MessageDrivenComponent.java:215)
> at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start(MessageDrivenComponent.java:186)
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54) [wildfly-ee-8.1.0.CR2.jar:8.1.0.CR2]
> ... 6 more
> Caused by: javax.resource.spi.work.WorkRejectedException: IJ000263: WorkManager is shutting down
> at org.jboss.jca.core.workmanager.WorkManagerImpl.doFirstChecks(WorkManagerImpl.java:776) [ironjacamar-core-impl-1.1.5.Final.jar:1.1.5.Final]
> at org.jboss.jca.core.workmanager.WorkManagerImpl.scheduleWork(WorkManagerImpl.java:617) [ironjacamar-core-impl-1.1.5.Final.jar:1.1.5.Final]
> at org.jboss.jca.core.workmanager.WorkManagerImpl.scheduleWork(WorkManagerImpl.java:602) [ironjacamar-core-impl-1.1.5.Final.jar:1.1.5.Final]
> at org.hornetq.ra.inflow.HornetQActivation.start(HornetQActivation.java:264) [hornetq-ra-2.4.1.Final.jar:]
> at org.hornetq.ra.HornetQResourceAdapter.endpointActivation(HornetQResourceAdapter.java:166) [hornetq-ra-2.4.1.Final.jar:]
> at org.jboss.jca.core.rar.EndpointImpl.activate(EndpointImpl.java:191) [ironjacamar-core-impl-1.1.5.Final.jar:1.1.5.Final]
> at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.activate(MessageDrivenComponent.java:213)
> ... 8 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-5084) [Migration operation] group-address/group-port/local-bind-address in discovery-group are not migrated
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5084?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-5084.
----------------------------
> [Migration operation] group-address/group-port/local-bind-address in discovery-group are not migrated
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-5084
> URL: https://issues.jboss.org/browse/WFLY-5084
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Alpha6
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Fix For: 10.0.0.CR1
>
>
> During migration of discovery group with local-bind-address, group-address and group-port, those parameters are not migrated properly:
> For example HornetQ configuration:
> {code}
> <discovery-group name="groupC">
> <local-bind-address>localhost</local-bind-address>
> <group-address>224.0.1.105</group-address>
> <group-port>45678</group-port>
> <refresh-timeout>${refresh.timeout:3500}</refresh-timeout>
> <initial-wait-timeout>${initial.wait.timeout:7500}</initial-wait-timeout>
> </discovery-group>
> {code}
> is migrated to Artemis like:
> {code}
> <discovery-group name="groupC" initial-wait-timeout="${initial.wait.timeout:7500}" refresh-timeout="${refresh.timeout:3500}"/>
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-4813) CCE in XMLXaDataSourceRuntimeHandler.java
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4813?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-4813.
----------------------------
> CCE in XMLXaDataSourceRuntimeHandler.java
> -----------------------------------------
>
> Key: WFLY-4813
> URL: https://issues.jboss.org/browse/WFLY-4813
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 10.0.0.Alpha4
> Reporter: Frank Langelage
> Assignee: Jesper Pedersen
> Fix For: 10.0.0.Alpha6
>
> Attachments: DefaultDS-ds.xml
>
>
> 19.06. 19:52:13,830 ERROR [org.jboss.as.controller.management-operation#executeStep] WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("deployment" => "DefaultDS-ds.xml"),
> ("subsystem" => "datasources"),
> ("xa-data-source" => "java:jboss/datasources/DefaultDS")
> ]): java.lang.ClassCastException: org.jboss.jca.common.metadata.ds.DsXaPoolImpl cannot be cast to org.jboss.jca.common.api.metadata.ds.DsPool
> at org.jboss.as.connector.subsystems.datasources.XMLXaDataSourceRuntimeHandler.handleDatasourceAttribute(XMLXaDataSourceRuntimeHandler.java:146)
> at org.jboss.as.connector.subsystems.datasources.XMLXaDataSourceRuntimeHandler.executeReadAttribute(XMLXaDataSourceRuntimeHandler.java:54)
> at org.jboss.as.connector.subsystems.datasources.XMLXaDataSourceRuntimeHandler.executeReadAttribute(XMLXaDataSourceRuntimeHandler.java:43)
> at org.jboss.as.connector.subsystems.datasources.AbstractXMLDataSourceRuntimeHandler.executeRuntimeStep(AbstractXMLDataSourceRuntimeHandler.java:62)
> at org.jboss.as.controller.AbstractRuntimeOnlyHandler$1.execute(AbstractRuntimeOnlyHandler.java:53)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:822)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:620)
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:373)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:349)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1201)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:223)
> 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.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
> at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:95)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> 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)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months