December 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-749) JBoss AS lifecycle controlling tests

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/WFLY-749?page=com.atlassian.jira.plugin.s... ] Karel Piwko reassigned WFLY-749: -------------------------------- Assignee: (was: Karel Piwko) > JBoss AS lifecycle controlling tests > ------------------------------------ > > Key: WFLY-749 > URL: https://issues.jboss.org/browse/WFLY-749 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Karel Piwko > Fix For: Awaiting Volunteers > > > Create a test suite that uses Arquillian to control JBoss AS 7 lifecycle in a more precise way, that is: > * DomainClient specific controller > * Asynchronous start, stop > * Manual start after modifying a domain configuration > * Monitoring of container and deployment status > * Forced / programmable kill (cleanup to be investigated here though) > Some of the features would require modifications of Arquillian. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7720) Expose generic options for elytron dir-context

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7720?page=com.atlassian.jira.plugin.... ] Martin Choma updated WFLY-7720: ------------------------------- Description: Expose generic options like in case of legacy ldap outbound connection. Users relying on them can't migrate to elytron. As [~tfonteyn] has already [pointed out|https://issues.jboss.org/browse/JBEAP-6480?focusedCommentId=13312043&...] customers use generic options exposed by legacy ldap outbound connection. Here are references to possible properties to be configured * [general properties|http://docs.oracle.com/javase/jndi/tutorial/beyond/env/overvie...] * Service-specific ** e.g. java.naming.ldap.* , for example for [connection pool configuration|http://docs.oracle.com/javase/jndi/tutorial/ldap/connect/co...] * Feature-specific ** e.g. [java.naming.security.sasl.*|http://docs.oracle.com/javase/jndi/tutorial/l...] * Provider-specific ** e.g. com.sun.jndi.ldap.trace.ber AFAICT it is already prepared in elytron, just elytron-subsystem part is missing. {code:title=SimpleDirContextFactoryBuilder.java} // set any additional connection property if (connectionProperties != null) { for (Object key : connectionProperties.keySet()) { Object value = connectionProperties.get(key.toString()); if (value != null) { env.put(key.toString(), value.toString()); } } } {code} was: Expose generic options like in case of legacy ldap outbound connection. Users relying on them can't migrate to elytron. As [~tfonteyn] has already [pointed out|https://issues.jboss.org/browse/JBEAP-6480?focusedCommentId=13312043&...] customers use generic options exposed by legacy ldap outbound connection. Here are references to possible properties to be configured * [list of general properties|http://docs.oracle.com/javase/jndi/tutorial/beyond/env/overvie...] ** Service-specific *** e.g. java.naming.ldap.* , for example for [connection pool configuration|http://docs.oracle.com/javase/jndi/tutorial/ldap/connect/co...] ** Feature-specific *** e.g. [java.naming.security.sasl.*|http://docs.oracle.com/javase/jndi/tutorial/l...] ** Provider-specific *** e.g. com.sun.jndi.ldap.trace.ber AFAICT it is already prepared in elytron, just elytron-subsystem part is missing. {code:title=SimpleDirContextFactoryBuilder.java} // set any additional connection property if (connectionProperties != null) { for (Object key : connectionProperties.keySet()) { Object value = connectionProperties.get(key.toString()); if (value != null) { env.put(key.toString(), value.toString()); } } } {code} > Expose generic options for elytron dir-context > ---------------------------------------------- > > Key: WFLY-7720 > URL: https://issues.jboss.org/browse/WFLY-7720 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Priority: Critical > > Expose generic options like in case of legacy ldap outbound connection. Users relying on them can't migrate to elytron. > As [~tfonteyn] has already [pointed out|https://issues.jboss.org/browse/JBEAP-6480?focusedCommentId=13312043&...] customers use generic options exposed by legacy ldap outbound connection. > Here are references to possible properties to be configured > * [general properties|http://docs.oracle.com/javase/jndi/tutorial/beyond/env/overvie...] > * Service-specific > ** e.g. java.naming.ldap.* , for example for [connection pool configuration|http://docs.oracle.com/javase/jndi/tutorial/ldap/connect/co...] > * Feature-specific > ** e.g. [java.naming.security.sasl.*|http://docs.oracle.com/javase/jndi/tutorial/l...] > * Provider-specific > ** e.g. com.sun.jndi.ldap.trace.ber > > AFAICT it is already prepared in elytron, just elytron-subsystem part is missing. > {code:title=SimpleDirContextFactoryBuilder.java} > // set any additional connection property > if (connectionProperties != null) { > for (Object key : connectionProperties.keySet()) { > Object value = connectionProperties.get(key.toString()); > if (value != null) { > env.put(key.toString(), value.toString()); > } > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7720) Expose generic options for elytron dir-context

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7720?page=com.atlassian.jira.plugin.... ] Martin Choma updated WFLY-7720: ------------------------------- Description: Expose generic options like in case of legacy ldap outbound connection. Users relying on them can't migrate to elytron. As [~tfonteyn] has already [pointed out|https://issues.jboss.org/browse/JBEAP-6480?focusedCommentId=13312043&...] customers use generic options exposed by legacy ldap outbound connection. Here are references to possible properties to be configured * [General properties|http://docs.oracle.com/javase/jndi/tutorial/beyond/env/overvie...] * Service-specific ** e.g. java.naming.ldap.* , for example for [connection pool configuration|http://docs.oracle.com/javase/jndi/tutorial/ldap/connect/co...] * Feature-specific ** e.g. [java.naming.security.sasl.*|http://docs.oracle.com/javase/jndi/tutorial/l...] * Provider-specific ** e.g. com.sun.jndi.ldap.trace.ber AFAICT it is already prepared in elytron, just elytron-subsystem part is missing. {code:title=SimpleDirContextFactoryBuilder.java} // set any additional connection property if (connectionProperties != null) { for (Object key : connectionProperties.keySet()) { Object value = connectionProperties.get(key.toString()); if (value != null) { env.put(key.toString(), value.toString()); } } } {code} was: Expose generic options like in case of legacy ldap outbound connection. Users relying on them can't migrate to elytron. As [~tfonteyn] has already [pointed out|https://issues.jboss.org/browse/JBEAP-6480?focusedCommentId=13312043&...] customers use generic options exposed by legacy ldap outbound connection. Here are references to possible properties to be configured * [general properties|http://docs.oracle.com/javase/jndi/tutorial/beyond/env/overvie...] * Service-specific ** e.g. java.naming.ldap.* , for example for [connection pool configuration|http://docs.oracle.com/javase/jndi/tutorial/ldap/connect/co...] * Feature-specific ** e.g. [java.naming.security.sasl.*|http://docs.oracle.com/javase/jndi/tutorial/l...] * Provider-specific ** e.g. com.sun.jndi.ldap.trace.ber AFAICT it is already prepared in elytron, just elytron-subsystem part is missing. {code:title=SimpleDirContextFactoryBuilder.java} // set any additional connection property if (connectionProperties != null) { for (Object key : connectionProperties.keySet()) { Object value = connectionProperties.get(key.toString()); if (value != null) { env.put(key.toString(), value.toString()); } } } {code} > Expose generic options for elytron dir-context > ---------------------------------------------- > > Key: WFLY-7720 > URL: https://issues.jboss.org/browse/WFLY-7720 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Priority: Critical > > Expose generic options like in case of legacy ldap outbound connection. Users relying on them can't migrate to elytron. > As [~tfonteyn] has already [pointed out|https://issues.jboss.org/browse/JBEAP-6480?focusedCommentId=13312043&...] customers use generic options exposed by legacy ldap outbound connection. > Here are references to possible properties to be configured > * [General properties|http://docs.oracle.com/javase/jndi/tutorial/beyond/env/overvie...] > * Service-specific > ** e.g. java.naming.ldap.* , for example for [connection pool configuration|http://docs.oracle.com/javase/jndi/tutorial/ldap/connect/co...] > * Feature-specific > ** e.g. [java.naming.security.sasl.*|http://docs.oracle.com/javase/jndi/tutorial/l...] > * Provider-specific > ** e.g. com.sun.jndi.ldap.trace.ber > > AFAICT it is already prepared in elytron, just elytron-subsystem part is missing. > {code:title=SimpleDirContextFactoryBuilder.java} > // set any additional connection property > if (connectionProperties != null) { > for (Object key : connectionProperties.keySet()) { > Object value = connectionProperties.get(key.toString()); > if (value != null) { > env.put(key.toString(), value.toString()); > } > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7720) Expose generic options for elytron dir-context

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7720?page=com.atlassian.jira.plugin.... ] Martin Choma moved JBEAP-7611 to WFLY-7720: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7720 (was: JBEAP-7611) 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.DR9) > Expose generic options for elytron dir-context > ---------------------------------------------- > > Key: WFLY-7720 > URL: https://issues.jboss.org/browse/WFLY-7720 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Priority: Critical > > Expose generic options like in case of legacy ldap outbound connection. Users relying on them can't migrate to elytron. > As [~tfonteyn] has already [pointed out|https://issues.jboss.org/browse/JBEAP-6480?focusedCommentId=13312043&...] customers use generic options exposed by legacy ldap outbound connection. > Here are references to possible properties to be configured > * [list of general properties|http://docs.oracle.com/javase/jndi/tutorial/beyond/env/overvie...] > ** Service-specific > *** e.g. java.naming.ldap.* , for example for [connection pool configuration|http://docs.oracle.com/javase/jndi/tutorial/ldap/connect/co...] > ** Feature-specific > *** e.g. [java.naming.security.sasl.*|http://docs.oracle.com/javase/jndi/tutorial/l...] > ** Provider-specific > *** e.g. com.sun.jndi.ldap.trace.ber > > AFAICT it is already prepared in elytron, just elytron-subsystem part is missing. > {code:title=SimpleDirContextFactoryBuilder.java} > // set any additional connection property > if (connectionProperties != null) { > for (Object key : connectionProperties.keySet()) { > Object value = connectionProperties.get(key.toString()); > if (value != null) { > env.put(key.toString(), value.toString()); > } > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2011) Inconsistency of formatter and named-formatter in console logging handler

