[JBoss Tools] - Thoughts on Google Eclipse Plugins going Open Source
by Max Rydahl Andersen
Max Rydahl Andersen [http://community.jboss.org/people/maxandersen] modified the blog post:
"Thoughts on Google Eclipse Plugins going Open Source"
To view the blog post, visit: http://community.jboss.org/community/tools/blog/2011/11/16/thoughts-on-go...
--------------------------------------------------------------
Google http://googlewebtoolkit.blogspot.com/2011/11/google-plugin-for-eclipse-gp... today announced they are making http://code.google.com/p/google-plugin-for-eclipse/ “Google Plugin for Eclipse” and http://code.google.com/p/gwt-designer/ "GWT Designer" fully open source and available under the Eclipse Public license.
We have many developers using Google’s Eclipse plugin to develop GWT-based applications targeting the JBoss Application Server.
With the open sourcing of the plugin we are looking forward to working even more closely with the Google team and the rest of the community on making the developer experience even more productive and an integrated part of Eclipse platform.
We are especially interested in seeing the Google Eclipse plugins being able to target multiple runtimes such as the JBoss Enterprise Application Platform and Google App Engine in a uniform way, working more seamlessly with standards-based tools and frameworks.
This targeting of multiple runtimes will also help users of JBoss AS, Glassfish, Tomcat and any other server that provides an Eclipse Web Tools compatible server adapter.
h1. JBoss Tools GWT Integration
JBoss Tools already provide integration with the previous release of GPE via our experimental http://community.jboss.org/docs/DOC-15794 JBoss GWT Integration.
Our experimental plugin allows you to easily use the Eclipse standard web wizards and projects instead of the Google specific wizards to create and deploy projects.
One of the reasons we marked this integration “experimental” was because opposite to what many believe large parts of Google’s plugins for Eclipse was not open sourced. That made the implementation dependent on non-public API and to use it you needed the GPE GWT plugins that was not possible to distribute freely.
Those concerns were the reasons I’ve been urging Google to make the GWT plugins open source so we and users could actually distribute and use the plugins freely and at the same time we could start contributing fixes and features and not just bugreports.
In the end this should allow for much more stable and uniform user experience. This goes not only for JBoss Tools plugins integration, but for integration across the Eclipse ecosystem such as Eclipse Web Tools Project and m2eclipse.
Some of the issues we had, have been fixed in GPE 2.0. Now with Google open sourcing their plugin we and others can help contribute and fix the remaining issues and implement enhancements to make easy usage of Google GWT across multiple platforms from Eclipse a reality.
None of this of course happen automatically but the open sourcing of the Google plugins definitely make it much easier and I look forward to see and support the work around these plugins.
Thank you Google - now let’s go and have Fun :)
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/community/tools/blog/2011/11/16/thoughts-on-go...]
12 years, 7 months
[jBPM] - JUnit test support for jBPM5
by Maciej Swiderski
Maciej Swiderski [http://community.jboss.org/people/swiderski.maciej] modified the document:
"JUnit test support for jBPM5"
To view the document, visit: http://community.jboss.org/docs/DOC-17345
--------------------------------------------------------------
There are number of issues that people are facing while working with jBPM and to get help the most useful elements are:
* process definition (BPMN2 file)
* test case that illustrates mentioned issue
As process definition is concerned that is rather straight forward (since we already working with it when encountering the problem),
but with test case it can be bit more complex to give directly to others the driver we use for our case.
So, after struggling for some time with exactly the same issue, I decided to start with small but yet powerful support for test cases for jBPM.
There is already a test case class that we could extend and that already brings some useful elements but that is not all we need...
I tried to build up a small library that is dedicated to test cases based on JUnit and that aligns with latest releases of JUnit, meaning it is
based on annotations. So to move directly what I am referring to, lets take a look at very simple test case:
@RunWith(JbpmJUnitRunner.class)
@KnowledgeBase(source={"script.bpmn2"})
@KnowledgeSession()
public class JbpmJUnitTestCase {
protected org.drools.KnowledgeBase knowledgeBase;
protected StatefulKnowledgeSession session;
@Test
public void testScriptTask() {
ProcessInstance instance = session.startProcess("ScriptTask");
assertProcessInstanceComplete(instance);
}
}
What you can see here is the most basic test case that allows to execute and assert process instance completion. I think the code is self explanatory so
I jump directly to the annotations that were introduced with this library:
+*@RunWith*+ - this one is standard JUnit annotation that instructs what runner should be used to execute tests
+*@KnowledgeBase*+ - annotation that defines what artifacts should be loaded into knowledge base
Annotation attributes:
* source - list of resources to be loaded (currently only BPMN2 and DRL resources are supported)
* sharedKey - name of the key that will be used to cache knowledge based between test cases, so if you have set of resources that are used across various
test cases and you want to avoid building knowledge base for each of the test cases sharedKey attribute should be set to load knowledge base only one time
+*@KnowledgeSession*+ - annotation that defines how stateful sessions should be created and maintained
Annotation attributes:
* disposePerTest - defines if session should be disposed after each test within test case, default set to true
* logger - defines what working memory logger should be configured for the session, available options NONE (default), CONSOLE, JPA
* handlers - set of work item handlers that will be registered for each session (WorkItemHandler annotation)
* persistence - defines persistence for the session (Persistence annotation)
+*@Persistence*+ annotation attributes:
* persistenceUnit - name of the persistence unit that should be used while configuring JPA entity manager factory
* reloadSession - defines if session should be reloaded (with the same id) between test invocation within test case, default false
+*@WorkItemHandler*+ annotation attributes:
* taskName - name of the task the handler is registered for
* handles - class of the handler
+*@HumanTaskSupport*+ - annotation that instructs runner that test case requires Human Task interactions so it will initialize Task Server accessible via MINA transport
it will be started on test case scope, meaning that all tests will have access to the same instance of the server within test case.
Annotation attributes:
* users - list of user ids that should be added to the task server on startup
* groups - list of groups that should be added to the task server on startup
* persistanceUnit - name of the persistence unit that should be used while building entity manager factory
* host - interface on which task server should be started, defaults to localhost
* port - port on which task server should be started, defaults to 9123
+*@LifeCycle*+ - annotation that lets developer to configure what operation should be executed for particular human task.
Annotation attributes:
* phases - list of human task life cycle phases (claim, start, complete, fail, skip, etc) defined as enumeration LifeCyclePhase
This annotation is intended to simplify work with human tasks while writing unit tests - very experimental!!!
In addition to annotation there are two property files required when configuring session persistence or human task server:
* datasource.properties - defines parameters of connection pool
* jndi.properties - defines JNDI provider for bitronix
NOTE: Connection pool will be created for entire test phase once datasource.properties file was discovered.
Obviously following files are required as well, since they are required by jbpm and task server artifacts:
* META-INF/persistence.xml that defines both (jbpm and human task persistence units)
* META-INF/JBPMorm.xml
* META-INF/Taskorm.xml
Main concept is around injecting dependencies into your test case class. As dependencies I mean following items:
* Knowledge base
* Stateful session
* Task client
Methods from JUnit life cycle are still available, such as these annotated with @Before, @After, @BeforeClass, @AfterClass. Instance methods (@Before @After) will
have access to session and knowledge base, for instance if some facts should be inserted before running the test.
There is one more item that is worth to mention, an assert class dedicated to jbpm - JbpmAssert, which defines (at the moment):
* assertProcessInstanceComplete
* assertProcessInstanceActive
* assertProcessInstanceAborted
* assertProcessInstancePending
* assertProcessInstanceSuspended
and most likely more to come...
*And now, its time to show some examples of it*
Simple test case with session persistence:
@RunWith(JbpmJUnitRunner.class)
@KnowledgeBase(source={"script.bpmn2"})
@KnowledgeSession(persistence=@Persistence(persistenceUnit="org.jbpm.persistence.jpa"))
public class JbpmJUnitTestCase {
protected org.drools.KnowledgeBase knowledgeBase;
protected StatefulKnowledgeSession session;
@Test
public void testScriptTask() {
ProcessInstance instance = session.startProcess("ScriptTask");
assertProcessInstanceComplete(instance);
}
}
If session reload is desired between tests test case should be defined as follows:
@RunWith(JbpmJUnitRunner.class)
@KnowledgeBase(source={"script.bpmn2"})
@KnowledgeSession(persistence=@Persistence(persistenceUnit="org.jbpm.persistence.jpa", reloadSession=true))
public class JbpmJUnitTestCase {
protected org.drools.KnowledgeBase knowledgeBase;
protected StatefulKnowledgeSession session;
@Test
public void testScriptTask() {
ProcessInstance instance = session.startProcess("ScriptTask");
assertProcessInstanceComplete(instance);
}
@Test
public void testScriptTask2() {
ProcessInstance instance = session.startProcess("ScriptTask");
assertProcessInstanceComplete(instance);
}
}
Both tests will use same session.
Last but not least, human interaction test case:
@RunWith(JbpmJUnitRunner.class)
@KnowledgeBase(source={"script.bpmn2","usertask.bpmn2"}, sharedKey="common")
@KnowledgeSession(handlers={@WorkItemHandler(taskName="Human Task", handler=WSHumanTaskHandler.class)}, logger=Logger.CONSOLE)
@HumanTaskSupport(persistenceUnit="org.jbpm.task", users={"john", "Administrator"})
public class JbpmJUnitRunnerTest {
protected org.drools.KnowledgeBase knowledgeBase;
protected StatefulKnowledgeSession session;
protected TaskClient taskClient;
@Test
public void testHumanTask() throws Exception {
ProcessInstance instance = session.startProcess("UserTask");
Thread.sleep(1000);
BlockingTaskSummaryResponseHandler taskSummaryHandler = new BlockingTaskSummaryResponseHandler();
taskClient.getTasksAssignedAsPotentialOwner("john", "en-UK", taskSummaryHandler);
assertEquals(1, taskSummaryHandler.getResults().size());
TaskSummary task1 = taskSummaryHandler.getResults().get(0);
BlockingTaskOperationResponseHandler taskOperationHandler = new BlockingTaskOperationResponseHandler();
taskClient.claim(task1.getId(), "john", taskOperationHandler);
taskOperationHandler = new BlockingTaskOperationResponseHandler();
taskClient.start(task1.getId(), "john", taskOperationHandler);
taskOperationHandler.waitTillDone(1000);
taskOperationHandler = new BlockingTaskOperationResponseHandler();
taskClient.complete(task1.getId(), "john", null, taskOperationHandler);
taskOperationHandler.waitTillDone(1000);
Thread.sleep(1000);
assertProcessInstanceComplete(instance);
}
}
In the example we can notice several configurations elements:
* knowledge base is configured to be shared between test cases under 'common' shared key
* knowledge session will have registered handler for 'Human Task' work items
* knowledge session will have a console logger configured
* human task server will be configured with 'org.jbpm.task' persistence unit and will add two users once it's started (john, Administrator)
As mentioned on the comments, working with human tasks is still quite complex so an alternative approach is introduced:
@RunWith(JbpmJUnitRunner.class)
@KnowledgeBase(source={"script.bpmn2","service.bpmn2","usertask.bpmn2"}, sharedKey="common")
@KnowledgeSession(handlers={@WorkItemHandler(taskName="Service Task", handler=ServiceTaskHandler.class),
@WorkItemHandler(taskName="Human Task", handler=WSHumanTaskHandler.class)}, logger=Logger.CONSOLE)
@HumanTaskSupport(persistenceUnit="org.jbpm.task", users={"john", "Administrator"})
public class JbpmJUnitRunnerTest {
protected org.drools.KnowledgeBase knowledgeBase;
protected StatefulKnowledgeSession session;
protected TestTaskClient taskClient;
@Test
@LifeCycle(phases={LifeCyclePhase.CLAIM, LifeCyclePhase.START, LifeCyclePhase.COMPLETE})
public void testHumanTask() throws Exception {
ProcessInstance instance = session.startProcess("UserTask");
taskClient.performLifeCycle("john", "en-UK", null);
assertProcessInstanceComplete(instance);
}
}
So, here you can see a quite substantial change in code lines to achieve exactly the same result as previous example. So at the method level you can define what life cycle operation of human task you would like to invoke, using @LifeCycle annotation. That of course is interesting if you would like to invoke exactly the same life cycle phases for all your human tasks within test case, for instance testing positive path for the entire process.
But if you would like to have it on task instance level you can specify the phases on execution of performLifeCycel method of testTaskClient.
An extension of regular TaskClient was introduced (TestTaskClient) that was equipped with two methods:
performLifeCycle(String user, String targetUser, String locale, HashMap input)
performLifeCycle(String user, String targetUser, String locale, HashMap input, LifeCyclePhase[] phases)
obviously it does not cover all possible use cases but as it was said it is experimental and will be enhanced hopefully soon (if you find it useful).
So far following life cycle phases are available:
* claim
* start
* stop
* complete
* fail
* skip
* remove
* release
* suspend
* resume
* delegate
* forward
Note that there is not consistency check of defined phases in test case, meaning that if you use exclusive phases you will get errors, for instance complete and fail. If you have operations that cause task to be reassigned, for instance delegate than you need to invoke performLifeCycle method twice.
@Test
(a)LifeCycle(phases={LifeCyclePhase.START, LifeCyclePhase.DELEGATE})
public void testHumanTask() throws Exception {
ProcessInstance instance = session.startProcess("UserTask");
taskClient.performLifeCycle("john", "mike", "en-UK", null);
taskClient.performLifeCycle("mike", null, "en-UK", null, new LifeCyclePhase[]{LifeCyclePhase.START,
LifeCyclePhase.COMPLETE});
assertProcessInstanceComplete(instance);
}
*Global configuration*
Another thing was added to the mentioned test support - possibility to configure your tests globally.
So what does it mean? Generally it allows to configure same components as annotations but in the scope of the project or maven module by defining it as simple properties file. Main benefits of this approach are as follows:
* single configuration for all test cases (no need to put annotations in your test case class
* possibility to share knowledge base for all your tests (will be loaded only once)
* can run the same test suit with different properties set to verify various configuration without a need to modify test cases
* annotations can be used to override global configuration
Here an example of jbpm-test.properties file:
#knowledge base configuration
#mandatory properties
knowledge.base.source=script.bpmn2;service.bpmn2;usertask.bpmn2
#optional properties
knowledge.base.shared.key=common
#knowledge session configuration
#all of them are optional with defaults
session.dispose.per.test=true
session.logger=FILE
#session.persistence.unit=
#session.persistence.reload=
session.workitem.handlers=Service Task:org.jbpm.bpmn2.handler.ServiceTaskHandler;Human Task:org.jbpm.process.workitem.wsht.WSHumanTaskHandler;
#human task service configuration
#mandatory properties
human.task.persistence.unit=org.jbpm.task
#optional parameters that are default to localhost and 9123
human.task.users=john;Administrator
#human.task.groups=
#human.task.host=
#human.task.port=
Currently, junit runner expects to find it on root of the classpath and with exactly the name of jbpm-test.properties. Will be enhanced with next update of code base to support extensions, for instance using -D parameters of jvm.
Ok, so that is it! I hope you can provide some feedback about it and hopefully we can get a valuable discussion around it and what's even more important
maybe we start using it on daily basis so everybody could benefit from it.
Attached draft version of the library.
Looking forward to your comments
P.S.
If you are interested in the complete module you can find it at: https://github.com/mswiderski/jbpm/tree/master/jbpm-test-support https://github.com/mswiderski/jbpm/tree/master/jbpm-test-support It is now merged with the jBPM code base as additional module
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-17345]
Create a new document in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
12 years, 7 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, 7 months