[jBPM] - jBPM5 Console Integration with Tomcat6
by bpmn2 user
bpmn2user [http://community.jboss.org/people/bpmn2user] created the discussion
"jBPM5 Console Integration with Tomcat6"
To view the discussion, visit: http://community.jboss.org/message/578103#578103
--------------------------------------------------------------
Here are the required steps to get the jBPM5 console running in Tomcat6
1.) Copy the console war files provided in JBPM_INSTALLER/lib into Tomcat’s webapps directory
These war files can also be downloaded from ( http://sourceforge.net/projects/jbpm/files/jBPM%205/jbpm-5.0-CR1/jbpm-5.0... http://sourceforge.net/projects/jbpm/files/jBPM%205/jbpm-5.0-CR1/jbpm-5.0...). This download has two war files jbpm-gwt-console-5.0-CR1.war and jbpm-gwt-console-server-5.0-CR1.war. Rename them to jbpm-console.war and gwt-console-server.war and copy them to TOMCAT_HOME/webapps
2.) Create users and roles in TOMCAT_HOME/conf/tomcat-users.xml.
Here is an example
<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
<role rolename="tomcat"/>
<role rolename="role1"/>
<role rolename="manager"/>
<role rolename="admin"/>
<role rolename="user"/>
<user username="tomcat" password="tomcat" roles="tomcat"/>
<user username="both" password="tomcat" roles="tomcat,role1"/>
<user username="role1" password="tomcat" roles="role1"/>
<user username="manager" password="manager" roles="manager"/>
<user username="krisv" password="krisv" roles="manager,admin,user"/>
<user username="john" password="john" roles="manager,admin,user"/>
<user username="mary" password="mary" roles="manager,admin,user"/>
</tomcat-users>
3.) Set the jbpm.console.directory in Catalina.bat (.sh)
Here is an example.
.. -Djbpm.console.directory=C:/jbpm5/CR1/jbpm-installer/sample/evaluation/src/main/resources ..
4.) Copy JBPM_INSTALLER\jboss-4.2.3.GA server\default\data\birt into TOMCAT_HOME\birt. This will provide the reporting functionality
5.) Copy the database driver (e.g., h2.jar) and all the dependant jar files into TOMCAT_HOME/lib.
Here are the required libraries:
jbpm-persistence-jpa-5.0-CR1.jar
h2-1.2.124.jar
persistence-api-1.0.jar
geronimo-jta_1.0.1B_spec-1.0.1.jar
javassist-3.4.GA.jar
hibernate-entitymanager-3.4.0.GA.jar
hibernate-core-3.3.0.SP1.jar
hibernate-commons-annotations-3.1.0.GA.jar
hibernate-annotations-3.4.0.GA.jar
ejb3-persistence-1.0.2.GA.jar
dom4j-1.6.1.jar
commons-collections-3.1.jar
antlr-2.7.6.jar
6.) Start database:
e.g, run ‘ant h2.start’ from JBPM_INSTALLER directory
7.) Start human task, e.g., run ‘ant start.human.task’ from JBPM_INSTALLER directory
This assumes that a datasource JNDI (jdbc/testDS1) is configured in Tomcat and a transaction manager (such as Bitronix or JOTM or Atomikos etc) is configured on Tomcat.
Refer to http://tomcat.apache.org/tomcat-6.0-doc/jndi-resources-howto.html http://tomcat.apache.org/tomcat-6.0-doc/jndi-resources-howto.html for JNDI configuration on Tomcat6.
Login to console http://localhost:8080/jbpm-console http://localhost:8080/jbpm-console (krisv/krisv)
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/578103#578103]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 5 months
[jBPM] - Error 400 on Build Package Click
by Tobias Wittur
Tobias Wittur [http://community.jboss.org/people/tob1as] created the discussion
"Error 400 on Build Package Click"
To view the discussion, visit: http://community.jboss.org/message/621389#621389
--------------------------------------------------------------
Hi,
I got the following error when I tryed to build the default sample repository after starting guvnor the first time.
I then tried to build my own package, and got the same error:
| | 400 Sorry, a technical error occurred. Please contact a system administrator. |
This is what the server log says:
> | 2011-08-17 15:52:44,813 INFO [STDOUT] (http-localhost%2F127.0.0.1-8080-1) ERROR 17-08 15:52:44,811 (LoggingHelper.java:error:69) | Service method 'public abstract org.drools.guvnor.client.rpc.BuilderResult org.drools.guvnor.client.rpc.PackageService.buildPackage
> (java.lang.String,boolean,java.lang.String,java.lang.String,java.lang.String,boolean,java.lang.String,
> java.lang.String,boolean,java.lang.String)
> throws com.google.gwt.user.client.rpc.SerializationException' threw an unexpected exception: org.drools.RuntimeDroolsException:
> Unable to load dialect 'org.drools.rule.builder.dialect.java.JavaDialectConfiguration:java:org.drools.rule.builder.dialect.java.
> JavaDialectConfiguration' |
> org.drools.RuntimeDroolsException: Unable to load dialect 'org.drools.rule.builder.dialect.java.JavaDialectConfiguration:java:org.drools.rule.builder.dialect.java.JavaDialectConfiguration'
> | | at org.drools.compiler.PackageBuilderConfiguration.addDialect(PackageBuilderConfiguration.java:277) |
> | | at org.drools.compiler.PackageBuilderConfiguration.buildDialectConfigurationMap(PackageBuilderConfiguration.java:262) |
> | | at org.drools.compiler.PackageBuilderConfiguration.init(PackageBuilderConfiguration.java:175) |
> | | at org.drools.compiler.PackageBuilderConfiguration.<init>(PackageBuilderConfiguration.java:148) |
> | | at org.drools.guvnor.server.builder.BRMSPackageBuilder.getPackageBuilderConfiguration(BRMSPackageBuilder.java:134) |
> | | at org.drools.guvnor.server.builder.BRMSPackageBuilder.<init>(BRMSPackageBuilder.java:67) |
> | | at org.drools.guvnor.server.builder.AssemblerBase.createBuilder(AssemblerBase.java:46) |
> | | at org.drools.guvnor.server.builder.PackageAssembler.createBuilder(PackageAssembler.java:35) |
> | | at org.drools.guvnor.server.builder.AssemblerBase.<init>(AssemblerBase.java:42) |
> | | at org.drools.guvnor.server.builder.PackageAssemblerBase.<init>(PackageAssemblerBase.java:44) |
> | | at org.drools.guvnor.server.builder.PackageAssembler.<init>(PackageAssembler.java:49) |
> | | at org.drools.guvnor.server.RepositoryPackageOperations.buildPackage(RepositoryPackageOperations.java:522) |
> | | at org.drools.guvnor.server.RepositoryPackageOperations.buildPackage(RepositoryPackageOperations.java:480) |
> | | at org.drools.guvnor.server.RepositoryPackageService.buildPackage(RepositoryPackageService.java:299) |
> | | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) |
> | | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) |
> | | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) |
> | | at java.lang.reflect.Method.invoke(Method.java:601) |
> | | at org.jboss.seam.util.Reflections.invoke(Reflections.java:22) |
> | | at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31) |
> | | at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56) |
> | | at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28) |
> | | at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) |
> | | at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77) |
> | | at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) |
> | | at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44) |
> | | at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) |
> | | at org.jboss.seam.security.SecurityInterceptor.aroundInvoke(SecurityInterceptor.java:157) |
> | | at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) |
> | | at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107) |
> | | at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166) |
> | | at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102) |
> | | at org.drools.guvnor.server.RepositoryPackageService_$$_javassist_7.buildPackage(RepositoryPackageService_$$_javassist_7.java) |
> | | at org.drools.guvnor.server.RepositoryServiceServlet.buildPackage(RepositoryServiceServlet.java:282) |
> | | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) |
> | | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) |
> | | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) |
> | | at java.lang.reflect.Method.invoke(Method.java:601) |
> | | at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:569) |
> | | at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:208) |
> | | at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:248) |
> | | at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62) |
> | | at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) |
> | | at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) |
> | | at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) |
> | | at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) |
> | | at org.jboss.seam.web.ContextFilter$1.process(ContextFilter.java:42) |
> | | at org.jboss.seam.servlet.ContextualHttpServletRequest.run(ContextualHttpServletRequest.java:53) |
> | | at org.jboss.seam.web.ContextFilter.doFilter(ContextFilter.java:37) |
> | | at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) |
> | | at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) |
> | | at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) |
> | | at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) |
> | | at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) |
> | | at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235) |
> | | at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) |
> | | at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190) |
> | | at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92) |
> | | at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126) |
> | | at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70) |
> | | at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) |
> | | at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) |
> | | at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) |
> | | at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) |
> | | at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330) |
> | | at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829) |
> | | at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598) |
> | | at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) |
> | | at java.lang.Thread.run(Thread.java:722) |
> Caused by: org.drools.RuntimeDroolsException: value '1.7' is not a valid language level
> | | at org.drools.rule.builder.dialect.java.JavaDialectConfiguration.getDefaultLanguageLevel(JavaDialectConfiguration.java:161) |
> | | at org.drools.rule.builder.dialect.java.JavaDialectConfiguration.init(JavaDialectConfiguration.java:56) |
> | | at org.drools.compiler.PackageBuilderConfiguration.addDialect(PackageBuilderConfiguration.java:273) |
> | | ... 68 more |
>
Any hints?
Best regards,
Tobias
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/621389#621389]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 5 months
[EJB3] - How to reconcile CMPC and SMPC?
by Bojan Dolinar
Bojan Dolinar [http://community.jboss.org/people/bodzolca] created the discussion
"How to reconcile CMPC and SMPC?"
To view the discussion, visit: http://community.jboss.org/message/611536#611536
--------------------------------------------------------------
When using EJB and Seam, it's probably inevitable to end up with lots of EJBs that are components at the same time, some with container-managed persistent context, some with SMPC. Because it was easier to do (mostly since it precludes any kind of LazyInitializationException) our codebase ended up with lots of EJBs/components with SMPC, even the ones that are part of the data engine and are not always part of the JSF lifecycle (triggered jobs, WS, other services, etc.). The absence of this lifecycle is probably the reason for some strange behaviour since it's not clear what the session is scoped to. For example, sometimes the actionqueue just doesn't get cleaned up after commit, so performance of a job degrades quickly (every flush "flushes" every preceding change), not to mention the memory leak. Migration from Seam 2.0.1 to 2.2.1 was the start of a whole new problem: org.hibernate.StaleStateException because optimistic locking failed. Looks like actionqueue again is keeping some stale objects and decides to commit them, quite sporadically, for all I could find out.
I guess that in the absence of conversation the session doesn't get closed. The situation is alleviated by superseding SMPC with @PersistenceContext. But due to convoluted and numerous execution paths, I'm not allowed to even dream that I'm aware of all the side effects. LIE is just on the top of the list, because all the entities loaded by PC are detached sooner or later.
All this leads to two questions. First, what would be the best way to handle this situation? Is mocking the approapriate JSF life cycle phases safe? Is it possible to scope SMPC to transaction programmatically?
Second, what is the best way to handle this situation from the scratch, when you have that luxury? I didn't find anything addressing this exact problem and I'm sure I'm not the only one experiencing it. My personal approach would be to keep the seam layer as thin as possible. When I was not restricted by legacy code, it worked quite well, although I had to think carefully about LIE all over again. However, every book I've read so far advocates the exact opposite approach. Their samples are usually pure web applications, but I was more than welcome to the real world.
Any thoughts or pointers to further reading on this would be appreciated.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/611536#611536]
Start a new discussion in EJB3 at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 5 months
[jBPM] - Re: Persisting Human Task, letting user to complete after server restart.
by Mauricio Salatino
Mauricio Salatino [http://community.jboss.org/people/salaboy21] created the discussion
"Re: Persisting Human Task, letting user to complete after server restart."
To view the discussion, visit: http://community.jboss.org/message/601635#601635
--------------------------------------------------------------
Hi Adam,
I think that you are mixing a lot of concepts here. Don't get me wrong, it usually happens. The concept of save point also includes Human Tasks. Human interactions are considered as long living activities. For that reason the engine need to wait until the task is completed. As you mention all this waiting happens in a database, so you don't need to be worried about the application is running or not. Obviously the task server needs to be up when the user cames back and want's to interact, but it doesn't mean that needs to be up all time. Right now in jBPM5, we keep two different things persisted.
1) A knowledge runtime snapshot (SessionInfo in the database)
2) The status of each particular task inside the task server.
The task server is configured to use persistence by default, but as far as I remember, it's configured to use an in memory database. You should go and change that to a real database like MySQL/Postgres.
For having persistence of your processes status, that you will need if you are using human tasks interactions you need to use JPAKnowledgeService helpers to keep your sessions persisted in a database.
Greetings.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/601635#601635]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 5 months