[JBoss JIRA] (WFLY-7768) Singleton deployment marked with jboss-all.xml will fail if deployed with a non HA profile
by Wolf-Dieter Fink (JIRA)
Wolf-Dieter Fink created WFLY-7768:
--------------------------------------
Summary: Singleton deployment marked with jboss-all.xml will fail if deployed with a non HA profile
Key: WFLY-7768
URL: https://issues.jboss.org/browse/WFLY-7768
Project: WildFly
Issue Type: Bug
Components: Clustering
Reporter: Wolf-Dieter Fink
Assignee: Paul Ferraro
Priority: Minor
If an application which is marked as a cluster HA-Singleton deployment is added to a server without a HA configuration, exactly without having the singleton subsystem, the parser for the application will fail as it does not use the related xsd.
For conveniance and user experiance this should be possible
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (WFCORE-2096) ServiceTarget and ServiceBuilder provided by OperationContext remain coupled to the context after the op is complete
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2096?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2096:
-------------------------------------
Description:
OperationContextImpl provides impls of ServiceTarget and ServiceBuilder to OSHs. It is valid for those OSHs to pass those (particularly the ServiceTarget) out to other code, e.g. DUPs, which will then use them as a kind of "subsystem scoped" target. As opposed, say, to a deployment scoped target that can be obtained from the DeploymentUnitService.
If this is done though, the target and builders continue to hold a ref to the state held by the OperationContext that created them. That state is no longer relevant once the management op is done and retaining a ref to it is a kind of memory leak. Any link back to the OC should be cleared from these objects when the operation is complete.
was:
OperationContextImpl provides impls of ServiceTarget and ServiceBuilder to OSHs. It is valid for those OSHs to pass those (particularly the ServiceTarget) out to other code, e.g. DUPs, which will then use them as a kind of "subsystem scoped" target. (As opposed, say, to a deployment scoped target that can be obtained from the DeploymentUnitService.
If this is done though, the target and builders continue to a ref to the state held by the OperationContext that created them. That state is no longer relevant once the management op is done and retaining a ref to it is a kind of memory leak. Any link back to the OC should be cleared from these objecdts when the operation is complete.
> ServiceTarget and ServiceBuilder provided by OperationContext remain coupled to the context after the op is complete
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2096
> URL: https://issues.jboss.org/browse/WFCORE-2096
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha15
>
>
> OperationContextImpl provides impls of ServiceTarget and ServiceBuilder to OSHs. It is valid for those OSHs to pass those (particularly the ServiceTarget) out to other code, e.g. DUPs, which will then use them as a kind of "subsystem scoped" target. As opposed, say, to a deployment scoped target that can be obtained from the DeploymentUnitService.
> If this is done though, the target and builders continue to hold a ref to the state held by the OperationContext that created them. That state is no longer relevant once the management op is done and retaining a ref to it is a kind of memory leak. Any link back to the OC should be cleared from these objects when the operation is complete.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (WFLY-7730) Problem in undertow application-security-domain removing
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7730?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7730:
-----------------------------
Description:
Following error when try to remove *undertow.application-security-domain*:
{code:java}
WFLYCTL0013: Operation ("remove") failed - address: ([
("subsystem" => "undertow"),
("application-security-domain" => "ejb3-tests")
]): java.lang.IllegalArgumentException: WFLYCTL0394: Capability 'org.wildfly.extension.undertow.application-security-domain.ejb3-tests' does not provide services of type 'class org.wildfly.security.auth.server.HttpAuthenticationFactory'
{code}
Problem is wrong type in obtaining service in RemoveHandler.
was:
Following error when try to remove *undertow.application-security-domain*:
java.lang.IllegalArgumentException: WFLYCTL0394: Capability 'org.wildfly.extension.undertow.application-security-domain.ejb3-tests' does not provide services of type 'class org.wildfly.security.auth.server.HttpAuthenticationFactory'
Problem is wrong type in obtaining service in RemoveHandler.
> Problem in undertow application-security-domain removing
> --------------------------------------------------------
>
> Key: WFLY-7730
> URL: https://issues.jboss.org/browse/WFLY-7730
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 11.0.0.Alpha1
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> Following error when try to remove *undertow.application-security-domain*:
> {code:java}
> WFLYCTL0013: Operation ("remove") failed - address: ([
> ("subsystem" => "undertow"),
> ("application-security-domain" => "ejb3-tests")
> ]): java.lang.IllegalArgumentException: WFLYCTL0394: Capability 'org.wildfly.extension.undertow.application-security-domain.ejb3-tests' does not provide services of type 'class org.wildfly.security.auth.server.HttpAuthenticationFactory'
> {code}
> Problem is wrong type in obtaining service in RemoveHandler.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (ELY-524) RealmIdentity data caching support in the LDAP realm
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-524?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-524:
---------------------------------
Fix Version/s: 1.1.0.Beta18
(was: 1.1.0.Beta17)
> RealmIdentity data caching support in the LDAP realm
> ----------------------------------------------------
>
> Key: ELY-524
> URL: https://issues.jboss.org/browse/ELY-524
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Realms
> Reporter: David Lloyd
> Assignee: Pedro Igor
> Priority: Critical
> Fix For: 1.1.0.Beta18
>
>
> The LDAP realm should use a caching strategy to avoid excessive database load in the presence of per-request authentication traffic.
> The realm implementation could maintain a synchronized LRU cache of one-time-initialize references to a cached DirContext or Attributes or binding or some combination of these. Because the cache is synchronized, the one-time-initialize object would be added under the lock and then the lock released before the object is populated and returned as a cached credential, allowing atomic action with a minimum of contention.
> For each cached entity, a NamingListener could be established which would invalidate (or possibly update) the cached value as the database changes.
> Alternatively, a NamingListener could be established for all identities, and each update would invalidate or update any cached values corresponding to the DN or resolved name.
> This is a complex design topic so discussion is welcome.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months