[JBoss JIRA] Created: (JBPM-2821) Adding a variable converter to jBPM is not intuitive and the documentation is lacking.
by Jochen Mader (JIRA)
Adding a variable converter to jBPM is not intuitive and the documentation is lacking.
--------------------------------------------------------------------------------------
Key: JBPM-2821
URL: https://jira.jboss.org/jira/browse/JBPM-2821
Project: jBPM
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.3
Reporter: Jochen Mader
To add …
[View More]a converter to jBPM it's currently required to add it in two places:
jbpm.variables.types.xml and jbpm.execution.hbm.xml
There are two issues with this:
1) I don't think it's a good approach to be required to edit two files to get the converter enabled.
2) The second file is an internal hibernate mapping file for jBPM and shouldn't be edited by a user for something as simple as adding a converter.
At the very least the whole thing should be added to the documentation.
Even better would be to enable converters by just adding them to jbpm.variables.types.xml
--
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
[View Less]
14 years, 9 months
[JBoss JIRA] Created: (JBPM-2809) Defer email sending until transaction is commited
by Peter Horvath (JIRA)
Defer email sending until transaction is commited
-------------------------------------------------
Key: JBPM-2809
URL: https://jira.jboss.org/jira/browse/JBPM-2809
Project: jBPM
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: jBPM 4.x
Reporter: Peter Horvath
Currently emails are sent immediately when they are dispatched from e.g. a mail node or task notification. This can …
[View More]be confusing since the transaction the JBPM execution runs in can be rolled back later.
For example a workflow could contain an initial email node which sends a confirmation email to the user who submitted a request ("Your request has been successfully submitted to the workflow system...") - but if the the next node in the workflow throws an exception which rolls back the transaction the submitted request won't be stored in the system. This can be very confusing for the end users. There are similar problems with task notifications as well.
I think it would be fairly easy to solve this problem by introducing an optional attribute to the mail node which instructs JBPM to send the email only on transaction commit and modify MailActivity so that it creates a transaction synchronization which sends the email from javax.transaction.Synchronization.afterCompletion(int status) method if the status is COMMITED.
--
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
[View Less]
14 years, 9 months
[JBoss JIRA] Created: (JBPM-2798) ID Generation for Oracle or DB2 Database when using out of the box JobExecutor causes Integrity Constraint violations with subprocesses
by Martin Porter (JIRA)
ID Generation for Oracle or DB2 Database when using out of the box JobExecutor causes Integrity Constraint violations with subprocesses
---------------------------------------------------------------------------------------------------------------------------------------
Key: JBPM-2798
URL: https://jira.jboss.org/jira/browse/JBPM-2798
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: …
[View More]Runtime Engine
Affects Versions: jBPM 4.3
Environment: WLS 11g, Oracle 11g, jBPM 4.3
Reporter: Martin Porter
When using jBPM in default configuration with out of the box JobExecutors (2 threads) we see issues with ID generation causing Integrity Constraint violations. There is a long thread related to this as also this behaviour has been seen with DB2 as well as Oracle. The link to the thread is:-
http://community.jboss.org/message/522625#522625
This seems to be related to the use of Subprocesses. It has been witnessed that removing the subprocesses solves the issue. Unfortunately we cannot do that.
We solved the issue by implementing our own ID generator using an Oracle Sequence. I have attached the code to this case. It would be nice to have this added to the trunk code if possible. We have been testing with it and it solved all of our problems.
Note that this was NOT running in cluster configuration and the problems occur on a single server instance with the default (non modifed) JobExecutor configuration.
Regards
martin
--
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
[View Less]
14 years, 9 months
[JBoss JIRA] Created: (JBPM-2789) Java task field injection works when java class is on the Spring context
by Robert Moskal (JIRA)
Java task field injection works when java class is on the Spring context
------------------------------------------------------------------------
Key: JBPM-2789
URL: https://jira.jboss.org/jira/browse/JBPM-2789
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.1
Environment: Nothing unusual, hsql, jetty.
Reporter: Robert …
[View More]Moskal
If I create a java task that pulls from the spring context, like so:
<java expr="#{pipelineNode}" g="300,79,92,52" method="execute" name="Rig">
<field name="execution"><object expr="#{execution}"/></field>
<field name="allowableFlows"><string value="NormalFlow2"/></field>
<transition g="-31,-28" name="success" to="Animate"/>
<transition g="303,252:-25,-32" name="to Rework" to="Rework"/>
</java>
Then none of the field injectors work. However if I change the definition to one where I instantiate using the class:
<java class="com.bluesky.skyline.workflow.extensions.PipelineNode" g="123,78,127,52" method="execute" name="Model">
<!--<field name="execution"><object expr="#{execution}"/></field>-->
<field name="allowableFlows"><string value="NormalFlow2"/></field>
<transition g="-31,-28" name="success" to="Rig"/>
<transition g="-24,-58" name="to Rework" to="Rework"/>
</java>
Then they work as expected. Whats' interesting is that in the latter case the Execution isn't injected.However, if I add the execution in an argument to my method:
<arg><object expr="#{execution}"/></arg>
Then it is passed in correctly. I suspect this has to do with the way the java code is stored with the process.
--
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
[View Less]
14 years, 9 months
[JBoss JIRA] Created: (JBPM-2783) refresh button doesn't wok in gwt-console application
by sunil tiwari (JIRA)
refresh button doesn't wok in gwt-console application
-----------------------------------------------------
Key: JBPM-2783
URL: https://jira.jboss.org/jira/browse/JBPM-2783
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Console
Affects Versions: jBPM 4.2
Environment: RAD7.5 , websphere server 6.1 , derby Data base , hibernate for DB connection
Reporter: sunil …
[View More]tiwari
I imported the gwt-console.war and gwt-console-server.war as web project in RAD 7.5 .
Now i ran the console application after login i can see the process definitions list in the process grid , if i add another process instance
using db explorer as i have an application which creates process instances and click on refresh button ideally that instance should come into the list
but nothing happens . Even if select one instance and terminate it or delete it i m able to see them in the list after click on refresh button .
--
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
[View Less]
14 years, 9 months
[JBoss JIRA] Created: (JBPM-2762) XML Schema Validation errors in jpdl files don't get reported when deploying them
by Erwin Bolwidt (JIRA)
XML Schema Validation errors in jpdl files don't get reported when deploying them
---------------------------------------------------------------------------------
Key: JBPM-2762
URL: https://jira.jboss.org/jira/browse/JBPM-2762
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jBPM 4.2, jBPM 4.3
Reporter: Erwin Bolwidt
When I deploy an invalid JPDL file (take a valid file, …
[View More]add <abc/> at some random location, voila) through the RepositoryService, the deployment succeeds. I can see that the validation error is reported internally, but an exception is not thrown.
It is also not possible for the caller to determine that there was a validation error, unless the caller is willing to cast NewDeployment to DeploymentImpl and invoke the methods from the ProblemList superclass.
The thing is, DeployerManager (line 49, jbpm 4.3) checks that there haven't been any errors using ProblemList#hasErrors(). And ProblemList#hasErrors() returns true if there is at least one problem with severity ProblemImpl.TYPE_ERROR. However, validation errors are reported with severity ProblemImpl.TYPE_XML_VALIDATION_ERROR.
Of course I don't know the reasons why the developer of this code choose this implementation, but to me it seems that this was an oversight and the hasErrors() should have checked for TYPE_XML_VALIDATION_ERROR as well.
I haven't had a chance yet to see how a process definition with an invalid jpdl file functions in practice, but it doesn't seem right that you can deploy an incorrect process definition.
And if it was right, for some reason, then I think the caller should have a chance to find out, so in that case the interface NewDeployment could be extended with methods to retrieve any problems during deployment.
--
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
[View Less]
14 years, 9 months
[JBoss JIRA] Created: (JBPM-2763) jBPM 4.3 - InitialContext is not closed after being used for JNDI Lookup (Multiple classes)
by Martin Porter (JIRA)
jBPM 4.3 - InitialContext is not closed after being used for JNDI Lookup (Multiple classes)
-------------------------------------------------------------------------------------------
Key: JBPM-2763
URL: https://jira.jboss.org/jira/browse/JBPM-2763
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.3
Reporter: Martin Porter
In …
[View More]various classes when an InitialContext is created it is not closed before the method returns. The following classes have this issue:-
org.jboss.bpm.console.server.util.InvocationProxy
org.jbpm.jpdl.internal.activity.JavaActivity
org.jbpm.jpdl.internal.activity.JmsActivity
org.jbpm.pvm.internal.cfg.ConfigurationImpl
org.jbpm.pvm.internal.processengine.ProcessEngineImpl
org.jbpm.pvm.internal.tx.JtaTransaction
org.jbpm.pvm.internal.wire.descriptor.JbossIdmIdentitySessionFactoryDescriptor
org.jbpm.pvm.internal.wire.descriptor.JndiDescriptor
Hence this will result in memory leaks and also issues with hot deployment for EAR's containing the process engine.
--
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
[View Less]
14 years, 9 months