[JBoss JIRA] Created: (JBPM-2517) Timer with due date set > 24 days in jPDL process definition will cause the timer to be set in the past
by Tobias Groothuyse (JIRA)
Timer with due date set > 24 days in jPDL process definition will cause the timer to be set in the past
-------------------------------------------------------------------------------------------------------
Key: JBPM-2517
URL: https://jira.jboss.org/jira/browse/JBPM-2517
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.0
Reporter: Tobias Groothuyse
I have a process with
<time duedate="5 weeks"/>
However when this timer gets instantiated in a running process it's actual duedate which is calculated is in the past. I traced this bug to the following piece of code:
TimerImpl.class
{code}
} else {
long millis = duration.getMillis() +
1000*( duration.getSeconds() +
60*( duration.getMinutes() +
60*( duration.getHours() +
24*( duration.getDays() +
7*duration.getWeeks()))));
dueDate = new Date(now.getTime() + millis);
}
{code}
Because all the fields from the duration object are of type int, when duration.getDays() is larger then 24 or a weeks larger than 4 for that matter an int overflow will occur and long millis will have a negative value.
It is probably best to use the normale calendar operations in all cases to add intervals to the current systime.
--
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, 10 months
[JBoss JIRA] Created: (JBPM-2626) Console login fails on tomcat
by Heiko Braun (JIRA)
Console login fails on tomcat
-----------------------------
Key: JBPM-2626
URL: https://jira.jboss.org/jira/browse/JBPM-2626
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Console
Affects Versions: jBPM 4.2
Reporter: Heiko Braun
Fix For: jBPM 4.2
The actual reason is that the gwt-console-server module doesn't deploy:
catalina out:
INFO: Deploying web application archive gwt-console-server.war
log4j:WARN No appenders could be found for logger (org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap).
log4j:WARN Please initialize the log4j system properly.
Nov 4, 2009 3:40:11 PM org.apache.catalina.core.StandardContext start
SEVERE: Error listenerStart
Nov 4, 2009 3:40:11 PM org.apache.catalina.core.StandardContext start
SEVERE: Context [/gwt-console-server] startup failed due to previous errors
tomcat logs:
Nov 4, 2009 3:40:11 PM org.apache.catalina.core.StandardContext listenerStart
SEVERE: Exception sending context initialized event to listener instance of class org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap
java.lang.NullPointerException
at org.jboss.bpm.report.JMXServerConfig.getServerDataDir(JMXServerConfig.java:88)
at org.jboss.bpm.report.ReportFacade.initBirtService(ReportFacade.java:87)
at org.jboss.bpm.report.ReportFacade.<init>(ReportFacade.java:71)
at org.jboss.bpm.console.server.ConsoleServerApplication.<init>(ConsoleServerApplication.java:48)
--
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, 11 months
[JBoss JIRA] Created: (JBPM-2047) PersistenceDbServiceTest and PersistenceServiceDbTest are dependent
by Jiri Pechanec (JIRA)
PersistenceDbServiceTest and PersistenceServiceDbTest are dependent
-------------------------------------------------------------------
Key: JBPM-2047
URL: https://jira.jboss.org/jira/browse/JBPM-2047
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Core Engine
Affects Versions: jBPM-3.2.5.SP1
Reporter: Jiri Pechanec
Assignee: Thomas Diesler
The tests can fail based on the execution order of these tests.
If PersistenceDbServiceTest is executed first then it sets session factory to MockSessionFactory.
Unfortunately it seems that the setting is SAME for ALL future newly created JbpmContexts.
PersistenceServiceDbTest then tests that the factory is null but it is not assertNull(persistenceServiceFactory.sessionFactory). The same test also tests few more features that ends in calls of unsupported operations on the MockSessionFactory.
I am not sure if this is a problem of test - then the sessionFactory should be cleard after test or if it is wrong that the setting is shared for all JBpmContexts.
--
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, 11 months
[JBoss JIRA] Created: (JBPM-1707) pageflow parsing is slow
by Alejandro Guizar (JIRA)
pageflow parsing is slow
------------------------
Key: JBPM-1707
URL: https://jira.jboss.org/jira/browse/JBPM-1707
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Core Engine
Affects Versions: jBPM 3.2.3
Environment: Red Hat Enterprise Linux AS release 4 (Nahant Update 7)
enterprise-installer-4.3.0.GA-1.ep1.8.jar
jdk-1.5.0_16-fcs
Reporter: Alejandro Guizar
Assignee: Alejandro Guizar
Fix For: jBPM 3.3.0 CR1
On a RHEL machine, while deploying a seam based ear, which contains 13 pageflow definitions, the parsing of these 13 pageflow files takes more than 34 minutes (!).
The culprit seems to be the usage of the original systemId (http://jboss.com/products/seam/pageflow-2.0.xsd) in the org.jbpm.jdpl.xml.JpdlParser$JpdlEntityResolver class, as this
apparently results in slow internet lookups:
log.debug("original systemId as input source");
inputSource = new InputSource(systemId);
Using a null InputSource:
inputSource = new InputSource((InputStream)null);
brings the parsing time down to less than 1 second.
Of course it would be better to actually pass in a reference to the local pageflow-2.0.xsd file, which is inside the jboss-seam.jar.
--
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, 11 months