September 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1795) :query() operation fails with IllegalArgumentException when specifying a where parameter

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1795?page=com.atlassian.jira.plugi... ] Jean-Francois Denise resolved WFCORE-1795. ------------------------------------------ Fix Version/s: 3.0.0.Alpha8 Resolution: Done > :query() operation fails with IllegalArgumentException when specifying a where parameter > ---------------------------------------------------------------------------------------- > > Key: WFCORE-1795 > URL: https://issues.jboss.org/browse/WFCORE-1795 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI, Domain Management > Reporter: Harald Pehl > Assignee: Jean-Francois Denise > Fix For: 3.0.0.Alpha8 > > > This operation works in WFLY 10: > {code} > /host=*/server=*:query(select=["name"],where={"server-group" = "main-server-group"}) > {code} > whereas it fails with an IllegalArgumentException in WFLY 11 > Without the {{where}} parameter the operation works. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-649) Make the exists and create methods on HttpScope default

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-649: ------------------------------------ Summary: Make the exists and create methods on HttpScope default Key: ELY-649 URL: https://issues.jboss.org/browse/ELY-649 Project: WildFly Elytron Issue Type: Enhancement Components: API / SPI, HTTP Reporter: Darran Lofthouse Assignee: Darran Lofthouse Priority: Blocker Fix For: 1.1.0.Beta10 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1838) Upgrade to Elytron Web 1.0.0.Beta4

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-1838: ---------------------------------------- Summary: Upgrade to Elytron Web 1.0.0.Beta4 Key: WFCORE-1838 URL: https://issues.jboss.org/browse/WFCORE-1838 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Alpha9 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1837) Upgrade to WildFly Elytron 1.1.0.Beta10

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-1837: ---------------------------------------- Summary: Upgrade to WildFly Elytron 1.1.0.Beta10 Key: WFCORE-1837 URL: https://issues.jboss.org/browse/WFCORE-1837 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Alpha9 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-648) Release WildFly Elytron 1.1.0.Beta10

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-648: ------------------------------------ Summary: Release WildFly Elytron 1.1.0.Beta10 Key: ELY-648 URL: https://issues.jboss.org/browse/ELY-648 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta10 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2098: -------------------------------- I added attribute {{max_rank_to_reply}} to {{Discovery}}. If {{TP.use_ip_addrs}} is enabled and the rank is higher than {{max_rank_to_reply}}, then a member won't send a discovery response. This is implemented in {{PING}} and {{TCPPING}}. > Discovery: reduce messages when IpAddressUUID is used > ----------------------------------------------------- > > Key: JGRP-2098 > URL: https://issues.jboss.org/browse/JGRP-2098 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > Attachments: LESS_PING.java > > > Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase. > Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID. > Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-646) Unable to setup CLIENT_CERT authentication with elytron.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-646?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse reassigned ELY-646: ------------------------------------ Assignee: Jan Kalina (was: Darran Lofthouse) > Unable to setup CLIENT_CERT authentication with elytron. > -------------------------------------------------------- > > Key: ELY-646 > URL: https://issues.jboss.org/browse/ELY-646 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Blocker > > Following Zach's notes on [How to setup 2 way TLS|https://gitlab.cee.redhat.com/zrhoads/kbase/blob/master/eap71.elytron...] I am unable to setup it properly. User is not requested by browser for specifying client certificate and get access to application without certificate. > In log you there is: > 1. Server send request for certificate > {code} > ^[[0m^[[0m13:55:33,309 INFO [stdout] (default task-1) *** CertificateRequest > ^[[0m^[[0m13:55:33,309 INFO [stdout] (default task-1) Cert Types: RSA, DSS, ECDSA > ^[[0m^[[0m13:55:33,309 INFO [stdout] (default task-1) Cert Authorities: > ^[[0m^[[0m13:55:33,310 INFO [stdout] (default task-1) <CN=client> > {code} > 2. And client responds with empty certificate chain. Without asking for certificate > {code} > ^[[0m^[[0m13:55:33,432 INFO [stdout] (default task-2) *** Certificate chain > ^[[0m^[[0m13:55:33,432 INFO [stdout] (default task-2) <Empty> > ^[[0m^[[0m13:55:33,432 INFO [stdout] (default task-2) *** > {code} > I am attaching: > * server.log - server log with -Djavax.net.debug=all turn on. > * 2wayTLS.pcap - wireshark recording of port 8443 > * secured-app - tested application -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7226) Missing realm-map attribute for mapped-regex-realm-mapper throws IllegalArgumentException to server log

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7226?page=com.atlassian.jira.plugin.... ] Jan Kalina commented on WFLY-7226: ---------------------------------- No need to worry, this required only trivial fix of resource definition. > Missing realm-map attribute for mapped-regex-realm-mapper throws IllegalArgumentException to server log > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-7226 > URL: https://issues.jboss.org/browse/WFLY-7226 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > > In case when mapped-regex-realm-mapper is added through CLI and realm-map attribute is not used then IllegalArgumentException is thrown to server log instead of some CLI failure message like "realm-map may not be null". > Expcetion in server log: > {code} > ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("mapped-regex-realm-mapper" => "MappedRealmMapper") > ]): java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:139) > at org.jboss.dmr.ModelNode.keys(ModelNode.java:1378) > at org.wildfly.extension.elytron.RealmMapperDefinitions$MappedRegexRealmMapperAddHandler.performRuntime(RealmMapperDefinitions.java:221) > at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337) > at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7226) Missing realm-map attribute for mapped-regex-realm-mapper throws IllegalArgumentException to server log

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7226?page=com.atlassian.jira.plugin.... ] Jan Kalina edited comment on WFLY-7226 at 9/29/16 6:16 AM: ----------------------------------------------------------- [~ivassile] No need to worry, this required only trivial fix of resource definition. was (Author: honza889): No need to worry, this required only trivial fix of resource definition. > Missing realm-map attribute for mapped-regex-realm-mapper throws IllegalArgumentException to server log > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-7226 > URL: https://issues.jboss.org/browse/WFLY-7226 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > > In case when mapped-regex-realm-mapper is added through CLI and realm-map attribute is not used then IllegalArgumentException is thrown to server log instead of some CLI failure message like "realm-map may not be null". > Expcetion in server log: > {code} > ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("mapped-regex-realm-mapper" => "MappedRealmMapper") > ]): java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:139) > at org.jboss.dmr.ModelNode.keys(ModelNode.java:1378) > at org.wildfly.extension.elytron.RealmMapperDefinitions$MappedRegexRealmMapperAddHandler.performRuntime(RealmMapperDefinitions.java:221) > at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337) > at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1641) CLI, completion for more than one header is not working

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1641?page=com.atlassian.jira.plugi... ] Jean-Francois Denise resolved WFCORE-1641. ------------------------------------------ Fix Version/s: 3.0.0.Alpha6 Resolution: Done > CLI, completion for more than one header is not working > ------------------------------------------------------- > > Key: WFCORE-1641 > URL: https://issues.jboss.org/browse/WFCORE-1641 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > Fix For: 3.0.0.Alpha6 > > > This can't be fixed until https://issues.jboss.org/browse/AESH-386 is fixed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2016