October 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-94) Add -secmgr to startup scripts and propagate -secmgr through the domain

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-94?page=com.atlassian.jira.plugin.... ] James Perkins updated WFCORE-94: -------------------------------- Summary: Add -secmgr to startup scripts and propagate -secmgr through the domain (was: Add MODULE_OPTS to startup scripts and propagate -secmgr through the domain) > Add -secmgr to startup scripts and propagate -secmgr through the domain > ----------------------------------------------------------------------- > > Key: WFCORE-94 > URL: https://issues.jboss.org/browse/WFCORE-94 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Scripts > Reporter: Kabir Khan > Assignee: James Perkins > Fix For: 1.0.0.Alpha9 > > > The preferred mechanism to enable a security manager is to use the -secmgr module option. Modify the scripts to make this easier to add, and make adjustments to propagate this through the domain. > The -secmgr module option is not visible from the launched process, so for the process controller and host controller to pass that on to the started host controller or server process respectively, a check is added to see if a security manager was enabeld. If a security manager is enabled, and -Djava.security.manager is not present in the system properties, we add the -secmgr module option when starting the next process. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3932) Enable security manager via JBoss Modules

by James Perkins (JIRA)

James Perkins created WFLY-3932: ----------------------------------- Summary: Enable security manager via JBoss Modules Key: WFLY-3932 URL: https://issues.jboss.org/browse/WFLY-3932 Project: WildFly Issue Type: Feature Request Components: Security Manager Reporter: James Perkins Assignee: James Perkins In WildFly Core the security manager can be enabled via the {{-secmgr}} argument or setting the {{SECMGR=true}} environment variable. In order for this change to work correctly the {{WildFlySecurityManager.install()}} needs to be disabled. Also all modules that declare a dependency on {{org.wildfly.security.manager}} need to export the services. Tests need to be updated to use the {{-secmgr}} argument rather than {{-Djava.security.manager}}. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1332) Integrate the compressed message support that was introduced in EJB client library

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1332?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-1332: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1149020, https://bugzilla.redhat.com/show_bug.cgi?id=1149023 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1149020) > Integrate the compressed message support that was introduced in EJB client library > ---------------------------------------------------------------------------------- > > Key: WFLY-1332 > URL: https://issues.jboss.org/browse/WFLY-1332 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: jaikiran pai > Assignee: jaikiran pai > Fix For: 8.0.0.Alpha2 > > > https://issues.jboss.org/browse/EJBCLIENT-76 introduced a feature where the message stream that contains the EJB protocol message can be compressed. This involves a new message header which the server needs to support for the compression to be functional. This JIRA tracks the server side additions to support this feature. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1332) Integrate the compressed message support that was introduced in EJB client library

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1332?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-1332: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1149020 > Integrate the compressed message support that was introduced in EJB client library > ---------------------------------------------------------------------------------- > > Key: WFLY-1332 > URL: https://issues.jboss.org/browse/WFLY-1332 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: jaikiran pai > Assignee: jaikiran pai > Fix For: 8.0.0.Alpha2 > > > https://issues.jboss.org/browse/EJBCLIENT-76 introduced a feature where the message stream that contains the EJB protocol message can be compressed. This involves a new message header which the server needs to support for the compression to be functional. This JIRA tracks the server side additions to support this feature. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3925) JAX-RS bean implemented as Stateless is destroyed after response

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3925?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-3925: -------------------------------------- Unfortunately it is impossible to provide a 'reasonable' default, as what is reasonable for one app will be a massive performance bottleneck on others. Also modern JVM GC is much better than in the past, depending on the EJB (and if it does any expensive initialisation) allocation+GC can actually be cheaper than pooling (as pooling uses locks / atomics, which are relatively expensive). > JAX-RS bean implemented as Stateless is destroyed after response > ---------------------------------------------------------------- > > Key: WFLY-3925 > URL: https://issues.jboss.org/browse/WFLY-3925 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.1.0.Final > Reporter: Sergio Samayoa > Assignee: Jason Greene > > A JAX-RS bean implemented as stateless EJB is destroyed after response is sent. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3931) Custom formatter property changes not written to, but overriden by logging.properties

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-3931?page=com.atlassian.jira.plugin.... ] James Perkins updated WFLY-3931: -------------------------------- Workaround Description: Use the CLI {{write-attribute}} operation to write new properties. > Custom formatter property changes not written to, but overriden by logging.properties > ------------------------------------------------------------------------------------- > > Key: WFLY-3931 > URL: https://issues.jboss.org/browse/WFLY-3931 > Project: WildFly > Issue Type: Bug > Components: Logging > Affects Versions: 8.1.0.Final > Environment: Wildfly 8.1.0.Final > Reporter: Vsevolod Golovanov > Assignee: James Perkins > > When you first add custom formatter with properties to standalone.xml, on server start property values get correctly resolved and written to logging.properties. > If you change property values in standalone.xml of an existing custom formatter, that was flushed to logging.properties before, then on the next server start new values don't get written to logging.properties and formatter instance gets the old values from logging.properties. > For properties with static values that are defined in standalone.xml there is a workaround: change the custom formatter name each time you change a property value. > But with more dynamic properties, e.g. that rely on system properties, it's not so simple... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-43) Clean up Base64

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-43?page=com.atlassian.jira.plugin.sys... ] David Lloyd commented on ELY-43: -------------------------------- I think that the benefits of Jason's implementation are on the micro-optimization scale. If we have to construct byte arrays and copy, we've lost that benefit in spades. Mostly I just thought you'd find it interesting. :) [~jason.greene] might have more input as he mainly implemented his version because he thought it was interesting. Unrelatedly, I think it would be nice if we could get to a point where there's just one base 64 implementation across all of the WildFly project family which has all of the various capabilities we need. However this isn't possible without adding a dependency (on wildfly-common perhaps?) to Elytron (and of course moving this stuff there) - which is something [~dlofthouse] would have to comment on. End rambling brain dump > Clean up Base64 > --------------- > > Key: ELY-43 > URL: https://issues.jboss.org/browse/ELY-43 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Utils > Reporter: Darran Lofthouse > Assignee: Farah Juma > Fix For: 1.0.0.Beta1 > > > The Base64 implementation has been split out of PasswordUtils some additional steps are needed to finish cleaning it up: - > - Look at switching to input and output streams instead of the custom iterators it is using. > - Consider the ByteStringBuilder from SASL > - As potentially more visible ensure clearer method names. > - Ensure adequate javadoc and cross referencing of standards supported. > e.g. If we implement an RFC ensure the number is referenced. > - Testing of each variant > - Consider optional support, e.g. decoding a padded String > - Go beyond testing we can decode what we encode and ensure pre-encoded values can be handled adequately. > Any other clean up here that seems relevant. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-43) Clean up Base64

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/ELY-43?page=com.atlassian.jira.plugin.sys... ] Farah Juma commented on ELY-43: ------------------------------- Took a look at the FlexBase64 implementation. We could replace the existing Base64 implementation with this one but we'd need to make at least the following modifications to it: \\ \\ * Add support for the bcrypt and modular crypt alphabets (it currently supports the standard Base64 alphabet and a URL-safe variant of Base64) * Add methods for encoding/decoding with an interleave table using the modular crypt style little-endian scheme * Add methods for encoding/decoding a single byte * Add a method for decoding an encoded character array To get an idea of how this would change usage, consider the following examples: 1) Using the Base64 implementation, encoding a byte array, {{src}}, using the bcrypt alphabet and appending the result to a StringBuilder, {{b}}, is currently done like this: {code}Base64.base64EncodeBCrypt(b, new ByteArrayInputStream(src));{code} With a modified version of {{FlexBase64}}, the above might be done like this: {code}b.append(FlexBase64.encodeString(src, false, FlexBase64.BCRYPT));{code} 2) Using the Base64 implementation, decoding a character array, {{encoded}}, into a byte array, {{bytes}}, using the standard alphabet, is currently done like this: {code}byte[] bytes = Base64.base64DecodeStandard(encoded, 0){code} With a modified version of {{FlexBase64}}, the above might look like this: {code} ByteBuffer b = FlexBase64.decode(encoded, 0, encoded.length, FlexBase64.STANDARD); byte[] bytes = new byte[b.limit()]; b.get(bytes) {code} Any thoughts on this? > Clean up Base64 > --------------- > > Key: ELY-43 > URL: https://issues.jboss.org/browse/ELY-43 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Utils > Reporter: Darran Lofthouse > Assignee: Farah Juma > Fix For: 1.0.0.Beta1 > > > The Base64 implementation has been split out of PasswordUtils some additional steps are needed to finish cleaning it up: - > - Look at switching to input and output streams instead of the custom iterators it is using. > - Consider the ByteStringBuilder from SASL > - As potentially more visible ensure clearer method names. > - Ensure adequate javadoc and cross referencing of standards supported. > e.g. If we implement an RFC ensure the number is referenced. > - Testing of each variant > - Consider optional support, e.g. decoding a padded String > - Go beyond testing we can decode what we encode and ensure pre-encoded values can be handled adequately. > Any other clean up here that seems relevant. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-94) Add MODULE_OPTS to startup scripts and propagate -secmgr through the domain

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFCORE-94?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFCORE-94: ----------------------------------- One other thing. The -Dsecurity.manager build/test profile will have to be redone (again) to go back to the -secmgr flag behavior, and the default profile will have to be changed to always include the security manager subsystem. > Add MODULE_OPTS to startup scripts and propagate -secmgr through the domain > --------------------------------------------------------------------------- > > Key: WFCORE-94 > URL: https://issues.jboss.org/browse/WFCORE-94 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Scripts > Reporter: Kabir Khan > Assignee: James Perkins > Fix For: 1.0.0.Alpha9 > > > The preferred mechanism to enable a security manager is to use the -secmgr module option. Modify the scripts to make this easier to add, and make adjustments to propagate this through the domain. > The -secmgr module option is not visible from the launched process, so for the process controller and host controller to pass that on to the started host controller or server process respectively, a check is added to see if a security manager was enabeld. If a security manager is enabled, and -Djava.security.manager is not present in the system properties, we add the -secmgr module option when starting the next process. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3832) Upgrade JBMETA to 8.0.1.Final

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3832?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3832: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1139626|https://bugzilla.redhat.com/show_bug.cgi?id=1139626] from POST to MODIFIED > Upgrade JBMETA to 8.0.1.Final > ----------------------------- > > Key: WFLY-3832 > URL: https://issues.jboss.org/browse/WFLY-3832 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Bartosz Baranowski > Assignee: Jason Greene > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 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 2014