October 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3943) There is no testing of the messaging subsystem integration with the JGroups subsystem

by Yong Hao Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-3943?page=com.atlassian.jira.plugin.... ] Yong Hao Gao updated WFLY-3943: ------------------------------- Attachment: standalone-full-ha.xml this modified configuration file works (no error reported in this jira). > There is no testing of the messaging subsystem integration with the JGroups subsystem > ------------------------------------------------------------------------------------- > > Key: WFLY-3943 > URL: https://issues.jboss.org/browse/WFLY-3943 > Project: WildFly > Issue Type: Task > Components: JMS > Affects Versions: 9.0.0.Alpha1 > Reporter: Brian Stansberry > Assignee: Jeff Mesnil > Priority: Critical > Attachments: standalone-full-ha.xml > > > HornetQServerAdd and HornetQServerService have integration with the JGroups subsystem in order to add a dependency on a ChannelFactory for use with broadcast and discovery groups. But it seems there is no testing of this integration. > Looks like it's currently broken. That problem is likely a clustering bug, as there was a recent major change in this area, and this works in the 6.x branch. > This JIRA is about the fact lack of testing that would have caught the bug. Also, https://github.com/wildfly/wildfly/pull/6725 passed the testsuite with a code change that was binary incompatible with the version of HQ that was integrated at the time. > I'll file a separate issue for the problem I'm referring to. To reproduce it change the bg-group1 element in standalone-full-ha.xml to replace the socket-binding element with the following: > {code} > <jgroups-stack>udp</jgroups-stack> > <jgroups-channel>hq-bg</jgroups-channel> >  > {code} > At boot this appears in the logs: > {code} > 10:00:58,707 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "messaging"), > ("hornetq-server" => "default") > ]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.messaging.default is missing [jboss.jgroups.stack.udp]"]} > 10:00:58,930 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.jgroups.stack.udp (missing) dependents: [service jboss.messaging.default] > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3943) There is no testing of the messaging subsystem integration with the JGroups subsystem

by Yong Hao Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-3943?page=com.atlassian.jira.plugin.... ] Yong Hao Gao commented on WFLY-3943: ------------------------------------ Hi Brian, I'm trying to reproduce this but failed to do so. The configure I'm using is: <broadcast-groups> <broadcast-group name="bg-group1"> <jgroups-stack>udp</jgroups-stack> <jgroups-channel>hq-bg</jgroups-channel>  <connector-ref>http-connector</connector-ref> </broadcast-group> </broadcast-groups> <discovery-groups> <discovery-group name="dg-group1"> <jgroups-stack>udp</jgroups-stack> <jgroups-channel>hq-bg</jgroups-channel>  </discovery-group> </discovery-groups> and the server starts ok. I'll attach the standalone-full-ha.xml. > There is no testing of the messaging subsystem integration with the JGroups subsystem > ------------------------------------------------------------------------------------- > > Key: WFLY-3943 > URL: https://issues.jboss.org/browse/WFLY-3943 > Project: WildFly > Issue Type: Task > Components: JMS > Affects Versions: 9.0.0.Alpha1 > Reporter: Brian Stansberry > Assignee: Jeff Mesnil > Priority: Critical > > HornetQServerAdd and HornetQServerService have integration with the JGroups subsystem in order to add a dependency on a ChannelFactory for use with broadcast and discovery groups. But it seems there is no testing of this integration. > Looks like it's currently broken. That problem is likely a clustering bug, as there was a recent major change in this area, and this works in the 6.x branch. > This JIRA is about the fact lack of testing that would have caught the bug. Also, https://github.com/wildfly/wildfly/pull/6725 passed the testsuite with a code change that was binary incompatible with the version of HQ that was integrated at the time. > I'll file a separate issue for the problem I'm referring to. To reproduce it change the bg-group1 element in standalone-full-ha.xml to replace the socket-binding element with the following: > {code} > <jgroups-stack>udp</jgroups-stack> > <jgroups-channel>hq-bg</jgroups-channel> >  > {code} > At boot this appears in the logs: > {code} > 10:00:58,707 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "messaging"), > ("hornetq-server" => "default") > ]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.messaging.default is missing [jboss.jgroups.stack.udp]"]} > 10:00:58,930 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.jgroups.stack.udp (missing) dependents: [service jboss.messaging.default] > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (ELY-94) Password types not properly acquiring KeySpec

by David Lloyd (JIRA)

