January 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Closed: (JBPM-689) Task Management Definition maps tasks by name

by Koen Aers (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-689?page=all ] Koen Aers closed JBPM-689. -------------------------- Resolution: Done This issue is replaced by GPD-31 > Task Management Definition maps tasks by name > --------------------------------------------- > > Key: JBPM-689 > URL: http://jira.jboss.com/jira/browse/JBPM-689 > Project: JBoss jBPM > Issue Type: Bug > Components: Graphical Process Designer > Affects Versions: jBPM 3.1.1 > Environment: jBPM 3.1.1 > WebSphere 5.1 > Windows XP > Reporter: Chris OBrien > Assigned To: Koen Aers > > When retrieving all tasks from a process definition like so: > processDefinition.getTaskMgmtDefinition().getTasks() > it returns a MAP of tasks, keyed by task name. This is a problem if two tasks anywhere in the same process definition have the same name. > By default, the GPD creates all tasks as "task1" when it is the first task on a task node. If none of these were renamed, you would only get a single task when trying to get all of them for the process definition. > Yes, the tasks probably should be renamed, but there are no restrictions that two tasks couldn't have the same name of "Send Email" or some other common name. -- 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

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBPM-674) All checboxes being checked in Deployment Tab after file saved

by Koen Aers (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-674?page=all ] Koen Aers closed JBPM-674. -------------------------- Resolution: Done This issue is part of GPD-9. I am closing it here. > All checboxes being checked in Deployment Tab after file saved > -------------------------------------------------------------- > > Key: JBPM-674 > URL: http://jira.jboss.com/jira/browse/JBPM-674 > Project: JBoss jBPM > Issue Type: Bug > Components: Graphical Process Designer > Reporter: David Hosier > Assigned To: Tom Baeyens > > If I have a process open in GPD 3.0.9.2, initially the correct set of classes are checked in the Deployment Tab. However, if I leave the process open and save any files, all classes in every source directory in which there was originally a file checked become checked as well. Closing the process and opening it again clears the checkboxes back to their default (and correct) state until a file is saved again. -- 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

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBPM-670) Bug in the configuration of Node

by Koen Aers (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-670?page=all ] Koen Aers closed JBPM-670. -------------------------- Resolution: Done This is done > Bug in the configuration of Node > -------------------------------- > > Key: JBPM-670 > URL: http://jira.jboss.com/jira/browse/JBPM-670 > Project: JBoss jBPM > Issue Type: Bug > Components: Graphical Process Designer > Reporter: Koen Aers > Assigned To: Koen Aers > > The transition element appears before the action element. This should be reversed. -- 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

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBPM-655) node packaging and decoupling

by Koen Aers (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-655?page=all ] Koen Aers updated JBPM-655: --------------------------- Component/s: (was: Graphical Process Designer) > node packaging and decoupling > ----------------------------- > > Key: JBPM-655 > URL: http://jira.jboss.com/jira/browse/JBPM-655 > Project: JBoss jBPM > Issue Type: Task > Components: Core Engine > Reporter: Tom Baeyens > Assigned To: Koen Aers > Fix For: jBPM 4.0 > > > This task is to collect all the artifacts for implementing nodes in jBPM 4. > * Node implementation class > * XML parsing information > * Node persistence: > --- With a hibernate mapping file. In that case, we should scan all node packages somehow to find all the hibernate mapping files. Also this implies that it is not possible to have a common base schema for different languages such as jPDL and BPEL. > --- Persisting node-specific configuration information in descriptors. We can have a generic set of mappings for persisting descriptor information. If the node specific configuration information is parsed to descriptors, it will always be storable. In that case, we just need add the sub class mapping and the type identifier. > * Graphical information: > --- icon > --- form -- 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

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-326) Run testsuite by default with udp.xml, tcp.xml and tcp-nio.xml

by Bela Ban (JIRA)

Run testsuite by default with udp.xml, tcp.xml and tcp-nio.xml -------------------------------------------------------------- Key: JGRP-326 URL: http://jira.jboss.com/jira/browse/JGRP-326 Project: JGroups Issue Type: Task Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 -- 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

19 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-398) Replace all _OK events with method calls to passUp() or passDown()

