June 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPM-962) SuperState.nodes Mapping causes serious problems

by Bernd Ruecker (JIRA)

SuperState.nodes Mapping causes serious problems ------------------------------------------------ Key: JBPM-962 URL: http://jira.jboss.com/jira/browse/JBPM-962 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM jPDL 3.2 Reporter: Bernd Ruecker Assigned To: Tom Baeyens The SuperState Node mapping in the database has a problem. When parsing a process, everything is done fine. All Nodes at the root level are added to the nodes-association at the process-definition and the nodes in the super-state are added to the super-state nodes. But after persisting we have a problem: For every Node the processDefinition-association is set (by JpdlXmlReader.readNodes). So we have a id in every database column for PROCESSDEFINITION_. Because of the many-to-one mapping in ProcessDefinition: <list name="nodes" cascade="all"> <cache usage="nonstrict-read-write"/> <key column="PROCESSDEFINITION_" /> <list-index column="NODECOLLECTIONINDEX_" /> <one-to-many class="org.jbpm.graph.def.Node" /> </list> we now load ALL nodes in the nodes-List in ProcessDefinition (instead of only root nodes). To make things worse, because of the NODECOLLECTIONINDEX_ overlapping with SuperState-Nodes, we only get some of the nodes (I think it is somehow random which ones). Took some minutes to catch that ;-) One possible fix would be to NOT set the processDefinition for SuperState-Nodes (not my favorite) or maybe improve the mapping to reflect the situation (sorry, there my hibernate expertise ends). -- 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, 10 months

3
4
0 / 0

[JBoss JIRA] Created: (JBPM-823) Provide *nix support in the Starters Kit

by Micah Modell (JIRA)

Provide *nix support in the Starters Kit ---------------------------------------- Key: JBPM-823 URL: http://jira.jboss.com/jira/browse/JBPM-823 Project: JBoss jBPM Issue Type: Feature Request Components: Training Environment: RHEL 5 Beta Sun JDK 1.5.0.09 Reporter: Micah Modell Assigned To: Tom Baeyens The Starters Kit and associated documentation is very windows-centric. This is explained adequately and the issues are simple enough to compensate for, but providing the bash scripts would make it that much easier for developers and it's easy to provide them. -- 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, 10 months

3
5
0 / 0

[JBoss JIRA] Created: (JBPM-983) concurrent process execution fails

by Alexander Schlett (JIRA)

concurrent process execution fails ---------------------------------- Key: JBPM-983 URL: http://jira.jboss.com/jira/browse/JBPM-983 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM jPDL 3.2 Environment: Hypersonic in-memory database, JobExecutor configured with 5 threads Reporter: Alexander Schlett Assigned To: Tom Baeyens concurrent execution of async nodes with multiple JobExecutor threads fails. the effect is: 1) job sync within JobExecutor fails due to org.hibernate.StaleObjectStateException 2) process gets stuck in join node and never ends junit test for this is attached, it's a simple process with just a fork and a join and some scripts inbetween. -- 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, 10 months

7
34
0 / 0

[JBoss JIRA] Created: (JBPM-821) ProcessClassLoader.getResourceAsStream throws JbpmException when the resource is not found in DB

by V?ctor Su?rez (JIRA)

ProcessClassLoader.getResourceAsStream throws JbpmException when the resource is not found in DB ------------------------------------------------------------------------------------------------ Key: JBPM-821 URL: http://jira.jboss.com/jira/browse/JBPM-821 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM 3.1.2 Reporter: V?ctor Su?rez Assigned To: Tom Baeyens "ProcessClassLoader.getResourceAsStream(String name)" must return null when the resource is not found <link>http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ClassLoader.html#getRes...</link>. But when the resource look up must be performed in the DB, if that resource is not found I get a JbpmException. "ProcessClassLoader.getResourceAsStream(String name)" delegates in "fileDefinition.getBytes(name)" for searching the resource, and this calls to "getBytesFromDb(name)", and finally, this calls to "getByteArray(name)", that performs this code: if (byteArray == null) { throw new JbpmException("file '" + name + "' not found in db"); } I think that a possible solution could be: byte[] getBytesFromDb(String name) { byte[] bytes; //refactored this line ByteArray byteArray = doGetByteArray(name); bytes = byteArray.getBytes(); return bytes; } ByteArray getByteArray(String name) { //extract method refactoring ByteArray byteArray = doGetByteArray(name); if (byteArray == null) { throw new JbpmException("file '" + name + "' not found in db"); } return byteArray; } //extracted method ByteArray doGetByteArray(String name) { ByteArray byteArray = (ByteArray) (processFiles != null ? processFiles.get(name) : null); return byteArray; } I let with no modifications "getByteArray(String name)" because is referenced in the rest of code. Thanks -- 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, 10 months

