October 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (LOGMGR-99) Infinite recursion when exception stack frame class lookup fails

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-99?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on LOGMGR-99: ----------------------------------------------- James Perkins <jperkins(a)redhat.com> changed the Status of [bug 1071695|https://bugzilla.redhat.com/show_bug.cgi?id=1071695] from NEW to ASSIGNED > Infinite recursion when exception stack frame class lookup fails > ---------------------------------------------------------------- > > Key: LOGMGR-99 > URL: https://issues.jboss.org/browse/LOGMGR-99 > Project: JBoss Log Manager > Issue Type: Bug > Affects Versions: 1.5.1.Final > Reporter: James Livingston > Assignee: James Perkins > Priority: Critical > Fix For: 1.3.3.Final, 1.4.4.Final, 1.5.4.Final, 2.0.0.Beta2 > > Attachments: logmgr99.war > > > To print out the jar information in exception stack traces, the log manager needs to resolve the class name from StackTraceElement to the Class object. Since the log manager cannot know which classloader was used, guessClass() tries the TCCL, the logmanager's classloader and finally the system classloader. > It is possible that the TCCL contains a class of the same name as the one in the stack frame, but it not the same class. This can easily happen if the application packages a jar that is also used by the container. In this situation, the class may not be able to be loaded, such as if the application-packages class is missing it's dependencies. > If Class.forName() would throw a NoClassDefFoundError or similar, JBoss Modules (or other classloader implementation) may attempt to log this using java.util.logging API. This can result in infinite recursion, for example > {code} > ... > at org.jboss.logmanager.Logger.log(Logger.java:367) > at org.jboss.modules.log.JDKModuleLogger.doLog(JDKModuleLogger.java:109) > at org.jboss.modules.log.JDKModuleLogger.classDefineFailed(JDKModuleLogger.java:194) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:401) > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:243) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:73) > at org.jboss.modules.Module.loadModuleClass(Module.java:527) > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:182) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:266) > at org.jboss.logmanager.formatters.Formatters$12.guessClass(Formatters.java:578) > at org.jboss.logmanager.formatters.Formatters$12.renderExtended(Formatters.java:421) > at org.jboss.logmanager.formatters.Formatters$12.renderRaw(Formatters.java:388) > at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:150) > at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86) > at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35) > at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49) > at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:290) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298) > at org.jboss.logmanager.Logger.logRaw(Logger.java:721) > at org.jboss.logmanager.Logger.logRaw(Logger.java:731) > at org.jboss.logmanager.Logger.log(Logger.java:367) > ... > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-150) Undefining suffix on size-rotating-file-handler sets invalid value on suffix

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-150?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-150: ------------------------------------------------ James Perkins <jperkins(a)redhat.com> changed the Status of [bug 1148842|https://bugzilla.redhat.com/show_bug.cgi?id=1148842] from ASSIGNED to POST > Undefining suffix on size-rotating-file-handler sets invalid value on suffix > ---------------------------------------------------------------------------- > > Key: WFCORE-150 > URL: https://issues.jboss.org/browse/WFCORE-150 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > When the suffix is undefined ({{undefine-attribute(name=suffix)}}) on a {{size-rotating-file-handler}} the value {{undefined}} gets written to the suffix which is invalid. The value needs to be set to null if undefined. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-152) Rewriting the property attribute on custom handlers or formatters does not unset values

by James Perkins (JIRA)

James Perkins created WFCORE-152: ------------------------------------ Summary: Rewriting the property attribute on custom handlers or formatters does not unset values Key: WFCORE-152 URL: https://issues.jboss.org/browse/WFCORE-152 Project: WildFly Core Issue Type: Bug Components: Logging Reporter: James Perkins Assignee: James Perkins I'm not setting a target for this as likely part of this needs to be solved in the logmanager. Currently rewriting properties does not unset properties that have been removed from the property map. It seems simple enough to just pass a {{null}} value to the property and then remove the property, but this won't work for primitives. >From the WildFly perspective there is know way from the configuration API to determine the type for a property to set. This is the part that should probably be handled in the logmanager. WildFly will need to set the value to {{null}} once this is solved on the logmanager side. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3944) Broken integration between messaging subsystem and jgroups subsystem

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-3944?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-3944: ------------------------------------ The messaging subsystem was not leveraging the public ChannelFactoryService.getServiceName(...) method for generating the ServiceName of a ChannelFactory. The implementation of this method had changed to accommodate fork channels. > Broken integration between messaging subsystem and jgroups subsystem > -------------------------------------------------------------------- > > Key: WFLY-3944 > URL: https://issues.jboss.org/browse/WFLY-3944 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Brian Stansberry > Assignee: Paul Ferraro > Priority: Critical > > The integration between messaging and jgroups is currently broken. My guess is this was due to recent changes in clustering. > To reproduce it change the bg-group1 element in standalone-full-ha.xml to replace the socket-binding element with the following: > {code} > <jgroups-stack>udp</jgroups-stack> > <jgroups-channel>hq-bg</jgroups-channel> >  > {code} > At boot this appears in the logs: > {code} > 10:00:58,707 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "messaging"), > ("hornetq-server" => "default") > ]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.messaging.default is missing [jboss.jgroups.stack.udp]"]} > 10:00:58,930 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.jgroups.stack.udp (missing) dependents: [service jboss.messaging.default] > {code} > WFLY-3943 is about the lack of testing of this integration, -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-628) DecisionTable incorrectly parsed

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-628?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-628. -------------------------------- Fix Version/s: 6.2.0.CR1 Resolution: Done Fixed by https://github.com/droolsjbpm/drools/commit/c31427e21 > DecisionTable incorrectly parsed > --------------------------------- > > Key: DROOLS-628 > URL: https://issues.jboss.org/browse/DROOLS-628 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.2.0.CR1 > > > 5.2.0.CR1 creates incorrect drl from decision table. With 5.1.0.M1 the drl for the same decision table is correct. > Wrong DRL from 5.2.0.CR1: > rule "ProcessState" > salience 65522 > ruleflow-group "CompleteSubOrder" > activation-group "ProcessState" > when > $m:ModifiedMarker(processState==null, state ==null) > $s:SubOrder > then > $m.setIsModified(true); > $s.setProcessState(ProcessState.CREATED); > end > Correct DRL with 5.1.0.M1: > rule "ProcessState" > salience 65522 > ruleflow-group "CompleteSubOrder" > activation-group "ProcessState" > when > $m:ModifiedMarker() > $s:SubOrder(processState==null, state ==null) > then > $m.setIsModified(true); > $s.setProcessState(ProcessState.CREATED); > end > The difference is that the constraints are put to $m instead of putting them to $s. > The behaviour in 5.2.0.CR1 is the same for all decision tables in my project and prevents me from upgrading to newer drools versions. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-628) DecisionTable incorrectly parsed

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-628: ---------------------------------- Summary: DecisionTable incorrectly parsed Key: DROOLS-628 URL: https://issues.jboss.org/browse/DROOLS-628 Project: Drools Issue Type: Bug Reporter: Mario Fusco Assignee: Mario Fusco 5.2.0.CR1 creates incorrect drl from decision table. With 5.1.0.M1 the drl for the same decision table is correct. Wrong DRL from 5.2.0.CR1: rule "ProcessState" salience 65522 ruleflow-group "CompleteSubOrder" activation-group "ProcessState" when $m:ModifiedMarker(processState==null, state ==null) $s:SubOrder then $m.setIsModified(true); $s.setProcessState(ProcessState.CREATED); end Correct DRL with 5.1.0.M1: rule "ProcessState" salience 65522 ruleflow-group "CompleteSubOrder" activation-group "ProcessState" when $m:ModifiedMarker() $s:SubOrder(processState==null, state ==null) then $m.setIsModified(true); $s.setProcessState(ProcessState.CREATED); end The difference is that the constraints are put to $m instead of putting them to $s. The behaviour in 5.2.0.CR1 is the same for all decision tables in my project and prevents me from upgrading to newer drools versions. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3948) Extract JGroups ChannelFactory and ServiceName factories into separate module

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-3948: ---------------------------------- Summary: Extract JGroups ChannelFactory and ServiceName factories into separate module Key: WFLY-3948 URL: https://issues.jboss.org/browse/WFLY-3948 Project: WildFly Issue Type: Feature Request Components: Clustering Affects Versions: 9.0.0.Alpha1 Reporter: Paul Ferraro Assignee: Paul Ferraro Modules that wish to create JGroups channels currently need to import the entire jgroups subsystem module just to reference a ChannelFactory and generate the appropriate ServiceNames. These should reside in a separate module from the extension. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-116) Correct or remove usage of finalize in LoggerNode

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-116?page=com.atlassian.jira.plugin... ] Jason Greene closed LOGMGR-116. ------------------------------- Fix Version/s: (was: 1.4.4.Final) (was: 1.5.4.Final) Resolution: Won't Fix Ah fair enough. I'll close it as won't fix then. > Correct or remove usage of finalize in LoggerNode > ------------------------------------------------- > > Key: LOGMGR-116 > URL: https://issues.jboss.org/browse/LOGMGR-116 > Project: JBoss Log Manager > Issue Type: Task > Reporter: Jason Greene > Assignee: James Perkins > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-116) Correct or remove usage of finalize in LoggerNode

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-116?page=com.atlassian.jira.plugin... ] David Lloyd commented on LOGMGR-116: ------------------------------------ The API itself makes certain contracts in terms of finalization. Like for example if I get a logger, set a level on it, and then log a message, I am not guaranteed that the logger will retain the level setting for the duration of the log call (though in general, it probably will, because there are locks etc. all over the place) because the API specifies that "It is important to note that the Logger returned by one of the getLogger factory methods may be garbage collected at any time if a strong reference to the Logger is not kept." > Correct or remove usage of finalize in LoggerNode > ------------------------------------------------- > > Key: LOGMGR-116 > URL: https://issues.jboss.org/browse/LOGMGR-116 > Project: JBoss Log Manager > Issue Type: Task > Reporter: Jason Greene > Assignee: James Perkins > Fix For: 1.4.4.Final, 1.5.4.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-116) Correct or remove usage of finalize in LoggerNode

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-116?page=com.atlassian.jira.plugin... ] Jason Greene commented on LOGMGR-116: ------------------------------------- Do you have any sort of guarantee that LoggerNode is held past all desired usage of it (e.g. log calls)? If not then the main issue, aside from the potential finalizer thread stall, is you could lose log messages. > Correct or remove usage of finalize in LoggerNode > ------------------------------------------------- > > Key: LOGMGR-116 > URL: https://issues.jboss.org/browse/LOGMGR-116 > Project: JBoss Log Manager > Issue Type: Task > Reporter: Jason Greene > Assignee: James Perkins > Fix For: 1.4.4.Final, 1.5.4.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 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 October 2014