by ted won (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2011?page=com.atlassian.jira.plugi... ] ted won updated WFCORE-2011: ---------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2001 > Inconsistency of formatter and named-formatter in console logging handler > ------------------------------------------------------------------------- > > Key: WFCORE-2011 > URL: https://issues.jboss.org/browse/WFCORE-2011 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 3.0.0.Alpha13 > Environment: It is possible to reproduce with all profiles and all modes. > All WildFly profiles > All WildFly clustering mode > * standalone mode > * domain mode > Reporter: ted won > Assignee: ted won > Priority: Minor > Labels: logging > Attachments: COLOR-PATTERN.png, CONSOLE-console-handler.png > > > In logging subsystem the default CONSOLE console-handler is defined with COLOR-PATTERN named-formatter. > And the COLOR-PATTERN named-formatter is defined with: {noformat}"%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"{noformat} > It is working as it is defined with colors in a console. > {code:title=standalone.xml} > ... > <subsystem xmlns="urn:jboss:domain:logging:3.0"> > <console-handler name="CONSOLE"> > <level name="INFO"/> > <formatter> > <named-formatter name="COLOR-PATTERN"/> > </formatter> > </console-handler> > ... > <formatter name="COLOR-PATTERN"> > <pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"/> > </formatter> > </subsystem> > ... > {code} > However there is a inconsistency in the CLI and WildFly admin console views. > In the CLI, CONSOLE formatter is: {noformat}"%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"{noformat} It is wrong and different with the working logging format in a console. > {code:title=JBoss CLI} > [standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource > { > "outcome" => "success", > "result" => { > "autoflush" => true, > "enabled" => true, > "encoding" => undefined, > "filter" => undefined, > "filter-spec" => undefined, > "formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n", > "level" => "INFO", > "name" => "CONSOLE", > "named-formatter" => "COLOR-PATTERN", > "target" => "System.out" > } > } > {code} > It should be fixed like below: > {code:title=Expected result} > [standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource > { > "outcome" => "success", > "result" => { > "autoflush" => true, > "enabled" => true, > "encoding" => undefined, > "filter" => undefined, > "filter-spec" => undefined, > "formatter" => undefined, > "level" => "INFO", > "name" => "CONSOLE", > "named-formatter" => "COLOR-PATTERN", > "target" => "System.out" > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7719) HotRod-based distributed session manager

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-7719?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-7719: ------------------------------------ Topic branch is here: https://github.com/wildfly-clustering/wildfly/tree/hotrod > HotRod-based distributed session manager > ---------------------------------------- > > Key: WFLY-7719 > URL: https://issues.jboss.org/browse/WFLY-7719 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Reporter: Paul Ferraro > Assignee: Paul Ferraro > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2011) Inconsistency of formatter and named-formatter in console logging handler

