March 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-1663) DRL/DSLR file inclusion

by Paul Ryan (JIRA)

DRL/DSLR file inclusion ----------------------- Key: JBRULES-1663 URL: http://jira.jboss.com/jira/browse/JBRULES-1663 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Documentation, Drl Parser/Builder, drools-brms Reporter: Paul Ryan Assigned To: Mark Proctor The ability to include one rule file in another would be helpful from the stand point of overrides. I know this can be done using the package builder however giving the rule file writer the ability to include a parent rule file by directory would be of great benefit on some projects. This would allow an easy mechanism for override and extension paradigms for rules without moving into full inheritance (very much not needed). It appears that this was possible when rules were still xml by just using entities but that this feature has been overlooked when moving to text based drl files. -- 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

15 years, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-1998) Classes with same name but difference packages cannot be used as Facts in BRL definitions

by Chris LeCompte (JIRA)

Classes with same name but difference packages cannot be used as Facts in BRL definitions ----------------------------------------------------------------------------------------- Key: JBRULES-1998 URL: https://jira.jboss.org/jira/browse/JBRULES-1998 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-guvnor Affects Versions: 5.0.0.M5 Reporter: Chris LeCompte Assignee: Mark Proctor Guvnor (as well as Drools in general) allows for defining packages which import facts from different java packages with the same name. In a technical rules file, this problem can be resolved obviously by fully qualifying the names of the facts used in the rule(s). In the business rule editor however the user is presented with two names in the facts drop down and can only pull properties from the last type added in the imports. The editor should have some capability to sort this out either by appending a package name where collisions occur or by appending a (1), (2),..., (n) suffix to the names of the classes and internally mapping the facts back to their respective classes. The error in the logs when validating a resultant rule using the editor gives the error: Unable to find unambiguously defined class... -- 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

15 years, 9 months

3
2
0 / 0

[JBoss JIRA] Created: (JBPORTAL-2359) Link to http://portal.demo.jboss.com/ is broken

by Joao Paulo Viragine (JIRA)

Link to http://portal.demo.jboss.com/ is broken ----------------------------------------------- Key: JBPORTAL-2359 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2359 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.7.2 Final Environment: JBoss Portal 2.7.2-SNAPSHOT Reporter: Joao Paulo Viragine Link to http://portal.demo.jboss.com/ is broken. This link appears in Demo (image/link) of Welcome portlet (JSPPortletWindow) -- 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

15 years, 9 months

2
1
0 / 0

[JBoss JIRA] Created: (JBPORTAL-2360) Ordering alphabetically the Language combo box in CMS Editor (Create File)

by Joao Paulo Viragine (JIRA)

Ordering alphabetically the Language combo box in CMS Editor (Create File) -------------------------------------------------------------------------- Key: JBPORTAL-2360 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2360 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Portal CMS Affects Versions: 2.7.2 Final Environment: JBoss Portal 2.7.2-SNAPSHOT. Reporter: Joao Paulo Viragine Assignee: Sohil Shah -- 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

15 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-6669) when new items are added to the "config-property" composite ManagedProperty on a Datasource component, after updateComponent() is called, the items that were added are gone

by Ian Springer (JIRA)

when new items are added to the "config-property" composite ManagedProperty on a Datasource component, after updateComponent() is called, the items that were added are gone ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBAS-6669 URL: https://jira.jboss.org/jira/browse/JBAS-6669 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: ProfileService Reporter: Ian Springer Assignee: Scott M Stark I'm assuming this may be because the "config-property" prop is meant to be read-only on Datasources. If that is the case, the ManagedProperty just needs to be marked as read-only once that API has been added. -- 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

15 years, 9 months

3
8
0 / 0

[JBoss JIRA] Created: (JBAS-6696) add another parameter to DeploymentManager.distribute(), e.g. boolean deployExploded, where true means the archive gets unzipped before it's deployed

by Ian Springer (JIRA)

add another parameter to DeploymentManager.distribute(), e.g. boolean deployExploded, where true means the archive gets unzipped before it's deployed ----------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBAS-6696 URL: https://jira.jboss.org/jira/browse/JBAS-6696 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: ProfileService Reporter: Ian Springer Assignee: Emanuel Muckenhuber -- 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

15 years, 9 months

1
1
0 / 0

[JBoss JIRA] Commented: (JBMESSAGING-1406) Implement STOMP protocol natively

by Michael Justin (JIRA)

