[JBoss JIRA] (JGRP-2102) bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2102?page=com.atlassian.jira.plugin.... ]
Bela Ban closed JGRP-2102.
--------------------------
Resolution: Rejected
Either use {{bind_interface}} (not recommended) or {{bind_addr}} (recommended), but not both. The former has been removed in later versions anyway.
> bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict
> --------------------------------------------------------------------
>
> Key: JGRP-2102
> URL: https://issues.jboss.org/browse/JGRP-2102
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.1
> Environment: {noformat}
> [root@wtc2k01v27 ~] CLONE # ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> inet6 2606:ae00:e200:3f::83/128 scope global
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:50:56:ab:2a:ea brd ff:ff:ff:ff:ff:ff
> inet 107.250.167.28/25 brd 107.250.167.127 scope global eth0
> inet6 2606:ae00:e200:3f::28/64 scope global
> valid_lft forever preferred_lft forever
> inet6 fe80::250:56ff:feab:2aea/64 scope link
> valid_lft forever preferred_lft forever
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:50:56:ab:d6:12 brd ff:ff:ff:ff:ff:ff
> inet 192.168.0.59/24 brd 192.168.0.255 scope global eth1
> inet6 fe80::250:56ff:feab:d612/64 scope link
> valid_lft forever preferred_lft forever
> {noformat}
> There're eth0 and eth1 exists in the environment
> Reporter: 俐佳 张
> Assignee: Bela Ban
> Fix For: 3.6.14
>
> Attachments: jgroups-udp.xml
>
>
> Error happens while
> Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000085: Error while trying to create a channel using the specified configuration file: /opt/oss/NSN-icf_notification_dispatcher/conf/jgroups-udp.xml
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:406)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:307)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:351)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
> at java.lang.reflect.Method.invoke(Method.java:620)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:226)
> ... 26 more
> Caused by: java.lang.Exception: Property assignment of bind_interface in UDP with original property value eth0 and converted to null could not be assigned
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1153)
> at org.jgroups.stack.Configurator.createLayer(Configurator.java:444)
> 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:854)
> at org.jgroups.JChannel.<init>(JChannel.java:159)
> at org.jgroups.JChannel.<init>(JChannel.java:129)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:404)
> ... 39 more
> Caused by: java.lang.Exception: Conversion of bind_interface in UDP with original property value eth0 failed
> at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84)
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1147)
> ... 48 more
> Caused by: java.lang.mail(a)example.comIllegalArgumentException: network interface eth0 does not contain address fe80:0:0:0:250:56ff:feab:d612%3
> at org.jgroups.util.Util.validateBindAddressFromInterface(Util.java:3132)
> bind_interface="eth0" and bind_addr="LINK_LOCAL" config are config at the same time
> but it couldn't get the eth0 link local address but return eth1 link local address
> This code return the first address that match, it should return with eth0
> jgroups-3.6.1.Final-sources\org\jgroups\util\Util.java
> {code}
> public static InetAddress getAddress(AddressScope scope) // ----> scope is LINK_LOCAL
> throws SocketException
> {
> InetAddress address = null;
> Enumeration intfs = NetworkInterface.getNetworkInterfaces();
> while (intfs.hasMoreElements()) {
> NetworkInterface intf = (NetworkInterface)intfs.nextElement();
> try {
> if (intf.isUp()) {
> address = getAddress(intf, scope); // -------> It will return the first LINK_LOCAL address from NICs list
> if (address != null)
> return address;
> }
> }
> catch (SocketException e) {
> }
> }
> return null;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (JGRP-2034) SASLTest-functional and SASL_SimpleAuthorizingCallbackTest-functional fails on IBM jdk 1.8
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2034?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2034:
---------------------------
Fix Version/s: 3.6.15
(was: 3.6.14)
Moving to 3.6.15 last time, next time I'll delete this issue
> SASLTest-functional and SASL_SimpleAuthorizingCallbackTest-functional fails on IBM jdk 1.8
> ------------------------------------------------------------------------------------------
>
> Key: JGRP-2034
> URL: https://issues.jboss.org/browse/JGRP-2034
> Project: JGroups
> Issue Type: Bug
> Reporter: Ivan Straka
> Assignee: Tristan Tarrant
> Fix For: 3.6.15
>
>
> We see these two tests failing on IBM jdk 1.8
> org.jgroups.protocols.SASLTest-functional
> org.jgroups.protocols.SASL_SimpleAuthorizingCallbackTest-functional
> This issue may be related to https://issues.jboss.org/browse/JGRP-1993 somehow.
> There is standard output of tests.
> {code}
> ------------- testSASLDigestMD5 -----------
> -------------------------------------------------------------------
> GMS: address=A, cluster=SaslTest
> -------------------------------------------------------------------
> 521823 [TRACE] GMS: A: no members discovered after 3000 ms: creating cluster as first member
> 521823 [DEBUG] GMS: A: installing view [A|0] (1) [A]
> 521823 [DEBUG] GMS: A: created cluster (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
> -------------------------------------------------------------------
> GMS: address=B, cluster=SaslTest
> -------------------------------------------------------------------
> 521825 [TRACE] GMS: B: discovery took 0 ms, members: 1 rsps (1 coords) [done]
> 521826 [DEBUG] GMS: B: sending JOIN(B) to A
> 521826 [TRACE] SASL: B: received CHALLENGE from A
> 521827 [WARN] SASL: B: failed to validate CHALLENGE from A, token
> javax.security.sasl.SaslException: DIGEST-MD5: Error acquiring realm, authentication ID or password
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:380) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at com.ibm.security.sasl.digest.DigestMD5Client.evaluateChallenge(DigestMD5Client.java:236) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at org.jgroups.auth.sasl.SaslClientContext.evaluateChallenge(SaslClientContext.java:119) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.addHeader(SaslClientContext.java:92) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.nextMessage(SaslClientContext.java:72) ~[classes/:?]
> at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?]
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?]
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) [classes/:?]
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) [classes/:?]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645) [classes/:?]
> at org.jgroups.protocols.Discovery.up(Discovery.java:296) [classes/:?]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1567) [classes/:?]
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783) [classes/:?]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [?:1.8.0-internal]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:1.8.0-internal]
> at java.lang.Thread.run(Thread.java:785) [?:1.8.0-internal]
> Caused by: java.io.IOException: Invalid realm A
> at org.jgroups.auth.sasl.SimpleAuthorizingCallbackHandler.handle(SimpleAuthorizingCallbackHandler.java:119) ~[classes/:?]
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:353) ~[ibmsaslprovider.jar:8.0 build_20150506]
> ... 16 more
> 524826 [WARN] GMS: B: JOIN(B) sent to A timed out (after 3000 ms), on try 1
> 524827 [TRACE] GMS: B: discovery took 1 ms, members: 1 rsps (1 coords) [done]
> 524827 [DEBUG] GMS: B: sending JOIN(B) to A
> 524828 [TRACE] SASL: B: received CHALLENGE from A
> 524828 [WARN] SASL: B: failed to validate CHALLENGE from A, token
> javax.security.sasl.SaslException: DIGEST-MD5: Error acquiring realm, authentication ID or password
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:380) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at com.ibm.security.sasl.digest.DigestMD5Client.evaluateChallenge(DigestMD5Client.java:236) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at org.jgroups.auth.sasl.SaslClientContext.evaluateChallenge(SaslClientContext.java:119) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.addHeader(SaslClientContext.java:92) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.nextMessage(SaslClientContext.java:72) ~[classes/:?]
> at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?]
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?]
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) [classes/:?]
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) [classes/:?]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645) [classes/:?]
> at org.jgroups.protocols.Discovery.up(Discovery.java:296) [classes/:?]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1567) [classes/:?]
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783) [classes/:?]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [?:1.8.0-internal]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:1.8.0-internal]
> at java.lang.Thread.run(Thread.java:785) [?:1.8.0-internal]
> Caused by: java.io.IOException: Invalid realm A
> at org.jgroups.auth.sasl.SimpleAuthorizingCallbackHandler.handle(SimpleAuthorizingCallbackHandler.java:119) ~[classes/:?]
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:353) ~[ibmsaslprovider.jar:8.0 build_20150506]
> ... 16 more
> 526826 [WARN] SASL: failed to validate SaslHeader from B, header: payload=[B@ad737f58
> ------------- testSASLDigestMD5Failure -----------
> -------------------------------------------------------------------
> GMS: address=A, cluster=SaslTest
> -------------------------------------------------------------------
> 529863 [TRACE] GMS: A: no members discovered after 3000 ms: creating cluster as first member
> 529864 [DEBUG] GMS: A: installing view [A|0] (1) [A]
> 529864 [DEBUG] GMS: A: created cluster (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
> -------------------------------------------------------------------
> GMS: address=B, cluster=SaslTest
> -------------------------------------------------------------------
> 529866 [TRACE] GMS: B: discovery took 1 ms, members: 1 rsps (1 coords) [done]
> 529866 [DEBUG] GMS: B: sending JOIN(B) to A
> 529867 [TRACE] SASL: B: received CHALLENGE from A
> 529867 [WARN] SASL: B: failed to validate CHALLENGE from A, token
> javax.security.sasl.SaslException: DIGEST-MD5: Error acquiring realm, authentication ID or password
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:380) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at com.ibm.security.sasl.digest.DigestMD5Client.evaluateChallenge(DigestMD5Client.java:236) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at org.jgroups.auth.sasl.SaslClientContext.evaluateChallenge(SaslClientContext.java:119) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.addHeader(SaslClientContext.java:92) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.nextMessage(SaslClientContext.java:72) ~[classes/:?]
> at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?]
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?]
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) [classes/:?]
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) [classes/:?]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645) [classes/:?]
> at org.jgroups.protocols.Discovery.up(Discovery.java:296) [classes/:?]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1567) [classes/:?]
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783) [classes/:?]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [?:1.8.0-internal]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:1.8.0-internal]
> at java.lang.Thread.run(Thread.java:785) [?:1.8.0-internal]
> Caused by: java.io.IOException: Invalid realm A
> at org.jgroups.auth.sasl.SimpleAuthorizingCallbackHandler.handle(SimpleAuthorizingCallbackHandler.java:119) ~[classes/:?]
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:353) ~[ibmsaslprovider.jar:8.0 build_20150506]
> ... 16 more
> 532867 [WARN] GMS: B: JOIN(B) sent to A timed out (after 3000 ms), on try 1
> 532867 [TRACE] GMS: B: discovery took 0 ms, members: 1 rsps (1 coords) [done]
> 532867 [DEBUG] GMS: B: sending JOIN(B) to A
> 532868 [TRACE] SASL: B: received CHALLENGE from A
> 532869 [WARN] SASL: B: failed to validate CHALLENGE from A, token
> javax.security.sasl.SaslException: DIGEST-MD5: Error acquiring realm, authentication ID or password
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:380) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at com.ibm.security.sasl.digest.DigestMD5Client.evaluateChallenge(DigestMD5Client.java:236) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at org.jgroups.auth.sasl.SaslClientContext.evaluateChallenge(SaslClientContext.java:119) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.addHeader(SaslClientContext.java:92) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.nextMessage(SaslClientContext.java:72) ~[classes/:?]
> at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?]
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?]
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) [classes/:?]
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) [classes/:?]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645) [classes/:?]
> at org.jgroups.protocols.Discovery.up(Discovery.java:296) [classes/:?]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1567) [classes/:?]
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783) [classes/:?]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [?:1.8.0-internal]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:1.8.0-internal]
> at java.lang.Thread.run(Thread.java:785) [?:1.8.0-internal]
> Caused by: java.io.IOException: Invalid realm A
> at org.jgroups.auth.sasl.SimpleAuthorizingCallbackHandler.handle(SimpleAuthorizingCallbackHandler.java:119) ~[classes/:?]
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:353) ~[ibmsaslprovider.jar:8.0 build_20150506]
> ... 16 more
> 534867 [WARN] SASL: failed to validate SaslHeader from B, header: payload=[B@6f6c2511
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-3210:
---------------------------------------
That is correct. Any log4j appender can be used as a {{custom-handler}}, https://issues.jboss.org/browse/WFCORE-3210?focusedCommentId=13454919&pag....
As a simple example here's a CLI command to add a file appender.
{code}
/subsystem=logging/custom-handler=test:add(class=org.apache.log4j.FileAppender, module=org.apache.log4j, named-formatter=PATTERN, properties={file="${jboss.server.log.dir}/test.log"})
{code}
You may also be interested in [logging profiles|https://docs.jboss.org/author/display/WFLY10/Logging+Configurati...] if you don't want deployments logging to the default logging configuration.
> Wildfly module isolation not working consistently
> -------------------------------------------------
>
> Key: WFCORE-3210
> URL: https://issues.jboss.org/browse/WFCORE-3210
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging, Modules
> Affects Versions: 2.2.0.Final
> Reporter: Nuno Godinho de Matos
>
> There is an underministic bug on the module layer of wildfly, whereby the boot logic of the application server is not ensured to give the appropriate module isolation - which can lead to unexpected boot classpath problems.
> An example of this phenomena is given on the wildfly forum thread:
> https://developer.jboss.org/thread/275839
> In this example, we have the logging subsystem setup to use a custome handler.
> The custom handler wishes to have acces to the JUL extension classes on the org.jboss.logmanger module, but wishes to do have no relationship with the org.apache.log4j packages associated to the wildfly org.jboss.log4j module.
> What we see in this example is that an application gets from wildfly mixed behavior.
> Most of the time, during boot, the processes works without problem, where the custom handler runs isolated from the undersired log4j libraries within wildfly.
> But other times the application boot procedure will not go smoothly with the custom handler having processes routing JUL LogRecords events into the bundled log4j because the application server has loaded some of the classes that exist the org.jboss.log4j module.
> And as we know when the same class is loaded by different class loaders, then that class that orinates from class loader A cannot be assigned to the corresponding class of class loader B, even if the classes are exactly the same.
> This is not an isolated issue.
> There are also open issues on the wildfly forum reporting on startup problems on the logging subsystme where sometimes the LogManager class had not yet been loaded, and sometimes this issue goes away.
> This is an indication of some deep issue engrained into the module loading, where the module isolation behavior is not ensured to work all the time and that the boot procedure is not deterministically reliable.
> It should not be that the application server some time starts successfully and others not.
> Booting wildfly should always result in the same outcode.
> Problems of this nature with class loading problems should either always happen if the configuration is not done properly or never happen if the configuration is proper.
> In the case of thread:
> https://developer.jboss.org/thread/275839
> Our belief is that the configuration is doing all it possible can to request the necessary module isolation from base packages and the outcome where log4j class load problems take place should never be allowed to happen.
> Many thanks.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3250) CLI command recorder
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3250:
----------------------------------------
Summary: CLI command recorder
Key: WFCORE-3250
URL: https://issues.jboss.org/browse/WFCORE-3250
Project: WildFly Core
Issue Type: Enhancement
Components: CLI
Reporter: Jean-Francois Denise
Assignee: Jean-Francois Denise
It has been identified a need to capture a set of commands in order to address 2 use cases:
1) Capture a set of commands in order to create an named command for this set of commands
2) Capture a set of commands and export it into a script file.
Named command can then be executed from the CLI. Exported file can then be run when starting the CLI using the --file option
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3249) Support for | and >> operators
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3249:
----------------------------------------
Summary: Support for | and >> operators
Key: WFCORE-3249
URL: https://issues.jboss.org/browse/WFCORE-3249
Project: WildFly Core
Issue Type: Feature Request
Components: CLI
Reporter: Jean-Francois Denise
Assignee: Jean-Francois Denise
Aesh 1.0 comes with a set of useful operators. 2 are of particular interest in CLI:
In order to extend the CLI ‘>’ support with the ability to append to a file, ‘>>’ support is required.
To make interesting combination of commands (eg: grep, cat, less), the ‘|’ operator is required.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3248) Enhanced help for CLI
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3248:
----------------------------------------
Summary: Enhanced help for CLI
Key: WFCORE-3248
URL: https://issues.jboss.org/browse/WFCORE-3248
Project: WildFly Core
Issue Type: Feature Request
Components: CLI
Reporter: Jean-Francois Denise
Assignee: Jean-Francois Denise
Replace help text file by “on the fly” generation of help content. The source of input for this generation are the Command Annotations and Bundle files that contain descriptions.
Furthermore the help content currently doesn’t scale with the complexity of commands. The help has to be attached to command and command’s actions.
Low level operations usage is aligned with command documentation.
Both commands and operations help are available from the help command.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3247) CLI commands management
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3247:
----------------------------------------
Summary: CLI commands management
Key: WFCORE-3247
URL: https://issues.jboss.org/browse/WFCORE-3247
Project: WildFly Core
Issue Type: Feature Request
Components: CLI
Reporter: Jean-Francois Denise
Assignee: Jean-Francois Denise
With the evolution of CLI to support aesh 1.0 commands, we have new use cases that CLI needs to handle. For example, to take benefit of third-party aesh commands (eg: aesh-extensions), the CLI must be able to load commands dynamically.
Currently it is difficult or impossible to achieve the following use cases:
List all commands
List enabled commands
List disabled commands
List deprecated commands
List commands that are loaded from extensions
Display errors that occurred loading commands
List commands loaded from ServiceLoader
Load commands dynamically from a jar
Load commands dynamically from a module
A dedicated command should be designed to help achieve these use cases.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months