[JBoss JIRA] (WFLY-3211) java:app resources can not be shared between ejb and appclient modules
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-3211?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-3211:
------------------------------
Affects Version/s: 11.0.0.Final
> java:app resources can not be shared between ejb and appclient modules
> ----------------------------------------------------------------------
>
> Key: WFLY-3211
> URL: https://issues.jboss.org/browse/WFLY-3211
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Affects Versions: 8.0.0.Final, 11.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Eduardo Martins
> Attachments: Sample_WildFly10.zip
>
>
> use case:
> 1 ear composed of:
> 1 appclient module that defines 2 JMS queues (one in java:app, the other in java:global)
> 1 ejb modules with 2 MDBs (one listening to the java:app queue and the other to the java:global queue)
> When the ear is deployed:
> 1. the ejb module is deployed, the MDBs are created and wait for the creations of their respective queues (defined in the appclient module)
> 2. the appclient module is deployed, its 2 queues are deployed
> 3. the appclient main is run
> When the appclient uses the java:global queue, it looks it up, sends the message and the corresponding MDB receives it fine.
> When the appclient uses the java:app queue, it looks it up, sends the message but the corresponding MDB never receives it
> => the MDB was never deployed because it did not see the java:app queue deployed from the appclient module.
> Note that if I move the destination definitions to the ejb module, the MDBs are correctly activated but the appclient module is no longer deployed with errors:
> {noformat}
> [APPCLIENT-out] {"JBAS014771: Services with missing/unavailable dependencies" => [
> [APPCLIENT-out] "jboss.naming.context.java.module.simple-jms-appclient-test.appclient.env.jms.queueInGlobal is missing [jboss.naming.context.java.global.jms.queu
> e.queue1]",
> [APPCLIENT-out] "jboss.naming.context.java.module.simple-jms-appclient-test.appclient.env.jms.queueInApp is missing [jboss.naming.context.java.app.simple-jms-app
> client-test.jms.queue.queue2]"
> [APPCLIENT-out] ]}
> {noformat}
> Steps to reproduce:
> 1. fetch git branch https://github.com/jmesnil/wildfly/tree/jms_appclient
> 2. build WildFly
> 3. run ./integration-tests.sh -Dts.basic -Dtest=org.jboss.as.test.integration.ee.appclient.jms.basic.SimpleJMSApplicationClientTestCase -DnoWebProfile
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-9530) Requesting TRANSACTIONAL cache concurrency strategy but the cache is not configured as transactional.
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-9530?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-9530:
-------------------------------
Summary: Requesting TRANSACTIONAL cache concurrency strategy but the cache is not configured as transactional. (was: [GSS](7.2.0) Requesting TRANSACTIONAL cache concurrency strategy but the cache is not configured as transactional.)
> Requesting TRANSACTIONAL cache concurrency strategy but the cache is not configured as transactional.
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-9530
> URL: https://issues.jboss.org/browse/WFLY-9530
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, JPA / Hibernate
> Affects Versions: 11.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> When deploying a legacy (non-JPA) Hibernate application with level 2 cache enabled, the following WARN is logged:
> {code}
> ... WARN [org.hibernate.cache.infinispan.impl.BaseRegion] ... Requesting TRANSACTIONAL cache concurrency strategy but the cache is not configured as transactional.
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFCORE-3410) Deadlock in model controller encountered in basic test suite
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3410?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3410:
------------------------------------------
Good news is it looks like the only place this is a problem is ConcreteResourceRegistration.unregisterSubModel(final PathElement address) where the WFCORE-1785 work introduced the problematic call that results in trying to acquire read locks on parent resources while holding the write lock.
> Deadlock in model controller encountered in basic test suite
> ------------------------------------------------------------
>
> Key: WFCORE-3410
> URL: https://issues.jboss.org/browse/WFCORE-3410
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: David Lloyd
> Assignee: Brian Stansberry
> Priority: Critical
> Attachments: stack.txt
>
>
> A Java-level deadlock was encountered while running {{org.jboss.as.test.integration.jca.workmanager.LongRunningThreadsCheckTestCase}}. The thread dump is attached.
> This occurred during testing of the new thread pool (WFLY-5332 and related), but it seems unlikely to be caused by this change, unless the new pool's scheduling behavior differed enough from the default that it exposed an already-existing race condition. The deadlock was hit just once in more than 10 runs.
> This is the deadlock:
> {noformat}
> Found one Java-level deadlock:
> =============================
> "DeploymentScanner-threads - 2":
> waiting for ownable synchronizer 0x000000075357cef0, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
> which is held by "MSC service thread 1-1"
> "MSC service thread 1-1":
> waiting for ownable synchronizer 0x000000071dff9b08, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
> which is held by "MSC service thread 1-2"
> "MSC service thread 1-2":
> waiting for ownable synchronizer 0x000000075357cef0, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
> which is held by "MSC service thread 1-1"
> {noformat}
> Here is the specific deadlock info (also in the attachment), showing that it has something to do with the model controller:
> {noformat}
> Java stack information for the threads listed above:
> ===================================================
> "DeploymentScanner-threads - 2":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000000075357cef0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.getOperationEntry(ConcreteResourceRegistration.java:304)
> at org.jboss.as.controller.registry.NodeSubregistry.getOperationEntry(NodeSubregistry.java:186)
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.getOperationEntry(ConcreteResourceRegistration.java:300)
> at org.jboss.as.controller.registry.NodeSubregistry.getOperationEntry(NodeSubregistry.java:186)
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.getOperationEntry(ConcreteResourceRegistration.java:300)
> at org.jboss.as.controller.registry.AbstractResourceRegistration.getOperationEntry(AbstractResourceRegistration.java:180)
> at org.jboss.as.controller.registry.AbstractResourceRegistration.getOperationEntry(AbstractResourceRegistration.java:175)
> at org.jboss.as.controller.OperationContextImpl.getAuthorizationAction(OperationContextImpl.java:1890)
> at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1832)
> at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1756)
> at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1306)
> at org.jboss.as.controller.operations.global.ReadResourceHandler.doExecuteInternal(ReadResourceHandler.java:316)
> at org.jboss.as.controller.operations.global.ReadResourceHandler.doExecute(ReadResourceHandler.java:171)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:231)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:982)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1402)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:418)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
> at org.jboss.as.controller.ModelControllerImpl$$Lambda$656/1109010279.run(Unknown Source)
> at org.wildfly.security.auth.server.SecurityIdentity$$Lambda$657/2059677950.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.controller.ModelControllerClientFactoryImpl$LocalClient.executeOperation(ModelControllerClientFactoryImpl.java:131)
> at org.jboss.as.controller.ModelControllerClientFactoryImpl$1$$Lambda$654/385827253.apply(Unknown Source)
> at org.jboss.as.controller.ModelControllerClientFactoryImpl.lambda$executeInVm$0(ModelControllerClientFactoryImpl.java:296)
> at org.jboss.as.controller.ModelControllerClientFactoryImpl$$Lambda$655/955046503.run(Unknown Source)
> at org.jboss.as.controller.access.InVmAccess.runInVm(InVmAccess.java:85)
> at org.jboss.as.controller.ModelControllerClientFactoryImpl.executeInVm(ModelControllerClientFactoryImpl.java:296)
> at org.jboss.as.controller.ModelControllerClientFactoryImpl.access$000(ModelControllerClientFactoryImpl.java:54)
> at org.jboss.as.controller.ModelControllerClientFactoryImpl$1.executeOperation(ModelControllerClientFactoryImpl.java:77)
> at org.jboss.as.controller.LocalModelControllerClient.execute(LocalModelControllerClient.java:54)
> at org.jboss.as.controller.LocalModelControllerClient.execute(LocalModelControllerClient.java:39)
> at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations$$Lambda$652/737892850.apply(Unknown Source)
> at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations$Execution$1.execute(DefaultDeploymentOperations.java:135)
> at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations.getDeploymentsStatus(DefaultDeploymentOperations.java:80)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScanContext.<init>(FileSystemDeploymentService.java:1687)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScanContext.<init>(FileSystemDeploymentService.java:1636)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:589)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:493)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$DeploymentScanRunnable.run(FileSystemDeploymentService.java:255)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:484)
> "MSC service thread 1-1":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000000071dff9b08> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.getCapabilities(ConcreteResourceRegistration.java:607)
> at org.jboss.as.controller.registry.NodeSubregistry.unregisterSubModel(NodeSubregistry.java:172)
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.unregisterSubModel(ConcreteResourceRegistration.java:273)
> at org.jboss.as.connector.services.resourceadapters.IronJacamarActivationResourceService.stop(IronJacamarActivationResourceService.java:283)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1761)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.execute(ServiceControllerImpl.java:1734)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1521)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1964)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1467)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1346)
> at java.lang.Thread.run(Thread.java:748)
> "MSC service thread 1-2":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000000075357cef0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.getSubregistry(ConcreteResourceRegistration.java:571)
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.getChildAddresses(ConcreteResourceRegistration.java:829)
> at org.jboss.as.controller.registry.NodeSubregistry.getChildAddresses(NodeSubregistry.java:349)
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.getChildAddresses(ConcreteResourceRegistration.java:833)
> at org.jboss.as.controller.registry.NodeSubregistry.getChildAddresses(NodeSubregistry.java:349)
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.getChildAddresses(ConcreteResourceRegistration.java:833)
> at org.jboss.as.controller.registry.AbstractResourceRegistration.getChildAddresses(AbstractResourceRegistration.java:326)
> at org.jboss.as.controller.registry.AbstractResourceRegistration.getChildAddresses(AbstractResourceRegistration.java:323)
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.unregisterSubModel(ConcreteResourceRegistration.java:264)
> at org.jboss.as.connector.services.resourceadapters.IronJacamarActivationResourceService.stop(IronJacamarActivationResourceService.java:281)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1761)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.execute(ServiceControllerImpl.java:1734)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1521)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1964)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1467)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1346)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (DROOLS-1825) [Guided Decision Table] Ability to change HIT policy in a decision table anytime
by Matthew Stevens (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1825?page=com.atlassian.jira.plugi... ]
Matthew Stevens updated DROOLS-1825:
------------------------------------
Sprint: 2017 Week 45-46
> [Guided Decision Table] Ability to change HIT policy in a decision table anytime
> --------------------------------------------------------------------------------
>
> Key: DROOLS-1825
> URL: https://issues.jboss.org/browse/DROOLS-1825
> Project: Drools
> Issue Type: Enhancement
> Components: Guided Decision Table Editor
> Affects Versions: 7.1.0.Beta2
> Reporter: Ivo Bek
> Assignee: Toni Rikkola
> Priority: Critical
> Labels: UX
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> Today, it's possible to set 1 of 5 HIT policies when we create a new guided decision table. However, the user might not know which HIT policy he/she should use at this early beginning. Therefore, it should be possible to set the policy to None when we create a new guided decision table and set the HIT policy later after we add columns and rows, fill in some data and see and decide based on the created table how the rules should behave using the HIT policy.
> Thus, it should be possible to change HIT policy in a decision table anytime.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (DROOLS-1811) [Guided Decision Table] Column Wizard usability improvements
by Matthew Stevens (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1811?page=com.atlassian.jira.plugi... ]
Matthew Stevens updated DROOLS-1811:
------------------------------------
Sprint: 2017 Week 45-46
> [Guided Decision Table] Column Wizard usability improvements
> ------------------------------------------------------------
>
> Key: DROOLS-1811
> URL: https://issues.jboss.org/browse/DROOLS-1811
> Project: Drools
> Issue Type: Enhancement
> Components: Guided Decision Table Editor
> Affects Versions: 7.2.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Carreiro
> Labels: UX
> Fix For: 7.5.0.Final
>
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> On the _BRMS 7.0 - Getting Started Experience_ meeting, there were mentioned these points that could improve the column wizard:
> - Placement of input fields
> -- *Field binding* should be on the same page as *Field*
> -- Pages like *Operator* and *Field* could be merged or at least recapitulate what was selected on previous pages of the wizard
> - Input fields should be explained somehow. For newbies it is really hard to understand what is the *Calculation Type* or *Value List*. I liked concept of small _i_ in blue circle that shows hint after mouse is over this info sign.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (DROOLS-1825) [Guided Decision Table] Ability to change HIT policy in a decision table anytime
by Matthew Stevens (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1825?page=com.atlassian.jira.plugi... ]
Matthew Stevens updated DROOLS-1825:
------------------------------------
Labels: UX (was: )
> [Guided Decision Table] Ability to change HIT policy in a decision table anytime
> --------------------------------------------------------------------------------
>
> Key: DROOLS-1825
> URL: https://issues.jboss.org/browse/DROOLS-1825
> Project: Drools
> Issue Type: Enhancement
> Components: Guided Decision Table Editor
> Affects Versions: 7.1.0.Beta2
> Reporter: Ivo Bek
> Assignee: Toni Rikkola
> Priority: Critical
> Labels: UX
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> Today, it's possible to set 1 of 5 HIT policies when we create a new guided decision table. However, the user might not know which HIT policy he/she should use at this early beginning. Therefore, it should be possible to set the policy to None when we create a new guided decision table and set the HIT policy later after we add columns and rows, fill in some data and see and decide based on the created table how the rules should behave using the HIT policy.
> Thus, it should be possible to change HIT policy in a decision table anytime.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (DROOLS-1811) [Guided Decision Table] Column Wizard usability improvements
by Matthew Stevens (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1811?page=com.atlassian.jira.plugi... ]
Matthew Stevens updated DROOLS-1811:
------------------------------------
Labels: UX (was: )
> [Guided Decision Table] Column Wizard usability improvements
> ------------------------------------------------------------
>
> Key: DROOLS-1811
> URL: https://issues.jboss.org/browse/DROOLS-1811
> Project: Drools
> Issue Type: Enhancement
> Components: Guided Decision Table Editor
> Affects Versions: 7.2.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Carreiro
> Labels: UX
> Fix For: 7.5.0.Final
>
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> On the _BRMS 7.0 - Getting Started Experience_ meeting, there were mentioned these points that could improve the column wizard:
> - Placement of input fields
> -- *Field binding* should be on the same page as *Field*
> -- Pages like *Operator* and *Field* could be merged or at least recapitulate what was selected on previous pages of the wizard
> - Input fields should be explained somehow. For newbies it is really hard to understand what is the *Calculation Type* or *Value List*. I liked concept of small _i_ in blue circle that shows hint after mouse is over this info sign.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-447) Connection Reauthentication and Security Propagation
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-447?page=com.atlassian.jira.plugin.s... ]
David Lloyd resolved WFLY-447.
------------------------------
Fix Version/s: 11.0.0.Final
(was: 12.0.0.Alpha1)
Resolution: Done
This is resolved with the introduction of the Elytron security layer.
> Connection Reauthentication and Security Propagation
> ----------------------------------------------------
>
> Key: WFLY-447
> URL: https://issues.jboss.org/browse/WFLY-447
> Project: WildFly
> Issue Type: Task
> Components: EJB, Remoting, Security
> Reporter: Darran Lofthouse
> Labels: authentication_service
> Fix For: 11.0.0.Final
>
>
> This task is a top level task to coordinate the addition of support for switching to different security identities on an existing connection over Remoting.
> This is to predominantly cover two major scenarios: -
> - Clients using a single connection but require different calls to be executed as different users, in this case the client has the information required to start a new authentication as a different user.
> - Server to server communication where the first server has already authenticated a remote user - for this scenario the first server needs a way to tell the second server what identity to run the call as.
> The following document is building up the requirements and design considerations and decisions: -
> https://community.jboss.org/wiki/ConnectionRe-AuthenticationAndSecurityPr...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-959) Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-959?page=com.atlassian.jira.plugin.s... ]
David Lloyd resolved WFLY-959.
------------------------------
Fix Version/s: 11.0.0.Final
Resolution: Done
This issue is resolved with the integration of the new security layer (Elytron). Now it is possible to flow and switch identities in a number of ways.
> Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-959
> URL: https://issues.jboss.org/browse/WFLY-959
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Derek Horton
> Fix For: 11.0.0.Final
>
>
> My confusion is around the remoting/security-realm setup in the use case
> where multiple EJBs are deployed that use different security-domains and
> the EJBs will be invoked by remote standalone clients. For example,
> ejbX needs to be in the sec-domain-X security-domain, while ejbY needs to
> be in the sec-domain-Y security-domain.
> In this situation, the authentication checks are going to be handled by
> the security-realm that is associated with the remote connector that is
> configured to be used by the EJB subsystem.
> It looks like the security-realm can either handle the authentication
> checks directly (properties file, ldap, etc) or it can defer to the
> jaas security-domain. In both of those situations, it seems that the
> EJBs are limited to a single authentication point. The EJB
> authentication is either going to be handled by a single security-realm
> or the security-realm will defer to a single security-domain.
> I could configure the security-domain to have multiple login modules. I
> assume the same thing could be done with the security-realm.
> Basically the problem that I am trying to solve boils down to this: the
> authentication checks for remote EJBs appear to be checked by either a
> single security-realm or a single security-domain. Is there a way to
> change this?
> One idea I had was to add another remote connector to the EJB subsystem.
> Unfortunately, this does not appear to be possible.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months