September 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-818) Listeners declared in kmodule.xml are not registered in StatelessKieSession

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-818?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-818: ------------------------------------------------ Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1233197|https://bugzilla.redhat.com/show_bug.cgi?id=1233197] from ON_QA to VERIFIED > Listeners declared in kmodule.xml are not registered in StatelessKieSession > --------------------------------------------------------------------------- > > Key: DROOLS-818 > URL: https://issues.jboss.org/browse/DROOLS-818 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.3.0.Beta2 > > > Listener declared in kmodule.xml as in the following snippet of XML works on stateful KieSession, but are not registered on stateless ones. > {code} > <ksession name="statelessKieSession1" type="stateless"> > <listeners> > <ruleRuntimeEventListener type="com.esrx.ref.testproject.TestRuleRuntimeEventListener"/> > </listeners> > </ksession> > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1954) SWIFT_PING discovery protocol fatal error on OpenStack Kilo

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1954?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1954: -------------------------------- Hi Nick, Java 6 is absolutely *not* a requirement as 3.6.5 is already on Java 7 as base line. If you think the cleaner approach is to move SWIFT_PING into its own separate project, that's a valid choice, too. But Thomas kind of seemed against it, or did I only imply this Thomas ? > SWIFT_PING discovery protocol fatal error on OpenStack Kilo > ----------------------------------------------------------- > > Key: JGRP-1954 > URL: https://issues.jboss.org/browse/JGRP-1954 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.4 > Environment: JGroups client running on Mac OS X - Yosemite > JDK 1.7.71 > OpenStack Kilo > Reporter: Nick Sawadsky > Assignee: Bela Ban > Fix For: 3.6.5 > > > I'm attempting to use the SWIFT_PING discovery protocol on the most recent version of OpenStack, "Kilo". An error occurs during initialization of the protocol stack, the stack trace is provided below. > The problem appears to be that support for XML-formatted responses has been removed in the OpenStack Identity API (http://developer.openstack.org/api-ref-identity-v2.html). Even though SWIFT_PING sends an Accept header of application/xml, the response still comes back as JSON (around line 286 of SWIFT_PING.java). > I've been able to repro the issue using Postman in Chrome. I tried providing the *request* in XML , with a Content-Type header of application/xml, but Swift returns an error: "Expecting to find application/json in Content-Type header". > It seems like the resolution would be for SWIFT_PING to be modified so it can parse the JSON response that it is receiving. If that sounds like a reasonable approach, I can try to create a patch that fixes the issue. > Stack Trace: > 2015-08-21 14:30:16,123 FATAL [com.pingidentity.common.util.ErrorHandler] Problem creating factory for multiplexed cluster communications > org.xml.sax.SAXParseException: Content is not allowed in prolog. > at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:257) ~[?:1.8.0_25] > at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:348) ~[?:1.8.0_25] > at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121) ~[?:1.8.0_25] > at org.jgroups.protocols.SWIFT_PING$Keystone_V_2_0_Auth.authenticate(SWIFT_PING.java:307) ~[jgroups.jar:3.6.4.Final] > at org.jgroups.protocols.SWIFT_PING$SwiftClient.authenticate(SWIFT_PING.java:443) ~[jgroups.jar:3.6.4.Final] > at org.jgroups.protocols.SWIFT_PING.init(SWIFT_PING.java:68) ~[jgroups.jar:3.6.4.Final] > at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860) ~[jgroups.jar:3.6.4.Final] > at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481) ~[jgroups.jar:3.6.4.Final] > at org.jgroups.JChannel.init(JChannel.java:854) ~[jgroups.jar:3.6.4.Final] > at org.jgroups.JChannel.<init>(JChannel.java:159) ~[jgroups.jar:3.6.4.Final] > at org.jgroups.JChannel.<init>(JChannel.java:120) ~[jgroups.jar:3.6.4.Final] -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1954) SWIFT_PING discovery protocol fatal error on OpenStack Kilo

by Nick Sawadsky (JIRA)

[ https://issues.jboss.org/browse/JGRP-1954?page=com.atlassian.jira.plugin.... ] Nick Sawadsky edited comment on JGRP-1954 at 9/1/15 11:53 AM: -------------------------------------------------------------- Yes, I think you're right, that should avoid the security risks I was concerned about (I thought the code would have to eval the JSON string that was returned). There are some posts about JSON.parse not being available when running on Java 6, but hopefully that is resolved in Java 7 and later. [~belaban] do you think Java 6 compatibility is a requirement for the fix? If so, this approach may become a little more complicated, as a Javascript implementation of JSON.parse would have to be loaded in to the ScriptEngine instance. was (Author: nsawadsky): Yes, I think you're right, that should avoid the security risks I was concerned about (I thought the code would have to eval the JSON string that was returned). As long as JSON.parse is available, that seems like a good way to go. There are some posts about JSON.parse not being available when running on Java 6, but hopefully that is resolved in Java 7 and later. > SWIFT_PING discovery protocol fatal error on OpenStack Kilo > ----------------------------------------------------------- > > Key: JGRP-1954 > URL: https://issues.jboss.org/browse/JGRP-1954 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.4 > Environment: JGroups client running on Mac OS X - Yosemite > JDK 1.7.71 > OpenStack Kilo > Reporter: Nick Sawadsky > Assignee: Bela Ban > Fix For: 3.6.5 > > > I'm attempting to use the SWIFT_PING discovery protocol on the most recent version of OpenStack, "Kilo". An error occurs during initialization of the protocol stack, the stack trace is provided below. > The problem appears to be that support for XML-formatted responses has been removed in the OpenStack Identity API (http://developer.openstack.org/api-ref-identity-v2.html). Even though SWIFT_PING sends an Accept header of application/xml, the response still comes back as JSON (around line 286 of SWIFT_PING.java). > I've been able to repro the issue using Postman in Chrome. I tried providing the *request* in XML , with a Content-Type header of application/xml, but Swift returns an error: "Expecting to find application/json in Content-Type header". > It seems like the resolution would be for SWIFT_PING to be modified so it can parse the JSON response that it is receiving. If that sounds like a reasonable approach, I can try to create a patch that fixes the issue. > Stack Trace: > 2015-08-21 14:30:16,123 FATAL [com.pingidentity.common.util.ErrorHandler] Problem creating factory for multiplexed cluster communications > org.xml.sax.SAXParseException: Content is not allowed in prolog. > at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:257) ~[?:1.8.0_25] > at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:348) ~[?:1.8.0_25] > at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121) ~[?:1.8.0_25] > at org.jgroups.protocols.SWIFT_PING$Keystone_V_2_0_Auth.authenticate(SWIFT_PING.java:307) ~[jgroups.jar:3.6.4.Final] > at org.jgroups.protocols.SWIFT_PING$SwiftClient.authenticate(SWIFT_PING.java:443) ~[jgroups.jar:3.6.4.Final] > at org.jgroups.protocols.SWIFT_PING.init(SWIFT_PING.java:68) ~[jgroups.jar:3.6.4.Final] > at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860) ~[jgroups.jar:3.6.4.Final] > at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481) ~[jgroups.jar:3.6.4.Final] > at org.jgroups.JChannel.init(JChannel.java:854) ~[jgroups.jar:3.6.4.Final] > at org.jgroups.JChannel.<init>(JChannel.java:159) ~[jgroups.jar:3.6.4.Final] > at org.jgroups.JChannel.<init>(JChannel.java:120) ~[jgroups.jar:3.6.4.Final] -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1954) SWIFT_PING discovery protocol fatal error on OpenStack Kilo

by Nick Sawadsky (JIRA)

[ https://issues.jboss.org/browse/JGRP-1954?page=com.atlassian.jira.plugin.... ] Nick Sawadsky commented on JGRP-1954: ------------------------------------- Yes, I think you're right, that should avoid the security risks I was concerned about (I thought the code would have to eval the JSON string that was returned). As long as JSON.parse is available, that seems like a good way to go. There are some posts about JSON.parse not being available when running on Java 6, but hopefully that is resolved in Java 7 and later. > SWIFT_PING discovery protocol fatal error on OpenStack Kilo > ----------------------------------------------------------- > > Key: JGRP-1954 > URL: https://issues.jboss.org/browse/JGRP-1954 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.4 > Environment: JGroups client running on Mac OS X - Yosemite > JDK 1.7.71 > OpenStack Kilo > Reporter: Nick Sawadsky > Assignee: Bela Ban > Fix For: 3.6.5 > > > I'm attempting to use the SWIFT_PING discovery protocol on the most recent version of OpenStack, "Kilo". An error occurs during initialization of the protocol stack, the stack trace is provided below. > The problem appears to be that support for XML-formatted responses has been removed in the OpenStack Identity API (http://developer.openstack.org/api-ref-identity-v2.html). Even though SWIFT_PING sends an Accept header of application/xml, the response still comes back as JSON (around line 286 of SWIFT_PING.java). > I've been able to repro the issue using Postman in Chrome. I tried providing the *request* in XML , with a Content-Type header of application/xml, but Swift returns an error: "Expecting to find application/json in Content-Type header". > It seems like the resolution would be for SWIFT_PING to be modified so it can parse the JSON response that it is receiving. If that sounds like a reasonable approach, I can try to create a patch that fixes the issue. > Stack Trace: > 2015-08-21 14:30:16,123 FATAL [com.pingidentity.common.util.ErrorHandler] Problem creating factory for multiplexed cluster communications > org.xml.sax.SAXParseException: Content is not allowed in prolog. > at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:257) ~[?:1.8.0_25] > at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:348) ~[?:1.8.0_25] > at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121) ~[?:1.8.0_25] > at org.jgroups.protocols.SWIFT_PING$Keystone_V_2_0_Auth.authenticate(SWIFT_PING.java:307) ~[jgroups.jar:3.6.4.Final] > at org.jgroups.protocols.SWIFT_PING$SwiftClient.authenticate(SWIFT_PING.java:443) ~[jgroups.jar:3.6.4.Final] > at org.jgroups.protocols.SWIFT_PING.init(SWIFT_PING.java:68) ~[jgroups.jar:3.6.4.Final] > at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860) ~[jgroups.jar:3.6.4.Final] > at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481) ~[jgroups.jar:3.6.4.Final] > at org.jgroups.JChannel.init(JChannel.java:854) ~[jgroups.jar:3.6.4.Final] > at org.jgroups.JChannel.<init>(JChannel.java:159) ~[jgroups.jar:3.6.4.Final] > at org.jgroups.JChannel.<init>(JChannel.java:120) ~[jgroups.jar:3.6.4.Final] -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5254) Upgrade Infinispan to 8.0.0.Final

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-5254: ---------------------------------- Summary: Upgrade Infinispan to 8.0.0.Final Key: WFLY-5254 URL: https://issues.jboss.org/browse/WFLY-5254 Project: WildFly Issue Type: Component Upgrade Components: Clustering Affects Versions: 10.0.0.Beta2 Reporter: Paul Ferraro Assignee: Paul Ferraro -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1943) GossipRouter: use NioServer to re-implement

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1943?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1943: -------------------------------- Created classes TcpClient / NioClient, TcpServer / NioServer and re-implemented GossipRouter / RouterStub / RouterStubManager with them. > GossipRouter: use NioServer to re-implement > ------------------------------------------- > > Key: JGRP-1943 > URL: https://issues.jboss.org/browse/JGRP-1943 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.5 > > > If {{NioServer}} is used to implement {{GossipRouter}}, then we'd remove the need to use 1 thread per connection, but all requests would be handled by a configurable thread pool. > Should also reduce the code size of {{GossipRouter}}. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1943) GossipRouter: use NioServer to re-implement

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1943?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1943: -------------------------------- - nio <true|false> can be used to determine whether GR is blocking or non-blocking > GossipRouter: use NioServer to re-implement > ------------------------------------------- > > Key: JGRP-1943 > URL: https://issues.jboss.org/browse/JGRP-1943 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.5 > > > If {{NioServer}} is used to implement {{GossipRouter}}, then we'd remove the need to use 1 thread per connection, but all requests would be handled by a configurable thread pool. > Should also reduce the code size of {{GossipRouter}}. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1943) GossipRouter: use NioServer to re-implement

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1943?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1943. ---------------------------- Resolution: Done > GossipRouter: use NioServer to re-implement > ------------------------------------------- > > Key: JGRP-1943 > URL: https://issues.jboss.org/browse/JGRP-1943 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.5 > > > If {{NioServer}} is used to implement {{GossipRouter}}, then we'd remove the need to use 1 thread per connection, but all requests would be handled by a configurable thread pool. > Should also reduce the code size of {{GossipRouter}}. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-941) The file javax/sql/rowset/rowset.properties is not present in jboss-javax-sql-api_7.0_spec-1.1.0.Final.jar

by Marco Mondini (JIRA)

[ https://issues.jboss.org/browse/WFCORE-941?page=com.atlassian.jira.plugin... ] Marco Mondini commented on WFCORE-941: -------------------------------------- That will never go in Wildfly 9.x. Will it? > The file javax/sql/rowset/rowset.properties is not present in jboss-javax-sql-api_7.0_spec-1.1.0.Final.jar > ---------------------------------------------------------------------------------------------------------- > > Key: WFCORE-941 > URL: https://issues.jboss.org/browse/WFCORE-941 > Project: WildFly Core > Issue Type: Component Upgrade > Affects Versions: 1.0.1.Final, 1.0.2.Final > Reporter: Marco Mondini > Fix For: 2.0.0.Beta5 > > > Changing version of the artifact "jboss-javax-sql-api_7.0_spec" to 1.1.1.Final will fix the issue. > (see: https://issues.jboss.org/browse/WFLY-4884) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5253) [Migration operation] [Web to Undertow] Protocol attribute in ssl configuration of https connector is not properly migrated

by Radim Hatlapatka (JIRA)

Radim Hatlapatka created WFLY-5253: -------------------------------------- Summary: [Migration operation] [Web to Undertow] Protocol attribute in ssl configuration of https connector is not properly migrated Key: WFLY-5253 URL: https://issues.jboss.org/browse/WFLY-5253 Project: WildFly Issue Type: Bug Components: Web (Undertow) Reporter: Radim Hatlapatka Assignee: Stuart Douglas Priority: Critical In Web {{protocol}} attribute of https ssl configuration is used for defining ssl protocols such as TLSv1.2. This attribute isn't properly migrated. Migrate operation defines {{enabled-protocols}} in {{https-listener}} based on Web's {{ssl-protocol}} which is incorrect as {{ssl-protocol}} in Web stands for name of custom ssl protocol provider. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2015