[Design of JBoss jBPM] - Re: Thinking about transition attrs
by tom.baeyens＠jboss.com
"brittm" wrote : The process patch thread got me thinking about some things I've been wanting to see in Transition configuration.
|
| 1) Is anything in the works to allow a process designer to suggest to the UI that a user be asked to "confirm" a particular transition? For instance, when completing a task, one option might be 'done' while the other option is 'cancel'. If the user selects 'cancel', the process designer may want to suggest that he user be asked to confirm that choice.
| Something like <transition name='...' to='...' confirm='true'/>
|
that is UI. the task form ui only can do so much. we can keep adding features till it is as rich as JSF+Facelets+RichFaces... if it would be added, it should be done in the Facelets form document. that is where you could reference java script or a new component.
i don't think this info should be added to the process definition itself.
"brittm" wrote :
| 2) Is anything coming up that would allow the process designer to suggest to the UI that a transition should be restricted to administrative use? For instance, transitions that you would like to be available to application adminsitrators or administrative tools, but not available to the typical user--I might not want a typical user to revisit a node handling integration 20 times in one hour, but I might want an admin to be able to retry it after the problem has been solved--same thing for some types of cancellation.
| Something like <transition name='...' to='...' restricted='true'/> or refer to a UI's roll based system with <transition name='...' to='...' role='admin'/>
|
| I know there have be plenty of words put out discussing where certain types of configuration ought to go. Thoughts?
|
| -Britt
same here. to implement this, we should be looking at configuring the task form transition button in some way. probably this is already possible in facelets with the use of a simple if tag around the transition button.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052992#4052992
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052992
18 years, 10 months
[Design of JBoss jBPM] - Re: Timer servlet
by tom.baeyens＠jboss.com
yes, it should be added.
here's some argumentation for this:
if the job thread servlet and the other servlets are all separate war files as you propose, it's going to be a nightmare for people to get that set up right.
i want to provide to our users the simplest and best possible evaluation platform out of the box. developers must be able to get up and running quickly.
that is where i think your proposed solutions differ from my position. from a design standpoint, i think you're right. but has turned out not easy for people to start managing a bunch of deployment files.
the more artifacts they encounter, the more difficult it gets.
the suite distribution should be as integrated as possible. then the docs should explain how the different pieces can be decoupled and configured.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052988#4052988
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052988
18 years, 10 months
[Design of JMX on JBoss (JBoss/JMX)] - Abnormal shutdown of JBoss
by jboss2005_01
Hello everybody,
First of all, I am not sure if this is the correct forum to post this topic.
I guess this is related to the core functionality of the AS.
I am trying to develop a MBean that acts like a SMS sending/receiving service. At first sight, everything seems to work normal. But when I send the shutdown command to the application server (CTRL+C since it is a Windows machine) everything goes wrong. I get a very long output in the console with a bunch of JBoss Shutdown Hooks. It seems like JBoss is no longer able to shutdown normally in this case. The service uses SMSLib (http://smslib.sourceforge.net/) which communicates through the COM-port with a GSM modem. This library works fine in a stand-alone application.
I have the following questions:
1. What causes such a JBoss Shutdown Hook message in the console. Could this be caused by the fact that the SAR uses user threads?
2. My application needs to create user threads to listen at different JMS queues, is this the appropriate way to do so or is it better to retrieve user threads from a thread pool? If so, how can this be achieved.
Any response would be highly appreciated.
Below you will find an extract of the output generated by the application server.
| 2007-06-08 16:26:10,919 INFO [org.jboss.system.server.Server] Runtime shutdown hook called, forceHalt: true
| 2007-06-08 16:26:10,919 INFO [STDOUT] 911566 [JBoss Shutdown Hook] INFO org.jboss.system.server.Server - Runtime shutdown hook called, forceHalt: true
| 2007-06-08 16:26:10,919 INFO [org.jboss.system.server.Server] JBoss SHUTDOWN: Undeploying all packages
| 2007-06-08 16:26:10,919 INFO [STDOUT] 911566 [JBoss Shutdown Hook] INFO org.jboss.system.server.Server - JBoss SHUTDOWN: Undeploying all packages
| 2007-06-08 16:26:10,919 DEBUG [org.jboss.deployment.MainDeployer] Undeploying file:/D:/jboss-4.0.5.GA/server/default/deploy/deploy.last/, isShutdown=true
| 2007-06-08 16:26:10,919 INFO [STDOUT] 911566 [JBoss Shutdown Hook] DEBUG org.jboss.deployment.MainDeployer - Undeploying file:/D:/jboss-4.0.5.GA/server/default/deploy/deploy.last/, isShutdown=true
| 2007-06-08 16:26:10,919 DEBUG [org.jboss.deployment.MainDeployer] Stopping sub deployment: file:/D:/jboss-4.0.5.GA/server/default/deploy/deploy.last/SMSServer.sar/
| 2007-06-08 16:26:10,935 INFO [STDOUT] 911566 [JBoss Shutdown Hook] DEBUG org.jboss.deployment.MainDeployer - Stopping sub deployment: file:/D:/jboss-4.0.5.GA/server/default/deploy/deploy.last/SMSServer.sar/
| 2007-06-08 16:26:10,935 DEBUG [org.jboss.deployment.MainDeployer] Stopping sub deployment: file:/D:/jboss-4.0.5.GA/server/default/deploy/deploy.last/SMSServer.sar/smslib-2.1.4.jar
| 2007-06-08 16:26:10,935 INFO [STDOUT] 911582 [JBoss Shutdown Hook] DEBUG org.jboss.deployment.MainDeployer - Stopping sub deployment: file:/D:/jboss-4.0.5.GA/server/default/deploy/deploy.last/SMSServer.sar/smslib-2.1.4.jar
| 2007-06-08 16:26:10,935 DEBUG [org.jboss.deployment.SARDeployer] undeploying document file:/D:/jboss-4.0.5.GA/server/default/deploy/deploy.last/SMSServer.sar/
| 2007-06-08 16:26:10,935 INFO [STDOUT] 911582 [JBoss Shutdown Hook] DEBUG org.jboss.deployment.SARDeployer - undeploying document file:/D:/jboss-4.0.5.GA/server/default/deploy/deploy.last/SMSServer.sar/
| 2007-06-08 16:26:10,935 DEBUG [org.jboss.deployment.SARDeployer] stopping mbean tph.services:service=SMSServer
| 2007-06-08 16:26:10,935 INFO [STDOUT] 911582 [JBoss Shutdown Hook] DEBUG org.jboss.deployment.SARDeployer - stopping mbean tph.services:service=SMSServer
| 2007-06-08 16:26:10,935 DEBUG [org.jboss.system.ServiceController] stopping service: tph.services:service=SMSServer
| 2007-06-08 16:26:10,935 INFO [STDOUT] 911582 [JBoss Shutdown Hook] DEBUG org.jboss.system.ServiceController - stopping service: tph.services:service=SMSServer
| 2007-06-08 16:26:10,935 DEBUG [org.jboss.deployment.MainDeployer] Destroying sub deployment: file:/D:/jboss-4.0.5.GA/server/default/deploy/deploy.last/SMSServer.sar/
| 2007-06-08 16:26:10,935 INFO [STDOUT] 911582 [JBoss Shutdown Hook] DEBUG org.jboss.deployment.MainDeployer - Destroying sub deployment: file:/D:/jboss-4.0.5.GA/server/default/deploy/deploy.last/SMSServer.sar/
| 2007-06-08 16:26:10,935 DEBUG [org.jboss.deployment.MainDeployer] Destroying sub deployment: file:/D:/jboss-4.0.5.GA/server/default/deploy/deploy.last/SMSServer.sar/smslib-2.1.4.jar
| 2007-06-08 16:26:10,935 INFO [STDOUT] 911582 [JBoss Shutdown Hook] DEBUG org.jboss.deployment.MainDeployer - Destroying sub deployment: file:/D:/jboss-4.0.5.GA/server/default/deploy/deploy.last/SMSServer.sar/smslib-2.1.4.jar
| 2007-06-08 16:26:10,935 DEBUG [org.jboss.util.file.Files] Failed to delete dir: D:\jboss-4.0.5.GA\server\default\tmp\deploy\tmp20537smslib-2.1.4.jar
| 2007-06-08 16:26:10,935 INFO [STDOUT] 911582 [JBoss Shutdown Hook] DEBUG org.jboss.util.file.Files - Failed to delete dir: D:\jboss-4.0.5.GA\server\default\tmp\deploy\tmp20537smslib-2.1.4.jar
| 2007-06-08 16:26:10,935 DEBUG [org.jboss.deployment.DeploymentInfo] Could not delete file:/D:/jboss-4.0.5.GA/server/default/tmp/deploy/tmp20537smslib-2.1.4.jar restart will delete it
| 2007-06-08 16:26:10,935 INFO [STDOUT] 911582 [JBoss Shutdown Hook] DEBUG org.jboss.deployment.DeploymentInfo - Could not delete file:/D:/jboss-4.0.5.GA/server/default/tmp/deploy/tmp20537smslib-2.1.4.jar restart will delete it
| 2007-06-08 16:26:10,935 DEBUG [org.jboss.deployment.MainDeployer] Undeployed file:/D:/jboss-4.0.5.GA/server/default/deploy/deploy.last/SMSServer.sar/smslib-2.1.4.jar
| 2007-06-08 16:26:10,935 INFO [STDOUT] 911582 [JBoss Shutdown Hook] DEBUG org.jboss.deployment.MainDeployer - Undeployed file:/D:/jboss-4.0.5.GA/server/default/deploy/deploy.last/SMSServer.sar/smslib-2.1.4.jar
| 2007-06-08 16:26:10,935 DEBUG [org.jboss.deployment.SARDeployer] destroying mbean tph.services:service=SMSServer
| 2007-06-08 16:26:10,935 INFO [STDOUT] 911582 [JBoss Shutdown Hook] DEBUG org.jboss.deployment.SARDeployer - destroying mbean tph.services:service=SMSServer
| 2007-06-08 16:26:10,935 DEBUG [org.jboss.system.ServiceController] destroying service: tph.services:service=SMSServer
| 2007-06-08 16:26:10,935 INFO [STDOUT] 911582 [JBoss Shutdown Hook] DEBUG org.jboss.system.ServiceController - destroying service: tph.services:service=SMSServer
|
| And this goes on and on and on....
|
Greetings,
Kurt
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052987#4052987
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052987
18 years, 10 months
[Design of JBoss jBPM] - Re: JSF Components to move into main CVS
by tom.baeyens＠jboss.com
"david.lloyd(a)jboss.com" wrote : I've been considering what to do about the jBPM Facelets component library for the upcoming release, and I think it would be best to move it out of the new repository and into the current jBPM CVS repository. This allows the component library to track with jBPM releases and will make bug fixing and maintenance easier overall.
|
+1. good idea.
"david.lloyd(a)jboss.com" wrote :
| So, I want to make the following changes:
|
| * Add a jbpm4jsf subproject into the main CVS repository
| * Update the build system so that jbpm4jsf is built by default, and include it as a project dependency rather than as an external JAR
|
| Any objections or opinions?
please, do it as a new subproject of jbpm.3 in the same style as the other subprojects. if your problem is the build scripts, i can help you with those if you want.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052787#4052787
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052787
18 years, 10 months
[Design of JBoss jBPM] - Re: process patch files
by tom.baeyens＠jboss.com
"david.lloyd(a)jboss.com" wrote : That's a novel approach - but I think there is one main problem with it as suggested: we don't want users to actually be able to change the graph structure of their existing process (more specifically, anything that we consider to be static in the process definition) - we want them to be able to change *anything else* but that (like classes, extra process files [like images] or auxiliary XML data like GPD information).
|
| Maybe there could be a way to provide a process patch where just classes and files are provided, and changes to the XML that are not related to graph structure. Maybe a separate schema/DTD for updates that can clearly express this requirement.
could you explain why you make the difference between changing the graph structure and other changes ?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052786#4052786
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052786
18 years, 10 months