July 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-3093) Drools Fusion broker example throws stacktraces in drools 5.2.0

by Geoffrey De Smet (JIRA)

Drools Fusion broker example throws stacktraces in drools 5.2.0 --------------------------------------------------------------- Key: JBRULES-3093 URL: https://issues.jboss.org/browse/JBRULES-3093 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Geoffrey De Smet Assignee: Kris Verlaenen Fix For: 5.2.0 {code} ============================================================= Unexpected exception caught: Unexpected exception executing action org.jbpm.process.instance.event.DefaultSignalManager$SignalAction@1eeba19 org.drools.RuntimeDroolsException: Unexpected exception executing action org.jbpm.process.instance.event.DefaultSignalManager$SignalAction@1eeba19 at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:996) at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1059) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:733) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:699) at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:218) at org.drools.examples.broker.Broker.receive(Broker.java:68) at org.drools.examples.broker.events.EventFeeder$FeedJob.execute(EventFeeder.java:85) at org.drools.time.impl.JDKTimerService$JDKCallableJob.call(JDKTimerService.java:146) at org.drools.time.impl.JDKTimerService$JDKCallableJob.call(JDKTimerService.java:124) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: java.lang.IllegalArgumentException: XOR split could not find at least one valid outgoing connection for split Take Action at org.jbpm.workflow.instance.node.SplitInstance.internalTrigger(SplitInstance.java:98) at org.jbpm.workflow.instance.impl.NodeInstanceImpl.trigger(NodeInstanceImpl.java:122) at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerConnection(NodeInstanceImpl.java:185) at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerCompleted(NodeInstanceImpl.java:150) at org.jbpm.workflow.instance.impl.ExtendedNodeInstanceImpl.triggerCompleted(ExtendedNodeInstanceImpl.java:47) at org.jbpm.workflow.instance.node.StateBasedNodeInstance.triggerCompleted(StateBasedNodeInstance.java:162) at org.jbpm.workflow.instance.node.StateBasedNodeInstance.triggerCompleted(StateBasedNodeInstance.java:143) at org.jbpm.workflow.instance.node.RuleSetNodeInstance.signalEvent(RuleSetNodeInstance.java:73) at org.jbpm.workflow.instance.impl.WorkflowProcessInstanceImpl.signalEvent(WorkflowProcessInstanceImpl.java:339) at org.jbpm.process.instance.event.DefaultSignalManager.internalSignalEvent(DefaultSignalManager.java:80) at org.jbpm.process.instance.event.DefaultSignalManager$SignalAction.execute(DefaultSignalManager.java:175) at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:994) ... 15 more {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

5
11
0 / 0

[JBoss JIRA] Created: (AS7-1207) test for not persisted (xa)datasource properties

by Stefano Maestri (JIRA)

test for not persisted (xa)datasource properties ------------------------------------------------ Key: AS7-1207 URL: https://issues.jboss.org/browse/AS7-1207 Project: Application Server 7 Issue Type: Sub-task Components: Test Suite Reporter: Stefano Maestri Fix For: 7.1.0.CR1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

4
4
0 / 0

[JBoss JIRA] Created: (JBAS-9095) Management only mode

by Brian Stansberry (JIRA)

Management only mode -------------------- Key: JBAS-9095 URL: https://issues.jboss.org/browse/JBAS-9095 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Domain Management Reporter: Brian Stansberry Fix For: 7.0.0.Beta4 There is a requirement that "Instances will still be configurable even if they are not currently running. Changes will become active when the instance is next started." That could be interpreted as meaning the xml config files are human editable (which they are), but it would be nice to support something richer; i.e. starting standalone server or ProcessController+HostController processes that install no runtime services beyond what's needed to accept, process and persist management changes. This is a container task; there will be subtasks for standalone mode and domain mode. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

5
6
0 / 0

[JBoss JIRA] Created: (JBAS-9097) Management only standalone mode

by Brian Stansberry (JIRA)

Management only standalone mode ------------------------------- Key: JBAS-9097 URL: https://issues.jboss.org/browse/JBAS-9097 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Domain Management Reporter: Brian Stansberry Fix For: 7.0.0.Beta4 See parent task for core concept. In standalone mode, the issue is distinguishing operations that provide management services from those that don't. If the server is started in "management only" mode a RuntimeContext should only be provided to handlers for those operations. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

5
6
0 / 0

[JBoss JIRA] Created: (AS7-1387) Enable SSL for the Remoting/Native Interface

by Darran Lofthouse (JIRA)

Enable SSL for the Remoting/Native Interface -------------------------------------------- Key: AS7-1387 URL: https://issues.jboss.org/browse/AS7-1387 Project: Application Server 7 Issue Type: Task Components: Domain Management, Remoting, Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 7.1.0.Beta1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

3
3
0 / 0

[JBoss JIRA] Created: (AS7-1388) Certificate based authentication.