David Lloyd created ELY-94: ------------------------------ Summary: Password types not properly acquiring KeySpec Key: ELY-94 URL: https://issues.jboss.org/browse/ELY-94 Project: WildFly Elytron Issue Type: Bug Components: Password Types Reporter: David Lloyd Assignee: Darran Lofthouse The password implementations' {{engineGetKeySpec}} and {{engineConvertibleToKeySpec}} are all testing against an exact {{KeySpec}} type. However this makes it impossible to acquire a general {{KeySpec}} of any type, and is also inconsistent with {{KeyFactory}}'s behavior. Change the implementations to use {{isAssignableFrom}} checks. All implementations should allow a class of {{PasswordSpec}} or {{KeySpec}} to be passed in; in this case, that type's preferred {{KeySpec}} type will be returned. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-136) Create a new error message for suffix attribute on size-rotating-file-handler

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-136?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-136: ------------------------------------------------ Nikoleta Ziakova <nziakova(a)redhat.com> changed the Status of [bug 1147806|https://bugzilla.redhat.com/show_bug.cgi?id=1147806] from ON_QA to VERIFIED > Create a new error message for suffix attribute on size-rotating-file-handler > ------------------------------------------------------------------------------ > > Key: WFCORE-136 > URL: https://issues.jboss.org/browse/WFCORE-136 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Fix For: 1.0.0.Alpha9 > > > As part of WFCORE-113, the suffix attribute on size-rotating-file-handler has a little bit different functionality than on other handlers (seconds or milliseconds are allowed). However the validation error message is the same as on other handlers ("seconds or milliseconds are not allowed"). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3961) XSDs should use a correct and existing schemaLocation.

by Jay Kumar SenSharma (JIRA)

[ https://issues.jboss.org/browse/WFLY-3961?page=com.atlassian.jira.plugin.... ] Jay Kumar SenSharma updated WFLY-3961: -------------------------------------- Description: The Feature Request: https://issues.jboss.org/browse/WFLY-3014 Does not address the actual issue. - It is understood that we do not validate the xml with the "schemaLocation". However there are some users who reads the XSD via valid schemaLocation and parse them according to their requirement for XML processing. - The XSDs that are shipped with wildfly uses a non existing "schemaLocation". For example: "jboss-web_8_0.xsd" {code} <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_8_0.xsd" version="8.0"> ... </jboss-web> {code} - The schema location points to http://www.jboss.org/j2ee/schema/jboss-web_8_0.xsd (causes 404 http response) Where as all those XSDs are actually present in another location, http://www.jboss.org/schema/jbossas/ So for the "jboss-web_8_0.xsd" the correct schemaLocation should be http://www.jboss.org/schema/jbossas/jboss-web_8_0.xsd So in order to avoid confusion to the users who are more familiar with XML/XSD naming the "schemaLocation" should be corrected in all the XSDs. *Expectation:* Either the XSDs should point to a valid existing URL. Or the XSDs should be corrected to alter the Schema locations from non-existing http://www.jboss.org/j2ee/schema/ (which has very few XSDs) to http://www.jboss.org/schema/jbossas/ (which has almost all the updated xsds) was: The Feature Request: https://issues.jboss.org/browse/WFLY-3014 Does not address the actual issue. - It is understood that we do not validate the xml with it. However there are some users who reads the XSD via valid schemaLocation and parse them according to their requirement for XML processing. - The XSDs that are shipped with wildfly uses a non existing "schemaLocation". For example: "jboss-web_8_0.xsd" {code} <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_8_0.xsd" version="8.0"> ... </jboss-web> {code} - The schema location points to http://www.jboss.org/j2ee/schema/jboss-web_8_0.xsd (causes 404 http response) Where as all those XSDs are actually present in another location, http://www.jboss.org/schema/jbossas/ So for the "jboss-web_8_0.xsd" the correct schemaLocation should be http://www.jboss.org/schema/jbossas/jboss-web_8_0.xsd So in order to avoid confusion to the users who are more familiar with XML/XSD naming the "schemaLocation" should be corrected in all the XSDs. *Expectation:* Either the XSDs should point to a valid existing URL. Or the XSDs should be corrected to alter the Schema locations from non-existing http://www.jboss.org/j2ee/schema/ (which has very few XSDs) to http://www.jboss.org/schema/jbossas/ (which has almost all the updated xsds) > XSDs should use a correct and existing schemaLocation. > ------------------------------------------------------ > > Key: WFLY-3961 > URL: https://issues.jboss.org/browse/WFLY-3961 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.1.0.Final, 9.0.0.Alpha1 > Environment: All > Reporter: Jay Kumar SenSharma > Assignee: Jason Greene > Labels: xml, xml_schema > > The Feature Request: https://issues.jboss.org/browse/WFLY-3014 > Does not address the actual issue. > - It is understood that we do not validate the xml with the "schemaLocation". However there are some users who reads the XSD via valid schemaLocation and parse them according to their requirement for XML processing. > - The XSDs that are shipped with wildfly uses a non existing "schemaLocation". For example: "jboss-web_8_0.xsd" > {code} > <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_8_0.xsd" > version="8.0"> > ... > </jboss-web> > {code} > - The schema location points to http://www.jboss.org/j2ee/schema/jboss-web_8_0.xsd (causes 404 http response) Where as all those XSDs are actually present in another location, http://www.jboss.org/schema/jbossas/ So for the "jboss-web_8_0.xsd" the correct schemaLocation should be http://www.jboss.org/schema/jbossas/jboss-web_8_0.xsd > So in order to avoid confusion to the users who are more familiar with XML/XSD naming the "schemaLocation" should be corrected in all the XSDs. > *Expectation:* Either the XSDs should point to a valid existing URL. Or the XSDs should be corrected to alter the Schema locations from non-existing http://www.jboss.org/j2ee/schema/ (which has very few XSDs) to http://www.jboss.org/schema/jbossas/ (which has almost all the updated xsds) -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3961) XSDs should use a correct and existing schemaLocation.

by Jay Kumar SenSharma (JIRA)

[ https://issues.jboss.org/browse/WFLY-3961?page=com.atlassian.jira.plugin.... ] Jay Kumar SenSharma updated WFLY-3961: -------------------------------------- Description: The Feature Request: https://issues.jboss.org/browse/WFLY-3014 Does not address the actual issue. - It is understood that we do not validate the xml with it. However there are some users who reads the XSD via valid schemaLocation and parse them according to their requirement for XML processing. - The XSDs that are shipped with wildfly uses a non existing "schemaLocation". For example: "jboss-web_8_0.xsd" {code} <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_8_0.xsd" version="8.0"> ... </jboss-web> {code} - The schema location points to http://www.jboss.org/j2ee/schema/jboss-web_8_0.xsd (causes 404 http response) Where as all those XSDs are actually present in another location, http://www.jboss.org/schema/jbossas/ So for the "jboss-web_8_0.xsd" the correct schemaLocation should be http://www.jboss.org/schema/jbossas/jboss-web_8_0.xsd So in order to avoid confusion to the users who are more familiar with XML/XSD naming the "schemaLocation" should be corrected in all the XSDs. *Expectation:* Either the XSDs should point to a valid existing URL. Or the XSDs should be corrected to alter the Schema locations from non-existing http://www.jboss.org/j2ee/schema/ (which has very few XSDs) to http://www.jboss.org/schema/jbossas/ (which has almost all the updated xsds) was: The Feature Request: https://issues.jboss.org/browse/WFLY-3014 Does not address the actuall issue. - It is understood that we do not validate the xml with it. However there are some users who reads the XSD via valid schemaLocation and parse them according to their requirement for XML processing. - The XSDs that are shipped with wildfly uses a non existing "schemaLocation". For example: "jboss-web_8_0.xsd" {code} <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_8_0.xsd" version="8.0"> ... </jboss-web> {code} - The schema location points to "http://www.jboss.org/j2ee/schema/jboss-web_8_0.xsd" Where as all those XSDs are actually present in another location, "http://www.jboss.org/schema/jbossas/" So for the "jboss-web_8_0.xsd" the correct schemaLocation should be "http://www.jboss.org/schema/jbossas/jboss-web_8_0.xsd" So in order to avoid confusion to the users who are more familiar with XML/XSD naming the "schemaLocation" should be corrected in all the XSDs. *Expectation:* Either the XSDs should point to a valid existing URL. Or the XSDs should be corrected to alter the Schema locations from non-existing "http://www.jboss.org/j2ee/schema/...." (which has very few XSDs) to ""http://www.jboss.org/schema/jbossas/...." (which has almost all the updated xsds) > XSDs should use a correct and existing schemaLocation. > ------------------------------------------------------ > > Key: WFLY-3961 > URL: https://issues.jboss.org/browse/WFLY-3961 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.1.0.Final, 9.0.0.Alpha1 > Environment: All > Reporter: Jay Kumar SenSharma > Assignee: Jason Greene > Labels: xml, xml_schema > > The Feature Request: https://issues.jboss.org/browse/WFLY-3014 > Does not address the actual issue. > - It is understood that we do not validate the xml with it. However there are some users who reads the XSD via valid schemaLocation and parse them according to their requirement for XML processing. > - The XSDs that are shipped with wildfly uses a non existing "schemaLocation". For example: "jboss-web_8_0.xsd" > {code} > <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_8_0.xsd" > version="8.0"> > ... > </jboss-web> > {code} > - The schema location points to http://www.jboss.org/j2ee/schema/jboss-web_8_0.xsd (causes 404 http response) Where as all those XSDs are actually present in another location, http://www.jboss.org/schema/jbossas/ So for the "jboss-web_8_0.xsd" the correct schemaLocation should be http://www.jboss.org/schema/jbossas/jboss-web_8_0.xsd > So in order to avoid confusion to the users who are more familiar with XML/XSD naming the "schemaLocation" should be corrected in all the XSDs. > *Expectation:* Either the XSDs should point to a valid existing URL. Or the XSDs should be corrected to alter the Schema locations from non-existing http://www.jboss.org/j2ee/schema/ (which has very few XSDs) to http://www.jboss.org/schema/jbossas/ (which has almost all the updated xsds) -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3961) XSDs should use a correct and existing schemaLocation.

by Jay Kumar SenSharma (JIRA)

Jay Kumar SenSharma created WFLY-3961: ----------------------------------------- Summary: XSDs should use a correct and existing schemaLocation. Key: WFLY-3961 URL: https://issues.jboss.org/browse/WFLY-3961 Project: WildFly Issue Type: Bug Affects Versions: 9.0.0.Alpha1, 8.1.0.Final Environment: All Reporter: Jay Kumar SenSharma Assignee: Jason Greene The Feature Request: https://issues.jboss.org/browse/WFLY-3014 Does not address the actuall issue. - It is understood that we do not validate the xml with it. However there are some users who reads the XSD via valid schemaLocation and parse them according to their requirement for XML processing. - The XSDs that are shipped with wildfly uses a non existing "schemaLocation". For example: "jboss-web_8_0.xsd" {code} <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_8_0.xsd" version="8.0"> ... </jboss-web> {code} - The schema location points to "http://www.jboss.org/j2ee/schema/jboss-web_8_0.xsd" Where as all those XSDs are actually present in another location, "http://www.jboss.org/schema/jbossas/" So for the "jboss-web_8_0.xsd" the correct schemaLocation should be "http://www.jboss.org/schema/jbossas/jboss-web_8_0.xsd" So in order to avoid confusion to the users who are more familiar with XML/XSD naming the "schemaLocation" should be corrected in all the XSDs. *Expectation:* Either the XSDs should point to a valid existing URL. Or the XSDs should be corrected to alter the Schema locations from non-existing "http://www.jboss.org/j2ee/schema/...." (which has very few XSDs) to ""http://www.jboss.org/schema/jbossas/...." (which has almost all the updated xsds) -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3960) Upgrade HAL to 2.4.3.Final

by Harald Pehl (JIRA)

Harald Pehl created WFLY-3960: --------------------------------- Summary: Upgrade HAL to 2.4.3.Final Key: WFLY-3960 URL: https://issues.jboss.org/browse/WFLY-3960 Project: WildFly Issue Type: Component Upgrade Components: Web Console Reporter: Harald Pehl Assignee: Harald Pehl Fix For: 8.2.0.CR1 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3959) Upgrade HAL to 2.4.3.Final

by Harald Pehl (JIRA)

[ https://issues.jboss.org/browse/WFLY-3959?page=com.atlassian.jira.plugin.... ] Harald Pehl updated WFLY-3959: ------------------------------ Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/6772) > Upgrade HAL to 2.4.3.Final > -------------------------- > > Key: WFLY-3959 > URL: https://issues.jboss.org/browse/WFLY-3959 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3960) Upgrade HAL to 2.4.3.Final

by Harald Pehl (JIRA)

[ https://issues.jboss.org/browse/WFLY-3960?page=com.atlassian.jira.plugin.... ] Harald Pehl updated WFLY-3960: ------------------------------ Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/6773) > Upgrade HAL to 2.4.3.Final > -------------------------- > > Key: WFLY-3960 > URL: https://issues.jboss.org/browse/WFLY-3960 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Fix For: 8.2.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2014