August 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-2213) When the decider doesn't pick a move, the DefaultLocalSearchSolver shouldn't terminate by exception by try again, especially with relativeSelection on

by Geoffrey De Smet (JIRA)

When the decider doesn't pick a move, the DefaultLocalSearchSolver shouldn't terminate by exception by try again, especially with relativeSelection on ------------------------------------------------------------------------------------------------------------------------------------------------------ Key: JBRULES-2213 URL: https://jira.jboss.org/jira/browse/JBRULES-2213 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-solver Affects Versions: 5.0.1.FINAL Reporter: Geoffrey De Smet Assignee: Geoffrey De Smet Priority: Critical a random bad relativeSelection could select only moves that are tabu that no reason to stop, because the next relativeSelection could be great. -- 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

13 years, 9 months

3
5
0 / 0

[JBoss JIRA] (JBRULES-3598) Planner: topSize move selector (was removed for 5.5.0.Beta1, bring it back)

by Geoffrey De Smet (JIRA)

Geoffrey De Smet created JBRULES-3598: ----------------------------------------- Summary: Planner: topSize move selector (was removed for 5.5.0.Beta1, bring it back) Key: JBRULES-3598 URL: https://issues.jboss.org/browse/JBRULES-3598 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-planner Reporter: Geoffrey De Smet Priority: Optional This never worked well and it was trouble to migrate in the new selector architecture. Nevertheless, it might work well if properly implemented. So bring it back if enough people vote for this issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
0
0 / 0

[JBoss JIRA] (AS7-5313) Deployment of multiple .rar's with ironjacamar.xml

by Brad Maxwell (JIRA)

