January 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2178) [Deployment overlay] Operation list-links does not check if deployment exists

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2178?page=com.atlassian.jira.plugi... ] Chao Wang commented on WFCORE-2178: ----------------------------------- It's better to log a warning or throw CommandLineException to User if there is no resource found in provided overlay name at [DeploymentOverlayHandler.java#L1075|https://github.com/wildfly/wildfly-co...] instead of returning an empty list in silence. > [Deployment overlay] Operation list-links does not check if deployment exists > ----------------------------------------------------------------------------- > > Key: WFCORE-2178 > URL: https://issues.jboss.org/browse/WFCORE-2178 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management > Affects Versions: 3.0.0.Alpha17 > Reporter: Chao Wang > Assignee: Chao Wang > Priority: Minor > > *Problem* > When not existing overlay is specified no warning message is displayed. For example: > {code} > deployment-overlay list-links --name=not-existing-overlay > {code} > returns empty line > *Proposed solution* > Display warning message that not existing overlay was given. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2178) [Deployment overlay] Operation list-links does not check if deployment exists

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2178?page=com.atlassian.jira.plugi... ] Chao Wang moved JBEAP-8200 to WFCORE-2178: ------------------------------------------ Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2178 (was: JBEAP-8200) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: CLI Domain Management (was: Domain Management) (was: User Experience) Affects Version/s: 3.0.0.Alpha17 (was: 7.1.0.DR8) > [Deployment overlay] Operation list-links does not check if deployment exists > ----------------------------------------------------------------------------- > > Key: WFCORE-2178 > URL: https://issues.jboss.org/browse/WFCORE-2178 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management > Affects Versions: 3.0.0.Alpha17 > Reporter: Chao Wang > Assignee: Chao Wang > Priority: Minor > > *Problem* > When not existing overlay is specified no warning message is displayed. For example: > {code} > deployment-overlay list-links --name=not-existing-overlay > {code} > returns empty line > *Proposed solution* > Display warning message that not existing overlay was given. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7871) Decouple backup/site name from the name of the corresponding resource

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7871?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-7871: --------------------------------- Description: Currently, the site names defined in the JGroups subsystem RELAY2 protocol, and the backup names defined in the Infinispan subsystem do not allow expressions, since these name are used for the corresponding resource paths. To simplify the use of cross-site replication (specifically, to allow each site to use an identical domain.xml/standalone.xml), we can support expressions if we decouple the site name from the resource name. e.g. {noformat} <backups> <backup name="remote" site="${...}" strategy="SYNC"/> </backups> <relay site="local"> <remote-site name="local" site-name="${...}" channel=".."/> <remote-site name="remote" site-name="${...}" channel=".."/> </relay> {noformat} was: Currently, the site names defined in the JGroups subsystem RELAY2 protocol, and the backup names defined in the Infinispan subsystem do not allow expressions, since these name are used for the corresponding resource paths. To simplify the use of cross-site replication (specifically, to allow each site to use an identical domain.xml/standalone.xml), we can support expressions if we decouple the site name from the resource name. e.g. <backups> <backup name="remote" site="${...}" strategy="SYNC"/> </backups> <relay site="local"> <remote-site name="local" site-name="${...}" channel=".."/> <remote-site name="remote" site-name="${...}" channel=".."/> </relay> > Decouple backup/site name from the name of the corresponding resource > --------------------------------------------------------------------- > > Key: WFLY-7871 > URL: https://issues.jboss.org/browse/WFLY-7871 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Beta1 > > > Currently, the site names defined in the JGroups subsystem RELAY2 protocol, and the backup names defined in the Infinispan subsystem do not allow expressions, since these name are used for the corresponding resource paths. To simplify the use of cross-site replication (specifically, to allow each site to use an identical domain.xml/standalone.xml), we can support expressions if we decouple the site name from the resource name. > e.g. > {noformat} > <backups> > <backup name="remote" site="${...}" strategy="SYNC"/> > </backups> > <relay site="local"> > <remote-site name="local" site-name="${...}" channel=".."/> > <remote-site name="remote" site-name="${...}" channel=".."/> > </relay> > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7874) Configuring SSLContext in mod_cluster filter fails with "Capability 'org.wildfly.undertow.mod_cluster_filter.modcluster' is unknown in context 'global'."

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7874?page=com.atlassian.jira.plugin.... ] Radoslav Husar moved JBEAP-8196 to WFLY-7874: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7874 (was: JBEAP-8196) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Web (Undertow) (was: Undertow) Affects Version/s: (was: 7.1.0.DR10) > Configuring SSLContext in mod_cluster filter fails with "Capability 'org.wildfly.undertow.mod_cluster_filter.modcluster' is unknown in context 'global'." > --------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7874 > URL: https://issues.jboss.org/browse/WFLY-7874 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Critical > > {noformat} > [standalone@localhost:9990 /] /subsystem=undertow/configuration=filter/mod-cluster=modcluster:write-attribute(name=ssl-context,value=test > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0365: Capability 'org.wildfly.undertow.mod_cluster_filter.modcluster' is unknown in context 'global'.", > "rolled-back" => true > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7874) Configuring SSLContext in mod_cluster filter fails with "Capability 'org.wildfly.undertow.mod_cluster_filter.modcluster' is unknown in context 'global'."

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7874?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-7874: --------------------------------- Affects Version/s: 10.1.0.Final > Configuring SSLContext in mod_cluster filter fails with "Capability 'org.wildfly.undertow.mod_cluster_filter.modcluster' is unknown in context 'global'." > --------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7874 > URL: https://issues.jboss.org/browse/WFLY-7874 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Critical > > {noformat} > [standalone@localhost:9990 /] /subsystem=undertow/configuration=filter/mod-cluster=modcluster:write-attribute(name=ssl-context,value=test > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0365: Capability 'org.wildfly.undertow.mod_cluster_filter.modcluster' is unknown in context 'global'.", > "rolled-back" => true > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-866) Update legacy properties realm so realm can be specified in case not specified in file.

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-866: ------------------------------------ Summary: Update legacy properties realm so realm can be specified in case not specified in file. Key: ELY-866 URL: https://issues.jboss.org/browse/ELY-866 Project: WildFly Elytron Issue Type: Enhancement Components: Realms Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta19 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7873) JaxRS archive does not warn when no servlet is provided.

