[JBoss JIRA] (WFLY-8309) build.sh and integration-tests.sh scripts doesn't work on Solaris SPARC
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFLY-8309?page=com.atlassian.jira.plugin.... ]
Romain Pelisse reopened WFLY-8309:
----------------------------------
Assignee: Romain Pelisse (was: Peter Palaga)
Previous fix from Peter did not cut it, so reopening.
> build.sh and integration-tests.sh scripts doesn't work on Solaris SPARC
> -----------------------------------------------------------------------
>
> Key: WFLY-8309
> URL: https://issues.jboss.org/browse/WFLY-8309
> Project: WildFly
> Issue Type: Bug
> Components: Build System, Test Suite
> Reporter: Peter Palaga
> Assignee: Romain Pelisse
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
>
> Solaris 10 SPARC and Solaris 11 SPARC are supported platforms.
> This issue is regression against EAP 7.1.0.DR11.
> *Wrong behaviour in EAP 7.1.0.DR12*
> build.sh and integration-tests.sh scripts doesn't work on Solaris SPARC.
> *Desired behaviour*
> build.sh and integration-tests.sh scripts should work on Solaris SPARC.
> *Solaris 10*
> * Solaris 10 SPARC release information:
> {noformat}
> [hudson@dev139-03 ~]$ cat /etc/release
> Oracle Solaris 10 1/13 s10s_u11wos_24a SPARC
> Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights reserved.
> Assembled 17 January 2013
> [hudson@dev139-03 ~]$
> {noformat}
> * logs from build.sh
> {noformat}
> 07:39:36 + ./build.sh -Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-unit-solaris/abacf11d/eap-local-maven-repository -fae -Dmaven.test.failure.ignore=true -Dts.noSmoke
> 07:39:36 ./build.sh: syntax error at line 20: `DIRNAME="$( cd "$' unexpected
> {noformat}
> * logs from integration-tests.sh:
> {noformat}
> 07:43:10 + ./integration-tests.sh -Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/abacf11d/eap-local-maven-repository -fae -Dmaven.test.failure.ignore=true -Dnode0=10.16.178.25 -Dnode1=10.16.178.26 -Dmcast=227.43.91.56 -DallTests -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/abacf11d/jboss-eap-7.1
> 07:43:10 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/abacf11d/mvnw install -Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/abacf11d/eap-local-maven-repository -fae -Dmaven.test.failure.ignore=true -Dnode0=10.16.178.25 -Dnode1=10.16.178.26 -Dmcast=227.43.91.56 -DallTests -fae -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/abacf11d/jboss-eap-7.1 -s /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/abacf11d/tools/maven/conf/settings.xml
> 07:43:10 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/abacf11d/mvnw: syntax error at line 190: `(' unexpected
> {noformat}
> *Solaris 11*
> * Solaris 11 SPARC release information:
> {noformat}
> [hudson@dev34-03 ~]$ cat /etc/release
> Oracle Solaris 11.3 SPARC
> Copyright (c) 1983, 2016, Oracle and/or its affiliates. All rights reserved.
> Assembled 03 August 2016
> [hudson@dev34-03 ~]$
> {noformat}
> * logs from build.sh
> {noformat}
> 07:39:35 + ./build.sh -Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-unit-solaris/e745cc07/eap-local-maven-repository -fae -Dmaven.test.failure.ignore=true -Dts.noSmoke
> 07:39:35 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-unit-solaris/e745cc07/mvnw install '-Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-unit-solaris/e745cc07/eap-local-maven-repository' '-fae' '-Dmaven.test.failure.ignore=true' '-Dts.noSmoke'
> 07:39:35 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-unit-solaris/e745cc07/mvnw[190]: local: not found [No such file or directory]
> 07:39:35 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-unit-solaris/e745cc07/mvnw[191]: local: not found [No such file or directory]
> 07:39:36 Error: Could not find or load main class org.apache.maven.wrapper.MavenWrapperMain
> {noformat}
> * logs from integration-tests.sh:
> {noformat}
> 7:43:15 + ./integration-tests.sh -Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/eap-local-maven-repository -fae -Dmaven.test.failure.ignore=true -Dnode0=10.16.179.32 -Dnode1=10.16.179.33 -Dmcast=227.43.91.214 -DallTests -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/jboss-eap-7.1
> 07:43:15 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/mvnw install -Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/eap-local-maven-repository -fae -Dmaven.test.failure.ignore=true -Dnode0=10.16.179.32 -Dnode1=10.16.179.33 -Dmcast=227.43.91.214 -DallTests -fae -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/jboss-eap-7.1 -s /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/tools/maven/conf/settings.xml
> 07:43:15 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/mvnw[190]: local: not found [No such file or directory]
> 07:43:15 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/mvnw[191]: local: not found [No such file or directory]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-1563) Failed CLI batch command with "deploy --force" for replace deployment
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1563?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1563:
-------------------------------------------------
Radovan Netuka <rnetuka(a)redhat.com> changed the Status of [bug 1417679|https://bugzilla.redhat.com/show_bug.cgi?id=1417679] from POST to MODIFIED
> Failed CLI batch command with "deploy --force" for replace deployment
> ---------------------------------------------------------------------
>
> Key: WFCORE-1563
> URL: https://issues.jboss.org/browse/WFCORE-1563
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.1.0.Final, 3.0.0.Alpha1
> Reporter: Ted Won
> Assignee: Ted Won
> Priority: Minor
> Labels: cli, jboss
> Fix For: 3.0.0.Alpha2
>
> Attachments: jboss-ejb-in-ear.ear
>
>
> Using 'deploy --force' command on CLI batch mode fails and returns an error message: "Request is missing the address part."
> {code:title=Command}
> jboss-cli.sh --connect --controller=127.0.0.1:9999 --user=admin --password=xxx --file="deploy.cli"
> {code}
> {code:title=deploy.cli}
> batch
> deploy --force ./jboss-ejb-in-ear.ear
> run-batch
> {code}
> {panel:title=Full Error message}
> Failed to handle 'run-batch': org.jboss.as.cli.CommandFormatException: Request is missing the address part.: Request is missing the address part.
> or
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): Request is missing the address part.
> {panel}
> {panel:title=Expected message}
> The batch executed successfully
> {panel}
> However, it's working in "WildFly 10 CLI interactive mode" and "JBoss AS 7 CLI batch" without error.
> There is no adding "address" key in buildDeploymentReplace() of DeployHandler like below.
> Even though on CLI batch mode it validates existence of "address" key in request with Util.validateRequest(), when 'run-batch' command execute in org.jboss.as.cli.handlers.batch.BatchRunHandler.doHandle()
> -------------------------------------------------------------------------------------------
> * First deploy: add by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentAdd()
> {code}
> {
> "operation" => "add",
> "address" => {"deployment" => "jboss-ejb-in-ear.ear"},
> "content" => [{"bytes" => bytes {
> ...
> }}]
> }
> {code}
> -------------------------------------------------------------------------------------------
> * After deploy: replace by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentReplace()
> {code}
> {
> "operation" => "full-replace-deployment",
> "name" => "jboss-ejb-in-ear.ear",
> "enabled" => true,
> "content" => [{"bytes" => bytes {
> ...
> }}]
> }
> {code}
> -------------------------------------------------------------------------------------------
> * Expected by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentReplace()
> {code}
> {
> "operation" => "full-replace-deployment",
> "name" => "jboss-ejb-in-ear.ear",
> "address" => [],
> "enabled" => true,
> "content" => [{"bytes" => bytes {
> ...
> }}]
> }
> {code}
> -------------------------------------------------------------------------------------------
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2283) Make 'required' attributes clearer when using tab completion within CLI
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2283?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-2283:
----------------------------------------------
We have converged toward a solution.
[~weeks.c], in case you want to provide feedback, we have a [document|https://docs.google.com/document/d/1HuoJzr01XES1pbbvpoM2A7K_gVTg...] with spec, examples and link to the repository.
> Make 'required' attributes clearer when using tab completion within CLI
> -----------------------------------------------------------------------
>
> Key: WFCORE-2283
> URL: https://issues.jboss.org/browse/WFCORE-2283
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Darran Lofthouse
> Assignee: Jean-Francois Denise
>
> The following is some example output pressing tab to reveal the parameters of 'add': -
> {{[standalone@localhost:9990 /] ./subsystem=elytron/key-store=localhost:add(
> ! alias-filter credential-reference path provider-name providers relative-to required type }}
> From this is it not clear which are actually required.
> Suggestions to make it clearer: -
> * Show required / optional in different colours.
> * Add something to the required attributes e.g. '*'
> * Add something to the optional requirements e.g. {optional_arg}
> Maybe this can go one step further and take into account arguments already added by the user, especially where attributes require another attribute or are an alternative.
> Once an attribute is identified as being an alternative to another attribute maybe it should be omitted altogether from the list or maybe also have something adding to it !attr_name.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (ELY-49) Unable to build wildfly-sasl using the IBM JDK
by Pawel Wtorek (JIRA)
[ https://issues.jboss.org/browse/ELY-49?page=com.atlassian.jira.plugin.sys... ]
Pawel Wtorek commented on ELY-49:
---------------------------------
The maven-injection-plugin works fine, I use it and I have no reservations. Are you using the <className> tag in the section:
{code}
<bytecodeInjection>
<expression>${mavenVersion}</expression>
<targetMembers>
<methodBodyReturn>
<className>com.project.MyClassVersion</className>
<methodName>getVersionMaven</methodName>
</methodBodyReturn>
</targetMembers>
</bytecodeInjection>
{code}
I suspect this error is due to an invalid path in className and because of missing correct class name or path
> Unable to build wildfly-sasl using the IBM JDK
> ----------------------------------------------
>
> Key: ELY-49
> URL: https://issues.jboss.org/browse/ELY-49
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SASL
> Environment: java version "1.7.0"
> Java(TM) SE Runtime Environment (build pxa6470_27-20131115_04)
> IBM J9 VM (build 2.7, JRE 1.7.0 Linux amd64-64 Compressed References 20131114_175264 (JIT enabled, AOT enabled)
> J9VM - R27_Java727_GA_20131114_0833_B175264
> JIT - tr.r13.java_20131113_50523
> GC - R27_Java727_GA_20131114_0833_B175264_CMPRSS
> J9CL - 20131114_175264)
> JCL - 20131113_01 based on Oracle 7u45-b18
> Reporter: Darran Lofthouse
> Assignee: David Lloyd
> Fix For: 1.0.0.Alpha1
>
>
> The build currently fails with the following error: -
> {noformat}
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ wildfly-sasl ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 3 resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ wildfly-sasl ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 47 source files to /home/darranl/src/wildfly/wildfly-sasl/target/classes
> [INFO]
> [INFO] --- maven-injection-plugin:1.0.2:bytecode (default) @ wildfly-sasl ---
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 3.377 s
> [INFO] Finished at: 2014-06-25T11:42:26+00:00
> [INFO] Final Memory: 17M/34M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.jboss.maven.plugins:maven-injection-plugin:1.0.2:bytecode (default) on project wildfly-sasl: Unable to resolve class file path: NullPointerException -> [Help 1]
> [ERROR]
> {noformat}
> As the local testsuite now contains interoperability testing with JDK supplied implementations being able to run the build with other vendors implementations is important.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (ELY-1053) Review realm attribute in Elytron authentication-configuration
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/ELY-1053?page=com.atlassian.jira.plugin.s... ]
Ondrej Lukas closed ELY-1053.
-----------------------------
Resolution: Rejected
> Review realm attribute in Elytron authentication-configuration
> --------------------------------------------------------------
>
> Key: ELY-1053
> URL: https://issues.jboss.org/browse/ELY-1053
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta31-SP1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
>
> Is there any real scenario for usage of {{realm}} attribute in authentication-configuration?
> If server provides DIGEST-MD5 mechanism and client chooses it, then server provides name of realm which should be used for creating {{user:realm:password}} digest. It was the original reason which was provided to us. However it seems that reason for that attribute is currently different. What is the reason for attribute {{realm}} in authentication-configuration?
> This information will be also needed for documentation.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2626) Network interface selection criteria is not working for a duplicate IP addresses but one is down
by Osamu Nagano (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2626?page=com.atlassian.jira.plugi... ]
Osamu Nagano updated WFCORE-2626:
---------------------------------
Environment:
On Fedora 24 KVM instance, I added 2 extra NICs those are recognized as ens9 and ens10. Both have 192.168.1.1 but one is down.
{code}
# ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:ca:86:e2 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.117/24 brd 192.168.122.255 scope global dynamic ens3
valid_lft 3483sec preferred_lft 3483sec
inet6 fe80::782d:5d87:243d:917f/64 scope link
valid_lft forever preferred_lft forever
3: ens9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:ee:c6:16 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 scope global ens9
valid_lft forever preferred_lft forever
4: ens10: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether 52:54:00:52:78:ca brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 scope global ens10
valid_lft forever preferred_lft forever
{code}
was:
On Fedora 24 KVM instance, I added 2 extra NICs those are recognized as ens9 and ens10. Both have 192.168.1.1 but one is down.
{code}
# ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:ca:86:e2 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.117/24 brd 192.168.122.255 scope global dynamic ens3
valid_lft 3483sec preferred_lft 3483sec
inet6 fe80::782d:5d87:243d:917f/64 scope link
valid_lft forever preferred_lft forever
3: ens9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:ee:c6:16 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 scope global ens9
valid_lft forever preferred_lft forever
4: ens10: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether 52:54:00:52:78:ca brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 scope global ens10
valid_lft forever preferred_lft forever
{code}
Note that those devices should be unmanaged by NetworkManager by "{{nmcli device set ens9 managed no}}". And you can give an IP address by "{{ip addr add 192.168.1.1/24 dev ens9}}". Repeat the same on ens10.
> Network interface selection criteria is not working for a duplicate IP addresses but one is down
> ------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2626
> URL: https://issues.jboss.org/browse/WFCORE-2626
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Environment: On Fedora 24 KVM instance, I added 2 extra NICs those are recognized as ens9 and ens10. Both have 192.168.1.1 but one is down.
> {code}
> # ip address show
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
> link/ether 52:54:00:ca:86:e2 brd ff:ff:ff:ff:ff:ff
> inet 192.168.122.117/24 brd 192.168.122.255 scope global dynamic ens3
> valid_lft 3483sec preferred_lft 3483sec
> inet6 fe80::782d:5d87:243d:917f/64 scope link
> valid_lft forever preferred_lft forever
> 3: ens9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
> link/ether 52:54:00:ee:c6:16 brd ff:ff:ff:ff:ff:ff
> inet 192.168.1.1/24 scope global ens9
> valid_lft forever preferred_lft forever
> 4: ens10: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
> link/ether 52:54:00:52:78:ca brd ff:ff:ff:ff:ff:ff
> inet 192.168.1.1/24 scope global ens10
> valid_lft forever preferred_lft forever
> {code}
> Reporter: Osamu Nagano
> Assignee: Brian Stansberry
>
> In the standalone.xml, there are {{<up/>}} criterion which is sufficient to identify a unique NIC under the environment described above.
> {code}
> <interfaces>
> <interface name="management">
> <up/>
> <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
> </interface>
> <interface name="public">
> <up/>
> <inet-address value="${jboss.bind.address:127.0.0.1}"/>
> </interface>
> </interfaces>
> {code}
> But it says "ambiguous". WildFly 10.1.0.Final doesn't show this error.
> {code}
> # $JBOSS_HOME/bin/standalone.sh -b 192.168.1.1 -bmanagement=192.168.1.1
> ...
> 04:38:52,839 WARN [org.jboss.as.controller] (MSC service thread 1-3) WFLYCTL0023: Value '192.168.1.1' for interface selection criteria 'inet-address' is ambiguous, as more than one address or network interface available on the machine matches it. Because of this ambiguity,
> no address will be selected as a match. Matching addresses: [/192.168.1.1]. Matching network interfaces: [ens9, ens10].
> 04:38:52,840 WARN [org.jboss.as.controller] (MSC service thread 1-4) WFLYCTL0023: Value '192.168.1.1' for interface selection criteria 'inet-address' is ambiguous, as more than one address or network interface available on the machine matches it. Because of this ambiguity,
> no address will be selected as a match. Matching addresses: [/192.168.1.1]. Matching network interfaces: [ens9, ens10].
> 04:38:52,840 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.network.public: org.jboss.msc.service.StartException in service jboss.network.public: WFLYSRV0082: failed to resolve interface public
> at org.jboss.as.server.services.net.NetworkInterfaceService.start(NetworkInterfaceService.java:91)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> 04:38:52,841 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.network.management: org.jboss.msc.service.StartException in service jboss.network.management: WFLYSRV0082: failed to resolve interface management
> at org.jboss.as.server.services.net.NetworkInterfaceService.start(NetworkInterfaceService.java:91)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2626) Network interface selection criteria is not working for a duplicate IP addresses but one is down
by Osamu Nagano (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2626?page=com.atlassian.jira.plugi... ]
Osamu Nagano updated WFCORE-2626:
---------------------------------
Steps to Reproduce:
Suppose 2 NICs are added (by virt-manager) and recognised as "ens9" and "ens10" respectively. These need to be umanamged by NetworkManager. Then asign the same IP address and disable "ens10".
{code}
# nmcli device set ens9 managed no
# ip addr add 192.168.1.1/24 dev ens9
(Repeat the same for "ens10".)
# ip link set ens10 down
{code}
was:See "Environment".
> Network interface selection criteria is not working for a duplicate IP addresses but one is down
> ------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2626
> URL: https://issues.jboss.org/browse/WFCORE-2626
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Environment: On Fedora 24 KVM instance, I added 2 extra NICs those are recognized as ens9 and ens10. Both have 192.168.1.1 but one is down.
> {code}
> # ip address show
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
> link/ether 52:54:00:ca:86:e2 brd ff:ff:ff:ff:ff:ff
> inet 192.168.122.117/24 brd 192.168.122.255 scope global dynamic ens3
> valid_lft 3483sec preferred_lft 3483sec
> inet6 fe80::782d:5d87:243d:917f/64 scope link
> valid_lft forever preferred_lft forever
> 3: ens9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
> link/ether 52:54:00:ee:c6:16 brd ff:ff:ff:ff:ff:ff
> inet 192.168.1.1/24 scope global ens9
> valid_lft forever preferred_lft forever
> 4: ens10: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
> link/ether 52:54:00:52:78:ca brd ff:ff:ff:ff:ff:ff
> inet 192.168.1.1/24 scope global ens10
> valid_lft forever preferred_lft forever
> {code}
> Note that those devices should be unmanaged by NetworkManager by "{{nmcli device set ens9 managed no}}". And you can give an IP address by "{{ip addr add 192.168.1.1/24 dev ens9}}". Repeat the same on ens10.
> Reporter: Osamu Nagano
> Assignee: Brian Stansberry
>
> In the standalone.xml, there are {{<up/>}} criterion which is sufficient to identify a unique NIC under the environment described above.
> {code}
> <interfaces>
> <interface name="management">
> <up/>
> <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
> </interface>
> <interface name="public">
> <up/>
> <inet-address value="${jboss.bind.address:127.0.0.1}"/>
> </interface>
> </interfaces>
> {code}
> But it says "ambiguous". WildFly 10.1.0.Final doesn't show this error.
> {code}
> # $JBOSS_HOME/bin/standalone.sh -b 192.168.1.1 -bmanagement=192.168.1.1
> ...
> 04:38:52,839 WARN [org.jboss.as.controller] (MSC service thread 1-3) WFLYCTL0023: Value '192.168.1.1' for interface selection criteria 'inet-address' is ambiguous, as more than one address or network interface available on the machine matches it. Because of this ambiguity,
> no address will be selected as a match. Matching addresses: [/192.168.1.1]. Matching network interfaces: [ens9, ens10].
> 04:38:52,840 WARN [org.jboss.as.controller] (MSC service thread 1-4) WFLYCTL0023: Value '192.168.1.1' for interface selection criteria 'inet-address' is ambiguous, as more than one address or network interface available on the machine matches it. Because of this ambiguity,
> no address will be selected as a match. Matching addresses: [/192.168.1.1]. Matching network interfaces: [ens9, ens10].
> 04:38:52,840 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.network.public: org.jboss.msc.service.StartException in service jboss.network.public: WFLYSRV0082: failed to resolve interface public
> at org.jboss.as.server.services.net.NetworkInterfaceService.start(NetworkInterfaceService.java:91)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> 04:38:52,841 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.network.management: org.jboss.msc.service.StartException in service jboss.network.management: WFLYSRV0082: failed to resolve interface management
> at org.jboss.as.server.services.net.NetworkInterfaceService.start(NetworkInterfaceService.java:91)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (DROOLS-1512) Nullpointer exception when running a decision table with "null" as the input
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1512?page=com.atlassian.jira.plugi... ]
Edson Tirelli commented on DROOLS-1512:
---------------------------------------
Fixed on the linked PR.
> Nullpointer exception when running a decision table with "null" as the input
> ----------------------------------------------------------------------------
>
> Key: DROOLS-1512
> URL: https://issues.jboss.org/browse/DROOLS-1512
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Reporter: Mélanie Gauthier
> Assignee: Edson Tirelli
> Attachments: NPE.dmn
>
>
> Here is the stack trace:
> WARN org.kie.dmn.core.compiler.DMNFEELHelper - A non-critical error happened while evaluating a unary test. Execution will continue.
> java.lang.NullPointerException
> at org.kie.dmn.core.compiler.DMNFEELHelper.valueMatchesInUnaryTests(DMNFEELHelper.java:64)
> at org.kie.dmn.core.impl.DMNRuntimeImpl.checkDependencyValueIsValid(DMNRuntimeImpl.java:361)
> at org.kie.dmn.core.impl.DMNRuntimeImpl.evaluateDecision(DMNRuntimeImpl.java:256)
> at org.kie.dmn.core.impl.DMNRuntimeImpl.evaluateAll(DMNRuntimeImpl.java:90)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months