by ted won (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2011?page=com.atlassian.jira.plugi... ] ted won updated WFCORE-2011: ---------------------------- SourceForge Reference: (was: https://c.na7.visual.force.com/apex/Case_View?sbstr=01721475) > Inconsistency of formatter and named-formatter in console logging handler > ------------------------------------------------------------------------- > > Key: WFCORE-2011 > URL: https://issues.jboss.org/browse/WFCORE-2011 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 3.0.0.Alpha13 > Environment: It is possible to reproduce with all profiles and all modes. > All WildFly profiles > All WildFly clustering mode > * standalone mode > * domain mode > Reporter: ted won > Assignee: ted won > Priority: Minor > Labels: logging > Attachments: COLOR-PATTERN.png, CONSOLE-console-handler.png > > > In logging subsystem the default CONSOLE console-handler is defined with COLOR-PATTERN named-formatter. > And the COLOR-PATTERN named-formatter is defined with: {noformat}"%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"{noformat} > It is working as it is defined with colors in a console. > {code:title=standalone.xml} > ... > <subsystem xmlns="urn:jboss:domain:logging:3.0"> > <console-handler name="CONSOLE"> > <level name="INFO"/> > <formatter> > <named-formatter name="COLOR-PATTERN"/> > </formatter> > </console-handler> > ... > <formatter name="COLOR-PATTERN"> > <pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"/> > </formatter> > </subsystem> > ... > {code} > However there is a inconsistency in the CLI and WildFly admin console views. > In the CLI, CONSOLE formatter is: {noformat}"%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"{noformat} It is wrong and different with the working logging format in a console. > {code:title=JBoss CLI} > [standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource > { > "outcome" => "success", > "result" => { > "autoflush" => true, > "enabled" => true, > "encoding" => undefined, > "filter" => undefined, > "filter-spec" => undefined, > "formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n", > "level" => "INFO", > "name" => "CONSOLE", > "named-formatter" => "COLOR-PATTERN", > "target" => "System.out" > } > } > {code} > It should be fixed like below: > {code:title=Expected result} > [standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource > { > "outcome" => "success", > "result" => { > "autoflush" => true, > "enabled" => true, > "encoding" => undefined, > "filter" => undefined, > "filter-spec" => undefined, > "formatter" => undefined, > "level" => "INFO", > "name" => "CONSOLE", > "named-formatter" => "COLOR-PATTERN", > "target" => "System.out" > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1282) Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1282?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1282: ------------------------------------- Fix Version/s: 3.0.0.Alpha15 (was: 3.0.0.Alpha14) > Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string > --------------------------------------------------------------------------------------- > > Key: WFCORE-1282 > URL: https://issues.jboss.org/browse/WFCORE-1282 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 1.0.2.Final > Environment: Oracle Java > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Alpha15 > > Attachments: client_debug_eap6.log, client_debug_eap7.log, server-cert-key-ec.jks, server_debug_eap6.log, server_debug_eap7.log > > > User using these cipher suites / cipher name in EAP6 won't be able to use it in EAP7. > Setting as critical as these cipher suites, are considered for strong and widely used in my opinion. > In server log, error "no cipher suites in common" can be seen using -Djavax.net.debug=all. > Note, that analogous configuration in EAP6 works fine. > Issue can be seen on Oracle Java only, as on OpenJDK / IBM these suites are not provided by method getDefaultCipherSuites(). > Also is it possible to log "no cipher suites in common" and similar tls handshake errors without -Djavax.net.debug for better troubleshooting? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1145) Review of HostController / Application Server Remoting connections

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1145?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1145: ------------------------------------- Fix Version/s: 3.0.0.Alpha15 (was: 3.0.0.Alpha14) > Review of HostController / Application Server Remoting connections > ------------------------------------------------------------------ > > Key: WFCORE-1145 > URL: https://issues.jboss.org/browse/WFCORE-1145 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: affects_elytron > Fix For: 3.0.0.Alpha15 > > > Where an application server connects back to it's host controller in domain mode it used the same Remoting connector exposed possibly for native domain management access. > The problem with this is that as soon as any security restrictions are placed on the connector exposed by the host controller then the application servers require something to work with this - this is even though we are only ever talking about loopback communication between two process on the same machine. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1059) RestartParentResourceAdd/RemoveHandler should handle capability registration

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1059?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1059: ------------------------------------- Fix Version/s: 3.0.0.Alpha15 (was: 3.0.0.Alpha14) > RestartParentResourceAdd/RemoveHandler should handle capability registration > ---------------------------------------------------------------------------- > > Key: WFCORE-1059 > URL: https://issues.jboss.org/browse/WFCORE-1059 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.0.CR6 > Reporter: Paul Ferraro > Assignee: Tomaz Cerar > Fix For: 3.0.0.Alpha15 > > > RestartParentResourceAddHandler and RestartParentResourceRemoveHandler do not extend the respective AbstractAddStepHandler and AbstractRemoveStepHandler base classes, and thus does not handle capability [un]registration. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 3 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2016