November 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPM-691) Decision class does not allow setting of Decision Delegation

by Chris OBrien (JIRA)

Decision class does not allow setting of Decision Delegation ------------------------------------------------------------ Key: JBPM-691 URL: http://jira.jboss.com/jira/browse/JBPM-691 Project: JBoss jBPM Issue Type: Feature Request Components: Core Engine Affects Versions: jBPM 3.1.1 Environment: Windows XP MySQL WSAD 5.1.2 Reporter: Chris OBrien Assigned To: Tom Baeyens In programmatically creating/manipulating a process definition, one cannot specify a Decision Delegation on a Decision node. The Decision class just needs a method like: public void setDecisionDelegation( Delegation del ) { this.decisionDelegation = del; } I have added this to my install, and it allows me to programmatically change the process definition to define the handler. -- 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

18 years, 10 months

4
4
0 / 0

[JBoss JIRA] Created: (JBPM-743) Optionally allow swimlanes to perform assignment for each evaluation

by Brian Greene (JIRA)

Optionally allow swimlanes to perform assignment for each evaluation -------------------------------------------------------------------- Key: JBPM-743 URL: http://jira.jboss.com/jira/browse/JBPM-743 Project: JBoss jBPM Issue Type: Feature Request Components: Core Engine Environment: All Reporter: Brian Greene Assigned To: Tom Baeyens Swimlanes are a very effective way to perform assignment, and we have implemented several that are nicely reusable. A swimlane though, isn't always (to my mind) the same actor or actors throughout the life of a process instance. In our case (and we've several use cases where this is applicable) a swimlane may represent an actor(s) that are related to a particular object or object in the process. The problem arises when the user(s) that are related to said object change in a long-running process. For example, a long running requisition process. The manager of the user who made the requisition may wish to have notifications as the process goes along (we have integrated email functionality in a custom extension). The most intuitive way to handle this as a process author is to use a swimlane that defines the relationship. The current jBPM TaskMgtInstance will only perform the assignment once per swimlane though, assuming that the SAME actor(s) will be used for the life of the process. Depending on what you're orchestrating, this may not be tenable. I think at the least there ought to be a way to allow a swimlane to configure a swimlane to perform its work every time it is referenced rather than using the previously determined actor(s). I've made a modification to jBPM to force swimlane instances to ALWAYS perform assignment, and while this fixes the issue in the short term, eventually I plan to modify either the global config for swimlanes, and better, add an attribute to the swimlane declaration that allows configurable behavior on a swimlane that will override the global default. In this way you could have the current behavior or configure the global setting to behave as I've discussed and provide an override to the current behavior on a case by case basis. You can get this behavior using nested assignment delegations, but there are reusability issues as well as the general cleanliness of the jPDL language to consider. We think swimlanes are in many cases more intuitive, and make the process definition much more readable. As we've discussed in internally, this seems reasonable, and seems to be required in a flexible environment supporting long running processes. -- 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

18 years, 10 months

6
7
0 / 0

[JBoss JIRA] Created: (JGRP-347) TCP bundling with FLUSH not working

by Bela Ban (JIRA)

TCP bundling with FLUSH not working ----------------------------------- Key: JGRP-347 URL: http://jira.jboss.com/jira/browse/JGRP-347 Project: JGroups Issue Type: Bug Affects Versions: 2.3 SP1 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.4 We can make TCP with bundling *on* work (timeout 0) if we exchange order of passUp/passDown of the view for a new member in Gms line 509. Since bundler is sending messages in bundles it screws up synchronous step process required for a new member when doing START_FLUSH, view installation, STOP_FLUSH. We have a thread race here on line 509. In order to circumvent that we can *first* pass a view from a join response up to FLUSH and then pass it down. I am not sure how this affects other tests. -- 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

18 years, 10 months

3
6
0 / 0

[JBoss JIRA] Created: (JBAS-3572) Fix the NPEs (better error handling) identified by the new ServiceController testsuite

by Adrian Brock (JIRA)

Fix the NPEs (better error handling) identified by the new ServiceController testsuite -------------------------------------------------------------------------------------- Key: JBAS-3572 URL: http://jira.jboss.com/jira/browse/JBAS-3572 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.0.4.GA Reporter: Adrian Brock The new testsuite in system[-jmx] has identifies a number of areas where the old Service deployment (including the impl in JBoss4) does not give a reasonable error message, e.g. it throws an NPE These need to be fixed. -- 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

18 years, 10 months

3
6
0 / 0

[JBoss JIRA] Created: (JBPM-738) jboss.com and jboss.org show different download versions

by Ronald van Kuijk (JIRA)

