February 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-4118) A truly trivial issue; a typo...

by Brian Stansberry (JIRA)

A truly trivial issue; a typo... -------------------------------- Key: JBAS-4118 URL: http://jira.jboss.com/jira/browse/JBAS-4118 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering, Web (Tomcat) service Affects Versions: JBossAS-4.0.5.GA Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Trivial Fix For: JBossAS-4.2.0.CR1 Reported by Bob Brown on JBCACHE-980: 08:46:16,594 INFO [JBossCacheManager] init(): replicationGranularity_ is 0 and invaldateSessionPolicy is 2 'invaldateSessionPolicy ' ? Somehow, my eye is drawn to this on each startup... -- 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

19 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-980) A truly trivial issue; a typo...

by Bob Brown (JIRA)

A truly trivial issue; a typo... -------------------------------- Key: JBCACHE-980 URL: http://jira.jboss.com/jira/browse/JBCACHE-980 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Environment: JBoss 4.0.5GA/XPSP2/ Reporter: Bob Brown Assigned To: Manik Surtani Priority: Trivial Eg. 08:46:16,594 INFO [JBossCacheManager] init(): replicationGranularity_ is 0 and invaldateSessionPolicy is 2 'invaldateSessionPolicy ' ? Somehow, my eye is drawn to this on each startup... -- 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

19 years, 2 months

2
1
0 / 0

[JBoss JIRA] Created: (JBAOP-357) ClassNotFoundExceptions when running with JRockit

by Kabir Khan (JIRA)

ClassNotFoundExceptions when running with JRockit ------------------------------------------------- Key: JBAOP-357 URL: http://jira.jboss.com/jira/browse/JBAOP-357 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.alpha2, 1.5.3.GA Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: 1.5.4.GA, 2.0.0.alpha3 We need to preload classes so that JRockit does not need to initiate load the classes as part of the weaving -- 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

19 years, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-614) logically asserted facts do not get retracted properly

by Philipp Rechberger (JIRA)

logically asserted facts do not get retracted properly ------------------------------------------------------ Key: JBRULES-614 URL: http://jira.jboss.com/jira/browse/JBRULES-614 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.0.5 Reporter: Philipp Rechberger Assigned To: Mark Proctor 1) Setup the following rules: rule "#1: value out of range (verification)" when val : Value( value > 100 ) then System.out.println("found invalid value: " + val.getValue()); assertLogical(new Message("value out of range")); end rule "#2: value out of range (print out)" when Message( message == "value out of range" ) then System.out.println("value out of range"); end 2) Assert a Value fact that triggers rule #1 (note that the Value Bean provides Property Change Support for its "value" attribute): // assert fact - invalid value Value value = new Value(101); FactHandle handle = workingMemory.assertObject(value); workingMemory.fireAllRules(); => Output looks like this: found invalid value: 101 value out of range --- working memory dump --- class com.sample.Value: value = 101 class com.sample.Message: value out of range 3) Now modify the Value fact: // modify fact - invalid value value.setValue(102); workingMemory.modifyObject(handle, value); workingMemory.fireAllRules(); => Output looks like this: found invalid value: 102 value out of range --- working memory dump --- class com.sample.Value: value = 102 class com.sample.Message: value out of range class com.sample.Message: value out of range => A bit strange here: we have two Message objects - but this could be ok if both objects get retracted after modifying Value fact's value, so that it does not support the truth for rule #1... let's test 4) Modify the value fact again: // modify fact - valid value value.setValue(100); workingMemory.modifyObject(handle, value); workingMemory.fireAllRules(); => Output looks like this: <none> --- working memory dump --- class com.sample.Value: value = 100 class com.sample.Message: value out of range Conclusion: There is still a Message fact in the working memory that was asserted logically (by rule) due to the fact Value ( value > 100 ), which does not exist any more! The (second) Message fact must be retracted too OR logically asserted facts must be asserted only once (even if the according rule is triggered multiple times). Otherwise the statement in the documentation is incorrect (chapter 3.5.2): "assertLogical(new Something());" is similar to assert, but the object will be automatically retracted when there are no more facts to support the truth of the currently firing rule". -- 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