by Darran Lofthouse (JIRA)

Certificate based authentication. --------------------------------- Key: AS7-1388 URL: https://issues.jboss.org/browse/AS7-1388 Project: Application Server 7 Issue Type: Task Components: Domain Management, Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 7.1.0.Beta1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

5
6
0 / 0

[JBoss JIRA] Created: (JBREM-1286) Fix sources encoding to UTF-8

by Ondrej Zizka (JIRA)

Fix sources encoding to UTF-8 ----------------------------- Key: JBREM-1286 URL: https://issues.jboss.org/browse/JBREM-1286 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Ondrej Zizka Compiling 395 source files to build/classes src/main/org/jboss/remoting/callback/CallbackStore.java:79: unmappable character for encoding UTF-8 * Key for setting the file suffix to use for the callback objects written to disk. The default value is �ser�. src/main/org/jboss/remoting/callback/CallbackStore.java:79: unmappable character for encoding UTF-8 * Key for setting the file suffix to use for the callback objects written to disk. The default value is �ser�. 2 errors -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

6
9
0 / 0

[JBoss JIRA] Created: (JBREM-552) cannot init cause of ClassCastException

by John Mazzitelli (JIRA)

cannot init cause of ClassCastException --------------------------------------- Key: JBREM-552 URL: http://jira.jboss.com/jira/browse/JBREM-552 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.Beta2 (Boon) Reporter: John Mazzitelli Assigned To: Tom Elrod Priority: Minor Fix For: 2.0.0.CR1 (Boon) I'm in a catch clause within InvokerRegistry and I'm getting a weird exception thrown: java.lang.IllegalStateException: Can't overwrite cause at java.lang.Throwable.initCause(Throwable.java:320) at org.jboss.remoting.InvokerRegistry.loadClientInvoker(InvokerRegistry.java:447) at org.jboss.remoting.InvokerRegistry.createClientInvoker(InvokerRegistry.java:324) at org.jboss.remoting.Client.connect(Client.java:385) at org.jboss.on.communications.command.client.JBossRemotingRemoteCommunicator.getRemotingClient(JBossRemotingRemoteCommunicator.java:470) at org.jboss.on.communications.command.client.JBossRemotingRemoteCommunicator.send(JBossRemotingRemoteCommunicator.java:430) at org.jboss.on.communications.command.client.AbstractCommandClient.invoke(AbstractCommandClient.java:167) at org.jboss.on.communications.command.client.ClientCommandSender.send(ClientCommandSender.java:820) at org.jboss.on.communications.command.client.ServerPollingThread.run(ServerPollingThread.java:102) Look at line 447 and you'll see it is trying to init the cause of a ClassNotFoundException. Running in a debugger, the newly constructed exception created on 446 has a null cause. Looking then at Throwable.initCause and you'll see a null cause causes this IllegalStateException to be thrown. The cause needs to be "this", not null (I don't know why, seems like it should also look for null, but whatever - that's the way the JDK is written). The fix is simple - use the constructor that takes a throwable as its second parameter. Not sure why initCause it being used, as opposed to this constructor. e.g.: new ClassNotFoundException("Can not invoke loadClientInvokerClass method on " + transportFactoryClass, e); (notice the ", e" parameter). There are three other instances where initCause is called on ClassNotFoundException that also need to be fixed. See the other catch clauses in here. -- 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

13 years, 1 month

5
5
0 / 0

[JBoss JIRA] Created: (JGRP-1250) Properties for each message

by Bela Ban (JIRA)

Properties for each message --------------------------- Key: JGRP-1250 URL: https://jira.jboss.org/browse/JGRP-1250 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.12 JGroups already has the ability to bypass certain protocols, e.g. NO_FC set in a message bypasses any flow control layer. It would be nice to do this for other protocols, too, e.g. SEQUENCER, but this needs to be done in a generic fashion. What should be done is to use *properties*, e.g. +reliable-mcast, -frag, +flowcontrol, -bundling etc. Based on these flags, each protocol decides whether to handle (or not) a message. The properties should not take up *any* space in a message if not set. This can probably be generalized, ie. by annotating a protocol with the props it provides, e.g. @Reliable @ReliableUnicast UNICAST, and by having code which matches the flags in a message and decides whether or not to process the message. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

5
11
0 / 0

[JBoss JIRA] Created: (SECURITY-176) Implement JBossRequestContext.asElement(Document)

by Anil Saldhana (JIRA)

Implement JBossRequestContext.asElement(Document) ------------------------------------------------- Key: SECURITY-176 URL: http://jira.jboss.com/jira/browse/SECURITY-176 Project: JBoss Security and Identity Management Issue Type: Task Security Level: Public (Everyone can see) Components: JBossXACML Affects Versions: 2.0.2-BETA6 Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: 2.0.2.GA If provided a Document, then create an element with the request details. Pretty cumbersome process. -- 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

13 years, 1 month

4
4
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2011