September 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPORTAL-1680) make cms tests pass with jdk1.5 on linux

by Prabhat Jha (JIRA)

make cms tests pass with jdk1.5 on linux ---------------------------------------- Key: JBPORTAL-1680 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1680 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal CMS Affects Versions: 2.6 Final Reporter: Prabhat Jha Assigned To: Prabhat Jha The cms tests have been failing when run with jdk1.5 on linux. Please see http://dev45.qa.atl.jboss.com:8585/hudson/view/JBoss%20Portal/job/jboss-p.... The error is javax.jcr.RepositoryException: Cannot instantiate persistence manager org.jboss.portal.cms.hibernate.state.JBossCachePersistenceManager: org.jgroups.ChannelException: failed to start protocol stack: org.jgroups.ChannelException: failed to start protocol stack at org.apache.jackrabbit.core.RepositoryImpl.createPersistenceManager(RepositoryImpl.java:1083) at org.apache.jackrabbit.core.RepositoryImpl.createVersionManager(RepositoryImpl.java:299) at org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:244) at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:497) at org.jboss.portal.cms.impl.jcr.jackrabbit.JackrabbitJCRService.start(JackrabbitJCRService.java:105) at org.jboss.portal.cms.impl.jcr.JCRCMS.startJCR(JCRCMS.java:350) at org.jboss.portal.cms.impl.jcr.JCRCMS.startService(JCRCMS.java:315) at org.jboss.portal.test.cms.commands.AbstractCommandTestCase.setUp(AbstractCommandTestCase.java:69) at org.jboss.portal.test.framework.junit.POJOJUnitTest.invokeNoArg(POJOJUnitTest.java:287) at org.jboss.portal.test.framework.junit.POJOJUnitTest.invoke(POJOJUnitTest.java:153) at org.jboss.portal.test.framework.junit.JUnitAdapter$2.runBare(JUnitAdapter.java:115) at org.jboss.portal.test.framework.junit.JUnitAdapter$1.visit(JUnitAdapter.java:130) at org.jboss.portal.test.framework.info.TestInfo.internalVisit(TestInfo.java:138) at org.jboss.portal.test.framework.info.TestContainerInfo.internalVisit(TestContainerInfo.java:97) at org.jboss.portal.test.framework.info.TestItemInfo.visit(TestItemInfo.java:210) at org.jboss.portal.test.framework.junit.JUnitAdapter.run(JUnitAdapter.java:134) at org.jboss.portal.test.framework.junit.JUnitAdapter.run(JUnitAdapter.java:88)Caused by: java.lang.RuntimeException: org.jgroups.ChannelException: failed to start protocol stack at org.jboss.portal.cms.hibernate.state.JBossCachePersistenceManager.init(JBossCachePersistenceManager.java:285) at org.apache.jackrabbit.core.RepositoryImpl.createPersistenceManager(RepositoryImpl.java:1079) ... 29 moreCaused by: org.jgroups.ChannelException: failed to start protocol stack at org.jgroups.JChannel.connect(JChannel.java:393) at org.jboss.cache.TreeCache.startService(TreeCache.java:1424) at org.jboss.portal.cms.hibernate.state.JBossCachePersistenceManager.init(JBossCachePersistenceManager.java:262) ... 30 moreCaused by: java.lang.Exception: exception caused by UDP.start(): java.net.BindException: Cannot assign requested address at org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:600) at org.jgroups.stack.DownHandler.run(Protocol.java:117)java.lang.RuntimeException: org.jgroups.ChannelException: failed to start protocol stack at org.jboss.portal.cms.hibernate.state.JBossCachePersistenceManager.init(JBossCachePersistenceManager.java:285) at org.apache.jackrabbit.core.RepositoryImpl.createPersistenceManager(RepositoryImpl.java:1079) at org.apache.jackrabbit.core.RepositoryImpl.createVersionManager(RepositoryImpl.java:299) at org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:244) at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:497) at org.jboss.portal.cms.impl.jcr.jackrabbit.JackrabbitJCRService.start(JackrabbitJCRService.java:105) at org.jboss.portal.cms.impl.jcr.JCRCMS.startJCR(JCRCMS.java:350) at org.jboss.portal.cms.impl.jcr.JCRCMS.startService(JCRCMS.java:315) at org.jboss.portal.test.cms.commands.AbstractCommandTestCase.setUp(AbstractCommandTestCase.java:69) at org.jboss.portal.test.framework.junit.POJOJUnitTest.invokeNoArg(POJOJUnitTest.java:287) at org.jboss.portal.test.framework.junit.POJOJUnitTest.invoke(POJOJUnitTest.java:153) at I think solution is to turn on -Djava.net.preferIPv4Stack=true. Not sure if jbossas needs to be started with this flag on or something on the testsuite itself. Need to find out. -- 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

