[JBoss JIRA] (ELY-233) ServerAuthenticationContext callback handler special handling for AuthorizeCallback
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-233?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-233:
---------------------------------
Fix Version/s: 1.0.0.Alpha5
> ServerAuthenticationContext callback handler special handling for AuthorizeCallback
> -----------------------------------------------------------------------------------
>
> Key: ELY-233
> URL: https://issues.jboss.org/browse/ELY-233
> Project: WildFly Elytron
> Issue Type: Task
> Components: API / SPI
> Reporter: David Lloyd
> Fix For: 1.0.0.Alpha5
>
>
> The ServerAuthenticationContext's callback handler implementation currently handles each callback in order.
> It should instead handle all callbacks in order *except* for the AuthorizeCallback, which it should handle last. This will make it somewhat resilient against SASL server mechanisms (and other server mechanisms) which incorrectly send in the authorize callback before finishing authentication.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (DROOLS-861) Incremental update causes NPE in TypeDeclarationFactory when declaring interface as @PropertyReactive event.
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-861?page=com.atlassian.jira.plugin... ]
Mario Fusco commented on DROOLS-861:
------------------------------------
I'm investigating this issue, but anyway it doesn't seem related with @PropertyReactive. Just declaring the type in the 2nd drl (while it wasn't declared in the 1st) is enough to reproduce this NPE.
> Incremental update causes NPE in TypeDeclarationFactory when declaring interface as @PropertyReactive event.
> ------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-861
> URL: https://issues.jboss.org/browse/DROOLS-861
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Beta2
> Environment: Mac OS X 10.10.3, Oracle JDK 1.7.0_79
> Reporter: Duncan Doyle
> Assignee: Mario Fusco
>
> When incrementally updating a KieContainer, the TypeDeclarationFactory throws an NPE when an Interface is declared as an @PropertyReactive event in the new rulebase.
> {code}
> java.lang.NullPointerException
> at org.drools.compiler.builder.impl.TypeDeclarationFactory.compareTypeDeclarations(TypeDeclarationFactory.java:214)
> at org.drools.compiler.builder.impl.TypeDeclarationFactory.checkRedeclaration(TypeDeclarationFactory.java:152)
> at org.drools.compiler.builder.impl.TypeDeclarationBuilder.createBean(TypeDeclarationBuilder.java:235)
> at org.drools.compiler.builder.impl.TypeDeclarationBuilder.processTypeDeclarations(TypeDeclarationBuilder.java:128)
> at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildTypeDeclarations(CompositeKnowledgeBuilderImpl.java:333)
> at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:117)
> at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:105)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.rebuildAll(KieContainerImpl.java:369)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:207)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion(KieContainerImpl.java:128)
> at org.jboss.ddoyle.drools.IncrementalUpdateTest.test(IncrementalUpdateTest.java:48)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75){code}
> See reproducer here: https://github.com/DuncanDoyle/drools-declare-interface-incremental-updat...
> Simply run {{mvn clean test}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (DROOLS-870) Nested properties get hashed even if they shouldn't
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-870?page=com.atlassian.jira.plugin... ]
Mario Fusco updated DROOLS-870:
-------------------------------
Fix Version/s: 6.3.0.Final
(was: 6.3.0.CR1)
> Nested properties get hashed even if they shouldn't
> ---------------------------------------------------
>
> Key: DROOLS-870
> URL: https://issues.jboss.org/browse/DROOLS-870
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.3.0.Final
>
>
> In some cases nested properties get hashed by the CompositeObjectSinkAdapter even if they shouldn't
> The following test case demonstrates this problem:
> {code}
> public class A1 {
> public B1 b = new B1();
> }
> public class B1 {
> public int b1 = 1;
> public int b2 = 2;
> public int b3 = 3;
> }
> @Test
> public void testSkipHashingOfNestedProperties() {
> String drl =
> "import " + A1.class.getCanonicalName() + "\n" +
> "global java.util.List list\n" +
> "rule One when\n" +
> " A1(b.b1 == 1)\n" +
> "then\n" +
> " list.add(\"One\");\n" +
> "end\n" +
> "\n" +
> "rule \"Two\" when\n" +
> " A1(b.b2 == 2)\n" +
> "then\n" +
> " list.add(\"Two\");\n" +
> "end\n" +
> "\n" +
> "rule \"Three\" when\n" +
> " A1(b.b3 == 3)\n" +
> "then\n" +
> " list.add(\"Three\");\n" +
> "end\n";
> KieSession ksession = new KieHelper().addContent( drl, ResourceType.DRL )
> .build()
> .newKieSession();
> List<Object> list = new ArrayList<Object>();
> ksession.setGlobal( "list", list );
> ksession.insert( new A1() );
> ksession.fireAllRules();
> assertEquals( 3, list.size() );
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JGRP-1947) JGRP000006 errors triggered by nmap TCP Connect scanning JGroups ports
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1947?page=com.atlassian.jira.plugin.... ]
Bela Ban closed JGRP-1947.
--------------------------
Resolution: Won't Fix
> JGRP000006 errors triggered by nmap TCP Connect scanning JGroups ports
> ----------------------------------------------------------------------
>
> Key: JGRP-1947
> URL: https://issues.jboss.org/browse/JGRP-1947
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.6
> Environment: Java 7u80 x32
> Tomcat 7.0.62
> HA-JDBC 3.0.4-SNAPSHOT + JGroups 3.4.6
> nmap 5.5.1
> Reporter: Justin Cranford
> Assignee: Bela Ban
> Fix For: 3.6.5
>
>
> I am running a two node Tomcat cluster. Both JGroups and Hazelcast are used for different parts of application clustering - JGroups for HA-JDBC, and Hazelcast for application locks outside of HA-JDBC.
> Hazelcast is not relevant to JGroups, except I included the Hazelcast errors because they happen at the same time as the JGroups JGRP000006 errors. This gave me a hint of why I see JGRP000006, because the Hazelcast error is more specific about root cause.
> Basically if I run a nmap TCP Connect scan on my servers like so, this opens/closes empty TCP connections. JGroups reports these events as JGRP000006, whereas Hazelcast reports them as "java.io.IOException[Connection reset by peer]".
> I am wondering if JGroups can handle these nmap TCP Connect scans more gracefully, or even log a more descriptive error with the JGRP000006 error code.
> My Tomcat errors for both JGroups and Hazelcast
> Jul 31, 2015 12:27:52 AM com.hazelcast.nio.SocketAcceptor
> INFO: [10.0.0.85]:5900 [ClusterManager] [3.2.4] Accepting socket connection from /10.0.0.86:40527
> Jul 31, 2015 12:27:52 AM com.hazelcast.nio.TcpIpConnectionManager
> INFO: [10.0.0.85]:5900 [ClusterManager] [3.2.4] 5900 accepted socket connection from /10.0.0.86:40527
> Jul 31, 2015 12:27:52 AM org.jgroups.logging.JDKLogImpl warn
> WARNING: JGRP000006: failed accepting connection from peer
> java.net.SocketException: Connection reset
> at java.net.SocketInputStream.read(Unknown Source)
> at java.net.SocketInputStream.read(Unknown Source)
> at java.io.BufferedInputStream.fill(Unknown Source)
> at java.io.BufferedInputStream.read1(Unknown Source)
> at java.io.BufferedInputStream.read(Unknown Source)
> at java.io.DataInputStream.readFully(Unknown Source)
> at org.jgroups.blocks.TCPConnectionMap$TCPConnection.readPeerAddress(TCPConnectionMap.java:494)
> at org.jgroups.blocks.TCPConnectionMap$TCPConnection.<init>(TCPConnectionMap.java:376)
> at org.jgroups.blocks.TCPConnectionMap$Acceptor.handleAccept(TCPConnectionMap.java:298)
> at org.jgroups.blocks.TCPConnectionMap$Acceptor.run(TCPConnectionMap.java:282)
> at java.lang.Thread.run(Unknown Source)
> Jul 31, 2015 12:27:52 AM com.hazelcast.nio.TcpIpConnection
> INFO: [10.0.0.85]:5900 [ClusterManager] [3.2.4] Connection [/10.0.0.86:40527] lost. Reason: java.io.IOException[Connection reset by peer]
> My nmap scan which triggers the JGRP000006 errors:
> root@myserver:~$ nmap -n -T4 -sT -PN --max-scan-delay 0ms --min-rate 1000000 --max-retries 0 -p 443,3306,5900,7900,7901 10.0.0.85
> Starting Nmap 5.51 ( http://nmap.org ) at 2015-07-31 01:33 UTC
> Cannot find nmap-payloads. UDP payloads are disabled.
> Nmap scan report for 10.0.0.85
> Host is up (0.00035s latency).
> PORT STATE SERVICE
> 443/tcp open https
> 3306/tcp open mysql
> 5900/tcp open vnc
> 7900/tcp open mevent
> 7901/tcp open unknown
> Nmap done: 1 IP address (1 host up) scanned in 0.04 seconds
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JGRP-1944) jgroups does not recover properly when using UDP after ifdown / ifup
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1944?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1944:
--------------------------------
The changes made in JGRP-1804 were reverted when I switched from using a MulticastSocket to a DatagramSocket for sending of multicasts.
> 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)
10 years, 11 months
[JBoss JIRA] (WFLY-1548) Add fallback querry to jconsole plugin
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1548?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1548:
-----------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1215278|https://bugzilla.redhat.com/show_bug.cgi?id=1215278] from MODIFIED to ON_QA
> Add fallback querry to jconsole plugin
> --------------------------------------
>
> Key: WFLY-1548
> URL: https://issues.jboss.org/browse/WFLY-1548
> Project: WildFly
> Issue Type: Enhancement
> Affects Versions: 8.0.0.Alpha1
> Reporter: Bartosz Baranowski
> Assignee: Darran Lofthouse
> Labels: JConsole, JMX, Plugin
> Fix For: 8.0.0.Beta1
>
>
> JConsolePlugin connecects to default port, despite chance to use proper info.
> Problem:
> Unless I miss somethingm JConsole has a bit tight isolation between components. There is no way for AS7 JConsolePlugin to access "connect dialog" info. Hence it has no idea what is the content of URL being passed as remote.
> AS7 JConsolePlugin checks if MBeanServerConnection is instance of RemotinConnection. If its not, it fallbacks to default: localhost:9990.
> However we can check for socket bindings and try to connect to proper socket.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (AS7-6911) jconsole fails if trying to connect to a standalone EAP instance running with offset ports
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6911?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6911:
----------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1215278|https://bugzilla.redhat.com/show_bug.cgi?id=1215278] from MODIFIED to ON_QA
> jconsole fails if trying to connect to a standalone EAP instance running with offset ports
> ------------------------------------------------------------------------------------------
>
> Key: AS7-6911
> URL: https://issues.jboss.org/browse/AS7-6911
> Project: Application Server 7
> Issue Type: Bug
> Components: CLI
> Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
> Environment: All
> Reporter: Jay Kumar SenSharma
> Assignee: Stan Silvert
> Labels: cli
>
> If JBoss AS7/8 is started using port-offset as following:
> ie. with -Djboss.socket.binding.port-offset=100
> Then While connecting to it using "jconsole.sh" as a Local Process it throws the following Exception:
> +++++++++++++++++++++++++++++
> Exception in thread "AWT-EventQueue-0" java.lang.RuntimeException: Error connecting to JBoss AS.
> at org.jboss.as.cli.gui.JConsoleCLIPlugin.getTabs(JConsoleCLIPlugin.java:80)
> at sun.tools.jconsole.VMPanel.createPluginTabs(VMPanel.java:641)
> at sun.tools.jconsole.VMPanel.propertyChange(VMPanel.java:315)
> at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:339)
> at javax.swing.event.SwingPropertyChangeSupport.firePropertyChange(SwingPropertyChangeSupport.java:75)
> at javax.swing.event.SwingPropertyChangeSupport$1.run(SwingPropertyChangeSupport.java:80)
> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:646)
> at java.awt.EventQueue.access$000(EventQueue.java:84)
> at java.awt.EventQueue$1.run(EventQueue.java:607)
> at java.awt.EventQueue$1.run(EventQueue.java:605)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:616)
> at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
> at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
> at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
> Caused by: java.lang.NullPointerException
> at org.jboss.as.cli.gui.JConsoleCLIPlugin.connectCommandContext(JConsoleCLIPlugin.java:109)
> at org.jboss.as.cli.gui.JConsoleCLIPlugin.getTabs(JConsoleCLIPlugin.java:77)
> +++++++++++++++++++++++
> And the Code "org.jboss.as.cli.gui.JConsoleCLIPlugin" classes Line 109 throws NullPointerException, Because "cliGuiCtx" object is null and not initialized earlier:
> 109 JOptionPane.showMessageDialog(cliGuiCtx.getMainWindow(), message);
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (DROOLS-871) Remove the MVEL dependency from kie-internal
by Marco Rietveld (JIRA)
[ https://issues.jboss.org/browse/DROOLS-871?page=com.atlassian.jira.plugin... ]
Marco Rietveld commented on DROOLS-871:
---------------------------------------
One possible easy solution here is to simply set the MVEL dependcy to the "provided" or "optional" scope.
> Remove the MVEL dependency from kie-internal
> --------------------------------------------
>
> Key: DROOLS-871
> URL: https://issues.jboss.org/browse/DROOLS-871
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Marco Rietveld
> Assignee: Mario Fusco
> Fix For: 6.2.0.Final, 6.3.0.Final
>
>
> The {{kie-internal}} module has a dependency on MVEL. This jira is for the task of removing that dependency from {{kie-internal}}.
> The problem is that the MVEL dependency ({{org.mvel:mvel2}}) is nearly 1MB large!
> This means that the dependency tree grows by 1MB everywhere where {{kie-internal}} is used, among others: {{kie-remote-client}}, which has the explicit goal of being as small a dependency as possible, given that it's meant to be used as a lightweight client jar.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months