February 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4368) Remove usage of jboss-common-core in appclient

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFLY-4368: --------------------------------- Summary: Remove usage of jboss-common-core in appclient Key: WFLY-4368 URL: https://issues.jboss.org/browse/WFLY-4368 Project: WildFly Issue Type: Sub-task Components: Application Client Reporter: Tomaz Cerar Assignee: Stuart Douglas jboss-common-core usage should be reviewed and if possible eliminated. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-686) Documentation build: Upgrade pressgang-tools from 2 to 3

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-686?page=com.atlassian.jira.plugin... ] Petr Široký edited comment on DROOLS-686 at 2/19/15 12:40 PM: -------------------------------------------------------------- Thanks for [~ge0ffrey] for releasing the jdocbook-core and the plugin. I updated the versions in {{kie-parent-metadata}} and everything (kie-docs + optaplanner-docs) builds fine. was (Author: psiroky-redhat.com): Thanks for [~ge0ffrey] for releasing the jdocbook-core and the plugin. I update the versions in kie-parent-metadata and everything builds fine. > Documentation build: Upgrade pressgang-tools from 2 to 3 > -------------------------------------------------------- > > Key: DROOLS-686 > URL: https://issues.jboss.org/browse/DROOLS-686 > Project: Drools > Issue Type: Task > Reporter: Geoffrey De Smet > Assignee: Petr Široký > Fix For: 6.2.0.Final > > > We're still using pressgang-tools 2: > https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom.... > but some years ago pressgang-tools 3.x was build and released (by Steve Ebersole), which fixes some issues and enables some new features (such as topics in docbook): > https://github.com/pressgang/pressgang-tools > However, pressgang-tools 3.x has an important regression in combination with the maven-docbook-plugin 2.3.8, which prevents building offline, which is a blocker for us: > https://issues.jboss.org/browse/PRESSGANG-79 > The interesting note is that the gradle-docbook-plugin does build offline, and that both plugins (maven and gradle) use the same jdocbook-core: > https://github.com/pressgang > Goal: Fix that jira in maven-docbook-plugin and/or pressgang-tools, so droolsjbpm can upgrade to pressgang-tools 3.x. This is probably not easy. > The reason that it doesn't build offline, is because the xslt's contain full-url imports, so it reaches out to download those, but the jdocbook-core is able to intercepts to calls and reroute them to the local resources in the pressgang-tools jar (instead of downloading them from the internet). For some reason that works (probably configured correctly) for the gradle plugin, but not for the maven plugin. It's also strange that the maven plugin does work correctly with pressgang 2 jars. > In any case, the build should work offline (and doing "mvn -o" alone doesn't suffice to prove it, because the -o is ignored for the xslt stuff), plug out the network cable to verify it builds offline. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-686) Documentation build: Upgrade pressgang-tools from 2 to 3

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-686?page=com.atlassian.jira.plugin... ] Petr Široký resolved DROOLS-686. -------------------------------- Fix Version/s: 6.2.0.Final Resolution: Done Thanks for [~ge0ffrey] for releasing the jdocbook-core and the plugin. I update the versions in kie-parent-metadata and everything builds fine. > Documentation build: Upgrade pressgang-tools from 2 to 3 > -------------------------------------------------------- > > Key: DROOLS-686 > URL: https://issues.jboss.org/browse/DROOLS-686 > Project: Drools > Issue Type: Task > Reporter: Geoffrey De Smet > Assignee: Petr Široký > Fix For: 6.2.0.Final > > > We're still using pressgang-tools 2: > https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom.... > but some years ago pressgang-tools 3.x was build and released (by Steve Ebersole), which fixes some issues and enables some new features (such as topics in docbook): > https://github.com/pressgang/pressgang-tools > However, pressgang-tools 3.x has an important regression in combination with the maven-docbook-plugin 2.3.8, which prevents building offline, which is a blocker for us: > https://issues.jboss.org/browse/PRESSGANG-79 > The interesting note is that the gradle-docbook-plugin does build offline, and that both plugins (maven and gradle) use the same jdocbook-core: > https://github.com/pressgang > Goal: Fix that jira in maven-docbook-plugin and/or pressgang-tools, so droolsjbpm can upgrade to pressgang-tools 3.x. This is probably not easy. > The reason that it doesn't build offline, is because the xslt's contain full-url imports, so it reaches out to download those, but the jdocbook-core is able to intercepts to calls and reroute them to the local resources in the pressgang-tools jar (instead of downloading them from the internet). For some reason that works (probably configured correctly) for the gradle plugin, but not for the maven plugin. It's also strange that the maven plugin does work correctly with pressgang 2 jars. > In any case, the build should work offline (and doing "mvn -o" alone doesn't suffice to prove it, because the -o is ignored for the xslt stuff), plug out the network cable to verify it builds offline. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4303) Allow expressions in jboss-ejb-client.xml if configuration jboss-descriptor-property-replacement=true

