November 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1453) Sigtest: In public API non public class RealmDefiniteOutcomeAuthenticationEvent is used

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1453?page=com.atlassian.jira.plugin.s... ] Jan Kalina reassigned ELY-1453: ------------------------------- Assignee: Jan Kalina > Sigtest: In public API non public class RealmDefiniteOutcomeAuthenticationEvent is used > --------------------------------------------------------------------------------------- > > Key: ELY-1453 > URL: https://issues.jboss.org/browse/ELY-1453 > Project: WildFly Elytron > Issue Type: Bug > Components: API / SPI > Affects Versions: 1.2.0.Beta10 > Reporter: Martin Choma > Assignee: Jan Kalina > > SigTest check reveals: > {noformat} > Hidden class found: > org.wildfly.security.auth.server.event.RealmDefiniteOutcomeAuthenticationEvent > in method public > {org.wildfly.security.auth.server.event.RealmEventVisitor%1} > org.wildfly.security.auth.server.event.RealmEventVisitor.handleDefiniteOutcomeAuthenticationEvent(org.wildfly.security.auth.server.event.RealmDefiniteOutcomeAuthenticationEvent,{org.wildfly.security.auth.server.event.RealmEventVisitor%0}) > in class org.wildfly.security.auth.server.event.RealmEventVisitor > {noformat} > Fix could be as easy as make RealmDefiniteOutcomeAuthenticationEvent public. > But I still left for developers judgement if make constructor of RealmDefiniteOutcomeAuthenticationEvent package private. Thus RealmDefiniteOutcomeAuthenticationEvent can't be inherited from. If that was reason for not marking this class as public originally. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2236) UNICAST max_xmit_req_size doesn't work

by Dennis Reed (JIRA)

