[JBoss JIRA] Updated: (JBPM-1068) Possibility of UITaskFormButtonBase to use child action tags such as it done with h:commandButton
by Thomas Diesler (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-1068?page=all ]
Thomas Diesler updated JBPM-1068:
---------------------------------
Assignee: (was: Tom Baeyens)
> Possibility of UITaskFormButtonBase to use child action tags such as it done with h:commandButton
> -------------------------------------------------------------------------------------------------
>
> Key: JBPM-1068
> URL: http://jira.jboss.com/jira/browse/JBPM-1068
> Project: JBoss jBPM
> Issue Type: Feature Request
> Components: Web Interface
> Affects Versions: jBPM jPDL 3.2.1
> Reporter: Vt Ysh
> Priority: Optional
>
> If i am trying to put custom action tags between for example <tf:saveButton value="Save"></tf:saveButton > such as it can be done with h:commandButton i am getting NullPointer exception with the next stack trace:
> java.lang.NullPointerException
> at org.jbpm.jsf.taskform.ui.UITaskFormButtonBase.getEnclosingForm(UITask
> FormButtonBase.java:30)
> at org.jbpm.jsf.taskform.ui.UITaskFormButtonBase.addActionListener(UITas
> kFormButtonBase.java:44)
> at org.jbpm.jsf.core.handler.AbstractHandler.apply(AbstractHandler.java:
> 64)
> at com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentH
> andler.java:314)
> at com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java
> :169)
> at com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHa
> ndler.java:47)
> at com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentH
> andler.java:314)
> at com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java
> :169)
> at com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHa
> ndler.java:47)
> at com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentH
> andler.java:314)
> at com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java
> :169)
> at com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHa
> ndler.java:47)
> at com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentH
> andler.java:314)
> at com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java
> :169)
> at com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentH
> andler.java:314)
> at com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java
> :169)
> at com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHa
> ndler.java:47)
> at com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentH
> andler.java:314)
> at com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java
> :169)
> at com.sun.facelets.tag.ui.DefineHandler.apply(DefineHandler.java:58)
> at com.sun.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.j
> ava:128)
> at com.sun.facelets.impl.DefaultFaceletContext$TemplateManager.apply(Def
> aultFaceletContext.java:306)
> at com.sun.facelets.impl.DefaultFaceletContext.includeDefinition(Default
> FaceletContext.java:279)
> at com.sun.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:68)
> at com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHa
> ndler.java:47)
> at test.facelets.IfHandler.apply(IfHandler.java:33)
> at com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHa
> ndler.java:47)
> at com.sun.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.jav
> a:49)
> at com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHa
> ndler.java:47)
> at com.sun.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:
> 25)
> at com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:248)
> at com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:294)
> at com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:273)
> at com.sun.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFac
> eletContext.java:143)
> at com.sun.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.j
> ava:113)
> at com.sun.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.jav
> a:49)
> at com.sun.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:
> 25)
> at com.sun.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:95)
> at com.sun.facelets.FaceletViewHandler.buildView(FaceletViewHandler.java
> :503)
> at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.jav
> a:546)
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrap
> per.java:178)
> at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePha
> se.java:106)
> at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:248)
> at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:144)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:245)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> icationFilterChain.java:252)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> ilterChain.java:173)
> at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFi
> lter.java:96)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> icationFilterChain.java:202)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> ilterChain.java:173)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
> alve.java:213)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
> alve.java:178)
> at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(Securit
> yAssociationValve.java:175)
> at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValv
> e.java:74)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
> ava:126)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
> ava:105)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
> ve.java:107)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
> a:148)
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
> :869)
> at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.p
> rocessConnection(Http11BaseProtocol.java:664)
> at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpo
> int.java:527)
> at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWor
> kerThread.java:112)
> at java.lang.Thread.run(Thread.java:595)
> Seems that problem can be in HtmlCommandButton.getParent() method. Is there any suggestions how to fix this issue?
--
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
16 years, 6 months
[JBoss JIRA] Updated: (JBPM-1029) calling getGroupTaskList results in 4N queries being made to the database
by Thomas Diesler (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-1029?page=all ]
Thomas Diesler updated JBPM-1029:
---------------------------------
Assignee: (was: Tom Baeyens)
> calling getGroupTaskList results in 4N queries being made to the database
> -------------------------------------------------------------------------
>
> Key: JBPM-1029
> URL: http://jira.jboss.com/jira/browse/JBPM-1029
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Core Engine
> Affects Versions: jBPM jPDL 3.2.1
> Reporter: David Sheth
>
> In the seam 2.0.0.Beta 1 dvdstore example, which uses jbpm-jpdl 3.2.1, one of the admin pages lists all the tasks assigned to the group of the admin, allowing the admin to assign one of the tasks to him or herself. In this page, a task represents an order placed in the store.
> Each time a new order is placed in the store, the number of tasks on that admin page goes up by one, as would be expected. However, the number of queries used render the page of tasks goes up by 4 each time a new order is placed.
> This seems bad. I asked about this in the seam forum, and got this back from Gavin:
> --begin quote
> AFAIK, this is a jBPM question, not a Seam question, unless you have evidence otherwise.
> --end quote
> The specific bit of code in the seam bpm libs that is being called is :
> return ManagedJbpmContext.instance()
> .getGroupTaskList( new ArrayList( Actor.instance().getGroupActorIds() ) );
> which is basically just calling getGroupTaskList on an org.jbpm.JbpmContext instance.
> Reference to the post in the seam forum:
> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=114668
--
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
16 years, 6 months
[JBoss JIRA] Updated: (JBPM-756) log.debug calls are unprotected
by Thomas Diesler (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-756?page=all ]
Thomas Diesler updated JBPM-756:
--------------------------------
Assignee: (was: Ronald van Kuijk)
> log.debug calls are unprotected
> -------------------------------
>
> Key: JBPM-756
> URL: http://jira.jboss.com/jira/browse/JBPM-756
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Core Engine
> Affects Versions: jBPM 3.1.2
> Environment: Window XP, Java 5
> Reporter: Dave Caruana
>
> Within org.jbpm.context.exe.VariableContainer there are calls to log.debug. In particular:
> line 156: log.debug("create variable '"+name+"' in '"+this+"' with value '"+value+"'");
> line 160: log.debug("update variable '"+name+"' in '"+this+"' to value '"+value+"'");
> However, they are unprotected i.e. the method is called even if debug logging is not switched on. This is not too much of a problem if the variable value is of a primitive type, but sometimes, values can be complex (including their toString()).
> "if (log.isDebugEnabled())" statements are missing.
--
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
16 years, 6 months
[JBoss JIRA] Updated: (JBPM-1056) CompositeCommand misimplementation
by Thomas Diesler (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-1056?page=all ]
Thomas Diesler updated JBPM-1056:
---------------------------------
Assignee: (was: Tom Baeyens)
> CompositeCommand misimplementation
> ----------------------------------
>
> Key: JBPM-1056
> URL: http://jira.jboss.com/jira/browse/JBPM-1056
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Core Engine
> Affects Versions: jBPM jPDL 3.2.2, jBPM jPDL 3.2.1, jBPM jPDL 3.2, jBPM 3.1.4, jBPM 3.1.3, jBPM 3.1.2, jBPM 3.1.1, jBPM 3.1
> Reporter: Edward Staub
>
> CompositeCommand doesn't copy fields from one command to the next, as I THINK is intended.
> This was reported in
> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=90146&postdays=0...
> on October 11 2006 at 11:23 AM., along with a proposed fix. But it was never JIRA'd and never fixed.
> Secondarily... AFAIK, there is not one word of documentation (example, test, javadoc, anything) explaining how CompositeCommand is supposed to work.
--
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
16 years, 6 months
[JBoss JIRA] Updated: (JBPM-1071) Possible problem in concurrent signalling from multiple threads
by Thomas Diesler (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-1071?page=all ]
Thomas Diesler updated JBPM-1071:
---------------------------------
Assignee: (was: Len DiMaggio)
> Possible problem in concurrent signalling from multiple threads
> ---------------------------------------------------------------
>
> Key: JBPM-1071
> URL: http://jira.jboss.com/jira/browse/JBPM-1071
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Core Engine
> Affects Versions: jBPM jPDL 3.2.2
> Environment: Linux 2.6.21-1.3228.fc7 #1 SMP Tue Jun 12 14:56:37 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
> MySQL 5.0.22
> Reporter: Jiri Pechanec
> Priority: Critical
> Attachments: expl.tar.gz, LockingTest.java, log.txt
>
>
> Attached is a simple test case that
> 1) Deploys process definition with two nodes
> 2) Starts the process instance that will go to the wait state on first node
> 3) Starts 20 threads that tries concurrently signal the same process instance
> 4) The second node writes a record to the database
> The test case needs to be executed multiple times to see the incorrect behaviour.
> This is an example of run output
> Isol 8
> Action 1
> Action 2
> Action 2
> Action 2
> Action 2
> Action 2 1
> Action 2 1
> Action 2 1
> Action 2 1
> Signalist 5
> Signalist 6
> Signalist 8
> Signalist 12
> Signalist 7
> Signalist 13
> Signalist 14
> Signalist 15
> Signalist 9
> Signalist 16
> Signalist 17
> Signalist 18
> Signalist 4
> Success 7
> Failure 13
> Explanation of the outcome
> 4 threads successfully executed the node action including database operation. All database opeartion were comitted (4 new records were created)
> 3 threads successfully executed the signal operation but no real action was performed
> 13 threads attempted to execute the signal operation but ended with an exception
--
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
16 years, 6 months
[JBoss JIRA] Updated: (JBPM-826) Incorrect action exception handling
by Thomas Diesler (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-826?page=all ]
Thomas Diesler updated JBPM-826:
--------------------------------
Assignee: (was: Alejandro Guizar)
> Incorrect action exception handling
> -----------------------------------
>
> Key: JBPM-826
> URL: http://jira.jboss.com/jira/browse/JBPM-826
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Core Engine
> Affects Versions: jBPM 3.1.3
> Environment: Eclipse + Tomcat + JDK 6.0
> Reporter: Pedro Silva
> Priority: Critical
>
> If an action in a process definition throws an exception it doesn't correctly reach the client class, e.g. the class doing the signalling.
> Imagine that you have a process definition that in one of the task as an action that opens a file for reading. If the file cannot be found there will be an exception. Te exception is thrown and when it reaches the class, where the code for signalling is, you can't see the exception message. If you try to do, in the catch block, System.err.println(e.getMessage()) the result is null! However if you print System.err.println(e.getCause().getMessage()) the result is the file not found exception.
> This is worst in the case when you caught the exception in the action delegated class and you throw your own exception by explicitly doing: throw new MyException("Some error"); and the message still is null.
> In the case where the exception occurs in another class than the one of the action (if the execute code of the action invokes another class), even the code System.err.println(e.getCause().getMessage()) outputs null.
> The documentattion clearly states in 9.7 Exception Handling:
> "...Uncaught exceptions are thrown to the client (e.g. the client that called the token.signal()) or the exception is caught by a jBPM exception-handler. ..."
--
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
16 years, 6 months
[JBoss JIRA] Updated: (JBPM-1057) unsaved type for VariableInstance
by Thomas Diesler (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-1057?page=all ]
Thomas Diesler updated JBPM-1057:
---------------------------------
Assignee: (was: Tom Baeyens)
> unsaved type for VariableInstance
> ----------------------------------
>
> Key: JBPM-1057
> URL: http://jira.jboss.com/jira/browse/JBPM-1057
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Core Engine
> Affects Versions: jBPM 3.1.4, jBPM 3.1.3, jBPM jPDL 3.2.3
> Reporter: renaud chone
> Priority: Minor
>
> When creating a new process with Integer variables, I retrieve the same variables as a Long in a new session. In the database, the converter_ column contains only null values.
> I've identified the problem: there were two instances of IntegerToLongConverter. This is most likely a mistake but it's really hard to find. It would be a good idea to make the converter classes singleton or to use the class instead of the instance as a key in the HashMap of org.jbpm.db.hibernate.Converters.
--
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
16 years, 6 months