by Bela Ban (JIRA)

Replace all _OK events with method calls to passUp() or passDown() ------------------------------------------------------------------- Key: JGRP-398 URL: http://jira.jboss.com/jira/browse/JGRP-398 Project: JGroups Issue Type: Task Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 -- 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

19 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-3994) Upgrade apache digester to v1.7

by Dimitris Andreadis (JIRA)

Upgrade apache digester to v1.7 ------------------------------- Key: JBAS-3994 URL: http://jira.jboss.com/jira/browse/JBAS-3994 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Other Reporter: Dimitris Andreadis Assigned To: Dimitris Andreadis Fix For: JBossAS-4.2.0.CR1 Version 1.7brew (build with/for jdk5) -- 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

19 years, 3 months

1
1
0 / 0

[JBoss JIRA] Closed: (JBPM-651) Eclipse workbench freeze

by Koen Aers (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-651?page=all ] Koen Aers closed JBPM-651. -------------------------- Resolution: Done I supposed this is solved as I have not seen any complaints about it any more.So I am closing the issue. > Eclipse workbench freeze > ------------------------ > > Key: JBPM-651 > URL: http://jira.jboss.com/jira/browse/JBPM-651 > Project: JBoss jBPM > Issue Type: Bug > Components: Graphical Process Designer > Reporter: Koen Aers > Assigned To: Koen Aers > > The workbench freezes when importing the jbpm.3 project in the workspace and opening the websale 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

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JGRP-223) Major features that need to make it into JBossAS 5

by Bela Ban (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-223?page=all ] Bela Ban resolved JGRP-223. --------------------------- Resolution: Done > Major features that need to make it into JBossAS 5 > -------------------------------------------------- > > Key: JGRP-223 > URL: http://jira.jboss.com/jira/browse/JGRP-223 > Project: JGroups > Issue Type: Release > Affects Versions: 2.3, 2.4 > Reporter: Bela Ban > Assigned To: Bela Ban > Fix For: 2.5 > > > Container JIRA for JGroups features which need to make it into JBossAS 5 -- 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

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JGRP-180) Harden stack to prevent loss of intra-stack events

by Bela Ban (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-180?page=all ] Bela Ban updated JGRP-180: -------------------------- Fix Version/s: 2.6 (was: 2.5) > Harden stack to prevent loss of intra-stack events > -------------------------------------------------- > > Key: JGRP-180 > URL: http://jira.jboss.com/jira/browse/JGRP-180 > Project: JGroups > Issue Type: Task > Affects Versions: 2.2.9, 2.2.9.1, 2.2.8 > Reporter: Bela Ban > Assigned To: Bela Ban > Fix For: 2.6 > > > When an *intra-stack* event is lost, this can be serious (*inter-stack* message are simply retransmitted, so that is not critical). > Losses are mainly caused by runtime exceptions, e.g. OutOfMemory exception (OOM), or resource problems, and to a lesser extent by program bugs. > For example, when a user sends a message using Channel.send(), and there is an exception, then the user will simply send the message again, possibly after fixing the cause of the exception. > However, for events such as VIEW_CHANGE that are multicast by the GMS protocol, a loss can be serious: in this case, the view would never be received ! > The same applies to the up direction: when NAKACK has successfully delivered a message, if that message is lost travelling between NAKACK and the Channel, then is serious (essentially loss of that message). > So while these error situations don't occur very often, if they do occur, they have serious consequences. > SOLUTION: > - Do nothing for user messages: Channel.send() throws an exception, user has to resend message. Note that in http://jira.jboss.com/jira/browse/JGRP-179, we made retransmission handling atomic, e.g. if there is an exception, there will *not* be a gap in the seqnos for NAKACK and UNICAST > - Provide either a pass{Up/Down}Reliably() method or an Event with a RELIABLE field, such that this event needs to be acked. The sender (e.g. GMS on a VIEW_CHANGE) sends down the message and waits until it gets an ACK, which could be sent by the NAKACK or UNICAST protocols, or as last resort by the transport (TP). If the ACK is not received within M ms, the event is resent. -- 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

19 years, 3 months

1
0
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 January 2007