1
1
0 / 0

[JBoss JIRA] Commented: (JBPM-426) enable jpdl schema extension via namespaces

by Tom Baeyens (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-426?page=comments#action_12375915 ] Tom Baeyens commented on JBPM-426: ---------------------------------- just for my information so that i don't loose track of it: jpdl/jar/src/test/java/org.jbpm.jpdl.xml.ParsingTest > enable jpdl schema extension via namespaces > ------------------------------------------- > > Key: JBPM-426 > URL: http://jira.jboss.com/jira/browse/JBPM-426 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Affects Versions: jBPM jPDL 3.2, jBPM 3.1 > Reporter: Martin Dirichs > Assigned To: Ronald van Kuijk > Fix For: jBPM jPDL 3.2.2 > > > Customizing jpdl elements in a process definition via application-specific XML-elements is currently only possible outside of any schema validation. XML namespaces are the canonical way to allow for the extension of jpdl so that configuration data of delegation classes may be defined within an application-specific namespace and associated XML schema. In particular, this would be necessary to enable customization of jpdl elements > - action > - assignment > - handler > - controller > - task > Bug #JBPM-332: > http://jira.jboss.com/jira/browse/JBPM-332 > is somewhat related to this issue. However, resolution of JBPM-332 > - only allows for arbitrary elements to appear inside jpdl files (without schema validation) > - and only for customizing assignments (leaving out action, handler, controller and task). > Implementation of this feature request would be done via a more intelligent version of an EntityResolver (defined in org.jbpm.jpdl.xml.SchemaValidationHandle) that can return application specific schemas in addition to the default one for jpdl. -- 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

1
0
0 / 0

[JBoss JIRA] Created: (JBPM-981) Whitespace and line endings in script elements are not preserved - fix?

by Edward Staub (JIRA)

Whitespace and line endings in script elements are not preserved - fix? ----------------------------------------------------------------------- Key: JBPM-981 URL: http://jira.jboss.com/jira/browse/JBPM-981 Project: JBoss jBPM Issue Type: Feature Request Components: Core Engine Affects Versions: jBPM jPDL 3.2 Reporter: Edward Staub Assigned To: Tom Baeyens The current Script implementation collapses script whitespace and eliminates line-endings in scripts - even when within a !CDATA. I believe this is often bad and never good, apart from trivial optimization. Line-ending preservation is necessary for use of // comments. Whitespace and line-ending preservation are useful for script compiler error messages that call out a line and column position of the error. These positions are meaningless if space has been collapsed and line-endings removed. I happen to be experimenting with using other script languages (especially Groovy) for which line endings are meaningful. You probably don't care about that, though! The fix is easy: in Script.read(), replace both occurrences of getTextTrim() with getText(). -- 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
2
0 / 0

[JBoss JIRA] Created: (JBPM-822) XML example incorrect Chapter 7.2.2

by tom (JIRA)

XML example incorrect Chapter 7.2.2 ----------------------------------- Key: JBPM-822 URL: http://jira.jboss.com/jira/browse/JBPM-822 Project: JBoss jBPM Issue Type: Bug Components: Documentation Reporter: tom Assigned To: Tom Baeyens Line: <bean factory="org.jbpm.persistence.db.DbPersistenceServiceFactory"> should read <bean class="org.jbpm.persistence.db.DbPersistenceServiceFactory"> Can I also suggest that the XML configuration schemas or DTDs are also included in the documentation. -- 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
3
0 / 0

[JBoss JIRA] Created: (JBPM-1044) TaskMgmtInstance.removeSignalling(Token token) - Remove signalling capabilities from all task instances related to the given token

by Wolfgang Hollweck (JIRA)

TaskMgmtInstance.removeSignalling(Token token) - Remove signalling capabilities from all task instances related to the given token ---------------------------------------------------------------------------------------------------------------------------------- Key: JBPM-1044 URL: http://jira.jboss.com/jira/browse/JBPM-1044 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM jPDL 3.2, jBPM 3.1.4 Reporter: Wolfgang Hollweck Assigned To: Tom Baeyens There is a bug in TaskMgmtinstance.removeSignalling(Token token) of jBPM versions 3.1.4 and 3.2: Signalling is set to false for all TaskInstances that are in the current TaskMgmtInstance. It has to be checked, that signalling is removed only from TaskInstances belonging to the given Token. (see forum) -- 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-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] Closed: (JBPM-642) Signaling RootToken on Fork Node

by Tom Baeyens (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-642?page=all ] Tom Baeyens closed JBPM-642. ---------------------------- Fix Version/s: (was: jBPM jPDL 3.2.2) Resolution: Rejected i think it makes sense to null out the node pointer in the token after the fork has executed. in that case it can't be signalled and then it doesn't need another db column. BUT since i'm not sure of the consequences and people might just rely on the current behaviour, i don't think this feature request is worth while the risk. So I'm going to bare this in mind for the 4.0 implementation, but in 3.x, we'll leave it as it is now. > Signaling RootToken on Fork Node > --------------------------------- > > Key: JBPM-642 > URL: http://jira.jboss.com/jira/browse/JBPM-642 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Reporter: Enric Cecilla > Assigned To: Tom Baeyens > > Giving the following processdefinition: > *start->fork->a->join->end > ->b ^ > When RootToken is on Fork node trying to signal again the RootToken actually moves the token to one branch state, then RootToken can be signalled til it is on the Join node. At that moment it can be signalled again and it leaves the Join node. > pi.signal(); > assertEquals( "fork", pi.getRootToken().getNode().getName() ); //true > pi.signal(); > assertEquals( "b", pi.getRootToken().getNode().getName() ); //true > pi.signal(); > assertEquals( "join", pi.getRootToken().getNode().getName() ); //true > Does it makes any sense being able to signal a RootToken on Fork node which has children on every branch? From my point of view signalling on that condition should throw and Exception. Only child tokens should be allowed to signal since "real" tasks are on child tokens -- 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

1
0
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-1043) ProcessDefinition delete throws HibernateException: null index column for collection: org. jbpm.graph.def.ProcessDefinition.actions

by Martin Putz (JIRA)

ProcessDefinition delete throws HibernateException: null index column for collection: org. jbpm.graph.def.ProcessDefinition.actions ------------------------------------------------------------------------------------------------------------------------------------ Key: JBPM-1043 URL: http://jira.jboss.com/jira/browse/JBPM-1043 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM jPDL 3.2.1 Reporter: Martin Putz Assigned To: Tom Baeyens if the process definition contains a task with notify="yes", eg. <task-node name="mail"> <task name="email info" notify="yes"> <assignment actor-id="mputz"></assignment> </task> <transition to="end-state1"></transition> </task-node> the deletion of this process definition results in the stated HibernateException: null index column for collection: org. jbpm.graph.def.ProcessDefinition.actions -- 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-435) Update AspectDeployer following the next MC release

by Kabir Khan (JIRA)

Update AspectDeployer following the next MC release --------------------------------------------------- Key: JBAOP-435 URL: http://jira.jboss.com/jira/browse/JBAOP-435 Project: JBoss AOP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: 2.0.0.CR1 Can copy the code from jboss-head/system org.jboss.aop.deployers.temp.AspectDeployer -- 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

1
3
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 September 2007