June 2008 - jbpm-issues - Jboss List Archives

[JBoss JIRA] Updated: (JBPM-250) policy implementation based on the identity component

by Thomas Diesler (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-250?page=all ] Thomas Diesler updated JBPM-250: -------------------------------- Assignee: (was: Tom Baeyens) > policy implementation based on the identity component > ----------------------------------------------------- > > Key: JBPM-250 > URL: http://jira.jboss.com/jira/browse/JBPM-250 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Reporter: Tom Baeyens > Priority: Minor > > a policy implementation that verifies permissions against the currently authenticated user. the currently authenticated user should be looked up in the identity component database and the permissions can be collected from that database. -- 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

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBPM-564) jbpm community contribution tips

by Thomas Diesler (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-564?page=all ] Thomas Diesler updated JBPM-564: -------------------------------- Assignee: (was: Tom Baeyens) > jbpm community contribution tips > -------------------------------- > > Key: JBPM-564 > URL: http://jira.jboss.com/jira/browse/JBPM-564 > Project: JBoss jBPM > Issue Type: Task > Reporter: Tom Baeyens > Priority: Minor > > if you're looking for something to contribute. this issue links to issues that are good candidates to get you started. of course, you're always free to do your own proposal on the jbpm development forum: http://www.jboss.org/index.html?module=bb&op=viewforum&f=219 > regards, tom. -- 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

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBPM-720) create a schema for the jbpm ws frontend

by Thomas Diesler (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-720?page=all ] Thomas Diesler updated JBPM-720: -------------------------------- Assignee: (was: Ronald van Kuijk) > create a schema for the jbpm ws frontend > ---------------------------------------- > > Key: JBPM-720 > URL: http://jira.jboss.com/jira/browse/JBPM-720 > Project: JBoss jBPM > Issue Type: Sub-task > Environment: n/a > Reporter: Ronald van Kuijk > Priority: Minor > Original Estimate: 1 day > Remaining Estimate: 1 day > > It should work with jboss ws 1.0.2.GA (or all since 1.0?) -- 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

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBPM-993) make assignment handlers configurable

by Thomas Diesler (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-993?page=all ] Thomas Diesler updated JBPM-993: -------------------------------- Assignee: (was: Tom Baeyens) > make assignment handlers configurable > ------------------------------------- > > Key: JBPM-993 > URL: http://jira.jboss.com/jira/browse/JBPM-993 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Affects Versions: jBPM 3.1.4 > Environment: N/A > Reporter: Martin Goldhahn > Priority: Minor > Attachments: assignment-handler.patch > > > The JpdlXmlReader contains a hard-coded reference to both org.jbpm.identity.assignment.ExpressionAssignmentHandler and org.jbpm.taskmgmt.assignment.ActorAssignmentHandler. > We need this parameter to be configurable, e.g. being able to use our own ExpressionAssignmentHandler -- 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

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBPM-66) add collections support to process variables

by Thomas Diesler (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-66?page=all ] Thomas Diesler updated JBPM-66: ------------------------------- Assignee: (was: Tom Baeyens) > add collections support to process variables > -------------------------------------------- > > Key: JBPM-66 > URL: http://jira.jboss.com/jira/browse/JBPM-66 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Reporter: Tom Baeyens > Priority: Optional > > we can add support for collections and maps to process variables. > even a merge can be implemented straightforward when the collections are updated. > this would require a ListVariableInstance and a MapVariableInstance.... -- 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

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBPM-1008) ejb deployment : avoid ClassNotFoundException on client side after unmarshalling

