February 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-8680) More robust handling of previous versions of the configuration files

by Brian Stansberry (JIRA)

More robust handling of previous versions of the configuration files -------------------------------------------------------------------- Key: JBAS-8680 URL: https://jira.jboss.org/browse/JBAS-8680 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Domain Management Reporter: Brian Stansberry Fix For: 7.0.0.Beta1 Currently when an update is made to the configuration, we copy the config file to ".lastknowngood" and write a new version. We need something more sophisticated than that. 1) The original version of present on server start should be saved as .original. 2) We should keep a proper versioned history (standalone.xml.v1, standalone.xml.v2 etc) 3) Keep a standalone.xml.last which is the same as the current standalone.xml. This can be used to detect (via file timestamps) changes to standalone.xml made while the server is offline -- such change results in a new .original. 4) We need to create proper semantics for the ".lastknowngood" notion, or scrap it. Right now it's just the previous version of the file, which may or may not have been "good". -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

3
7
0 / 0

[JBoss JIRA] Created: (JBRULES-2333) Support <scoreDsl> besides <scoreDrl> for XmlSolverConfigurer in LocalSearchSolverConfig to allow to use DSL's instead of DRL's for score rules

by Geoffrey De Smet (JIRA)

Support <scoreDsl> besides <scoreDrl> for XmlSolverConfigurer in LocalSearchSolverConfig to allow to use DSL's instead of DRL's for score rules ----------------------------------------------------------------------------------------------------------------------------------------------- Key: JBRULES-2333 URL: https://jira.jboss.org/jira/browse/JBRULES-2333 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-solver Affects Versions: 5.1.0.M1 Reporter: Geoffrey De Smet Assignee: Geoffrey De Smet Fix For: 5.1.0.M2 shouldn't be to hard, simply adjust LocalSearchSolverConfig class as needed -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

5
12
0 / 0

[JBoss JIRA] Created: (JBRULES-2887) AccumulateNode runs into NPE

by Wolfgang Laun (JIRA)

AccumulateNode runs into NPE ---------------------------- Key: JBRULES-2887 URL: https://issues.jboss.org/browse/JBRULES-2887 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.1.1.FINAL Reporter: Wolfgang Laun Assignee: Mark Proctor Fix For: 5.2.0.M1 A rule such as rule "average" when B( id < 10 ) $list: List() from collect ( A() over window:time(10s) ) Number( $avg: doubleValue ) from accumulate( A( $id : id ) from $list, average( $id ) ) then System.out.println( "average = " + $avg ); end runs into a NPE Caused by: java.lang.NullPointerException at org.drools.reteoo.AccumulateNode.getFirstMatch(AccumulateNode.java:967) at org.drools.reteoo.AccumulateNode.splitList(AccumulateNode.java:920) at org.drools.reteoo.AccumulateNode.removePreviousMatchesForLeftTuple(AccumulateNode.java:874) at org.drools.reteoo.AccumulateNode.retractLeftTuple(AccumulateNode.java:205) at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateRetractLeftTuple(CompositeLeftTupleSinkAdapter.java:238) at org.drools.reteoo.CompositeLeftTupleSinkAdapter.propagateRetractLeftTupleDestroyRightTuple(CompositeLeftTupleSinkAdapter.java:138) at org.drools.reteoo.AccumulateNode.retractLeftTuple(AccumulateNode.java:212) at org.drools.reteoo.ModifyPreviousTuples.retractTuples(ModifyPreviousTuples.java:111) at org.drools.reteoo.EntryPointNode.modifyObject(EntryPointNode.java:176) at org.drools.common.NamedEntryPoint.update(NamedEntryPoint.java:450) at org.drools.common.NamedEntryPoint.update(NamedEntryPoint.java:361) at org.drools.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:183) at org.drools.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:196) at event.Rule_launch_0.defaultConsequence(Rule_launch_0.java:7) at event.Rule_launch_0DefaultConsequenceInvoker.evaluate(Rule_launch_0DefaultConsequenceInvoker.java:33) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:913) A null Parameter accctx is passed down from retractLeftTuple. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

4
12
0 / 0

[JBoss JIRA] Created: (JBAS-4413) Incorrect behaviour in TCLFilter

