[jBPM Development] - Help me! processinstance why not delete?
by chen lei
chen lei [http://community.jboss.org/people/clsun88] created the discussion
"Help me! processinstance why not delete?"
To view the discussion, visit: http://community.jboss.org/message/558440#558440
--------------------------------------------------------------
*my project use JBPM 3.2.1. Now ,customer business Data is very so many. I use JBPM API (deleteProcessInstance) delete data.but console out Error.Error is deplay:*
org.jbpm.JbpmException: problem closing services {persistence=org.jbpm.persistence.JbpmPersistenceException: hibernate flush failed}
at org.jbpm.svc.Services.close(Services.java:234)
at org.jbpm.JbpmContext.close(JbpmContext.java:139)
at com.wedge.edp.framework.jbpm.dao.support.JbpmTemplate.closeJbpmContext(JbpmTemplate.java:109)
at com.wedge.edp.framework.jbpm.dao.support.JbpmTemplate.execute(JbpmTemplate.java:84)
at com.wedge.edp.framework.jbpm.service.support.OpenWorkflowContextAdvice.invoke(OpenWorkflowContextAdvice.java:22)
at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:576)
at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:562)
at org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:60)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:107)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:630)
at com.wedge.edp.framework.jbpm.application.JbpmProcessApplication$$EnhancerByCGLIB$$22de81b1.deleteProcess(<generated>)
at com.wedge.rms.commons.process.service.impl.ProcessServiceImpl.proceeDelete(ProcessServiceImpl.java:345)
at com.wedge.rms.commons.process.service.impl.ProcessServiceImpl$$FastClassByCGLIB$$e6553eb9.invoke(<generated>)
at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
at org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.invokeJoinpoint(Cglib2AopProxy.java:695)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:107)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:630)
at com.wedge.rms.commons.process.service.impl.ProcessServiceImpl$$EnhancerByCGLIB$$95e4e6ee.proceeDelete(<generated>)
at test.wfTest.delete(wfTest.java:51)
at test.wfTest.main(wfTest.java:46)
Caused by: org.jbpm.persistence.JbpmPersistenceException: hibernate flush failed
at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:236)
at org.jbpm.svc.Services.close(Services.java:222)
... 28 more
Caused by: org.hibernate.exception.ConstraintViolationException: could not delete: [org.jbpm.graph.exe.ProcessInstance#6094]
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:71)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
at org.hibernate.persister.entity.AbstractEntityPersister.delete(AbstractEntityPersister.java:2491)
at org.hibernate.persister.entity.AbstractEntityPersister.delete(AbstractEntityPersister.java:2647)
at org.hibernate.action.EntityDeleteAction.execute(EntityDeleteAction.java:74)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:248)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:232)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:144)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
at org.jbpm.persistence.db.DbPersistenceService.flushSession(DbPersistenceService.java:267)
at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:231)
... 29 more
Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: DELETE 语句与 REFERENCE 约束"FK_TOKEN_SUBPI"冲突。该冲突发生于数据库"PES"，表"dbo.JBPM_TOKEN", column 'SUBPROCESSINSTANCE_'。
at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(Unknown Source)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.getNextResult(Unknown Source)
at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.doExecutePreparedStatement(Unknown Source)
at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement$PrepStmtExecCmd.doExecute(Unknown Source)
at com.microsoft.sqlserver.jdbc.TDSCommand.execute(Unknown Source)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(Unknown Source)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeCommand(Unknown Source)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeStatement(Unknown Source)
at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.executeUpdate(Unknown Source)
at org.hibernate.persister.entity.AbstractEntityPersister.delete(AbstractEntityPersister.java:2473)
... 39 more
*see database.JBPM_PROCESSINSTANCE and JBPM_TOKEN.Table.subprocessinstance_ is null.*
*why I can't delete it? how should I delete?*
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/558440#558440]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 10 months
[JBoss Tools] - Create Eclipse Ecore (EMF) Models manually
by Andre Dietisheim
Andre Dietisheim [http://community.jboss.org/people/adietish] modified the document:
"Create Eclipse Ecore (EMF) Models manually"
To view the document, visit: http://community.jboss.org/docs/DOC-15705
--------------------------------------------------------------
h1. *Forewords*
EMF provides a runtime and tools that allow you to create ecore object models. The starting point is a model definition. It may be created out of a XML Schema (XSD), annotated java classes, etc. but you will mostly craft one by hand. This document attempts to describe the process involved in the later. It will show you the basic steps to create an ecore model implementation and give you some more advanced hints here and there.
There are a few tutorials available on http://www.eclipse.org/modeling/emf/docs/#tutorials eclipse.org, the best one (to my eyes's) the one provided by http://www.vogella.de/articles/EclipseEMF/article.html Lars Vogella.
h1. Get started, create an EMF Project
To get started, create an empty EMF project.
http://community.jboss.org/servlet/JiveServlet/showImage/102-15705-19-533... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15705-19...
You'll get a new project, that's set up to work with the EMF framework.
What's pops to your eyes is that there's a *model* directory in this project. That´s the folder that will hold the ecore files, the model definitions (not a must but a standard so far).
h1. Create a Model Definition
Create a new ecore model file in this folder by selecting the folder and invoking the new ecore model wizard.
http://community.jboss.org/servlet/JiveServlet/showImage/102-15705-19-533... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15705-19...
h1. Create a Package
We created an empty ecore model so far. The wizard opened the model in an new editor when all steps were achieved. The ecore file already has an empty, unnamed package. Your task is to give it a name, set its Ns URI and prefix.
* *name*: a simple term (not required to be unique)
* *Ns prefix*: ~shoretened 'java package' name (not required to be unique)
* *Ns URI*: some real (or bogus) unique URI where the scheme might be found.
Eclipse used the *Sample Ecore Model Editor* so far but there are other editors that you may use. There are text based editors like http://wiki.eclipse.org/Emfatic Emfatic or http://www.eclipse.org/Xtext/ Xtext. If you prefer to manipulate diagrams you may use the http://www.eclipse.org/modeling/emft/?project=ecoretools Ecore Diagram Editor or http://www.soyatec.com/euml2/ eUML2.
h4. example: org.eclipse.emf.cdo.ui.defs
I have a plugin/module in cdo called *org.eclipse.emf.cdo.ui.defs*
The ecore model for it has the following declarations:
http://community.jboss.org/servlet/JiveServlet/showImage/102-15705-19-538... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15705-19...
*name*: defs
*Ns prefix*: cdo.ui.defs
*Ns URI*: http://www.eclipse.org/emf/CDO/ui/defs/1.0.0 http://www.eclipse.org/emf/CDO/ui/defs/1.0.0
h1. Add Classes
You are now ready to create classes in your package. Select your package and use the context menu to create a new *EClass*.
The properties view will allow you to set its name.
http://community.jboss.org/servlet/JiveServlet/showImage/102-15705-19-538... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15705-19...
Ecore files define classes that will be generated in a later step. Each class you define wil create an interface and a class.
http://community.jboss.org/servlet/JiveServlet/showImage/102-15705-19-538... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15705-19...
http://community.jboss.org/servlet/JiveServlet/showImage/102-15705-19-539... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15705-19...
h1. No POJO?
The generated java classes are not plain POJOs but extend http://download.eclipse.org/modeling/emf/emf/javadoc/2.5.0/index.html?org... EObject. You may therefore only define elements that EObjects may have. There are *Classes, Attributes*, *References*, *Operations*, etc. A quick look at the http://download.eclipse.org/modeling/emf/emf/javadoc/2.5.0/org/eclipse/em... EObject class diagram may help you get in touch with the terms used in EMF.
EObjects offer various capabilities that are not (or at least at high cost) offered with plain POJOs. Extending EObjects in your model classes offers you all these capabilities free of charge:
* *serialization* (XML, XMI, binary, database based persistence, etc.)
* *change propagation*
* ** *validation*
* ** *object* *query*
* ** etc.
Furthermore the EMF ecosystem holds plenty of frameworks that extend it in various areas. Using EObject based POJOs allows you to take advantage of all these powerful frameworks.
A disadvantage is that EMF's pretty invasive. You get all its power, but you mostly have to stick to EObjects. This usually isn't prroblematic in client (aka Eclipse IDE/RCP or other RCP platforms) projects, but might be a problem in server side projects. You may tell the generator http://wiki.eclipse.org/EMF/Recipes#Recipe:_Generating_Pure_API_With_No_V... not to extend EObjects, but you'll loose all benefits the powerful EMF runtime offers to you. Another solution emerged lately with Eclipse http://martintaal.wordpress.com/2010/05/18/introducing-the-texo-project/ Texo. Texo generates plain POJOs and offers a runtime that unleasehes most of the emf runtime capabilities.
h1. All Ways lead to Rome
There are usually several ways to get to the desired result (aka generated java code). The best way to find out about them is to get http://www.amazon.com/EMF-Eclipse-Modeling-Framework-2nd/dp/0321331885/re... Eclipse Modeling Framework book or trial and error.
A rule of thumb is to have all referenced classes available in your model definition. This is evident for ecore classes. But if your ecore classes use references to plain java types (that are not part of your ecore model in the strict sense) you'll have to declare those java types in the ecore model. In other words, the ecore model needs to know about all types (ecore or plain java) that are part of your model.
h4. example: Use EDataTypes for Java types
Let's say that my modeled class CDOEditorDefs has a method execute() that throws an ExecutionException. I could add that method by hand but as a matter of taste I prefer to declare that method in my model.
My model does not know anything about this exception so far, so there's no way to get the correct signature generated out of the box . I'll therefore have to declare this exception in model. I create a DataType *ExecutionException*.
create an EDataType:
http://community.jboss.org/servlet/JiveServlet/showImage/4911/declare-dat... http://community.jboss.org/servlet/JiveServlet/downloadImage/4911/declare...
Give it an instance type name so it won't be generated but is referencable:
http://community.jboss.org/servlet/JiveServlet/showImage/4913/declare-exe... http://community.jboss.org/servlet/JiveServlet/downloadImage/4913/declare...
Set the execute method (operation) to throw the ExecutionException:
http://community.jboss.org/servlet/JiveServlet/showImage/4914/declare-thr... http://community.jboss.org/servlet/JiveServlet/downloadImage/4914/declare...
The generated method now throws the given Exception:
http://community.jboss.org/servlet/JiveServlet/showImage/4915/generated-t... http://community.jboss.org/servlet/JiveServlet/downloadImage/4915/generat...
h4. example: Use EClass for Java Interfaces
A very common problem is to have modeled (ecore-) classes that shall extend Java Interfaces. Let's say that I want EditorDef (an ecore class) to implement *java.lang.Comparable*.
** The former example used a EDataType to declare an external type to the ecore model. Interfaces are modeled as supertypes in EMF. EDataTypes cannot be supertypes to ecore classes.I therefore have to declare an *eclass* for my additional interface. *instance type name* will - like in the former example - ensure that no artifact gets generated.
I declare the Comparable Interface:
http://community.jboss.org/servlet/JiveServlet/showImage/102-15705-19-539... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15705-19...
and add it to the supertypes of EditorDef:
The (generated) java interface will now extend Comparable:
http://community.jboss.org/servlet/JiveServlet/showImage/102-15705-19-539... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15705-19...
h1. Get prepared to generate code, create a Genmodel
This is mostly straight forward. Select the ecore file and create a genmodel for it. Select your ecore file and start a new *EMF Generator Model* wizard. The wizard will allow you to create a so called Generator Model that holds all settings which are important to the code generation process.
http://community.jboss.org/servlet/JiveServlet/showImage/102-15705-19-533... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15705-19...
There are 2 settings that might be of interest to you:
'*All*' (property group when the package is selected):
- *Base Package*: the base package all ecore classes get generated to
- *Prefix*: Prefix that the factory- and package-class get
http://community.jboss.org/servlet/JiveServlet/showImage/102-15705-19-533... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15705-19...
example (still using the cdo.ui.defs example):
*Base Package*: org.eclipse.emf.cdo.ui
*Prefix*: CDOUIDefs
Package-class gets CDOUIDefsPackage, Factory gets CDOUIDefsFactory, etc. All classes get generated to the package org.eclipse.emf.cdo.ui
Further modifications you might be interested in are the suffixes of the sub-packages (the defaults creates an 'impl' package where it puts all implementation classes). It can be modified by selecting the '*Package Suffixes*' and choosing the properties '*Implementation*' and '*Interfaces*'.
The naming of the implementation- and interface-classes may be changed, too. You find those settings if you select the root-node of the tree in the genmodel-editor and choose the '*Model*' property group. You'll find 'Class Name Pattern' and 'Interface Name Pattern' among the available properties. The explanations for the values show up in the statusbar (default is '*{0}impl*' and '*{0}*').
http://community.jboss.org/servlet/JiveServlet/showImage/102-15697-11-484... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15697-11...
Once you're done defining your generator model, you simply need to generate the implementation classes. Select the package you want to generate, right click and select the implementation you want to create. You may choose among the models, the editor, the tests.
http://community.jboss.org/servlet/JiveServlet/showImage/102-15697-11-485... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15697-11...
h1. Modify the Generated Classes
Ecore is built to be modified, the basic usage-pattern is to code and generate hand-in-hand. To tell the generator not to override your modifications you need to set the javadoc-annotation to anything different than *@generated*. Good practice says that you should set it to '@generated NOT'. Good practice also tells you to annotate any manually added method by *@ADDED*, but its optional though.
There is another handy that allows you to modify and get the generated code. If you want to have your code instead of the generated one, you just annotate accordingly and the generator will preserve your code. If you want the generated code, too, you'd need to create a method that has the original name + a suffix 'Gen'
example:
/**
*
* @generated NOT
*/
public void setName(String name) {
YOUR OWN CODE
}
/**
*
* @generated
*/
public void setNameGen(String name) {
GENERATOR provides the generated code in here
}
After making your modifications, you simply need to re-generate the ecore classes. (+*How?*+)
h1. Refactor generated Code and Regenerate
The code generator in EMF's is pretty capable when it's up to merge manual code changes in generated code. It respects *@generated* tags and preserves your handwritten code in generated classes.
If you rename a class in your ecore file though, it won't be able to detect your change. EMF has no clue that you renamed ecore class definitions. It will not be able to detect your java files because they have the old name. It will generate new artifacts and merging will not occur. You could copy your changes manually, but this is pretty cumbersome, there's a better approach to this use case:
Refactor/rename the generated java classes in a first step. Rename your ecore class definitions in a second step and regenerate afterwards. EMF will detect the preexisting artifacts and merge your manual code changes with the generated content. You will not have to copy your code manually.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-15705]
Create a new document in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 10 months
[JBoss Tools] - Create Eclipse Ecore (EMF) Models manually
by Andre Dietisheim
Andre Dietisheim [http://community.jboss.org/people/adietish] modified the document:
"Create Eclipse Ecore (EMF) Models manually"
To view the document, visit: http://community.jboss.org/docs/DOC-15705
--------------------------------------------------------------
h1. *Forewords*
EMF provides a runtime and tools that allow you to create ecore object models. The starting point is a model definition. It may be created out of a XML Schema (XSD), annotated java classes, etc. but you will mostly craft one by hand. This document attempts to describe the process involved in the later. It will show you the basic steps to create an ecore model implementation and give you some more advanced hints here and there.
There are a few tutorials available on http://www.eclipse.org/modeling/emf/docs/#tutorials eclipse.org, the best one (to my eyes's) the one provided by http://www.vogella.de/articles/EclipseEMF/article.html Lars Vogella.
h1. Get started, create an EMF Project
To get started, create an empty EMF project.
http://community.jboss.org/servlet/JiveServlet/showImage/102-15705-19-533... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15705-19...
You'll get a new project, that's set up to work with the EMF framework.
What's pops to your eyes is that there's a *model* directory in this project. That´s the folder that will hold the ecore files, the model definitions (not a must but a standard so far).
h1. Create a Model Definition
Create a new ecore model file in this folder by selecting the folder and invoking the new ecore model wizard.
http://community.jboss.org/servlet/JiveServlet/showImage/102-15705-19-533... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15705-19...
h1. Create a Package
We created an empty ecore model so far. The wizard opened the model in an new editor when all steps were achieved. The ecore file already has an empty, unnamed package. Your task is to give it a name, set its Ns URI and prefix.
* *name*: a simple term (not required to be unique)
* *Ns prefix*: ~shoretened 'java package' name (not required to be unique)
* *Ns URI*: some real (or bogus) unique URI where the scheme might be found.
Eclipse used the *Sample Ecore Model Editor* so far but there are other editors that you may use. There are text based editors like http://wiki.eclipse.org/Emfatic Emfatic or http://www.eclipse.org/Xtext/ Xtext. If you prefer to manipulate diagrams you may use the http://www.eclipse.org/modeling/emft/?project=ecoretools Ecore Diagram Editor or http://www.soyatec.com/euml2/ eUML2.
h4. example: org.eclipse.emf.cdo.ui.defs
I have a plugin/module in cdo called *org.eclipse.emf.cdo.ui.defs*
The ecore model for it has the following declarations:
http://community.jboss.org/servlet/JiveServlet/showImage/102-15705-19-538... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15705-19...
*name*: defs
*Ns prefix*: cdo.ui.defs
*Ns URI*: http://www.eclipse.org/emf/CDO/ui/defs/1.0.0 http://www.eclipse.org/emf/CDO/ui/defs/1.0.0
h1. Add Classes
You are now ready to create classes in your package. Select your package and use the context menu to create a new *EClass*.
The properties view will allow you to set its name.
http://community.jboss.org/servlet/JiveServlet/showImage/102-15705-19-538... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15705-19...
Ecore files define classes that will be generated in a later step. Each class you define wil create an interface and a class.
http://community.jboss.org/servlet/JiveServlet/showImage/102-15705-19-538... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15705-19...
http://community.jboss.org/servlet/JiveServlet/showImage/102-15705-19-539... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15705-19...
h1. No POJO?
The generated java classes are not plain POJOs but extend http://download.eclipse.org/modeling/emf/emf/javadoc/2.5.0/index.html?org... EObject. You may therefore only define elements that EObjects may have. There are *Classes, Attributes*, *References*, *Operations*, etc. A quick look at the http://download.eclipse.org/modeling/emf/emf/javadoc/2.5.0/org/eclipse/em... EObject class diagram may help you get in touch with the terms used in EMF.
EObjects offer various capabilities that are not (or at least at high cost) offered with plain POJOs. Extending EObjects in your model classes offers you all these capabilities free of charge:
* *serialization* (XML, XMI, binary, database based persistence, etc.)
* *change propagation*
* ** *validation*
* ** *object* *query*
* ** etc.
Furthermore the EMF ecosystem holds plenty of frameworks that extend it in various areas. Using EObject based POJOs allows you to take advantage of all these powerful frameworks.
A disadvantage is that EMF's pretty invasive. You get all its power, but you mostly have to stick to EObjects. This usually isn't prroblematic in client (aka Eclipse IDE/RCP or other RCP platforms) projects, but might be a problem in server side projects. You may tell the generator http://wiki.eclipse.org/EMF/Recipes#Recipe:_Generating_Pure_API_With_No_V... not to extend EObjects, but you'll loose all benefits the powerful EMF runtime offers to you. Another solution emerged lately with Eclipse http://martintaal.wordpress.com/2010/05/18/introducing-the-texo-project/ Texo. Texo generates plain POJOs and offers a runtime that unleasehes most of the emf runtime capabilities.
h1. All Ways lead to Rome
There are usually several ways to get to the desired result (aka generated java code). The best way to find out about them is to get http://www.amazon.com/EMF-Eclipse-Modeling-Framework-2nd/dp/0321331885/re... Eclipse Modeling Framework book or trial and error.
A rule of thumb is to have all referenced classes available in your model definition. This is evident for ecore classes. But if your ecore classes use references to plain java types (that are not part of your ecore model in the strict sense) you'll have to declare those java types in the ecore model. In other words, the ecore model needs to know about all types (ecore or plain java) that are part of your model.
h4. example: Use EDataTypes for Java types
Let's say that my modeled class CDOEditorDefs has a method execute() that throws an ExecutionException. I could add that method by hand but as a matter of taste I prefer to declare that method in my model.
My model does not know anything about this exception so far, so there's no way to get the correct signature generated out of the box . I'll therefore have to declare this exception in model. I create a DataType *ExecutionException*.
create an EDataType:
http://community.jboss.org/servlet/JiveServlet/showImage/4911/declare-dat... http://community.jboss.org/servlet/JiveServlet/downloadImage/4911/declare...
Give it an instance type name so it won't be generated but is referencable:
http://community.jboss.org/servlet/JiveServlet/showImage/4913/declare-exe... http://community.jboss.org/servlet/JiveServlet/downloadImage/4913/declare...
Set the execute method (operation) to throw the ExecutionException:
http://community.jboss.org/servlet/JiveServlet/showImage/4914/declare-thr... http://community.jboss.org/servlet/JiveServlet/downloadImage/4914/declare...
The generated method now throws the given Exception:
http://community.jboss.org/servlet/JiveServlet/showImage/4915/generated-t... http://community.jboss.org/servlet/JiveServlet/downloadImage/4915/generat...
h4. example: Use Instance Type Name to model Java Interfaces
A very common problem is to have modeled (ecore-) classes that shall extend Java Interfaces. Let's say that we want to have a Ecore Class that implements *java.lang.Comparable*. You could of course add this interface manually in the code but I personally prefer to have most relevant strucutral informations in my model.
** The former example used a EDataType to declare an external type to the ecore model. Interfaces are modeled as supertypes in EMF. EDataTypes cannot be supertypes to ecore classes.You can achieve this in a slight different manner though. You define a *eclass* for your interface. If you set the *instance type name*, it will not get its artifact (java class generated) generated, but it may be referenced by other eclasses and therefore used as supertype.
http://community.jboss.org/servlet/JiveServlet/showImage/102-15705-19-539... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15705-19...
http://community.jboss.org/servlet/JiveServlet/showImage/102-15705-16-539... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15705-16...
http://community.jboss.org/servlet/JiveServlet/showImage/102-15705-19-539... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15705-19...
h1. Get prepared to generate code, create a Genmodel
This is mostly straight forward. Select the ecore file and create a genmodel for it. Select your ecore file and start a new *EMF Generator Model* wizard. The wizard will allow you to create a so called Generator Model that holds all settings which are important to the code generation process.
http://community.jboss.org/servlet/JiveServlet/showImage/102-15705-19-533... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15705-19...
There are 2 settings that might be of interest to you:
'*All*' (property group when the package is selected):
- *Base Package*: the base package all ecore classes get generated to
- *Prefix*: Prefix that the factory- and package-class get
http://community.jboss.org/servlet/JiveServlet/showImage/102-15705-19-533... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15705-19...
example (still using the cdo.ui.defs example):
*Base Package*: org.eclipse.emf.cdo.ui
*Prefix*: CDOUIDefs
Package-class gets CDOUIDefsPackage, Factory gets CDOUIDefsFactory, etc. All classes get generated to the package org.eclipse.emf.cdo.ui
Further modifications you might be interested in are the suffixes of the sub-packages (the defaults creates an 'impl' package where it puts all implementation classes). It can be modified by selecting the '*Package Suffixes*' and choosing the properties '*Implementation*' and '*Interfaces*'.
The naming of the implementation- and interface-classes may be changed, too. You find those settings if you select the root-node of the tree in the genmodel-editor and choose the '*Model*' property group. You'll find 'Class Name Pattern' and 'Interface Name Pattern' among the available properties. The explanations for the values show up in the statusbar (default is '*{0}impl*' and '*{0}*').
http://community.jboss.org/servlet/JiveServlet/showImage/102-15697-11-484... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15697-11...
Once you're done defining your generator model, you simply need to generate the implementation classes. Select the package you want to generate, right click and select the implementation you want to create. You may choose among the models, the editor, the tests.
http://community.jboss.org/servlet/JiveServlet/showImage/102-15697-11-485... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15697-11...
h1. Modify the Generated Classes
Ecore is built to be modified, the basic usage-pattern is to code and generate hand-in-hand. To tell the generator not to override your modifications you need to set the javadoc-annotation to anything different than *@generated*. Good practice says that you should set it to '@generated NOT'. Good practice also tells you to annotate any manually added method by *@ADDED*, but its optional though.
There is another handy that allows you to modify and get the generated code. If you want to have your code instead of the generated one, you just annotate accordingly and the generator will preserve your code. If you want the generated code, too, you'd need to create a method that has the original name + a suffix 'Gen'
example:
/**
*
* @generated NOT
*/
public void setName(String name) {
YOUR OWN CODE
}
/**
*
* @generated
*/
public void setNameGen(String name) {
GENERATOR provides the generated code in here
}
After making your modifications, you simply need to re-generate the ecore classes. (+*How?*+)
h1. Refactor generated Code and Regenerate
The code generator in EMF's is pretty capable when it's up to merge manual code changes in generated code. It respects *@generated* tags and preserves your handwritten code in generated classes.
If you rename a class in your ecore file though, it won't be able to detect your change. EMF has no clue that you renamed ecore class definitions. It will not be able to detect your java files because they have the old name. It will generate new artifacts and merging will not occur. You could copy your changes manually, but this is pretty cumbersome, there's a better approach to this use case:
Refactor/rename the generated java classes in a first step. Rename your ecore class definitions in a second step and regenerate afterwards. EMF will detect the preexisting artifacts and merge your manual code changes with the generated content. You will not have to copy your code manually.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-15705]
Create a new document in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 10 months
[jBPM] - Deployments and the Console
by Karoy Labs
Karoy Labs [http://community.jboss.org/people/obolabs] created the discussion
"Deployments and the Console"
To view the discussion, visit: http://community.jboss.org/message/558428#558428
--------------------------------------------------------------
First, a quick bkgrnd:
I've got Weblogic background and all kinds associated JEE skills, in case that's supposed to make me smarter about things.. ;)
With that, I haven't had much experience with JBoss, nor with JBPM. Practically a noob with both..
But about my current problem..
JBPM 4.4 downloaded, unzipped. Executed ant demo.setup.jboss, but it croaked during Eclipse download, so I did that manually. After that I ran teardown and setup again, which then completed, but I'm still not sure if everything is in place as they should be.
By now, HSQL and JBoss start up, so I can access web modeler and Console. Log in with alex but there's nothing to be seen in the console, as in processes, nada. Tried running +ant install.examples.into.jboss+, but it croaked with "jbpm-4.4\examples\*build.xml:120*: org.jbpm.api.JbpmException:
xml validation error: cvc-complex-type.4: Attribute 'method' must appear on element 'java'. [line=8 column=40 ]". I haven't followed up on this yet.
Next, in Eclipse Modeler, I went and created a very simple process and made a .bar file out of the .jpdl.xml and .png files. No Java classes yet, only these two. The process doesn't do anything, simply START=>TASK=>END.
Created a simple build.xml that deploys it, seemingly without error.
I am expecting the deployed process to show up in the Console, ready for execution. Don't really if it would croak, just see it try would do it.
Reading the User Guide makes me think I need to write a Service class impl and that's the guy that gets recognized by the Console then?
Obvoiusly, I've got some learning to do, but any guidance to get out of the woods would be appreciated..
Thanks,
karoy
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/558428#558428]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 10 months
[JBoss Tools] - Create Eclipse Ecore (EMF) Models manually
by Andre Dietisheim
Andre Dietisheim [http://community.jboss.org/people/adietish] modified the document:
"Create Eclipse Ecore (EMF) Models manually"
To view the document, visit: http://community.jboss.org/docs/DOC-15705
--------------------------------------------------------------
h1. *Forewords*
EMF provides a runtime and tools that allow you to create ecore object models. The starting point is a model definition. It may be created out of a XML Schema (XSD), annotated java classes, etc. but you will mostly craft one by hand. This document attempts to describe the process involved in the later. It will show you the basic steps to create an ecore model implementation and give you some more advanced hints here and there.
There are a few tutorials available on http://www.eclipse.org/modeling/emf/docs/#tutorials eclipse.org, the best one (to my eyes's) the one provided by http://www.vogella.de/articles/EclipseEMF/article.html Lars Vogella.
h1. Get started, create an EMF Project
To get started, create an empty EMF project.
http://community.jboss.org/servlet/JiveServlet/showImage/102-15705-15-533... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15705-15...
You'll get a new project, that's set up to work with the EMF framework.
What's pops to your eyes is that there's a *model* directory in this project. That´s the folder that will hold the ecore files, the model definitions (not a must but a standard so far).
h1. Create a Model Definition
Create a new ecore model file in this folder by selecting the folder and invoking the new ecore model wizard.
http://community.jboss.org/servlet/JiveServlet/showImage/102-15705-15-533... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15705-15...
h1. Create a Package
You can now add classes to your package. There are different editors you may use to edit your ecore file. The most common one is Sample Ecore Model Editor that is included in the Eclipse modeling edition. Alternatively you may also use text based editors like http://wiki.eclipse.org/Emfatic Emfatic or http://www.eclipse.org/modeling/emft/?project=ecoretools Ecore Diagram Editor or the http://www.soyatec.com/euml2/ eUML2 Editor.
We created an empty ecore model so far, so the next step is to create a package in your model. You set its name, Ns Prefix and Ns URI.
* *name*: a simple term (not required to be unique)
* *Ns prefix*: ~shoretened 'java package' name (not required to be unique)
* *Ns URI*: some real (or bogus) unique URI where the scheme might be found.
h4. example: org.eclipse.emf.cdo.ui.defs
I have a plugin/module in cdo called *org.eclipse.emf.cdo.ui.defs*
The ecore model for it has the following declarations:
*name*: defs
*Ns prefix*: cdo.ui.defs
*Ns URI*: http://www.eclipse.org/emf/CDO/ui/defs/1.0.0 http://www.eclipse.org/emf/CDO/ui/defs/1.0.0
h1. Add Classes
You can now add classes to your package. There are different editors at hand that you may use to edit your ecore file. The most common one is the *Sample Ecore Model Editor* that is included in the Eclipse modeling edition. Alternatively you may also use text based editors like http://wiki.eclipse.org/Emfatic Emfatic or http://www.eclipse.org/Xtext/ Xtext. There are also graphical editors around like the* http://www.eclipse.org/modeling/emft/?project=ecoretools Ecore Diagram Editor or the eUML2 Editor.*
Ecore files define classes that will be generated in a later step. The generated java classes are not plain POJOs but extend http://download.eclipse.org/modeling/emf/emf/javadoc/2.5.0/index.html?org... EObject. You may therefore only define elements that EObjects may have. There are *Classes, Attributes*, *References*, *Operations*, etc. A quick look at the http://download.eclipse.org/modeling/emf/emf/javadoc/2.5.0/org/eclipse/em... EObject class diagram may help you get in touch with the terms used in EMF.
EObjects offer various capabilities that are not (or at least at high cost) offered with plain POJOs. Extending EObjects in your model classes offers you all these capabilities free of charge:
* *serialization* (XML, XMI, binary, database based persistence, etc.)
* *change propagation*
* ** *validation*
* ** *object* *query*
* ** etc.
Furthermore the EMF ecosystem holds plenty of frameworks that extend it in various areas. Using EObject based POJOs allows you to take advantage of all these powerful frameworks.
A disadvantage is that EMF's pretty invasive. You get all its power, but you mostly have to stick to EObjects. This usually isn't prroblematic in client (aka Eclipse IDE/RCP or other RCP platforms) projects, but might be a problem in server side projects. You may tell the generator http://wiki.eclipse.org/EMF/Recipes#Recipe:_Generating_Pure_API_With_No_V... not to extend EObjects, but you'll loose all benefits the powerful EMF runtime offers to you. Another solution emerged lately with Eclipse http://martintaal.wordpress.com/2010/05/18/introducing-the-texo-project/ Texo. Texo generates plain POJOs and offers a runtime that unleasehes most of the emf runtime capabilities.
h1. All Ways lead to Rome
*
*
There are usually several ways to get to the desired result (aka generated java code). The best way to find out about them is to get http://www.amazon.com/EMF-Eclipse-Modeling-Framework-2nd/dp/0321331885/re... Eclipse Modeling Framework book or trial and error.
A rule of thumb is to have all referenced classes available in your model definition. This is evident for ecore classes. But if your ecore classes use references to plain java types (that are not part of your ecore model in the strict sense) you'll have to declare those java types in the ecore model. In other words, the ecore model needs to know about all types (ecore or plain java) that are part of your model.
h4. example: Use EDataTypes for Java types
Let's say that my modeled class CDOEditorDefs has a method execute() that throws an ExecutionException. I could add that method by hand but as a matter of taste I prefer to declare that method in my model.
My model does not know anything about this exception so far, so there's no way to get the correct signature generated out of the box . I'll therefore have to declare this exception in model. I create a DataType *ExecutionException*.
create an EDataType:
http://community.jboss.org/servlet/JiveServlet/showImage/4911/declare-dat... http://community.jboss.org/servlet/JiveServlet/downloadImage/4911/declare...
Give it an instance type name so it won't be generated but is referencable:
http://community.jboss.org/servlet/JiveServlet/showImage/4913/declare-exe... http://community.jboss.org/servlet/JiveServlet/downloadImage/4913/declare...
Set the execute method (operation) to throw the ExecutionException:
http://community.jboss.org/servlet/JiveServlet/showImage/4914/declare-thr... http://community.jboss.org/servlet/JiveServlet/downloadImage/4914/declare...
The generated method now throws the given Exception:
http://community.jboss.org/servlet/JiveServlet/showImage/4915/generated-t... http://community.jboss.org/servlet/JiveServlet/downloadImage/4915/generat...
h4. example: Use Instance Type Name to model Java Interfaces
A very common problem is to have modeled (ecore-) classes extend Java Interfaces. For instance this could be java.lang.Comparable
The best way to achieve that is to model a class Comparable. Do not model its operation as this is just a mirror of the real java interface in the ecore-world.
Interfaces are modeled as supertypes in ecore. You therefore cannot use EDataTypes here as they cannot be supertypes of ecore classes. Nevertheless you can achieve that in a slight different manner: You model a (real) ecore class, but you set its *instance type name:* *java.lang.Comparable*. You can now add the Comparable class to the super type of each ecore-class that shall implement Comparable. The generator will not generate an ecore class that's called Comparable but it will include java.lang.Comparable in the interface that your ecore-classes implement.
+*Not sure I follow this example and what we're trying to illustrate. Would example code help?*+
h1. Get prepared to generate code, create a Genmodel
This is mostly straight forward. Select the ecore file and create a genmodel for it. Select your ecore file and start a new *EMF Generator Model* wizard. The wizard will allow you to create a so called Generator Model that holds all settings which are important to the code generation process.
http://community.jboss.org/servlet/JiveServlet/showImage/102-15705-15-533... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15705-15...
There are 2 settings that might be of interest to you:
'*All*' (property group when the package is selected):
- *Base Package*: the base package all ecore classes get generated to
- *Prefix*: Prefix that the factory- and package-class get
http://community.jboss.org/servlet/JiveServlet/showImage/102-15705-15-533... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15705-15...
example (still using the cdo.ui.defs example):
*Base Package*: org.eclipse.emf.cdo.ui
*Prefix*: CDOUIDefs
Package-class gets CDOUIDefsPackage, Factory gets CDOUIDefsFactory, etc. All classes get generated to the package org.eclipse.emf.cdo.ui
Further modifications you might be interested in are the suffixes of the sub-packages (the defaults creates an 'impl' package where it puts all implementation classes). It can be modified by selecting the '*Package Suffixes*' and choosing the properties '*Implementation*' and '*Interfaces*'.
The naming of the implementation- and interface-classes may be changed, too. You find those settings if you select the root-node of the tree in the genmodel-editor and choose the '*Model*' property group. You'll find 'Class Name Pattern' and 'Interface Name Pattern' among the available properties. The explanations for the values show up in the statusbar (default is '*{0}impl*' and '*{0}*').
http://community.jboss.org/servlet/JiveServlet/showImage/102-15697-11-484... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15697-11...
Once you're done defining your generator model, you simply need to generate the implementation classes. Select the package you want to generate, right click and select the implementation you want to create. You may choose among the models, the editor, the tests.
http://community.jboss.org/servlet/JiveServlet/showImage/102-15697-11-485... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15697-11...
h1. Modify the Generated Classes
Ecore is built to be modified, the basic usage-pattern is to code and generate hand-in-hand. To tell the generator not to override your modifications you need to set the javadoc-annotation to anything different than *@generated*. Good practice says that you should set it to '@generated NOT'. Good practice also tells you to annotate any manually added method by *@ADDED*, but its optional though.
There is another handy that allows you to modify and get the generated code. If you want to have your code instead of the generated one, you just annotate accordingly and the generator will preserve your code. If you want the generated code, too, you'd need to create a method that has the original name + a suffix 'Gen'
example:
/**
*
* @generated NOT
*/
public void setName(String name) {
YOUR OWN CODE
}
/**
*
* @generated
*/
public void setNameGen(String name) {
GENERATOR provides the generated code in here
}
After making your modifications, you simply need to re-generate the ecore classes. (+*How?*+)
h1. Refactor generated Code and Regenerate
The code generator in EMF's is pretty capable when it's up to merge manual code changes in generated code. It respects *@generated* tags and preserves your handwritten code in generated classes.
If you rename a class in your ecore file though, it won't be able to detect your change. EMF has no clue that you renamed ecore class definitions. It will not be able to detect your java files because they have the old name. It will generate new artifacts and merging will not occur. You could copy your changes manually, but this is pretty cumbersome, there's a better approach to this use case:
Refactor/rename the generated java classes in a first step. Rename your ecore class definitions in a second step and regenerate afterwards. EMF will detect the preexisting artifacts and merge your manual code changes with the generated content. You will not have to copy your code manually.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-15705]
Create a new document in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 10 months