by Thomas Diesler (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-1008?page=all ] Thomas Diesler updated JBPM-1008: --------------------------------- Assignee: (was: Tom Baeyens) > ejb deployment : avoid ClassNotFoundException on client side after unmarshalling > --------------------------------------------------------------------------------- > > Key: JBPM-1008 > URL: http://jira.jboss.com/jira/browse/JBPM-1008 > Project: JBoss jBPM > Issue Type: Bug > Affects Versions: jBPM jPDL 3.2.1 > Environment: enterprise jBPM > Reporter: Adrian Dimulescu > > Two aspects in this jira : 1: hide hibernate-specific exceptions; 2: hide hibernate-specific datatypes. > 1. The EJB client only depends on the jBPM jar (for the various Command implementations) and on the JBoss client jar. If a Hibernate exception occurs, it is wrapped by a JBPMException and rethrown. When deserialiezed on the client side (which does not have a Hibernate dependency), a ClassNotFoundException occurs. > I think the CommandServiceBean should not wrap internal implementation-specific exceptions; it should instead simply copy the stack trace and throw a new implementation-independent exception which contains the exception trace without containing the causes themselves. That typically avoids ClassNotFoundExceptions without losing exception history. > 2. The second problem is that hibernate-specific collections get serialized over the wire, here is the description of the problem : > I use the GetProcessInstancesCommand in order to experiment with querying the remote ejb. This command returns a list with ProcessInstances. A ProcessInstance is read by Hibernate from the database. As Hibernate uses specific lazy-loading-aware implementations for collections -- the ProcessInstance.instances attribute, which is declared of type java.util.Map, is actually implemented by org.hibernate.collections.PersistentMap. > Which generates class loading exception while deserializing to hibernate-unaware ejb clients. > The solution would then be for the Command implementations to return clean JDK collections, by replacing Hibernate collection with JDK standard ones. Note that IIUC only the collections must be replaced, not the collection contents too, so the "cleaning" operation should not be that expensive. Cleaning should be only done in the SLSB remote call use case -- because in-JVM callers may want to benefit lazy-loading. -- 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

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBPM-1040) Improve jbpm:datacell with cross columns and rows feature

by Thomas Diesler (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-1040?page=all ] Thomas Diesler updated JBPM-1040: --------------------------------- Assignee: (was: Tom Baeyens) > Improve jbpm:datacell with cross columns and rows feature > --------------------------------------------------------- > > Key: JBPM-1040 > URL: http://jira.jboss.com/jira/browse/JBPM-1040 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Web Interface > Affects Versions: jBPM jPDL 3.2.1 > Reporter: zhou guangzhao > Priority: Optional > > The tag <jbpm:dataform> now has attribute "columns" that makes the table has multi columns. > But each <jpbm:datacell> can only occupy one cell in the table generated automatically by dataform. > In some cases, user need a datacell to cross more columns or rows. > So it is necessary to add the feature as title. -- 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

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBPM-1069) Include common-io and common-fileupload in the ear configuration

by Thomas Diesler (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-1069?page=all ] Thomas Diesler updated JBPM-1069: --------------------------------- Assignee: (was: Tom Baeyens) > Include common-io and common-fileupload in the ear configuration > ---------------------------------------------------------------- > > Key: JBPM-1069 > URL: http://jira.jboss.com/jira/browse/JBPM-1069 > Project: JBoss jBPM > Issue Type: Bug > Components: Core Engine > Affects Versions: jBPM jPDL 3.2.2 > Reporter: Fady Matar > Priority: Trivial > > Include the common-io.jar or the common-fileupload in the ear configuration or the JBoss server configuration whenever building the enterprise configuration (running the deploy target from the jbpm.enterprise.xml ant file) > The ear files can be appended to the JBoss AS configuration or can be packaged within the ear -- 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

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBPM-627) Cancel timer problem

