Re: [jboss-user] [jBPM] - Human Task API and Data Structures Proposal
by gardellajp
gardellajp [https://community.jboss.org/people/gardellajp] commented on the document
"Human Task API and Data Structures Proposal"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-18641#comment-10142
--------------------------------------------------
Hi Mauricio,
Thanks open to debate to the community the design API. I propose use JSR-330 instead of CDI for DI, there are more providers (Spring, Guice, Seam for example).
Thanks
--------------------------------------------------
12 years, 5 months
- 1
- 0
[jBPM] - Human Task Module RoadMap
by Mauricio Salatino
Mauricio Salatino [https://community.jboss.org/people/salaboy21] modified the document:
"Human Task Module RoadMap"
To view the document, visit: https://community.jboss.org/docs/DOC-18617
--------------------------------------------------------------
I've being working with the Human Task module since I've started with my first steps in the jBPM community more than 3 years ago. Now it's time to take this component to the next level.
This wiki page describes the features and improvements that I will be tackling down on the next few months. If you have feedaback about this roadmap please leave a comment here or contact me.
Most of the changes and new features comes from people that is using jBPM or Drools and the Human Task module to handle Human Interactions, so feel free to drop a your suggestions or features that you would like to see in the short term.
I've divided the work into two different sides:
* External Improvements :* Starting from the Local Task Service I will be focused in the following topics* https://community.jboss.org/docs/DOC-18641 API improvements :Well defined interfaces and factories to interact with the human task functionality. Refactor towards CDI/WELD I will be adding here the proposed changes.
* Documentation & Examples: Documentation about the exposed APIs and about the semantic of each method.
** Transport improvements (probably using apache camel) and integration with different environments (Application Server, Servlet Containers)
* Internal Refactorings* https://community.jboss.org/docs/DOC-18641 Review Task, TaskData and I18N structures and queries
* Admin Operations and Queries
* Task Events and Queries
* Refactoring for callbacks mechanisms (Task Parent)
* Task Definition Deployment ( (deploy + new instance) instead of add)
* Lifecycle hooks
* Sub Tasks mechanisms
Notice that the External Changes will happen gradually and in parallel with the internal reviews.
*
#Review_Task_TaskData_and_I18N_structures_and_queries Review Task, TaskData and I18N structures and queries
*
#Admin_Operations_and_Queries_Improvements Admin Operations and Queries Improvements
*
#Task_Events_and_Queries Task Events and Queries
*
#Callbacks_Mechanisms_Review Callbacks Mechanisms Review
*
#Task_Definition_Deployment_and_Instantiation_mechanisms Task Definition Deployment and Instantiation mechanisms
*
#LifeCycle_Hooks LifeCycle Hooks
*
#Sub_Tasks_and_Ad_Hoc_Sub_Tasks_Creation Sub Tasks and Ad Hoc Sub Tasks Creation
I've added my personal priority, but feel free to leave a comment if you have another topics or if you feel that one of these bullets needs to be prioritized.
(10 is Top Priority and 1 Low)
h1. Review Task, TaskData and I18N structures and queries
A deep process of documentation and review of the core data structures that are being used by the module will be done. The main focus
of this revision is to improve these structures to be easily accessed and work in the best way possible. The queries associated to these entities
will be reviewed, extended and documented as necessary. Migration scripts should be provided for migrating the old structures to the new ones in case that new structures
modifies core fields.
A detailed documentation about these structures and the generated tables should be provided by this revision.
A categorization about the provided queries should also be included to identify missing bits.
A set of mock task structures and tests for the queries should be provided to guarrantee the expected results.
Update: Based on revisions to the WS-HT specification and the current structures, I've started to belive that including the concept of
TaskDefinition will help us to create a simplier API, a simple deployment and instantiation mechanism and the relationship between the
different pieces of information that are kept.
This will help us to create simple queries on TaskInstances and more straight forward mechanisms.
All the Presentation, Assignment and delegation related fields can be extracted from the task itself and query only when an operation is executed.
For rendering the only information that matters is the one related with each particular task instance. We can avoid the need of querying for all the
other bits of information.
Update 2: https://community.jboss.org/wiki/HumanTaskAPIAndDataStructuresProposal (https://community.jboss.org/docs/DOC-18641)
Salaboy Priority: 9
h1. Admin Operations and Queries Improvements
All the administrative operations will be centralized in one place. Removing, archiving and querying finished tasks, and all the associated data.
These operations will include:
* Archive Finished Tasks
* Delete Finished Tasks
* Get all the finished tasks by Process instance
* Get all the finished tasks by Process Definition
* Etc.
Salaboy Priority: 7
h1. Task Events and Queries
Provide a mechanisms to record all the events derived by the Task interactions.
The WS-HT Specification defines 30 events that will be emited by the Human Task component depending on the different interactions against a human task instance.
A mechanism to record and query these events will be implemented.
Salaboy Priority: 7
h1. Callbacks Mechanisms Review
The main focus of this review is to extend and abstract the current methods that are being used for registering callabacks from third party components that wants to
keep track of the tasks' lifecycle.
Having different strategies for setting up callbacks will decouple the responsability for this module to decide how to contact the interested components. Providing
an interface to implement these callbacks in an application dependant way will allow us to describe best practices depending on the third party application requirements.
Salaboy Priority: 6
Topic included here also: https://community.jboss.org/wiki/HumanTaskAPIAndDataStructuresProposal (https://community.jboss.org/docs/DOC-18641)
h1. Task Definition Deployment and Instantiation mechanisms
The WS-HT specification defines to phases to Deploy a task definition and then to create an instance for a specific task definition.
This feature will allow us to have global tasks definitions that can be instantiated multiple times once we get a definition deployed. This mechanism
will give us a fine grained control about who creates a task and how the interactions are done.
Salaboy Priority: 4
Topic included here also: https://community.jboss.org/wiki/HumanTaskAPIAndDataStructuresProposal (https://community.jboss.org/docs/DOC-18641)
h1. LifeCycle Hooks
A flexible mechanism to define and plug your own task lifecycles will be provided, increasing the flexibility of the Human Task module to fit more simpler and more complex scenarios.
Salaboy Priority: 4
h1. Sub Tasks and Ad Hoc Sub Tasks Creation
Having a good and flexible mechanisms for creating sub tasks is a very important feature to have and to show. It will allows us to have new tasks defined on the fly depending on
a parent User Task defined in our business processes.
Salaboy Priority: 6
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-18617]
Create a new document in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
12 years, 5 months
- 1
- 0
[jBPM] - Human Task API and Data Structures Proposal
by Mauricio Salatino
Mauricio Salatino [https://community.jboss.org/people/salaboy21] modified the document:
"Human Task API and Data Structures Proposal"
To view the document, visit: https://community.jboss.org/docs/DOC-18641
--------------------------------------------------------------
h1. *
#Introduction Introduction
*
#Task_Def_Service Task Def Service
***
#Task_Def_Structure Task Def Structure
***
#Task_Instance_Queries Task Instance Queries
**
#Task_Presentation_Service Task Presentation Service
**
#Task_Assignments_Service Task Assignments Service
**
#Task_Delegation_Service Task Delegation Service
**
#Task_Notification_Service_ Task Notification Service
*
#Task_Instance_Service Task Instance Service
***
#Task_Instance_Structure Task Instance Structure
***
#Task_Instance_Queries_931664 Task Instance Queries
**
#Task_Attachment_and_Comment_Services_ Task Attachment and Comment Services
**
#_Task_Events_Callbacks_Listeners_Service Task Events, Callbacks, Listeners Service
h1. Introduction
Based on the previous document for reviewing the architecture and APIs exposed by the Human Task module I've came up with this first schetck of proposal for changes.
I've decided for this stage to show a more modular approach that the one provided by the current implementation.
This modular approach will let us scale if more functionality is required without the need of chainging the interfaces of the already existing services. It will also allow us to
provide different implementations for each of the modules which will give us a lot of flexibility to integrate with different technologies. For example provide an Attachments Service
which uses a Content Repository and keep the comments in a database. We will be able to mix and match based on the scenario requirement.
The main focus of this proposal is to decouple all the logical services provided by the Human Task module and enable different implementations to cohexist under the same set of APIs.
This document describe also the Data Structures and Interfaces that will be exposed to the end User. All the other internal mechanisms and classes will be hidden.
https://community.jboss.org/servlet/JiveServlet/showImage/18895/TaskServi... https://community.jboss.org/servlet/JiveServlet/downloadImage/18895/TaskS...
The figure shows the logical organization of the proposed services. The services are logically grouped Task Definition Services and Task Instances Services.
All the services will be created using CDI beans, which will allow us to expose them via Switchyard / Camel ( https://docs.jboss.org/author/display/SWITCHYARD/Bean+Services https://docs.jboss.org/author/display/SWITCHYARD/Bean+Services)etc. In other words, these services will be completely agnostic of the
transports that different applications under different scenarios can use to interact with them. Using CDI will enable us to define different profiles and configurations for the module
depending on the scenario that we want to use it. Meaning that if you don't need a service, you just don't use it and you don't need to suffer the footprint of that unused service.
The following sections explain the scope of the proposed services:
h1. Task Def Service
A Task Definition is a structure that contains a reusable structure to define a Human Interaction. By reusable I mean, a Task that can be executed multiple times and
that shares static information, such as Assignments, Delegation options, Deadlines, Notifications, etc. If all this information can be shared we can reduce the definition time
just providing the users to select on of the provided definitions, instead of defining all this information every time that a task is required.
The task service def service will deal with static Human Task Definitions. These definitions can be generated by the userTasks from a business processes or via the
provided APIs by third parties applications. We will be able to deploy new task definitions to the service, list all the available definitions based on different criterias, etc.
A set of more specific services will be provided to store and manage additional information about Task Definitions.
TaskDefService taskDefService = container.instance().select(TaskDefService.class).get();
// We can automatically create TaskDef based on the BPMN2 file
// We can enrich those tasks with the form builder
//From the spec: register, port == taskdefid
String port = taskDefService.deployTaskDef(id, taskdef);
// list
taskDefService.listTaskDef();
// getById
taskDefService.getTaskDef(id);
// unregister
taskDefService.undeployTaskDef(id);
h3. Task Def Structure
TBD
h3. Task Instance Queries
TBD
h2. Task Presentation Service
The task presentation service will allow us to provide more information about how a task will be presented to the users. This will include the I18N options for all the texts
related to a task such as Subject, Description, Goals, etc. Decoupling this logic and structures in a different service will allow us to only query this information when it's needed and
not everytime that we want to interact with a task. Because this is not a core service, we can choose to not use it and disable it if our implementation doesn't require such presentation information.
This service will allow us to define common presentation elements that can be shared among different task definitions.
TaskPresentationService taskPresentationService = container.instance().select(TaskPresentationService.class).get();
//Internally it will use taskDef.getTaskDef(id).getPresentationElements()
List<PresentationElement> presentationElements = taskPresentationService.getPresentationElements(taskId);
h2. Task Assignments Service
The task Assignment service will be in charge of hosting information about task assignments. This information will describe the potentialOwners, excludedOwners, StakeHolders, BusinessAdmins, etc.
All this information will be related with a task definition and not with a task instance. In other words this is about static definitions (doing on modeling time) of the task and not about the
assignments that will be defined at runtime when a Task Instance is created. Having this information decoupled will allow us to define different strategies for validating, querying and interacting with
an external identity service. When a Task instance is created, using this information plus the runtime context and the defined strategies the concrete assigments will be applied to the Task instance.
Instead of store and duplicate assignment information per task , we can reuse the assignments from previously defined tasks.
h2. Task Delegation Service
This service will host different delegation schemas that can be used by the task definitions. Depending on the business scenario were the human interactions will be defined, this service will host common patterns that can be reused by Task Definitions. Instead of store and duplicate delegation/escalation information per task , we can reuse the delegationescalation information from previously defined tasks.
h2. Task Notification Service
The service expose an interface that allows us to define templates for notifications that can be used on Task Deadlines, Lifecycle Events, Callbacks.
h1. Task Instance Service
Once we have a Task Definiton deployed we can start creating instances of a specific Task Definition Type. The instance will use the static information provided
by the task definition to create the new Task Instance. The information about assignments, deadlines and escalations/delegations will be defined inside the Task Definition (which support
expressions) . When a new instance is created all the expressions are resolved and the task will only contain the relevant data for execution. If at runtime more information about the Task Definition is required, the Task Instance Service can use the Task Definition Service internally to get generic information.
The Task Instance Service will expose the life cycle methods to interact with a Task Instance, such as: start, complete, forward, claim, release, etc (WS-HT defined methods).
Internally, the Task Instance Service will contain the core logic to represent the task life cycle.
Having this Service decoupled from the rest will allow us to improve that logic and have a well defined boundary of the module capabilties and responsabilities. Because we are working
to provide a pluggable life cycle mechanism, different Task Instances Services implementation can be provided. Using CDI decorators and qualifiers the API usage will be extremely improved
and it will easily allow us to run the component in any environment (From standalone to EE with major changes).
Sync and Async Services should be modeled using CDI qualifiers instead of different interfaces.
// Lifecycle and query methods for task instances only!!!!
TaskInstanceService taskInstanceService = container.instance().select(TaskInstanceService.class).get();
long taskId = taskInstanceService.newTask(port, params);
taskInstanceService.start(taskId);
taskInstanceService.complete(taskId, params);
taskInstanceService.forward(taskId, "user");
h3. Task Instance Structure
TBD
h3. Task Instance Queries
TBD
h2. Task Attachment and Comment Services
Both services are decoupled to allow fine grained control on how the attachments are handled and stored. Depending on the context on the task and the architecture we the Human Interactions will happen is how we will want to handle attachments. Providing a decoupled interface for these services will allow us to gradually support different ways to store this information that is related with a specific task instance.
TaskAttachmentService taskAttachmentService = container.instance().select(TaskAttachmentService.class).get();
taskAttachmentService.addAttachment(taskId, attachment);
List<Attachment> attachs = taskAttachmentService.getAttachments(taskId);
TaskCommentService taskCommentService = container.instance().select(TaskCommentService.class).get();
taskCommentService.addComment(taskId, comment);
List<Comment> comments = taskCommentService.getComments(taskId);
taskCommentService.removeComment(commentId);
h2. Task Events, Callbacks, Listeners Service
This service will expose a set of APIs that will allow external applications to register interest and callback functions to a Task Instance or a group of Task Instances (could be also by Task Definition).
When a third party application creates a task inside the human task module, it will automatically becomes the owner of the task. If the application is interested in being notified about the Task Lifecycle or just a small set of events, the application will need to register a callback function or identifier which enables the component to contact back the application. This callbacks and listeners information should be (once again) agnostic to the transport. This information will represent a logic description about how to contact a third party application if it is needed, but several implementations can be plugged to achieve the desired behavior on runtime. We can leverage the Events features of CDI for listeners and callbacks.
Having this service as a decoupled module will allow us to:
* Provide different strategies for different environments
* Allow external components to be notified (pull) or to poll the task events notifications and execute the callbacks for us. Meaning that we expose the information
about what needs to happen but not how it will happen. Reducing the complexity of the component and leveraging already implemented features from frameworks like Switchard / Camel.
h2.
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-18641]
Create a new document in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
12 years, 5 months
- 1
- 0
[jBPM] - Human Task API and Data Structures Proposal
by Mauricio Salatino
Mauricio Salatino [https://community.jboss.org/people/salaboy21] modified the document:
"Human Task API and Data Structures Proposal"
To view the document, visit: https://community.jboss.org/docs/DOC-18641
--------------------------------------------------------------
h1. *
#Introduction Introduction
*
#Task_Def_Service Task Def Service
**
#Task_Presentation_Service Task Presentation Service
**
#Task_Assignments_Service Task Assignments Service
**
#Task_Delegation_Service Task Delegation Service
***
#Task_Notification_Service_ Task Notification Service
*
#Task_Instance_Service Task Instance Service
**
#Task_Attachment_and_Comment_Services_ Task Attachment and Comment Services
**
#_Task_Events_Callbacks_Listeners_Service Task Events, Callbacks, Listeners Service
h1. Introduction
Based on the previous document for reviewing the architecture and APIs exposed by the Human Task module I've came up with this first schetck of proposal for changes.
I've decided for this stage to show a more modular approach that the one provided by the current implementation.
This modular approach will let us scale if more functionality is required without the need of chainging the interfaces of the already existing services. It will also allow us to
provide different implementations for each of the modules which will give us a lot of flexibility to integrate with different technologies. For example provide an Attachments Service
which uses a Content Repository and keep the comments in a database. We will be able to mix and match based on the scenario requirement.
The main focus of this proposal is to decouple all the logical services provided by the Human Task module and enable different implementations to cohexist under the same set of APIs.
https://community.jboss.org/servlet/JiveServlet/showImage/18895/TaskServi... https://community.jboss.org/servlet/JiveServlet/downloadImage/18895/TaskS...
The figure shows the logical organization of the proposed services. The services are logically grouped Task Definition Services and Task Instances Services.
All the services will be created using CDI beans, which will allow us to expose them via Switchyard / Camel ( https://docs.jboss.org/author/display/SWITCHYARD/Bean+Services https://docs.jboss.org/author/display/SWITCHYARD/Bean+Services)etc. In other words, these services will be completely agnostic of the
transports that different applications under different scenarios can use to interact with them. Using CDI will enable us to define different profiles and configurations for the module
depending on the scenario that we want to use it. Meaning that if you don't need a service, you just don't use it and you don't need to suffer the footprint of that unused service.
The following sections explain the scope of the proposed services:
h1. Task Def Service
A Task Definition is a structure that contains a reusable structure to define a Human Interaction. By reusable I mean, a Task that can be executed multiple times and
that shares static information, such as Assignments, Delegation options, Deadlines, Notifications, etc. If all this information can be shared we can reduce the definition time
just providing the users to select on of the provided definitions, instead of defining all this information every time that a task is required.
The task service def service will deal with static Human Task Definitions. These definitions can be generated by the userTasks from a business processes or via the
provided APIs by third parties applications. We will be able to deploy new task definitions to the service, list all the available definitions based on different criterias, etc.
A set of more specific services will be provided to store and manage additional information about Task Definitions.
TaskDefService taskDefService = container.instance().select(TaskDefService.class).get();
// We can automatically create TaskDef based on the BPMN2 file
// We can enrich those tasks with the form builder
//From the spec: register, port == taskdefid
String port = taskDefService.deployTaskDef(id, taskdef);
// list
taskDefService.listTaskDef();
// getById
taskDefService.getTaskDef(id);
// unregister
taskDefService.undeployTaskDef(id);
h2. Task Presentation Service
The task presentation service will allow us to provide more information about how a task will be presented to the users. This will include the I18N options for all the texts
related to a task such as Subject, Description, Goals, etc. Decoupling this logic and structures in a different service will allow us to only query this information when it's needed and
not everytime that we want to interact with a task. Because this is not a core service, we can choose to not use it and disable it if our implementation doesn't require such presentation information.
This service will allow us to define common presentation elements that can be shared among different task definitions.
TaskPresentationService taskPresentationService = container.instance().select(TaskPresentationService.class).get();
//Internally it will use taskDef.getTaskDef(id).getPresentationElements()
List<PresentationElement> presentationElements = taskPresentationService.getPresentationElements(taskId);
h2. Task Assignments Service
The task Assignment service will be in charge of hosting information about task assignments. This information will describe the potentialOwners, excludedOwners, StakeHolders, BusinessAdmins, etc.
All this information will be related with a task definition and not with a task instance. In other words this is about static definitions (doing on modeling time) of the task and not about the
assignments that will be defined at runtime when a Task Instance is created. Having this information decoupled will allow us to define different strategies for validating, querying and interacting with
an external identity service. When a Task instance is created, using this information plus the runtime context and the defined strategies the concrete assigments will be applied to the Task instance.
Instead of store and duplicate assignment information per task , we can reuse the assignments from previously defined tasks.
h2. Task Delegation Service
This service will host different delegation schemas that can be used by the task definitions. Depending on the business scenario were the human interactions will be defined, this service will host common patterns that can be reused by Task Definitions. Instead of store and duplicate delegation/escalation information per task , we can reuse the delegationescalation information from previously defined tasks.
h3. Task Notification Service
The service expose an interface that allows us to define templates for notifications that can be used on Task Deadlines, Lifecycle Events, Callbacks.
h1. Task Instance Service
Once we have a Task Definiton deployed we can start creating instances of a specific Task Definition Type. The instance will use the static information provided
by the task definition to create the new Task Instance. The information about assignments, deadlines and escalations/delegations will be defined inside the Task Definition (which support
expressions) . When a new instance is created all the expressions are resolved and the task will only contain the relevant data for execution. If at runtime more information about the Task Definition is required, the Task Instance Service can use the Task Definition Service internally to get generic information.
The Task Instance Service will expose the life cycle methods to interact with a Task Instance, such as: start, complete, forward, claim, release, etc (WS-HT defined methods).
Internally, the Task Instance Service will contain the core logic to represent the task life cycle.
Having this Service decoupled from the rest will allow us to improve that logic and have a well defined boundary of the module capabilties and responsabilities. Because we are working
to provide a pluggable life cycle mechanism, different Task Instances Services implementation can be provided. Using CDI decorators and qualifiers the API usage will be extremely improved
and it will easily allow us to run the component in any environment (From standalone to EE with major changes).
Sync and Async Services should be modeled using CDI qualifiers instead of different interfaces.
// Lifecycle and query methods for task instances only!!!!
TaskInstanceService taskInstanceService = container.instance().select(TaskInstanceService.class).get();
long taskId = taskInstanceService.newTask(port, params);
taskInstanceService.start(taskId);
taskInstanceService.complete(taskId, params);
taskInstanceService.forward(taskId, "user");
h2. Task Attachment and Comment Services
Both services are decoupled to allow fine grained control on how the attachments are handled and stored. Depending on the context on the task and the architecture we the Human Interactions will happen is how we will want to handle attachments. Providing a decoupled interface for these services will allow us to gradually support different ways to store this information that is related with a specific task instance.
TaskAttachmentService taskAttachmentService = container.instance().select(TaskAttachmentService.class).get();
taskAttachmentService.addAttachment(taskId, attachment);
List<Attachment> attachs = taskAttachmentService.getAttachments(taskId);
TaskCommentService taskCommentService = container.instance().select(TaskCommentService.class).get();
taskCommentService.addComment(taskId, comment);
List<Comment> comments = taskCommentService.getComments(taskId);
taskCommentService.removeComment(commentId);
h2. Task Events, Callbacks, Listeners Service
This service will expose a set of APIs that will allow external applications to register interest and callback functions to a Task Instance or a group of Task Instances (could be also by Task Definition).
When a third party application creates a task inside the human task module, it will automatically becomes the owner of the task. If the application is interested in being notified about the Task Lifecycle or just a small set of events, the application will need to register a callback function or identifier which enables the component to contact back the application. This callbacks and listeners information should be (once again) agnostic to the transport. This information will represent a logic description about how to contact a third party application if it is needed, but several implementations can be plugged to achieve the desired behavior on runtime. We can leverage the Events features of CDI for listeners and callbacks.
Having this service as a decoupled module will allow us to:
* Provide different strategies for different environments
* Allow external components to be notified (pull) or to poll the task events notifications and execute the callbacks for us. Meaning that we expose the information
about what needs to happen but not how it will happen. Reducing the complexity of the component and leveraging already implemented features from frameworks like Switchard / Camel.
h2.
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-18641]
Create a new document in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
12 years, 5 months
- 1
- 0
[JBoss Tools] - Deploy from Eclipse to OpenShift in a breeze
by Andre Dietisheim
Andre Dietisheim [https://community.jboss.org/people/adietish] modified the blog post:
"Deploy from Eclipse to OpenShift in a breeze"
To view the blog post, visit: https://community.jboss.org/community/tools/blog/2012/06/27/deploy-from-e...
--------------------------------------------------------------
*
#Dont_get_your_fingers_dirty_use_the_JBoss_Tools_for_OpenShift Dont get your fingers dirty, use the JBoss Tools for OpenShift
**
#Get_the_tools_get_started Get the tools, get started
*
#A_very_basic_workflow A very basic workflow
**
#Create_your_application_runtime Create your application runtime
**
#Push_to_build_and_deploy Push to build and deploy
**
#Server_Adapter_to_the_rescue Server Adapter to the rescue
*
#Deploy_my_very_own_project Deploy my very own project!
**
#Have_your_project_ready Have your project ready
**
#JBoss_Tools_configure_my_project JBoss Tools, configure my project
**
#Oh_my_project_how_you_changed Oh my project, how you changed!
**
#Push_me_up_Scotty Push me up, Scotty
**
#Multimodule_maven_projects Multi-module maven projects
*
#My_maven_project_is_not_in_the_git_repo_root My maven project is not in the git repo root
**
#Have_your_project_ready_142319 Have your project ready
**
#Create_your_OpenShift_application Create your OpenShift application
**
#OpenShift_here_I_come OpenShift, here I come
h1. Dont get your fingers dirty, use the JBoss Tools for OpenShift
https://openshift.redhat.com/app/ OpenShift is the PaaS offering from http://www.redhat.com Red Hat. It gives you your personal application platform on demand. With OpenShift, there's no need to look for hosting and application stack. OpenShift provides you those within minutes, whenever you need them.
http://www.jboss.org/tools JBoss Tools for OpenShift offers a feature complete environment to work with OpenShift. From developing to deploying, JBoss Tools provides you a fully fledged environment for your project and aligns with the standard workflows within Eclipse. It allows Eclipse users to stick to their favorite IDE and deal with OpenShift within their developement environment. Especially the OpenShift server adapter mimics an http://www.eclipse.org/webtools/ Eclipse WTP compliant way of deploying to OpenShift and hides the complexity, that you'd otherwise had to handle when publishing bare metal (which is by using Git).
h2. Get the tools, get started
The https://community.jboss.org/community/tools/blog/2012/06/21/jboss-tools-3... release blog shows you extensively how to get JBoss Tools from our update site, from the Eclipse marketplace or even how to install the https://devstudio.jboss.com/download/ JBoss Developer Studio. If installing JBoss Tools, you'll have to make sure you choose at least the OpenShift bundles on our update site:
https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188... (https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18803/u...)
Once you have JBoss Tools installed, you'll spot our wizards either in JBoss Central or in the Eclipse Wizards:
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18806/c... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
All you need to get started quickly is offered within this wizard. It'll create your application platform, import a starter project and create a server adapter that you may use to publish to the PaaS.
OpenShift of course requires you to have an account. If you have none yet, the wizard will drop you to the signup form by hitting the link that is displayed on the first wizard page.
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18807/s... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
Once you have your account, you'll be ready to go, ready to get amazed by JBoss Tools and OpenShift.
h1. A very basic workflow
OpenShift is a http://en.wikipedia.org/wiki/Platform_as_a_service PaaS, a Platform as a Service. As such it offers you your personal application stack and it does this on demand. A range of standards runtimes are offered to you whenever you need them. Working with the PaaS is as simple as importing a stub (the starter application) to your workspace, changing and publishing it again:
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18892/o... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
h2. Create your application runtime
It all starts by creating your own application runtime. In the OpenShift Application wizard, set a name and choose the application (runtime) you need:
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18809/a... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
OpenShift offers a wide range of standard runtimes. You may to choose among php, ruby, phython, nodejs etc. Java developers will be most amazed to see that OpenShift offers a fully Java EE 6 compliant application server: the blazing fast http://www.jboss.org/as7 JBoss AS 7.1.
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18810/a... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
You may also add different extensions to your platform ranging from SQL- (like MySQL or Postgres) or NoSQL-databases (like MongoDB) up to your very own CI server (jenkins).
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18811/a... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
Once you made up your choices and finish the wizard, it'll create your OpenShift application, wait for it to become reachable and import it's initial content - a starter application - to your Eclipse workspace. Looking into your Project Explorer or Navigator, you'll spot the new project that the wizard imported. It has the very same name as the OpenShift application. In case of a JBoss AS7 runtime, the starter app is a maven artifact and the project we import to your workspace will have the name that's configured for the maven artifact.
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18852/i... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
h2. Push to build and deploy
The new project in your Eclipse workspace is where you apply your changes. It is shared with a git repository on your local machine. This repository is a clone of the git repository within your OpenShift application.
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18853/a... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
Deploying this project to the PaaS is as simple as pushing the local repository to it's origin, the OpenShift git repository. OpenShift will then build and deploy your application to the application runtime.
In case of a Java application, OpenShift relies on a maven based build, that is triggered with each git push:
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18817/a... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
h2. Server Adapter to the rescue
When dealing with git, you have to deal with a brilliant but rather complex code versioning system. Even if you're familiar with git, there's still room to reduce the number of manipulations when publishing.
http://www.eclipse.org/webtools/ Eclipse WTP server adapters historically allow you to interact with your server. This would typically be some local or remote server you'd have file- or SSH-based access to. We adapted this handy concept and implemented a variant that would work with OpenShift. This server adapter hides the complexity of dealing with git and allows 1-click publishing to the cloud.
The OpenShift Application wizard sets the adapter up when you create your application and import the starter project to your workspace. Our Server adapter is bound to the OpenShift project in your workspace and it'll do the git operations for you.
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18818/s... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
When publishing it will deploy the changes in your OpenShift project to the PaaS. It'll hide all the complexity that is inherent to git. It will commit your changes to your local clone and push them to the git repository of your OpenShift application (the origin).
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18819/s... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
h1. Deploy my very own project!
Importing the starter application to your workspace is the most simple usecase we provide. I bet most users already have a project that they'd want to deploy though. We of course also provide this ability in our OpenShift Application wizard.
Our little screencast shows you the steps when starting with your very own project. It uses the kitchensink example to demonstrate how this would occourr. You may get it on github:
> *Kitchensink example project:*
>
> https://github.com/adietish/kitchensink.git https://github.com/adietish/kitchensink.git
h2. Have your project ready
You first have to get your project to Eclipse. We only support *git-shared or non-shared project* though. A typical usecase would be to have your project on https://github.com/ github or in any other git repository.You then simply clone it's repository to your local machine (using http://www.eclipse.org/egit/ EGit or the command line) and import the project within it to your Eclipse workspace.
h2. JBoss Tools, configure my project
You then create your OpenShift application in our wizard, provide the name, type and eventually additional cartridges. You then switch to the second wizard page and tell the wizard that you dont want to create a new project in your workspace. You tell it to use your project instead.
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18854/u... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
The wizard will warn you about upcoming changes to your project and ask you to confirm:
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18886/m... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
h2. Oh my project, how you changed!
We then add OpenShift specific configurations to your project. These changes unfortunately cannot be undone. You'd have to provide your own means (ex. a separate branch) if you dont want these additions in your developement code The changes we apply are the following:
> *All changes:*
> *
> *
> * eventually create a git repository and commit your project to it
> * add a *.op**enshift* folder with openshift specific hooks
> * add a *deployments* folder
> * add the Eclipse specific files (.project, .classpath etc.) to the *.gitignore*
> * add *openshift-profile* to the pom
> * add OpenShift *git repo as remote* to your local git repo
>
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18855/m... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
Since publishing to OpenShift is git pushing to it, we'll make sure your project is shared to a *git repo*. We therefore eventually create a git repository for your project if there's none yet and add your project to it.
We add the *.openshift* folder which may contain OpenShift specific configurations and tweaks (like custom build-scripts, markers, cron entries etc.). We also create a *deployments* folder which OpenShift will use to build to. You may also add additional artifacts to it.
We then tweak *.gitignore* and add the Eclipse specific files so that they dont make it to the git repo by default.
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18857/m... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
For maven-based java projects we tweak the *pom* and add an openshift profile to it.
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18858/o... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
The openshift profile is what the PaaS is using when building your project on the PaaS. The profile we add is telling maven to create the war in the deployments folder. The deployments folder is where JBoss AS7 is expecting and picking new deployables from. Adding the profile makes sure that your project is deployed when it is built.
We'll also then add the OpenShift application git repo as *remote* to the git repo of your local project. This will allow you to push your project to OpenShift without knowing about the exact url you'll have to push to. All you have to know is what name the OpenShift repo is stored at.
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18871/m... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
We're storing the OpenShift application git url as "openshift" in the remotes known to your local repo. You may of course tell the wizard to use any name you like:
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18872/m... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
h2. Push me up, Scotty
Once we configured your project, we commit the changes to your local git repo (either your project was already shared with a git repo or we created one for you). To now deploy your project to OpenShift, you'd have to go to the Servers view, choose the OpenShift server adapter (that we created for you) and tell it to *publish*. The server adapter will then detect that the local project is ahead of the remote one and that publishing would only be possible when overriding the remote starter application. It'll ask you to confirm this step:
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18887/m... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
Once the publishing is done, you'll have your project running on OpenShift!
h2. Multi-module maven projects
Our OpenShift Application wizard also supports multi-module maven projects. You'd simply have to make sure all modules are nested within a parent project and choose the parent project as existing project (multi vs. multi-web, multi-ejb, multi-ejb in my screenshot) in the wizard:
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18889/m... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18890/m... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
> *Note:*
>
> in case your multi-module maven project is an ear, there are still slight limitations in our tooling for the moment. You may easily work around them though. You'd have to alter the maven profile in the pom of your parent-projec and replace the maven-war-plugin by the maven-ear-plugin:
>
> https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18870/m... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
>
> You may read about it in all details and track our progress on it in https://issues.jboss.org/browse/JBIDE-12252 JBIDE-12252
h1. My maven project is not in the git repo root
When deploying an existing project to OpenShift, you'd have to tell the wizard in JBoss Tools about your project. Your project would have to comply to a basic layout though. We expect the pom in the root of your git repository. If this is not the case, then you'd have to take an alternative approach when publishing. Publishing then gets as easy as drag and dropping your project to the adapter.
In our screencast, we show you how to proceed. We use the the ticket-monster example project which is available at github:
> *Ticket-monster example project:*
>
> https://github.com/jboss-jdf/ticket-monster https://github.com/jboss-jdf/ticket-monster
h2. Have your project ready
The first thing to do is to import your application to your Eclipse workspace. The only requirement we have is that your project shall be http://www.eclipse.org/webtools/ Eclipse WTP compliant. It may be a Dynamic Web or a Maven project. Maven projects are turned into Eclipse WTP projects if you have https://www.eclipse.org/m2e-wtp/ m2e-wtp installed when importing them (m2e-wtp bridges the gap between Eclipse WTP and maven, it turns any maven project into a WTP compliant project).
In the ticket-monster example, the maven project is nested into the demo folder:
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18881/d... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
We import with the Eclipse Maven import wizard pointing it to the demo-folder:
h2. Create your OpenShift application
Once you have your project ready you'll go and create the OpenShift application that will host your application. Launch the OpenShit Application wizard in JBoss Tools, tell it to create a *jbossas-7* application and let it import the starter app, as shown in the first paragraphs of this blog.
h2. OpenShift, here I come
The OpenShift Application wizard imports the starter application to your workspace and creates a server adapter for it:
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18891/d... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18878/d... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
You are then ready to publish your project. Simply drag and drop it to the OpenShift *server adapter* in the Servers view. Your project will then get published to OpenShift.
Once the publishing is done, you'll notice that the server adapter now has 2 modules: the starter application and your project:
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18882/d... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
The server adapter actually compressed your project to a war and dropped it to the deployments folder within the starter application:
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18883/d... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
It then committed this addition and pushed the starter application to OpenShift. The JBoss AS7 then noticed the new war and deployed it. Simple as that.
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/community/tools/blog/2012/06/27/deploy-from-e...]
12 years, 5 months
- 1
- 0
[jBPM] - Re: Human tasks : LocalTaskService JTA issue
by Maciej Swiderski
Maciej Swiderski [https://community.jboss.org/people/swiderski.maciej] created the discussion
"Re: Human tasks : LocalTaskService JTA issue"
To view the discussion, visit: https://community.jboss.org/message/744555#744555
--------------------------------------------------------------
that sounds very weird as can find any reason why it would work only for new processes. Once it is registered on the session that is moving on with the process instance.
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/744555#744555]
Start a new discussion in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
12 years, 5 months
- 1
- 0
[JBoss Tools] - Deploy from Eclipse to OpenShift in a breeze
by Andre Dietisheim
Andre Dietisheim [https://community.jboss.org/people/adietish] modified the blog post:
"Deploy from Eclipse to OpenShift in a breeze"
To view the blog post, visit: https://community.jboss.org/community/tools/blog/2012/06/27/deploy-from-e...
--------------------------------------------------------------
*
#Dont_get_your_fingers_dirty_use_the_JBoss_Tools_for_OpenShift Dont get your fingers dirty, use the JBoss Tools for OpenShift
**
#Get_the_tools_get_started Get the tools, get started
*
#A_very_basic_workflow A very basic workflow
**
#Create_your_application_runtime Create your application runtime
**
#Push_to_build_and_deploy Push to build and deploy
**
#Server_Adapter_to_the_rescue Server Adapter to the rescue
*
#Deploy_my_very_own_project Deploy my very own project!
**
#Have_your_project_ready Have your project ready
**
#JBoss_Tools_configure_my_project JBoss Tools, configure my project
**
#Oh_my_project_how_you_changed Oh my project, how you changed!
**
#Push_me_up_Scotty Push me up, Scotty
**
#Multimodule_maven_projects Multi-module maven projects
*
#My_maven_project_is_not_in_the_git_repo_root My maven project is not in the git repo root
**
#Have_your_project_ready_127964 Have your project ready
**
#Create_your_OpenShift_application Create your OpenShift application
**
#OpenShift_here_I_come OpenShift, here I come
h1. Dont get your fingers dirty, use the JBoss Tools for OpenShift
https://openshift.redhat.com/app/ OpenShift is the PaaS offering from http://www.redhat.com Red Hat. It gives you your personal application platform on demand. With OpenShift, there's no need to look for hosting and application stack. OpenShift provides you those within minutes, whenever you need them.
http://www.jboss.org/tools JBoss Tools for OpenShift offers a feature complete environment to work with OpenShift. From developing to deploying, JBoss Tools provides you a fully fledged environment for your project and aligns with the standard workflows within Eclipse. It allows Eclipse users to stick to their favorite IDE and deal with OpenShift within their developement environment. Especially the OpenShift server adapter mimics an http://www.eclipse.org/webtools/ Eclipse WTP compliant way of deploying to OpenShift and hides the complexity, that you'd otherwise had to handle when publishing bare metal (which is by using Git).
h2. Get the tools, get started
The https://community.jboss.org/community/tools/blog/2012/06/21/jboss-tools-3... release blog shows you extensively how to get JBoss Tools from our update site, from the Eclipse marketplace or even how to install the https://devstudio.jboss.com/download/ JBoss Developer Studio. If installing JBoss Tools, you'll have to make sure you choose at least the OpenShift bundles on our update site:
https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188... (https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18803/u...)
Once you have JBoss Tools installed, you'll spot our wizards either in JBoss Central or in the Eclipse Wizards:
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18806/c... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
All you need to get started quickly is offered within this wizard. It'll create your application platform, import a starter project and create a server adapter that you may use to publish to the PaaS.
OpenShift of course requires you to have an account. If you have none yet, the wizard will drop you to the signup form by hitting the link that is displayed on the first wizard page.
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18807/s... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
Once you have your account, you'll be ready to go, ready to get amazed by JBoss Tools and OpenShift.
h1. A very basic workflow
OpenShift is a http://en.wikipedia.org/wiki/Platform_as_a_service PaaS, a Platform as a Service. As such it offers you your personal application stack and it does this on demand. A range of standards runtimes are offered to you whenever you need them. Working with the PaaS is as simple as importing a stub (the starter application) to your workspace, changing and publishing it again:
h2. Create your application runtime
It all starts by creating your own application runtime. You set a name and choose the application (runtime) you need:
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18809/a... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
OpenShift offers a wide range of standard runtimes. You may to choose among php, ruby, phython, nodejs etc. Java developers will be most amazed to see that OpenShift offers a fully Java EE 6 compliant application server: the blazing fast http://www.jboss.org/as7 JBoss AS 7.1.
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18810/a... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
You may also add different extensions to your platform ranging from SQL- (like MySQL or Postgres) or NoSQL-databases (like MongoDB) up to your very own CI server (jenkins).
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18811/a... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
Once you made up your choices and finish the wizard, it'll create your OpenShift application, wait for it to become reachable and import it's initial content - a starter application - to your Eclipse workspace. Looking into your Project Explorer or Navigator, you'll spot the new project that the wizard imported. It has the very same name as the OpenShift application. In case of a JBoss AS7 runtime, the starter app is a maven artifact and the project we import to your workspace will have the name that's configured for the maven artifact.
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18852/i... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
h2. Push to build and deploy
The new project in your Eclipse workspace is where you apply your changes. It is shared with a git repository on your local machine. This repository is a clone of the git repository within your OpenShift application.
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18853/a... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
Deploying this project to the PaaS is as simple as pushing the local repository to it's origin, the OpenShift git repository. OpenShift will then build and deploy your application to the application runtime.
In case of a Java application, OpenShift relies on a maven based build, that is triggered with each git push:
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18817/a... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
h2. Server Adapter to the rescue
When dealing with git, you have to deal with a brilliant but rather complex code versioning system. Even if you're familiar with git, there's still room to reduce the number of manipulations when publishing.
http://www.eclipse.org/webtools/ Eclipse WTP server adapters historically allow you to interact with your server. This would typically be some local or remote server you'd have file- or SSH-based access to. We adapted this handy concept and implemented a variant that would work with OpenShift. This server adapter hides the complexity of dealing with git and allows 1-click publishing to the cloud.
The OpenShift Application wizard sets the adapter up when you create your application and import the starter project to your workspace. Our Server adapter is bound to the OpenShift project in your workspace and it'll do the git operations for you.
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18818/s... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
When publishing it will deploy the changes in your OpenShift project to the PaaS. It'll hide all the complexity that is inherent to git. It will commit your changes to your local clone and push them to the git repository of your OpenShift application (the origin).
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18819/s... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
h1. Deploy my very own project!
Importing the starter application to your workspace is the most simple usecase we provide. I bet most users already have a project that they'd want to deploy though. We of course also provide this ability in our OpenShift Application wizard.
Our little screencast shows you the steps when starting with your very own project. It uses the kitchensink example to demonstrate how this would occourr. You may get it on github:
> *Kitchensink example project:*
>
> https://github.com/adietish/kitchensink.git https://github.com/adietish/kitchensink.git
h2. Have your project ready
You first have to get your project to Eclipse. We only support *git-shared or non-shared project* though. A typical usecase would be to have your project on https://github.com/ github or in any other git repository.You then simply clone it's repository to your local machine (using http://www.eclipse.org/egit/ EGit or the command line) and import the project within it to your Eclipse workspace.
h2. JBoss Tools, configure my project
You then create your OpenShift application in our wizard, provide the name, type and eventually additional cartridges. You then switch to the second wizard page and tell the wizard that you dont want to create a new project in your workspace. You tell it to use your project instead.
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18854/u... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
The wizard will warn you about upcoming changes to your project and ask you to confirm:
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18886/m... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
h2. Oh my project, how you changed!
We then add OpenShift specific configurations to your project. These changes unfortunately cannot be undone. You'd have to provide your own means (ex. a separate branch) if you dont want these additions in your developement code The changes we apply are the following:
> *All changes:*
> *
> *
> * eventually create a git repository and commit your project to it
> * add a *.op**enshift* folder with openshift specific hooks
> * add a *deployments* folder
> * add the Eclipse specific files (.project, .classpath etc.) to the *.gitignore*
> * add *openshift-profile* to the pom
> * add OpenShift *git repo as remote* to your local git repo
>
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18855/m... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
Since publishing to OpenShift is git pushing to it, we'll make sure your project is shared to a *git repo*. We therefore eventually create a git repository for your project if there's none yet and add your project to it.
We add the *.openshift* folder which may contain OpenShift specific configurations and tweaks (like custom build-scripts, markers, cron entries etc.). We also create a *deployments* folder which OpenShift will use to build to. You may also add additional artifacts to it.
We then tweak *.gitignore* and add the Eclipse specific files so that they dont make it to the git repo by default.
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18857/m... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
For maven-based java projects we tweak the *pom* and add an openshift profile to it.
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18858/o... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
The openshift profile is what the PaaS is using when building your project on the PaaS. The profile we add is telling maven to create the war in the deployments folder. The deployments folder is where JBoss AS7 is expecting and picking new deployables from. Adding the profile makes sure that your project is deployed when it is built.
We'll also then add the OpenShift application git repo as *remote* to the git repo of your local project. This will allow you to push your project to OpenShift without knowing about the exact url you'll have to push to. All you have to know is what name the OpenShift repo is stored at.
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18871/m... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
We're storing the OpenShift application git url as "openshift" in the remotes known to your local repo. You may of course tell the wizard to use any name you like:
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18872/m... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
h2. Push me up, Scotty
Once we configured your project, we commit the changes to your local git repo (either your project was already shared with a git repo or we created one for you). To now deploy your project to OpenShift, you'd have to go to the Servers view, choose the OpenShift server adapter (that we created for you) and tell it to *publish*. The server adapter will then detect that the local project is ahead of the remote one and that publishing would only be possible when overriding the remote starter application. It'll ask you to confirm this step:
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18887/m... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
Once the publishing is done, you'll have your project running on OpenShift!
h2. Multi-module maven projects
Our OpenShift Application wizard also supports multi-module maven projects. You'd simply have to make sure all modules are nested within a parent project and choose the parent project as existing project (multi vs. multi-web, multi-ejb, multi-ejb in my screenshot) in the wizard:
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18889/m... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18890/m... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
> *Note:*
>
> in case your multi-module maven project is an ear, there are still slight limitations in our tooling for the moment. You may easily work around them though. You'd have to alter the maven profile in the pom of your parent-projec and replace the maven-war-plugin by the maven-ear-plugin:
>
> https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18870/m... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
>
> You may read about it in all details and track our progress on it in https://issues.jboss.org/browse/JBIDE-12252 JBIDE-12252
h1. My maven project is not in the git repo root
When deploying an existing project to OpenShift, you'd have to tell the wizard in JBoss Tools about your project. Your project would have to comply to a basic layout though. We expect the pom in the root of your git repository. If this is not the case, then you'd have to take an alternative approach when publishing. Publishing then gets as easy as drag and dropping your project to the adapter.
In our screencast, we show you how to proceed. We use the the ticket-monster example project which is available at github:
> *Ticket-monster example project:*
>
> https://github.com/jboss-jdf/ticket-monster https://github.com/jboss-jdf/ticket-monster
h2. Have your project ready
The first thing to do is to import your application to your Eclipse workspace. The only requirement we have is that your project shall be http://www.eclipse.org/webtools/ Eclipse WTP compliant. It may be a Dynamic Web or a Maven project. Maven projects are turned into Eclipse WTP projects if you have https://www.eclipse.org/m2e-wtp/ m2e-wtp installed when importing them (m2e-wtp bridges the gap between Eclipse WTP and maven, it turns any maven project into a WTP compliant project).
In the ticket-monster example, the maven project is nested into the demo folder:
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18881/d... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
We import with the Eclipse Maven import wizard pointing it to the demo-folder:
h2. Create your OpenShift application
Once you have your project ready you'll go and create the OpenShift application that will host your application. Launch the OpenShit Application wizard in JBoss Tools, tell it to create a *jbossas-7* application and let it import the starter app, as shown in the first paragraphs of this blog.
h2. OpenShift, here I come
The OpenShift Application wizard imports the starter application to your workspace and creates a server adapter for it:
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18891/d... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18878/d... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
You are then ready to publish your project. Simply drag and drop it to the OpenShift *server adapter* in the Servers view. Your project will then get published to OpenShift.
Once the publishing is done, you'll notice that the server adapter now has 2 modules: the starter application and your project:
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18882/d... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
The server adapter actually compressed your project to a war and dropped it to the deployments folder within the starter application:
https://community.jboss.org/servlet/JiveServlet/showImage/38-4972-18883/d... https://community.jboss.org/servlet/JiveServlet/downloadImage/38-4972-188...
It then committed this addition and pushed the starter application to OpenShift. The JBoss AS7 then noticed the new war and deployed it. Simple as that.
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/community/tools/blog/2012/06/27/deploy-from-e...]
12 years, 5 months
- 1
- 0
[Performance Tuning] - max heap size on 64 bit red hat linux 5
by Zippy Zeppoli
Zippy Zeppoli [https://community.jboss.org/people/zippyzeppoli] created the discussion
"max heap size on 64 bit red hat linux 5"
To view the discussion, visit: https://community.jboss.org/message/744378#744378
--------------------------------------------------------------
Hi everyone,
I searched the Red Hat and Oracle JVM docs (sun jvm docs gone) and I wasn't able to find the answer to my question.
I am wondering what the real max heap size is on RHEL 5 64 bit for JBoss AS 5?
My understanding is that on a 64 bit process the memory references use a good deal of the heap space.
For example, if I have a 10G max heap, it's not really going to use all of that space right?
About what would it be? And whats the max limit on a 64 bit system?
Thanks in advance.
Z
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/744378#744378]
Start a new discussion in Performance Tuning at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
12 years, 5 months
- 2
- 3
[jBPM] - How to use the Error Event node in process (jBPM5.2)?
by Michael G
Michael G [https://community.jboss.org/people/mpgong] created the discussion
"How to use the Error Event node in process (jBPM5.2)?"
To view the discussion, visit: https://community.jboss.org/message/744303#744303
--------------------------------------------------------------
Hello,
I've searched around for this but didn't find an answer, is it possible to use the Error Event node to trigger a handler?
>From the documentation is says this:
An Error Event can be used to signal an exceptional condition in the process. It should have one incoming connection and no outgoing connections. When an Error Event is reached in the process, it will throw an error with the given name. The process will search for an appropriate error handler that is capable of handling this kind of fault. If no error handler is found, the process instance will be aborted. An Error Event contains the following properties:
* +Id+: The id of the node (which is unique within one node container).
* +Name+: The display name of the node.
* +FaultName+: The name of the fault. This name is used to search for appropriate exception handlers that are capable of handling this kind of fault.
* +FaultVariable+: The name of the variable that contains the data associated with this fault. This data is also passed on to the exception handler (if one is found).
Error handlers can be specified using boundary events. This is however currently only possible when working with XML directly. We will be adding support for graphically specifying this in the new BPMN2 editor.
So i would like to know how the handler is implemented and inserted into the process. On the process properties page there is a Property for Exception Handlers but when i define one here it isn't getting called.
Does anyone know what i'm doing wrong?
Thanks
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/744303#744303]
Start a new discussion in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
12 years, 5 months
- 2
- 2
Re: [jboss-user] [JBoss Tools] - JBoss Tools 3.3 and Developer Studio 5.0 Final Release!
by Linda Moon
Linda Moon [https://community.jboss.org/people/lindamoon] commented on
"JBoss Tools 3.3 and Developer Studio 5.0 Final Release!"
To view all comments on this blog post, visit: https://community.jboss.org/community/tools/blog/2012/06/21/jboss-tools-3...
--------------------------------------------------
Great! Congratulations :)
--------------------------------------------------
12 years, 5 months
- 1
- 0