January 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1260) TCPDelegatingCacheLoader should be able to handle reconnects in the event of the TCPCacheServer being restarted.

by Manik Surtani (JIRA)

TCPDelegatingCacheLoader should be able to handle reconnects in the event of the TCPCacheServer being restarted. ---------------------------------------------------------------------------------------------------------------- Key: JBCACHE-1260 URL: http://jira.jboss.com/jira/browse/JBCACHE-1260 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Cache loaders Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.1.0.CR3, 2.1.0.GA -- 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

18 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1204) Investogate shutdown hook usage in an MBeanServer environment

by Manik Surtani (JIRA)

Investogate shutdown hook usage in an MBeanServer environment ------------------------------------------------------------- Key: JBCACHE-1204 URL: http://jira.jboss.com/jira/browse/JBCACHE-1204 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.0.0.GA Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.1.0.CR1, 2.1.0.GA -- 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

18 years, 3 months

1
11
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1868) portlet-instances_2_6.dtd has a duplicate element defined

by Thad West (JIRA)

portlet-instances_2_6.dtd has a duplicate element defined --------------------------------------------------------- Key: JBPORTAL-1868 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1868 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.6.3 Final Environment: Portal 2.6.3 Bundled Version Reporter: Thad West The display-name element is defined twice in portlet-instances_2_6.dtd. Elements may only be defined once. Look for: <!ELEMENT display-name (#PCDATA)> -- 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

18 years, 3 months

2
1
0 / 0

[JBoss JIRA] Created: (SECURITY-105) Clear Modules in invokeCommit and invokeAbort of JBossAuthorizationManager

by Anil Saldhana (JIRA)

Clear Modules in invokeCommit and invokeAbort of JBossAuthorizationManager -------------------------------------------------------------------------- Key: SECURITY-105 URL: http://jira.jboss.com/jira/browse/SECURITY-105 Project: JBoss Security and Identity Management Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.1-BETA2 Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: 2.0.2.GA Without the clears, the modules are just piling on. -- 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

18 years, 3 months

1
3
0 / 0

[JBoss JIRA] Created: (SECURITY-106) Clean up ResourceKeys

by Anil Saldhana (JIRA)

Clean up ResourceKeys --------------------- Key: SECURITY-106 URL: http://jira.jboss.com/jira/browse/SECURITY-106 Project: JBoss Security and Identity Management Issue Type: Task Security Level: Public (Everyone can see) Components: Security SPI Affects Versions: 2.0.2-BETA Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: 2.0.2-BETA3 Remove unused ResourceKeys -- 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

18 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (SECURITY-107) Authorization Framework needs to use the Identity stuff

by Anil Saldhana (JIRA)

Authorization Framework needs to use the Identity stuff ------------------------------------------------------- Key: SECURITY-107 URL: http://jira.jboss.com/jira/browse/SECURITY-107 Project: JBoss Security and Identity Management Issue Type: Task Security Level: Public (Everyone can see) Components: Identity, Security SPI Affects Versions: 2.0.2-BETA Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: 2.0.2-BETA3 AuthorizationContext/AuthorizationModule need an update to handle Identity (Role/RoleGroup) -- 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

18 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-5112) WebXMLRewriter leaks input stream

by Heiko Braun (JIRA)

WebXMLRewriter leaks input stream --------------------------------- Key: JBAS-5112 URL: http://jira.jboss.com/jira/browse/JBAS-5112 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web Services Affects Versions: JBossAS-4.2.2.GA Reporter: Heiko Braun Assigned To: Heiko Braun Fix For: JBossAS-4.2.3.GA -- 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

18 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1410) Rules with Collect / Accumulate CEs not working correctly when dinamically added to a rulebase

by Edson Tirelli (JIRA)

