September 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1364) Elytron BEARER_TOKEN HTTP authentication mechanism doesn't send WWW-Authenticate header

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1364?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1364: ---------------------------------- Fix Version/s: 1.2.0.Beta4 (was: 1.2.0.Beta3) > Elytron BEARER_TOKEN HTTP authentication mechanism doesn't send WWW-Authenticate header > --------------------------------------------------------------------------------------- > > Key: ELY-1364 > URL: https://issues.jboss.org/browse/ELY-1364 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Affects Versions: 1.1.2.CR1 > Reporter: Pedro Igor > Assignee: Pedro Igor > Fix For: 1.1.3.CR1, 1.2.0.Beta4 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1354) Increment WildFly Elytron schema version for client configuration updates

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1354?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1354: ---------------------------------- Fix Version/s: 1.2.0.Beta4 (was: 1.2.0.Beta3) > Increment WildFly Elytron schema version for client configuration updates > ------------------------------------------------------------------------- > > Key: ELY-1354 > URL: https://issues.jboss.org/browse/ELY-1354 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.2.0.Beta4 > > > At the same time we need to review how we handle supporting multiple versions. > On one hand we can look at making our parser fairly permissive so if we are just adding it can support both old and new, the biggest advantage here is we can minimise code duplication. > The down side however is in the future it becomes very difficult to reverse and remove support for older schema. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1366) Release WildFly Elytron 1.2.0.Beta3

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1366?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse resolved ELY-1366. ----------------------------------- Resolution: Done > Release WildFly Elytron 1.2.0.Beta3 > ----------------------------------- > > Key: ELY-1366 > URL: https://issues.jboss.org/browse/ELY-1366 > Project: WildFly Elytron > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.2.0.Beta3 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1364) Elytron BEARER_TOKEN HTTP authentication mechanism doesn't send WWW-Authenticate header

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1364?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1364: ---------------------------------- Fix Version/s: 1.1.3.CR1 (was: 1.1.2.Final) > Elytron BEARER_TOKEN HTTP authentication mechanism doesn't send WWW-Authenticate header > --------------------------------------------------------------------------------------- > > Key: ELY-1364 > URL: https://issues.jboss.org/browse/ELY-1364 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Affects Versions: 1.1.2.CR1 > Reporter: Pedro Igor > Assignee: Pedro Igor > Fix For: 1.1.3.CR1, 1.2.0.Beta3 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1365) Release WildFly Elytron 1.1.2.Final

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1365?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse resolved ELY-1365. ----------------------------------- Resolution: Done > Release WildFly Elytron 1.1.2.Final > ----------------------------------- > > Key: ELY-1365 > URL: https://issues.jboss.org/browse/ELY-1365 > Project: WildFly Elytron > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.2.CR2 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2218) New buffers

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2218?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2218: --------------------------- Description: h3. Goal Change payload in {{Message}} from byte[] arrays to a {{Buffer}} interface which can have multiple implementations. h3. Motivation Currently, having to pass a byte[] array to a message leads to unnecessary copying: * When an application has a ref to an NIO (direct) {{ByteBuffer}}, the bytes in the byte buffer have to be copied into a byte[] array and then set in the message * When the application sends around byte[] arrays, but also wants to add some additional metadata, e.g. type (1000-byte requests/responses), it needs to create a new byte[] array of (say) 1001 bytes and copy the data (1000 bytes) plus the request type (1 byte) into the new copy. Example: {{MPerf}} and {{UPerf}} h3. Design Instead of copying, the application creates an instance of {{Buffer}} and sets the buffer in {{Message}}. The {{Buffer}} is then passed all the way down into the transport where it is marshalled and sent. There can be a number of buffer implementations, e.g. * {{ArrayBuffer}}: wraps a byte[] array with an offset and length * {{NioDirectBuffer}}: wraps an NIO direct {{ByteBuffer}} * {{NioHeapBuffer}}: wraps an NIO heap-based {{ByteBuffer}} * {{CompositeBuffer}}: wraps multiple Buffers. E.g. type (1 byte) and data (1000 bytes) as described above * {{IntBuffer}}: a single integer * {{ObjectBuffer}}: has an Object and a ClassLoader (for reading), plus a Marshaller which know how to marshal the object, this allows for objects to be passed in buffers and they're only marshalled at the end (transport). * {{PartialBuffer}}: a ref to a {{Buffer}}, with an offset and length The {{Buffer}} interface has methods: * {{size()}} * {{writeTo(DataOutput)}} * {{readFrom(DataInput)}} * {{getInput()}}: this provides a {{DataInput}} stream for reading from the underlying buffer and possibly also * {{acquire()}} and * {{release()}} (for ref-counting). Each buffer impl has an ID and it should be possible to register new impls. A {{BufferFactory}} maintains a mapping between IDs and impl classes. When marshalling a {{Buffer}}, the ID is written first, followed by the buffer's {{writeTo()}} method. When reading buffers, the {{BufferFactory}} is used to create instances from IDs. h4. Fragmentation When fragmenting a buffer, the fragments are instances of {{PartialBuffer}} which maintains an offset and length over an underlying buffer. When marshalling a {{PartialBuffer}}, only the part between offset and offset+length is written to the output stream. h4. Reference counting If we implement ref-counting, then buffers can be reused as soon as the ref-count is 0. For example, when sending a message, the buffer's ref-count could be incremented by the app calling {{acquire()}}. (Assuming the message is a unicast message), {{UNICAST3}} would increment the count to 2. This is needed because {{UNICAST3}} might have to retransmit the message if it was lost on the network, and meanwhile the buffer cannot be reused (changed). The app calls {{release()}} when the {{JChannel.send()}} call returns, but the buffer cannot be reused until {{UNICAST3}} calls {{release()}} as well. This will happen when an {{ACK}} for the given message has been received. h4. Buffer management When a request is received, the buffer is created from the bytes received on the network, based on the ID. This should be done by asking a {{BufferManagement}} (or {{BufferPool}} component for a new buffer. A naive implementation might create a new buffer every time, and more sophisticated one might use a pool of buffers. The {{BufferManagement}} instance could be replaced by one's own implementation; this allows for an application to control the lifecycle of buffers: thus the creation of buffers by the application and of buffers received over the network can be controlled by the same buffer management impl. h4. Misc * Since this issue includes API changes, the version will be 5.0 was: h3. Goal Change payload in {{Message}} from byte[] arrays to a {{Buffer}} interface which can have multiple implementations. h3. Motivation Currently, having to pass a byte[] array to a message leads to unnecessary copying: * When an application has a ref to an NIO (direct) {{ByteBuffer}}, the bytes in the byte buffer have to be copied into a byte[] array and then set in the message * When the application sends around byte[] arrays, but also wants to add some additional metadata, e.g. type (1000-byte requests/responses), it needs to create a new byte[] array of (say) 1001 bytes and copy the data (1000 bytes) plus the request type (1 byte) into the new copy. Example: {{MPerf}} and {{UPerf}} h3. Design Instead of copying, the application creates an instance of {{Buffer}} and sets the buffer in {{Message}}. The {{Buffer}} is then passed all the way down into the transport where it is marshalled and sent. There can be a number of buffer implementations, e.g. * {{ArrayBuffer}}: wraps a byte[] array with an offset and length * {{NioDirectBuffer}}: wraps an NIO direct {{ByteBuffer}} * {{NioHeapBuffer}}: wraps an NIO heap-based {{ByteBuffer}} * {{CompositeBuffer}}: wraps multiple Buffers. E.g. type (1 byte) and data (1000 bytes) as described above * {{IntBuffer}}: a single integer * {{ObjectBuffer}}: has an Object and a ClassLoader (for reading), plus a Marshaller which know how to marshal the object, this allows for objects to be passed in buffers and they're only marshalled at the end (transport). * {{PartialBuffer}}: a ref to a {{Buffer}}, with an offset and length The {{Buffer}} interface has methods: * {{size()}} * {{writeTo(DataOutput)}} * {{readFrom(DataInput)}} * {{getInput()}}: this provides a {{DataInput}} stream for reading from the underlying buffer and possibly also * {{acquire()}} and * {{release()}} (for ref-counting). Each buffer impl has an ID and it should be possible to register new impls. A {{BufferFactory}} maintains a mapping between IDs and impl classes. When marshalling a {{Buffer}}, the ID is written first, followed by the buffer's {{writeTo()}} method. When reading buffers, the {{BufferFactory}} is used to create instances from IDs. h4. Fragmentation When fragmenting a buffer, the fragments are instances of {{PartialBuffer}} which maintains an offset and length over an underlying buffer. When marshalling a {{PartialBuffer}}, only the part between offset and offset+length is written to the output stream. h4. Reference counting If we implement ref-counting, then buffers can be reused as soon as the ref-count is 0. For example, when sending a message, the buffer's ref-count could be incremented by the app calling {{acquire()}}. (Assuming the message is a unicast message), {{UNICAST3}} would increment the count to 2. This is needed because {{UNICAST3}} might have to retransmit the message if it was lost on the network, and meanwhile the buffer cannot be reused (changed). The app calls {{release()}} when the {{JChannel.send()}} call returns, but the buffer cannot be reused until {{UNICAST3}} calls {{release()}} as well. This will happen when an {{ACK}} for the given message has been received. h4. Buffer management When a request is received, the buffer is created from the bytes received on the network, based on the ID. This should be done by asking a {{BufferManagement}} (or {{BufferPool}} component for a new buffer. A naive implementation might create a new buffer every time, and more sophisticated one might use a pool of buffers. The {{BufferManagement}} instance could be replaced by one's own implementation; this allows for an application to control the lifecycle of buffers: thus the creation of buffers by the application and of buffers received over the network can be controlled by the same buffer management impl. > New buffers > ----------- > > Key: JGRP-2218 > URL: https://issues.jboss.org/browse/JGRP-2218 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 5.0 > > > h3. Goal > Change payload in {{Message}} from byte[] arrays to a {{Buffer}} interface which can have multiple implementations. > h3. Motivation > Currently, having to pass a byte[] array to a message leads to unnecessary copying: > * When an application has a ref to an NIO (direct) {{ByteBuffer}}, the bytes in the byte buffer have to be copied into a byte[] array and then set in the message > * When the application sends around byte[] arrays, but also wants to add some additional metadata, e.g. type (1000-byte requests/responses), it needs to create a new byte[] array of (say) 1001 bytes and copy the data (1000 bytes) plus the request type (1 byte) into the new copy. Example: {{MPerf}} and {{UPerf}} > h3. Design > Instead of copying, the application creates an instance of {{Buffer}} and sets the buffer in {{Message}}. The {{Buffer}} is then passed all the way down into the transport where it is marshalled and sent. There can be a number of buffer implementations, e.g. > * {{ArrayBuffer}}: wraps a byte[] array with an offset and length > * {{NioDirectBuffer}}: wraps an NIO direct {{ByteBuffer}} > * {{NioHeapBuffer}}: wraps an NIO heap-based {{ByteBuffer}} > * {{CompositeBuffer}}: wraps multiple Buffers. E.g. type (1 byte) and data (1000 bytes) as described above > * {{IntBuffer}}: a single integer > * {{ObjectBuffer}}: has an Object and a ClassLoader (for reading), plus a Marshaller which know how to marshal the object, this allows for objects to be passed in buffers and they're only marshalled at the end (transport). > * {{PartialBuffer}}: a ref to a {{Buffer}}, with an offset and length > The {{Buffer}} interface has methods: > * {{size()}} > * {{writeTo(DataOutput)}} > * {{readFrom(DataInput)}} > * {{getInput()}}: this provides a {{DataInput}} stream for reading from the underlying buffer > and possibly also > * {{acquire()}} and > * {{release()}} (for ref-counting). > Each buffer impl has an ID and it should be possible to register new impls. A {{BufferFactory}} maintains a mapping between IDs and impl classes. > When marshalling a {{Buffer}}, the ID is written first, followed by the buffer's {{writeTo()}} method. When reading buffers, the {{BufferFactory}} is used to create instances from IDs. > h4. Fragmentation > When fragmenting a buffer, the fragments are instances of {{PartialBuffer}} which maintains an offset and length over an underlying buffer. When marshalling a {{PartialBuffer}}, only the part between offset and offset+length is written to the output stream. > h4. Reference counting > If we implement ref-counting, then buffers can be reused as soon as the ref-count is 0. For example, when sending a message, the buffer's ref-count could be incremented by the app calling {{acquire()}}. (Assuming the message is a unicast message), {{UNICAST3}} would increment the count to 2. This is needed because {{UNICAST3}} might have to retransmit the message if it was lost on the network, and meanwhile the buffer cannot be reused (changed). The app calls {{release()}} when the {{JChannel.send()}} call returns, but the buffer cannot be reused until {{UNICAST3}} calls {{release()}} as well. This will happen when an {{ACK}} for the given message has been received. > h4. Buffer management > When a request is received, the buffer is created from the bytes received on the network, based on the ID. This should be done by asking a {{BufferManagement}} (or {{BufferPool}} component for a new buffer. A naive implementation might create a new buffer every time, and more sophisticated one might use a pool of buffers. > The {{BufferManagement}} instance could be replaced by one's own implementation; this allows for an application to control the lifecycle of buffers: thus the creation of buffers by the application and of buffers received over the network can be controlled by the same buffer management impl. > h4. Misc > * Since this issue includes API changes, the version will be 5.0 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3282) Duplicate record is written in property file when group name set to empty