by Thomas Diesler (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-627?page=all ] Thomas Diesler updated JBPM-627: -------------------------------- Assignee: (was: Tom Baeyens) > Cancel timer problem > -------------------- > > Key: JBPM-627 > URL: http://jira.jboss.com/jira/browse/JBPM-627 > Project: JBoss jBPM > Issue Type: Bug > Components: Core Engine > Affects Versions: jBPM 3.1 > Environment: Windows XP Pro > Database: DB2/400 v5r3, HSQLDB > Reporter: Mark Shotton > Attachments: JBPM-627-screenshots.doc > > > As reported in issue JBPM-594, timers do not get deleted on the cancel-timer event. This is because in SchedulerSession.cancelTimersByName(String, Token), the timer is deleted by a call to SchedulerSession.deleteTimer: > public void deleteTimer(Timer timer) { > if (! deletedTimers.contains(timer)) { > try { > session.delete(timer); > deletedTimers.add(timer); > } catch (Exception e) { > log.error(e); > jbpmSession.handleException(); > throw new JbpmException("couldn't delete timer '"+timer+"' from the database", e); > } > } > } > but in SchedulerThread, the timer is saved again if timer.getRepeat() is not null: > public long executeTimers() { > long millisTillNextTimerIsDue = -1; > boolean isDueDateInPast = true; > > JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext(jbpmContextName); > try { > SchedulerSession schedulerSession = jbpmContext.getSchedulerSession(); > > log.debug("checking for timers"); > Iterator iter = schedulerSession.findTimersByDueDate(); > while( (iter.hasNext()) > && (isDueDateInPast) > ) { > Timer timer = (Timer) iter.next(); > log.debug("found timer "+timer); > > // if this timer is due > if (timer.isDue()) { > log.debug("executing timer '"+timer+"'"); > > // execute > timer.execute(); > > // save the process instance > jbpmContext.save(timer.getProcessInstance()); > > // notify the listeners (e.g. the scheduler servlet) > notifyListeners(timer); > > // if there was an exception, just save the timer > if (timer.getException()!=null) { > schedulerSession.saveTimer(timer); > > // if repeat is specified > } else if (timer.getRepeat()!=null) { > // update timer by adding the repeat duration > Date dueDate = timer.getDueDate(); > > // suppose that it took the timer runner thread a > // very long time to execute the timers. > // then the repeat action dueDate could already have passed. > while (dueDate.getTime()<=System.currentTimeMillis()) { > dueDate = businessCalendar > .add(dueDate, > new Duration(timer.getRepeat())); > } > timer.setDueDate( dueDate ); > // save the updated timer in the database > log.debug("saving updated timer for repetition '"+timer+"' in '"+(dueDate.getTime()-System.currentTimeMillis())+"' millis"); > schedulerSession.saveTimer(timer); > > } else { > // delete this timer > log.debug("deleting timer '"+timer+"'"); > schedulerSession.deleteTimer(timer); > } > } else { // this is the first timer that is not yet due > isDueDateInPast = false; > millisTillNextTimerIsDue = timer.getDueDate().getTime() - System.currentTimeMillis(); > } > } > > } finally { > jbpmContext.close(); > } > A work-around was suggested in JBPM-594: > "As workaround now I do remove timer myself in action just before calling signal(): > if(flag) { > //need to remove scheduler session as it is not removed during event with > //cancel-timer element > SchedulerSession schsession = ctx.getJbpmContext().getSchedulerSession(); > Timer timer=(Timer) schsession.findTimersByName("aaa",ctx.getToken()).get(0); > log.info("found timer:"+timer.getName()); > timer.setRepeat(null); > timer.setSuspended(true); > schsession.saveTimer(timer); > > ctx.getToken().signal("tonode1"); > } > " > However, this does not seem to be thread-safe as the call to findTimersByName sometimes returns a zero-length array and sometimes an exception if the work-around code to cancel the timer executes before the timer is available from the SchedulerSession (and this does happen even when the code to cancel the timer is within the ActionHandler of the timer) As a different work-around, I set the timer repeat to null in the SchedulerSession.deleteTimer method to ensure that it will not be saved again in the SchedulerThread.executeTimers method: > public void deleteTimer(Timer timer) { > if (! deletedTimers.contains(timer)) { > try { > session.delete(timer); > deletedTimers.add(timer); > //MWS 06/04/06 workaround to ensure that timer is deleted > timer.setRepeat(null); > } catch (Exception e) { > log.error(e); > jbpmSession.handleException(); > throw new JbpmException("couldn't delete timer '"+timer+"' from the database", e); > } > } > } > However, this causes an occasional exception to be thrown: > org.jbpm.persistence.JbpmPersistenceException: couldn't commit hibernate session > at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:171) > at org.jbpm.svc.Services.close(Services.java:211) > at org.jbpm.JbpmContext.close(JbpmContext.java:138) > at org.jbpm.scheduler.impl.SchedulerThread.executeTimers(SchedulerThread.java:161) > at org.jbpm.scheduler.impl.SchedulerThread.run(SchedulerThread.java:70) > Caused by: org.hibernate.StaleStateException: Unexpected row count: 0 expected: 1 > at org.hibernate.jdbc.NonBatchingBatcher.addToBatch(NonBatchingBatcher.java:27) > at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2204) > at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2118) > at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2374) > at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:84) > at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:243) > at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:227) > at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:141) > at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:296) > at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27) > at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:980) > at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:353) > On further investigation, it appears that on some occasions, when deleting a timer on a cancel-timer event, the call to session.getNamedQuery("SchedulerSession.findTimersByName") causes a hibernate flush to occur which attempts to update a timer that has already been deleted: > public void cancelTimersByName(String timerName, Token token) { > try { > Query query = session.getNamedQuery("SchedulerSession.findTimersByName"); > query.setString("timerName", timerName); > query.setEntity("token", token); > Iterator iter = query.list().iterator(); > while(iter.hasNext()) { > deleteTimer((Timer) iter.next()); > } > > } catch (Exception e) { > log.error(e); > jbpmSession.handleException(); > throw new JbpmException("couldn't delete timer '"+timerName+"' on '"+token+"' from the database", e); > } > } > I have some screenshots below to illustrate this but cannot include them in this form. The attempt to cancel the timer ?processing_error_task_timer? causes the following query to be issued: > <query name="SchedulerSession.findTimersByName"> > <![CDATA[ > select t > from org.jbpm.scheduler.exe.Timer t > where t.name = :timerName > and t.token = :token > ]]> > </query> > which in turn causes hibernate to flush and attempt to issue the SQL statement: > update JBPM_TIMER set NAME_=?, DUEDATE_=?, REPEAT_=?, TRANSITIONNAME_=?, EXCEPTION_=?, ISSUSPENDED_=?, ACTION_=?, TOKEN_=?, PROCESSINSTANCE_=?, TASKINSTANCE_=?, GRAPHELEMENTTYPE_=?, GRAPHELEMENT_=? where ID_=? > where the ID_ of the timer is that of a previous timer that has already been deleted from the database called ?credit_referral_task_timer? (I confirmed this by inspection of the JBPM_TIMER table). > I am at a loss to explain how the hibernate cache contains a timer that has already been deleted from the database. -- 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

