December 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-570) Do we need acceptReliableMessages flag on the channel?

by Tim Fox (JIRA)

Do we need acceptReliableMessages flag on the channel? ------------------------------------------------------ Key: JBMESSAGING-570 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-570 Project: JBoss Messaging Issue Type: Task Affects Versions: 1.2.0.Alpha1 Reporter: Tim Fox Priority: Minor Fix For: 1.2.0.Beta1 Is there a real use case for ever setting this to false? I can't think of one in a typical messaging application. If not, we should consider removing this flag. -- 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
5
0 / 0

[JBoss JIRA] Created: (JBRULES-593) Rule names must be globally unique, even if they come from different packages

by Jeff Lansing (JIRA)

Rule names must be globally unique, even if they come from different packages ----------------------------------------------------------------------------- Key: JBRULES-593 URL: http://jira.jboss.com/jira/browse/JBRULES-593 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 3.0.5 Environment: NA Reporter: Jeff Lansing Assigned To: Mark Proctor When 2 DRL rule files with different package names (the name following the 'package' keyword) each have a rule with the same name (the name being the quoted string that follows the 'rule' keyword), then the following exception occurs: org.drools.rule.InvalidRulePackage: Rule Compilation error The type Rule_Incident__Vehicle_0 is already defined at org.drools.rule.Package.checkValidity(Unknown Source) at org.drools.common.AbstractRuleBase.addPackage(Unknown Source) at driver.RulesTest.readRule(RulesTest.java:256) This occurs when using a single org.drools.rule.Package object, as in: private void test(Reader source1, Reader source2) throws Exception { PackageBuilder builder = new PackageBuilder(); builder.addPackageFromDrl( source1 ); builder.addPackageFromDrl( source2 ); Package pkg = builder.getPackage(); RuleBase ruleBase = RuleBaseFactory.newRuleBase(); ruleBase.addPackage( pkg ); } If, on the other hand two org.drools.rule.Package objects are used, as in: private void test2(Reader source1, Reader source2) throws Exception { PackageBuilder builder1 = new PackageBuilder(); PackageBuilder builder2 = new PackageBuilder(); builder1.addPackageFromDrl( source1 ); builder2.addPackageFromDrl( source2 ); Package pkg1 = builder1.getPackage(); Package pkg2 = builder2.getPackage(); RuleBase ruleBase = RuleBaseFactory.newRuleBase(); ruleBase.addPackage( pkg1 ); ruleBase.addPackage( pkg2 ); } then one of the identically named rules is simply ignored. In either case, rule names must be globally unique. -- 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

3
3
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-126) ProxyMapCreator does not handle default annotation values

by Adrian Brock (JIRA)

ProxyMapCreator does not handle default annotation values --------------------------------------------------------- Key: JBMICROCONT-126 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-126 Project: JBoss MicroContainer Issue Type: Task Components: General Affects Versions: JBossMC_2_0_0 Beta Reporter: Adrian Brock Assigned To: Kabir Khan There is a fixme in ProxyMapCreator that says "//TODO: Need to handle default values for annotations in jdk 1.5" -- 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
2
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-124) Fixme in test org.jboss.test.classinfo.support.AnnotatedSubClass

by Adrian Brock (JIRA)

Fixme in test org.jboss.test.classinfo.support.AnnotatedSubClass ---------------------------------------------------------------- Key: JBMICROCONT-124 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-124 Project: JBoss MicroContainer Issue Type: Task Components: General Affects Versions: JBossMC_2_0_0 Beta Reporter: Adrian Brock Assigned To: Kabir Khan Priority: Minor There is a FIXME in the above class. Kabir can you update this task to describe the problem. -- 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
3
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-109) Support direct registration of beans without a StandardMBean wrapper

by Brian Stansberry (JIRA)

Support direct registration of beans without a StandardMBean wrapper -------------------------------------------------------------------- Key: JBMICROCONT-109 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-109 Project: JBoss MicroContainer Issue Type: Sub-task Components: General Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossMC_2_0_0 Beta If a bean is already a valid MBean, it should be possible to directly register it in JMX without wrapping it in a StandardMBean. Otherwise beans that implement things like MBeanRegistration, NotificationBroadcaster, NotificationEmitter will not expose that API to the mbean server. To support this, @JMX will add an attribute: boolean registerDirectly() default false; JMXIntroduction will check the attribute; if true the target bean will be registered directly; otherwise a StandardMBean will be created and registered. -- 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
5
0 / 0

[JBoss JIRA] Created: (JBRULES-379) function with another drools function call won't compile (either with eclipse compiler or janino)

by Thierry R (JIRA)

function with another drools function call won't compile (either with eclipse compiler or janino) ------------------------------------------------------------------------------------------------- Key: JBRULES-379 URL: http://jira.jboss.com/jira/browse/JBRULES-379 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 3.0.1 Environment: Debian linux JDK 5 Reporter: Thierry R Assigned To: Mark Proctor function with another drools function call won't compile (either with eclipse compiler or janino) with the error msg : "Function Compilation error " I wrote a DroolsHelper class to work around. -- 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
6
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1091) CMS UI : order : for lists of languages, folders, files names

by Antoine Herzog (JIRA)

