[JBoss JIRA] (WFLY-1749) Switch from commons-beanutils to commons-beanutils-core
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1749?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1749:
-----------------------------------------------
Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 918564|https://bugzilla.redhat.com/show_bug.cgi?id=918564] from ASSIGNED to CLOSED
> Switch from commons-beanutils to commons-beanutils-core
> -------------------------------------------------------
>
> Key: WFLY-1749
> URL: https://issues.jboss.org/browse/WFLY-1749
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Affects Versions: 8.0.0.Alpha3
> Reporter: David Walluck
> Assignee: Tomaz Cerar
> Priority: Minor
> Fix For: 9.0.0.Beta1
>
>
> The commons-beanutils jar includes classes from commons-collections which are not shaded, and should not be used, in any case.
> The dependency can be switched from commons-beanutils:commons-beanutils to commons-beanutils:commons-beanutils-core which does not contain the classes.
> Any module that actually needs the commons-collections classes should ensure that org.apache.commons.collections is also included as an import.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1747) add-user.sh script should have better help message
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1747?page=com.atlassian.jira.plugi... ]
Ilia Vassilev moved WFLY-7017 to WFCORE-1747:
---------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-1747 (was: WFLY-7017)
Component/s: Domain Management
Scripts
(was: Domain Management)
(was: Scripts)
Affects Version/s: (was: 10.1.0.Final)
> add-user.sh script should have better help message
> --------------------------------------------------
>
> Key: WFCORE-1747
> URL: https://issues.jboss.org/browse/WFCORE-1747
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Scripts
> Reporter: Ilia Vassilev
> Assignee: Ilia Vassilev
>
> add-user.sh script should have better help message. There is no general description about this script. There is only list of attributes.
> {code:bash}
> ./add-user.sh -h
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-964) Kie Drools WB - Startup error(org.eclipse.jgit.util.FS.readPipe)
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-964?page=com.atlassian.jira.plugin... ]
Edson Tirelli reassigned DROOLS-964:
------------------------------------
Assignee: Alexandre Porcelli (was: Michael Biarnes Kiefer)
> Kie Drools WB - Startup error(org.eclipse.jgit.util.FS.readPipe)
> ----------------------------------------------------------------
>
> Key: DROOLS-964
> URL: https://issues.jboss.org/browse/DROOLS-964
> Project: Drools
> Issue Type: Bug
> Components: tools
> Affects Versions: 6.3.0.Final
> Environment: Tomcat 7 / 8
> 6.3.0.Final
> Reporter: Jebuselwyn Martin
> Assignee: Alexandre Porcelli
> Priority: Minor
>
> Issue in startup of DroolsWB + Drools Execution Server
> 23-Oct-2015 15:40:18.898 SEVERE [localhost-startStop-1] org.eclipse.jgit.util.FS.readPipe Caught exception in FS.readPipe()
> java.io.IOException: Cannot run program "bash" (in directory "C:\Users\selwyn.martin"): CreateProcess error=2, The system cannot find the file specified
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
> at java.lang.Runtime.exec(Runtime.java:620)
> at org.eclipse.jgit.util.FS.readPipe(FS.java:431)
> at org.eclipse.jgit.util.FS_Win32.discoverGitPrefix(FS_Win32.java:113)
> at org.eclipse.jgit.util.FS.gitPrefix(FS.java:517)
> at org.eclipse.jgit.util.SystemReader$Default.openSystemConfig(SystemReader.java:92)
> at org.eclipse.jgit.internal.storage.file.FileRepository.<init>(FileRepository.java:171)
> at org.eclipse.jgit.lib.BaseRepositoryBuilder.build(BaseRepositoryBuilder.java:577)
> at org.eclipse.jgit.api.InitCommand.call(InitCommand.java:113)
> at org.uberfire.java.nio.fs.jgit.util.JGitUtil.newRepository(JGitUtil.java:104)
> at org.uberfire.java.nio.fs.jgit.JGitFileSystemProvider.rescanForExistingRepositories(JGitFileSystemProvider.java:407)
> at org.uberfire.java.nio.fs.jgit.JGitFileSystemProvider.<init>(JGitFileSystemProvider.java:371)
> at org.uberfire.java.nio.fs.jgit.JGitFileSystemProvider.<init>(JGitFileSystemProvider.java:343)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
> at java.lang.Class.newInstance(Class.java:442)
> at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380)
> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
> at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
> at org.uberfire.java.nio.file.api.FileSystemProviders.buildProviders(FileSystemProviders.java:65)
> at org.uberfire.java.nio.file.api.FileSystemProviders.setup(FileSystemProviders.java:48)
> at org.uberfire.java.nio.file.api.FileSystemProviders.resolveProvider(FileSystemProviders.java:104)
> at org.uberfire.java.nio.file.FileSystems.newFileSystem(FileSystems.java:117)
> at org.uberfire.java.nio.file.FileSystems.newFileSystem(FileSystems.java:83)
> at org.uberfire.io.impl.AbstractIOService.newFileSystem(AbstractIOService.java:241)
> at org.uberfire.backend.server.cdi.SystemConfigProducer$2.create(SystemConfigProducer.java:252)
> at org.uberfire.backend.server.cdi.SystemConfigProducer$2.create(SystemConfigProducer.java:187)
> at org.jboss.weld.context.AbstractContext.get(AbstractContext
> https://groups.google.com/forum/#!topic/drools-setup/qCMYwdOiBAI
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7021) jdr.sh script should have better help message
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7021?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev moved JBEAP-5797 to WFLY-7021:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7021 (was: JBEAP-5797)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JDR
(was: JDR)
Affects Version/s: 10.1.0.Final
(was: 7.1.0.DR3)
> jdr.sh script should have better help message
> ---------------------------------------------
>
> Key: WFLY-7021
> URL: https://issues.jboss.org/browse/WFLY-7021
> Project: WildFly
> Issue Type: Bug
> Components: JDR
> Affects Versions: 10.1.0.Final
> Reporter: Ilia Vassilev
> Assignee: Ilia Vassilev
>
> jdr.sh script should have better help message. There is no general description about this script. There is only list of attributes.
> {code:bash}
> ./jdr.sh -h
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1746) Update the browse-content operation to return more information about the content
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1746?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet reassigned WFCORE-1746:
-----------------------------------------
Assignee: ehsavoie Hugonnet (was: Brian Stansberry)
> Update the browse-content operation to return more information about the content
> --------------------------------------------------------------------------------
>
> Key: WFCORE-1746
> URL: https://issues.jboss.org/browse/WFCORE-1746
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha5
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
>
> Currently the browse-content operation returns a list of String which defines the content file hierarchy. Instead it should return a list of complex type with at least the following attributes : a relative-path (aka the String currently returned), a boolean to indicate if it is a file or a folder, the file size (if it is a file, we won't compute the folder size).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1741) read-content operation does not return the uuid of the stream as the operation result
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1741?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1741:
-------------------------------------
Description:
See the tail end of the discussion on WFCORE-1726.
The rules around streams in responses are:
1) If the thing providing the stream is an attribute, the attribute value set by the read OperationStepHandler must be the uuid of the stream.
2) If the thing providing the stream is a custom operation like :read-content, the result value in the response must be the uuid of the stream or a complex result object one of whose fields is the uuid of the stream.
Metadata about streams is propagated to the client using a response-header. But since a particular request can result in more than one attached stream, the normal non-response-header part of the result for a step must provide the uuid of the stream set by that step. This allows the client to correlate the various streams with the steps that provided them.
was:
See the tail end of the discussion on WFCORE-1726.
The rules around streams in responses are:
1) If the thing providing the stream is an attribute, the attribute value set by the read OperationStepHandler must be the uuid of the stream.
2) If the thing providing the stream is a custom operation like :read-content, the result value in the response must be the uuid of the stream.
Metadata about streams is propagated to the client using a response-header. But since a particular request can result in more than one attached stream, the normal non-response-header part of the result for a step must provide the uuid of the stream set by that step. This allows the client to correlate the various streams with the steps that provided them.
> read-content operation does not return the uuid of the stream as the operation result
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-1741
> URL: https://issues.jboss.org/browse/WFCORE-1741
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
> Fix For: 3.0.0.Alpha6
>
>
> See the tail end of the discussion on WFCORE-1726.
> The rules around streams in responses are:
> 1) If the thing providing the stream is an attribute, the attribute value set by the read OperationStepHandler must be the uuid of the stream.
> 2) If the thing providing the stream is a custom operation like :read-content, the result value in the response must be the uuid of the stream or a complex result object one of whose fields is the uuid of the stream.
> Metadata about streams is propagated to the client using a response-header. But since a particular request can result in more than one attached stream, the normal non-response-header part of the result for a step must provide the uuid of the stream set by that step. This allows the client to correlate the various streams with the steps that provided them.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1726) CLI support for response attachments
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1726?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1726:
----------------------------------------------
I read your earlier sentence as "can be somewhere in the response". I am scanning the result for uuid. I am searching in simple String, complex type and list, so should be just fine.
> CLI support for response attachments
> ------------------------------------
>
> Key: WFCORE-1726
> URL: https://issues.jboss.org/browse/WFCORE-1726
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> CLI doesn't support the streams attached to a response. Incremental deployment support offers today the ability to read the content of a deployment. It would be interesting to operate it from the CLI. Some resource (such as the log file) expose some attributes as stream.
> The following operations are returning streams:
> /subsystem=logging/log-file=server.log:read-attribute(name=stream)
> /subsystem=logging/log-file=server.log:read-resource(include-runtime)
> /deployment=toto:read-content(path=index.html)
> As we can see, streams can be located in attributes, as operation response, inside a resource.
> The CLI offers 2 way to approach the problem:
> 1) Extend the Low level operation support with a way to save/display attached streams. This would require some XML configuration and possibly UI workflow to prompt user for the right action. Making from stream to file path would be not ideal and far from being user friendly. The good side is tha tit would work in any case (batch, non batch). The XML configuration can be a bit complex and prompting user is not an ideal workflow.
> 2) Define a new high level command that would cope with any operation.
> Such command would look like:
> attachment save --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream) --file=/my/local/path/to/file
> attachment display --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream)
> - No risk to impact existing scripts. This is a new feature, so people would have to update their scripts to add the command.
> - The challenge is located in mapping a Stream to a file name. The user provides the name he wants. Furthermore, in interactive mode, the user can use completion to complete this target file.
> - No more prompting, the user knows ahead of time what he wants to do.
> - Problem is that batch mode doesn't re-dispatch each step response to each input command. So some logic should be needed to properly handle streams in batch.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1746) Update the browse-content operation to return more information about the content
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1746?page=com.atlassian.jira.plugi... ]
Radoslav Husar updated WFCORE-1746:
-----------------------------------
Summary: Update the browse-content operation to return more information about the content (was: Update the browse-content operation to return more informations about the content)
> Update the browse-content operation to return more information about the content
> --------------------------------------------------------------------------------
>
> Key: WFCORE-1746
> URL: https://issues.jboss.org/browse/WFCORE-1746
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha5
> Reporter: ehsavoie Hugonnet
> Assignee: Brian Stansberry
>
> Currently the browse-content operation returns a list of String which defines the content file hierarchy. Instead it should return a list of complex type with at least the following attributes : a relative-path (aka the String currently returned), a boolean to indicate if it is a file or a folder, the file size (if it is a file, we won't compute the folder size).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1726) CLI support for response attachments
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1726?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1726:
------------------------------------------
[~jdenise] [~ehugonnet] In an earlier comment here and in the description of WFCORE-1741 I described the requirements for providing the uuid in the result part of the response. This comment here is a bit of a theoretical question since for the concrete deployment content use case we are working the way the server will provide the file size for deployment content is via the browse-content op and not read-content. But if Claudio hadn't proposed that better way I had suggested including the file size in a complex result object for read-content. If we had done that, or have some future case where we need to, this bit I wrote in the description is wrong:
"2) If the thing providing the stream is a custom operation like :read-content, the result value in the response must be the uuid of the stream."
Better would be:
2) If the thing providing the stream is a custom operation like :read-content, the result value in the response must be the uuid of the stream or a complex result object one of whose fields is the uuid of the stream."
Does that language work for you, Jeff?
> CLI support for response attachments
> ------------------------------------
>
> Key: WFCORE-1726
> URL: https://issues.jboss.org/browse/WFCORE-1726
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> CLI doesn't support the streams attached to a response. Incremental deployment support offers today the ability to read the content of a deployment. It would be interesting to operate it from the CLI. Some resource (such as the log file) expose some attributes as stream.
> The following operations are returning streams:
> /subsystem=logging/log-file=server.log:read-attribute(name=stream)
> /subsystem=logging/log-file=server.log:read-resource(include-runtime)
> /deployment=toto:read-content(path=index.html)
> As we can see, streams can be located in attributes, as operation response, inside a resource.
> The CLI offers 2 way to approach the problem:
> 1) Extend the Low level operation support with a way to save/display attached streams. This would require some XML configuration and possibly UI workflow to prompt user for the right action. Making from stream to file path would be not ideal and far from being user friendly. The good side is tha tit would work in any case (batch, non batch). The XML configuration can be a bit complex and prompting user is not an ideal workflow.
> 2) Define a new high level command that would cope with any operation.
> Such command would look like:
> attachment save --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream) --file=/my/local/path/to/file
> attachment display --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream)
> - No risk to impact existing scripts. This is a new feature, so people would have to update their scripts to add the command.
> - The challenge is located in mapping a Stream to a file name. The user provides the name he wants. Furthermore, in interactive mode, the user can use completion to complete this target file.
> - No more prompting, the user knows ahead of time what he wants to do.
> - Problem is that batch mode doesn't re-dispatch each step response to each input command. So some logic should be needed to properly handle streams in batch.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-5892) JGroups throws UnknownHostException on processing IPv6 zone interface id with a subinterface
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-5892?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-5892:
----------------------------------------
FWIW, here's a bit of argument that this is a VM bug that I did on a similar issue, WFCORE-934. In that case it was just affecting a test case so we were willing to hack the test to not execute the problem test if the relevant NetworkInterface is virtual and thus made the problem go away. But production code is a different beast. My comment on the other issue:
"
Looks like a JVM problem then. InetAddress.getByName("fe80:0:0:0:8:20ff:fe6d:eab0%net0:2") is not behaving in accordance with javadoc. It is throwing UnknownHostException when it should not. For a literal IPv6 address string that represents a link-local or site-local it should only check the validity of the address format. The format is valid, as described at https://docs.oracle.com/javase/8/docs/api/java/net/Inet6Address.html#scoped which is linked in the InetAddress.getByName javadoc.
For an IPv6 literal address string with a scope_id appended, UnknownHostException should only be thrown if the address isn't a site-local or link-local address.
This test passes in the community CI runs: http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WildFlyCore&...
There have been failures in the past. I haven't examined them all, but it looks like the failures were due to incorrectly testing global IPv6 addresses, which my patch fixed.
What's happening here is for an InetAddress 'address' obtained from inspecting the addresses available on the system, InetAddress.getByName(address.getHostAddress()) is throwing an UnknownHostException. That's clearly wrong.
"
The test change is here: https://github.com/wildfly/wildfly-core/pull/1415/files
> JGroups throws UnknownHostException on processing IPv6 zone interface id with a subinterface
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-5892
> URL: https://issues.jboss.org/browse/WFLY-5892
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Environment: Solaris 11 Sparc JDK8, IPv6
> Reporter: Michal Karm Babacek
> Assignee: Bela Ban
> Priority: Critical
> Attachments: tcp.xml
>
>
> JGroups pick up IPv6 zone id index and it fails at translating it into an interface name:
> h3. Address
> * address used {{2620:52:0:105f:0:0:ffff:188%net0:2}}
> * {{Caused by: java.net.UnknownHostException: no such interface net0:2}}
> h3. Configuration
> {code}
> <interfaces>
> <interface name="management">
> <inet-address value="2620:52:0:105f::ffff:188"/>
> </interface>
> <interface name="public">
> <inet-address value="2620:52:0:105f::ffff:188"/>
> </interface>
> </interfaces>
> <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
> <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
> <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
> <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
> <socket-binding name="http" port="${jboss.http.port:8080}"/>
> <socket-binding name="https" port="${jboss.https.port:8443}"/>
> <socket-binding name="jgroups-mping" port="0" multicast-address="ff02::12" multicast-port="45700"/>
> <socket-binding name="jgroups-tcp" port="7600"/>
> <socket-binding name="jgroups-tcp-fd" port="57600"/>
> <socket-binding name="jgroups-udp" port="55200" multicast-address="ff02::12" multicast-port="45688"/>
> <socket-binding name="jgroups-udp-fd" port="54200"/>
> <socket-binding name="modcluster" port="0" multicast-address="ff02::a" multicast-port="32983"/>
> <socket-binding name="txn-recovery-environment" port="4712"/>
> <socket-binding name="txn-status-manager" port="4713"/>
> <outbound-socket-binding name="mail-smtp">
> <remote-destination host="localhost" port="25"/>
> </outbound-socket-binding>
> </socket-binding-group>
> {code}
> h3. Exception
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.jgroups.channel.ee: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee: java.security.PrivilegedActionException: java.lang.Exception: Property assignment of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 and converted to null could not be assigned
> at org.wildfly.clustering.jgroups.spi.service.ChannelBuilder.start(ChannelBuilder.java:80)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> 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)
> Caused by: java.security.PrivilegedActionException: java.lang.Exception: Property assignment of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 and converted to null could not be assigned
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:640)
> at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:98)
> at org.wildfly.clustering.jgroups.spi.service.ChannelBuilder.start(ChannelBuilder.java:78)
> ... 5 more
> Caused by: java.lang.Exception: Property assignment of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 and converted to null could not be assigned
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1154)
> at org.jgroups.stack.Configurator.createLayer(Configurator.java:445)
> at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57)
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477)
> at org.jgroups.JChannel.init(JChannel.java:853)
> at org.jgroups.JChannel.<init>(JChannel.java:159)
> at org.jboss.as.clustering.jgroups.JChannelFactory$1.run(JChannelFactory.java:95)
> at org.jboss.as.clustering.jgroups.JChannelFactory$1.run(JChannelFactory.java:92)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> ... 7 more
> Caused by: java.lang.Exception: Conversion of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 failed
> at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84)
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1148)
> ... 17 more
> Caused by: java.net.UnknownHostException: no such interface net0:2
> at java.net.Inet6Address.initstr(Inet6Address.java:487)
> at java.net.Inet6Address.<init>(Inet6Address.java:408)
> at java.net.InetAddress.getAllByName(InetAddress.java:1181)
> at java.net.InetAddress.getAllByName(InetAddress.java:1126)
> at java.net.InetAddress.getByName(InetAddress.java:1076)
> at org.jgroups.conf.PropertyConverters$Default.convert(PropertyConverters.java:288)
> at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:81)
> ... 18 more
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "jgroups"),
> ("channel" => "ee")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.jgroups.channel.ee" => "org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee: java.security.PrivilegedActionException: java.lang.Exception: Property assignment of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 and converted to null could not be assigned
> Caused by: java.security.PrivilegedActionException: java.lang.Exception: Property assignment of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 and converted to null could not be assigned
> Caused by: java.lang.Exception: Property assignment of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 and converted to null could not be assigned
> Caused by: java.lang.Exception: Conversion of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 failed
> Caused by: java.net.UnknownHostException: no such interface net0:2"}}
> {code}
> h3. Interfaces on the Solaris 11 box
> See my undermentioned example:
> {code}
> [mbabacek@dev33 ~]$ groovy https://gist.githubusercontent.com/Karm/ec21b42b59f8889f976f/raw/951f01c6...
> Iface Display name: net4
> Iface Name: net4
> Iface Display name: net0
> Iface Name: net0
> Subiface Display name: net0:7
> Subiface Name: net0:7
> Subiface Display name: net0:6
> Subiface Name: net0:6
> Subiface Display name: net0:5
> Subiface Name: net0:5
> Subiface Display name: net0:4
> Subiface Name: net0:4
> Subiface Display name: net0:3
> Subiface Name: net0:3
> Subiface Display name: net0:2
> Subiface Name: net0:2
> Subiface Display name: net0:1
> Subiface Name: net0:1
> Iface Display name: lo0
> Iface Name: lo0
> {code}
> WDYT? Why should JGroups even try to do that?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months