[jBPM Users] - JBPM 4 dynamic timer duedate
by newcomer1
What is the best practice for setting dynamic duedates on timers in jbpm4?
I have a use case were I need to signal a transition at a specific date/time depending on a variable(java.util.Date) in the business process.
In the example below start is a Date variable on the process and this fails due to a classcast exception. This way of setting a dynamic duedate seems to be supported in jbpm 3.x. (e.g. http://docs.jboss.org/jbpm/v3.2/userguide/html/businesscalendar.html).
| <state name="waiting">
| <transition name="to out" to="out">
| <timer duedate="#{start} - 1 days" />
| </transition>
| ..
| </state>
|
Part of stacktrace:
| ERROR [ExecuteJobCmd] exception while executing 'ExecuteActivityMessage[11]'
|
| java.lang.ClassCastException: java.util.Date cannot be cast to java.lang.String
| at org.jbpm.pvm.internal.job.TimerImpl.setDueDateDescription(TimerImpl.java:76)
| at org.jbpm.pvm.internal.model.ScopeInstanceImpl.createTimer(ScopeInstanceImpl.java:303)
| at org.jbpm.pvm.internal.model.ScopeInstanceImpl.initializeTimers(ScopeInstanceImpl.java:323)
| at org.jbpm.pvm.internal.model.ExecutionImpl.createScope(ExecutionImpl.java:262)
A quick peak in the jbpm source code seems to reveal that the wanted behavior is not possible, hence the starting question. Do i need to create and persist the timer manually? (e.g. node enter event listener)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4270032#4270032
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4270032
15 years, 1 month
[JBoss Tools Users] - 3.1.0 nightly update fails for jPDL, bpel plugins
by bdlink
System is windows 7, Eclipse 3.5 EE with JBT 3.1.0 nightly update site //download.jboss.org/jbosstools/updates/nightly/trunk/ The BIRT update site http://download.eclipse.org/birt/update-site/2.5 is also enabled. The only plugins on top of Eclipse EE are checkstyle, subclipse and m2eclipse. I have been updateing daily (with the jPDL update unchecked since it started failing).
The bulk of the JBT plugins are at H34 and the update is H40. THe JBoss jPDL tools are at 3.2.0.v200910261201N-H27-RC1 and the update wants org.jbpm.gd.jpdl.feature.feature.group3.2.0.v200912080327-41-7w311A23191438. The JBpss BPEL Editor is at 1.0.0.v200912081204N-H34-GA and the update is org.jboss.tools.bpel.feature.feature.group1.0.0.v200912090331-27q-FAFkNP1ZkP1NwwZ
Interestingly, the jBPM tools runtime is at jBPM 4 Tools Runtime 4.0.0.v200912080349-773-88H3CH-F9QSGFOOHIPVx422B org.jboss.tools.jbpm4.feature.feature.group whereas the jBPM jPDL tools is at 3.2
For the last few weeks, the jPDL update has been failing and the only way to update JBT is to uncheck it. Today, in addition the following bpel ones also failed with the following message:An error occurred while collecting items to be installed
| session context was:(profile=epp.package.jee, phase=org.eclipse.equinox.internal.provisional.p2.engine.phases.Collect, operand=, action=).
| Problems downloading artifact: osgi.bundle,org.jbpm.gd.jpdl,3.2.0.v200912080327.
| Unpacking fails because intermediate file is empty: C:\Users\blink\AppData\Local\Temp\work6718214770681077360\p2.optimizers.incoming4571294547687034735.jar
| Problems downloading artifact: osgi.bundle,org.eclipse.bpel.common.ui,0.5.0.v200912090331.
| Unpacking fails because intermediate file is empty: C:\Users\blink\AppData\Local\Temp\work6781773857109872534\p2.optimizers.incoming375636462944740258.jar
| Problems downloading artifact: osgi.bundle,org.eclipse.bpel.ui,0.5.0.v200912090331.
| Unpacking fails because intermediate file is empty: C:\Users\blink\AppData\Local\Temp\work2135299298996056344\p2.optimizers.incoming1458072181015840034.jar
| Problems downloading artifact: osgi.bundle,org.eclipse.bpel.validator,0.5.0.v200912090331.
| Unpacking fails because intermediate file is empty: C:\Users\blink\AppData\Local\Temp\work4222297386252367799\p2.optimizers.incoming8128901940429895743.jar
| Problems downloading artifact: osgi.bundle,org.eclipse.bpel.wsil.model,0.5.0.v200912090331.
| Unpacking fails because intermediate file is empty: C:\Users\blink\AppData\Local\Temp\work6332140314794074277\p2.optimizers.incoming5999961151256381330.jar
|
By the way, if the readers have not found the site yet, the JBoss Community Asylum podcasts at http://asylum.libsyn.com/ are excellent.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4270029#4270029
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4270029
15 years, 1 month
[JBoss Web Services Users] - JBOSSWS Webservice Error in UNIX
by narmashan
I am testing a webservice using JBOSS5,JBOSSWS and jdk 6 in unix system.
My webservice got deployed and worked well in Windows. Client was able to able to access the HTTP response fine.
Windows XP Environment Tools:
a) JBOSS AS5
b)JBOSS WS
c)JDK 5.0
Steps followed to install in Windows
# From Windows Explorer, navigate to "C:\jbossws-native-bin-dist". Inside the folder, locate the file "ant.properties.example".
# Make a copy of "ant.properties.example", then rename it to "ant.properties".
# Start up your favorite code editor (like UltraEdit32, or Notepad++), then open up "ant.properties" for editing.
# Locate the line "jboss500.home=(a)jboss500.home@", change it to "jboss500.home=/jboss-5.0.0.GA". Then save it and close the code editor.
# Open Command Prompt, navigate to "C:\jbossws-native-bin-dist". Then run the command "ant deploy-jboss500". When it finishes successfully, JBossWS will be installed and configured properly for use.
Unix Environment:
JDK 6
JBOSS 5.0
Copied the JBOSSWS jar files from C:\jbossws-native-bin-dist\output\deploy-jboss500folder to corresponding folders in client, bin,common,lib,server in Unix.
When I start the JBOSSAS I am able to view the webservice and wsdl is generated but while testing the webservic in client I get the following error:
javax.xml.ws.WebServiceException: Cannot process response message
at org.jboss.ws.core.jaxws.client.DispatchSOAPBinding.getReturnObject(DispatchSOAPBinding.java:191)
at org.jboss.ws.core.jaxws.client.DispatchImpl.getReturnObject(DispatchImpl.java:470)
at org.jboss.ws.core.jaxws.client.DispatchImpl.invokeInternalSOAP(DispatchImpl.java:264)
at org.jboss.ws.core.jaxws.client.DispatchImpl.invokeInternal(DispatchImpl.java:170)
at org.jboss.ws.core.jaxws.client.DispatchImpl.invoke(DispatchImpl.java:133)
at tutorial.hanbo.webservice.GreetingTestClient2.main(GreetingTestClient2.java:60)
Caused by: javax.xml.soap.SOAPException: Cannot obtain SOAPBody from SOAPMessage
at javax.xml.soap.SOAPMessage.getSOAPBody(SOAPMessage.java:181)
at org.jboss.ws.core.jaxws.client.DispatchSOAPBinding.getReturnObject(DispatchSOAPBinding.java:159)
While Analyzing using TCP monitor I find that content length is zero
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Powered-By: Servlet 2.5; JBoss-5.0/JBossWeb-2.1
Content-Length: 0
Date: Thu, 10 Dec 2009 15:27:26 GMT
I assume it has something to do with JBOSSWS jar files used in Unix.
Could anyone help in this regard ? Grealty appreciate it.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4270026#4270026
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4270026
15 years, 1 month
[JNDI and Naming] - Re: EJB (SLSB) invocation ignores read timeout, blocks indef
by sumitsu
Thanks to another forum post by someone with a simlar issue (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250461), I found a way to "seed" the invoker proxy returned by JNDI lookup with a desired read timeout value, thus enforcing the timeout upon each invocation of a service within the bean.
The timeout setting, somewhat counter-intuitively, is maintained on the server side rather than specified by the client; follow these steps to add the timeout value:
(1) Edit server/CONF/deploy/ejb3.deployer/META-INF/jboss-service.xml (where CONF is the container configuration you are using)
(2) Modify the mbean
| <mbean code="org.jboss.remoting.transport.Connector"
| name="jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3">
|
(3) Alter the socket:// URI given by the InvokerLocator attribute to add the suffix /?timeout=#####, where ##### is the desired timeout value, in milliseconds
Upon the change to the configuration, the new timeout value is reflected in the client-side TRACE logs referencing a number to which the timeout value is set (which previously indicated a blocking timeout of 0). Running the deliberate-stall test code detailed in the previous post produces a read timeout such as the following, where formerly it had stalled out:
| java.lang.reflect.UndeclaredThrowableException
| ...
| Caused by: java.rmi.MarshalException: Socket timed out. Waited 5000 milliseconds for response while calling on InvokerLocator [socket://(node1):31516/?timeout=5000]; nested exception is:
| ...
| Caused by: java.net.SocketTimeoutException: Read timed out
| ...
|
It is confusing to me that this timeout is implemented as a server-side configuration rather than by obtaining it from the parameters (jnp.timeout and jnp.sotimeout) specified by the client when the JNDI context is created, since the latter option would seem to provide more flexibility to the client. As it stands, this solution would appear to apply to all remote invocations to all EJB3 services running on the app server.
If anyone in the know regarding the design logic behind this approach would like to provide an explanation, I would be interested in hearing it. (For that matter, if anyone knows of an alternative way to produce the same timeout effect, I would be interested in that as well.)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4270022#4270022
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4270022
15 years, 1 month