[ https://issues.jboss.org/browse/JGRP-2236?page=com.atlassian.jira.plugin.... ] Dennis Reed commented on JGRP-2236: ----------------------------------- Manually setting max_xmit_req_size is not a workaround, since the bug is that it does not actually effect the message size. > UNICAST max_xmit_req_size doesn't work > -------------------------------------- > > Key: JGRP-2236 > URL: https://issues.jboss.org/browse/JGRP-2236 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.1 > Reporter: Dennis Reed > Assignee: Bela Ban > Fix For: 4.0.9 > > > UNICAST3 sets max_xmit_req_size to avoid requesting too many messages to fit into the maximum message size. > But the check is implemented incorrectly, so it is not effective. > JGRP000029: node1: failed sending message to node2 (120314 bytes): java.io.IOException: Message too long, headers: UNICAST3: XMIT_REQ, seqno=0, TP: [cluster_name=cluster] -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9564) Segregate EJB client clustering tests into separate profile

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9564?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-9564: --------------------------------- Attachment: after.txt before.txt > Segregate EJB client clustering tests into separate profile > ----------------------------------------------------------- > > Key: WFLY-9564 > URL: https://issues.jboss.org/browse/WFLY-9564 > Project: WildFly > Issue Type: Task > Components: Clustering, Test Suite > Affects Versions: 11.0.0.Final > Reporter: Paul Ferraro > Assignee: Radoslav Husar > Attachments: after.txt, before.txt > > > Because the EJB client relies heavily on static global context, the our ejb client tests need to be run with reuseForks disabled. This slows down the entire clustering testsuite significantly. > Instead we should isolate the ejb client tests into a separate profile, such that the rest of the clustering testsuite can enable reuseForks. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3205) Logging does not work in the embedded server

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3205?page=com.atlassian.jira.plugi... ] David Lloyd commented on WFCORE-3205: ------------------------------------- Well, perhaps we could add a way to disable the wrapping. A command line switch or system property, or something of that sort. But yeah setting a logger for stdout and stderr would work as well, and would have the added advantage (compared to passing through stdout/stderr) of ensuring that the output of logging and the output of stdout/stderr don't get jumbled too much. > Logging does not work in the embedded server > -------------------------------------------- > > Key: WFCORE-3205 > URL: https://issues.jboss.org/browse/WFCORE-3205 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > When using the {{EmbeddedProcessFactory}} logging does not appear to work. Debugging shows a different {{LogContext}} associated with the loggers than the one associated with the logging subsystem. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3205) Logging does not work in the embedded server

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3205?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-3205: --------------------------------------- Yeah. That has to do with jboss-stdio wrapping the {{System.out}} and {{System.err}}. It doesn't look like there is a workaround for that short of editing the {{logging.properties}} file or creating a logger called {{stdout}} and creating a second console handler/appender with a message only pattern. > Logging does not work in the embedded server > -------------------------------------------- > > Key: WFCORE-3205 > URL: https://issues.jboss.org/browse/WFCORE-3205 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > When using the {{EmbeddedProcessFactory}} logging does not appear to work. Debugging shows a different {{LogContext}} associated with the loggers than the one associated with the logging subsystem. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3205) Logging does not work in the embedded server

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3205?page=com.atlassian.jira.plugi... ] David Lloyd commented on WFCORE-3205: ------------------------------------- So in embedded mode we probably need to be disabling the stdio wrapping stuff. > Logging does not work in the embedded server > -------------------------------------------- > > Key: WFCORE-3205 > URL: https://issues.jboss.org/browse/WFCORE-3205 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > When using the {{EmbeddedProcessFactory}} logging does not appear to work. Debugging shows a different {{LogContext}} associated with the loggers than the one associated with the logging subsystem. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1763) Dependent rule not firing

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1763?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-1763. --------------------------------- Resolution: Rejected I'm rejecting this issue for now, but please feel free to reopen it in case you will find that my advices didn't help you. > Dependent rule not firing > ------------------------- > > Key: DROOLS-1763 > URL: https://issues.jboss.org/browse/DROOLS-1763 > Project: Drools > Issue Type: Bug > Affects Versions: 7.0.0.Beta7, 7.3.0.Final > Environment: Linux all versions. > JDK 1.8.0 Update 144 > Reporter: David Wade > Assignee: Mario Fusco > Attachments: 7.0.0.Beta6.txt, 7.3.0.Final.txt > > > We have been using Drools since 2.x. > Currently we use 7.0.0.Beta6 which works. > We can't upgrade because since 7.0.0.Beta7 rules dependent on the consequence of another rule are not firing for some reason. This happens for us on 7.0.0.Beta7 through to 7.3.0.Final. > Consider the following two rules. When run on 7.0.0.Beta6 both rules fire. From Beta7 through to 7.3.0.Final, only the SQ rule fire, despite the RC rule passing its conditions > {code} > rule "H2" > salience -300 > when > segment:SegmentWithTax( > containsTax("SQ") > , notContainsTax("H2", "RC") > ) > then > segment.addPercentageTaxEntry(taxCodeMap,"SQ","RC_13_PERCENT"); > end > rule "SQ" > when > segment:SegmentWithTax( > !containsTax("SQ") > ) > then > modify(segment) { > addTaxEntry(taxCodeMap,"SQ_TRANSFER_TRANSIT_LESS_THAN_FOUR_HOURS") > } > end > {code} > Will attach Drools trace logging output * 2. One for [^7.0.0.Beta6.txt] , one for [^7.3.0.Final.txt] . -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1763) Dependent rule not firing

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1763?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-1763: -------------------------------- Sprint: 2017 Week 47-48 > Dependent rule not firing > ------------------------- > > Key: DROOLS-1763 > URL: https://issues.jboss.org/browse/DROOLS-1763 > Project: Drools > Issue Type: Bug > Affects Versions: 7.0.0.Beta7, 7.3.0.Final > Environment: Linux all versions. > JDK 1.8.0 Update 144 > Reporter: David Wade > Assignee: Mario Fusco > Attachments: 7.0.0.Beta6.txt, 7.3.0.Final.txt > > > We have been using Drools since 2.x. > Currently we use 7.0.0.Beta6 which works. > We can't upgrade because since 7.0.0.Beta7 rules dependent on the consequence of another rule are not firing for some reason. This happens for us on 7.0.0.Beta7 through to 7.3.0.Final. > Consider the following two rules. When run on 7.0.0.Beta6 both rules fire. From Beta7 through to 7.3.0.Final, only the SQ rule fire, despite the RC rule passing its conditions > {code} > rule "H2" > salience -300 > when > segment:SegmentWithTax( > containsTax("SQ") > , notContainsTax("H2", "RC") > ) > then > segment.addPercentageTaxEntry(taxCodeMap,"SQ","RC_13_PERCENT"); > end > rule "SQ" > when > segment:SegmentWithTax( > !containsTax("SQ") > ) > then > modify(segment) { > addTaxEntry(taxCodeMap,"SQ_TRANSFER_TRANSIT_LESS_THAN_FOUR_HOURS") > } > end > {code} > Will attach Drools trace logging output * 2. One for [^7.0.0.Beta6.txt] , one for [^7.3.0.Final.txt] . -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2151) DMN default disable Runtime type-check, provide flag for explicit enablement

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2151?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-2151: ----------------------------------- Sprint: 2017 Week 47-48 > DMN default disable Runtime type-check, provide flag for explicit enablement > ---------------------------------------------------------------------------- > > Key: DROOLS-2151 > URL: https://issues.jboss.org/browse/DROOLS-2151 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2236) UNICAST max_xmit_req_size doesn't work

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2236?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2236: -------------------------------- Added unit test reproducing the issue to {{TableTest}}: {code:java} public void testGetMissingWithMaxBundleSize() { final int max_bundle_size=64000; final int max_xmit_req_size=(max_bundle_size -50) * Global.LONG_SIZE; Table<Integer> table=new Table<>(10, 1000, 0); table.add(0, 0); table.add(1_000_000, 1_000_000); System.out.println("table = " + table); SeqnoList missing=table.getMissing(max_xmit_req_size); System.out.println("missing = " + missing); int serialized_size=missing.serializedSize(); assert serialized_size <= max_bundle_size : String.format("serialized size of %d needs to be less than max_bundle_size of %d bytes", serialized_size, max_bundle_size); } {code} > UNICAST max_xmit_req_size doesn't work > -------------------------------------- > > Key: JGRP-2236 > URL: https://issues.jboss.org/browse/JGRP-2236 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.1 > Reporter: Dennis Reed > Assignee: Bela Ban > Fix For: 4.0.9 > > > UNICAST3 sets max_xmit_req_size to avoid requesting too many messages to fit into the maximum message size. > But the check is implemented incorrectly, so it is not effective. > JGRP000029: node1: failed sending message to node2 (120314 bytes): java.io.IOException: Message too long, headers: UNICAST3: XMIT_REQ, seqno=0, TP: [cluster_name=cluster] -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 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 November 2017