June 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPM-979) Documentation enhancement for sub-process (fix error; add binding attribute)

by Arjan van Bentem (JIRA)

Documentation enhancement for sub-process (fix error; add binding attribute) ---------------------------------------------------------------------------- Key: JBPM-979 URL: http://jira.jboss.com/jira/browse/JBPM-979 Project: JBoss jBPM Issue Type: Feature Request Components: Documentation Affects Versions: jBPM jPDL 3.2 Environment: All Reporter: Arjan van Bentem Assigned To: Tom Baeyens http://jira.jboss.org/jira/browse/JBPM-733 added the attribute "binding" to element "sub-process". This attribute is not yet documented, and at some points the documentation seems to be wrong (hence: priority major). PLEASE VERIFY THAT MY PROPOSED CHANGES ARE CORRECT... See implementation at http://fisheye.labs.jboss.com/browse/JBPM/jbpm.3/jpdl/jar/src/main/java/o... http://fisheye.labs.jboss.com/browse/JBPM/jbpm.3/jpdl/jar/src/main/java/o... http://fisheye.labs.jboss.com/browse/JBPM/jbpm.3/jpdl/userguide/en/module... or http://docs.jboss.com/jbpm/v3.2/userguide/html/processmodelling.html#proc... Process Modelling 9.8. Process composition Change When execution arrives in the 'first interview', a new execution (=process instance) for the latest version of the 'interview' process is created. into something like: When execution arrives in the 'first interview', a new execution (=process instance) of the 'interview' process is created. As no explicit version is specified, the latest version of the sub process as known when deploying the 'hire' process is used. To make jBPM instantiate a specific version the optional <literal>version</literal> attribute can be specified. To postpone binding the specified or latest version until actually creating the sub process, the optional <literal>binding</literal> attribute should be set to <literal>late</literal>. http://fisheye.labs.jboss.com/browse/JBPM/jbpm.3/jpdl/userguide/en/module... or http://docs.jboss.com/jbpm/v3.2/userguide/html/jpdl.html#subprocess.element jBPM Process Definition Language (JPDL) 18.4.28. sub-process Change <row> <entry>version</entry> ... <entry>the version of the sub process. If no version is specified, the latest version of the given process will be taken.</entry> </row> into <entry>the version of the sub process. If no version is specified, the latest version of the given process as known while deploying the parent <link linkend="processstate.element">process-state</link> will be taken.</entry> And add something like: <row> <entry>binding</entry> <entry>attribute</entry> <entry>optional</entry> <entry>indicates if the version of the sub process should be determined when deploying the parent <link linkend="processstate.element">process-state</link> (default behavior), or when actually invoking the sub process (<literal>binding="late"</literal>). When both <literal>version</literal> and <literal>binding="late"</literal> are given then jBPM will use the version as requested, but will not yet try to find the sub process when the parent process-state is deployed. </entry> </row> Note: http://jira.jboss.com/jira/browse/JBPM-910 reports that the XML schema needs updating as well. -- 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: (JBAS-4479) it'd be nice for listThreadDump() to return a timestamp as well

by Galder Zamarreno (JIRA)

it'd be nice for listThreadDump() to return a timestamp as well --------------------------------------------------------------- Key: JBAS-4479 URL: http://jira.jboss.com/jira/browse/JBAS-4479 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Management services Affects Versions: JBossAS-4.2.0.GA, JBossAS-4.0.5.GA Reporter: Galder Zamarreno Assigned To: Dimitris Andreadis Priority: Minor >From a remote support perspective, it'd be very helpful if ServerInfo.listThreadDump() could a time stamp on the time when the thread dump was requested. -- 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
5
0 / 0

[JBoss JIRA] Created: (JBPM-990) Delete subprocess instances fails if super process token is not in process state

by Olga Ivanova (JIRA)

Delete subprocess instances fails if super process token is not in process state -------------------------------------------------------------------------------- Key: JBPM-990 URL: http://jira.jboss.com/jira/browse/JBPM-990 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM jPDL 3.2 Reporter: Olga Ivanova Assigned To: Tom Baeyens There was fixed issue "delete sub process instances recursively" (see http://jira.jboss.com/jira/browse/JBPM-614) that has been fixed. Sub processes are deleted using following code: ------------------------------------------------------------------------------------------------------------------- ProcessInstance subProcessInstance = token.getSubProcessInstance(); if (subProcessInstance != null) { subProcessInstance.setSuperProcessToken(null); token.setSubProcessInstance(null); deleteProcessInstance(subProcessInstance); } ----------------------------------------------------------------------------------------------------------------------- The problem is that token.getSubProcessInstance() returns something only while token is in process state, as soon as token leaves process state, getSubProcessInstance() returns null. The correct way to find sub process instances for current process is to query process instance by super process token, there is already defined named query in hibernate.queries.hbm.xml file - "GraphSession.findSubProcessInstances", so code should look following: ---------------------------------------------------------------------------------------------------------------------- Query query = session .getNamedQuery("GraphSession.findSubProcessInstances"); query.setLong("instanceId", token.getProcessInstance().getId()); List<ProcessInstance> processInstances = query.list(); if (processInstances == null || processInstances.isEmpty()) return; for (ProcessInstance instance : processInstances) { instance.setSuperProcessToken(null); token.setSubProcessInstance(null); deleteProcessInstance(instance); } --------------------------------------------------------------------------------------------------------------------------- -- 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: (JBMICROCONT-178) Expand the ManagedObject spi to operations/runtime properties