5
5
0 / 0

[JBoss JIRA] Created: (JBPM-992) ProcessClassLoader : cannot load resource from code deployed inside a process archive

by Adrian Dimulescu (JIRA)

ProcessClassLoader : cannot load resource from code deployed inside a process archive ------------------------------------------------------------------------------------- Key: JBPM-992 URL: http://jira.jboss.com/jira/browse/JBPM-992 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM jPDL 3.2 Environment: enterprise JBPM : process archive deployed and serialized into database Reporter: Adrian Dimulescu Assigned To: Tom Baeyens Fix For: jBPM jPDL 3.2.1 A Java class deployed with a process archive may need access to a class path resource deployed in the same process archive. A common example is an ActionHandler implementation that calls a remote EJB and needs a jndi.properties file containin remote appserver location. In order to load that it calls : this.getClass().getClassLoader().getResourceAsStream("jndi.properties") This call generates a java.lang.NullPointerException which I think justifies the classification of this issue as a bug. Looking inside the ProcessClassLoader class, I see that in order to load a class, a "classes/" prefix. Indeed, the "par" format wants that all compiled classes be locates underneath the "classes/" directory. The JBPM_BYTEARRAY.NAME_ field in the database table confirms this : the NAME_ of the jndi.properties resource is : "classes/jndi.properties". Still the ProcessClassLoader.getResourceAsStream method does not use the classes prefix. The fix look thus simple, i.e. adding that prefix. Second problem : if the resource is not found, a delegation should be made to the parent classloader. -- 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, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAOP-382) Remove Complex Advice Signatures from Classic Mode

by Flavia Rainone (JIRA)

Remove Complex Advice Signatures from Classic Mode -------------------------------------------------- Key: JBAOP-382 URL: http://jira.jboss.com/jira/browse/JBAOP-382 Project: JBoss AOP Issue Type: Task Security Level: Public (Everyone can see) Reporter: Flavia Rainone Assigned To: Flavia Rainone Priority: Minor Fix For: 2.0.0.alpha5 We need to update PerVMAdvice class, to remove the possibility of advices that receive joinpoint arguments (currently, the matching of parameters is not completely functional). We will leave the possibility of receiving joinpoint arguments as parameters to the annotated-parameters signature. This task also includes moving arg tests to beforeafterArgs package. PS: documentation is already stating that only annotated-parameters advice signatures can feature joinpoint arguments as parameters. No need to update documentation here. -- 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, 10 months

3
9
0 / 0

[JBoss JIRA] Created: (JGRP-347) TCP bundling with FLUSH not working

by Bela Ban (JIRA)

TCP bundling with FLUSH not working ----------------------------------- Key: JGRP-347 URL: http://jira.jboss.com/jira/browse/JGRP-347 Project: JGroups Issue Type: Bug Affects Versions: 2.3 SP1 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.4 We can make TCP with bundling *on* work (timeout 0) if we exchange order of passUp/passDown of the view for a new member in Gms line 509. Since bundler is sending messages in bundles it screws up synchronous step process required for a new member when doing START_FLUSH, view installation, STOP_FLUSH. We have a thread race here on line 509. In order to circumvent that we can *first* pass a view from a join response up to FLUSH and then pass it down. I am not sure how this affects other tests. -- 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, 10 months

3
6
0 / 0

[JBoss JIRA] Created: (JBPM-988) JpdlXmlReader fails to readProcessDefinition if process contains nodes with same name inside different containers

by Olga Ivanova (JIRA)