by Martin Stefanko (JIRA)

Martin Stefanko created WFCORE-3282: --------------------------------------- Summary: Duplicate record is written in property file when group name set to empty Key: WFCORE-3282 URL: https://issues.jboss.org/browse/WFCORE-3282 Project: WildFly Core Issue Type: Bug Components: Scripts Affects Versions: 3.0.2.CR1 Reporter: Martin Stefanko Assignee: Martin Stefanko Duplicate records are registered in mgmt-groups.properties and application-roles.properties if adding user with empty group name as follows. 1. Add user "testuser1" with empty group from add-user.sh. $JBOSS_HOME/bin/add-user.sh -sc ./standalone/configuration -u testuser1 -p RedHat1! -g "" 2. After that, the following record is written in the group property file. - mgmt-groups.properties (application-roles.properties) testuser1= 3. Add user "testuser2" with empty group from add-user.sh. $JBOSS_HOME/bin/add-user.sh -sc ./standalone/configuration -u testuser2 -p RedHat1! -g "" 4. After that, the user records that have empty group will be registered duplicately as below. - mgmt-groups.properties (application-roles.properties) testuser1= testuser2= testuser1= # duplicate record -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3204) Upgrade WildFly Elytron to 1.2.0.Beta3

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3204?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-3204: ------------------------------------- Summary: Upgrade WildFly Elytron to 1.2.0.Beta3 (was: Upgrade WildFly Elytron to 1.2.0.Beta2) > Upgrade WildFly Elytron to 1.2.0.Beta3 > -------------------------------------- > > Key: WFCORE-3204 > URL: https://issues.jboss.org/browse/WFCORE-3204 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 4.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1366) Release WildFly Elytron 1.2.0.Beta3

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-1366: ------------------------------------- Summary: Release WildFly Elytron 1.2.0.Beta3 Key: ELY-1366 URL: https://issues.jboss.org/browse/ELY-1366 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.2.0.Beta3 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1726) Configure XStream security framework

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-1726: ----------------------------------- Summary: Configure XStream security framework Key: DROOLS-1726 URL: https://issues.jboss.org/browse/DROOLS-1726 Project: Drools Issue Type: Enhancement Components: core engine Reporter: Mario Fusco Assignee: Mario Fusco -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 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 September 2017