June 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-1829) Nested From Tag Not Supported in Drools

by Nagarajan Shanmugam (JIRA)

Nested From Tag Not Supported in Drools --------------------------------------- Key: JBRULES-1829 URL: https://jira.jboss.org/jira/browse/JBRULES-1829 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.0.0.M2 Environment: Windows XP, Eclipse 3.3. Reporter: Nagarajan Shanmugam Assignee: Mark Proctor HI i have Created one rule file that have two From tag. Using XmlDumper I create Xml rule file. When i try to parse that Xml rule file its throwing Error. And also the parsed Xml files also Wrong. Exception in thread "main" org.drools.compiler.DroolsParserException: org.xml.sax.SAXParseException: <from> may not be nested at com.drools.service.ConvertDrlToXml.main(ConvertDrlToXml.java:47) -- 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

11 years, 8 months

4
13
0 / 0

[JBoss JIRA] Created: (JBRULES-2938) Naming a Java Class the Same as a Package Causes Compile Errors

by Matt Fowler (JIRA)

Naming a Java Class the Same as a Package Causes Compile Errors --------------------------------------------------------------- Key: JBRULES-2938 URL: https://issues.jboss.org/browse/JBRULES-2938 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.1.0.FINAL Reporter: Matt Fowler Assignee: Mark Proctor Creating a class with the same name as a package which is imported in a drools rule file causes compilation errors. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-1009) Can't execute rules twice with a second classloader

by aaron dixon (JIRA)

Can't execute rules twice with a second classloader --------------------------------------------------- Key: JBRULES-1009 URL: http://jira.jboss.com/jira/browse/JBRULES-1009 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Reteoo Affects Versions: 4.0.0.MR3 Reporter: aaron dixon Assigned To: Mark Proctor Priority: Minor Attachments: drools-test.zip I am trying to sequentially perform two rules executions using two different classloaders in the same VM. I create completely new state for each execution, yet I still fail on the second execution (the first execution succeeds). I believe this has to do with some internal static cached state that JBossRules is maintaining. An integration test is attached as an archived Eclipse project (zip). Exception thrown: Exception in thread "main" java.lang.ClassCastException: test.drools.classloader.FooShadowProxy at org.drools.base.test.drools.classloader.Foo$getName.getValue(Unknown Source) at org.drools.base.ClassFieldExtractor.getValue(ClassFieldExtractor.java:94) at org.drools.base.evaluators.StringFactory$StringEqualEvaluator.evaluate(StringFactory.java:85) at org.drools.rule.LiteralRestriction.isAllowed(LiteralRestriction.java:61) at org.drools.rule.LiteralConstraint.isAllowed(LiteralConstraint.java:82) at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:121) at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20) at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:159) at org.drools.reteoo.Rete.assertObject(Rete.java:175) at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190) at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:772) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:584) at org.drools.reteoo.ReteooStatelessSession.execute(ReteooStatelessSession.java:63) at test.drools.classloader.Driver.testRules(Driver.java:49) at test.drools.classloader.Driver.go(Driver.java:35) at test.drools.classloader.Driver.main(Driver.java:19) -- 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

11 years, 8 months

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-1924) It is possible to inherit a rule that doesn't exist

by Toni Rikkola (JIRA)

It is possible to inherit a rule that doesn't exist --------------------------------------------------- Key: JBRULES-1924 URL: https://jira.jboss.org/jira/browse/JBRULES-1924 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.0.0.M4 Reporter: Toni Rikkola Assignee: Mark Proctor Fix For: FUTURE Inheriting a rule that doesn't exist, doesn't give any errors. rule A extends you_can_not_find_me when ... then end -- 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

11 years, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-2031) Enhancements to spreadsheet based testing tool

by Michael Neale (JIRA)