Rules with Collect / Accumulate CEs not working correctly when dinamically added to a rulebase ---------------------------------------------------------------------------------------------- Key: JBRULES-1410 URL: http://jira.jboss.com/jira/browse/JBRULES-1410 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: Reteoo Affects Versions: 4.0.3 Reporter: Edson Tirelli Assigned To: Edson Tirelli Fix For: 4.0.4, 4.1.0 Reported by Dirk: -------------------------- I have modified my application to allow adding/removing/updating rules during runtime. However, when I add a new rule to the rulebase, I don't get the behavior I expect. First, as soon as I call RuleBase.addPackage(), the new rules fire (the RHS code runs). Shouldn't that happen only when I call fireAllRules()? Second, newly added collect() rules don't collect already asserted objects. New non-collect rules can see the objects just fine. Attached is a testcase, and below is the output it produces. Am I doing something wrong, or is this a bug? I'm running Drools 4.0.3 on JDK 1.5.0.13. Start RuleBase created Adding rules about 'tom': package rules; import java.util.ArrayList; import test.Tester.Record; import test.Tester; rule "Collect tom" when $list : ArrayList(size > 0) from collect( Record(field1 == "tom") ) then Tester.show($list, "Collect tom"); end rule "Non collect tom" when $rec : Record( field1 == "tom" ) then System.out.println("Find 'tom' " + $rec.dump()); end inserting record 1:"tom", inserting record 2:"fred", inserting record 3:"harry", inserting record 4:"fred", inserting record 5:"ed", inserting record 6:"tom", inserting record 7:"sreeni", inserting record 8:"jill", inserting record 9:"ralph", inserting record 10:"tom", fireAllRules() Find 'tom' 10:"tom", 'Collect tom' collected 3 records => 1:"tom", 6:"tom", 10:"tom", Find 'tom' 6:"tom", Find 'tom' 1:"tom", adding rules about 'fred': package morerules; import java.util.ArrayList; import test.Tester.Record; import test.Tester; rule "Collect fred" when $list : ArrayList(size > 0) from collect( Record(field1 == "fred") ) then Tester.show($list, "Collect fred"); end rule "Non collect fred" when $rec : Record( field1 == "fred" ) then System.out.println("Find 'fred' " + $rec.dump()); end ==> Why do the new rules fire when added? Find 'fred' 4:"fred", Find 'fred' 2:"fred", 'Collect fred' collected 0 records => ==> Why doesn't the collect rule collect? The non-collect rule works. fireAllRules() Changing record 3 to 'fred' fireAllRules() Find 'fred' 3:"fred", 'Collect fred' collected 1 records => 3:"fred", ==> Why does the collect rule not see the other two 'fred' records? -- 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

18 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1397) org.mvel.CompileException: variable already defined within scope

by Edson Tirelli (JIRA)

org.mvel.CompileException: variable already defined within scope ---------------------------------------------------------------- Key: JBRULES-1397 URL: http://jira.jboss.com/jira/browse/JBRULES-1397 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.3 Reporter: Edson Tirelli Assigned To: Edson Tirelli Fix For: 4.0.4, 4.1.0 Reported by Alexander Bagerman. The following rule and code snippet raises the problem: rule "rule" dialect "mvel" when $p : Person( $likes : likes ) then Cheese c = new Cheese( $likes ); System.out.println( $p + " -> " + c ); insert( c ); end // snippet Person bob = new Person( "Bob", "stilton" ); Person mark = new Person( "Mark", "brie" ); workingMemory.insert( bob ); workingMemory.insert( mark ); workingMemory.fireAllRules(); The exception is: Caused by: org.mvel.CompileException: variable already defined within scope: class com.sample.Cheese c at org.drools.base.mvel.DroolsMVELFactory.createVariable(DroolsMVELFactory.java:218) at org.mvel.ast.TypedVarNode.getReducedValueAccelerated(TypedVarNode.java:43) at org.mvel.MVELRuntime.execute(MVELRuntime.java:88) at org.mvel.CompiledExpression.getValue(CompiledExpression.java:108) at org.mvel.MVEL.executeExpression(MVEL.java:235) at org.drools.base.mvel.MVELConsequence.evaluate(MVELConsequence.java:47) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:550) -- 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

18 years, 3 months

1
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1226) State transfer doesn't clean out persistent store if size of transferred persistent state is 0

by Brian Stansberry (JIRA)

State transfer doesn't clean out persistent store if size of transferred persistent state is 0 ---------------------------------------------------------------------------------------------- Key: JBCACHE-1226 URL: http://jira.jboss.com/jira/browse/JBCACHE-1226 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 1.4.1.SP7 Reporter: Brian Stansberry Assigned To: Manik Surtani Priority: Minor StateTransferIntegrator_140.integratePersistentState() is a no-op if the size of the provided persistent state is 0. So, if persistent state transfer is enabled but the provider doesn't have any persistent state to transfer, any stale persistent state laying around on the recipient will not get cleaned up. A fix for this needs to properly discriminate between the above case and one where no persistent state is available because persistent state transfer is disabled. Manik, I found this when a solution to an EJB3 bug didn't work as expected. I can tweak my solution to get around it, so this isn't urgent for me. Feel free to assign to me, although I likely won't get to it for a long time. This likely affects all releases in the 1.x series. A *quick* look at how this works leads me to expect it's not an issue in 2.x. -- 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

18 years, 3 months

2
5
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 2008