[JBoss JIRA] (WFLY-9876) ActiveMQ Artemis with IPv6 and Scope fails
by Jens Popp (JIRA)
[ https://issues.jboss.org/browse/WFLY-9876?page=com.atlassian.jira.plugin.... ]
Jens Popp updated WFLY-9876:
----------------------------
Description:
Somehow Java behaves differently on Linux and Windows regarding the IPv6 Network Interfaces. With a small programm you can test this:
{code}
Enumeration<NetworkInterface> interfaces = NetworkInterface.getNetworkInterfaces();
while (interfaces.hasMoreElements()) {
NetworkInterface netInterface = interfaces.nextElement();
Enumeration<InetAddress> address = netInterface.getInetAddresses();
while (address.hasMoreElements()) {
InetAddress addr = address.nextElement();
if (addr instanceof Inet6Address) {
Inet6Address inet6addr = (Inet6Address) addr;
if (!inet6addr.isLinkLocalAddress() && !inet6addr.isLoopbackAddress())
System.out.println(netInterface.getName() +":"+ inet6addr.isLinkLocalAddress() +":"+ inet6addr +" - "+ inet6addr.getScopedInterface());
}
}
}
{code}
In windows the scope will only be set for Link Local, in CentOS also for ULA addresses.
If I lookup the JMS from a ULA address (without scope) e.g. with:
{code}
String JMS_CONNECTION_FACTORY_JNDI = "jms/RemoteConnectionFactory";
Context context = getApplicationManager().getConnectionHandler().getContext();
TopicConnectionFactory cf = (TopicConnectionFactory) context.lookup(JMS_CONNECTION_FACTORY_JNDI);
{code}
The TopicConnectionFactory is ActiveMQJMSConnectionFactory. This factory receives a TransportConfiguration from the server that includes the server scope (IPv6 Address with NetworkInterface after % e.g. [fd00::d7dc:b4cc:2e2a:ea1%enp0s3]). Trying to create a topic connection with the TopicConnectionFactory will fail, since the client does not know the scope (enp0s3).
There is a bug fix in NettyConnector (HORNETQ-907) to strip this "%enp0s3" scope, but this BugFix does not work. The fix uses the standard InetAddress methods to parse the host String, which fails, if the host String contains a server scope (network interface) not available on the client. This will only cause an exception, if server and client have different names for the NetworkInterfaces! Testing e.g. on two identical Linux machines will not uncover the problem!
I think the underlying problem is, that the lookup distributes the server scope in the IPv6 Address. The scope should only be distributed for Link-local Addresses, for all other addresses the scope should be stripped already on the server and not be distributed during lookup.
was:
Somehow Java behaves differently on Linux and Windows regarding the IPv6 Network Interfaces. With a small programm you can test this:
Enumeration<NetworkInterface> interfaces = NetworkInterface.getNetworkInterfaces();
while (interfaces.hasMoreElements()) {
NetworkInterface netInterface = interfaces.nextElement();
Enumeration<InetAddress> address = netInterface.getInetAddresses();
while (address.hasMoreElements()) {
InetAddress addr = address.nextElement();
if (addr instanceof Inet6Address) {
Inet6Address inet6addr = (Inet6Address) addr;
if (!inet6addr.isLinkLocalAddress() && !inet6addr.isLoopbackAddress())
System.out.println(netInterface.getName() +":"+ inet6addr.isLinkLocalAddress() +":"+ inet6addr +" - "+ inet6addr.getScopedInterface());
}
}
}
In windows the scope will only be set for Link Local, in CentOS also for ULA addresses.
If I lookup the JMS from a ULA address (without scope) e.g. with:
String JMS_CONNECTION_FACTORY_JNDI = "jms/RemoteConnectionFactory";
Context context = getApplicationManager().getConnectionHandler().getContext();
TopicConnectionFactory cf = (TopicConnectionFactory) context.lookup(JMS_CONNECTION_FACTORY_JNDI);
The TopicConnectionFactory is ActiveMQJMSConnectionFactory. This factory receives a TransportConfiguration from the server that includes the server scope (IPv6 Address with NetworkInterface after % e.g. [fd00::d7dc:b4cc:2e2a:ea1%enp0s3]). Trying to create a topic connection with the TopicConnectionFactory will fail, since the client does not know the scope (enp0s3).
There is a bug fix in NettyConnector (HORNETQ-907) to strip this "%enp0s3" scope, but this BugFix does not work. The fix uses the standard InetAddress methods to parse the host String, which fails, if the host String contains a server scope (network interface) not available on the client. This will only cause an exception, if server and client have different names for the NetworkInterfaces! Testing e.g. on two identical Linux machines will not uncover the problem!
I think the underlying problem is, that the lookup distributes the server scope in the IPv6 Address. The scope should only be distributed for Link-local Addresses, for all other addresses the scope should be stripped already on the server and not be distributed during lookup.
> ActiveMQ Artemis with IPv6 and Scope fails
> ------------------------------------------
>
> Key: WFLY-9876
> URL: https://issues.jboss.org/browse/WFLY-9876
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.1.0.Final, 11.0.0.Final
> Environment: CentOS 7 with IPv6 ULA Address as server for Wildfly 10.1.0Final
> Windows 10 as client
> Both with Java 8u161 (64bit)
> Reporter: Jens Popp
> Assignee: Jeff Mesnil
>
> Somehow Java behaves differently on Linux and Windows regarding the IPv6 Network Interfaces. With a small programm you can test this:
> {code}
> Enumeration<NetworkInterface> interfaces = NetworkInterface.getNetworkInterfaces();
> while (interfaces.hasMoreElements()) {
> NetworkInterface netInterface = interfaces.nextElement();
> Enumeration<InetAddress> address = netInterface.getInetAddresses();
> while (address.hasMoreElements()) {
> InetAddress addr = address.nextElement();
> if (addr instanceof Inet6Address) {
> Inet6Address inet6addr = (Inet6Address) addr;
> if (!inet6addr.isLinkLocalAddress() && !inet6addr.isLoopbackAddress())
> System.out.println(netInterface.getName() +":"+ inet6addr.isLinkLocalAddress() +":"+ inet6addr +" - "+ inet6addr.getScopedInterface());
> }
> }
> }
> {code}
> In windows the scope will only be set for Link Local, in CentOS also for ULA addresses.
> If I lookup the JMS from a ULA address (without scope) e.g. with:
> {code}
> String JMS_CONNECTION_FACTORY_JNDI = "jms/RemoteConnectionFactory";
> Context context = getApplicationManager().getConnectionHandler().getContext();
> TopicConnectionFactory cf = (TopicConnectionFactory) context.lookup(JMS_CONNECTION_FACTORY_JNDI);
> {code}
> The TopicConnectionFactory is ActiveMQJMSConnectionFactory. This factory receives a TransportConfiguration from the server that includes the server scope (IPv6 Address with NetworkInterface after % e.g. [fd00::d7dc:b4cc:2e2a:ea1%enp0s3]). Trying to create a topic connection with the TopicConnectionFactory will fail, since the client does not know the scope (enp0s3).
> There is a bug fix in NettyConnector (HORNETQ-907) to strip this "%enp0s3" scope, but this BugFix does not work. The fix uses the standard InetAddress methods to parse the host String, which fails, if the host String contains a server scope (network interface) not available on the client. This will only cause an exception, if server and client have different names for the NetworkInterfaces! Testing e.g. on two identical Linux machines will not uncover the problem!
> I think the underlying problem is, that the lookup distributes the server scope in the IPv6 Address. The scope should only be distributed for Link-local Addresses, for all other addresses the scope should be stripped already on the server and not be distributed during lookup.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFLY-9876) ActiveMQ Artemis with IPv6 and Scope fails
by Jens Popp (JIRA)
Jens Popp created WFLY-9876:
-------------------------------
Summary: ActiveMQ Artemis with IPv6 and Scope fails
Key: WFLY-9876
URL: https://issues.jboss.org/browse/WFLY-9876
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 11.0.0.Final, 10.1.0.Final
Environment: CentOS 7 with IPv6 ULA Address as server for Wildfly 10.1.0Final
Windows 10 as client
Both with Java 8u161 (64bit)
Reporter: Jens Popp
Assignee: Jeff Mesnil
Somehow Java behaves differently on Linux and Windows regarding the IPv6 Network Interfaces. With a small programm you can test this:
Enumeration<NetworkInterface> interfaces = NetworkInterface.getNetworkInterfaces();
while (interfaces.hasMoreElements()) {
NetworkInterface netInterface = interfaces.nextElement();
Enumeration<InetAddress> address = netInterface.getInetAddresses();
while (address.hasMoreElements()) {
InetAddress addr = address.nextElement();
if (addr instanceof Inet6Address) {
Inet6Address inet6addr = (Inet6Address) addr;
if (!inet6addr.isLinkLocalAddress() && !inet6addr.isLoopbackAddress())
System.out.println(netInterface.getName() +":"+ inet6addr.isLinkLocalAddress() +":"+ inet6addr +" - "+ inet6addr.getScopedInterface());
}
}
}
In windows the scope will only be set for Link Local, in CentOS also for ULA addresses.
If I lookup the JMS from a ULA address (without scope) e.g. with:
String JMS_CONNECTION_FACTORY_JNDI = "jms/RemoteConnectionFactory";
Context context = getApplicationManager().getConnectionHandler().getContext();
TopicConnectionFactory cf = (TopicConnectionFactory) context.lookup(JMS_CONNECTION_FACTORY_JNDI);
The TopicConnectionFactory is ActiveMQJMSConnectionFactory. This factory receives a TransportConfiguration from the server that includes the server scope (IPv6 Address with NetworkInterface after % e.g. [fd00::d7dc:b4cc:2e2a:ea1%enp0s3]). Trying to create a topic connection with the TopicConnectionFactory will fail, since the client does not know the scope (enp0s3).
There is a bug fix in NettyConnector (HORNETQ-907) to strip this "%enp0s3" scope, but this BugFix does not work. The fix uses the standard InetAddress methods to parse the host String, which fails, if the host String contains a server scope (network interface) not available on the client. This will only cause an exception, if server and client have different names for the NetworkInterfaces! Testing e.g. on two identical Linux machines will not uncover the problem!
I think the underlying problem is, that the lookup distributes the server scope in the IPv6 Address. The scope should only be distributed for Link-local Addresses, for all other addresses the scope should be stripped already on the server and not be distributed during lookup.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFCORE-3632) CLI, operation help should force the local
by Jean-Francois Denise (JIRA)
Jean-Francois Denise created WFCORE-3632:
--------------------------------------------
Summary: CLI, operation help should force the local
Key: WFCORE-3632
URL: https://issues.jboss.org/browse/WFCORE-3632
Project: WildFly Core
Issue Type: Enhancement
Reporter: Jean-Francois Denise
Help content of CLI commands is not translated, only english content is exposed.
In order to be homogeneous with this, operation descriptions formatted by the help command should (whatever the server language settings) be displayed in english.
locale="en" should be provided when retrieving the description.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (DROOLS-2341) Asset validation show errors of other assets
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2341?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-2341:
-----------------------------------
Sprint: 2018 Week 07-08
> Asset validation show errors of other assets
> --------------------------------------------
>
> Key: DROOLS-2341
> URL: https://issues.jboss.org/browse/DROOLS-2341
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor, Guided Rule Editor, Guided Template Editor
> Affects Versions: 7.7.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Blocker
>
> Setting this as blocker as the amount of failing tests.
> The issue can be seen if the project contains two assets, for example:
> - a.rdrl - valid
> - b.drl - invalid
> Then if user validates the asset *a*, he will see errors of the asset *b*
> The issue was revealed by the tests:
> * org.drools.workbench.screens.drltext.backend.server.DRLTextEditorServiceImplCDITest.testValidDSRLFile
> * org.drools.workbench.screens.drltext.backend.server.DRLTextEditorServiceImplCDITest.testInvalidDSRLFile
> * org.drools.workbench.screens.drltext.backend.server.DRLTextEditorServiceImplCDITest.testDSLCompinedWithPureDRL
> * org.drools.workbench.screens.drltext.backend.server.DRLTextEditorServiceImplCDITest.testDRLFileWithGlobalVariable
> * org.drools.workbench.screens.drltext.backend.server.DRLTextEditorServiceImplCDITest.testDRLFileWithExplicitNonExistingImport
> * org.drools.workbench.screens.drltext.backend.server.DRLTextEditorServiceImplCDITest.testDRLFileWithExplicitImport
> * org.drools.workbench.screens.drltext.backend.server.DRLTextEditorServiceImplCDITest.testValidDRLFileWithTwoRules
> * org.drools.workbench.screens.drltext.backend.server.DRLTextEditorServiceImplCDITest.testValidDRLFile
> * org.drools.workbench.screens.drltext.backend.server.DRLTextEditorServiceImplCDITest.testDRLFileWithUnknownGlobalVariable
> * org.drools.workbench.screens.drltext.backend.server.DRLTextEditorServiceImplCDITest.testDRLFileWrongConstructor
> * org.drools.workbench.screens.guided.dtable.backend.server.GuidedDecisionTableEditorServiceImplCDITest.testFunctionFromDrl
> * org.drools.workbench.screens.guided.rule.backend.server.GuidedRuleEditorServiceImplCDITest.testAbbreviatedCondition
> * org.drools.workbench.screens.guided.rule.backend.server.GuidedRuleEditorServiceImplCDITest.testValidateRuleThatInherit
> The tests was temporarily ignored by: [PR|https://github.com/kiegroup/drools-wb/pull/814]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFCORE-3631) Coloured output for CLI
by Jean-Francois Denise (JIRA)
Jean-Francois Denise created WFCORE-3631:
--------------------------------------------
Summary: Coloured output for CLI
Key: WFCORE-3631
URL: https://issues.jboss.org/browse/WFCORE-3631
Project: WildFly Core
Issue Type: Feature Request
Components: CLI
Affects Versions: 4.0.0.Alpha10
Reporter: Jean-Francois Denise
Assignee: Jean-Francois Denise
Add support to colour for CLI outputs
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFCORE-3568) Allow CLI output scrolling
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3568?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-3568:
----------------------------------------------
You can use space character to jump to the next page. I guess that it would give you fast scrolling.
With respect to scrolling up, that would require to have the output displayed in a different buffer something that has not been done.
> Allow CLI output scrolling
> --------------------------
>
> Key: WFCORE-3568
> URL: https://issues.jboss.org/browse/WFCORE-3568
> Project: WildFly Core
> Issue Type: Enhancement
> Components: CLI
> Affects Versions: 4.0.0.Alpha8
> Reporter: Chao Wang
> Assignee: Jean-Francois Denise
>
> Mouse scrolling is forbidden to large CLI out. User has to press {{Down}} or {{Enter}} to navigate.
> It would be nice to allow fast scrolling or {{PgUp}} / {{PgDn}}. e.g.
> {noformat}
> [standalone@localhost:9990 /] /core-service=capability-registry:read-resource
> {
> "outcome" => "success",
> "result" => {
> "capabilities" => [
> {
> "name" => "org.wildfly.batch.configuration",
> "dynamic" => false,
> "scope" => "global",
> "registration-points" => ["/subsystem=batch-jberet"]
> },
> {
> "name" => "org.wildfly.batch.job.repository.in-memory",
> "dynamic" => false,
> "scope" => "global",
> "registration-points" => ["/subsystem=batch-jberet/in-memory-job-repository=in-memory"]
> },
> {
> "name" => "org.wildfly.batch.thread.pool.batch",
> "dynamic" => false,
> "scope" => "global",
> "registration-points" => ["/subsystem=batch-jberet/thread-pool=batch"]
> },
> {
> "name" => "org.wildfly.clustering.cache.default-group.ejb",
> "dynamic" => false,
> "scope" => "global",
> "registration-points" => ["/subsystem=infinispan/cache-container=ejb"]
> },
> {
> "name" => "org.wildfly.clustering.cache.default-group.server",
> "dynamic" => false,
> "scope" => "global",
> "registration-points" => ["/subsystem=infinispan/cache-container=server"]
> },
> {
> "name" => "org.wildfly.clustering.cache.default-group.web",
> "dynamic" => false,
> "scope" => "global",
> "registration-points" => ["/subsystem=infinispan/cache-container=web"]
> },
> {
> "name" => "org.wildfly.clustering.cache.default-node-factory.ejb",
> "dynamic" => false,
> "scope" => "global",
> "registration-points" => ["/subsystem=infinispan/cache-container=ejb"]
> },
> {
> "name" => "org.wildfly.clustering.cache.default-node-factory.server",
> "dynamic" => false,
> --More(2%)--
> {noformat}
> Also, after pressing {{Down}} or {{Enter}} to display more output, user can not press {{up}} to go up. User has to inconveniently use scroll up.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (DROOLS-2342) Update Kie Navigator to the new git/rest structure
by Tomas David (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2342?page=com.atlassian.jira.plugi... ]
Tomas David updated DROOLS-2342:
--------------------------------
Description:
Drools eclipse plugin contains Kie Navigator tool which uses git structure and rest calls to connect to kie-wb. According to changes made in kie-wb 7.7.0 the tooling should be updated.
The rest api and the git structure changed. and the kie navigator doesn't work.
was:
Drools eclipse plugin contains Kie Navigator tool which uses git structure and rest calls to connect to kie-wb. According to changes made in RHDM 7.0 the tooling should be updated.
The rest api and the git structure changed. and the kie navigator doesn't work.
> Update Kie Navigator to the new git/rest structure
> --------------------------------------------------
>
> Key: DROOLS-2342
> URL: https://issues.jboss.org/browse/DROOLS-2342
> Project: Drools
> Issue Type: Bug
> Components: eclipse plugin
> Affects Versions: 7.5.0.Final
> Environment: 7.7.0-SNAPSHOT
> Reporter: Tomas David
> Assignee: Kris Verlaenen
>
> Drools eclipse plugin contains Kie Navigator tool which uses git structure and rest calls to connect to kie-wb. According to changes made in kie-wb 7.7.0 the tooling should be updated.
> The rest api and the git structure changed. and the kie navigator doesn't work.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (DROOLS-2342) Update Kie Navigator to the new git/rest structure
by Andrej Podhradsky (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2342?page=com.atlassian.jira.plugi... ]
Andrej Podhradsky updated DROOLS-2342:
--------------------------------------
Description:
Drools eclipse plugin contains Kie Navigator tool which uses git structure and rest calls to connect to kie-wb. According to changes made in RHDM 7.0 the tooling should be updated.
The rest api and the git structure changed. and the kie navigator doesn't work.
was:
Drools eclipse plugin contains Kie Navigator tool which uses git structure and rest calls to connect to kie-wb. According to changes it should be updated.
The rest api and the git structure changed. and the kie navigator doesn't work.
> Update Kie Navigator to the new git/rest structure
> --------------------------------------------------
>
> Key: DROOLS-2342
> URL: https://issues.jboss.org/browse/DROOLS-2342
> Project: Drools
> Issue Type: Bug
> Components: eclipse plugin
> Affects Versions: 7.5.0.Final
> Environment: 7.7.0-SNAPSHOT
> Reporter: Tomas David
> Assignee: Kris Verlaenen
>
> Drools eclipse plugin contains Kie Navigator tool which uses git structure and rest calls to connect to kie-wb. According to changes made in RHDM 7.0 the tooling should be updated.
> The rest api and the git structure changed. and the kie navigator doesn't work.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months