Enhancements to spreadsheet based testing tool ---------------------------------------------- Key: JBRULES-2031 URL: https://jira.jboss.org/jira/browse/JBRULES-2031 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-testing Reporter: Michael Neale Assignee: Michael Neale Fix For: FUTURE As mentioned by Ansgar in blog comments: http://blog.athico.com/2009/03/new-testing-tool.html Hi, we're using Drools to perform mortgage scoring. For testing, we developed a somewhat similar, but already more sophisticated testing framework. Currently, our test set comprises of roughly 800 test scenarios/test cases. Similarities: * also uses spreadsheet tables to define test cases. * each column resembles a test case * leftmost column used to name elements of input facts or define expected conditions (see below) Differences: * concept of "expected values" not expressed as mere values, but as drools conditions which are expected to hold after rules all under test finished execution. These conditions are automagically converted into a drools query which is run against the working memory after rule execution. Enhancements: * conditions support simple text replacement, like a macro preprocessor. Wildcards in drools condition can be replaced by test case-specific text * allows skipping of certain condition checks on a per-test-case basis * event logging of the drools working memory embedded into fit output file for failed checks. visibility of log can be toggled using html-embedded javascript. allows for simple copy/paste into "audit view" window in eclipse. This eases debugging rules a lot! * possibility to define a subset of rules contained in a *.drl file to be tested Open issues: * Syntax of initial facts specification is probably a bit cumbersome. We're using a self-brewed language to do this. Already thought of replacing this by MVEL, but not done yet. For us, the current solution works ok. * Up to now, requires explicit import of all used Java classes. This is rather a limitation of drools - we did not manage to get package imports in *.drl files to work. Could probably be solved. -- 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

11 years, 8 months

3
3
0 / 0

[JBoss JIRA] Created: (AS7-1038) Add http to https redirect capability to http-interface

by Darran Lofthouse (JIRA)

Add http to https redirect capability to http-interface ------------------------------------------------------- Key: AS7-1038 URL: https://issues.jboss.org/browse/AS7-1038 Project: Application Server 7 Issue Type: Task Components: Domain Management Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 7.0.0.CR1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

4
9
0 / 0

[JBoss JIRA] Created: (JBAS-9245) Passivation of a @Stateful session bean with an @Inject'ed @Stateless session bean fails with not-serializable error.

by Felix Ullrich (JIRA)

Passivation of a @Stateful session bean with an @Inject'ed @Stateless session bean fails with not-serializable error. --------------------------------------------------------------------------------------------------------------------- Key: JBAS-9245 URL: https://issues.jboss.org/browse/JBAS-9245 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB Affects Versions: 6.0.0.Final Reporter: Felix Ullrich Assignee: Carlo de Wolf I've the same problem described in this issue https://issues.jboss.org/browse/JBAS-8384 Could you please resolve it (maybe in 6.1.0) and dont just close it. Thank you -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

2
7
0 / 0

[JBoss JIRA] Created: (JBAS-9391) EJB3.1 spec 4.8.4: destroying singleton because of error during initialization is not honored

by Pierre Kobylanski (JIRA)