jboss.com and jboss.org show different download versions -------------------------------------------------------- Key: JBPM-738 URL: http://jira.jboss.com/jira/browse/JBPM-738 Project: JBoss jBPM Issue Type: Bug Environment: JBoss sites Reporter: Ronald van Kuijk Assigned To: Tom Baeyens Priority: Critical http://www.jboss.com/products/jbpm/downloads shows jBPM 3.0.4, 3.1.2 and GPD 3.0.11 http://labs.jboss.com/portal/jbossjbpm/download/ shows jBPM 3.1 and GPD 3.0.8 (bpel version is also wrong) Please can somebody fix this. No wonder old errors pop up know and then. -- 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

18 years, 10 months

5
6
0 / 0

[JBoss JIRA] Created: (JBREM-641) re-implement the callback polling for http transport to reduce latency

by Tom Elrod (JIRA)

re-implement the callback polling for http transport to reduce latency ---------------------------------------------------------------------- Key: JBREM-641 URL: http://jira.jboss.com/jira/browse/JBREM-641 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: callbacks Affects Versions: 2.0.0.GA (Boon) Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.2.0.Beta1 (Bluto) Per forum thread, would be nice to have a more "real-time" way to get callbacks from server when using http transport so don't have to wait on ping period. -- 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

18 years, 11 months

2
12
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-629) Unneccessary puts and gets in message store

by Tim Fox (JIRA)

Unneccessary puts and gets in message store ------------------------------------------- Key: JBMESSAGING-629 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-629 Project: JBoss Messaging Issue Type: Task Affects Versions: 1.0.1.GA, 1.2.0.Alpha1 Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.0.Beta1 We are currently executing unnecessary puts into the message store on the primary execution path of message routing. When a new message arrives - it is first added to the message store. The message is only ever retrieved from the message store if a reference is loaded from paging and we want to make sure we do not have more than once instance in memory at once. The first put is therefore unnecessary and will have some performance implications. Messages should only be added to the message store (if necessary) when they are paged to storage -- 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

18 years, 11 months

5
10
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1141) use binaries udner jbossas instead of portal while running portal testsuite

by Prabhat Jha (JIRA)

use binaries udner jbossas instead of portal while running portal testsuite --------------------------------------------------------------------------- Key: JBPORTAL-1141 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1141 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal Test Reporter: Prabhat Jha Assigned To: Julien Viet WSRP tests had failed while testing portal2.4.1.CR1 with jboss4.0.5 because there was a mismatch in webservices binary versions. To remove this conflict, it would be better if portal testsuite could point to jbossas binaries instead of binaries under portal/thirdparty. -- 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

18 years, 11 months

5
10
0 / 0

[JBoss JIRA] Created: (JBAS-3827) Remove JMS transport support

by Thomas Diesler (JIRA)

Remove JMS transport support ---------------------------- Key: JBAS-3827 URL: http://jira.jboss.com/jira/browse/JBAS-3827 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Web Services Reporter: Thomas Diesler Assigned To: Thomas Diesler Fix For: JBossAS-4.2.0.CR1 This should all be handled by jbossws -- 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

18 years, 11 months

3
2
0 / 0

[JBoss JIRA] Created: (JBAS-3670) org.jboss.axis.ConfigurationException: No engine configuration file

by Keith Gregory (JIRA)

org.jboss.axis.ConfigurationException: No engine configuration file ------------------------------------------------------------------- Key: JBAS-3670 URL: http://jira.jboss.com/jira/browse/JBAS-3670 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web Services Affects Versions: JBossAS-4.0.3 SP1 Reporter: Keith Gregory Assigned To: Thomas Diesler Priority: Minor The default org.jboss.axis.client.Service constructor will throw this exception. My particular case involves creating a new Service object from within an EJB, but this should occur with any client. Tracing through the code, I discovered that org.jboss.axis.configuration.EngineConfigurationFactoryDefault defines the default filenames for the client configuration as "client-config.wsdd", while the actual file distributed with jboss-ws4ee-client.jar is "axis-client-config.xml". When the Service object is constructed, org.jboss.axis.configuration.FileProvider looks on the classpath for "client-config.wsdd", and of course can't find it. The workaround specified in JBAS-1106 puts a file with the correct name but possibly the wrong configuration information onto the classpath, where FileProvider can find it. This will work for a standalone client, but not for client code within an EJB, since the Axis packages appear to be loaded with a different classloader than that for the EJB. The workaround is to provide the Service constructor with a FileProvider that specifies the correct configuration file: new Service(new FileProvider("META-INF/axis-client-config.xml")) -- 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

18 years, 11 months

2
1
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 November 2006