[JBoss Tools] - 64 bit xulrunner - has anyone got one, or detailed steps to build one?
by Steve Kohler
Steve Kohler [http://community.jboss.org/people/sck] created the discussion
"64 bit xulrunner - has anyone got one, or detailed steps to build one?"
To view the discussion, visit: http://community.jboss.org/message/560316#560316
--------------------------------------------------------------
Hi All,
Has anyone got a resolution to the xulrunner (JBoss tools) problem for 64 bit windows? I found the following how to:
"Q: How do I build the 64-bit version of SWT GTK?
A: Follow these steps to extract the 64-bit SWT GTK source code from CVS and produce your own build:
0.1. Start Eclipse and retrieve the org.eclipse.swt, org.eclipse.swt.gtk.linux.x86_64 and org.eclipse.swt.tools projects from dev.eclipse.org (see How to use SWT from CVS, use .classpath_gtk as the .classpath file in the org.eclipse.swt project).
0.2. Convert SWT's Java and C code from its 32-bit form to 64-bit: * To convert the Java code in-place, go to the build.xml ant script in the org.eclipse.swt.gtk.linux.x86_64 project and run its "replace.32.to.64" target. Once this target has completed you must refresh (F5) the org.eclipse.swt project in order to pick up the changes. * To convert and build the C code, run the "buildNatives" target in the same build.xml file. Refresh (F5) the org.eclipse.swt.gtk.linux.x86_64 project when this target has completed, to pick up the new libraries.
0.3. You're done! The org.eclipse.swt.gtk.linux.x86_64 project will now contain the 64-bit native libraries, and if you're interested, the 64-bit source code will now be available in the org.eclipse.swt.gtk.linux.x86_64/src folder."
It sounds easy, but I've had the following problems:
1. Can't get to the CVS repository from eclipse. (I've tried the dev.eclipse.org site with /cvsroot/eclipse anonymous and a set of newer parameters listed on the eclipse website.) This may be a firewall problem but I'm not sure.
2. Attempted to use the SWT .zip file downloaded from eclipse and unzipped as the basis for a project to follow above steps after creating project, but can't seem to get that to do what it's suppose to either. I have fooled around with the build.xml, tweaking and running the targets individually, but no success yet and can't help wondering if it's really supposed to be this complicated, or if I'm missing something that I'm just not seeing. Also, when I extracted the inner src.zip file (to the same level as the zip file itself for lack of any instructions), there were numerous "ActionErrors cannot be resolved to a type" messages after I refreshed the project.
Has anyone actually created a 64 bit xulrunner that can be used by the JBoss tool plugins? If so can you point me to the instructions and/or an actual working example or steps that will really work?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/560316#560316]
Start a new discussion in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 7 months
[EJB3] - EJB 3.1 Timer problems in scheduling recurring task
by Andrea Bennati
Andrea Bennati [http://community.jboss.org/people/andrea-b] created the discussion
"EJB 3.1 Timer problems in scheduling recurring task"
To view the discussion, visit: http://community.jboss.org/message/579029#579029
--------------------------------------------------------------
I'm trying to use an EJB 3.1 Timer to schedule a recurring task every 5 minutes.
I'm using JBOSS 6.0.0.Final.
This is the simple code I have deployed:
import javax.ejb.Schedule;
import javax.ejb.Stateless;
import javax.ejb.Timeout;
/**
* Session Bean implementation class AlerMonitorBean
*/
@Stateless
public class AlerMonitorBean {
/**
* Default constructor.
*/
public AlerMonitorBean() {
// TODO Auto-generated constructor stub
}
@Schedule(minute="0/5")
public void GestisciAlert() {
System.out.println("Gestisti Alert - Tick"+System.currentTimeMillis());
}
@Timeout
public void GestisciTimeout(){
System.out.println("Timeout");
}
}
import javax.ejb.Schedule;
import javax.ejb.Stateless;
import javax.ejb.Timeout;
/**
* Session Bean implementation class AlerMonitorBean
*/
@Stateless
public class AlerMonitorBean {
/**
* Default constructor.
*/
public AlerMonitorBean() {
// TODO Auto-generated constructor stub
}
@Schedule(minute="*/5")
public void GestisciAlert() {
System.out.println("Gestisti Alert - Tick -> "+System.currentTimeMillis());
//TODO: insert code
}
}
I notice the following in Jboss Console:
15:40:00,006 INFO [STDOUT] Gestisti Alert - Tick -> 1294238400006
15:40:00,010 INFO [STDOUT] Gestisti Alert - Tick -> 1294238400010
15:40:01,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238401004
15:40:02,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238402004
15:40:03,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238403004
15:40:04,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238404004
15:40:05,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238405004
15:40:06,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238406004
15:40:07,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238407004
15:40:08,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238408003
15:40:09,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238409004
15:40:10,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238410003
15:40:11,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238411004
15:40:12,006 INFO [STDOUT] Gestisti Alert - Tick -> 1294238412006
15:40:13,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238413004
15:40:14,008 INFO [STDOUT] Gestisti Alert - Tick -> 1294238414008
15:40:15,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238415004
15:40:16,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238416004
15:40:17,008 INFO [STDOUT] Gestisti Alert - Tick -> 1294238417008
15:40:18,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238418004
15:40:19,003 INFO [STDOUT] Gestisti Alert - Tick -> 1294238419003
15:40:20,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238420004
15:40:21,003 INFO [STDOUT] Gestisti Alert - Tick -> 1294238421003
15:40:22,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238422004
15:40:23,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238423003
15:40:24,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238424004
15:40:25,003 INFO [STDOUT] Gestisti Alert - Tick -> 1294238425003
15:40:26,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238426004
15:40:27,003 INFO [STDOUT] Gestisti Alert - Tick -> 1294238427003
15:40:28,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238428004
15:40:29,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238429004
15:40:30,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238430004
15:40:31,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238431004
15:40:32,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238432004
15:40:33,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238433004
15:40:34,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238434004
15:40:35,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238435004
15:40:36,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238436004
15:40:37,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238437004
15:40:38,005 INFO [STDOUT] Gestisti Alert - Tick -> 1294238438005
15:40:39,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238439004
15:40:40,003 INFO [STDOUT] Gestisti Alert - Tick -> 1294238440003
15:40:41,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238441004
15:40:42,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238442004
15:40:43,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238443004
15:40:44,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238444004
15:40:45,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238445004
15:40:46,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238446004
15:40:47,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238447004
15:40:48,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238448004
15:40:49,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238449004
15:40:50,003 INFO [STDOUT] Gestisti Alert - Tick -> 1294238450003
15:40:51,003 INFO [STDOUT] Gestisti Alert - Tick -> 1294238451003
15:40:52,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238452004
15:40:53,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238453004
15:40:54,003 INFO [STDOUT] Gestisti Alert - Tick -> 1294238454003
15:40:55,008 INFO [STDOUT] Gestisti Alert - Tick -> 1294238455008
15:40:56,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238456004
15:40:57,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238457003
15:40:58,004 INFO [STDOUT] Gestisti Alert - Tick -> 1294238458004
15:40:59,003 INFO [STDOUT] Gestisti Alert - Tick -> 1294238459003
I expected that method "GestisciAlert" was called once every 5 minutes.....
Every 5 minutes Timer starts and activates target method several times (about once per second) for a minute....
Then it stops and starts again after 4 minutes.
Hope someone can help me.
Andrea
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/579029#579029]
Start a new discussion in EJB3 at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 8 months
[jBPM] - can not end subprocess in concurrent execution (jBPM4.4)
by Philipp Ossler
saig0 [http://community.jboss.org/people/saig0] created the discussion
"can not end subprocess in concurrent execution (jBPM4.4)"
To view the discussion, visit: http://community.jboss.org/message/561928#561928
--------------------------------------------------------------
Hi!
I have a problem with jBPM 4.4 when I try to end a subprocess instance in a concurrent execution.
This image show an example process:
http://community.jboss.org/servlet/JiveServlet/showImage/2-561928-7482/su... http://community.jboss.org/servlet/JiveServlet/downloadImage/2-561928-748...
The process should execute a subprocess and wait of a signal in the concurrent execution. When a signal arrive, an external activity behavior (end subprocess) should call that will end the subprocess and both executions will join.
I can run this process correct with jBPM 4.3 but when i try to run with jBPM 4.4 the follow JbpmExecution throw:
com.ecg.mts.pcc.exceptions.PccException: EXCEPTION_tried to send signal: null to execution with id: SimpleProcess.57.63
at com.ecg.mts.pcc.internal.jbpm.control.jbpm.JbpmProcessInstanceManager.tryToSendSignalToExecution(JbpmProcessInstanceManager.java:209)
at com.ecg.mts.pcc.internal.jbpm.control.jbpm.JbpmProcessInstanceManager.sendSignalToActivity(JbpmProcessInstanceManager.java:191)
at com.ecg.mts.pcc.internal.jbpm.JbpmProcessInstanceManagerTest.testEndSubProcessInstanceInExternalActivity(JbpmProcessInstanceManagerTest.java:174)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at com.ecg.test.testcase.AbstractDbTestCase.run(AbstractDbTestCase.java:195)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: com.ecg.mts.pcc.exceptions.PccException: EXCEPTION_tried to delete processInstance with id: SimpleSubProcess.64
at com.ecg.mts.pcc.internal.jbpm.control.jbpm.JbpmProcessInstanceManager.endProcessInstanceById(JbpmProcessInstanceManager.java:91)
at com.ecg.mts.pcc.internal.jbpm.control.jbpm.JbpmProcessInstanceManager$1.execute(JbpmProcessInstanceManager.java:107)
at org.jbpm.pvm.internal.svc.DefaultCommandService.execute(DefaultCommandService.java:42)
at org.jbpm.pvm.internal.svc.SkipInterceptor.execute(SkipInterceptor.java:40)
at org.jbpm.pvm.internal.processengine.ProcessEngineImpl.execute(ProcessEngineImpl.java:300)
at com.ecg.mts.pcc.internal.jbpm.control.jbpm.JbpmEngine.executeCommand(JbpmEngine.java:194)
at com.ecg.mts.pcc.internal.jbpm.control.jbpm.JbpmProcessInstanceManager.endProcessInstanceByIdCascade(JbpmProcessInstanceManager.java:112)
at com.ecg.mts.pcc.internal.jbpm.control.jbpm.JbpmProcessInstanceManager$1.execute(JbpmProcessInstanceManager.java:106)
at org.jbpm.pvm.internal.svc.DefaultCommandService.execute(DefaultCommandService.java:42)
at org.jbpm.pvm.internal.svc.SkipInterceptor.execute(SkipInterceptor.java:40)
at org.jbpm.pvm.internal.processengine.ProcessEngineImpl.execute(ProcessEngineImpl.java:300)
at com.ecg.mts.pcc.internal.jbpm.control.jbpm.JbpmEngine.executeCommand(JbpmEngine.java:194)
at com.ecg.mts.pcc.internal.jbpm.control.jbpm.JbpmProcessInstanceManager.endProcessInstanceByIdCascade(JbpmProcessInstanceManager.java:112)
at com.ecg.mts.pcc.internal.jbpm.scenario.externalActivityBehaviour.EndSubProcess.execute(EndSubProcess.java:18)
at org.jbpm.pvm.internal.wire.usercode.UserCodeActivityBehaviour.execute(UserCodeActivityBehaviour.java:42)
at org.jbpm.pvm.internal.model.op.ExecuteActivity.perform(ExecuteActivity.java:60)
at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperationSync(ExecutionImpl.java:672)
at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperation(ExecutionImpl.java:632)
at org.jbpm.pvm.internal.model.ExecutionImpl.signal(ExecutionImpl.java:430)
at org.jbpm.pvm.internal.cmd.SignalCmd.execute(SignalCmd.java:61)
at org.jbpm.pvm.internal.cmd.SignalCmd.execute(SignalCmd.java:35)
at org.jbpm.pvm.internal.svc.DefaultCommandService.execute(DefaultCommandService.java:42)
at org.jbpm.pvm.internal.tx.StandardTransactionInterceptor.execute(StandardTransactionInterceptor.java:50)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.executeInNewEnvironment(EnvironmentInterceptor.java:53)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:40)
at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:56)
at org.jbpm.pvm.internal.svc.SkipInterceptor.execute(SkipInterceptor.java:43)
at org.jbpm.pvm.internal.svc.ExecutionServiceImpl.signalExecutionById(ExecutionServiceImpl.java:89)
at com.ecg.mts.pcc.internal.jbpm.control.jbpm.JbpmProcessInstanceManager.tryToSendSignalToExecution(JbpmProcessInstanceManager.java:205)
... 22 more
Caused by: org.jbpm.api.JbpmException: execution[SimpleProcess.57.62] has running subprocess: execution[SimpleSubProcess.64] in state remove
at org.jbpm.pvm.internal.model.ExecutionImpl.checkActive(ExecutionImpl.java:1086)
at org.jbpm.pvm.internal.model.ExecutionImpl.signal(ExecutionImpl.java:424)
at org.jbpm.pvm.internal.model.ExecutionImpl.signal(ExecutionImpl.java:412)
at org.jbpm.pvm.internal.model.ExecutionImpl.end(ExecutionImpl.java:393)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:197)
at org.jbpm.pvm.internal.model.ExecutionImpl_$$_javassist_189.end(ExecutionImpl_$$_javassist_189.java)
at org.jbpm.pvm.internal.cmd.EndProcessInstance.execute(EndProcessInstance.java:48)
at org.jbpm.pvm.internal.svc.DefaultCommandService.execute(DefaultCommandService.java:42)
at org.jbpm.pvm.internal.svc.SkipInterceptor.execute(SkipInterceptor.java:40)
at org.jbpm.pvm.internal.svc.ExecutionServiceImpl.endProcessInstance(ExecutionServiceImpl.java:117)
at com.ecg.mts.pcc.internal.jbpm.control.jbpm.JbpmProcessInstanceManager.endProcessInstanceById(JbpmProcessInstanceManager.java:87)
... 50 more
org.jbpm.api.JbpmException: execution[SimpleProcess.57.62] has running subprocess: execution[SimpleSubProcess.64] in state remove
at org.jbpm.pvm.internal.model.ExecutionImpl.checkActive(ExecutionImpl.java:1086)
at org.jbpm.pvm.internal.model.ExecutionImpl.signal(ExecutionImpl.java:424)
at org.jbpm.pvm.internal.model.ExecutionImpl.signal(ExecutionImpl.java:412)
at org.jbpm.pvm.internal.model.ExecutionImpl.end(ExecutionImpl.java:393)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:197)
at org.jbpm.pvm.internal.model.ExecutionImpl_$$_javassist_189.end(ExecutionImpl_$$_javassist_189.java)
at org.jbpm.pvm.internal.cmd.EndProcessInstance.execute(EndProcessInstance.java:48)
at org.jbpm.pvm.internal.svc.DefaultCommandService.execute(DefaultCommandService.java:42)
at org.jbpm.pvm.internal.svc.SkipInterceptor.execute(SkipInterceptor.java:40)
at org.jbpm.pvm.internal.svc.ExecutionServiceImpl.endProcessInstance(ExecutionServiceImpl.java:117)
...
I tried to end the subprocess instance like this:
executionService.endProcessInstance(processInstanceId, "remove");
(processInstanceId is the id of the execution in activity 'subprocess')
I also tried to send a signal to this execution but it throw the same exception.
It seems that I have to end the subprocess instance first, so I tried something like that but it doesn't work and throw the exception.
public void endProcessInstanceByIdCascade(final String processInstanceId) {
Command<Object> command = new Command<Object>() {
public Object execute(Environment environment) throws Exception {
ProcessInstance processInstance = executionService.findProcessInstanceById(processInstanceId);
Execution subProcessInstance = processInstance.getSubProcessInstance();
if (subProcessInstance != null) endProcessInstanceByIdCascade(subProcessInstance.getId());
executionService.endProcessInstance(processInstanceId, "remove");
return null;
}
};
processEngine.execute(command);
}
Did I make something wrong or is this a bug in jBPM 4.4?
Thank you for help!
Phil
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/561928#561928]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 8 months
[JBoss Web Services] - How to define context-root or URL for web service?
by Baradon Terendil
Baradon Terendil [http://community.jboss.org/people/baradon] created the discussion
"How to define context-root or URL for web service?"
To view the discussion, visit: http://community.jboss.org/message/582125#582125
--------------------------------------------------------------
Hi,
I would like to define the URL under which a web service is reachable. My web service is based on a stateless session bean. I know, that there is the @WebContext annotation, but I would like to keep my code free from any JBoss specific things.
The session bean/web service is implementen in a JAR file, which then is included in an EAR file. In fact, I have several JAR files, some of them implementing their own web services. All of them are included in the EAR file. This EAR file is project specific, and I would like to define the URL (or at least the context root) in that file, leaving the JAR file untouched.
Is such a solution possible? If yes, how can I achieve that?
Thanks and best regards,
Heiner
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/582125#582125]
Start a new discussion in JBoss Web Services at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 8 months
