[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
[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
[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
[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
[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
[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
[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
[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