April 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (LOGTOOL-101) Exception transformation

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-101?page=com.atlassian.jira.plugi... ] David Lloyd commented on LOGTOOL-101: ------------------------------------- Bonus points if you can figure out a way to clone the exception type! > Exception transformation > ------------------------ > > Key: LOGTOOL-101 > URL: https://issues.jboss.org/browse/LOGTOOL-101 > Project: Log Tool > Issue Type: Feature Request > Reporter: David Lloyd > Assignee: James Perkins > > I'd like to be able to transform an exception message. What this means is, create a new exception, embed its message in my message, and copy its stack trace to mine. > Something like this: > {code} > @Message(id = 1234, "Binding to %s failed") > IOException bindFailed(SocketAddress bindAddress, @TransformException IOException cause) > {code} > This would yield a message like: "Binding to 1.2.3.4/1234 failed: Address already in use". Note the addition of the ": " and the source string. > Note that I can almost do this now, except that there's no way to copy the exception stack: > {code} > @Message(id = 1234, "Binding to %s failed: %s") > IOException bindFailed(SocketAddress bindAddress, IOException cause) > {code} > An alternative approach is to add an annotation for copying the stack trace: > {code} > @Message(id = 1234, "Binding to %s failed") > IOException bindFailed(SocketAddress bindAddress, @CopyStackFrom IOException cause) > {code} > Note that in this case the original exception message is lost. The next variant would preserve the message: > {code} > @Message(id = 1234, "Binding to %s failed: %s") > IOException bindFailed(SocketAddress bindAddress, IOException cause, @CopyStackFrom IOException cause2) > {code} > And now to eliminate the duplication: > {code} > @Message(id = 1234, "Binding to %s failed: %s") > IOException bindFailed(SocketAddress bindAddress, @CopyStackFrom @Pos(2) IOException cause) > {code} > Note that I don't recall if @Pos is 1- or 0-based, so I guessed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-101) Exception transformation

by David Lloyd (JIRA)

David Lloyd created LOGTOOL-101: ----------------------------------- Summary: Exception transformation Key: LOGTOOL-101 URL: https://issues.jboss.org/browse/LOGTOOL-101 Project: Log Tool Issue Type: Feature Request Reporter: David Lloyd Assignee: James Perkins I'd like to be able to transform an exception message. What this means is, create a new exception, embed its message in my message, and copy its stack trace to mine. Something like this: {code} @Message(id = 1234, "Binding to %s failed") IOException bindFailed(SocketAddress bindAddress, @TransformException IOException cause) {code} This would yield a message like: "Binding to 1.2.3.4/1234 failed: Address already in use". Note the addition of the ": " and the source string. Note that I can almost do this now, except that there's no way to copy the exception stack: {code} @Message(id = 1234, "Binding to %s failed: %s") IOException bindFailed(SocketAddress bindAddress, IOException cause) {code} An alternative approach is to add an annotation for copying the stack trace: {code} @Message(id = 1234, "Binding to %s failed") IOException bindFailed(SocketAddress bindAddress, @CopyStackFrom IOException cause) {code} Note that in this case the original exception message is lost. The next variant would preserve the message: {code} @Message(id = 1234, "Binding to %s failed: %s") IOException bindFailed(SocketAddress bindAddress, IOException cause, @CopyStackFrom IOException cause2) {code} And now to eliminate the duplication: {code} @Message(id = 1234, "Binding to %s failed: %s") IOException bindFailed(SocketAddress bindAddress, @CopyStackFrom @Pos(2) IOException cause) {code} Note that I don't recall if @Pos is 1- or 0-based, so I guessed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2023) Network unreachable with localhost addresses if -Djava.net.preferIPv4Stack=true isn't specified

by Richard Janík (JIRA)