by Scott M Stark (JIRA)

Expand the ManagedObject spi to operations/runtime properties ------------------------------------------------------------- Key: JBMICROCONT-178 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-178 Project: JBoss MicroContainer Issue Type: Feature Request Reporter: Scott M Stark Assigned To: Scott M Stark Fix For: JBossMC_2_0_0_CR1 Properties that are updatable at runtime as well as operations need to be supported from the ManagedObject spi. -- 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

4
10
0 / 0

[JBoss JIRA] Created: (JBAS-3940) Use the JGroups multiplexer in the 4.2 branch

by Brian Stansberry (JIRA)

Use the JGroups multiplexer in the 4.2 branch --------------------------------------------- Key: JBAS-3940 URL: http://jira.jboss.com/jira/browse/JBAS-3940 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-4.2.0.CR1 Branch_4_2 will use JGroups 2.4.1, so we can use the multiplexer and multiplex the various channels. Only code change for this is in ClusterPartition; other services use JBoss Cache where it is just a config change. -- 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
5
0 / 0

[JBoss JIRA] Created: (JBPM-1006) Concurrent use of 'repeat' and 'transition' in a timer declaration will result in an execution of a non existing timer.

by Andreas Schienagel (JIRA)

Concurrent use of 'repeat' and 'transition' in a timer declaration will result in an execution of a non existing timer. ----------------------------------------------------------------------------------------------------------------------- Key: JBPM-1006 URL: http://jira.jboss.com/jira/browse/JBPM-1006 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM jPDL 3.2.1 Reporter: Andreas Schienagel Assigned To: Tom Baeyens As described in http://www.jboss.com/index.html?module=bb&op=viewtopic&t=112192 "If you set an transition on a timer, this transition will be taken if it reaches the duedate and no further repetitions are possible cause the timer is deleted from db. So far so good... But if you set the repeat option as well, the engine tries to execute the timer once 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, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (JBPM-980) superstate-enter not fired when taking a transition directly to the super state

by Olivier Cuzacq (JIRA)

superstate-enter not fired when taking a transition directly to the super state ------------------------------------------------------------------------------- Key: JBPM-980 URL: http://jira.jboss.com/jira/browse/JBPM-980 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM jPDL 3.2 Environment: JBpm 3.2GA Reporter: Olivier Cuzacq Assigned To: Tom Baeyens Priority: Minor Let's consider a simple example using a super-state : <start-state name="start"> <transition to="buildPhase"/> </start-state> <super-state name="buildPhase"> <event type="superstate-enter"> <action class="com..." /> </event> ... <state name="waitForValidation"> <transition to="../deliveryPhase"/> </state> <event type="superstate-leave"> <action class="com..." /> </event> The superstate leave event is fired, but enter is not. Looking at the code this seems 'normal' : - Transition.take: if ( destination.getSuperState()!=null ) { ... fire the event ... - SuperState.execute : Node startNode = (Node) nodes.get(0); startNode.enter(executionContext); Going from a node to a super-state taking an explicit transition wont cause the event to be fired as dest.getSuperState == null. Then the super state will be executed and the first node will be entered without any kind of 'transient' transition being taken. If we look at the doc : (http://docs.jboss.com/jbpm/v3/userguide/processmodelling.html#superstatee... ) 9.6.2. Superstate events ... These events will be fired no matter over which transitions the node is entered or left respectively -> I cant find anything more precise about the expected behaviour AFAIAC I would expect the super-enter event being fired whatever the enter context (thru an innder node, or referencing the super-state itself). Best regards Olivier Cuzacq -- 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
5
0 / 0

[JBoss JIRA] Created: (EJBTHREE-952) Not able to access EJB3 from client running in jre1.6, while it works if client running in jre1.5

by Harsha setty (JIRA)

