January 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-926) PojoCache local concurrent test produced lock timeout exception

by Ben Wang (JIRA)

PojoCache local concurrent test produced lock timeout exception --------------------------------------------------------------- Key: JBCACHE-926 URL: http://jira.jboss.com/jira/browse/JBCACHE-926 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Fix For: 2.0.0.BETA1 This is reproducible in LocalConcurrentTest that has multiple threads doing POJO attach simultaneously. End result is it can produce lock timeout exception during loop. -- 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, 4 months

2
1
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-144) JAXPDeployer needs to support a dom attachment to allow management overrides.

by Scott M Stark (JIRA)

JAXPDeployer needs to support a dom attachment to allow management overrides. ----------------------------------------------------------------------------- Key: JBMICROCONT-144 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-144 Project: JBoss MicroContainer Issue Type: Feature Request Components: Deployment Affects Versions: JBossMC_2_0_0 Beta Reporter: Scott M Stark Fix For: JBossMC_2_0_0_CR1 The JAXPDeployer should support a notion of a dom document attachment view that can be overriden to introduce an edited view of the xml document. This allows management tools to update the document without having to overwrite the original xml document. -- 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, 4 months

2
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-593) Analyse current JGroups stack usage

by Tim Fox (JIRA)

Analyse current JGroups stack usage ----------------------------------- Key: JBMESSAGING-593 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-593 Project: JBoss Messaging Issue Type: Task Affects Versions: 1.0.1.CR5 Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.0.Beta1 Need to tune our JGroups stack config to get the best performance possible. Also we need to consider whether we really need to two stacks and if we do, then which protocols we can safely omit from one. We need Brian and/or Bela's help with this one. -- 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, 4 months

4
5
0 / 0

[JBoss JIRA] Created: (JBAS-4037) Add support for ear lib directory

by Scott M Stark (JIRA)

Add support for ear lib directory --------------------------------- Key: JBAS-4037 URL: http://jira.jboss.com/jira/browse/JBAS-4037 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.0.5.GA Reporter: Scott M Stark Fix For: JBossAS-4.2.0.CR1 Add support for a library-directory to jboss-app.xml similar to the java ee 5 notion: A .ear file may contain a directory that contains libraries packaged in JAR files. The library-directory element of the .ear file's deployment descriptor contains the name of this directory. If a library-directory element isn't specified, or if the .ear file does not contain a deployment descriptor, the directory named lib is used. An empty library-directory element may be used to specify that there is no library directory. All files in this directory (but not subdirectories) with a .jar extension must be made available to all components packaged in the EAR file, including application clients. These libraries may reference other libraries, either bundled with the application or installed separately, using any of the techniques described herein. -- 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, 4 months

3
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-556) Isolate JBossMQ-specific test

by Ovidiu Feodorov (JIRA)

Isolate JBossMQ-specific test ----------------------------- Key: JBMESSAGING-556 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-556 Project: JBoss Messaging Issue Type: Sub-task Components: Tests and Performance Reporter: Ovidiu Feodorov Assigned To: Richard Achmatowicz Isolate JbossMQ specific tests so they'll be run as the JBossMQ functional testsuite, and NOT as integration tests. -- 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, 4 months

3
7
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-555) Separate generic JMS tests

by Ovidiu Feodorov (JIRA)

Separate generic JMS tests -------------------------- Key: JBMESSAGING-555 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-555 Project: JBoss Messaging Issue Type: Sub-task Components: Tests and Performance Reporter: Ovidiu Feodorov Assigned To: Richard Achmatowicz Fix For: 1.2.0.Beta1 Separate the generic JMS tests by creating a copy of all JBossMQ tests and eliminating the JBossMQ-specific ones. The remaining tests will be refactored so they can be run with both Messaging and JBossMQ, -- 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, 4 months

3
14
0 / 0

[JBoss JIRA] Created: (JBRULES-583) Refactor RuleItem to AssetItem

by Mark Proctor (JIRA)

Refactor RuleItem to AssetItem ------------------------------ Key: JBRULES-583 URL: http://jira.jboss.com/jira/browse/JBRULES-583 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-brms Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 3.1-m1 We should have a generic asset item for all asset types. -- 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, 4 months

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-563) ResourceHandler API for t he repository

by Mark Proctor (JIRA)

ResourceHandler API for t he repository --------------------------------------- Key: JBRULES-563 URL: http://jira.jboss.com/jira/browse/JBRULES-563 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-brms Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 3.1-m1 The repository should be able to use any content, which should be abstracted away behind a ResourceHandler api. -- 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, 4 months

2
1
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, 4 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, 4 months

4
6
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 January 2007