November 2008 - jbpm-issues - Jboss List Archives

[JBoss JIRA] Updated: (JBPM-1056) CompositeCommand misimplementation

by Thomas Diesler (JIRA)

[ https://jira.jboss.org/jira/browse/JBPM-1056?page=com.atlassian.jira.plug... ] Thomas Diesler updated JBPM-1056: --------------------------------- Fix Version/s: jBPM 3.3.2 GA Revisit open bugs > CompositeCommand misimplementation > ---------------------------------- > > Key: JBPM-1056 > URL: https://jira.jboss.org/jira/browse/JBPM-1056 > Project: JBoss jBPM > Issue Type: Bug > Components: Core Engine > Affects Versions: jBPM 3.1.0, jBPM 3.1.1, jBPM 3.1.2, jBPM 3.1.3, jBPM 3.1.4, jBPM 3.2.0, jBPM 3.2.1, jBPM 3.2.2 > Reporter: Edward Staub > Fix For: jBPM 3.3.2 GA > > > CompositeCommand doesn't copy fields from one command to the next, as I THINK is intended. > This was reported in > http://www.jboss.com/index.html?module=bb&op=viewtopic&t=90146&postdays=0... > on October 11 2006 at 11:23 AM., along with a proposed fix. But it was never JIRA'd and never fixed. > Secondarily... AFAIK, there is not one word of documentation (example, test, javadoc, anything) explaining how CompositeCommand is supposed to work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (JBPM-893) JBPM_VARIABLEINSTANCE.STRINGVALUE_ is inconsistent with JBPM_LOG.OLDSTRINGVALUE_ and JBPM_LOG.NEWSTRINGVALUE_

by Thomas Diesler (JIRA)

[ https://jira.jboss.org/jira/browse/JBPM-893?page=com.atlassian.jira.plugi... ] Thomas Diesler updated JBPM-893: -------------------------------- Fix Version/s: jBPM 3.3.2 GA Revisit open bugs > JBPM_VARIABLEINSTANCE.STRINGVALUE_ is inconsistent with JBPM_LOG.OLDSTRINGVALUE_ and JBPM_LOG.NEWSTRINGVALUE_ > ------------------------------------------------------------------------------------------------------------- > > Key: JBPM-893 > URL: https://jira.jboss.org/jira/browse/JBPM-893 > Project: JBoss jBPM > Issue Type: Bug > Components: Core Engine > Affects Versions: jBPM 3.1.4 > Environment: JBoss AS 4.0.5 GA + jBPM 3.1.4 + RHEL 4 + Oracle 10g > Reporter: Romeu Figueira > Priority: Minor > Fix For: jBPM 3.3.2 GA > > Original Estimate: 5 minutes > Remaining Estimate: 5 minutes > > The column JBPM_VARIABLEINSTANCE.STRINGVALUE_ is slated as VARCHAR2(255 char) while JBPM_LOG.OLDSTRINGVALUE_ and JBPM.NEWSTRINGVALUE_ are slated as VARCHAR2(4000). > These two values should be a match between each other. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (JBPM-1062) Serializable filter should be last in default jbpm.varmapping.xml

by Thomas Diesler (JIRA)

[ https://jira.jboss.org/jira/browse/JBPM-1062?page=com.atlassian.jira.plug... ] Thomas Diesler updated JBPM-1062: --------------------------------- Fix Version/s: jBPM 3.3.2 GA Revisit open bugs > Serializable filter should be last in default jbpm.varmapping.xml > ----------------------------------------------------------------- > > Key: JBPM-1062 > URL: https://jira.jboss.org/jira/browse/JBPM-1062 > Project: JBoss jBPM > Issue Type: Bug > Affects Versions: jBPM 3.2.2 > Reporter: Marcus Schmidke > Fix For: jBPM 3.3.2 GA > > > In 3.2.2 there are again some entries behind the Serializable Type mapping (see #JBPM-748). I think, Serializable should always be last. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (JBPM-1081) Simulation query with stddev not supported on HSQL

by Thomas Diesler (JIRA)

[ https://jira.jboss.org/jira/browse/JBPM-1081?page=com.atlassian.jira.plug... ] Thomas Diesler updated JBPM-1081: --------------------------------- Fix Version/s: jBPM 3.3.2 GA Revisit open bugs > Simulation query with stddev not supported on HSQL > -------------------------------------------------- > > Key: JBPM-1081 > URL: https://jira.jboss.org/jira/browse/JBPM-1081 > Project: JBoss jBPM > Issue Type: Bug > Components: Simulation > Affects Versions: jBPM 3.2.3 > Environment: N/A > Reporter: Ronald van Kuijk > Fix For: jBPM 3.3.2 GA > > > According to a user in the forum, stddev is not supported in the HSQLDialect on the hibernate version that comes with jBPM. I have not had the opportunity to verify this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (JBPM-987) display non GMT+0 time zones

by Thomas Diesler (JIRA)

[ https://jira.jboss.org/jira/browse/JBPM-987?page=com.atlassian.jira.plugi... ] Thomas Diesler updated JBPM-987: -------------------------------- Fix Version/s: jBPM 3.3.2 GA Revisit open bugs > display non GMT+0 time zones > ---------------------------- > > Key: JBPM-987 > URL: https://jira.jboss.org/jira/browse/JBPM-987 > Project: JBoss jBPM > Issue Type: Bug > Components: Console > Affects Versions: jBPM 3.2.0, jBPM 3.2.1 > Reporter: Jean-Louis Rastapoc > Fix For: jBPM 3.3.2 GA > > > The web-console currently uses the default JSF timezone conversion and displays GMT+0. > Other time zones should be read from the client or be configurable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (JBPM-1039) OutOfMemoryError While using multi h:selectOneRaido in dataform with multy columns

by Thomas Diesler (JIRA)

[ https://jira.jboss.org/jira/browse/JBPM-1039?page=com.atlassian.jira.plug... ] Thomas Diesler updated JBPM-1039: --------------------------------- Fix Version/s: jBPM 3.3.2 GA Revisit open bugs > OutOfMemoryError While using multi h:selectOneRaido in dataform with multy columns > ---------------------------------------------------------------------------------- > > Key: JBPM-1039 > URL: https://jira.jboss.org/jira/browse/JBPM-1039 > Project: JBoss jBPM > Issue Type: Bug > Components: Console > Affects Versions: jBPM 3.2.1 > Environment: jBPM 3.2.1 Tomcat 6.0.14 > Reporter: zhou guangzhao > Priority: Minor > Fix For: jBPM 3.3.2 GA > > > The following taskform code works in JBPM3.2.GA. > But when running in JBPM 3.2.1, it causes OutOfMemoryError. By testing, I found that if I change <jbpm:dataform columns="2"> to <jbpm:dataform>, it will work well in both JBPM3.2.GA and JBPM3.2.1. > Sometimes it maybe works in JBPM3.2.1. But while adding more h:selectOneRadio, I get the error. > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" > >  > <html xmlns="http://www.w3.org/1999/xhtml" > xmlns:ui="http://java.sun.com/jsf/facelets" > xmlns:c="http://java.sun.com/jstl/core" > xmlns:h="http://java.sun.com/jsf/html" > xmlns:f="http://java.sun.com/jsf/core" > xmlns:tf="http://jbpm.org/jsf/tf" > xmlns:jbpm="http://jbpm.org/jsf"> > <ui:component> > <jbpm:dataform columns="2"> > > <f:facet name="header"> > <h:outputText value="#{taskName}"/> > </f:facet> > >  > <jbpm:datacell> > <f:facet name="header"> > <h:outputText value="Sex"/> > </f:facet> > <h:selectOneRadio id="StudentSex" value="#{var['StudentSex']}"> > <f:selectItem itemLabel="Male" itemValue="Male"/> > <f:selectItem itemLabel="Female" itemValue="Female"/> > </h:selectOneRadio> > </jbpm:datacell> > <jbpm:datacell> > <f:facet name="header"> > <h:outputText value="HasAS"/> > </f:facet> > <h:selectOneRadio id="HasAS" value="#{var['HasAS']}" > > <f:selectItem itemLabel="Yes" itemValue="Yes"/> > <f:selectItem itemLabel="No" itemValue="No"/> > </h:selectOneRadio> > </jbpm:datacell> > > <jbpm:datacell> > <f:facet name="header"> > <h:outputText value="Actions"/> > </f:facet> >  > <tf:saveButton value="Save"/> > <tf:cancelButton value="Cancel"/> > <tf:transitionButton value="Save and Close"/> > </jbpm:datacell> > > </jbpm:dataform> > > </ui:component> > </html> > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (JBPM-1082) process start interval calculation is not correct and limited to special databases

by Thomas Diesler (JIRA)

[ https://jira.jboss.org/jira/browse/JBPM-1082?page=com.atlassian.jira.plug... ] Thomas Diesler updated JBPM-1082: --------------------------------- Fix Version/s: jBPM 3.3.2 GA Revisit open bugs > process start interval calculation is not correct and limited to special databases > ---------------------------------------------------------------------------------- > > Key: JBPM-1082 > URL: https://jira.jboss.org/jira/browse/JBPM-1082 > Project: JBoss jBPM > Issue Type: Bug > Components: Simulation > Affects Versions: jBPM 3.2.2 > Reporter: Bernd Ruecker > Fix For: jBPM 3.3.2 GA > > > See Forum. > The date interval calculation is right now only tested with mySQL. And even there I got wrong results... > By the way, this may be somehow to http://jira.jboss.com/jira/browse/JBPM-1080 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (JBPM-826) Incorrect action exception handling

by Thomas Diesler (JIRA)

[ https://jira.jboss.org/jira/browse/JBPM-826?page=com.atlassian.jira.plugi... ] Thomas Diesler updated JBPM-826: -------------------------------- Fix Version/s: jBPM 3.3.2 GA Revisit open bugs > Incorrect action exception handling > ----------------------------------- > > Key: JBPM-826 > URL: https://jira.jboss.org/jira/browse/JBPM-826 > Project: JBoss jBPM > Issue Type: Bug > Components: Core Engine > Affects Versions: jBPM 3.1.3 > Environment: Eclipse + Tomcat + JDK 6.0 > Reporter: Pedro Silva > Priority: Critical > Fix For: jBPM 3.3.2 GA > > > If an action in a process definition throws an exception it doesn't correctly reach the client class, e.g. the class doing the signalling. > Imagine that you have a process definition that in one of the task as an action that opens a file for reading. If the file cannot be found there will be an exception. Te exception is thrown and when it reaches the class, where the code for signalling is, you can't see the exception message. If you try to do, in the catch block, System.err.println(e.getMessage()) the result is null! However if you print System.err.println(e.getCause().getMessage()) the result is the file not found exception. > This is worst in the case when you caught the exception in the action delegated class and you throw your own exception by explicitly doing: throw new MyException("Some error"); and the message still is null. > In the case where the exception occurs in another class than the one of the action (if the execute code of the action invokes another class), even the code System.err.println(e.getCause().getMessage()) outputs null. > The documentattion clearly states in 9.7 Exception Handling: > "...Uncaught exceptions are thrown to the client (e.g. the client that called the token.signal()) or the exception is caught by a jBPM exception-handler. ..." -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (JBPM-1114) If a node is set to async the console does not seem to report which node has the focus in the process.

by Kurt Stam (JIRA)

If a node is set to async the console does not seem to report which node has the focus in the process. ------------------------------------------------------------------------------------------------------ Key: JBPM-1114 URL: http://jira.jboss.com/jira/browse/JBPM-1114 Project: JBoss jBPM Issue Type: Bug Reporter: Kurt Stam Assigned To: Tom Baeyens Priority: Minor Attachments: async=true on all nodes..jpg I'm deploying 1 jPDL with all nodes having the attribute async="true" and one where I left the node synchronous. When I now start the a process instance the async one does not show a focus on the "Review Order" while the other one does. See the attached screenshots. -- 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

16 years, 1 month

3
6
0 / 0

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

by Thomas Diesler (JIRA)

[ https://jira.jboss.org/jira/browse/JBPM-1008?page=com.atlassian.jira.plug... ] Thomas Diesler updated JBPM-1008: --------------------------------- Fix Version/s: jBPM 3.3.2 GA Revisit open bugs > ejb deployment : avoid ClassNotFoundException on client side after unmarshalling > --------------------------------------------------------------------------------- > > Key: JBPM-1008 > URL: https://jira.jboss.org/jira/browse/JBPM-1008 > Project: JBoss jBPM > Issue Type: Bug > Affects Versions: jBPM 3.2.1 > Environment: enterprise jBPM > Reporter: Adrian Dimulescu > Fix For: jBPM 3.3.2 GA > > > 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: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbpm-issues November 2008