October 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7288) Elytron - inconsistency between DMR and XSD representation of ldap-realm

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7288?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7288: ------------------------------- Affects Version/s: 11.0.0.Alpha1 > Elytron - inconsistency between DMR and XSD representation of ldap-realm > ------------------------------------------------------------------------ > > Key: WFLY-7288 > URL: https://issues.jboss.org/browse/WFLY-7288 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Optional > > There are inconsistencies between DMR and XSD representation of ldap-realm. > * According to XSD [1] {{from}} attribute from user-password-mapper is required in ldap-realm. According to DMR {{from}} attribute is {{"nillable" => true}}. > * According to XSD [2] every attribute ({{algorithm-from}}, {{hash-from}}, {{seed-from}}, {{sequence-from}}) from otp-credential-mapper is required in ldap-realm. According to DMR all these attributes are {{"nillable" => true}}. > * According to XSD [3] {{name}} of {{attribute}} from new-identity-attributes is required in ldap-realm. According to DMR {{name}} of {{attribute}} is {{"nillable" => true}}. > These inconsistencies should be unified. > [1] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c8... > [2] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c8... > [3] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c8... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7287) User should be able to specify only one password mapper in jdbc-realm resource

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7287?page=com.atlassian.jira.plugin.... ] Martin Choma moved JBEAP-6384 to WFLY-7287: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7287 (was: JBEAP-6384) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: 11.0.0.Alpha1 (was: 7.1.0.DR6) > User should be able to specify only one password mapper in jdbc-realm resource > ------------------------------------------------------------------------------ > > Key: WFLY-7287 > URL: https://issues.jboss.org/browse/WFLY-7287 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Pedro Igor > Priority: Minor > > It is possible to specify in {{principal-query}} all of {{clear-password-mapper}}, {{bcrypt-mapper}}, {{simple-digest-mapper}}, {{salted-simple-digest-mapper}}, {{scram-mapper}} at one moment. But, in fact, specifying only one mapper per principal query make sense. Change model/subsystem , that only adding on password mapper at a moment is allowed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7286) Elytron - inconsistency between DMR and XSD representation of mechanism-provider-filtering-sasl-server-factory

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7286?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7286: ------------------------------- Affects Version/s: 11.0.0.Alpha1 > Elytron - inconsistency between DMR and XSD representation of mechanism-provider-filtering-sasl-server-factory > -------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7286 > URL: https://issues.jboss.org/browse/WFLY-7286 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Optional > > There is an inconsistency between DMR and XSD representation of {{mechanism-provider-filtering-sasl-server-factory}}. > According to XSD [1] {{filters}} may not occur in {{mechanism-provider-filtering-sasl-server-factory}}. According to DMR {{filters}} is {{"nillable" => false}}. This should be unified. > [1] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c8... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7286) Elytron - inconsistency between DMR and XSD representation of mechanism-provider-filtering-sasl-server-factory

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-7286: ---------------------------------- Summary: Elytron - inconsistency between DMR and XSD representation of mechanism-provider-filtering-sasl-server-factory Key: WFLY-7286 URL: https://issues.jboss.org/browse/WFLY-7286 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Optional There is an inconsistency between DMR and XSD representation of {{mechanism-provider-filtering-sasl-server-factory}}. According to XSD [1] {{filters}} may not occur in {{mechanism-provider-filtering-sasl-server-factory}}. According to DMR {{filters}} is {{"nillable" => false}}. This should be unified. [1] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c8... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7285) Elytron - inconsistency between DMR and XSD representation of simple-permission-mapper

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7285?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7285: ------------------------------- Affects Version/s: 11.0.0.Alpha1 > Elytron - inconsistency between DMR and XSD representation of simple-permission-mapper > -------------------------------------------------------------------------------------- > > Key: WFLY-7285 > URL: https://issues.jboss.org/browse/WFLY-7285 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Optional > > There are inconsistencies between DMR and XSD representation of {{simple-permission-mapper}}. > According to XSD both {{permission-mapping}} [1] and its inner {{permission}} [2] must occur at least one times in {{simple-permission-mapper}}. According to DMR they are {{"nillable" => true}}. This should be unified. > [1] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c8... > [2] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c8... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2110) Transport: revisit buffers and threading

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2110?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2110: -------------------------------- Moving the parsing to the thread pool did *not* improve performance (UPerf, IspnPerfTest on cluster01-04). As a matter of fact, performance dropped slightly (~3-5%, with TCP)! Next step: use a buffer pool and refer to the buffer from Message.buf (+offset +length). Release the buffer when the message has been delivered. Complication for MessageBatch: release the buffer when all batches (read from a message list) have been delivered. > Transport: revisit buffers and threading > ---------------------------------------- > > Key: JGRP-2110 > URL: https://issues.jboss.org/browse/JGRP-2110 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > (Concerns only the receiver side) > h4. Parsing > Currently, parsing is done on the thread which received the message (or message batch) and then the message is passed on to the thread pool. One could argue that the parsing should be done on the thread from the thread pool, and the receiver thread should only fill the buffer and pass it to the thread pool immediately, without doing any parsing, as this might slow it down. > This actually used to be the model which JGroups used, but I abandoned it because (1) performance (IspnPerfTest and UPerf) was the same and (2) we could get rid of a buffer copy (more on this below). > h4. Buffers > * UDP has a fixed buffer of 65K. A datagram packet is read into this buffer and then parsed and passed to the thread pool, allowing the buffer to be reused for the next message. > * TCP: each connection has a buffer which grows according to the length sent in the header of a message. This buffer doesn't need to be copied when passed up the stack, until receive() returns > * TCP_NIO2: each connection also has a buffer which is reused after receive(), but if the read is not complete, is copied. > h4. Approaches > # The receiver thread parses the buffer into a message and passes the message to the thread pool for processing. This requires memory allocation (the new message and its payload buffer). This is the current approach. Parsing the buffer into a message might slow things down as message creation requires memory allocation. > # The receiver thread passes the buffer on to the thread pool where it is parsed. The advantage is that the receiver thread is immediately ready to receive new messages. The disadvantage is that this is 1x memory allocation for the message (as above), although done on a seperate thread, plus 1x memory allocation for copying of the buffer to reuse the original buffer (where necessary, depending on the transport). This was the old way of handling incoming messages. > # UDP: it is possible for the socket receive() method to be called by multiple threads. We could therefore create multiple receiver threads in UDP, to speed things up. > # To prevent memory allocation of the approaches above, we could create a buffer pool. The receiver thread grabs a buffer from the pool (the pool creates a new one when empty?) and fills it with the socket's receive() method, then passes the buffer to the thread pool for processing. If the message's payload buffer points to the original buffer (from the buffer pool), the thread from the thread pool returns the buffer to the buffer pool as soon as the {{receive()}} callback returns, otherwise it returns it as soon as the message has been parsed. > h4. Goals > Prototype approaches 2, 3 and 4 and benchmark them against each other, using UPerf and IspnPerfTest. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7285) Elytron - inconsistency between DMR and XSD representation of simple-permission-mapper

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-7285: ---------------------------------- Summary: Elytron - inconsistency between DMR and XSD representation of simple-permission-mapper Key: WFLY-7285 URL: https://issues.jboss.org/browse/WFLY-7285 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Optional There are inconsistencies between DMR and XSD representation of {{simple-permission-mapper}}. According to XSD both {{permission-mapping}} [1] and its inner {{permission}} [2] must occur at least one times in {{simple-permission-mapper}}. According to DMR they are {{"nillable" => true}}. This should be unified. [1] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c8... [2] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c8... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7284) group-properties can be added without path in Elytron properties-realm which results to invalid server configuration

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-7284: ---------------------------------- Summary: group-properties can be added without path in Elytron properties-realm which results to invalid server configuration Key: WFLY-7284 URL: https://issues.jboss.org/browse/WFLY-7284 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Adding {{groups-properties}} without {{path}} through CLI is allowed by Elytron subsystem which results to XMLStreamException after server is reloaded/restarted. Exception in server log after reload/restart: {code} ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) at org.jboss.as.server.ServerService.boot(ServerService.java:355) at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:302) at java.lang.Thread.run(Thread.java:745) Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[345,21] Message: WFLYCTL0133: Missing required attribute(s): path at org.jboss.as.controller.parsing.ParseUtils.missingRequired(ParseUtils.java:180) at org.wildfly.extension.elytron.RealmParser.readFileAttributes(RealmParser.java:522) at org.wildfly.extension.elytron.RealmParser.readPropertiesRealm(RealmParser.java:337) at org.wildfly.extension.elytron.RealmParser.readRealms(RealmParser.java:118) at org.wildfly.extension.elytron.ElytronSubsystemParser.readElement(ElytronSubsystemParser.java:114) at org.wildfly.extension.elytron.ElytronSubsystemParser.readElement(ElytronSubsystemParser.java:72) at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69) at org.jboss.as.server.parsing.StandaloneXml_5.parseServerProfile(StandaloneXml_5.java:591) at org.jboss.as.server.parsing.StandaloneXml_5.readServerElement(StandaloneXml_5.java:245) at org.jboss.as.server.parsing.StandaloneXml_5.readElement(StandaloneXml_5.java:144) at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:49) at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) ... 3 more FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7284) group-properties can be added without path in Elytron properties-realm which results to invalid server configuration

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7284?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7284: ------------------------------- Affects Version/s: 11.0.0.Alpha1 > group-properties can be added without path in Elytron properties-realm which results to invalid server configuration > -------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7284 > URL: https://issues.jboss.org/browse/WFLY-7284 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > Adding {{groups-properties}} without {{path}} through CLI is allowed by Elytron subsystem which results to XMLStreamException after server is reloaded/restarted. > Exception in server log after reload/restart: > {code} > ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) > at org.jboss.as.server.ServerService.boot(ServerService.java:355) > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:302) > at java.lang.Thread.run(Thread.java:745) > Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[345,21] > Message: WFLYCTL0133: Missing required attribute(s): path > at org.jboss.as.controller.parsing.ParseUtils.missingRequired(ParseUtils.java:180) > at org.wildfly.extension.elytron.RealmParser.readFileAttributes(RealmParser.java:522) > at org.wildfly.extension.elytron.RealmParser.readPropertiesRealm(RealmParser.java:337) > at org.wildfly.extension.elytron.RealmParser.readRealms(RealmParser.java:118) > at org.wildfly.extension.elytron.ElytronSubsystemParser.readElement(ElytronSubsystemParser.java:114) > at org.wildfly.extension.elytron.ElytronSubsystemParser.readElement(ElytronSubsystemParser.java:72) > at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) > at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69) > at org.jboss.as.server.parsing.StandaloneXml_5.parseServerProfile(StandaloneXml_5.java:591) > at org.jboss.as.server.parsing.StandaloneXml_5.readServerElement(StandaloneXml_5.java:245) > at org.jboss.as.server.parsing.StandaloneXml_5.readElement(StandaloneXml_5.java:144) > at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) > at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:49) > at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) > at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) > ... 3 more > FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1268) When using the RuleServicesClient for a remote rest interface, get the following error java.io.EOFException: No content to map to Object due to end of input

by Maciej Swiderski (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1268?page=com.atlassian.jira.plugi... ] Maciej Swiderski commented on DROOLS-1268: ------------------------------------------ any update on this or we can close it? > When using the RuleServicesClient for a remote rest interface, get the following error java.io.EOFException: No content to map to Object due to end of input > ------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-1268 > URL: https://issues.jboss.org/browse/DROOLS-1268 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 6.4.0.Final > Reporter: Nicolas Heron > Assignee: Maciej Swiderski > Labels: OnBoarding > Attachments: logerror.txt, picture1.png > > > here is the JSON http://pastebin.com/t1CdHg9F > The logs are in the file attached logerror.txt > Going further > the error comes from class org.kie.remote.common.rest.KieRemoteHttpRequest line 1329 > and the error behind is "not enough data" > I put in attachement and it seems true -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 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 October 2016