March 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1101) Upgrade protobuf-java from 2.5.0 to 2.6.0

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1101?page=com.atlassian.jira.plugi... ] Geoffrey De Smet commented on DROOLS-1101: ------------------------------------------ Ip-bom change on master: https://github.com/jboss-integration/jboss-integration-platform-bom/pull/276 on 6.0.x of ip-bom (used in drools 6.4.x): https://github.com/jboss-integration/jboss-integration-platform-bom/pull/277 > Upgrade protobuf-java from 2.5.0 to 2.6.0 > ----------------------------------------- > > Key: DROOLS-1101 > URL: https://issues.jboss.org/browse/DROOLS-1101 > Project: Drools > Issue Type: Task > Components: core engine > Reporter: Geoffrey De Smet > Assignee: Geoffrey De Smet > > From RPM discussion (BPMSPL-282) > Productization: protobuf-java redhat version is: 2.6.0-redhat-1, is it ok to upgrade from 2.5.0->2.6.0? > Motivation: > - The 2.5 version isn't build from source by productization, there is no redhat version. > - The 2.6 version is, which means they can do security patches on it easily (= important for long term support) and it can be RPM'ed (important for BPMSPL-282, which has PM support) > - 2.6 is higher than 2.5, so in theory this is low-risk change. > Needed on both master and 6.4.x. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1445) Fix schema as native-interface shouldn't be mandatory for host-management-interfaces

by ehsavoie Hugonnet (JIRA)

ehsavoie Hugonnet created WFCORE-1445: ----------------------------------------- Summary: Fix schema as native-interface shouldn't be mandatory for host-management-interfaces Key: WFCORE-1445 URL: https://issues.jboss.org/browse/WFCORE-1445 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 2.1.0.Final Reporter: ehsavoie Hugonnet Assignee: ehsavoie Hugonnet Priority: Minor Since host-management-interfaces could use http-remoting or native remote protocols the native-interface shouldn't be mandatory. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1444) Fix schema as native-interface shouldn't be mandatory for host-management-interfaces

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1444?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet reassigned WFCORE-1444: ----------------------------------------- Assignee: ehsavoie Hugonnet (was: Brian Stansberry) > Fix schema as native-interface shouldn't be mandatory for host-management-interfaces > ------------------------------------------------------------------------------------ > > Key: WFCORE-1444 > URL: https://issues.jboss.org/browse/WFCORE-1444 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.1.0.Final > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > Priority: Minor > > Since host-management-interfaces could use http-remoting or native remote protocols the native-interface shouldn't be mandatory. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1444) Fix schema as native-interface shouldn't be mandatory for host-management-interfaces

by ehsavoie Hugonnet (JIRA)

