July 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4188) Client Mapping expressions are allowed but are not resolved if used

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4188?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4188: ----------------------------------------------- Ladislav Thon <lthon(a)redhat.com> changed the Status of [bug 1175442|https://bugzilla.redhat.com/show_bug.cgi?id=1175442] from ON_QA to VERIFIED > Client Mapping expressions are allowed but are not resolved if used > ------------------------------------------------------------------- > > Key: WFLY-4188 > URL: https://issues.jboss.org/browse/WFLY-4188 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.2.0.Final, 9.0.0.Alpha1 > Reporter: Wolf-Dieter Fink > Assignee: Chao Wang > Fix For: 9.0.0.Beta1 > > > If socket binding with client-mapping is used to provide a valid client address for EJB invocation to the client the expressions are not resolved. > Depend on the attribute the parsing failed direct during startup (port# is not numeric) or the expression is send to the client where the Exception is thrown at runtime. > Notice for EJB invocation the problem is only visible if the application is clustered, otherwise the cluster view (where the client-mapping take effect) is not send to the client. > Dec 17, 2014 2:53:43 PM org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager getEJBReceiver > INFO: Could not create a connection for cluster node ClusterNode{clusterName='ejb', nodeName='redhat', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='${jboss.node.name}', destinationPort=8080}], resolvedDestination=[Destination address=${jboss.node.name}, destination port=8080]} in cluster ejb > java.lang.RuntimeException: java.io.IOException: java.net.URISyntaxException: Illegal character in authority at index 7: http://@${jboss.node.name}:8080/?# > at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92) > at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:77) > at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51) > at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:79) > at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:405) > at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:379) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.io.IOException: java.net.URISyntaxException: Illegal character in authority at index 7: http://@${jboss.node.name}:8080/?# > at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider.createConnection(HttpUpgradeConnectionProvider.java:102) > at org.jboss.remoting3.remote.RemoteConnectionProvider.connect(RemoteConnectionProvider.java:215) > at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:298) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:388) > at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:153) > at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:133) > at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:75) > at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51) > at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:79) > at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:405) > at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:379) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > at ...asynchronous invocation...(Unknown Source) > at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:388) > at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:153) > at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:133) > at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:75) > ... 8 more > Caused by: java.net.URISyntaxException: Illegal character in authority at index 7: http://@${jboss.node.name}:8080/?# > at java.net.URI$Parser.fail(URI.java:2829) > at java.net.URI$Parser.parseAuthority(URI.java:3167) > at java.net.URI$Parser.parseHierarchical(URI.java:3078) > at java.net.URI$Parser.parse(URI.java:3034) > at java.net.URI.<init>(URI.java:680) > at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider.createConnection(HttpUpgradeConnectionProvider.java:100) > at org.jboss.remoting3.remote.RemoteConnectionProvider.connect(RemoteConnectionProvider.java:215) > at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:298) > ... 12 more -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5041) Test case for Reuse authenticated subject from incoming context when security domains match

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-5041: ---------------------------------- Summary: Test case for Reuse authenticated subject from incoming context when security domains match Key: WFLY-5041 URL: https://issues.jboss.org/browse/WFLY-5041 Project: WildFly Issue Type: Task Components: Test Suite Reporter: Ondrej Lukas Assignee: Ondrej Lukas Add tests for Reuse authenticated subject from incoming context when security domains match. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-783) Intermittent Disconnection from CLI After Reload

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-783?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-783: ------------------------------------------------ Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1232933|https://bugzilla.redhat.com/show_bug.cgi?id=1232933] from ASSIGNED to VERIFIED > Intermittent Disconnection from CLI After Reload > ------------------------------------------------- > > Key: WFCORE-783 > URL: https://issues.jboss.org/browse/WFCORE-783 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 2.0.0.Alpha5 > Reporter: Joe Wertz > Assignee: Joe Wertz > Fix For: 2.0.0.Alpha8 > > > Race condition in server reload. The CLI only waits for a connection to be established and does not check the server status before continuing to execute commands. If the next command is executed before the server had completed the reload, failures occur. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-854) CLI Variables 'set' command broken

by Joe Wertz (JIRA)

[ https://issues.jboss.org/browse/WFCORE-854?page=com.atlassian.jira.plugin... ] Joe Wertz updated WFCORE-854: ----------------------------- Description: Before AESH had 'export', added by the AESH upgrade, the CLI created 'set' to handle variables. With the upgrade, the commands overlap and interfere. Using commands, 'set name=value', and then 'echo $name', AESH will now search it's 'export' list for the variable. Which doesn't exist, so the variable is replaced with nothing. By the time the input processing gets to the CLI to search the 'set' variable list, the '$name' part of the string has been removed from the line by AESH's export processing. Export didn't exist before the upgrade, so disabling it doesn't cause problems. This was missed by the tests because part of the CLI actually bypasses AESH and most of the tests use that method. was: Before AESH had 'export', added by the AESH upgrade, the CLI created 'set' to handle variables. With the upgrade, the commands overlap and interfere. Using commands, 'set name=value', and then 'echo $name', AESH will now search it's 'export' list for the variable. Which doesn't exist, so the variable is replaced with nothing. By the time the input processing gets to the CLI to search the 'set' variable list, the '$name' part of the string has been removed from the line by AESH's export processing. Export didn't exist before the upgrade, so disabling it doesn't cause problems. > CLI Variables 'set' command broken > ---------------------------------- > > Key: WFCORE-854 > URL: https://issues.jboss.org/browse/WFCORE-854 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 2.0.0.Alpha12 > Reporter: Joe Wertz > Assignee: Joe Wertz > Fix For: 2.0.0.Alpha12 > > Original Estimate: 2 hours > Time Spent: 2 hours > Remaining Estimate: 0 minutes > > Before AESH had 'export', added by the AESH upgrade, the CLI created 'set' to handle variables. > With the upgrade, the commands overlap and interfere. > Using commands, 'set name=value', and then 'echo $name', AESH will now search it's 'export' list for the variable. Which doesn't exist, so the variable is replaced with nothing. By the time the input processing gets to the CLI to search the 'set' variable list, the '$name' part of the string has been removed from the line by AESH's export processing. > Export didn't exist before the upgrade, so disabling it doesn't cause problems. > This was missed by the tests because part of the CLI actually bypasses AESH and most of the tests use that method. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-854) CLI Variables 'set' command broken

by Joe Wertz (JIRA)

Joe Wertz created WFCORE-854: -------------------------------- Summary: CLI Variables 'set' command broken Key: WFCORE-854 URL: https://issues.jboss.org/browse/WFCORE-854 Project: WildFly Core Issue Type: Bug Components: CLI Affects Versions: 2.0.0.Alpha12 Reporter: Joe Wertz Assignee: Joe Wertz Fix For: 2.0.0.Alpha12 Before AESH had 'export', added by the AESH upgrade, the CLI created 'set' to handle variables. With the upgrade, the commands overlap and interfere. Using commands, 'set name=value', and then 'echo $name', AESH will now search it's 'export' list for the variable. Which doesn't exist, so the variable is replaced with nothing. By the time the input processing gets to the CLI to search the 'set' variable list, the '$name' part of the string has been removed from the line by AESH's export processing. Export didn't exist before the upgrade, so disabling it doesn't cause problems. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-18) jconsole window for an AS 7 server is labeled "JBoss CLI"

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-18?page=com.atlassian.jira.plugin.sy... ] RH Bugzilla Integration updated WFLY-18: ---------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1215278 > jconsole window for an AS 7 server is labeled "JBoss CLI" > --------------------------------------------------------- > > Key: WFLY-18 > URL: https://issues.jboss.org/browse/WFLY-18 > Project: WildFly > Issue Type: Bug > Components: JMX > Reporter: Brian Stansberry > Assignee: Stan Silvert > Priority: Minor > Fix For: 8.0.0.Alpha1 > > Attachments: jconsole-screenshot.png > > > Run jconsole.sh and connect to an AS 7 server instance. The resulting window in jconsole is labeled "JBoss CLI / <machine name>". > The term CLI should be reserved for the actual CLI tool. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1944) jgroups does not recover properly when using UDP after ifdown / ifup

by Bram Klein Gunnewiek (JIRA)

[ https://issues.jboss.org/browse/JGRP-1944?page=com.atlassian.jira.plugin.... ] Bram Klein Gunnewiek commented on JGRP-1944: -------------------------------------------- Sending an ubuntu virtual box image to your mail address using wetransfer (uploading right now). Hope this helps you. > jgroups does not recover properly when using UDP after ifdown / ifup > -------------------------------------------------------------------- > > Key: JGRP-1944 > URL: https://issues.jboss.org/browse/JGRP-1944 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.4 > Environment: Linux Ubutun 14.04 where the network cards are configured as bridges: > auto bridge0 > iface bridge0 inet dhcp > bridge_ports eth1 > bridge_stp off > bridge_fd 0 > Reporter: Bram Klein Gunnewiek > Assignee: Bela Ban > Fix For: 3.6.5 > > Attachments: AutoRecoverMulticast.java > > > When we bring the interface down and back up in a complete (udp.xml) configuration everything *seems* to be fine, however multicast traffic from the node that had the interface brought down is not received by other nodes. The node also doesn't receive any data from the other nodes. No exceptions are logged. I don't think the previous test was done correctly by me ... sorry . > When we use TCP + MPING we see the stacktraces we had previously with UDP: > 12:13:51.624 50644 [Timer-3,debug,shockvm-tn3-42192] ERROR unknown.jul.logger - failed sending discovery request > java.io.IOException: Invalid argument > at java.net.PlainDatagramSocketImpl.send(Native Method) ~[na:1.7.0_79] > at java.net.DatagramSocket.send(DatagramSocket.java:697) ~[na:1.7.0_79] > at org.jgroups.protocols.MPING.sendMcastDiscoveryRequest(MPING.java:295) ~[jar:rsrc:jgroups-3.6.4.Final.jar!/:na] > at org.jgroups.protocols.PING.sendDiscoveryRequest(PING.java:61) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na] > at org.jgroups.protocols.PING.findMembers(PING.java:31) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na] > at org.jgroups.protocols.Discovery.findMembers(Discovery.java:244) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na] > at org.jgroups.protocols.Discovery.down(Discovery.java:387) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na] > at org.jgroups.protocols.MERGE3$InfoSender.run(MERGE3.java:382) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na] > at org.jgroups.util.TimeScheduler3$Task.run(TimeScheduler3.java:287) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na] > at org.jgroups.util.TimeScheduler3$RecurringTask.run(TimeScheduler3.java:321) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_79] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_79] > at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79] > (The exact message differs whether or not the -Djava.net.preferIPv4Stack=true argument is configured) > A configuration that uses MPING also doesn't recover from ifdown/ifup. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3971) Jar Services in META-INF/services are not loaded from static modules

by Tomas Repel (JIRA)

[ https://issues.jboss.org/browse/WFLY-3971?page=com.atlassian.jira.plugin.... ] Tomas Repel updated WFLY-3971: ------------------------------ Affects Version/s: 10.0.0.Alpha6 > Jar Services in META-INF/services are not loaded from static modules > -------------------------------------------------------------------- > > Key: WFLY-3971 > URL: https://issues.jboss.org/browse/WFLY-3971 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Affects Versions: 8.1.0.Final, 9.0.0.Final, 10.0.0.Alpha6 > Reporter: Tomas Repel > Assignee: Stuart Douglas > > If the web application (war) uses jar file from static module, the content of META-INF/services has no effect. If the jar is located inside WEB-INF/lib, services are loaded successfully. > Neither adding `Dependencies: my.module.name.com services` into MANIFEST.MF nor adding `services="import"` to jboss-deployment-structure.xml works. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4928) Feature pack modules are built in the wrong order

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/WFLY-4928?page=com.atlassian.jira.plugin.... ] Sanne Grinovero resolved WFLY-4928. ----------------------------------- Resolution: Rejected > Feature pack modules are built in the wrong order > ------------------------------------------------- > > Key: WFLY-4928 > URL: https://issues.jboss.org/browse/WFLY-4928 > Project: WildFly > Issue Type: Bug > Components: Build System > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Blocker > > The Maven module {{feature-pack}} depends on {{servlet-feature-pack}}, but the order in the parent pom is the opposite. > If you're lucky, you will notice this problem with a clean build getting > {noformat}[ERROR] Failed to execute goal on project wildfly-feature-pack: Could not resolve dependencies for project org.wildfly:wildfly-feature-pack:pom:10.0.0.Alpha6-SNAPSHOT: Failure to find org.wildfly:wildfly-servlet-feature-pack:zip:10.0.0.Alpha6-SNAPSHOT in ...{noformat} > The worst is if you don't notice, as you will end up assembling and including the previous build, and I guess this would lead a release attempt to fail. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4928) Feature pack modules are built in the wrong order

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/WFLY-4928?page=com.atlassian.jira.plugin.... ] Sanne Grinovero closed WFLY-4928. --------------------------------- > Feature pack modules are built in the wrong order > ------------------------------------------------- > > Key: WFLY-4928 > URL: https://issues.jboss.org/browse/WFLY-4928 > Project: WildFly > Issue Type: Bug > Components: Build System > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Blocker > > The Maven module {{feature-pack}} depends on {{servlet-feature-pack}}, but the order in the parent pom is the opposite. > If you're lucky, you will notice this problem with a clean build getting > {noformat}[ERROR] Failed to execute goal on project wildfly-feature-pack: Could not resolve dependencies for project org.wildfly:wildfly-feature-pack:pom:10.0.0.Alpha6-SNAPSHOT: Failure to find org.wildfly:wildfly-servlet-feature-pack:zip:10.0.0.Alpha6-SNAPSHOT in ...{noformat} > The worst is if you don't notice, as you will end up assembling and including the previous build, and I guess this would lead a release attempt to fail. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 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 July 2015