[ https://issues.jboss.org/browse/JGRP-2023?page=com.atlassian.jira.plugin.... ] Richard Janík commented on JGRP-2023: ------------------------------------- I've managed to set up multicast on localhost on my machine by doing the following: * add multicast flag to my localhost interface: {{sudo ifconfig lo multicast}} * add a routing with a interface local address: {{sudo route -6 add ff01::/16 dev lo}} * and use the interface local multicast address {{ff01::1}} * I also had firewall turned off (fedora 22: {{sudo service firewalld stop}}) so it might be necessary to tune that as well > Network unreachable with localhost addresses if -Djava.net.preferIPv4Stack=true isn't specified > ----------------------------------------------------------------------------------------------- > > Key: JGRP-2023 > URL: https://issues.jboss.org/browse/JGRP-2023 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.7, 3.6.8 > Environment: $ java -version > java version "1.8.0_45" > Java(TM) SE Runtime Environment (build 1.8.0_45-b14) > Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode) > Reporter: Richard Janík > Assignee: Bela Ban > > When setting {{-bind_addr}} to localhost (either 127.0.0.1 or ::1) without specifying {{-Djava.net.preferIPv4Stack=true}}, JGroups fail to connect. The following errors are logged: > {code} > ------------------------------------------------------------------- > GMS: address=rjanik-24069, cluster=draw, physical address=0:0:0:0:0:0:0:1:37921 > ------------------------------------------------------------------- > Mar 03, 2016 11:41:12 AM org.jgroups.protocols.TP$BaseBundler sendSingleMessage > SEVERE: JGRP000029: rjanik-24069: failed sending message to cluster (108 bytes): java.io.IOException: Network is unreachable, headers: PING: [type=GET_MBRS_REQ, cluster=draw], TP: [cluster_name=draw] > ** View=[rjanik-24069|0] (1) [rjanik-24069] > Mar 03, 2016 11:41:15 AM org.jgroups.protocols.TP$BaseBundler sendSingleMessage > SEVERE: JGRP000029: rjanik-24069: failed sending message to cluster (56 bytes): java.io.IOException: Network is unreachable, headers: NAKACK2: [MSG, seqno=1], TP: [cluster_name=draw] > {code} > I'm not sure if there's some other configuration option that I forgot to add, but the example (in Steps to Reproduce) works with previous versions (3.6.6 for example), so I assume not. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SECURITY-917) Remove setStatusCode call in NegotiationMechanism

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/SECURITY-917?page=com.atlassian.jira.plug... ] Darran Lofthouse updated SECURITY-917: -------------------------------------- Fix Version/s: Negotiation_3_0_3_CR1 (was: Negotiation_3_0_2_Final) > Remove setStatusCode call in NegotiationMechanism > ------------------------------------------------- > > Key: SECURITY-917 > URL: https://issues.jboss.org/browse/SECURITY-917 > Project: PicketBox > Issue Type: Task > Components: Negotiation > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: Negotiation_3_0_3_CR1 > > > Once UNDERTOW-548 is resolved we can remove manually setting the status code ourselves. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SECURITY-915) Migrate MessageFactory discovery to use ServiceLoader

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/SECURITY-915?page=com.atlassian.jira.plug... ] Darran Lofthouse updated SECURITY-915: -------------------------------------- Fix Version/s: Negotiation_3_0_3_CR1 (was: Negotiation_3_0_2_Final) > Migrate MessageFactory discovery to use ServiceLoader > ----------------------------------------------------- > > Key: SECURITY-915 > URL: https://issues.jboss.org/browse/SECURITY-915 > Project: PicketBox > Issue Type: Feature Request > Components: Negotiation > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: Negotiation_3_0_3_CR1 > > > At the moment we have statically defined class names and attempt to load them in turn to identify which ones are actually available - ServiceLoader based discovery would eliminate this. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SECURITY-940) Release JBoss Negotiation 3.0.2.Final

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/SECURITY-940?page=com.atlassian.jira.plug... ] Darran Lofthouse resolved SECURITY-940. --------------------------------------- Resolution: Done > Release JBoss Negotiation 3.0.2.Final > ------------------------------------- > > Key: SECURITY-940 > URL: https://issues.jboss.org/browse/SECURITY-940 > Project: PicketBox > Issue Type: Release > Components: Negotiation > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: Negotiation_3_0_2_CR1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1025) NPE removing a rule that contains a subnetwork

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1025?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on DROOLS-1025: ------------------------------------------------- Tibor Zimanyi <tzimanyi(a)redhat.com> changed the Status of [bug 1298579|https://bugzilla.redhat.com/show_bug.cgi?id=1298579] from ON_QA to VERIFIED > NPE removing a rule that contains a subnetwork > ---------------------------------------------- > > Key: DROOLS-1025 > URL: https://issues.jboss.org/browse/DROOLS-1025 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > > Removing a rule containing a subnetwork causes the following NPE: > {code} > java.lang.NullPointerException > at org.drools.core.phreak.AddRemoveRule.deletePeerLeftTuple(AddRemoveRule.java:777) > at org.drools.core.phreak.AddRemoveRule.followPeer(AddRemoveRule.java:749) > at org.drools.core.phreak.AddRemoveRule.processLeftTuples(AddRemoveRule.java:713) > at org.drools.core.phreak.AddRemoveRule.flushStagedTuples(AddRemoveRule.java:281) > at org.drools.core.phreak.AddRemoveRule.removeRule(AddRemoveRule.java:153) > at org.drools.core.reteoo.ReteooBuilder.removeTerminalNode(ReteooBuilder.java:173) > at org.drools.core.reteoo.ReteooBuilder.removeRule(ReteooBuilder.java:163) > at org.drools.core.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:1635) > at org.drools.core.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:1626) > at org.drools.core.impl.KnowledgeBaseImpl.internalRemoveRule(KnowledgeBaseImpl.java:1610) > at org.drools.core.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:1581) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1089) Reentrant working memory actions aren't flushed immediately even when eager evaluation is forced

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1089?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on DROOLS-1089: ------------------------------------------------- Tibor Zimanyi <tzimanyi(a)redhat.com> changed the Status of [bug 1316860|https://bugzilla.redhat.com/show_bug.cgi?id=1316860] from ON_QA to VERIFIED > Reentrant working memory actions aren't flushed immediately even when eager evaluation is forced > ------------------------------------------------------------------------------------------------ > > Key: DROOLS-1089 > URL: https://issues.jboss.org/browse/DROOLS-1089 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.4.0.CR2, 7.0.0.Final > > > jBPM requires Drools working memory actions to be immediately flushed and then uses Drools force eager activation option. However even when this option is enabled working memory actions that aren't created in a reentrant way (during a rule firing) are enqueued instead of being flushed as expected by jBPM. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6449) Upgrade Narayana to 5.3.2.Final

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/WFLY-6449?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated WFLY-6449: ---------------------------------- Fix Version/s: 11.0.0.Alpha1 > Upgrade Narayana to 5.3.2.Final > ------------------------------- > > Key: WFLY-6449 > URL: https://issues.jboss.org/browse/WFLY-6449 > Project: WildFly > Issue Type: Component Upgrade > Components: Transactions > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 11.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SECURITY-939) Contents of NegotiationContext getting cleared before challenge is sent to client.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/SECURITY-939?page=com.atlassian.jira.plug... ] Darran Lofthouse resolved SECURITY-939. --------------------------------------- Resolution: Done > Contents of NegotiationContext getting cleared before challenge is sent to client. > ---------------------------------------------------------------------------------- > > Key: SECURITY-939 > URL: https://issues.jboss.org/browse/SECURITY-939 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Affects Versions: Negotiation_3_0_0_Final > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: Negotiation_3_0_2_CR1 > > -- 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 April 2016