ehsavoie Hugonnet created WFCORE-1444: ----------------------------------------- Summary: Fix schema as native-interface shouldn't be mandatory for host-management-interfaces Key: WFCORE-1444 URL: https://issues.jboss.org/browse/WFCORE-1444 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 2.1.0.Final Reporter: ehsavoie Hugonnet Assignee: Brian Stansberry Priority: Minor Since host-management-interfaces could use http-remoting or native remote protocols the native-interface shouldn't be mandatory. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-1066) Automatic configuration of 'Initial_hosts' for a cluster using JGroups TCP-stack in domain mode (aka DOMAIN_PING)

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/WFLY-1066?page=com.atlassian.jira.plugin.... ] Bela Ban commented on WFLY-1066: -------------------------------- Oops, should have read the JIRA better, you're actually using TCP as transport. Then, yes, discovery is used (not with UDP)... > Automatic configuration of 'Initial_hosts' for a cluster using JGroups TCP-stack in domain mode (aka DOMAIN_PING) > ----------------------------------------------------------------------------------------------------------------- > > Key: WFLY-1066 > URL: https://issues.jboss.org/browse/WFLY-1066 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management > Environment: Server running in Domain mode > Reporter: Wolf-Dieter Fink > Assignee: Sebastian Łaskawiec > Labels: clustering, domain, jgroups > > It is complicated to keep the subsystem JGroups in sync if the tcp-stack is used in domain mode. > All new servers that join/leave a clustered server group (configuration) must be added or removed by hand for the jgroup configuration. > The domain server will receive the informations if a host-controller enrol and register server to a clustered server-group. > So the configuration of the initial_hosts can be done automaticaly to avoid old entries which cause unnecessary checks and ensure that all active servers are known. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-1066) Automatic configuration of 'Initial_hosts' for a cluster using JGroups TCP-stack in domain mode (aka DOMAIN_PING)

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/WFLY-1066?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec reassigned WFLY-1066: ----------------------------------------- Assignee: Sebastian Łaskawiec (was: Tristan Tarrant) > Automatic configuration of 'Initial_hosts' for a cluster using JGroups TCP-stack in domain mode (aka DOMAIN_PING) > ----------------------------------------------------------------------------------------------------------------- > > Key: WFLY-1066 > URL: https://issues.jboss.org/browse/WFLY-1066 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management > Environment: Server running in Domain mode > Reporter: Wolf-Dieter Fink > Assignee: Sebastian Łaskawiec > Labels: clustering, domain, jgroups > > It is complicated to keep the subsystem JGroups in sync if the tcp-stack is used in domain mode. > All new servers that join/leave a clustered server group (configuration) must be added or removed by hand for the jgroup configuration. > The domain server will receive the informations if a host-controller enrol and register server to a clustered server-group. > So the configuration of the initial_hosts can be done automaticaly to avoid old entries which cause unnecessary checks and ensure that all active servers are known. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1101) Upgrade protobuf-java from 2.5.0 to 2.6.0

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1101?page=com.atlassian.jira.plugi... ] Geoffrey De Smet commented on DROOLS-1101: ------------------------------------------ The drools-osgi don't even use 2.5 before: {code} <karaf.servicemix.version.com.google.protobuf>2.4.1_1</karaf.servicemix.version.com.google.protobuf> {code} so they will be no regression (nor any improvement in that area). > Upgrade protobuf-java from 2.5.0 to 2.6.0 > ----------------------------------------- > > Key: DROOLS-1101 > URL: https://issues.jboss.org/browse/DROOLS-1101 > Project: Drools > Issue Type: Task > Components: core engine > Reporter: Geoffrey De Smet > Assignee: Geoffrey De Smet > > From RPM discussion (BPMSPL-282) > Productization: protobuf-java redhat version is: 2.6.0-redhat-1, is it ok to upgrade from 2.5.0->2.6.0? > Motivation: > - The 2.5 version isn't build from source by productization, there is no redhat version. > - The 2.6 version is, which means they can do security patches on it easily (= important for long term support) and it can be RPM'ed (important for BPMSPL-282, which has PM support) > - 2.6 is higher than 2.5, so in theory this is low-risk change. > Needed on both master and 6.4.x. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1101) Upgrade protobuf-java from 2.5.0 to 2.6.0

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1101?page=com.atlassian.jira.plugi... ] Geoffrey De Smet commented on DROOLS-1101: ------------------------------------------ Protobuf 2.6.0's Manifest has this weirdness: {code} Bundle-Version: 2.6.0 ... Export-Package: com.google.protobuf;version="2.5.0" {code} I 'll run the drools-osgi tests. > Upgrade protobuf-java from 2.5.0 to 2.6.0 > ----------------------------------------- > > Key: DROOLS-1101 > URL: https://issues.jboss.org/browse/DROOLS-1101 > Project: Drools > Issue Type: Task > Components: core engine > Reporter: Geoffrey De Smet > Assignee: Geoffrey De Smet > > From RPM discussion (BPMSPL-282) > Productization: protobuf-java redhat version is: 2.6.0-redhat-1, is it ok to upgrade from 2.5.0->2.6.0? > Motivation: > - The 2.5 version isn't build from source by productization, there is no redhat version. > - The 2.6 version is, which means they can do security patches on it easily (= important for long term support) and it can be RPM'ed (important for BPMSPL-282, which has PM support) > - 2.6 is higher than 2.5, so in theory this is low-risk change. > Needed on both master and 6.4.x. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1101) Upgrade protobuf-java from 2.5.0 to 2.6.0

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1101?page=com.atlassian.jira.plugi... ] Geoffrey De Smet reassigned DROOLS-1101: ---------------------------------------- Assignee: Geoffrey De Smet (was: Mario Fusco) > Upgrade protobuf-java from 2.5.0 to 2.6.0 > ----------------------------------------- > > Key: DROOLS-1101 > URL: https://issues.jboss.org/browse/DROOLS-1101 > Project: Drools > Issue Type: Task > Components: core engine > Reporter: Geoffrey De Smet > Assignee: Geoffrey De Smet > > From RPM discussion (BPMSPL-282) > Productization: protobuf-java redhat version is: 2.6.0-redhat-1, is it ok to upgrade from 2.5.0->2.6.0? > Motivation: > - The 2.5 version isn't build from source by productization, there is no redhat version. > - The 2.6 version is, which means they can do security patches on it easily (= important for long term support) and it can be RPM'ed (important for BPMSPL-282, which has PM support) > - 2.6 is higher than 2.5, so in theory this is low-risk change. > Needed on both master and 6.4.x. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-1066) Automatic configuration of 'Initial_hosts' for a cluster using JGroups TCP-stack in domain mode (aka DOMAIN_PING)

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-1066?page=com.atlassian.jira.plugin.... ] Brian Stansberry edited comment on WFLY-1066 at 3/21/16 11:50 AM: ------------------------------------------------------------------ LOL. Yes, it's been a loooong while! I'm clueless myself but got my info from a source who shall remain nameless. Something about how MERGE3 "uses the Event.FIND_MBRS_EVT, same as MERGE2". was (Author: brian.stansberry): LOL. Yes, it's been a loooong while! I'm clueless myself but got my info from a source who shall remain nameless. Something about how MERGE "uses the Event.FIND_MBRS_EVT, same as MERGE2". > Automatic configuration of 'Initial_hosts' for a cluster using JGroups TCP-stack in domain mode (aka DOMAIN_PING) > ----------------------------------------------------------------------------------------------------------------- > > Key: WFLY-1066 > URL: https://issues.jboss.org/browse/WFLY-1066 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management > Environment: Server running in Domain mode > Reporter: Wolf-Dieter Fink > Assignee: Tristan Tarrant > Labels: clustering, domain, jgroups > > It is complicated to keep the subsystem JGroups in sync if the tcp-stack is used in domain mode. > All new servers that join/leave a clustered server group (configuration) must be added or removed by hand for the jgroup configuration. > The domain server will receive the informations if a host-controller enrol and register server to a clustered server-group. > So the configuration of the initial_hosts can be done automaticaly to avoid old entries which cause unnecessary checks and ensure that all active servers are known. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2016