[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 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
14 years, 5 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, 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
14 years, 5 months
[JBoss JIRA] Created: (JBPM-2768) Provide API for accessing JBPM email infrastructure
by Peter Horvath (JIRA)
Provide API for accessing JBPM email infrastructure
---------------------------------------------------
Key: JBPM-2768
URL: https://jira.jboss.org/jira/browse/JBPM-2768
Project: jBPM
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: jBPM 4.x
Reporter: Peter Horvath
Currently there is no way to access JBPM email infrastructure from custom Java code (for example from an EventListener, or ActivityBehaviour)
It would be good to be able to access JBPM email subsystem through a public API.
Adding a new Facade class with a single method that allows you to select the email template and pass an org.jbpm.api.Execution should be quite easy to implement and would add a lot of power to EventListeners, etc.
--
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
14 years, 5 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 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
14 years, 5 months
[JBoss JIRA] Created: (JBPM-2682) Add problem specific exception sub-classes
by Peter Horvath (JIRA)
Add problem specific exception sub-classes
------------------------------------------
Key: JBPM-2682
URL: https://jira.jboss.org/jira/browse/JBPM-2682
Project: jBPM
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.x
Reporter: Peter Horvath
Currently error conditions are signaled using a single exception type, JbpmException.
Using problem specific exception subclasses would make it possible for the client code to deal with different error conditions differently .
Example - current GetOutcomes command implementation:
package org.jbpm.pvm.internal.cmd;
...
public class GetOutcomes implements Command<Set<String>> {
...
public Set<String> execute(Environment environment) {
DbSession dbSession = environment.get(DbSession.class);
TaskImpl task = dbSession.get(TaskImpl.class, Long.parseLong(taskId));
if (task==null) {
throw new JbpmException("task "+taskId+" doesn't exist");
}
...
Introducing problem specific exception subclasses would allow client code to handle errors much better; for example if a custom TaskDoesNotExistException (public class TaskDoesNotExistException extends JbpmException) was thrown in GetOutcomes.execute when a task is not found, then the caller code would be able to distinguish this problem from say a transient database connectivity problem. It could display a user friendly error message rather than showing a generic error message etc:
public Set<String> execute(Environment environment) {
DbSession dbSession = environment.get(DbSession.class);
TaskImpl task = dbSession.get(TaskImpl.class, Long.parseLong(taskId));
if (task==null) {
throw new TaskDoesNotExistException("task "+taskId+" doesn't exist");
}
The same approach for process instances, executions, variables, etc. could be used to allow building robust client code.
--
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
14 years, 5 months
[JBoss JIRA] Created: (JBPM-2625) Add count() to Queries to support pagination
by Peter Horvath (JIRA)
Add count() to Queries to support pagination
--------------------------------------------
Key: JBPM-2625
URL: https://jira.jboss.org/jira/browse/JBPM-2625
Project: jBPM
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.x
Reporter: Peter Horvath
Queries provide a powerful interface to access JBPM tasks, jobs, deployments, etc;
currently the only way you can get the number of results that match a filter is to load the whole list, and determine its size by calling .size() method - this is extremely inefficient and can even cause OutOfMemoryError (e.g. a HistoryActivityInstanceQuery could return tens of thousands elements)
count() could be used with page(int firstResult, int maxResults) method to create a paginated result list where you can display the number of pages
--
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
14 years, 5 months
[JBoss JIRA] Created: (JBPM-2636) NPE in Configuration.getProcessEngine() when using jbpm.jbossremote.cfg.xml
by Mark Roy (JIRA)
NPE in Configuration.getProcessEngine() when using jbpm.jbossremote.cfg.xml
---------------------------------------------------------------------------
Key: JBPM-2636
URL: https://jira.jboss.org/jira/browse/JBPM-2636
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jBPM 4.2
Environment: Windows XP, JDK 6, JBoss, Oracle 10g
Reporter: Mark Roy
In jBPM 4.1, using the following jbpm.cfg.xml in my simple test app worked:
Code:
<jbpm-configuration>
<import resource="jbpm.jbossremote.cfg.xml" />
</jbpm-configuration>
Since upgrading to 4.2, however, I now get a NPE:
Code:
java.lang.NullPointerException
at org.jbpm.pvm.internal.cfg.ProcessEngineImpl.checkDb(ProcessEngineImpl.java:177)
at org.jbpm.pvm.internal.cfg.ProcessEngineImpl.buildProcessEngine(ProcessEngineImpl.java:170)
at org.jbpm.api.Configuration.getProcessEngine(Configuration.java:161)
at org.jbpm.test.JbpmTestCase.initialize(JbpmTestCase.java:81)
at org.jbpm.test.JbpmTestCase.setUp(JbpmTestCase.java:76)
at com.mydomain..ReviewProcess.setUp(ReviewProcess.java:24)
at junit.framework.TestCase.runBare(TestCase.java:132)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:13
0)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
I traced this to the fact the userCommandService is assigned null from the following:
Code:
userCommandService = (CommandService) processEngineWireContext.get(CommandService.NAME_TX_REQUIR
ED_COMMAND_SERVICE);
This problem can be easily reproduced using the examples included in the distribution.
--
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
14 years, 5 months
[JBoss JIRA] Created: (JBPM-2900) Timer expression does not accept EL expression that returns a duration string value
by Nugroho Saputro (JIRA)
Timer expression does not accept EL expression that returns a duration string value
-----------------------------------------------------------------------------------
Key: JBPM-2900
URL: https://jira.jboss.org/browse/JBPM-2900
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.4
Reporter: Nugroho Saputro
There is a problem on JBPM 4.4 snapshot when using EL expression #{provisioningService.checkStatusDelay} that return a duration string like "2 minutes" as timer expression.
Previously on JBPM 4.3, the EL gets evaluated correctly and timer works as expected but I get the following error on 4.4 snapshot.
09:15:26,535 ERROR [ExecuteJobCmd:42] exception while executing 'ExecuteActivityMessage[59]'
org.jbpm.api.JbpmException: Invalid basedate type: #{provisioningService.checkStatusDelay} is of type java.lang.String. Only Date and Calendar are supported
at org.jbpm.pvm.internal.cal.Duration.calculateDueDate(Duration.java:131)
at org.jbpm.pvm.internal.job.TimerImpl.setDueDateDescription(TimerImpl.java:75)
at org.jbpm.pvm.internal.model.ScopeInstanceImpl.createTimer(ScopeInstanceImpl.java:305)
at org.jbpm.pvm.internal.model.ScopeInstanceImpl.initializeTimers(ScopeInstanceImpl.java:334)
at org.jbpm.pvm.internal.model.ExecutionImpl.createScope(ExecutionImpl.java:264)
at org.jbpm.pvm.internal.model.op.TransitionStartActivity.perform(TransitionStartActivity.java:82)
at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperationSync(ExecutionImpl.java:671)
at org.jbpm.pvm.internal.model.op.ExecuteActivityMessage.execute(ExecuteActivityMessage.java:46)
at org.jbpm.pvm.internal.cmd.ExecuteJobCmd.execute(ExecuteJobCmd.java:76)
at org.jbpm.pvm.internal.cmd.ExecuteJobCmd.execute(ExecuteJobCmd.java:42)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months