JpdlXmlReader fails to readProcessDefinition if process contains nodes with same name inside different containers ----------------------------------------------------------------------------------------------------------------- Key: JBPM-988 URL: http://jira.jboss.com/jira/browse/JBPM-988 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM jPDL 3.2 Reporter: Olga Ivanova Assigned To: Tom Baeyens JpdlXmlReader incorrectly handles nodes that belong to super state container. While reading node, it first calls node.setName and only after that adds node to corresponding node container. Method setName is not simply getter, it also updates corresponding container with new node name. For node that belongs to super state, container is not yet set, so node updates it's name inside process definition (which is default container for all nodes), if there are several nodes with same name that belongs to different containers and if between processing them there are no process definition (root) nodes, exception is thrown when setting name to second node, that such node already exists: java.lang.IllegalArgumentException: couldn't set name 's' on node 'State(c70f32)'cause the process definition of this node has already another node with the same name at org.jbpm.graph.def.Node.setName(Node.java:426) at org.jbpm.jpdl.xml.JpdlXmlReader.readNode(JpdlXmlReader.java:488) UnitTest attached. This problem could either be solved by changing JpdlXmlReader.readNode method, and putting nodeCollection.addNode at the beginning of the method: public void readNode(Element nodeElement, Node node, NodeCollection nodeCollection) { nodeCollection.addNode(node); // get the node name String name = nodeElement.attributeValue("name"); if (name != null) { node.setName(name); ..... Another solution is to change Node.setName method, so it will first check if node already exists in container node collection (hasNode(name)), and only in this case update it's name there: public void setName(String name) { if (isDifferent(this.name, name)) { String oldName = this.name; if (superState!=null && superState.hasNode(oldName)) { if ( superState.hasNode(name) ) { throw new IllegalArgumentException("couldn't set name '"+name+"' on node '"+this+"'cause the superState of this node has already another child node with the same name"); } Map nodes = superState.getNodesMap(); nodes.remove(oldName); nodes.put(name,this); } else if (processDefinition!=null && processDefinition.hasNode(oldName)) { if ( processDefinition.hasNode(name) ) { throw new IllegalArgumentException("couldn't set name '"+name+"' on node '"+this+"'cause the process definition of this node has already another node with the same name"); } Map nodeMap = processDefinition.getNodesMap(); nodeMap.remove(oldName); nodeMap.put(name,this); } this.name = name; } } I would vote for second solution, as is does not change any logic, it simply does not updates something that does not require update anyway. -- 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, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (JBPM-832) persist annotated classes by using AnnotationConfiguration in HibernateHelper.java

by Chris Russell (JIRA)

persist annotated classes by using AnnotationConfiguration in HibernateHelper.java ---------------------------------------------------------------------------------- Key: JBPM-832 URL: http://jira.jboss.com/jira/browse/JBPM-832 Project: JBoss jBPM Issue Type: Feature Request Components: Core Engine Affects Versions: jBPM 3.2 beta 1 Reporter: Chris Russell Assigned To: Tom Baeyens Fix For: jBPM 3.2 beta 2 Should be able to persist annotated Entitys (classes that dont have a hbm.xml mapping file). To do this is a fairly simple change to HibernateHelper.java. One unresolved question here is why doesnt the hibernate.cfg.xml configuration option <property name="hibernate.ejb.naming_strategy"> get picked up?? HibernateHelper.java .. import org.hibernate.cfg.AnnotationConfiguration; import org.hibernate.cfg.DefaultComponentSafeNamingStrategy; . . public static Configuration createConfiguration(String cfgXmlResource, String propertiesResource) { AnnotationConfiguration configuration = new AnnotationConfiguration(); //NOT SURE WHY BUT configuration not picking up //hibernate.cfg.xml //<property name="hibernate.ejb.naming_strategy"> //org.hibernate.cfg.DefaultComponentSafeNamingStrategy</property> log.debug("NAMING START STRATEGY ["+configuration.getNamingStrategy().getClass().getName()+"]"); log.debug(configuration.setNamingStrategy(new DefaultComponentSafeNamingStrategy())); log.debug("NAMING AFTER STRATEGY ["+configuration.getNamingStrategy().getClass().getName()+"]"); With these changes you can now add mappings to the hibernate.cfg.xml such as <mapping package="foo"/> <mapping class="foo.MyAnnotatedFooClass"/> To pick up annotated classes.... -- 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, 10 months

3
4
0 / 0

[JBoss JIRA] Created: (JBAS-4392) Replace j2ee and ejb3x module with javaee module

by Carlo de Wolf (JIRA)

Replace j2ee and ejb3x module with javaee module ------------------------------------------------ Key: JBAS-4392 URL: http://jira.jboss.com/jira/browse/JBAS-4392 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.0.0.Beta2 Reporter: Carlo de Wolf Assigned To: Carlo de Wolf Fix For: JBossAS-5.0.0.Beta3 -- 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, 10 months

2
4
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2007