[ https://jira.jboss.org/jira/browse/JBMESSAGING-1406?page=com.atlassian.ji... ] Michael Justin commented on JBMESSAGING-1406: --------------------------------------------- Implementation of a Delphi 6 - 2009 and Free Pascal client is on my "todo list" already, I did it already for other JMS message brokers. > Implement STOMP protocol natively > --------------------------------- > > Key: JBMESSAGING-1406 > URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1406 > Project: JBoss Messaging > Issue Type: Task > Reporter: Tim Fox > Assignee: Tim Fox > Fix For: Unscheduled > > > Implement native broker support for STOMP (i.e. not using StompConnect) > http://stomp.codehaus.org -- 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

15 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-6695) Error occurs when starting JBoss Server because of JTA configuration

by ali aslan (JIRA)

Error occurs when starting JBoss Server because of JTA configuration -------------------------------------------------------------------- Key: JBAS-6695 URL: https://jira.jboss.org/jira/browse/JBAS-6695 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.0.1.GA Environment: Developer Machine: Windows Vista 64 bit Reporter: ali aslan Hi, I am new to JBoss and I think there is a problem with the configuration of JTA. In my components.xml I have the following entry: <core:init debug="true" jndi-pattern="@jndiPattern@" transaction-management-enabled="true" user-transaction-name="jta/UserTransaction"/> But the following error occurs starting the server: java.lang.RuntimeException: Could not create Component: org.jboss.seam.core.init at org.jboss.seam.init.Initialization.addComponent(Initialization.java:1178) at org.jboss.seam.init.Initialization.init(Initialization.java:696) at org.jboss.seam.servlet.SeamListener.contextInitialized(SeamListener.java:35) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3910) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4393) at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:312) at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:144) at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461) at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118) at org.jboss.web.deployers.WebModule.start(WebModule.java:97) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206) at $Proxy36.start(Unknown Source) at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42) at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37) at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:286) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553) at org.jboss.system.ServiceController.doChange(ServiceController.java:688) at org.jboss.system.ServiceController.start(ServiceController.java:460) at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163) at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99) at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46) at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62) at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50) at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171) at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210) at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553) at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781) at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:698) at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:304) at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:205) at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:405) at org.jboss.Main.boot(Main.java:209) at org.jboss.Main$1.run(Main.java:547) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.IllegalArgumentException: no such field: org.jboss.seam.core.Init.userTransactionName at org.jboss.seam.util.Reflections.getField(Reflections.java:316) at org.jboss.seam.Component.initInitializers(Component.java:490) at org.jboss.seam.Component.(Component.java:255) at org.jboss.seam.Component.(Component.java:206) at org.jboss.seam.init.Initialization.addComponent(Initialization.java:1162) ... 61 more -- 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

15 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-2017) Custom exception handler for condition evaluator

by Sergej Iljin (JIRA)

Custom exception handler for condition evaluator ------------------------------------------------ Key: JBRULES-2017 URL: https://jira.jboss.org/jira/browse/JBRULES-2017 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.0.0.CR1, 5.0.0.M5 Reporter: Sergej Iljin Assignee: Mark Proctor Priority: Critical Fix For: 5.0.0.GA Custom exception handler for condition evaluator. Its proposed to introduce custom exception handler for condition evaluator becaue "always re-trow" approach is not appropriate for some cases when fail-safe rule execution is necessary. There is an requirment which can't be satisfied with current implementation of condition evaluator: "All rules that are present in agenda should be performed fail safe and independed". So it means that if there are 2 rules and one of them throws a NullPointer exception while condition evaluation (because of wrong configuration) the second rule have to be performed. Changes have to be applied to following class: drools-core\src\main\java\org\drools\rule\EvalCondition.java in method: public boolean isAllowed(final Tuple tuple, final WorkingMemory workingMemory, final Object context) { try { return this.expression.evaluate( tuple, this.requiredDeclarations, workingMemory, context ); } catch ( final Exception e ) { throw new RuntimeDroolsException( this.getEvalExpression() + " : " + e, e ); } } should be replaced with somethig like this public boolean isAllowed(final Tuple tuple, final WorkingMemory workingMemory, final Object context) { try { return this.expression.evaluate( tuple, this.requiredDeclarations, workingMemory, context ); } catch ( final Exception e ) { getExceptionHandler().handle(e); } } -- 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

15 years, 9 months

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-2018) Documentation pat

by Wolfgang Laun (JIRA)

Documentation pat ----------------- Key: JBRULES-2018 URL: https://jira.jboss.org/jira/browse/JBRULES-2018 Project: JBoss Drools Issue Type: Patch Security Level: Public (Everyone can see) Reporter: Wolfgang Laun Assignee: Mark Proctor -- 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

15 years, 9 months

2
1
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2009