October 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3832) Upgrade JBMETA to 8.0.1.Final

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3832?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3832: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1139626|https://bugzilla.redhat.com/show_bug.cgi?id=1139626] from MODIFIED to ON_QA > Upgrade JBMETA to 8.0.1.Final > ----------------------------- > > Key: WFLY-3832 > URL: https://issues.jboss.org/browse/WFLY-3832 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Bartosz Baranowski > Assignee: Jason Greene > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-628?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated DROOLS-628: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1150308 > 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)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3889) JMX monitoring is extremely memory inefficient

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3889?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-3889: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1150304 > JMX monitoring is extremely memory inefficient > ---------------------------------------------- > > Key: WFLY-3889 > URL: https://issues.jboss.org/browse/WFLY-3889 > Project: WildFly > Issue Type: Bug > Components: Domain Management, JMX > Affects Versions: JBoss AS7 7.1.1.Final, 9.0.0.Alpha1 > Reporter: Koen Janssens > Assignee: Brian Stansberry > > When reading any JMX attribute(s), I have noticed a noticeable impact on the performance of our system. After attaching a profiler, I see that getting a single attribute of a JMX bean (either using remoting or using jconsole) is generating thousands of objects, that have to cleaned up by the GC. For instance, 6000 instances of the ModelNode class are created. > A clone is made of the complete management model before executing any JMX operation. This happens in the OperationContextImpl.readResourceFromRoot class. > More background on associated forum thread -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3894) Can't login JAAS secured management interfaces with --admin-only

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3894?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3894: ----------------------------------------------- mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1146240|https://bugzilla.redhat.com/show_bug.cgi?id=1146240] from NEW to CLOSED > Can't login JAAS secured management interfaces with --admin-only > ---------------------------------------------------------------- > > Key: WFLY-3894 > URL: https://issues.jboss.org/browse/WFLY-3894 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Affects Versions: 9.0.0.Alpha1 > Reporter: Chris Dolphy > Assignee: Darran Lofthouse > Attachments: standalone.xml > > > After configuring JAAS security for management realm, when I start JBoss with `bin/standalone.sh --admin-only', I can't login to the management web console. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

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

10 years

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)

10 years

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)

10 years

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)

10 years

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)

10 years

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)

10 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2014