CMS UI : order : for lists of languages, folders, files names ------------------------------------------------------------- Key: JBPORTAL-1091 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1091 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Portal CMS Affects Versions: 2.4 Final Environment: JBoss Portal 2.4, WXP, CMS repository in filesystem, Reporter: Antoine Herzog Assigned To: Roy Russo Priority: Minor In the CMS UI, the ordering of the folders and the files names is "Date of creation". Wish : the ordering by names (more convenient to work). even better : feature to choose the ordering on name, dates, description (second priority). In the list of languages, when you use it with another user language than english, the list is in a very messy order : I guess it is the order of the languages names in english, but showed in the "other language". example : "english" is written "anglais" and can be found after "grec" (greek) and before "esperanto". solution : order the list with the i18n label of each items. even better : propose in top of list the few languages that are supported by the portal. propose a one (or a few) strategie(s) of ordering. -- 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
3
0 / 0

[JBoss JIRA] Created: (JBRULES-549) Better support for linebreaks in LHS

by Dirk Bergstrom (JIRA)

Better support for linebreaks in LHS ------------------------------------ Key: JBRULES-549 URL: http://jira.jboss.com/jira/browse/JBRULES-549 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Drl Parser/Builder Reporter: Dirk Bergstrom Assigned To: Mark Proctor I have some rules with very long LHS expressions. I'd like to split them across multiple lines for readability. However, the parser has limited support for breaks. These work: when ObjectTypeName( p0_exit_epoch > (RUM.now()), p0_exit_epoch > (RUM.daysAgo(7)) ) variable : OtherObjectType($rlis : rlis -> (RUM.countFieldsMatching($rlis, "state", "dev-maybe") > 0)) These don't: variable : OtherObjectType($rlis : rlis -> (RUM.countFieldsMatching($rlis, "state", "dev-maybe") > 0)) variable : OtherObjectType(($rlis : rlis -> (RUM.countFieldsMatching($rlis, "state", "dev-maybe") > 0)) variable : OtherObjectType($rlis : rlis -> (RUM.countFieldsMatching($rlis, "state", "dev-maybe") > 0)) While I'm at it, I'd love to have support for multiline expressions in DSL files, but I can imagine that would be a bit harder... -- 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
3
0 / 0

[JBoss JIRA] Created: (JBRULES-589) WokingMemoryLogger and generics: ClassCastException

by Francesco Dandrea (JIRA)

WokingMemoryLogger and generics: ClassCastException --------------------------------------------------- Key: JBRULES-589 URL: http://jira.jboss.com/jira/browse/JBRULES-589 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.0.5 Environment: Java 1.5.0_9 Reporter: Francesco Dandrea Assigned To: Mark Proctor Attachments: BacoJBossRules.zip I'm using Jboss Rules 3.0.5 and Java 1.5.0_09. I'm using generics, but I see that I can't have the character < in a Fact in te drl. This is not a problem, I derived my generic class, and the new derived one is not a Generic class... (public class MyClassCiccio extends Ciccio<MyClass>{}) Now, when I execute the application without log it works. But when I instantiate a WorkingMemoryLogger I have a ClassCastException: Exception in thread "main" java.lang.ClassCastException: it.telecomitalia.netbox.MeasureAlarm at org.drools.base.it.telecomitalia.netbox.TfAlarm$getReferencedElement.getValue(Unknown Source) at org.drools.base.ClassFieldExtractor.getValue(Unknown Source) at org.drools.rule.Declaration.getValue(Unknown Source) at org.drools.audit.WorkingMemoryLogger.extractDeclarations(Unknown Source) at org.drools.audit.WorkingMemoryLogger.activationCreated(Unknown Source) at org.drools.event.AgendaEventSupport.fireActivationCreated(Unknown Source) at org.drools.reteoo.TerminalNode.assertTuple(Unknown Source) at org.drools.reteoo.TerminalNode.assertTuple(Unknown Source) at org.drools.reteoo.TupleSource.propagateAssertTuple(Unknown Source) at org.drools.reteoo.NotNode.assertTuple(Unknown Source) at org.drools.reteoo.LeftInputAdapterNode.createAndAssertTuple(Unknown Source) at org.drools.reteoo.LeftInputAdapterNode.assertObject(Unknown Source) at org.drools.reteoo.ObjectSource.propagateAssertObject(Unknown Source) at org.drools.reteoo.ObjectTypeNode.assertObject(Unknown Source) at org.drools.reteoo.Rete.assertObject(Unknown Source) at org.drools.reteoo.ReteooRuleBase.assertObject(Unknown Source) at org.drools.reteoo.ReteooWorkingMemory.doAssertObject(Unknown Source) at org.drools.common.AbstractWorkingMemory.assertObject(Unknown Source) at org.drools.common.AbstractWorkingMemory.assertObject(Unknown Source) at it.telecomitalia.netbox.Main.main(Main.java:34) I have an example (sent to the mailing list) that gives the exception, but -- 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
3
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-135) Adding support of MC metadata to JBoss5 MBeans

by Ales Justin (JIRA)

Adding support of MC metadata to JBoss5 MBeans ---------------------------------------------- Key: JBMICROCONT-135 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-135 Project: JBoss MicroContainer Issue Type: Task Components: Deployment Reporter: Ales Justin Assigned To: Ales Justin Priority: Minor Fix For: JBossMC_2_0_0_CR1 There is already some support for mixing common mbean xml and MC's xml metadata. We can try to port all the MC's metadata features that don't break backcompatibility on common mbeans metadata. -- 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
4
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 December 2006