[JBoss JIRA] (WFLY-2488) Adding a datasource fails in a composite operation
by James Perkins (JIRA)
James Perkins created WFLY-2488:
-----------------------------------
Summary: Adding a datasource fails in a composite operation
Key: WFLY-2488
URL: https://issues.jboss.org/browse/WFLY-2488
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JCA
Affects Versions: 8.0.0.Beta1
Reporter: James Perkins
Assignee: Jesper Pedersen
Executing a composite operation fails when adding a datasource.
Stack Trace:
{code}
08:38:49,787 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 6) JBAS014612: Operation ("add") failed - address: ([
("subsystem" => "datasources"),
("data-source" => "ds-test")
]): org.jboss.msc.service.DuplicateServiceException: Service jboss.data-source-config.ds-test is already registered
at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2384) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:1422) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
at org.jboss.as.connector.subsystems.datasources.DataSourceEnable.addServices(DataSourceEnable.java:188)
at org.jboss.as.connector.subsystems.datasources.DataSourceEnable$1.execute(DataSourceEnable.java:84)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:258) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:143) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:205) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:110) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:157) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_45]
at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_45]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta1.jar:8.0.0.Beta1]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta1.jar:8.0.0.Beta1]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-959) Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms
by Corey Puffalt (JIRA)
[ https://issues.jboss.org/browse/WFLY-959?page=com.atlassian.jira.plugin.s... ]
Corey Puffalt commented on WFLY-959:
------------------------------------
Can the remoting protocol not be adjusted to defer authentication until requested instead of authenticating immediately when the connection is established with the server?
> 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
> Security Level: Public(Everyone can see)
> Components: EJB
> Reporter: Derek Horton
> Assignee: David Lloyd
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-2174) Intermittent failures in DomainControllerMigrationTestCase
by Emanuel Muckenhuber (JIRA)
[ https://issues.jboss.org/browse/WFLY-2174?page=com.atlassian.jira.plugin.... ]
Emanuel Muckenhuber resolved WFLY-2174.
---------------------------------------
Resolution: Done
This should be resolved.
> Intermittent failures in DomainControllerMigrationTestCase
> ----------------------------------------------------------
>
> Key: WFLY-2174
> URL: https://issues.jboss.org/browse/WFLY-2174
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management, Test Suite
> Affects Versions: 8.0.0.Alpha4
> Reporter: Brian Stansberry
> Assignee: Emanuel Muckenhuber
> Fix For: 8.0.0.CR1
>
>
> For example:
> java.lang.RuntimeException: "JBAS010839: Operation failed or was rolled back on all servers."
> at org.jboss.as.test.integration.domain.management.util.DomainLifecycleUtil.executeForResult(DomainLifecycleUtil.java:582)
> at org.jboss.as.test.integration.domain.DomainControllerMigrationTestCase.testDCFailover(DomainControllerMigrationTestCase.java:206)
> With this in the logs:
> [Host Controller] 14:51:08,996 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss EAP 6.2.0.Alpha1 (AS 7.3.0.Final-redhat-SNAPSHOT) (Host Controller) started in 829ms - Started 12 of 12 services (0 services are passive or on-demand)
> [Server:failover-two] 14:51:10,113 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "SimpleServlet.war" (runtime-name: "SimpleServlet.war")
> [Host Controller] 14:51:10,377 INFO [org.jboss.as.domain.controller.mgmt] (Remoting "failover-h3:MANAGEMENT" task-2) JBAS010920: Server [Server:failover-three] registered using connection [Channel ID 7e979de4 (inbound) of Remoting connection 00429bb7 to /127.0.0.1:53634]
> [Host Controller] 14:51:11,185 ERROR [org.jboss.as.controller.management-operation] (domain-connection-threads - 2) JBAS014612: Operation ("composite") failed - address: ([
> [Host Controller] ("host" => "failover-h3"),
> [Host Controller] ("server" => "failover-three")
> [Host Controller] ]): java.lang.RuntimeException: java.io.IOException: JBAS012175: Channel closed
> [Host Controller] at org.jboss.as.controller.remote.RemoteProxyController.execute(RemoteProxyController.java:203) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.TransformingProxyController$TransformingProxyControllerImpl.execute(TransformingProxyController.java:149) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.ProxyStepHandler.execute(ProxyStepHandler.java:130) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:624) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]
> .....
> [Host Controller] Caused by: java.io.IOException: JBAS012175: Channel closed
> [Host Controller] at org.jboss.as.host.controller.ManagedServerProxy$DisconnectedProtocolClient.execute(ManagedServerProxy.java:114)
> [Host Controller] at org.jboss.as.host.controller.ManagedServerProxy.execute(ManagedServerProxy.java:92)
> [Host Controller] at org.jboss.as.host.controller.ManagedServerProxy.execute(ManagedServerProxy.java:80)
> [Host Controller] at org.jboss.as.controller.remote.RemoteProxyController.execute(RemoteProxyController.java:159) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]
> [Host Controller] ... 23 more
> I believe what is going on here is the test is hitting expected behavior. It restarts an HC without restarting the servers. When the HC is reloaded, it is aware that it has disconnected servers. While it awaits reconnect, any attempt to send an op through to the disconnected server will get the exception above.
> If my analysis is correct, then the test just needs adjusting to check server status before continuing on. If it's incorrect and this shouldn't fail, then we have a bug. A 3rd option is it's correct, but the behavior is bad.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-2403) Cannot disable Datasource or XADatasource in standalone and domain modes
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2403?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2403:
-----------------------------------------------
Stefano Maestri <smaestri(a)redhat.com> made a comment on [bug 970679|https://bugzilla.redhat.com/show_bug.cgi?id=970679]
enabled attribute is read-only attribute (as read-resource-description describe), so even if you set it in the command it will be ignored, and datasources are always created as disabled, requiring an explicit :enable operation to be enabled runtime w/o a reload.
note that special attribute allow-resource-service-restart=true avoid the requirement of :reload for :enable and :disable operation. See as an example:
/subsystem=datasources/data-source=ExampleDS:disable{allow-resource-service-restart=true}
> Cannot disable Datasource or XADatasource in standalone and domain modes
> ------------------------------------------------------------------------
>
> Key: WFLY-2403
> URL: https://issues.jboss.org/browse/WFLY-2403
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Stefano Maestri
> Assignee: Stefano Maestri
>
> Description of problem:
> Cannot disable a Datasource or XADatasource in standalone mode. It's back to enabled state after server reload.
> Version-Release number of selected component (if applicable):
> 6.1
> How reproducible:
> Always
> Steps to Reproduce:
> Use the http management interface or the CLI
> 1.Create a Datasource of XADatasource
> 2.Disable it
> 3.The response indicates a server reload is required
> 4.Execute the reload operation
> Actual results:
> The datasource is back to enabled state
> Expected results:
> The datasource should be in disabled state
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-1966) Hangs in DomainControllerMigrationTestCase
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-1966?page=com.atlassian.jira.plugin.... ]
Brian Stansberry resolved WFLY-1966.
------------------------------------
Assignee: Darran Lofthouse
Resolution: Done
Darran fixed the Subject propagation issue quite a while ago.
> Hangs in DomainControllerMigrationTestCase
> ------------------------------------------
>
> Key: WFLY-1966
> URL: https://issues.jboss.org/browse/WFLY-1966
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Darran Lofthouse
> Fix For: 8.0.0.CR1
>
> Attachments: thread-dump.txt
>
>
> DomainControllerMigrationTestCase is intermittently hanging recently.
> I will attach thread dumps from a recent hang.
> The test driver is hanging here:
> "main" prio=10 tid=0xb7605c00 nid=0x7656 in Object.wait() [0xb7786000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xa99833f8> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at java.lang.Object.wait(Object.java:503)
> at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
> - eliminated <0xa99833f8> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> - locked <0xa99833f8> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:76)
> at org.jboss.as.controller.client.helpers.domain.impl.DomainClientImpl.execute(DomainClientImpl.java:86)
> at org.jboss.as.test.integration.domain.management.util.DomainLifecycleUtil.executeForResult(DomainLifecycleUtil.java:580)
> at org.jboss.as.test.integration.domain.DomainControllerMigrationTestCase.testDCFailover(DomainControllerMigrationTestCase.java:206)
> The master HC process is stuck here:
> "management-handler-thread - 2" prio=10 tid=0x8be50400 nid=0x1a92 waiting on condition [0x87604000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xaa032fd0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
> at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at org.jboss.as.controller.remote.BlockingQueueOperationListener.retrievePreparedOperation(BlockingQueueOperationListener.java:84)
> at org.jboss.as.domain.controller.operations.coordination.DomainSlaveHandler.execute(DomainSlaveHandler.java:117)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:608)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:486)
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:275)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:270)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:257)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:142)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:205)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:110)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> I see nothing relevant in the other thread dumps.
> The master HC is blocking waiting for a response from the slave HC.
> Just before the client makes the request that triggers this, it has reloaded the slave HC. The test is not robust in terms of how it checks that the slave is ready before continuing on with the test; it merely connects directly to the slave checks that the slave's root resource can be read. That can succeed relatively early in boot even before the slave has registered with the master.
> Fixing that may prevent the hangs, but it would likely paper over whatever problem is causing the hangs. A client invoking multi-host operations while a slave is booting and registering is a use case that can't hang.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-959) Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-959?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse commented on WFLY-959:
---------------------------------------
Re-reading your comment - the answer is No.
The authentication occurs on the establishment of the connection to the server, at that point we do not know what is going to be invoked and that connection can be used to invoke many different services including many different EJB deployments so there is not at this point an underlying subsystem that we can delegate to.
> 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
> Security Level: Public(Everyone can see)
> Components: EJB
> Reporter: Derek Horton
> Assignee: David Lloyd
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-959) Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms
by Corey Puffalt (JIRA)
[ https://issues.jboss.org/browse/WFLY-959?page=com.atlassian.jira.plugin.s... ]
Corey Puffalt commented on WFLY-959:
------------------------------------
Darran, my concern was that the so-called complete solution proposed by Jaikiran above is very complicated which is why I was asking whether a simple delegated approach would be feasible. Conceptually this would make a lot more sense to users.
> 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
> Security Level: Public(Everyone can see)
> Components: EJB
> Reporter: Derek Horton
> Assignee: David Lloyd
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-2403) Cannot disable Datasource or XADatasource in standalone and domain modes
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2403?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2403:
-----------------------------------------------
Martin Simka <msimka(a)redhat.com> made a comment on [bug 970679|https://bugzilla.redhat.com/show_bug.cgi?id=970679]
By following steps to reproduce I got:
[standalone@localhost:9999 /] data-source add --name=Test2 --driver-name=h2 --enabled=true --jndi-name=java:jboss/datasources/Test2 --connection-url=jdbc:h2:mem:test2;DB_CLOSE_DELAY=-1
[standalone@localhost:9999 /] data-source disable --name=Test2
operation-requires-reload true
process-state reload-required
[standalone@localhost:9999 /] re
read-attribute read-operation reload
[standalone@localhost:9999 /] reload
[standalone@localhost:9999 /] /subsystem=datasources/data-source=Test2:read-attribute(name=enabled)
{
"outcome" => "success",
"result" => false
}
[standalone@localhost:9999 /]
but there is another problem:
[standalone@localhost:9999 /] data-source add --name=Test2 --driver-name=h2 --enabled=true --jndi-name=java:jboss/datasources/Test2 --connection-url=jdbc:h2:mem:test2;DB_CLOSE_DELAY=-1
[standalone@localhost:9999 /] /subsystem=datasources/data-source=Test2:read-attribute(name=enabled)
{
"outcome" => "success",
"result" => false
}
datasource is not enabled, it requires restart/reload, but it doesn't notifies user.
[standalone@localhost:9999 /] reload
[standalone@localhost:9999 /] /subsystem=datasources/data-source=Test2:read-attribute(name=enabled)
{
"outcome" => "success",
"result" => true
}
Is it part of this issue or is it another issue? Should I create new BZ?
> Cannot disable Datasource or XADatasource in standalone and domain modes
> ------------------------------------------------------------------------
>
> Key: WFLY-2403
> URL: https://issues.jboss.org/browse/WFLY-2403
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Stefano Maestri
> Assignee: Stefano Maestri
>
> Description of problem:
> Cannot disable a Datasource or XADatasource in standalone mode. It's back to enabled state after server reload.
> Version-Release number of selected component (if applicable):
> 6.1
> How reproducible:
> Always
> Steps to Reproduce:
> Use the http management interface or the CLI
> 1.Create a Datasource of XADatasource
> 2.Disable it
> 3.The response indicates a server reload is required
> 4.Execute the reload operation
> Actual results:
> The datasource is back to enabled state
> Expected results:
> The datasource should be in disabled state
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months