Not able to access EJB3 from client running in jre1.6, while it works if client running in jre1.5 ------------------------------------------------------------------------------------------------- Key: EJBTHREE-952 URL: http://jira.jboss.com/jira/browse/EJBTHREE-952 Project: EJB 3.0 Issue Type: Bug Environment: JBOSS 4.0.5 GA with EJB3 profile, EJBs - JBOSS running in JRE1.6 and EJBs compiled in JDK1.6. Works well with Client with JRE1.5 but throws "socket corrupted exception" for JRE1.6 This errors appear both on JBOSS installed on Windows XP and Red Hat Linux. Reporter: Harsha setty Priority: Critical Fix For: EJB 3.0 RC9 - FD When my java client runs in JRE1.6, it throws the exception Exception in thread "main" java.lang.reflect.UndeclaredThrowableException at $Proxy0.authenticateUser(Unknown Source) at gui.Test.main(Test.java:40) Caused by: java.rmi.MarshalException: Failed to communicate. Problem during marshalling/unmarshalling; nested exception is: java.io.StreamCorruptedException: invalid type code: 00 at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:306) at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143) at org.jboss.remoting.Client.invoke(Client.java:525) at org.jboss.remoting.Client.invoke(Client.java:488) at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:77) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102) ... 2 more Caused by: java.io.StreamCorruptedException: invalid type code: 00 at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.readArray(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.defaultReadFields(Unknown Source) at java.io.ObjectInputStream.readSerialData(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:122) at java.io.ObjectInputStream.readExternalData(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.defaultReadFields(Unknown Source) at java.io.ObjectInputStream.readSerialData(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:128) at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:66) at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:279) ... 14 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, 10 months

2
4
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1499) CMSAdminPortlet should use Users/Roles Module and not direct HQL query

by Antoine Herzog (JIRA)

CMSAdminPortlet should use Users/Roles Module and not direct HQL query ---------------------------------------------------------------------- Key: JBPORTAL-1499 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1499 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal CMS, Portal Identity Affects Versions: 2.6.CR2 Environment: JBP2.6 CR2 (bundle package with JBoss AS 4.0.5) Reporter: Antoine Herzog Assigned To: Sohil Shah When separating the CMS tables and the Users/Roles tables in two datasources, I found this : when trying to go to the CmsAdmin (CMSAdminPortlet), I got "access denied" and this exception : 2007-06-22 13:56:11,015 DEBUG [org.hibernate.jdbc.ConnectionManager] releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)] 2007-06-22 13:56:11,015 DEBUG [org.hibernate.util.JDBCExceptionReporter] could not execute query [SELECT * from jbp_cms_perm p,jbp_cms_perm_role r,jbp_role_membership m,jbp_roles roles,jbp_users users WHERE p.id=r.cms_perm_id AND r.role_id=roles.jbp_name AND m.jbp_rid=roles.jbp_rid AND m.jbp_uid=users.jbp_uid AND users.jbp_uname=?] com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Table 'jbptl_cms.jbp_role_membership' doesn't exist at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:936) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2870) and also : 13:56:11,015 WARN [JDBCExceptionReporter] SQL Error: 1146, SQLState: 42S02 13:56:11,015 ERROR [JDBCExceptionReporter] Table 'jbptl_cms.jbp_role_membership' doesn't exist Datasource for Users/Roles : jbptl_users Datasource for CMS : jbptl_cms I did not look precisely to the CMSAdminPortlet code, but obviously, the HQL query mix the tables of the CMS and the tables of the Users/Roles. Every thing works fine in the native version of portal, but it can't work with my production or architectures needs. I guess usual needs : separation of what is not really tied up. I guess the CMS service should check the security using the Users and Roles Modules, with some java level code, and not directly the Hibernate queries that manipulate the data. With this, we cannot have a specific Users/Roles Module, with other persistence than in the same database as the CMS. => is the CMSAdminPortlet working with a LDAP user repository ? I guess not, if the LDAP Users/Roles Module does not use the JBossPortal users tables (no replication between ldap and the usual portal u/r tables). => if we need a specific user database (legacy), with a home made Users/Roles Module that take the data from another legacy datasource, the CMSAdminPortlet and CMS Security won't work => general architecture design : the users data are in a database, the cms data are in another one : more clean for managing all that stuff (backup, restore if crash, maintenance against user data or cms data, etc...). Feature : - Enhance the CMSService with some Security API that provide all the basic security features to check the permission, doing it with java and Users/Roles Module, not with hibernate. - Or (I think is better) provide a Users/Roles Security service, that provide the usual security checking features (isInRole(), etc...). This would be above the Users/Roles Module I guess the portal needs the same kind of service : set a common service interface for both needs. Even if there are no time to decide and build these security interfaces for 2.6, it would be great to have the CMSAdminPortlet working with some CMS and Users/Roles separate DataSources. I will manage with only one DS for dev, but would be great to have it for the upgrade of our prod version (now in JBP2.4.1). Unfortunately, I have no time to do this now (huge work to have the next version of our portal ready asap... and I'd rather use right now the 2.6 than keep 2.4 for all this...). Thanks, Antoine -- 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

4
14
0 / 0

[JBoss JIRA] Created: (JBAS-4377) DataSource deployer needs to take over ConnectionFactoryDeployerManagedObjectBuilder

by Scott M Stark (JIRA)

DataSource deployer needs to take over ConnectionFactoryDeployerManagedObjectBuilder ------------------------------------------------------------------------------------- Key: JBAS-4377 URL: http://jira.jboss.com/jira/browse/JBAS-4377 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Scott M Stark Assigned To: Weston Price The org.jboss.profileservice.management.builders.ConnectionFactoryDeployerManagedObjectBuilder override of the data source deployer needs to be moved into the deployers. -- 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
2
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