EJB3.1 spec 4.8.4: destroying singleton because of error during initialization is not honored --------------------------------------------------------------------------------------------- Key: JBAS-9391 URL: https://issues.jboss.org/browse/JBAS-9391 Project: Legacy JBoss Application Server 6 Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB Affects Versions: 6.0.0.Final Environment: $ uname -a Linux tumlatum 2.6.38-2-686-bigmem #1 SMP Sun May 8 15:43:39 UTC 2011 i686 GNU/Linux Reporter: Pierre Kobylanski Assignee: Carlo de Wolf ejb 3.1 spec [4.8.4 Singleton Error Handling] says that "Errors occurring during Singleton initialization are considered fatal and must result in the discarding of the Singleton instance." I tried to raise a system exception in the @PostConstruct method of a singleton bean. Logs show the deployment error. But I then can access and call the singleton methods. -- Full paragraph 4.8.4: ----------------------------- Errors occurring during Singleton initialization are considered fatal and must result in the discarding of the Singleton instance. Possible initialization errors include injection failure, a system exception thrown from a PostConstruct method, or the failure of a PostConstruct method container-managed transaction to successfully commit. If a singleton fails to initialize, attempted invocations on the Singleton result in an exception as defined by Section 3.4.3 and Section 3.4.4. ------------------------------------------------------ I tested to raise a system exception (throw new RuntimeException()) in the @PostConstruct method. -- Logs show the error ------------------------------- ERROR [AbstractKernelController] Error installing to Start: name=startup-singleton-initiator:topLevelUnit=ts.ear,unit=testSingletonEjb.jar,bean=counter aliases=[startup-singleton-initiator:bean=counter,topLevelUnit=ts.ear,unit=testSingletonEjb.jar] state=Create: java.lang.RuntimeException: Could not invoke PostConstruct on the newly created bean instance at org.jboss.ejb3.singleton.impl.container.SingletonEJBInstanceManagerImpl.create(SingletonEJBInstanceManagerImpl.java:137) [:1.0.0-alpha-28] ... Caused by: testsingleton.exn.SE // class SE extends RuntimeException{} at testsingleton.ejb.CounterEjb.pc(CounterEjb.java:28) DEPLOYMENTS IN ERROR: Deployment "startup-singleton-initiator:topLevelUnit=ts.ear,unit=testSingletonEjb.jar,bean=counter" is in error due to the following reason(s): testsingleton.exn.SE at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:1228) [:2.2.0.GA] ------------------------------------------------------ However, it is after that possible to access the singleton through a JNDI lookup and successfully call its methods. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

2
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2255) @SecurityDomain has no equivalent for <security-domain/>

by Richard Kennard (JIRA)

@SecurityDomain has no equivalent for <security-domain/> -------------------------------------------------------- Key: EJBTHREE-2255 URL: https://issues.jboss.org/browse/EJBTHREE-2255 Project: EJB 3.0 Issue Type: Bug Environment: JBoss 6.0.0.Final Reporter: Richard Kennard Test case attached. We have found it useful to turn off the security-domain for certain EJBs so that they can be accessed from unauthenticated clients. We can do this in jboss.xml using <security-domain /> but not, it seems, from an EJB using the @SessionDomain annotation. A @SessionDomain( "" ) is simply ignored. We're not a big fan of hard-coding security domain names inside EJBs, but it seems fine to be able to say 'this EJB has no security domain at all'. Should the annotation work for this? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

3
8
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1642) The <security-domain> tag included in <container-configuration> in the jboss.xml file is ignored

by John Gonon (JIRA)

The <security-domain> tag included in <container-configuration> in the jboss.xml file is ignored ------------------------------------------------------------------------------------------------ Key: EJBTHREE-1642 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1642 Project: EJB 3.0 Issue Type: Bug Components: Security Affects Versions: HEAD Environment: Windows XP JDK 1.6.build10 JBOSS 5.0.0.GA Reporter: John Gonon Priority: Minor The <security-domain> tag included in <container-configuration> in the jboss.xml file is ignored. I have tracked were the problem seems to be (at least as I saw it). In the class "org.jboss.ejb3.security.bridge.SecurityDomainMetaDataBridge" there are those lines: //TODO: How to get the merged meta data? Is the following line correct? if(securityDomain == null) securityDomain = beanMetaData.getJBossMetaData().getSecurityDomain(); I replaced them with: if (securityDomain == null) { JBossMetaData metaData = beanMetaData.getJBossMetaData(); securityDomain = metaData.getContainerConfiguration(beanMetaData.determineConfigurationName()) .getSecurityDomain(); if (securityDomain == null) securityDomain = metaData.getSecurityDomain(); } As I understand it, if no "SecurityDomain" annotation is found, then we finish in this class and we do in order: 1. seek for a security domain in the bean's metadata (I guess it is in the EJB declaration) 2. seek for the one in "jboss-app.xml" I inserted between them some code returning the one comming from the container's configuration I hope this helps ... Best regards, Please keep me informed, I hope to remove my "modified" jar with an official one soon. John -- 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

11 years, 8 months

2
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2011