[JBoss Tools] - Manually Creating Eclipse EMF Ecore Models
by Andre Dietisheim
Andre Dietisheim [http://community.jboss.org/people/adietisheim] modified the document:
"Manually Creating Eclipse EMF Ecore Models"
To view the document, visit: http://community.jboss.org/docs/DOC-15697
--------------------------------------------------------------
EMF provides tools for creating an EMF object model from an XML Schema (XSD). It also provides tools for hand-crafting a model. This document attempts to describe the process involved in the later.
+Note: All Content provided by André Dietisheim. Thanks André !!+
Usually you model your stuff in an editor (default ecore tree editor or emfatic text editor).
h1. Create The Package
The first step is to create a package for your model. You set its name, Ns Prefix and Ns URI.
The good practice (or at least what most modelers do) is to
- *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.
Usually the version is included in the uri to make sure different versions have an unique URI. The URI is needed so that the ecore runtime finds its metal-models (the classes, the type system).
example:
I have a plugin/module in cdo called *org.eclipse.emf.cdo.ui.defs*
The ecore model for it has the following definitions:
*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. Model Your Classes
You can now add classes to your package. There are usually several ways to get to the desired result, most likely the best way is to get the book or error and trial.
example:
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. What differs to real ecore-classes is that you set its instance type name: java.lang.Comparable. You can now add the Comparable class to the super type of each ecore-class you want to. Modeled this way, 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. 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-15697-3-4847... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15697-3-...
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-15697-3-4848... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15697-3-...
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-3-4849... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15697-3-...
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-3-4850... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15697-3-...
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?*+)
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-15697]
Create a new document in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
15 years, 8 months
[JBoss Tools] - Manually Creating Eclipse EMF Ecore Models
by Andre Dietisheim
Andre Dietisheim [http://community.jboss.org/people/adietisheim] modified the document:
"Manually Creating Eclipse EMF Ecore Models"
To view the document, visit: http://community.jboss.org/docs/DOC-15697
--------------------------------------------------------------
EMF provides tools for creating an EMF object model from an XML Schema (XSD). It also provides tools for hand-crafting a model. This document attempts to describe the process involved in the later.
+Note: All Content provided by André Dietisheim. Thanks André !!+
Usually you model your stuff in an editor (default ecore tree editor or emfatic text editor).
h1. Create The Package
h1. Create The Package
The first step is to create a package for your model. You set its name, Ns Prefix and Ns URI.
The good practice (or at least what most modelers do) is to
- 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.
Usually the version is included in the uri to make sure different version have a unique URI. The URI is needed so that the ecore runtime finds its metal-models (the classes, the type system).
example:
I have a plugin/module in cdo: org.eclipse.emf.cdo.ui.defs
The ecore model for it has the following definitions:
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. Model Your Classes
You can now add classes to your package. There are usually several ways to get to the desired result, most likely the best way is to get the book or error and trial.
example:
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. What differs to real ecore-classes is that you set its instance type name: java.lang.Comparable. You can now add the Comparable class to the super type of each ecore-class you want to. Modeled this way, 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. 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-15697-2-4847... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15697-2-...
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
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}').
Once you're done defining your model, you simply need to generate it. (+*Generate it how?*+)
h1. Generate your models (ecore based implementations)
*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?*+)
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-15697]
Create a new document in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
15 years, 8 months
[jBPM] - jBPM 3.2.3 (with Seam 2.2.0) on WebSphere
by Mike Fox
Mike Fox [http://community.jboss.org/people/mhfox] created the discussion
"jBPM 3.2.3 (with Seam 2.2.0) on WebSphere"
To view the discussion, visit: http://community.jboss.org/message/556706#556706
--------------------------------------------------------------
Hello,
I've got a Seam 2.2 app that that has been running on JBoss and I now need to get it running on WebSphere. I've run across an error now during the deployment of the business process. When it goes to the database to look for an existing process (which does exist) I get back an odd error as shown below:
java.lang.ClassCastException: org.jbpm.graph.def.ProcessDefinition incompatible with org.jbpm.graph.def.ProcessDefinition
at org.jbpm.db.GraphSession.findLatestProcessDefinition(GraphSession.java:153)
at uk.co.iblocks.jbpm.JbpmExtensions$ProcessDescriptor.<init>(JbpmExtensions.java:84)
at uk.co.iblocks.jbpm.JbpmExtensions.installProcessDefinitions(JbpmExtensions.java:404)
at uk.co.iblocks.jbpm.JbpmExtensions.startup(JbpmExtensions.java:352)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:600)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:144)
at org.jboss.seam.Component.callComponentMethod(Component.java:2249)
at org.jboss.seam.Component.callCreateMethod(Component.java:2172)
at org.jboss.seam.Component.newInstance(Component.java:2132)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:304)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:278)
at org.jboss.seam.contexts.ServletLifecycle.endInitialization(ServletLifecycle.java:116)
at org.jboss.seam.init.Initialization.init(Initialization.java:740)
at org.jboss.seam.servlet.SeamListener.contextInitialized(SeamListener.java:36)
at com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:1678)
at com.ibm.ws.webcontainer.webapp.WebApp.commonInitializationFinish(WebApp.java:371)
at com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:298)
at com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication(WebGroupImpl.java:100)
at com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication(VirtualHostImpl.java:166)
at com.ibm.ws.webcontainer.WSWebContainer.addWebApp(WSWebContainer.java:731)
at com.ibm.ws.webcontainer.WSWebContainer.addWebApplication(WSWebContainer.java:616)
at com.ibm.ws.webcontainer.component.WebContainerImpl.install(WebContainerImpl.java:376)
at com.ibm.ws.webcontainer.component.WebContainerImpl.start(WebContainerImpl.java:668)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:1122)
at com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectStart(DeployedApplicationImpl.java:1315)
at com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:619)
at com.ibm.ws.runtime.component.DeployedApplicationImpl.start(DeployedApplicationImpl.java:940)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:725)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:2046)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:439)
at com.ibm.ws.runtime.component.CompositionUnitImpl.start(CompositionUnitImpl.java:123)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:382)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.access$300(CompositionUnitMgrImpl.java:110)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl$CUInitializer.run(CompositionUnitMgrImpl.java:949)
at com.ibm.wsspi.runtime.component.WsComponentImpl$_AsynchInitializer.run(WsComponentImpl.java:349)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1550)
All I can figure is that it's pulling back a null and trying to cast that, but when I look at the hibernate query defined by GraphSession.findProcessDefinitionByNameAndVersion, everything looks good and there certainly should be data. I'm not seeing any hibernate issues at the DEBUG level in log4j.
Has anyone here ever run into this or something similar before?
thanks,
Mike
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/556706#556706]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 8 months
Re: [jboss-user] [jBPM] - StaleObjectStateException
by Maurice de Chateau
Maurice de Chateau [http://community.jboss.org/people/MohReece] replied to the discussion
"StaleObjectStateException"
To view the discussion, visit: http://community.jboss.org/message/556699#556699
--------------------------------------------------------------
Hi Gregory,
I don't know of any delays you can configure on JBoss AS to stall the relaying of JMS messages, but you might not want to change something like that at such a level - that may impact other applications running in the same environment, and you never know which those may be over time.
There is a way to delay the execution of Jobs, however, and it's quite simple, albeit a little labourious if you need it often.
You would need to call the *setDueDate(Date dueDate)* method on all of the Job objects you're scheduling. Just using new Date() as the input value schedules them for right now, adding the amount of time you need for a delay should do the trick. (And for that, DateUtils in Apache's commons lang library may be helping out, or you could use jBPM's own BusinessCalendar too).
HTH!
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/556699#556699]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 8 months
[JBoss Tools] - Manually Creating Eclipse EMF Ecore Models
by Tom Fennelly
Tom Fennelly [http://community.jboss.org/people/tfennelly] created the document:
"Manually Creating Eclipse EMF Ecore Models"
To view the document, visit: http://community.jboss.org/docs/DOC-15697
--------------------------------------------------------------
EMF provides tools for creating an EMF object model from an XML Schema (XSD). It also provides tools for hand-crafting a model. This document attempts to describe the process involved in the later.
+Note: All Content provided by André Dietisheim. Thanks André !!+
Usually you model your stuff in an editor (default ecore tree editor or emfatic text editor).
h1. Create The Package
The first step is to create a package for your model. You set its name, Ns Prefix and Ns URI.
The good practice (or at least what most modelers do) is to
- 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.
Usually the version is included in the uri to make sure different version have a unique URI. The URI is needed so that the ecore runtime finds its metal-models (the modeled classes, the type system).
example:
I have a plugin/module in cdo: org.eclipse.emf.cdo.ui.defs
The ecore model for it has the following definitions:
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. Model Your Classes
You can now add classes to your package. There are usually several ways to get to the desired result, most likely the best way is to get the book or error and trial.
example:
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. What differs to real ecore-classes is that you set its instance type name: java.lang.Comparable. You can now add the Comparable class to the super type of each ecore-class you want to. Modeled this way, 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. Create a genmodel
This is mostly straight forward. Select the ecore file and create a genmodel for it (+*How do I create a genmodel... is there a tool?*+) . There are mostly only 2 settings to change there:
'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
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}').
Once you're done defining your model, you simply need to generate it. (+*Generate it how?*+)
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 model. (+*How?*+)
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-15697]
Create a new document in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
15 years, 8 months