17 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBPM-1058) Remove useless null checks from JbpmContext methods

by Thomas Diesler (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-1058?page=all ] Thomas Diesler updated JBPM-1058: --------------------------------- Assignee: (was: Tom Baeyens) > Remove useless null checks from JbpmContext methods > --------------------------------------------------- > > Key: JBPM-1058 > URL: http://jira.jboss.com/jira/browse/JBPM-1058 > Project: JBoss jBPM > Issue Type: Patch > Reporter: Johan Parent > > Remove useless null checks from often used methods to obtain: > /** > * more logging related database access. > */ > public LoggingSession getLoggingSession() { > PersistenceService persistenceService = getPersistenceService(); > return (persistenceService!=null ? persistenceService.getLoggingSession() : null); > } > /** > * more messaging related database access. > */ > public MessagingSession getMessagingSession() { > PersistenceService persistenceService = getPersistenceService(); > return (persistenceService!=null ? persistenceService.getMessagingSession() : null); > } > /** > * more scheduling related database access. > */ > public SchedulerSession getSchedulerSession() { > PersistenceService persistenceService = getPersistenceService(); > return (persistenceService!=null ? persistenceService.getSchedulerSession() : null); > } > /** > * more graph (process) related database access. > */ > public GraphSession getGraphSession() { > PersistenceService persistenceService = getPersistenceService(); > return (persistenceService!=null ? persistenceService.getGraphSession() : null); > } > /** > * more task related database access. > */ > public TaskMgmtSession getTaskMgmtSession() { > PersistenceService persistenceService = getPersistenceService(); > return (persistenceService!=null ? persistenceService.getTaskMgmtSession() : null); > } -- 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

17 years, 10 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

jbpm-issues June 2008