by Tomasz Adamski (JIRA)

[ https://issues.jboss.org/browse/WFLY-4303?page=com.atlassian.jira.plugin.... ] Tomasz Adamski reassigned WFLY-4303: ------------------------------------ Assignee: Tomasz Adamski (was: Jason Greene) > Allow expressions in jboss-ejb-client.xml if configuration jboss-descriptor-property-replacement=true > ----------------------------------------------------------------------------------------------------- > > Key: WFLY-4303 > URL: https://issues.jboss.org/browse/WFLY-4303 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: Wolf-Dieter Fink > Assignee: Tomasz Adamski > > Applications need to have a jboss-ejb-client.xml configuration to use connections to other WildFly servers. > The remote-outbound-connection allow expressions, i.e. for user-name. > But if a cluster come into play the related <cluster> element inside the jboss-ejb-client.xml must have the same username and this can be only hardcoded. > So the jboss-ejb-client.xml parsing should allow expressions for > outbound-connection-ref, username, security-realm etc. > See https://github.com/wildfly/quickstart/blob/master/ejb-multi-server/app-ma... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1876) MERGE3 : Strange number and content of subgroups

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1876?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1876: --------------------------- Fix Version/s: 3.6.3 (was: 3.6.2) > MERGE3 : Strange number and content of subgroups > ------------------------------------------------ > > Key: JGRP-1876 > URL: https://issues.jboss.org/browse/JGRP-1876 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.4.2 > Reporter: Karim AMMOUS > Assignee: Bela Ban > Fix For: 3.6.3 > > Attachments: 4Subgroups.zip, ChannelCreator.java, DkeJgrpAddress.java, JGRP-1876-1.pdf, karim-logs-files.zip, MergeTest4.java, MergeViewWith210Subgroups.log, SplitMergeTest.java, views.txt > > > Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2). > The final mergeView is correct and contains 210 members. > Here is an extract of subviews: > {code} > INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172] > 210 subgroups > [.... > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]] > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]] > [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]] > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]] > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]] > ....] > {code} > II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view. > Example: > {code} > {A, B, C} => {A, B, C} and {C} => {A, B, C} > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1876) MERGE3 : Strange number and content of subgroups

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1876?page=com.atlassian.jira.plugin.... ] Bela Ban reopened JGRP-1876: ---------------------------- OK, one thing we can do is to discard all ViewIds from a given member P but its *last*: if we receive from P V|3 -> V|4 -> V|5 in a given period of time until the view consistency check is done, then currently all 3 subviews will be included in the final MergeView's subviews. The change is to only include V|5 from P. This reduces the number of subviews. > MERGE3 : Strange number and content of subgroups > ------------------------------------------------ > > Key: JGRP-1876 > URL: https://issues.jboss.org/browse/JGRP-1876 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.4.2 > Reporter: Karim AMMOUS > Assignee: Bela Ban > Fix For: 3.6.2 > > Attachments: 4Subgroups.zip, ChannelCreator.java, DkeJgrpAddress.java, JGRP-1876-1.pdf, karim-logs-files.zip, MergeTest4.java, MergeViewWith210Subgroups.log, SplitMergeTest.java, views.txt > > > Using JGroups 3.4.2, a split occurred and a merge was processed successfully but number of subgroups is wrong (210 instead of 2). > The final mergeView is correct and contains 210 members. > Here is an extract of subviews: > {code} > INFO | Incoming-18,cluster,term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F] | [MyMembershipListener.java:126] | (middleware) | MergeView view ID = [serv-ZM2BU35940-58033:vt-14:192.168.55.55:1:CL(GROUP01)[F]|172] > 210 subgroups > [.... > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [term-ETJ104215245-11092:host:192.168.56.72:1:CL(GROUP01)[F]] > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU38960-6907:asb:192.168.55.52:1:CL(GROUP01)[F]] > [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]|171] (1) [term-ETJ101697729-31726:host:192.168.56.6:1:CL(GROUP01)[F]] > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU47533-55240:vt-14:192.168.55.57:1:CL(GROUP01)[F]] > [term-ETJ100691812-36873:host:192.168.56.16:1:CL(GROUP01)[F]|170] (1) [serv-ZM2BU35943-49435:asb:192.168.55.51:1:CL(GROUP01)[F]] > ....] > {code} > II wasn't able to reproduce that with a simple program. But I observed that merge was preceded by an ifdown/ifup on host 192.168.56.6. That member lost all others members, but it still present in their view. > Example: > {code} > {A, B, C} => {A, B, C} and {C} => {A, B, C} > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4303) Allow expressions in jboss-ejb-client.xml if configuration jboss-descriptor-property-replacement=true

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4303?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-4303: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1194381 > Allow expressions in jboss-ejb-client.xml if configuration jboss-descriptor-property-replacement=true > ----------------------------------------------------------------------------------------------------- > > Key: WFLY-4303 > URL: https://issues.jboss.org/browse/WFLY-4303 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: Wolf-Dieter Fink > Assignee: Jason Greene > > Applications need to have a jboss-ejb-client.xml configuration to use connections to other WildFly servers. > The remote-outbound-connection allow expressions, i.e. for user-name. > But if a cluster come into play the related <cluster> element inside the jboss-ejb-client.xml must have the same username and this can be only hardcoded. > So the jboss-ejb-client.xml parsing should allow expressions for > outbound-connection-ref, username, security-realm etc. > See https://github.com/wildfly/quickstart/blob/master/ejb-multi-server/app-ma... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-556) Remove usage of jboss-common-core in domain-managment

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-556?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-556: ----------------------------------------- The usage here is for Base64. Simplest solution is to wait a bit for work to start on JDK 8-based WFCORE 2.0 and just get Base64 from the JDK. > Remove usage of jboss-common-core in domain-managment > ----------------------------------------------------- > > Key: WFCORE-556 > URL: https://issues.jboss.org/browse/WFCORE-556 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management > Reporter: Tomaz Cerar > Assignee: Brian Stansberry > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-559) Remove usage of jboss-common-core in testsuite

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFCORE-559: ---------------------------------- Summary: Remove usage of jboss-common-core in testsuite Key: WFCORE-559 URL: https://issues.jboss.org/browse/WFCORE-559 Project: WildFly Core Issue Type: Sub-task Components: Test Suite Reporter: Tomaz Cerar Assignee: Tomaz Cerar If possible we should get rid of dependency in testsuite -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-558) Remove usage of jboss-common-core in VFS

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFCORE-558: ---------------------------------- Summary: Remove usage of jboss-common-core in VFS Key: WFCORE-558 URL: https://issues.jboss.org/browse/WFCORE-558 Project: WildFly Core Issue Type: Sub-task Components: VFS Affects Versions: 1.0.0.Alpha18 Reporter: Tomaz Cerar Assignee: Tomaz Cerar -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

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 February 2015