[JBoss JIRA] Created: (JBPM-741) JbpmSchedulerThread does not terminate the scheduler/command threads properly
by Alejandro Guizar (JIRA)
JbpmSchedulerThread does not terminate the scheduler/command threads properly
-----------------------------------------------------------------------------
Key: JBPM-741
URL: http://jira.jboss.com/jira/browse/JBPM-741
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM 3.1.1
Reporter: Alejandro Guizar
Fix For: jBPM 3.1.3
The implementation of SchedulerThread and CommandExecutorThread in 3.1.1 does not provide a mechanism to exit the run() method, allowing the Thread to exit properly and release any resources it is holding.
This becomes an issue for perm gen in JBoss AS and other containers.
For SchedulerThread, keepRunning (bool) should be public or provide mutators, so whatever launches the Thread can modify it.
For CommandExecutorThread, the while(true) in run() should be changed to something like SchedulerThread uses and, of course, provide mutators to the loop control variable.
--
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
18 years, 3 months
[JBoss JIRA] Commented: (JBPM-345) persisting process definition with superstate hibernate problems
by Dimitar Marinov (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-345?page=comments#action_12345024 ]
Dimitar Marinov commented on JBPM-345:
--------------------------------------
A simple modification in the ProcessDefinition.hbm.xml file soved the problem for me. Just replace
<list name="nodes" cascade="all">
with
<list name="nodes" cascade="all" where="SUPERSTATE_ is null">
after that ProcessDefinitions include only nodes which don't belong to any SuperState.
Best regards,
Dimitar Marinov
> persisting process definition with superstate hibernate problems
> ----------------------------------------------------------------
>
> Key: JBPM-345
> URL: http://jira.jboss.com/jira/browse/JBPM-345
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Core Engine
> Affects Versions: jBPM 3.0.1
> Reporter: James Depoorter
> Assigned To: Tom Baeyens
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> When persisting a process definition with superstates and reloading, hibernate has trouble loading "root" nodes mixed with superstates. The superstate 'overwrites' the link. This is due to the re-use of the collectionindex column for both nodes within superstates, and nodes within process definition, and the fact that EVERY node has a link to the process definition.
--
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
18 years, 3 months
[JBoss JIRA] Resolved: (JBXB-33) Util Class: Util method to pass a StringList/SchemaBindingResolver/Error Handler
by Thomas Diesler (JIRA)
[ http://jira.jboss.com/jira/browse/JBXB-33?page=all ]
Thomas Diesler resolved JBXB-33.
--------------------------------
Resolution: Out of Date
> Util Class: Util method to pass a StringList/SchemaBindingResolver/Error Handler
> ---------------------------------------------------------------------------------
>
> Key: JBXB-33
> URL: http://jira.jboss.com/jira/browse/JBXB-33
> Project: JBoss XML Binding (JBossXB)
> Issue Type: Feature Request
> Reporter: Anil Saldhana
> Assigned To: Alexey Loubyansky
>
> This is a feature request from JBoss Web Services Tools.
> In order for me to migrate the parsing of multiple schema files to the JBossXB layer, I need the following method in the Util class:
> public static XSModel loadSchema(StringList xsdList, SchemaBindingResolver schemaResolver,SchemaBindingErrorHandler schemaErrorHandler)
> Note: SchemaBindingErrorHandler can be a JBossXB class that internally holds org.apache.xerces.xni.parser.XMLErrorHandler as an implementation detail.
>
> I did test the following method:
> ===========================================================================
> /**
> * Loads a Xerces based Schema Model provided a list of Strings representing
> * schema files. Also a SchemaBindingResolver can be passed to the parser.
> * @param xsdURL
> * @param schemaResolver
> * @return
> */
> public static XSModel loadSchema(StringList xsdList, SchemaBindingResolver schemaResolver)
> {
> XSImplementation impl = getXSImplementation();
> XSLoader schemaLoader = impl.createXSLoader(null);
> if(schemaResolver != null)
> {
> setResourceResolver(schemaLoader, schemaResolver);
> }
> XSModel model = schemaLoader.loadURIList(xsdList);
> if(model == null)
> {
> throw new IllegalArgumentException("Invalid schema");
> }
> return model;
> }
> ======================================================
> I did not make the change because I need to pass an instance of org.apache.xerces.xni.parser.XMLErrorHandler to the Xerces parsers
> and I felt that you would be able to find a better way of passing an error handler to the parsers (while hiding the Xerces details like
> XMLErrorHandler as an implementation detail).
--
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
18 years, 3 months
[JBoss JIRA] Created: (JBPM-696) Field Instanciator problems
by Shai Bentin (JIRA)
Field Instanciator problems
---------------------------
Key: JBPM-696
URL: http://jira.jboss.com/jira/browse/JBPM-696
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM 3.1.1
Environment: WinXP, Linux running on JBoss Application Server 4.0.3SP1, JDK1.5.0_06
Reporter: Shai Bentin
Assigned To: Tom Baeyens
Priority: Minor
Fix For: jBPM 3.1.2
The method getValue() is see two problems, one is jdk5 related the other is just an idea.
In jdk5 doing if (type.isAssignableFrom(Set.class)) and such yields a 'false' even when it is supposed to be true...
if we would write the same if in reverse:
Set.class.isAssignableFrom(type) we will ge the desired reuslt.
The other issue is, if we know the super type why do we impose a specific implementation, i.e. if we have a Collection, why do we impose an ArrayList. We have the user's type and we know it is of type collection so why don't we instanciate the requested type....
Here is how I propose to write this method:
public static Object getValue(Class type, Element propertyElement) {
// parse the value
Object value = null;
try {
if ( type == String.class ) {
value = propertyElement.getText();
} else if ( (type==Integer.class) || (type==int.class) ) {
value = new Integer( propertyElement.getTextTrim() );
} else if ( (type==Long.class) || (type==long.class) ) {
value = new Long( propertyElement.getTextTrim() );
} else if ( (type==Float.class ) || (type==float.class) ) {
value = new Float( propertyElement.getTextTrim() );
} else if ( (type==Double.class ) || (type==double.class) ) {
value = new Double( propertyElement.getTextTrim() );
} else if ( (type==Boolean.class ) || (type==boolean.class) ) {
value = Boolean.valueOf( propertyElement.getTextTrim() );
} else if ( (type==Character.class ) || (type==char.class) ) {
value = new Character( propertyElement.getTextTrim().charAt(0) );
} else if ( (type==Short.class ) || (type==short.class) ) {
value = new Short( propertyElement.getTextTrim() );
} else if ( (type==Byte.class ) || (type==byte.class) ) {
value = new Byte( propertyElement.getTextTrim() );
} else if (List.class.isAssignableFrom(type)) {
value = getCollection(propertyElement, (List)type.newInstance());
} else if (Set.class.isAssignableFrom(type)) {
value = getCollection(propertyElement, (Set)type.newInstance());
} else if (Collection.class.isAssignableFrom(type)) {
value = getCollection(propertyElement, (Collection)type.newInstance());
} else if (Map.class.isAssignableFrom(type)) {
value = getMap(propertyElement, (Map)type.newInstance());
} else if ( type==Element.class ) {
value = propertyElement;
} else {
Constructor constructor = type.getConstructor(new Class[]{String.class});
if ( (propertyElement.isTextOnly())
&& (constructor!=null) ) {
value = constructor.newInstance(new Object[]{propertyElement.getTextTrim()});
}
}
} catch (Exception e) {
log.error("couldn't parse the bean property value '" + propertyElement.asXML() + "' to a '" + type.getName() + "'" );
throw new JbpmException( e );
}
return value;
}
--
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
18 years, 3 months
[JBoss JIRA] Created: (JBPM-758) DbPersistenceService needs update for new Hibernate version
by Thomas Klute (JIRA)
DbPersistenceService needs update for new Hibernate version
-----------------------------------------------------------
Key: JBPM-758
URL: http://jira.jboss.com/jira/browse/JBPM-758
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM 3.1.2
Environment: jboss AS 4.0.4, hibernate 3.1 or hibernate 3.2
Reporter: Thomas Klute
Assigned To: Tom Baeyens
Fix For: jBPM 3.1.3
Release of JDBC connections changed with hibernate version > 3.0.
DbPersistenceService now throws exception when trying to close a hibernate session (because in was closed automatically when the transaction committed).
The exception happens every few seconds when using the jbpm scheduler-service.
See below for stack trace.
See http://www.hibernate.org/250.html#A31 for a detailed description of hibernate-changes regarding JDBC connections.
FYI: The exception does not roll back the transaction, because it has already been committed.
Please adapt the code to the new hibernate behaviour. Maybe just comment out the "throw" of the exception.
I have no idea what code would work with old _and_ new hibernate versions.
We just got the problem integrating jbpm into a jboss AS 4.0.4 using hibernate 3.2.
...
2006-09-28 16:11:53,996 DEBUG [org.jbpm.persistence.db.DbPersistenceService] creating hibernate session
2006-09-28 16:11:53,998 DEBUG [org.hibernate.jdbc.JDBCContext] TransactionFactory reported no active transaction; Synchronization not registered
2006-09-28 16:11:53,998 DEBUG [org.hibernate.impl.SessionImpl] opened session at timestamp: 4749118316527616
2006-09-28 16:11:53,998 DEBUG [org.jbpm.persistence.db.DbPersistenceService] beginning hibernate transaction
2006-09-28 16:11:53,998 DEBUG [org.hibernate.transaction.JTATransaction] Looking for UserTransaction under: UserTransaction
2006-09-28 16:11:53,999 DEBUG [org.hibernate.transaction.JTATransaction] Obtained UserTransaction
2006-09-28 16:11:53,999 DEBUG [org.hibernate.transaction.JTATransaction] begin
2006-09-28 16:11:54,000 DEBUG [org.hibernate.transaction.JTATransaction] Began a new JTA transaction
2006-09-28 16:11:54,000 DEBUG [org.hibernate.jdbc.JDBCContext] successfully registered Synchronization
2006-09-28 16:11:54,000 DEBUG [org.jbpm.scheduler.impl.SchedulerThread] checking for timers
2006-09-28 16:11:54,000 DEBUG [org.hibernate.jdbc.AbstractBatcher] about to open PreparedStatement (open PreparedStatements: 0, globally: 0)
2006-09-28 16:11:54,000 DEBUG [org.hibernate.jdbc.ConnectionManager] opening JDBC connection
2006-09-28 16:11:54,000 DEBUG [org.hibernate.SQL] select timer0_.ID_ as col_0_0_ from JBPM_TIMER timer0_ where (timer0_.EXCEPTION_ is null) and timer0_.ISSUSPENDED_<>1 order by timer0_.DUEDATE_ asc
2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.AbstractBatcher] about to open ResultSet (open ResultSets: 0, globally: 0)
2006-09-28 16:11:54,001 DEBUG [org.hibernate.impl.IteratorImpl] exhausted results
2006-09-28 16:11:54,001 DEBUG [org.hibernate.impl.IteratorImpl] closing iterator
2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.AbstractBatcher] about to close ResultSet (open ResultSets: 1, globally: 1)
2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.AbstractBatcher] about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.ConnectionManager] aggressively releasing JDBC connection
2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.ConnectionManager] releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]
2006-09-28 16:11:54,001 DEBUG [org.jbpm.JbpmContext] closing JbpmContext
2006-09-28 16:11:54,002 DEBUG [org.jbpm.svc.Services] closing service 'persistence': org.jbpm.persistence.db.DbPersistenceService@15a9173
2006-09-28 16:11:54,002 DEBUG [org.jbpm.persistence.db.DbPersistenceService] committing hibernate transaction
2006-09-28 16:11:54,002 DEBUG [org.hibernate.transaction.JTATransaction] commit
2006-09-28 16:11:54,002 DEBUG [org.hibernate.transaction.JTATransaction] Committed JTA UserTransaction
2006-09-28 16:11:54,002 DEBUG [org.jbpm.persistence.db.DbPersistenceService] closing hibernate session
2006-09-28 16:11:54,002 ERROR [STDERR] org.jbpm.persistence.JbpmPersistenceException: couldn't close hibernate session
2006-09-28 16:11:54,002 ERROR [STDERR] at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:191)
2006-09-28 16:11:54,002 ERROR [STDERR] at org.jbpm.svc.Services.close(Services.java:211)
2006-09-28 16:11:54,002 ERROR [STDERR] at org.jbpm.JbpmContext.close(JbpmContext.java:139)
2006-09-28 16:11:54,002 ERROR [STDERR] at org.jbpm.scheduler.impl.SchedulerThread.executeTimers(SchedulerThread.java:161)
2006-09-28 16:11:54,002 ERROR [STDERR] at org.jbpm.scheduler.impl.SchedulerThread.run(SchedulerThread.java:70)
2006-09-28 16:11:54,003 ERROR [STDERR] Caused by: org.hibernate.SessionException: Session was already closed
2006-09-28 16:11:54,003 ERROR [STDERR] at org.hibernate.impl.SessionImpl.close(SessionImpl.java:277)
2006-09-28 16:11:54,003 ERROR [STDERR] at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:189)
2006-09-28 16:11:54,003 ERROR [STDERR] ... 4 more
2006-09-28 16:11:54,003 ERROR [org.jbpm.svc.Services] problem closing service 'persistence'
org.jbpm.persistence.JbpmPersistenceException: couldn't close hibernate session
at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:191)
at org.jbpm.svc.Services.close(Services.java:211)
at org.jbpm.JbpmContext.close(JbpmContext.java:139)
at org.jbpm.scheduler.impl.SchedulerThread.executeTimers(SchedulerThread.java:161)
at org.jbpm.scheduler.impl.SchedulerThread.run(SchedulerThread.java:70)
Caused by: org.hibernate.SessionException: Session was already closed
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:277)
at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:189)
... 4 more
2006-09-28 16:11:54,003 INFO [org.jbpm.scheduler.impl.SchedulerThread] runtime exception while executing timers
org.jbpm.JbpmException: problem closing services {persistence=org.jbpm.persistence.JbpmPersistenceException: couldn't close hibernate session}
at org.jbpm.svc.Services.close(Services.java:223)
at org.jbpm.JbpmContext.close(JbpmContext.java:139)
at org.jbpm.scheduler.impl.SchedulerThread.executeTimers(SchedulerThread.java:161)
at org.jbpm.scheduler.impl.SchedulerThread.run(SchedulerThread.java:70)
Caused by: org.jbpm.persistence.JbpmPersistenceException: couldn't close hibernate session
at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:191)
at org.jbpm.svc.Services.close(Services.java:211)
... 3 more
Caused by: org.hibernate.SessionException: Session was already closed
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:277)
at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:189)
... 4 more
--
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
18 years, 3 months
[JBoss JIRA] Created: (JBSEAM-404) Exception handling rules
by Louis Coetzee (JIRA)
Exception handling rules
------------------------
Key: JBSEAM-404
URL: http://jira.jboss.com/jira/browse/JBSEAM-404
Project: JBoss Seam
Issue Type: Feature Request
Reporter: Louis Coetzee
Seam provides the @Redirect annotation for use on Exception classes. It provides an attribute to specify the target viewId to redirect to once the exception has been thrown. It would be good if this view Id can be specified dynamically.
e.g.
@Name("napException")
@ApplicationException(rollback=true)
@Redirect(viewId = "#{napException.viewId}")
public class NAPException extends Exception implements Serializable {
or in xml
<from-view-id>/xxx.jsp</from-view-id>
<from-exception>com.myapp.NAPException</from-exception>
<to-view-id>/error.jsp</to-view-id>
<redirect/>
--
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
18 years, 3 months