March 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8366) JBoss EJB Client 4.0.0.Beta21

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-8366?page=com.atlassian.jira.plugin.... ] Stuart Douglas moved JBEAP-9576 to WFLY-8366: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8366 (was: JBEAP-9576) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) > JBoss EJB Client 4.0.0.Beta21 > ----------------------------- > > Key: WFLY-8366 > URL: https://issues.jboss.org/browse/WFLY-8366 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Stuart Douglas > Assignee: Stuart Douglas > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8365) Wildfly HTTP Client 1.0.0.Alpha4

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-8365?page=com.atlassian.jira.plugin.... ] Stuart Douglas moved JBEAP-9574 to WFLY-8365: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8365 (was: JBEAP-9574) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) > Wildfly HTTP Client 1.0.0.Alpha4 > -------------------------------- > > Key: WFLY-8365 > URL: https://issues.jboss.org/browse/WFLY-8365 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Stuart Douglas > Assignee: Stuart Douglas > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2248) DeploymentTestCase fails intermittently

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2248?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2248: ------------------------------------- Fix Version/s: 3.0.0.Beta10 (was: 3.0.0.Beta5) > DeploymentTestCase fails intermittently > --------------------------------------- > > Key: WFCORE-2248 > URL: https://issues.jboss.org/browse/WFCORE-2248 > Project: WildFly Core > Issue Type: Bug > Components: Deployment Scanner, Test Suite > Reporter: Marek Kopecký > Assignee: ehsavoie Hugonnet > Fix For: 3.0.0.Beta10 > > > *Description of problem:* > DeploymentTestCase fails intermittently > *How reproducible:* > 2% on RHEL > 15% on slower IPv6 machines > *Actual results:* > StackTrace: > {noformat} > org.junit.ComparisonFailure: service has the wrong value expected:<is [replaced]> but was:<is [new]> > at org.junit.Assert.assertEquals(Assert.java:115) > at org.jboss.as.test.deployment.trivial.ServiceActivatorDeploymentUtil.validateProperties(ServiceActivatorDeploymentUtil.java:126) > at org.jboss.as.test.deployment.trivial.ServiceActivatorDeploymentUtil.validateProperties(ServiceActivatorDeploymentUtil.java:111) > at org.wildfly.core.test.standalone.mgmt.api.DeploymentTestCase.testDeployments(DeploymentTestCase.java:872) > at org.wildfly.core.test.standalone.mgmt.api.DeploymentTestCase.testFilesystemDeployment_Auto(DeploymentTestCase.java:453) > {noformat} > Standard output: > {noformat} > &amp#27;[0m13:28:46,781 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-1) WFLYDS0013: Started FileSystemDeploymentService for directory /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core-rhel/b7cade8d/testsuite/standalone/target/auto-deployments > &amp#27;[0m&amp#27;[0m13:28:46,791 INFO [org.jboss.as.repository] (DeploymentScanner-threads - 2) WFLYDR0001: Content added at location /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core-rhel/b7cade8d/testsuite/standalone/target/wildfly-core/standalone/data/content/e0/afac1c502e481badbe10f16d5b2a18ef62fe18/content > &amp#27;[0m&amp#27;[0m13:28:46,793 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "test-deployment.jar" (runtime-name: "test-deployment.jar") > &amp#27;[0m&amp#27;[0m13:28:46,800 INFO [stdout] (MSC service thread 1-1) Properties found > &amp#27;[0m&amp#27;[0m13:28:46,800 INFO [stdout] (MSC service thread 1-1) Setting service to is new > &amp#27;[0m&amp#27;[0m13:28:46,803 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) WFLYSRV0010: Deployed "test-deployment.jar" (runtime-name : "test-deployment.jar") > &amp#27;[0m&amp#27;[0m13:29:07,226 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment test-deployment.jar (runtime-name: test-deployment.jar) in 0ms > &amp#27;[0m&amp#27;[0m13:29:07,229 INFO [org.jboss.as.repository] (management-handler-thread - 4) WFLYDR0002: Content removed from location /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core-rhel/b7cade8d/testsuite/standalone/target/wildfly-core/standalone/data/content/e0/afac1c502e481badbe10f16d5b2a18ef62fe18/content > &amp#27;[0m&amp#27;[0m13:29:07,229 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0009: Undeployed "test-deployment.jar" (runtime-name: "test-deployment.jar") > &amp#27;[0m > {noformat} > *Expected results:* > No errors -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-5688) mod_cluster subsystem remains silent if connector set to undefined connector

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-5688?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-5688: --------------------------------- Affects: User Experience > mod_cluster subsystem remains silent if connector set to undefined connector > ---------------------------------------------------------------------------- > > Key: WFLY-5688 > URL: https://issues.jboss.org/browse/WFLY-5688 > Project: WildFly > Issue Type: Bug > Components: Clustering, Web (Undertow) > Affects Versions: 10.0.0.CR4 > Reporter: Michal Karm Babacek > Assignee: Radoslav Husar > > If one sets mod_cluster subsystem {{connector="http"}} there is nothing in the log about any mod_cluster subsystem being initialized, no warning, nothing. It appears to be dead silent even with log level DEBUG. > When switched back to {{connector="ajp"}}, there are the well known comforting messages: > {noformat} > INFO [org.jboss.modcluster] (ServerService Thread Pool -- 62) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final > INFO [org.jboss.modcluster] (ServerService Thread Pool -- 62) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364 > {noformat} > Weird. Any obvious misconfiguration or explanation? The config is the default standalone-ha.xml otherwise. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-5688) mod_cluster subsystem remains silent if connector set to undefined connector

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-5688?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-5688: --------------------------------- Labels: (was: ux) > mod_cluster subsystem remains silent if connector set to undefined connector > ---------------------------------------------------------------------------- > > Key: WFLY-5688 > URL: https://issues.jboss.org/browse/WFLY-5688 > Project: WildFly > Issue Type: Bug > Components: Clustering, Web (Undertow) > Affects Versions: 10.0.0.CR4 > Reporter: Michal Karm Babacek > Assignee: Radoslav Husar > > If one sets mod_cluster subsystem {{connector="http"}} there is nothing in the log about any mod_cluster subsystem being initialized, no warning, nothing. It appears to be dead silent even with log level DEBUG. > When switched back to {{connector="ajp"}}, there are the well known comforting messages: > {noformat} > INFO [org.jboss.modcluster] (ServerService Thread Pool -- 62) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final > INFO [org.jboss.modcluster] (ServerService Thread Pool -- 62) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364 > {noformat} > Weird. Any obvious misconfiguration or explanation? The config is the default standalone-ha.xml otherwise. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-396) Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-396?page=com.atlassian.jira.plugin... ] Kabir Khan updated WFCORE-396: ------------------------------ Fix Version/s: 3.0.0.Beta10 (was: 3.0.0.Beta9) > Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users > --------------------------------------------------------------------------------------------- > > Key: WFCORE-396 > URL: https://issues.jboss.org/browse/WFCORE-396 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Ken Wills > Fix For: 3.0.0.Beta10 > > > Ops registered on a domain server without the RUNTIME_ONLY flag are hidden from users (e.g. in read-operation-names results etc) in order to not delude users into thinking they can do something like :write-attribute directly on a server (instead of modifying host or domain config elements.) > But shouldn't a READ_ONLY flag be sufficient as well? An op that only reads config should be valid. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-13) End users can call non-published management API operations

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-13?page=com.atlassian.jira.plugin.... ] Kabir Khan updated WFCORE-13: ----------------------------- Fix Version/s: 3.0.0.Beta10 (was: 3.0.0.Beta9) > End users can call non-published management API operations > ---------------------------------------------------------- > > Key: WFCORE-13 > URL: https://issues.jboss.org/browse/WFCORE-13 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ladislav Thon > Labels: EAP > Fix For: 3.0.0.Beta10 > > > It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces. > The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen. > What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized. > I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

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

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1282?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-1282: ------------------------------- Fix Version/s: 3.0.0.Beta10 (was: 3.0.0.Beta9) > 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.Beta10 > > 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)

9 years, 1 month

1
0
0 / 0

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

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1059?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-1059: ------------------------------- Fix Version/s: 3.0.0.Beta10 (was: 3.0.0.Beta9) > 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.Beta10 > > > 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)

9 years, 1 month

1
0
0 / 0

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

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1145?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-1145: ------------------------------- Fix Version/s: 3.0.0.Beta10 (was: 3.0.0.Beta9) > 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, domain-mode > Fix For: 3.0.0.Beta10 > > > 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)

9 years, 1 month

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 March 2017