by R Searls (JIRA)

[ https://issues.jboss.org/browse/WFLY-7873?page=com.atlassian.jira.plugin.... ] R Searls reassigned WFLY-7873: ------------------------------ Assignee: R Searls (was: Stuart Douglas) > JaxRS archive does not warn when no servlet is provided. > -------------------------------------------------------- > > Key: WFLY-7873 > URL: https://issues.jboss.org/browse/WFLY-7873 > Project: WildFly > Issue Type: Bug > Components: REST > Reporter: R Searls > Assignee: R Searls > Priority: Minor > > A jaxrs WAR archive must provide a servlet declaration either as a class that extends javax.ws.rs.core.Application or declare a servlet class in web.xml. If neither is provided > a warning messages should be provided during the deployment process. > This addresses the issue flagged in https://issues.jboss.org/browse/JBEAP-8163 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7873) JaxRS archive does not warn when no servlet is provided.

by R Searls (JIRA)

R Searls created WFLY-7873: ------------------------------ Summary: JaxRS archive does not warn when no servlet is provided. Key: WFLY-7873 URL: https://issues.jboss.org/browse/WFLY-7873 Project: WildFly Issue Type: Bug Components: REST Reporter: R Searls Assignee: Stuart Douglas Priority: Minor A jaxrs WAR archive must provide a servlet declaration either as a class that extends javax.ws.rs.core.Application or declare a servlet class in web.xml. If neither is provided a warning messages should be provided during the deployment process. This addresses the issue flagged in https://issues.jboss.org/browse/JBEAP-8163 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-857) Elytron ldap-realm is not able to use LDAP attribute as principal

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-857?page=com.atlassian.jira.plugin.sy... ] Jan Kalina edited comment on ELY-857 at 1/10/17 2:24 PM: --------------------------------------------------------- Ok, will add it as LdapRealm feature - configuration of attribute, which will be user principal. (similar normalization for other realms will be solved in ELY-865 ) was (Author: honza889): Ok, will add it as LdapRealm feature - configuration of attribute, which will be user principal. > Elytron ldap-realm is not able to use LDAP attribute as principal > ----------------------------------------------------------------- > > Key: ELY-857 > URL: https://issues.jboss.org/browse/ELY-857 > Project: WildFly Elytron > Issue Type: Bug > Components: Realms > Affects Versions: 1.1.0.Beta16 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Blocker > > In Elytron ldap-realm is currently not possible to obtain username from LDAP attribute which is different than rdn-identifier. It means that username of identity is always the same as value of rdn-identifier attribute. > It can cause issues when ldap-realm is used for authentication and another realm is used for authorization since data for realm authorization can depend on assigned name during authentication. > Example: > It seems that ldap-realm cannot be configured for following scenario: User with credentials {{someUser}}/{{Password}} is authenticated and name {{AuthenticatedUser}} is assigned to them (e.g. when calling {{./jboss-cli.sh -c -u=someUser -p=Password ':whoami'}}, then {{AuthenticatedUser}} should be printed). Following ldif is used: > {code} > dn: ou=People,dc=jboss,dc=org > objectclass: top > objectclass: organizationalUnit > ou: People > dn: uid=someUser,ou=People,dc=jboss,dc=org > objectclass: top > objectclass: person > objectclass: inetOrgPerson > uid: someUser > cn: some User > sn: AuthenticatedUser > userPassword: Password > {code} > Mentioned ldif works correctly with legacy security solution. > This missing feature can cause that migration from legacy security solution will not be possible -> we request blocker. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-857) Elytron ldap-realm is not able to use LDAP attribute as principal

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-857?page=com.atlassian.jira.plugin.sy... ] Jan Kalina commented on ELY-857: -------------------------------- Ok, will add it as LdapRealm feature - configuration of attribute, which will be user principal. > Elytron ldap-realm is not able to use LDAP attribute as principal > ----------------------------------------------------------------- > > Key: ELY-857 > URL: https://issues.jboss.org/browse/ELY-857 > Project: WildFly Elytron > Issue Type: Bug > Components: Realms > Affects Versions: 1.1.0.Beta16 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Blocker > > In Elytron ldap-realm is currently not possible to obtain username from LDAP attribute which is different than rdn-identifier. It means that username of identity is always the same as value of rdn-identifier attribute. > It can cause issues when ldap-realm is used for authentication and another realm is used for authorization since data for realm authorization can depend on assigned name during authentication. > Example: > It seems that ldap-realm cannot be configured for following scenario: User with credentials {{someUser}}/{{Password}} is authenticated and name {{AuthenticatedUser}} is assigned to them (e.g. when calling {{./jboss-cli.sh -c -u=someUser -p=Password ':whoami'}}, then {{AuthenticatedUser}} should be printed). Following ldif is used: > {code} > dn: ou=People,dc=jboss,dc=org > objectclass: top > objectclass: organizationalUnit > ou: People > dn: uid=someUser,ou=People,dc=jboss,dc=org > objectclass: top > objectclass: person > objectclass: inetOrgPerson > uid: someUser > cn: some User > sn: AuthenticatedUser > userPassword: Password > {code} > Mentioned ldif works correctly with legacy security solution. > This missing feature can cause that migration from legacy security solution will not be possible -> we request blocker. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2017