by Poyan (JIRA)

Incorrect behaviour in TCLFilter -------------------------------- Key: JBAS-4413 URL: http://jira.jboss.com/jira/browse/JBAS-4413 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Logging Affects Versions: JBossAS-4.0.5.GA Reporter: Poyan Assigned To: Scott M Stark Just one TCLFilter can be added to an appender, decide method return either ACCEPT or DENY. Should return NEUTRAL is some case. public int decide(LoggingEvent event) { int ok = Filter.DENY; if( acceptOnMatch == true ) { ok = Filter.DENY; if( isMatchingTCL() ){ ok = Filter.ACCEPT; } } else { ok = Filter.ACCEPT; // CHANGING THIS ROW TO ok = Filter.NEUTRAL; should do that you check the other filters to. if( isMatchingTCL() ) ok = Filter.DENY; } return ok; } Log4j.xml: <appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender"> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%d %-5p [%t] %c - %m%n"/> </layout> <filter class="org.jboss.logging.filter.TCLFilter"> <param name="AcceptOnMatch" value="false"/> <param name="DeployURL" value="jboss-common-client.jarpoyan"/> </filter> <filter class="org.jboss.logging.filter.TCLFilter"> <param name="AcceptOnMatch" value="false"/> <param name="DeployURL" value="dnsns.jarpoyan"/> </filter> </appender> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

2
1
0 / 0

[JBoss JIRA] Created: (JGRP-900) Address: remove isMulticastAddress()

by Bela Ban (JIRA)

Address: remove isMulticastAddress() ------------------------------------ Key: JGRP-900 URL: https://jira.jboss.org/jira/browse/JGRP-900 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.8 With logical addresses, we don't need this anymore: Address dest=msg.getDest(); boolean mcast=dest == null || dest.isMulticastAddress(); should be changed to boolean mcast=msg.isMulticastMessage(); // or isGroupMessage() ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

1
3
0 / 0

[JBoss JIRA] Created: (JGRP-899) Message: remove dest_addr

by Bela Ban (JIRA)

Message: remove dest_addr ------------------------- Key: JGRP-899 URL: https://jira.jboss.org/jira/browse/JGRP-899 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.0 We don't need this field, this will save us some memory. Note that today dest_addr is *not* shipped with a message, but nevertheless filled in on the receiving side. We have tests which use dest_addr to determine whether the message is a unicast or multicast message. This should go away, too, and be replaced by a flag in the message itself, ie. MULTICAST. Maybe add a method Message.isMulticast(). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

1
3
0 / 0

[JBoss JIRA] Created: (JBEE-23) Add jboss-validation-api_1.0_spec

by Shelly McGowan (JIRA)

Add jboss-validation-api_1.0_spec --------------------------------- Key: JBEE-23 URL: https://jira.jboss.org/jira/browse/JBEE-23 Project: JBoss JavaEE APIs Issue Type: Sub-task Reporter: Shelly McGowan -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

2
8
0 / 0

[JBoss JIRA] Created: (JBEE-25) Add cdi-api_1.0_spec

by Shelly McGowan (JIRA)

Add cdi-api_1.0_spec -------------------- Key: JBEE-25 URL: https://jira.jboss.org/jira/browse/JBEE-25 Project: JBoss JavaEE APIs Issue Type: Sub-task Reporter: Shelly McGowan -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

2
6
0 / 0

[JBoss JIRA] Created: (JGRP-1057) GroupRequest: turn mode (GET_ALL, GET_FIRST etc) into an enum

by Bela Ban (JIRA)

GroupRequest: turn mode (GET_ALL, GET_FIRST etc) into an enum ------------------------------------------------------------- Key: JGRP-1057 URL: https://jira.jboss.org/jira/browse/JGRP-1057 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.0 enum Mode {GET_FIRST, GET_ALL, GET_N, GET_MJORITY, GET_NONE} // etc Potentially move mode out of GroupRequest (to Global ?) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-904) UUID: remove additional_data

by Bela Ban (JIRA)

UUID: remove additional_data ---------------------------- Key: JGRP-904 URL: https://jira.jboss.org/jira/browse/JGRP-904 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 3.0 Use the logical name instead -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

1
3
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 February 2011