19 years, 2 months

4
5
0 / 0

[JBoss JIRA] Created: (JBESB-364) jBPM integration

by Mark Little (JIRA)

jBPM integration ---------------- Key: JBESB-364 URL: http://jira.jboss.com/jira/browse/JBESB-364 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: BPM Affects Versions: 4.0 CR2 Reporter: Mark Little Assigned To: Mark Little Fix For: 4.0 Adding a jBPM Action that knows how to invoke a service, an ESB action that knows how to start a new process instance or via the tokenid in the message header, signal a process instance. -- 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

19 years, 2 months

4
6
0 / 0

[JBoss JIRA] Created: (JBESB-352) Improve coverage on the org.jboss.soa.esb.listeners.config package (listeners)

by Tom Fennelly (JIRA)

Improve coverage on the org.jboss.soa.esb.listeners.config package (listeners) ------------------------------------------------------------------------------ Key: JBESB-352 URL: http://jira.jboss.com/jira/browse/JBESB-352 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 4.0 CR1 Reporter: Tom Fennelly Assigned To: Mark Little Fix For: 4.0 Coverage here is at 214.314 lines (62%) Of particular interest should be XmlValidatorImpl and ConfigurationController. My guess is that XmlValidatorImpl can be simplified considerably - it seems to be providing a number of execution options that we might not need. -- 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

19 years, 2 months

3
6
0 / 0

[JBoss JIRA] Created: (JBRULES-607) Working memory is not disposed when releasing the RuleSession

by Einat Idan (JIRA)

Working memory is not disposed when releasing the RuleSession ------------------------------------------------------------- Key: JBRULES-607 URL: http://jira.jboss.com/jira/browse/JBRULES-607 Project: JBoss Rules Issue Type: Patch Security Level: Public (Everyone can see) Components: JSR94 Affects Versions: 3.0.1 Reporter: Einat Idan Assigned To: Mark Proctor Under heavy load conditions I encountered high cpu and hangs of the system. A thread dump shows all threads being stuck in java.util.WeakHashMap, which is called from AbstractRuleBase.addWorkingMemory (please refer to linked thread). After digging into the code it turned out that the client session object (AbstractRuleSessionImpl) has a release method. This method is supposed to releases all resources used by this rule session. And so it sets the properties, the working memory and the RuleExecutionSet to null: public void release() { this.setProperties( null ); this.setWorkingMemory( null ); this.setRuleExecutionSet( null ); } However, it does NOT dispose the working memory as expected. I added the following line to method: getWorkingMemory().dispose(); Afterwards things improved significantly. -- 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

19 years, 2 months

4
8
0 / 0

[JBoss JIRA] Created: (JBRULES-667) Combination of Or condition and simple fact fails to evaluate

by Frederic Burlet (JIRA)

Combination of Or condition and simple fact fails to evaluate ------------------------------------------------------------- Key: JBRULES-667 URL: http://jira.jboss.com/jira/browse/JBRULES-667 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.1-m1 Environment: Debian Linux Unstable Java 1.4 Reporter: Frederic Burlet Assigned To: Mark Proctor Attachments: conditions-test.tar.gz When we have a lhs containing a combination of or condition and simple fact like: .... when MyBean(property == value_1) or MyBean(property == value_2) OtherBean( ) then.... The engine throwing a NPE when adding rules. It also fails with the same error when conditions are written in a different order. See attached test case in order to reproduce. This has been tested against the trunk revision #9453. -- 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

19 years, 2 months

2
6
0 / 0

[JBoss JIRA] Created: (JBESB-436) More EIP

by Mark Little (JIRA)

More EIP -------- Key: JBESB-436 URL: http://jira.jboss.com/jira/browse/JBESB-436 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Examples, Rosetta Reporter: Mark Little Assigned To: Mark Little Fix For: 4.2 -- 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

19 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBESB-435) Seam integration

by Mark Little (JIRA)

Seam integration ---------------- Key: JBESB-435 URL: http://jira.jboss.com/jira/browse/JBESB-435 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Rosetta Reporter: Mark Little Assigned To: Mark Little Fix For: 4.2 -- 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

19 years, 2 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 February 2007