[JBoss JIRA] (WFLY-5048) CLI escapes anpersand in double-quoted strings
by Roman Syroeshko (JIRA)
[ https://issues.jboss.org/browse/WFLY-5048?page=com.atlassian.jira.plugin.... ]
Roman Syroeshko commented on WFLY-5048:
---------------------------------------
Whoops. You're right. I forgot that we deal with XML here and expected to see pure BURL address here. Tough day. Thanks! I Checked, and it works okay.
> CLI escapes anpersand in double-quoted strings
> ----------------------------------------------
>
> Key: WFLY-5048
> URL: https://issues.jboss.org/browse/WFLY-5048
> Project: WildFly
> Issue Type: Bug
> Components: CLI
> Affects Versions: 8.2.0.Final
> Environment: Windows 8.1 x64, WildFly 8.2.0.Final, JDK 1.8.0.45.
> Reporter: Roman Syroeshko
> Assignee: Alexey Loubyansky
> Priority: Blocker
> Labels: BURL, CLI, Qpid, escaping
>
> I use Qpid JCA to work with AMQP message broker via JMS API. Qpid JCA is configured through Jboss CLI. Queues in Qpid are addressed using [Binding URL|https://qpid.apache.org/releases/qpid-0.32/jms-client-0-8/book/JMS-Cl...]. The format uses ampersands to separate additional options.
> For example,
> BURL:direct://AnotherExchange//AnotherQueue?routingkey='AnotherQueue'&durable='true'&autodelete='false'&exchangedurable='true'&exchangeautodelete='false'
> But when I run cli-command like that:
> {code}
> ./admin-objects=AnotherQueue:add(class-name=org.apache.qpid.ra.admin.QpidQueueImpl,jndi-name=java:/comp/env/jms/AnotherQueue)
> ./admin-objects=AnotherQueue/config-properties=DestinationAddress:add(value="BURL:direct://AnotherExchange//AnotherQueue?routingkey='AnotherQueue'&durable='true'&autodelete='false'&exchangedurable='true'&exchangeautodelete='false'")
> {code}
> I get
> {code:xml}
> <admin-object class-name="org.apache.qpid.ra.admin.QpidQueueImpl" jndi-name="java:/comp/env/jms/AnotherQueue" pool-name="AnotherQueue">
> <config-property name="DestinationAddress">
> BURL:direct://AnotherExchange//AnotherQueue?routingkey='AnotherQueue'&durable='true'&autodelete='false'&exchangedurable='true'&exchangeautodelete='false'
> </config-property>
> </admin-object>
> {code}
> instead of
> {code:xml}
> <admin-object class-name="org.apache.qpid.ra.admin.QpidQueueImpl" jndi-name="java:/comp/env/jms/AnotherQueue" pool-name="AnotherQueue">
> <config-property name="DestinationAddress">
> BURL:direct://AnotherExchange//AnotherQueue?routingkey='AnotherQueue'&durable='true'&autodelete='false'&exchangedurable='true'&exchangeautodelete='false'
> </config-property>
> </admin-object>
> {code}
> It seemed to me that CLI shouldn't escape double-quoted values. Am I missing something?
> Thanks.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (WFCORE-864) CLI echo command doesn't echo variables any more
by Joe Wertz (JIRA)
[ https://issues.jboss.org/browse/WFCORE-864?page=com.atlassian.jira.plugin... ]
Joe Wertz commented on WFCORE-864:
----------------------------------
Found this one last week while working on the testsuite refactoring.
> CLI echo command doesn't echo variables any more
> ------------------------------------------------
>
> Key: WFCORE-864
> URL: https://issues.jboss.org/browse/WFCORE-864
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.0.Alpha12
> Reporter: Alexey Loubyansky
> Assignee: Joe Wertz
>
> This CLI log is produced by wildfly-core-2.0.0.Alpha11
> [olubyans@fedovo bin]$ ./jboss-cli.sh
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] echo
> [disconnected /] set a=aa
> [disconnected /] echo $a
> aa
> And this one is the current one (with the new Aesh)
> [disconnected /] set a=aa
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] echo $a
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /]
> I've verified that the variables are set with set command. I guess Aesh is handling $xxx itself and just replaces them with nothing, as Aesh is unaware of the CLI variables.
> There is EchoTestCase but, as it's not interactive, Aesh does not get involved there, I guess.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (WFCORE-864) CLI echo command doesn't echo variables any more
by Joe Wertz (JIRA)
[ https://issues.jboss.org/browse/WFCORE-864?page=com.atlassian.jira.plugin... ]
Joe Wertz closed WFCORE-864.
----------------------------
Resolution: Duplicate Issue
> CLI echo command doesn't echo variables any more
> ------------------------------------------------
>
> Key: WFCORE-864
> URL: https://issues.jboss.org/browse/WFCORE-864
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.0.Alpha12
> Reporter: Alexey Loubyansky
> Assignee: Joe Wertz
>
> This CLI log is produced by wildfly-core-2.0.0.Alpha11
> [olubyans@fedovo bin]$ ./jboss-cli.sh
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] echo
> [disconnected /] set a=aa
> [disconnected /] echo $a
> aa
> And this one is the current one (with the new Aesh)
> [disconnected /] set a=aa
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] echo $a
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /]
> I've verified that the variables are set with set command. I guess Aesh is handling $xxx itself and just replaces them with nothing, as Aesh is unaware of the CLI variables.
> There is EchoTestCase but, as it's not interactive, Aesh does not get involved there, I guess.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (JGRP-1944) jgroups does not recover properly when using UDP after ifdown / ifup
by Bram Klein Gunnewiek (JIRA)
[ https://issues.jboss.org/browse/JGRP-1944?page=com.atlassian.jira.plugin.... ]
Bram Klein Gunnewiek commented on JGRP-1944:
--------------------------------------------
I did some more testing and it seems to be related to the scripts {{ifup <interface>}} and {{ifdown <interface>}} execute prior/post bringing the actual interface up or down. Those commands execute the scripts in (on ubuntu) {{/etc/network/if-\*}} where {{ifconfig <interface> down/up}} *only* brings the interface down or up. Its related to the type of interface, if I reconfigure the network cards to work as regular nic's jgroups auto recovers perfectly fine. So:
* {{ifdown bridge0}} and then {{ifup bridge0}} doesnt recover;
* {{ifconfig bridge0 down}} and then {{ifconfig bridge0 up}} does recover;
* {{ifdown eth0}} and then {{ifup eth0}} does recover (when the nic is configured as a regular ethernet device ofcourse).
I'm still not sure if this is something JGroups should fix but its (at least in our situations) common to bring interfaces down/up using ifdown / ifup. In case you'r wondering: we use bridges instead of regular interfaces because they are also used by QEMU instances.
> jgroups does not recover properly when using UDP after ifdown / ifup
> --------------------------------------------------------------------
>
> Key: JGRP-1944
> URL: https://issues.jboss.org/browse/JGRP-1944
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.4
> Environment: Linux Ubutun 14.04 where the network cards are configured as bridges:
> auto bridge0
> iface bridge0 inet dhcp
> bridge_ports eth1
> bridge_stp off
> bridge_fd 0
> Reporter: Bram Klein Gunnewiek
> Assignee: Bela Ban
> Fix For: 3.6.5
>
> Attachments: AutoRecoverMulticast.java
>
>
> When we bring the interface down and back up in a complete (udp.xml) configuration everything *seems* to be fine, however multicast traffic from the node that had the interface brought down is not received by other nodes. The node also doesn't receive any data from the other nodes. No exceptions are logged. I don't think the previous test was done correctly by me ... sorry .
> When we use TCP + MPING we see the stacktraces we had previously with UDP:
> 12:13:51.624 50644 [Timer-3,debug,shockvm-tn3-42192] ERROR unknown.jul.logger - failed sending discovery request
> java.io.IOException: Invalid argument
> at java.net.PlainDatagramSocketImpl.send(Native Method) ~[na:1.7.0_79]
> at java.net.DatagramSocket.send(DatagramSocket.java:697) ~[na:1.7.0_79]
> at org.jgroups.protocols.MPING.sendMcastDiscoveryRequest(MPING.java:295) ~[jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.PING.sendDiscoveryRequest(PING.java:61) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.PING.findMembers(PING.java:31) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.Discovery.findMembers(Discovery.java:244) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.Discovery.down(Discovery.java:387) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.MERGE3$InfoSender.run(MERGE3.java:382) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.util.TimeScheduler3$Task.run(TimeScheduler3.java:287) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.util.TimeScheduler3$RecurringTask.run(TimeScheduler3.java:321) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_79]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_79]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]
> (The exact message differs whether or not the -Djava.net.preferIPv4Stack=true argument is configured)
> A configuration that uses MPING also doesn't recover from ifdown/ifup.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (SECURITY-784) LdapExtLoginModule cannot find custom ldap socket factory
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/SECURITY-784?page=com.atlassian.jira.plug... ]
Pedro Igor commented on SECURITY-784:
-------------------------------------
Hi Jonhny,
That works too. However, you don't need to do that since TCCL is previously configured before invoking the LM.
> LdapExtLoginModule cannot find custom ldap socket factory
> ---------------------------------------------------------
>
> Key: SECURITY-784
> URL: https://issues.jboss.org/browse/SECURITY-784
> Project: PicketBox
> Issue Type: Feature Request
> Components: PicketBox
> Affects Versions: PicketBox_4_0_19.Final
> Reporter: Derek Horton
> Assignee: Pedro Igor
> Attachments: SECURITY-784.patch
>
>
> LdapExtLoginModule cannot find custom ldap socket factory.
> Passing the "java.naming.ldap.factory.socket" property in as an
> module-option:
> <module-option name="java.naming.ldap.factory.socket" value="org.jboss.example.CustomSocketFactory"/>
> results in a ClassNotFoundException:
> Caused by: javax.naming.CommunicationException: 192.168.1.8:389 [Root exception is java.lang.ClassNotFoundException: org/jboss/example/CustomSocketFactory]
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:226) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:136) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1608) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2698) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) [rt.jar:1.7.0_45]
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_45]
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_45]
> at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_45]
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:153) [rt.jar:1.7.0_45]
> at org.jboss.security.auth.spi.LdapExtLoginModule.constructInitialLdapContext(LdapExtLoginModule.java:767) [picketbox-4.0.17.SP2-redhat-2.jar:4.0.17.SP2-redhat-2]
> I tried making the custom socket factory into a jboss module and adding the module as a dependency to picketbox and
> sun.jdk. Unfortunately, that did not work. I also added the socket
> factory jar to the jre/lib/ext directory. That didn't work either.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (WFLY-4339) NPE when deployment contains a *-ds.xml in domain
by Jive JIRA Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4339?page=com.atlassian.jira.plugin.... ]
Jive JIRA Integration updated WFLY-4339:
----------------------------------------
Forum Reference: https://developer.jboss.org/message/937167#937167
> NPE when deployment contains a *-ds.xml in domain
> -------------------------------------------------
>
> Key: WFLY-4339
> URL: https://issues.jboss.org/browse/WFLY-4339
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 8.2.0.Final
> Reporter: James Perkins
> Assignee: Lin Gao
> Fix For: 10.0.0.Beta1
>
>
> If you build the [kitchen-sink quickstart|https://github.com/wildfly/quickstart/tree/master/kitchensink] and attempt to deploy to domain servers you'll see the following error. Same deployment works fine in standalone.
> {code}
> [Server:server-one] 09:25:06,563 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-14) MSC000001: Failed to start service jboss.data-source.java:jboss/datasources/KitchensinkQuickstartDS: org.jboss.msc.service.StartException in service jboss.data-source.java:jboss/datasources/KitchensinkQuickstartDS: WFLYJCA0033: Error during the deployment of java:jboss/datasources/KitchensinkQuickstartDS
> [Server:server-one] at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:142)
> [Server:server-two] 09:25:06,563 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.data-source.java:jboss/datasources/KitchensinkQuickstartDS: org.jboss.msc.service.StartException in service jboss.data-source.java:jboss/datasources/KitchensinkQuickstartDS: WFLYJCA0033: Error during the deployment of java:jboss/datasources/KitchensinkQuickstartDS
> [Server:server-two] at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:142)
> [Server:server-two] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [Server:server-two] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [Server:server-two] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:server-two] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:server-two] at java.lang.Thread.run(Thread.java:745)
> [Server:server-two] Caused by: java.lang.NullPointerException
> [Server:server-two] at org.jboss.as.connector.services.driver.registry.DriverRegistryImpl.getInstalledDriver(DriverRegistryImpl.java:93)
> [Server:server-two] at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.deploy(AbstractDataSourceService.java:324)
> [Server:server-two] at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:135)
> [Server:server-two] ... 5 more
> [Server:server-two]
> [Server:server-one] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [Server:server-one] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:server-one] at java.lang.Thread.run(Thread.java:745)
> [Server:server-one] Caused by: java.lang.NullPointerException
> [Server:server-one] at org.jboss.as.connector.services.driver.registry.DriverRegistryImpl.getInstalledDriver(DriverRegistryImpl.java:93)
> [Server:server-one] at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.deploy(AbstractDataSourceService.java:324)
> [Server:server-one] at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:135)
> [Server:server-one] ... 5 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (WFLY-5048) CLI escapes anpersand in double-quoted strings
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFLY-5048?page=com.atlassian.jira.plugin.... ]
Alexey Loubyansky commented on WFLY-5048:
-----------------------------------------
It's not the CLI who's doing that. It can also be easily reproduced with system properties, e.g.
{code}
[standalone@localhost:9990 /] /system-property=a:add(value="BURL:direct://AnotherExchange//AnotherQueue?routingkey='AnotherQueue'&durable='true'&autodelete='false'&exchangedurable='true'&exchangeautodelete='false'")
{"outcome" => "success"}
[standalone@localhost:9990 /] /system-property=a:read-attribute(name=value)
{
"outcome" => "success",
"result" => "BURL:direct://AnotherExchange//AnotherQueue?routingkey='AnotherQueue'&durable='true'&autodelete='false'&exchangedurable='true'&exchangeautodelete='false'"
}
[standalone@localhost:9990 /]
{code}
The XML will contain the value you reported but if you read it using the management API or the tools (even if you restart the server), you'll see the value as it was entered. Can you confirm this is true in your case? Why is this a problem for you?
Thanks.
> CLI escapes anpersand in double-quoted strings
> ----------------------------------------------
>
> Key: WFLY-5048
> URL: https://issues.jboss.org/browse/WFLY-5048
> Project: WildFly
> Issue Type: Bug
> Components: CLI
> Affects Versions: 8.2.0.Final
> Environment: Windows 8.1 x64, WildFly 8.2.0.Final, JDK 1.8.0.45.
> Reporter: Roman Syroeshko
> Assignee: Alexey Loubyansky
> Priority: Blocker
> Labels: BURL, CLI, Qpid, escaping
>
> I use Qpid JCA to work with AMQP message broker via JMS API. Qpid JCA is configured through Jboss CLI. Queues in Qpid are addressed using [Binding URL|https://qpid.apache.org/releases/qpid-0.32/jms-client-0-8/book/JMS-Cl...]. The format uses ampersands to separate additional options.
> For example,
> BURL:direct://AnotherExchange//AnotherQueue?routingkey='AnotherQueue'&durable='true'&autodelete='false'&exchangedurable='true'&exchangeautodelete='false'
> But when I run cli-command like that:
> {code}
> ./admin-objects=AnotherQueue:add(class-name=org.apache.qpid.ra.admin.QpidQueueImpl,jndi-name=java:/comp/env/jms/AnotherQueue)
> ./admin-objects=AnotherQueue/config-properties=DestinationAddress:add(value="BURL:direct://AnotherExchange//AnotherQueue?routingkey='AnotherQueue'&durable='true'&autodelete='false'&exchangedurable='true'&exchangeautodelete='false'")
> {code}
> I get
> {code:xml}
> <admin-object class-name="org.apache.qpid.ra.admin.QpidQueueImpl" jndi-name="java:/comp/env/jms/AnotherQueue" pool-name="AnotherQueue">
> <config-property name="DestinationAddress">
> BURL:direct://AnotherExchange//AnotherQueue?routingkey='AnotherQueue'&durable='true'&autodelete='false'&exchangedurable='true'&exchangeautodelete='false'
> </config-property>
> </admin-object>
> {code}
> instead of
> {code:xml}
> <admin-object class-name="org.apache.qpid.ra.admin.QpidQueueImpl" jndi-name="java:/comp/env/jms/AnotherQueue" pool-name="AnotherQueue">
> <config-property name="DestinationAddress">
> BURL:direct://AnotherExchange//AnotherQueue?routingkey='AnotherQueue'&durable='true'&autodelete='false'&exchangedurable='true'&exchangeautodelete='false'
> </config-property>
> </admin-object>
> {code}
> It seemed to me that CLI shouldn't escape double-quoted values. Am I missing something?
> Thanks.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (ELY-253) Optimised authentication protocol
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-253:
------------------------------------
Summary: Optimised authentication protocol
Key: ELY-253
URL: https://issues.jboss.org/browse/ELY-253
Project: WildFly Elytron
Issue Type: Task
Components: SASL
Reporter: Darran Lofthouse
Fix For: 2.0.0.Alpha1
An improved protocol has been discussed previously, however integration with existing projects make this inadvisable at this time for compatibility.
However we should revisit this - maybe we have an option that a client can request the optimised flow - obviously legacy clients will not request this so they remain unaffected.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (ELY-252) Take into account username after failed authentication for available mechs
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-252:
------------------------------------
Summary: Take into account username after failed authentication for available mechs
Key: ELY-252
URL: https://issues.jboss.org/browse/ELY-252
Project: WildFly Elytron
Issue Type: Task
Components: SASL
Reporter: Darran Lofthouse
Fix For: 1.0.0.Alpha4
This is something we would need to be cautious about as it does risk revealing information to an attacker but after a files attempt we may have more information and be able to offer mechanisms based on this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months