[JBoss JIRA] (AS7-3607) Native connector shoudl support the java.net.preferIPv4Stack system property
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/AS7-3607?page=com.atlassian.jira.plugin.s... ]
Richard Achmatowicz commented on AS7-3607:
------------------------------------------
OK. The patch mentioned above fixes this issue. It just didn't make it into 7.1.0.Final.
The problem is that whether we specify the IPv4 address 127.0.0.1 or the IPv6 mapped address ::ffff:127.0.0.1. InetAddress.getByName() returns /127.0.0.1 as the address. This gets passed down to AprEndpoint which creates the socket. There are some checks to try to determine the address family (AF_INET, AF_INET6) based on the address format, but no checks on the current stack preference. So when 127.0.0.1 appears, it is a assumed that the address family is AF_INET.
This fix checks the stack preference, and if an IPv4 address is passed, will set the correct family and prefix an IPv4 address with ::ffff: if required, which causes an IPv6 socket to be created.
> Native connector shoudl support the java.net.preferIPv4Stack system property
> ----------------------------------------------------------------------------
>
> Key: AS7-3607
> URL: https://issues.jboss.org/browse/AS7-3607
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Web
> Affects Versions: 7.1.0.CR1b
> Reporter: Pavel Janousek
> Assignee: Jean-Frederic Clere
> Labels: eap6_prd_req
> Fix For: 7.1.1.Final
>
>
> There is another example of incorrect address binding in IPv6 environment.
> Steps how to reproduce:
> 1. Download, unpack DR12 build somewhere
> 2. Remove -Djava.net.preferIPv4Stack=true, or change it to -Djava.net.preferIPv4Stack=false parameter inside JAVA_OPT in file bin/standalone.conf
> 3. Set some usefull IPv6 address to network interface (in my case network interface is p2p1, so you can use command like "ip addr add 1:0:0:1::10 dev p2p1")
> 3a. Don't forget to configure this IPv6 address as hostname for box (let say, hostname is fedora15-vrt1, so at least /etc/hosts should contain "1:0:0:1::10 fedora15-vrt1")
> 4. Verify if you really have configured wanted eth. interface only aka:
> {code}
> [root@fedora15-vrt1 Documents]# ifconfig
> p2p1 Link encap:Ethernet HWaddr 00:00:00:00:00:01
> inet6 addr: 1:0:0:1::10/128 Scope:Global
> inet6 addr: fe80::200:ff:fe00:1/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 b) TX bytes:766 (766.0 b)
> [root@fedora15-vrt1 Documents]#
> {code}
> 5. Start EAP6 as usual bin/standalone.sh and wait until it says somethink similas as "[org.jboss.as] (Controller Boot Thread) JBoss EAP 6.0.0.Alpha2 (AS 7.1.0.CR1-redhat-1) started in 16179ms - Started 158 of 228 services (68 services are passive or on-demand)"
> 6. Check addresses binding via "netstat -lnp|grep java"
> The result it this scenario should be something like mine:
> {code}
> [root@fedora15-vrt1 jboss-as]# netstat -lnp|grep java
> tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:5445 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:9990 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:3528 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:9999 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:5455 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:4447 :::* LISTEN 4765/java
> [root@fedora15-vrt1 jboss-as]#
> {code}
> As you may see - poor binding is done to 127.0.0.1 IPv4 address, but anyway others are bound to IPv6 address ::ffff:127.0.0.1 although every log message refers to IPv4 address 127.0.0.1.
> The worst is that in case when you disable loopback interface at all (ip link set dev lo down) before starting EAP, the result is the same although IP address 127.0.0.1, nor ::ffff:127.0.0.1 doesn't exist (isn't active) in Linux system.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] (AS7-3537) jboss-cli freezes on connect on out-of-box OSX AS7.1-snapshot
by Max Rydahl Andersen (JIRA)
Max Rydahl Andersen created AS7-3537:
----------------------------------------
Summary: jboss-cli freezes on connect on out-of-box OSX AS7.1-snapshot
Key: AS7-3537
URL: https://issues.jboss.org/browse/AS7-3537
Project: Application Server 7
Issue Type: Bug
Reporter: Max Rydahl Andersen
Downloaded snapshot from 30th January.
Unzip as7
cd as7
./bin/standalone
<server running and responding as expected>
./bin/jboss-cli
connect
<freeze>
thread dump:
{code:title=threaddump}
2012-02-01 12:40:04
Full thread dump Java HotSpot(TM) 64-Bit Server VM (20.4-b02-402 mixed mode):
"Attach Listener" daemon prio=9 tid=7fa1f4c94800 nid=0x107814000 waiting on condition [00000000]
java.lang.Thread.State: RUNNABLE
"Remoting "management-client" write-1" prio=5 tid=7fa1f4c55800 nid=0x108a87000 runnable [108a86000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.KQueueArrayWrapper.kevent0(Native Method)
at sun.nio.ch.KQueueArrayWrapper.poll(KQueueArrayWrapper.java:136)
at sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:69)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
- locked <7f42b0188> (a sun.nio.ch.Util$2)
- locked <7f42b0198> (a java.util.Collections$UnmodifiableSet)
- locked <7f42b0140> (a sun.nio.ch.KQueueSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:84)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:153)
"Remoting "management-client" read-1" prio=5 tid=7fa1f4921800 nid=0x108984000 runnable [108983000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.KQueueArrayWrapper.kevent0(Native Method)
at sun.nio.ch.KQueueArrayWrapper.poll(KQueueArrayWrapper.java:136)
at sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:69)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
- locked <7f4365858> (a sun.nio.ch.Util$2)
- locked <7f4365848> (a java.util.Collections$UnmodifiableSet)
- locked <7f43657b0> (a sun.nio.ch.KQueueSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:84)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:153)
"Poller SunPKCS11-Darwin" daemon prio=1 tid=7fa1f335f000 nid=0x1082f7000 waiting on condition [1082f6000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at sun.security.pkcs11.SunPKCS11$TokenPoller.run(SunPKCS11.java:692)
at java.lang.Thread.run(Thread.java:680)
"Reference Reaper" daemon prio=5 tid=7fa1f316d000 nid=0x108142000 in Object.wait() [108141000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <7f42b02d8> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
- locked <7f42b02d8> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
at org.jboss.modules.ref.References$ReaperThread.run(References.java:68)
"Low Memory Detector" daemon prio=5 tid=7fa1f4846800 nid=0x107d26000 runnable [00000000]
java.lang.Thread.State: RUNNABLE
"C2 CompilerThread1" daemon prio=9 tid=7fa1f4845800 nid=0x107c23000 waiting on condition [00000000]
java.lang.Thread.State: RUNNABLE
"C2 CompilerThread0" daemon prio=9 tid=7fa1f4845000 nid=0x107b20000 waiting on condition [00000000]
java.lang.Thread.State: RUNNABLE
"Signal Dispatcher" daemon prio=9 tid=7fa1f4844000 nid=0x107a1d000 runnable [00000000]
java.lang.Thread.State: RUNNABLE
"Surrogate Locker Thread (Concurrent GC)" daemon prio=5 tid=7fa1f4843800 nid=0x10791a000 waiting on condition [00000000]
java.lang.Thread.State: RUNNABLE
"Finalizer" daemon prio=8 tid=7fa1f3065000 nid=0x107656000 in Object.wait() [107655000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <7f434a6c0> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
- locked <7f434a6c0> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
"Reference Handler" daemon prio=10 tid=7fa1f4836800 nid=0x107553000 in Object.wait() [107552000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <7f42b2078> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:485)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
- locked <7f42b2078> (a java.lang.ref.Reference$Lock)
"main" prio=5 tid=7fa1f4801000 nid=0x100bf1000 in Object.wait() [100bef000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <7f434aaf8> (a java.lang.Object)
at java.lang.Object.wait(Object.java:485)
at org.jboss.remoting3.spi.AbstractHandleableCloseable.close(AbstractHandleableCloseable.java:177)
- locked <7f434aaf8> (a java.lang.Object)
at org.jboss.as.protocol.StreamUtils.safeClose(StreamUtils.java:59)
at org.jboss.as.controller.client.impl.RemotingModelControllerClient.close(RemotingModelControllerClient.java:64)
- locked <7f434d438> (a org.jboss.as.controller.client.impl.RemotingModelControllerClient)
at org.jboss.as.protocol.StreamUtils.safeClose(StreamUtils.java:59)
at org.jboss.as.cli.impl.CommandContextImpl.initialConnection(CommandContextImpl.java:778)
at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:611)
at org.jboss.as.cli.handlers.ConnectHandler.doHandle(ConnectHandler.java:109)
at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:84)
at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:444)
at org.jboss.as.cli.impl.CommandContextImpl.processLine(CommandContextImpl.java:455)
at org.jboss.as.cli.impl.CommandContextImpl.interact(CommandContextImpl.java:1002)
at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:189)
at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.modules.Module.run(Module.java:260)
at org.jboss.modules.Main.main(Main.java:288)
"VM Thread" prio=9 tid=7fa1f4832000 nid=0x107450000 runnable
"Gang worker#0 (Parallel GC Threads)" prio=9 tid=7fa1f3000800 nid=0x103f2d000 runnable
"Gang worker#1 (Parallel GC Threads)" prio=9 tid=7fa1f3001000 nid=0x104030000 runnable
"Concurrent Mark-Sweep GC Thread" prio=9 tid=7fa1f304c000 nid=0x1070f6000 runnable
"VM Periodic Task Thread" prio=10 tid=7fa1f3071000 nid=0x107e29000 waiting on condition
"Exception Catcher Thread" prio=10 tid=7fa1f4801800 nid=0x100d54000 runnable
JNI global references: 1119
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] (AS7-3607) Native connector shoudl support the java.net.preferIPv4Stack system property
by Jean-Frederic Clere (JIRA)
[ https://issues.jboss.org/browse/AS7-3607?page=com.atlassian.jira.plugin.s... ]
Jean-Frederic Clere commented on AS7-3607:
------------------------------------------
http://anonsvn.jboss.org/repos/jbossweb/tags/JBOSSWEB_7_0_10_FINAL/java/o...
> Native connector shoudl support the java.net.preferIPv4Stack system property
> ----------------------------------------------------------------------------
>
> Key: AS7-3607
> URL: https://issues.jboss.org/browse/AS7-3607
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Web
> Affects Versions: 7.1.0.CR1b
> Reporter: Pavel Janousek
> Assignee: Jean-Frederic Clere
> Labels: eap6_prd_req
> Fix For: 7.1.1.Final
>
>
> There is another example of incorrect address binding in IPv6 environment.
> Steps how to reproduce:
> 1. Download, unpack DR12 build somewhere
> 2. Remove -Djava.net.preferIPv4Stack=true, or change it to -Djava.net.preferIPv4Stack=false parameter inside JAVA_OPT in file bin/standalone.conf
> 3. Set some usefull IPv6 address to network interface (in my case network interface is p2p1, so you can use command like "ip addr add 1:0:0:1::10 dev p2p1")
> 3a. Don't forget to configure this IPv6 address as hostname for box (let say, hostname is fedora15-vrt1, so at least /etc/hosts should contain "1:0:0:1::10 fedora15-vrt1")
> 4. Verify if you really have configured wanted eth. interface only aka:
> {code}
> [root@fedora15-vrt1 Documents]# ifconfig
> p2p1 Link encap:Ethernet HWaddr 00:00:00:00:00:01
> inet6 addr: 1:0:0:1::10/128 Scope:Global
> inet6 addr: fe80::200:ff:fe00:1/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 b) TX bytes:766 (766.0 b)
> [root@fedora15-vrt1 Documents]#
> {code}
> 5. Start EAP6 as usual bin/standalone.sh and wait until it says somethink similas as "[org.jboss.as] (Controller Boot Thread) JBoss EAP 6.0.0.Alpha2 (AS 7.1.0.CR1-redhat-1) started in 16179ms - Started 158 of 228 services (68 services are passive or on-demand)"
> 6. Check addresses binding via "netstat -lnp|grep java"
> The result it this scenario should be something like mine:
> {code}
> [root@fedora15-vrt1 jboss-as]# netstat -lnp|grep java
> tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:5445 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:9990 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:3528 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:9999 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:5455 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:4447 :::* LISTEN 4765/java
> [root@fedora15-vrt1 jboss-as]#
> {code}
> As you may see - poor binding is done to 127.0.0.1 IPv4 address, but anyway others are bound to IPv6 address ::ffff:127.0.0.1 although every log message refers to IPv4 address 127.0.0.1.
> The worst is that in case when you disable loopback interface at all (ip link set dev lo down) before starting EAP, the result is the same although IP address 127.0.0.1, nor ::ffff:127.0.0.1 doesn't exist (isn't active) in Linux system.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] (AS7-3607) Native connector shoudl support the java.net.preferIPv4Stack system property
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/AS7-3607?page=com.atlassian.jira.plugin.s... ]
Richard Achmatowicz commented on AS7-3607:
------------------------------------------
This handles the opposite case - if I prefer an IPv6 stack and i'm given an IPv4 address, convert it to an IPv6 mapped address.
But even with this fix, if I do prefer an IPv6 stack and I do pass in an IPv4 address, it still comes out as an IPv4 socket.
The problem is further down.
I tried locating the code for AprEndpoint to insert some debugging statements to confirm my suspicions. J-F, where is it located (i.e. which source repo and which jar?) I see JBoss Web 7.0.10.Final included in the pom; when I go to JBoss Web page, no hint of any version called 7.0.10.Final, as far as I could tell.
> Native connector shoudl support the java.net.preferIPv4Stack system property
> ----------------------------------------------------------------------------
>
> Key: AS7-3607
> URL: https://issues.jboss.org/browse/AS7-3607
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Web
> Affects Versions: 7.1.0.CR1b
> Reporter: Pavel Janousek
> Assignee: Jean-Frederic Clere
> Labels: eap6_prd_req
> Fix For: 7.1.1.Final
>
>
> There is another example of incorrect address binding in IPv6 environment.
> Steps how to reproduce:
> 1. Download, unpack DR12 build somewhere
> 2. Remove -Djava.net.preferIPv4Stack=true, or change it to -Djava.net.preferIPv4Stack=false parameter inside JAVA_OPT in file bin/standalone.conf
> 3. Set some usefull IPv6 address to network interface (in my case network interface is p2p1, so you can use command like "ip addr add 1:0:0:1::10 dev p2p1")
> 3a. Don't forget to configure this IPv6 address as hostname for box (let say, hostname is fedora15-vrt1, so at least /etc/hosts should contain "1:0:0:1::10 fedora15-vrt1")
> 4. Verify if you really have configured wanted eth. interface only aka:
> {code}
> [root@fedora15-vrt1 Documents]# ifconfig
> p2p1 Link encap:Ethernet HWaddr 00:00:00:00:00:01
> inet6 addr: 1:0:0:1::10/128 Scope:Global
> inet6 addr: fe80::200:ff:fe00:1/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 b) TX bytes:766 (766.0 b)
> [root@fedora15-vrt1 Documents]#
> {code}
> 5. Start EAP6 as usual bin/standalone.sh and wait until it says somethink similas as "[org.jboss.as] (Controller Boot Thread) JBoss EAP 6.0.0.Alpha2 (AS 7.1.0.CR1-redhat-1) started in 16179ms - Started 158 of 228 services (68 services are passive or on-demand)"
> 6. Check addresses binding via "netstat -lnp|grep java"
> The result it this scenario should be something like mine:
> {code}
> [root@fedora15-vrt1 jboss-as]# netstat -lnp|grep java
> tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:5445 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:9990 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:3528 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:9999 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:5455 :::* LISTEN 4765/java
> tcp 0 0 ::ffff:127.0.0.1:4447 :::* LISTEN 4765/java
> [root@fedora15-vrt1 jboss-as]#
> {code}
> As you may see - poor binding is done to 127.0.0.1 IPv4 address, but anyway others are bound to IPv6 address ::ffff:127.0.0.1 although every log message refers to IPv4 address 127.0.0.1.
> The worst is that in case when you disable loopback interface at all (ip link set dev lo down) before starting EAP, the result is the same although IP address 127.0.0.1, nor ::ffff:127.0.0.1 doesn't exist (isn't active) in Linux system.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] (AS7-3758) ParsedInterfaceCriteria.parseCriteria is not maintaining ExpressionValues
by Scott Stark (JIRA)
Scott Stark created AS7-3758:
--------------------------------
Summary: ParsedInterfaceCriteria.parseCriteria is not maintaining ExpressionValues
Key: AS7-3758
URL: https://issues.jboss.org/browse/AS7-3758
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Affects Versions: 7.1.0.CR1b
Reporter: Scott Stark
Assignee: Scott Stark
The parsing of interfaces is throwing away ExpressionValues that are created from parsePossibleExpression since the resulting ExpressionValue is not passed onto the
For example, in this LOOPBACK_ADDRESS block, the input property.getValue() is passed to the LoopbackAddressInterfaceCriteria ctor rather than the ExpressionValue that is created by parsePossibleExpression:
case LOOPBACK_ADDRESS: {
ModelNode value = property.getValue();
value = parsePossibleExpression(value);
checkStringType(value, element.getLocalName(), true);
return new LoopbackAddressInterfaceCriteria(property.getValue());
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] (AS7-3042) IPv6: Invalid redirect to Admin console (wrong IP address)
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/AS7-3042?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse commented on AS7-3042:
---------------------------------------
I have just tried starting AS7 and bind the management interfaces to the public interface and the remainder to loopback - connecting to localhost:8080 and trying to connect to the console I get an error: -
"It is not possible to redirect to the console, please contact the system administrator for the correct address to access the console."
This is the correct behaviour.
End users WILL go into production with the welcome context enabled, this is the reason the redirect is only possible for simple scenarios where the same NIC is used by both and in those scenarios there is no guarantee that just because a user can connect to one they will be able to connect to the other.
The only other option would be that where the welcome context is enabled we actually add a config option to specify the redirect address to use but that will still be error prone.
> IPv6: Invalid redirect to Admin console (wrong IP address)
> ----------------------------------------------------------
>
> Key: AS7-3042
> URL: https://issues.jboss.org/browse/AS7-3042
> Project: Application Server 7
> Issue Type: Bug
> Components: Console, Web
> Affects Versions: 7.1.0.Beta1b
> Reporter: Pavel Janousek
> Assignee: Darran Lofthouse
> Fix For: Open To Community
>
>
> This issue is some derivation from AS7-3040. Lets imagine starting server like this:
> {code}./standalone.sh -Djava.net.preferIPv4Stack=false -Djboss.bind.address=::1{code}
> So by default the admin/management is bound to _::ffff:127.0.0.1:9990_ and _::ffff:127.0.0.1:9999_, but it isn't accessible from Web WelcomePage at _::1:8080_ because the URL is specified as: {code}<a href="/console">{code} and so the next request is http://[::1]:8080/console which redirect requester to http://[::1]:9990, but there isn't any console because it is here - http://[::ffff:127.0.0.1]:9990.
> This is not good as it could lead to integration issues between components (X trying to connect to Y on ::1; Y listening on ::ffff:127.0.0.1).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] (AS7-3762) Unable to start in jBoss AS & in standalone
by Raju Ansari (JIRA)
Raju Ansari created AS7-3762:
--------------------------------
Summary: Unable to start in jBoss AS & in standalone
Key: AS7-3762
URL: https://issues.jboss.org/browse/AS7-3762
Project: Application Server 7
Issue Type: Bug
Environment: RedHat Linux 5.X
Reporter: Raju Ansari
=========================================================================
15:08:30,760 INFO [org.jboss.modules] JBoss Modules version 1.1.0.CR6
15:08:30,990 INFO [org.jboss.msc] JBoss MSC version 1.0.1.GA
15:08:31,047 INFO [org.jboss.as] JBoss AS 7.1.0.CR1b "Flux Capacitor" starting
15:08:37,430 INFO [org.jboss.as] JBoss AS 7.1.0.CR1b "Flux Capacitor" stopped in 6ms
15:08:37,427 ERROR [org.jboss.as.controller] JBAS014601: Error booting the container: java.lang.RuntimeException: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:161) [jboss-as-controller-7.1.0.CR1b.jar:7.1.0.CR1b]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_30]
Caused by: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:125) [jboss-as-controller-7.1.0.CR1b.jar:7.1.0.CR1b]
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:187) [jboss-as-controller-7.1.0.CR1b.jar:7.1.0.CR1b]
at org.jboss.as.server.ServerService.boot(ServerService.java:256) [jboss-as-server-7.1.0.CR1b.jar:7.1.0.CR1b]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:155) [jboss-as-controller-7.1.0.CR1b.jar:7.1.0.CR1b]
... 1 more
Caused by: java.lang.RuntimeException: JBAS014641: Unable to determine a default name based on the local host name
at org.jboss.as.controller.parsing.CommonXml.getDefaultName(CommonXml.java:172) [jboss-as-controller-7.1.0.CR1b.jar:7.1.0.CR1b]
at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_1(StandaloneXml.java:286) [jboss-as-server-7.1.0.CR1b.jar:7.1.0.CR1b]
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:120) [jboss-as-server-7.1.0.CR1b.jar:7.1.0.CR1b]
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:97) [jboss-as-server-7.1.0.CR1b.jar:7.1.0.CR1b]
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:100) [staxmapper-1.0.0.Final.jar:1.0.0.Final]
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:59) [staxmapper-1.0.0.Final.jar:1.0.0.Final]
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:117) [jboss-as-controller-7.1.0.CR1b.jar:7.1.0.CR1b]
... 4 more
Caused by: java.net.UnknownHostException: 101/udp: 101/udp
at java.net.InetAddress.getLocalHost(InetAddress.java:1360) [:1.6.0_30]
at org.jboss.as.controller.parsing.CommonXml.getDefaultName(CommonXml.java:170) [jboss-as-controller-7.1.0.CR1b.jar:7.1.0.CR1b]
... 10 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] (EJBTHREE-2277) Missing interpretation of EJB-Annotation results in wrong call of dynamic method
by Mustafa Musaji (JIRA)
Mustafa Musaji created EJBTHREE-2277:
----------------------------------------
Summary: Missing interpretation of EJB-Annotation results in wrong call of dynamic method
Key: EJBTHREE-2277
URL: https://issues.jboss.org/browse/EJBTHREE-2277
Project: EJB 3.0
Issue Type: Bug
Components: core
Affects Versions: trunk
Environment: java version "1.6.0_18"
Reporter: Mustafa Musaji
Assignee: jaikiran pai
Attachments: jbossbug-EJBTHREE-2086.tar.gz
when looking up a method for invocation in StatefulContainer.dynamicInvoke():522 jboss tries to determine if it's an EJB-Object-Method via SessionSpecContainer.isEjBObjectMethod(). This results wrongly in "false" if the class in question doesn't implement EJBObject but has e.g. a @Stateful annotation.
Futher the method EJBContainer.getNonBridgeMethod() seems to be rather optimistic in trying to find the correct method only according to the number of parameters.
This was tested with jboss-6.0.0.M1, but the corresponding code in trunk seems to be the same.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] (AS7-3728) @RestoreASConfigAfterTest to make a snapshot before test and reload it after.
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/AS7-3728?page=com.atlassian.jira.plugin.s... ]
Miroslav Novak commented on AS7-3728:
-------------------------------------
Hi all,
I believe this feature would help us a lot with reducing effort to maintain AS7 testsuite.
For example for HornetQ testing we need to have very different configuration for HA topologies - dedicated/colocated. We have to test it in different modes of paging like BLOG/PAGE or AIO/NIO. Then if it's clustered/non-clustered and there are more combinations we'd like to test.
Restoring configuration file after each test brings us much more effort and is very error-prone. Suggested feature would save a lot of time.
We tried to precise requested feature for reloading configuration:
- @RestoreASConfigAfterTest as described will be needed per test and per test class
- per test - configuration will restore to state before the whole test class was started
- we also need to have possibility to delete "tmp", "log", "data" and "deployments" directory per test and per test class. But those could be separate annotation for better flexibility.
Thanks,
Mirek
> @RestoreASConfigAfterTest to make a snapshot before test and reload it after.
> -----------------------------------------------------------------------------
>
> Key: AS7-3728
> URL: https://issues.jboss.org/browse/AS7-3728
> Project: Application Server 7
> Issue Type: Feature Request
> Reporter: Ondrej Zizka
> Assignee: Aslak Knutsen
>
> Having a possibility to restore server configuration after the test is run, or similar principle, would be very cool.
> For example, there are some tests which change datasource config quite dramatically.
> And getting it back to the original state afterwards requires a lot of coding.
> So instead, the test would have {{@RestoreASConfigAfterTest}}
> and Arq would re-load a snapshot it made before the test was run.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months