[JBoss JIRA] (ELY-767) LDAP realm - AttributeMapping structure
by Jan Kalina (JIRA)
Jan Kalina created ELY-767:
------------------------------
Summary: LDAP realm - AttributeMapping structure
Key: ELY-767
URL: https://issues.jboss.org/browse/ELY-767
Project: WildFly Elytron
Issue Type: Enhancement
Components: Realms
Reporter: Jan Kalina
Assignee: Jan Kalina
Structure of AttributeMaping of LdapSecurityRealm is illogical:
Currently:
* meaning of asRdn is different for mappings without filter (obtaining attribute from identity entry) and with filter (different entry)
* simple: attribute value is parsed as DN
* filtered: DN of the whole entry is parsed (and ldapName, which is required, is ignored)
I suggest:
* when asRdn is defined:
* if ldapName will be defined, LDAP attribute will be parsed (for filtered mappings too)
* if ldapName will not be defined, DN of entry will be parsed (DN of identity entry for simple mapping)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (WFLY-7210) Expose JAX-RS resources as children of the subsystem
by Harald Pehl (JIRA)
[ https://issues.jboss.org/browse/WFLY-7210?page=com.atlassian.jira.plugin.... ]
Harald Pehl commented on WFLY-7210:
-----------------------------------
How exactly are the JAX-RS resources exposed in the management model? Is there one resource for each JAX-RS resource with different children for each method of the JAX-RS resource or are there resources for each JAX-RS class / method?
Could you give a quick example of some annotated JAX-RS classes (using both class and method-level annotations) and the related management resources? Thanks.
> Expose JAX-RS resources as children of the subsystem
> ----------------------------------------------------
>
> Key: WFLY-7210
> URL: https://issues.jboss.org/browse/WFLY-7210
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Affects Versions: 10.1.0.Final
> Reporter: Guillermo González de Agüero
> Assignee: Lin Gao
> Attachments: after-wfly7024.png, hal-jaxrs.png
>
>
> Servlets, EJBs, WebSockets, JPA, etc expose its components as children of the subsystem in the management API. For example to list the stateless EJBs of a deployment:
> [standalone@localhost:9990 /] /deployment=cdivsejb.war/subsystem=ejb3:read-children-resources(child-type=stateless-session-bean)
> This makes it specially easy to navigate trough the web console (attached screenshot).
> To read JAX-RS resources, the command would be:
> [standalone@localhost:9990 /] /deployment=cdivsejb.war/subsystem=jaxrs:show-resources()
> I propose to make deprecate the show-resources operation and create a new "resources" child, containing the Rest resources.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (JGRP-2131) UNICAST3 drops all messages until it receives the first one
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2131?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2131.
----------------------------
Resolution: Done
> UNICAST3 drops all messages until it receives the first one
> -----------------------------------------------------------
>
> Key: JGRP-2131
> URL: https://issues.jboss.org/browse/JGRP-2131
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Dennis Reed
> Assignee: Bela Ban
> Fix For: 3.6.12, 4.0
>
>
> UNICAST3.getReceiverEntry returns null if it hasn't seen the first message yet.
> This causes UNICAST3.handleDataReceived to drop the message.
> When you add *ENCRYPT, this causes a major deadlock. *ENCRYPT will queue most messages until it gets the encryption key, which can often include the first message (so UNICAST3 won't see it yet). Then when an important message such as JOIN_RSP comes through, UNICAST3 drops it. Since UNICAST3 never lets any messages through in this case, the encryption key will never get set so that *ENCRYPT can pass the first message up and free the deadlock.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (REMJMX-120) Enable All Security Tests Backed By Elytron
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/REMJMX-120?page=com.atlassian.jira.plugin... ]
Darran Lofthouse resolved REMJMX-120.
-------------------------------------
Resolution: Done
> Enable All Security Tests Backed By Elytron
> -------------------------------------------
>
> Key: REMJMX-120
> URL: https://issues.jboss.org/browse/REMJMX-120
> Project: Remoting JMX
> Issue Type: Enhancement
> Components: Security, Tests
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 3.0.0.Alpha5
>
>
> By enabling the tests I mean get them all working ;-)
> We most likely need a wildfly-client-config.xml for default settings, also tests should be updated to cover both direct JMXConnector use and cases where AuthenticationConfiguration can be set before.
> Some clients such as jconsole will not be calling AuthenticationConfiguration first.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (WFCORE-2007) standalone.sh fails to backup gc.log.#.current file silently.
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2007?page=com.atlassian.jira.plugi... ]
Lin Gao reassigned WFCORE-2007:
-------------------------------
Assignee: Lin Gao (was: Tomaz Cerar)
> standalone.sh fails to backup gc.log.#.current file silently.
> -------------------------------------------------------------
>
> Key: WFCORE-2007
> URL: https://issues.jboss.org/browse/WFCORE-2007
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Environment: * Red Hat Enterprise Linux
> * This problem occurs on JBoss EAP 7.0.0.GA and later, but does not occur on EAP 6.4.x.
> Reporter: Lin Gao
> Assignee: Lin Gao
> Labels: downstream_dependency
>
> gc.log.*.current enclosed with double quotes in the following line (line 265) in standalone.sh is not evaluated as a wildcard by bash,
> {code:java}
> mv "$JBOSS_LOG_DIR/gc.log.*.current" "$JBOSS_LOG_DIR/backupgc.log.current" >/dev/null 2>&1
> {code}
> therefore standalone.sh fails to move an existing gc.log.<number>.current file to backupgc.log.current silently.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months