Brad Maxwell created AS7-5313: --------------------------------- Summary: Deployment of multiple .rar's with ironjacamar.xml Key: AS7-5313 URL: https://issues.jboss.org/browse/AS7-5313 Project: Application Server 7 Issue Type: Bug Components: JCA Affects Versions: 7.1.2.Final (EAP) Reporter: Brad Maxwell Assignee: Stefano Maestri Priority: Critical Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1 Deploying an .ear with multiple .rar's, which all have an ironjacamar.xml file results in {noformat} 11:17:24,899 ERROR [org.jboss.msc.service] (MSC service thread 1-14) MSC000002: Invocation of listener "org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1@16c5f7e" failed: java.lang.IllegalArgumentException: JBAS014809: Ein Knoten ist bereits registriert unter '(deployment => *)(subdeployment => *)(subsystem => resource-adapters)(ironjacamar => ironjacamar)' at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:108) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] at org.jboss.as.controller.registry.AbstractResourceRegistration.registerSubModel(AbstractResourceRegistration.java:68) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] at org.jboss.as.connector.subsystems.resourceadapters.IronJacamarRegistrator.invoke(IronJacamarRegistrator.java:33) [jboss-as-connector-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] at org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1.registerIronjacamar(ParsedRaDeploymentProcessor.java:158) [jboss-as-connector-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] at org.jboss.as.connector.deployers.ra.processors.AbstractResourceAdapterDeploymentServiceListener.transition(AbstractResourceAdapterDeploymentServiceListener.java:131) [jboss-as-connector-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1416) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1] at org.jboss.msc.service.ServiceControllerImpl.access$2700(ServiceControllerImpl.java:49) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1] at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:1954) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_31] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31] {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
0
0 / 0

[JBoss JIRA] (AS7-5300) Enhance user-name vs. security domain check

by Jesper Pedersen (JIRA)

Jesper Pedersen created AS7-5300: ------------------------------------ Summary: Enhance user-name vs. security domain check Key: AS7-5300 URL: https://issues.jboss.org/browse/AS7-5300 Project: Application Server 7 Issue Type: Task Components: JCA Affects Versions: 7.1.2.Final (EAP) Reporter: Jesper Pedersen Assignee: Stefano Maestri Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1 Enhance the check of user-name vs. security domain so only one can be defined at a time -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
2
0 / 0

[JBoss JIRA] (AS7-5240) The naming subsystem is not shown in the profiles subsystem view if the server is started in domain mode

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created AS7-5240: ------------------------------------- Summary: The naming subsystem is not shown in the profiles subsystem view if the server is started in domain mode Key: AS7-5240 URL: https://issues.jboss.org/browse/AS7-5240 Project: Application Server 7 Issue Type: Bug Components: Console, Domain Management Affects Versions: 7.1.2.Final (EAP) Environment: Domain mode Reporter: Wolf-Dieter Fink Assignee: Heiko Braun The naming subsystem is not shown in domain mode for the different profiles. If the server is started in standalone mode the naming subsystem is shown in the tree of Profile/Container between Transaction and EJB3. In domain mode I expect it if I select a profile at the same location. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
3
0 / 0

[JBoss JIRA] (AS7-5269) HornetQ interceptors are not supported

by Jeff Mesnil (JIRA)

Jeff Mesnil created AS7-5269: -------------------------------- Summary: HornetQ interceptors are not supported Key: AS7-5269 URL: https://issues.jboss.org/browse/AS7-5269 Project: Application Server 7 Issue Type: Feature Request Components: JMS Affects Versions: 7.1.2.Final (EAP) Reporter: Jeff Mesnil Assignee: Jeff Mesnil HornetQ interceptors are not supported by the messaging subsystem. Their attributes are handled by the XML parser but they are not set when adding the HornetQ server instance. Moreover, passing the interceptor class name is not enough. Since they are loaded by HornetQ, its classloader must be able to access them. The interceptors must be put in a JBoss module that is declared as a transitive dependency of org.hornetq module. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
2
0 / 0

[JBoss JIRA] (JBJCA-881) ShrinkWrap Descriptors 2.0.0.Alpha4

by Jesper Pedersen (JIRA)

Jesper Pedersen created JBJCA-881: ------------------------------------- Summary: ShrinkWrap Descriptors 2.0.0.Alpha4 Key: JBJCA-881 URL: https://issues.jboss.org/browse/JBJCA-881 Project: IronJacamar Issue Type: Component Upgrade Components: Build Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.1.0.Beta2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBFORUMS-298) xception in thread "main" javax.xml.stream.FactoryConfigurationError: Provider com.bea.xml.stream.EventFactory not found

by chandrasheker b (JIRA)

chandrasheker b created JBFORUMS-298: ---------------------------------------- Summary: xception in thread "main" javax.xml.stream.FactoryConfigurationError: Provider com.bea.xml.stream.EventFactory not found Key: JBFORUMS-298 URL: https://issues.jboss.org/browse/JBFORUMS-298 Project: JBoss Forums Issue Type: Feature Request Reporter: chandrasheker b Assignee: Luca Stancapiano C:\Program Files\jboss-eap-6.0\bin>standalone.bat Calling "C:\Program Files\jboss-eap-6.0\bin\standalone.conf.bat" =============================================================================== JBoss Bootstrap Environment JBOSS_HOME: C:\Program Files\jboss-eap-6.0 JAVA: C:\Java\jdk1.6.0_26\bin\java JAVA_OPTS: -client -Dprogram.name=standalone.bat -Xms64M -Xmx512M -XX:MaxPermSize=256M -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djboss.server.default.config=standalone.xml =============================================================================== Exception in thread "main" javax.xml.stream.FactoryConfigurationError: Provider com.bea.xml.stream.EventFactory not found at javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java:72) at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:176) at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:92) at javax.xml.stream.XMLEventFactory.newInstance(XMLEventFactory.java:30) at __redirected.__XMLEventFactory.<clinit>(__XMLEventFactory.java:73) at __redirected.__JAXPRedirected.initAll(__JAXPRedirected.java:81) at org.jboss.modules.Module$1.run(Module.java:126) at org.jboss.modules.Module$1.run(Module.java:113) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.modules.Module.<clinit>(Module.java:113) at org.jboss.modules.Main.main(Main.java:255) Press any key to continue . . . -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBRULES-3587) Declarations from "declare" sections don't apply to sub-classes if those live in a different package

by Jörg Henne (JIRA)

Jörg Henne created JBRULES-3587: ----------------------------------- Summary: Declarations from "declare" sections don't apply to sub-classes if those live in a different package Key: JBRULES-3587 URL: https://issues.jboss.org/browse/JBRULES-3587 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.4.0.Final Reporter: Jörg Henne Assignee: Mark Proctor Declarations (like {{@role(event)}}) in a {{declare}}-Section should apply to sub-classes of the declared class, too, but don't if the sub-class resides in a different package than the base class. Attached you'll find an example which demonstrates the issue. The class {{ButtonEvent}} derives from {{VSCPEvent}} which is declared with{{@role(event)}}. Running {{com.levigo.overlord.DroolsTest}} yields a {{java.lang.ClassCastException: org.drools.common.DefaultFactHandle}} which is caused by the ButtonEvent not being recognized as an event instead of a fact. The Problem goes away if {{ButtonEvent}} is declared as an event (uncomment the section in {{overlord.drl}} or {{ButtonEvent}} is moved to the same package as {{VSCPEvent}}. For more information see the referenced forum thread. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
5
0 / 0

[JBoss JIRA] Created: (JBRULES-3033) java.lang.ClassCastException when change rule condition and declarative facts/events are used

by Federico Weisse (JIRA)

java.lang.ClassCastException when change rule condition and declarative facts/events are used --------------------------------------------------------------------------------------------- Key: JBRULES-3033 URL: https://issues.jboss.org/browse/JBRULES-3033 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.1.1.FINAL Reporter: Federico Weisse Assignee: Mark Proctor We have drl files where we declare events. we use declarative events (there is no java class AlertaPosManual) (like this) declare AlertaPosManual @role (event) @expires(10s) idTerminal : java.lang.String end We use a StatefullSession for fusion cep and we need that changes in rules refresh the kBase in runtime. But when a rule condition changes this exception in throw Exception in thread "Thread-2" java.lang.ClassCastException: com.sample.ConsumoPostManual cannot be cast to com.sample.ConsumoPostManual at org.drools.base.com.sample.ConsumoPostManual17710704$getIdTerminal.getValue(Unknown Source) at org.drools.base.extractors.BaseObjectClassFieldReader.getHashCode(BaseObjectClassFieldReader.java:192) at org.drools.base.ClassFieldReader.getHashCode(ClassFieldReader.java:193) at org.drools.core.util.AbstractHashTable$SingleIndex.hashCodeOf(AbstractHashTable.java:582) at org.drools.core.util.RightTupleIndexHashTable.getOrCreate(RightTupleIndexHashTable.java:360) at org.drools.core.util.RightTupleIndexHashTable.add(RightTupleIndexHashTable.java:243) at org.drools.reteoo.AccumulateNode.assertObject(AccumulateNode.java:246) at org.drools.reteoo.ObjectTypeNode.updateSink(ObjectTypeNode.java:276) at org.drools.reteoo.PropagationQueuingNode.updateSink(PropagationQueuingNode.java:111) at org.drools.reteoo.BetaNode.attach(BetaNode.java:214) at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:151) at org.drools.reteoo.builder.CollectBuilder.build(CollectBuilder.java:114) at org.drools.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:111) at org.drools.reteoo.builder.PatternBuilder.build(PatternBuilder.java:72) at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:132) at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:78) at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:155) at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:128) at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:117) at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:428) at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:721) at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:545) at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:445) at org.drools.reteoo.ReteooRuleBase.addPackage(ReteooRuleBase.java:452) at org.drools.agent.impl.KnowledgeAgentImpl.addResourcesToKnowledgeBase(KnowledgeAgentImpl.java:937) at org.drools.agent.impl.KnowledgeAgentImpl.incrementalBuildResources(KnowledgeAgentImpl.java:821) at org.drools.agent.impl.KnowledgeAgentImpl.buildKnowledgeBase(KnowledgeAgentImpl.java:586) at org.drools.agent.impl.KnowledgeAgentImpl.applyChangeSet(KnowledgeAgentImpl.java:185) at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector.run(KnowledgeAgentImpl.java:1106) at java.lang.Thread.run(Thread.java:619) I think that's because the statefullSession has an instance of com.sample.ConsumoPostManual (loaded with the classLoader org.drools.rule.JavaDialectRuntimeData$PackageClassLoader@1218b25) But when the kBase is regenerated and the class com.sample.ConsumoPostManual to, the classLoader org.drools.rule.JavaDialectRuntimeData is recreated so there are two versions of the class com.sample.ConsumoPostManual in differents classLoader (one in the statefullSession and the other in the kBase) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
2
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 August 2012