[JBoss JIRA] (WFCORE-934) IPv6ScopeIdMatchUnitTestCase fails on some machines
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFCORE-934?page=com.atlassian.jira.plugin... ]
Marek Kopecký closed WFCORE-934.
--------------------------------
Resolution: Duplicate Issue
Duplicite issue with WFCORE-794
> IPv6ScopeIdMatchUnitTestCase fails on some machines
> ---------------------------------------------------
>
> Key: WFCORE-934
> URL: https://issues.jboss.org/browse/WFCORE-934
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 2.0.0.Beta4
> Reporter: Marek Kopecký
> Assignee: Brian Stansberry
>
> *Description of problem:*
> org.jboss.as.controller.interfaces.IPv6ScopeIdMatchUnitTestCase#testNonLoopback in WildFly Core TS fails on Solaris11 SPARC.
> *How reproducible:*
> Always with this configuration on Solaris11 SPARC:
> {noformat}
> $ /usr/sbin/ifconfig -a
> lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
> inet 127.0.0.1 netmask ff000000
> net0: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.91.211 netmask fffff800 broadcast 10.16.95.255
> net0:1: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.179.24 netmask fffff800 broadcast 10.16.183.255
> net0:2: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.179.25 netmask fffff800 broadcast 10.16.183.255
> net0:3: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.179.26 netmask fffff800 broadcast 10.16.183.255
> net0:4: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.179.27 netmask fffff800 broadcast 10.16.183.255
> lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
> inet6 ::1/128
> net0: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 fe80::8:20ff:fe6d:eab1/10
> net0:1: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 fe80::8:20ff:fe6d:eab2/10
> net0:2: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 fe80::8:20ff:fe6d:eab0/10
> net0:3: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f::ffff:164/64
> net0:4: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f::ffff:165/64
> net0:5: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f::ffff:166/64
> net0:6: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f::ffff:167/64
> net0:7: flags=120002080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f:8:20ff:fe6d:eab0/64
> $
> {noformat}
> *Steps to Reproduce:*
> # cd controller
> # mvn test -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dtest=IPv6ScopeIdMatchUnitTestCase
> *Actual results:*
> * StackTrace:
> {noformat}
> java.lang.AssertionError: expected:</fe80:0:0:0:8:20ff:fe6d:eab0%net0:2> but was:<null>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at org.jboss.as.controller.interfaces.IPv6ScopeIdMatchUnitTestCase.testNonLoopback(IPv6ScopeIdMatchUnitTestCase.java:129)
> {noformat}
> * Test output:
> {noformat}
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address fe80:0:0:0:8:20ff:fe6d:eab2%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:8:20ff:fe6d:eab0%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address fe80:0:0:0:8:20ff:fe6d:eab1%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:0:0:ffff:167%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:0:0:ffff:166%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:0:0:ffff:165%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:0:0:ffff:164%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address fe80:0:0:0:8:20ff:fe6d:eab0%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address fe80:0:0:0:8:20ff:fe6d:eab0%net0:2, so cannot match it to any InetAddress
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5716) Wrong handling of request context for remote EJB calls
by Ste Gr (JIRA)
[ https://issues.jboss.org/browse/WFLY-5716?page=com.atlassian.jira.plugin.... ]
Ste Gr commented on WFLY-5716:
------------------------------
I've extended my test and added event observers for the request scope (initialize and destroy). The context will be created but the bean is not affected.
*wfly5716-app*
{code}
13:32:58,206 INFO [stdout] (default task-8) [app] IFrameworkResourceManager = Proxy for remote EJB StatelessEJBLocator for "/wfly5716-fw/WebFrameworkImpl", view is interface testing.wfly5716.share.IWebFramework, affinity is None
13:32:58,206 INFO [stdout] (default task-8) New request: Request context initialized for EJB invocation [class org.jboss.weld.event.ContextEvent]
13:32:58,206 INFO [stdout] (default task-8) [fw] invoke WebFrameworkImpl#resolveUser
13:32:58,206 INFO [stdout] (default task-8) [fw] testing.wfly5716.fw.RequestBean@2c5c8faf INIT
13:32:58,206 INFO [stdout] (default task-8) [fw] testing.wfly5716.fw.RequestBean@2c5c8faf DUMMY
13:32:58,206 INFO [stdout] (default task-8) [fw] testing.wfly5716.fw.RequestBean@2c5c8faf DESTROY
13:32:58,206 INFO [stdout] (default task-8) End request: Request context destroyed after EJB invocation [class org.jboss.weld.event.ContextEvent]
13:32:58,206 INFO [stdout] (default task-8) New request: Request context initialized for EJB invocation [class org.jboss.weld.event.ContextEvent]
13:32:58,206 INFO [stdout] (default task-8) [fw] invoke WebFrameworkImpl#resolveRights
13:32:58,206 INFO [stdout] (default task-8) [fw] testing.wfly5716.fw.RequestBean@2c5c8faf DUMMY
13:32:58,206 INFO [stdout] (default task-8) End request: Request context destroyed after EJB invocation [class org.jboss.weld.event.ContextEvent]
{code}
> Wrong handling of request context for remote EJB calls
> ------------------------------------------------------
>
> Key: WFLY-5716
> URL: https://issues.jboss.org/browse/WFLY-5716
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB
> Affects Versions: 9.0.0.Final, 10.0.0.CR4
> Reporter: Ste Gr
> Assignee: Stuart Douglas
> Attachments: wfly5716.zip
>
>
> Two applications deployed to Wildfly. The first one provides a singleton remote ejb which uses request scoped beans (in this case a RESOURCE_LOCAL entity manager manged by a CDI producer/disposer, but +all+ request scoped beans are affected). The second application uses that EJB to get some data only accessible by the first application.
> A request is made to the second app from a browser. The app will get the remote EJB and invokes two methods on it. The first method produces the entity manager, accesses the database and returns the result. The entity manager will be disposed again. The second method won't produce a new entity manager but tries to re-use the one from the previous invokation. This fails as the entity manager was disposed.
> If the same use-case is made using the first app everythings works as desired. But it doesn't look right (or the request context is joined because it is the same application). It produces the the entity manager on the first invocation and closes it as soon as the whole request made from the browser is completed. Thats why the second invokation has a valid entity manager to work with.
> I don't know the spec but:
> - either the first EJB invokation from second app to first app is not allowed to dispose the request context (all the request scoped beans)
> - or each invokation must get its own request context (entity manager must be produced and disposed again).
> I've made a [stackoverflow thread|http://stackoverflow.com/q/33826720/1741604] which shows some code examples.
> (JBoss AS 7.1.3.Final is also affected but it is not available in 'affected version/s')
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5715) Wildfly 9/10 removing deployments after a certain time
by Sven Ulrich (JIRA)
[ https://issues.jboss.org/browse/WFLY-5715?page=com.atlassian.jira.plugin.... ]
Sven Ulrich updated WFLY-5715:
------------------------------
Attachment: Dummy.war
> Wildfly 9/10 removing deployments after a certain time
> ------------------------------------------------------
>
> Key: WFLY-5715
> URL: https://issues.jboss.org/browse/WFLY-5715
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 9.0.2.Final, 10.0.0.CR4
> Environment: Ubuntu 12.04.5 LTS
> Reporter: Sven Ulrich
> Assignee: ehsavoie Hugonnet
> Attachments: Dummy.war, ifxjdbc_4.10.jar, server.log, standalone.xml
>
>
> I have setup a Wildfly 10 CR4 on a Ubuntu 12.04.5 LTS. The server is running fine.
> Now I want to deploye my jar files (jdbc driver and jee apps).
> All is uploaded via the management web interface running on the port 10010 (added offset of 20 because a WF8 is running on Port 8080)
> First I log into the web interface and navigate to the tab deployments. Then I use the button add.
> In the popup window:
> 1: Upload a new deployment
> 2: I choose ifxjdbc_4.10.jar for e.g.
> 3: In Verify upload enabled is set and everything else is standard
> 4: The upload takes round about 30sec.
> Now I can setup datasources for this driver and its works fine. My next step is to stop the server and restart it. Then the server wont start because the content is missing for the jar.
> It wont be an issue for me if i could be 100% sure that the server wont be restarted anytime :)
> I have added my standalone.xml and the log with hopefully all needed information.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1143) Cancel button in JConsole do nothing
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1143?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-1143:
------------------------------------------
Ok, I see what you are saying - I agree that cancel button should be removed or the behaviour changed.
The top level connection dialogue in jconcole will close if you click cancel but they also have a menu item to bring it up again - for ours I think there are two options: -
1 - When a user clicks cancel switch them to a different tab (not sure if this is possible)
2 - Remove the cancel button.
> Cancel button in JConsole do nothing
> ------------------------------------
>
> Key: WFCORE-1143
> URL: https://issues.jboss.org/browse/WFCORE-1143
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.0.Final
> Reporter: Marek Kopecký
> Assignee: Tomaz Cerar
> Attachments: cancel_button.png
>
>
> *Description of problem:*
> Cancel button in JConsole do nothing. It should be removed from JConsole
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # cd EAP_HOME
> # ./bin/standalone.sh &
> # ./bin/jconsole.sh
> # Click to CLI tab
> # Click to "Cancel" button
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1143) Cancel button in JConsole do nothing
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1143?page=com.atlassian.jira.plugi... ]
Marek Kopecký commented on WFCORE-1143:
---------------------------------------
I was connected to "Local Process". I didn't use Remoting JMX.
> Cancel button in JConsole do nothing
> ------------------------------------
>
> Key: WFCORE-1143
> URL: https://issues.jboss.org/browse/WFCORE-1143
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.0.Final
> Reporter: Marek Kopecký
> Assignee: Tomaz Cerar
> Attachments: cancel_button.png
>
>
> *Description of problem:*
> Cancel button in JConsole do nothing. It should be removed from JConsole
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # cd EAP_HOME
> # ./bin/standalone.sh &
> # ./bin/jconsole.sh
> # Click to CLI tab
> # Click to "Cancel" button
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5673) Equals signs in cookies configuration is not working in Domain mode
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5673?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-5673:
-----------------------------------
What is the exact version of WildFly you are using?
Can you also try on at least 8.2.x or even 9?
As I cannot reproduce your behavior on latest code, and looking at the history of changes in this area it was changing rapidly around 8.1.0.Final time
> Equals signs in cookies configuration is not working in Domain mode
> -------------------------------------------------------------------
>
> Key: WFLY-5673
> URL: https://issues.jboss.org/browse/WFLY-5673
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Web (Undertow)
> Affects Versions: 8.1.0.Final
> Reporter: Boominathan Shanmugam
> Assignee: Tomaz Cerar
>
> The property that allows WILDFLY 8.1 in standalone mode to have = in cookie values
> <subsystem xmlns="urn:jboss:domain:undertow:1.1">
> <buffer-cache name="default"/>
> <server name="default-server">
> <http-listener name="default" socket-binding="http" allow-equals-in-cookie-value="true"/>
> The issue we are seeing is that setting that to true, via CLI, in domain mode does not make the code behave the same way as it does in standalone. Could be that there are more changes required in domain mode than just setting this setting, but I could not find anything. Could also be that caching is somehow not letting the new value in, tho I did restart the entire system, including the DC (even deleted the /tmp folder on both nodes and on DC).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-917) "Could not initialize class java.lang.StringCoding" on HP-UX
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFCORE-917?page=com.atlassian.jira.plugin... ]
Marek Kopecký commented on WFCORE-917:
--------------------------------------
[~gene.bradley]: LANG property is set in environment:
{noformat}
$ env | grep LANG
LANG=en_US.utf8
$
{noformat}
> "Could not initialize class java.lang.StringCoding" on HP-UX
> ------------------------------------------------------------
>
> Key: WFCORE-917
> URL: https://issues.jboss.org/browse/WFCORE-917
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Marek Kopecký
> Assignee: Jason Greene
>
> *Description of problem:*
> "NoClassDefFoundError: Could not initialize class java.lang.StringCoding" occurs on HP-UX in a non-interactive mode of CLI
> This is intermittent issue.
> This exception occurs even without running domain server.
> *How reproducible:*
> 2% on HP-UX
> *Steps to Reproduce: (this reproducer always hits this issue)*
> # ./domain.sh \# optional step
> # {noformat}for (( i = 1; i <= 200 ; i++ )) ; do
> ./jboss-cli.sh -c command="/profile=test:add"
> ./jboss-cli.sh -c command="/profile=test:remove"
> done{noformat}
> *Actual results:*
> {noformat}
> Exception: java.lang.NullPointerException thrown from the UncaughtExceptionHandler in thread "Finalizer"
> Error occurred during initialization of VM
> java.lang.NoClassDefFoundError: Could not initialize class java.lang.StringCoding
> at java.lang.String.<init>(String.java:534)
> at java.lang.String.<init>(String.java:554)
> at java.lang.System.initProperties(Native Method)
> at java.lang.System.initializeSystemClass(System.java:1164)
> {noformat}
> *Expected results:*
> No errors
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1143) Cancel button in JConsole do nothing
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1143?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-1143:
------------------------------------------
Ok that one does appear to be our code - WFCORE is the correct project as that is where the code for the CLI tab lives.
Looking at the screen shot you were already connected to the server - how did you connect? If you are connected using Remoting JMX there should be no need to authenticate again as that tab is supposed to share the same connection.
> Cancel button in JConsole do nothing
> ------------------------------------
>
> Key: WFCORE-1143
> URL: https://issues.jboss.org/browse/WFCORE-1143
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.0.Final
> Reporter: Marek Kopecký
> Assignee: Tomaz Cerar
> Attachments: cancel_button.png
>
>
> *Description of problem:*
> Cancel button in JConsole do nothing. It should be removed from JConsole
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # cd EAP_HOME
> # ./bin/standalone.sh &
> # ./bin/jconsole.sh
> # Click to CLI tab
> # Click to "Cancel" button
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1143) Cancel button in JConsole do nothing
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1143?page=com.atlassian.jira.plugi... ]
Marek Kopecký commented on WFCORE-1143:
---------------------------------------
[~dlofthouse]: Screen shot is attached. This button is part "login dialog" in CLI tab. "Login dialog" disappear after login to CLI.
> Cancel button in JConsole do nothing
> ------------------------------------
>
> Key: WFCORE-1143
> URL: https://issues.jboss.org/browse/WFCORE-1143
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.0.Final
> Reporter: Marek Kopecký
> Assignee: Tomaz Cerar
> Attachments: cancel_button.png
>
>
> *Description of problem:*
> Cancel button in JConsole do nothing. It should be removed from JConsole
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # cd EAP_HOME
> # ./bin/standalone.sh &
> # ./bin/jconsole.sh
> # Click to CLI tab
> # Click to "Cancel" button
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1143) Cancel button in JConsole do nothing
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1143?page=com.atlassian.jira.plugi... ]
Marek Kopecký updated WFCORE-1143:
----------------------------------
Attachment: cancel_button.png
> Cancel button in JConsole do nothing
> ------------------------------------
>
> Key: WFCORE-1143
> URL: https://issues.jboss.org/browse/WFCORE-1143
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.0.Final
> Reporter: Marek Kopecký
> Assignee: Tomaz Cerar
> Attachments: cancel_button.png
>
>
> *Description of problem:*
> Cancel button in JConsole do nothing. It should be removed from JConsole
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # cd EAP_HOME
> # ./bin/standalone.sh &
> # ./bin/jconsole.sh
> # Click to CLI tab
> # Click to "Cancel" button
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months