[JBoss JIRA] (WFLY-5192) XTSSubsystemDefinition says HOST attribute doesn't allow null, but it should
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5192?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-5192.
----------------------------
> XTSSubsystemDefinition says HOST attribute doesn't allow null, but it should
> ----------------------------------------------------------------------------
>
> Key: WFLY-5192
> URL: https://issues.jboss.org/browse/WFLY-5192
> Project: WildFly
> Issue Type: Bug
> Components: XTS
> Affects Versions: 10.0.0.Beta2
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 10.0.0.CR1
>
>
> The xsd for the xts subsystem says the "host" element is not required, and the parser behaves accordingly, but the HOST attribute in XTSSubsystemDefinition says the attribute doesn't allow null, while simultaneously configuring a default value for it.
> Setting a default value for an attribute is pointless if it doesn't allow null; the default value is what the runtime services will use if the persistent config value is null.
> This situation prevents booting of legacy xml configs using schema versions that predate the "host element. (Specifically, EAP 6 configs.) The boot validates the entire config to ensure that required attributes are configured, and that validation fails. Booting configs that conform to the current schema would fail too if "host" was not present.
> This should be a simple one line change.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[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)
7 years, 1 month
[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)
7 years, 1 month
[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)
7 years, 1 month
[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)
7 years, 1 month