March 2007 - jboss-jira - Jboss List Archives

[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, 9 months

6
7
0 / 0

[JBoss JIRA] Created: (JBAS-4096) Cleanup the JBoss JTS implementation

by Dimitris Andreadis (JIRA)

Cleanup the JBoss JTS implementation ------------------------------------ Key: JBAS-4096 URL: http://jira.jboss.com/jira/browse/JBAS-4096 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: IIOP service Reporter: Dimitris Andreadis Assigned To: Francisco Reverbel Fix For: JBossAS-4.2.1.CR1 Under the J2EE spec, JTS support is optional. It is preferable not to support it by default, rather than maintaining a JTS implementation inside the app server code base in addition to JBossTS JTS as we go forward. App server users requiring transactions over RMI/IIOP will need to download and drop in the JBoss JTS. Some cleanup of the app server code will be beneficial to ensure elegant failure rather than the current exceptions. We may be able to achieve this though the jboss iiop-service.xml settings? See also JBAS-4024 -- 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, 9 months

1
2
0 / 0

[JBoss JIRA] Created: (JBPM-908) in the suite, use the original loggin in the server

by Tom Baeyens (JIRA)

in the suite, use the original loggin in the server --------------------------------------------------- Key: JBPM-908 URL: http://jira.jboss.com/jira/browse/JBPM-908 Project: JBoss jBPM Issue Type: Task Reporter: Tom Baeyens Assigned To: Tom Baeyens maybe the console logging can be tweaked to include the jbpm.org debug logs but at least the file based logging should be as in the default jboss installation -- 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, 9 months

1
6
0 / 0

[JBoss JIRA] Created: (JBPM-822) XML example incorrect Chapter 7.2.2

by tom (JIRA)

XML example incorrect Chapter 7.2.2 ----------------------------------- Key: JBPM-822 URL: http://jira.jboss.com/jira/browse/JBPM-822 Project: JBoss jBPM Issue Type: Bug Components: Documentation Reporter: tom Assigned To: Tom Baeyens Line: <bean factory="org.jbpm.persistence.db.DbPersistenceServiceFactory"> should read <bean class="org.jbpm.persistence.db.DbPersistenceServiceFactory"> Can I also suggest that the XML configuration schemas or DTDs are also included in the documentation. -- 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, 9 months

3
3
0 / 0

[JBoss JIRA] Created: (JBPM-823) Provide *nix support in the Starters Kit

by Micah Modell (JIRA)

Provide *nix support in the Starters Kit ---------------------------------------- Key: JBPM-823 URL: http://jira.jboss.com/jira/browse/JBPM-823 Project: JBoss jBPM Issue Type: Feature Request Components: Training Environment: RHEL 5 Beta Sun JDK 1.5.0.09 Reporter: Micah Modell Assigned To: Tom Baeyens The Starters Kit and associated documentation is very windows-centric. This is explained adequately and the issues are simple enough to compensate for, but providing the bash scripts would make it that much easier for developers and it's easy to provide them. -- 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, 9 months

3
5
0 / 0

[JBoss JIRA] Created: (JBPM-821) ProcessClassLoader.getResourceAsStream throws JbpmException when the resource is not found in DB

by V?ctor Su?rez (JIRA)

ProcessClassLoader.getResourceAsStream throws JbpmException when the resource is not found in DB ------------------------------------------------------------------------------------------------ Key: JBPM-821 URL: http://jira.jboss.com/jira/browse/JBPM-821 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM 3.1.2 Reporter: V?ctor Su?rez Assigned To: Tom Baeyens "ProcessClassLoader.getResourceAsStream(String name)" must return null when the resource is not found <link>http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ClassLoader.html#getRes...</link>. But when the resource look up must be performed in the DB, if that resource is not found I get a JbpmException. "ProcessClassLoader.getResourceAsStream(String name)" delegates in "fileDefinition.getBytes(name)" for searching the resource, and this calls to "getBytesFromDb(name)", and finally, this calls to "getByteArray(name)", that performs this code: if (byteArray == null) { throw new JbpmException("file '" + name + "' not found in db"); } I think that a possible solution could be: byte[] getBytesFromDb(String name) { byte[] bytes; //refactored this line ByteArray byteArray = doGetByteArray(name); bytes = byteArray.getBytes(); return bytes; } ByteArray getByteArray(String name) { //extract method refactoring ByteArray byteArray = doGetByteArray(name); if (byteArray == null) { throw new JbpmException("file '" + name + "' not found in db"); } return byteArray; } //extracted method ByteArray doGetByteArray(String name) { ByteArray byteArray = (ByteArray) (processFiles != null ? processFiles.get(name) : null); return byteArray; } I let with no modifications "getByteArray(String name)" because is referenced in the rest of code. Thanks -- 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, 9 months

5
5
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, 9 months

3
6
0 / 0

[JBoss JIRA] Created: (JBPM-832) persist annotated classes by using AnnotationConfiguration in HibernateHelper.java

by Chris Russell (JIRA)

persist annotated classes by using AnnotationConfiguration in HibernateHelper.java ---------------------------------------------------------------------------------- Key: JBPM-832 URL: http://jira.jboss.com/jira/browse/JBPM-832 Project: JBoss jBPM Issue Type: Feature Request Components: Core Engine Affects Versions: jBPM 3.2 beta 1 Reporter: Chris Russell Assigned To: Tom Baeyens Fix For: jBPM 3.2 beta 2 Should be able to persist annotated Entitys (classes that dont have a hbm.xml mapping file). To do this is a fairly simple change to HibernateHelper.java. One unresolved question here is why doesnt the hibernate.cfg.xml configuration option <property name="hibernate.ejb.naming_strategy"> get picked up?? HibernateHelper.java .. import org.hibernate.cfg.AnnotationConfiguration; import org.hibernate.cfg.DefaultComponentSafeNamingStrategy; . . public static Configuration createConfiguration(String cfgXmlResource, String propertiesResource) { AnnotationConfiguration configuration = new AnnotationConfiguration(); //NOT SURE WHY BUT configuration not picking up //hibernate.cfg.xml //<property name="hibernate.ejb.naming_strategy"> //org.hibernate.cfg.DefaultComponentSafeNamingStrategy</property> log.debug("NAMING START STRATEGY ["+configuration.getNamingStrategy().getClass().getName()+"]"); log.debug(configuration.setNamingStrategy(new DefaultComponentSafeNamingStrategy())); log.debug("NAMING AFTER STRATEGY ["+configuration.getNamingStrategy().getClass().getName()+"]"); With these changes you can now add mappings to the hibernate.cfg.xml such as <mapping package="foo"/> <mapping class="foo.MyAnnotatedFooClass"/> To pick up annotated classes.... -- 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, 9 months

3
4
0 / 0

[JBoss JIRA] Created: (JBAS-3940) Use the JGroups multiplexer in the 4.2 branch

by Brian Stansberry (JIRA)

Use the JGroups multiplexer in the 4.2 branch --------------------------------------------- Key: JBAS-3940 URL: http://jira.jboss.com/jira/browse/JBAS-3940 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-4.2.0.CR1 Branch_4_2 will use JGroups 2.4.1, so we can use the multiplexer and multiplex the various channels. Only code change for this is in ClusterPartition; other services use JBoss Cache where it is just a config change. -- 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, 9 months

2
5
0 / 0

[JBoss JIRA] Created: (JBAS-4125) Move clustering test support classes to test module

by Brian Stansberry (JIRA)

Move clustering test support classes to test module --------------------------------------------------- Key: JBAS-4125 URL: http://jira.jboss.com/jira/browse/JBAS-4125 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Test Suite Reporter: Brian Stansberry The org.jboss.test.JBossClusteredTestCase, JBossClusteredTestServices and JBossClusteredTestSetup classes should be moved out of the testsuite module and into test. They are just utility classes to support deployment to more than one AS instance and exposure to test clients of more than one JNDI URL and base HTTP URL. EJB3 uses them as well, so they need to be in a binary to allow EJB3 to decouple from the AS. This should be done on both trunk and Branch_4_2. -- 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, 9 months

1
3
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 March 2007