form builder - requirements request (+work in progress)
by Mauricio Salatino
Hi guys,
This is a quick update trying to describe the current status of the form
builder project. I've being working the project for a week now and I've
created a branch to do some big changes. I will quickly try to explain what
these changes are and why I think that are important for the project. The
following list shows the project modules that I'm trying to create inside
the form-builder-split branch in:
https://github.com/droolsjbpm/jbpm-form-builder
-Form Builder API (already existing): as the name of the project mention,
it will contain all the APIs to interact with the form builder functionality
-Form Builder Model (new): this new module contains the models that are
being used to represent forms and it was decoupled from the WAR and API
modules in order to allow us depend on the model without being tied to all
the form builder project as a dependency for the one that only wants to
consume and render the forms that were created.
-Form Builder Services (work in progress): I'm still working on this
module, but once again, the services the get the forms and the tasks
associated with a form needs to be decoupled from the Form Builder WAR
module which is the authoring tool. The ones that wants to just render a
form doesn't need to depend on the whole tool.
-Form Builder (WAR) (already existing): This war needs to be clean up in
order to only contain the classes that are used for authoring forms
-Form Builder Consumer/Client (archetype probably/ new): we need to have
clear rules and dependencies to be able to consume a form, no matter the
technology that we want to use for rendering. In theory the consumer will
use the Model and the Services + one exporter to render a form.
-Form Builder Exporters (FTL/GWT): (already existing) the exporter projects
have the mappings between the form meta model and each rendering
technology. I will be focused on GWT and I will try to dig a little bit in
HTML5 to see what can be done. At this point I don't know to much about
these projects and their limitations.
As you can see in the attached image, the services module interacts with an
storage to do different things. One of the things that I will be adding
soon is a service to manage the form builder settings. Until now, all the
services were stateless, they do not store status in no way. What I would
like to add is a way for the user to store their customizations and
configurations in a persistent storage. At this point there are a two
different things that can be stored:
1) Forms Structures / Form Item Structures / Human Task
Structures-Information
The form builder have a very cool feature to analyze Human Tasks structures
that can be retrieved from a bpmn2 file and based on that generate forms.
Those generated forms needs to be stored somewhere. Because they are
knowledge assets, guvnor looks like the right place to go. I've implemented
also a FileSystem support, to be able to use the FormBuilder without guvnor
which makes our life easier to test the component without having the whole
environment running. All this information is static and stateless in some
way. We store and load these assets from Guvnor or the FileSystem using the
existing services. (Adding support for a DB storage option probably make
sense as well)
2) Settings / Customizations per user or role
I'm planning to add a new service to manage and store settings for the form
builder. These settings can be stored in a database, and I'm not sure that
they can be considered as business assets. These settings are related to
the user that is working with an instance of the form builder and want to
customize its menus and for example choose if he/she wants to store if
he/she was using the FileSystem storage option and a set of custom Form
Items.
As soon as I have the initial version of this service to handle settings I
will be focused in creating a Generic Form Builder Consumer to demonstrate
how you can use and integrate the generated Form with your own application.
Hopefully I can get this working next week.
If you have feedback about this points or if you have some features that
you would like to see working in the form builder in the next month please
write back. I'm eager to see how people wants to use this component.
Remember that I'm working to get this component working in a "standalone"
mode, so if you have another ideas about how to use it outside of the
business process context please let us know :)
Cheers
--
- MyJourney @ http://salaboy.wordpress.com
- Co-Founder @ http://www.jugargentina.org
- Co-Founder @ http://www.jbug.com.ar
- Salatino "Salaboy" Mauricio -
11 years, 10 months
jBPM maven archetypes
by Maciej Swiderski
Hi guys,
thought I will share this with you as some can have similar needs - I
created a new repository on github for maven archetypes related to jbpm
(https://github.com/mswiderski/jbpm-archetypes). It is on my github but
if we think that could be useful in the future we could promote it to
the main location. Currently there is only one archetype available for
building domain specific services that will do quite a bit for developer:
- prepare project with initial structure (wid file template, help web
page template, work item handler class template)
- comes with assembly definition that will package the project into
structure that service repository expects
- wid file will be populated with all runtime dependencies derived from pom
So developer needs to define service dependencies, implement the handler
and define the work item (parameters, icon, description and eclipse
editor if special one is needed).
I think we can add more archetypes for jBPM such as web application
archetype to bootstrap developers to start developing systems based on jBPM.
For those that would like to give it a test drive, simple clone the
repo, run mvn clean install and then you are ready to build your domain
specific services by generating the project from the archetype: mvn
archetype:generate . By default it will be in interactive mode so you'll
be asked some questions, Archetype that you need is
org.jbpm:domain-service-archetype.
Comments? Thoughts?
Cheers
Maciej
11 years, 11 months
Fwd: [rules-dev] 2nd CFP - 6th Int. Workshop on Event-Driven Business Process Management (edBPM12)
by Mauricio Salatino
We really need to submit something here, right?
Cheers
---------- Forwarded message ----------
From: Adrian Paschke <Adrian.Paschke(a)gmx.de>
Date: Mon, May 21, 2012 at 5:25 AM
Subject: [rules-dev] 2nd CFP - 6th Int. Workshop on Event-Driven Business
Process Management (edBPM12)
To: rules-dev(a)lists.jboss.org
[ our apologies should you receive this message more than one time ]
6th Int. Workshop on Event-Driven Business Process Management (edBPM12)
collocated with BPM 2012
Tallinn, Estonia, 3-7 September 2012
http://icep-edbpm12.fzi.de/
++++ SUBMISSION DEADLINE - JUNE 1st +++++
Workshop Themes
--------------------------
Authors are invited to submit novel contributions in the prior described
problem domain.
* Event-driven BPM: Concepts
o Role of event processing in BPM
o Business Events: types and representation
o Event stream processing in business processes
o Data- and event-driven business processes
o Evaluation/ROI of event-driven BPM
o Event-driven SOA
o EDA and BPM
o Real/time awareness in BPM
o Context in BPM
* Design-time CEP and BPM
o Modelling languages, notations and methods for event-driven BPM
o Event Patterns: Definition / Creation / Representation /
Learning
o BPMN and event processing
o Modelling unknown/similar events in business processes
o Modelling events in human-oriented tasks
o Semantics/Ontologies for event-driven BPM
o Publish/subscription mechanism and process modelling
* Run-time CEP and BPM
o Event pattern detection
o BPEL and event processing
o Reasoning about unknown/similar events
o Distributed event processing
o Dynamic workflows
o Ad-hoc workflows
* Applications/Use cases for event-driven BPM
o Event-driven monitoring/BAM
o Event-driven SLA monitoring
o Domains: Logistics, Automotive, .
o Event processing and Internet of Services
Important Dates
--------------------------
Deadline paper submissions: 1 June 2012
Notification of acceptance: 2 July 2012
Camera-ready papers: 30 July 2012
Workshops: 3 September 2012
Submission
--------------------------
The following types of submission are solicited:
- Long paper submissions, describing substantial contributions of novel
ongoing work. Long papers should be at most 12 pages long.
- Short paper submissions, describing work in progress. These papers should
be at most 6 pages long.
- Use case submission, describing results from an edBPM use case. These
papers should be at most 4 pages long.
Papers should be submitted in the new LNBIP format
(http://www.springer.com/computer/lncs?SGWID=0-164-6-791344-0). Papers have
to present original research contributions not concurrently submitted
elsewhere. The title page must contain a short abstract, a classification of
the topics covered, preferably using the list of topics above, and an
indication of the submission category (Long Paper/ Short Paper). Accepted
paper will be published in the joint workshops proceeding (Springer).
For submission, please visit
http://www.easychair.org/conferences/?conf=edbpm12.
Organizing Committee
--------------------------
Nenad Stojanovic
FZI - Research Center for Information Technologies at the University of
Karlsruhe, Germany.
nstojano (at) fzi dot de
Opher Etzion
IBM Research Lab in Haifa
OPHER (at) il dot ibm dot com
Adrian Paschke
Corporate Semantic Web, Free University Berlin, Germany and RuleML Inc.,
Canada
paschke (at) inf dot fu-berlin dot de
Christian Janiesch
Karlsruhe Institute of Technology (KIT)
Christian.Janiesch (at) kit dot edu
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
- MyJourney @ http://salaboy.wordpress.com
- Co-Founder @ http://www.jugargentina.org
- Co-Founder @ http://www.jbug.com.ar
- Salatino "Salaboy" Mauricio -
11 years, 11 months
form builder updates and requirements gathering
by Mauricio Salatino
Hi guys,
I was working with the form builder these last couple of days and I manage
to provide support for file system storage. Making the form builder
independent from Guvnor. You now can change the repository via a spring
configuration file and deploy the form builder component without the need
of any other component being deployed.
Now when I was trying to create a simple web application that will host the
form that was created inside the form builder, I've started finding that
some more work needs to be done in order to provide external applications
the right set of dependencies which includes the model, the services and
the renderers required to display the form.
For this reason, I've started breaking up the projects jbpm-form-builder
and jbpm-form-builder-api into a more granular structure. As soon as I get
this refactoring ready I will write a blog post that shows how people can
set up the form builder to start creating your forms and how they can
publish and consume these forms from a different application.
Besides, from the update I would like to take advantage of this opportunity
to ask for feedback on this component and also for new requirements. What
do you think that will be the most important requirements that we need to
fulfill to satisfy a business user? Should we target technical users first?
What do you expect from a component that is called Form Builder? All the
inputs are valuable and will help me to scope my deliverables and deadlines
accordingly.
Cheers!
--
- MyJourney @ http://salaboy.wordpress.com
- Co-Founder @ http://www.jugargentina.org
- Co-Founder @ http://www.jbug.com.ar
- Salatino "Salaboy" Mauricio -
11 years, 11 months
Re: [jbpm-dev] jbpm human task core tests refactorings - next steps
by Mauricio Salatino
Hi guys, I've already merged the proposed changes my next steps will be:
1) migrate to Junit 4 all the tests using the @Test annotation and remove
the TestCase extensions
2) refactor all the tests with hardcoded users and just leave the tests
which uses the UserGroupCallBacks (refactoring their names to not include
UserGroupCallBacks )
3) write docs about the new Handlers and probably an example to see what
tests needs to be implemented if a new functionality wants to be tested.
4) Write the documentation about the Exceptions and review if we can
introduce more specific ones.
I will be spending some time these week in the form builder so probably I
will create a separate thread about that.
On Sun, May 13, 2012 at 11:26 AM, Mauricio Salatino <salaboy(a)gmail.com>wrote:
> Ok, because I didn't get more feedback I'm pushing the changes today to
> master.
> I will be looking jenkins to see if something else gets affected, please
> get in touch with me if you notice something wrong before I do.
> Cheers
>
>
> On Fri, May 11, 2012 at 7:16 PM, Mauricio Salatino <salaboy(a)gmail.com>wrote:
>
>> @Marco: Hehe totally agree with the approach. I just don't want to make
>> those reports looks better, I want to be sure that the code that we have is
>> good.
>>
>> I've already migrated the changes to the transport projects, which it was
>> easier than I thought, meaning that the changes doesn't affect too much. I
>> will delete all the commented classes as well.
>>
>> I'm ready to push now, but I will wait for a while to see if I get more
>> feedback. I'm confident with fixing issues with the callbacks if they
>> appear. If you guys knows where the callbacks are being used in the
>> jbpm-console please let me know.
>> Cheers
>>
>>
>>
>> On Fri, May 11, 2012 at 12:48 PM, Marco Rietveld <mrietvel(a)redhat.com>wrote:
>>
>>> Oh yeah: coverage reports.
>>>
>>> IMHO, coverage reports are like weather reports: good to check now and
>>> then, but not something you want to plan around.
>>> Also, wrt agile/efficiency, we're better off making sure that the tests
>>> do actually test what we want them to -- which is pretty much exactly what
>>> you've been doing, Mauricio.
>>>
>>> 11-05-12 11:36, Maciej Swiderski:
>>>
>>> +1 for cleaning up the test, it takes quite some time to run all of them.
>>>
>>> Regarding changes of package good to keep in mind:
>>> - installer stuff that it declares DefaultUserGroupCallback in both
>>> web.xml and jbpm.usergroup.callback.properties.
>>> - human task war tests could declare...
>>>
>>> There should be LDAPUserInfo class that could go into identity package
>>> as well.
>>>
>>> Coverage report look quite ok :) and improvement is always welcome.
>>>
>>> Cheers
>>> Maciej
>>>
>>> 2012/5/11 Mauricio Salatino <salaboy(a)gmail.com>
>>>
>>>> Sure, I will do that if all the other points make sense, and I will not
>>>> push the commented out tests :)
>>>>
>>>>
>>>> On Fri, May 11, 2012 at 12:04 PM, Marco Rietveld <mrietvel(a)redhat.com>wrote:
>>>>
>>>>> Hi Mauricio,
>>>>>
>>>>> Feel free to delete the code instead of commenting it out, especially
>>>>> if you can't use @Ignore.
>>>>>
>>>>> Commented out code is more often confusing than not. :)
>>>>>
>>>>> Thanks,
>>>>> Marco
>>>>>
>>>>> 11-05-12 10:46, Mauricio Salatino:
>>>>>
>>>>> Hi guys,
>>>>> I was working yesterday trying to understand why we have 390 test
>>>>> running inside jbpm-human-task-core and if they are really necessary.
>>>>> This is my initial approach so forgive me if I'm missing something,
>>>>> the following notes and changes are what I found until now:
>>>>>
>>>>> 1) All the test classes using directly TaskClient should be
>>>>> removed, now everything should go through TaskService and AsyncTaskService
>>>>> test which are placed inside async and sync. For that reason all the
>>>>> test inside org.jbpm.task.service are commented out.
>>>>> I've checked that all the test classes that were using TaskClient now
>>>>> has their correspondency inside the org.jbpm.task.service.base.async
>>>>> package.
>>>>> Where the only important change is from TaskClient
>>>>> to AsyncTaskService. We were running the same tests for both wasting a lot
>>>>> of time.
>>>>> Now the base.sync package tests everything using the TaskService
>>>>> interface. Right now there are not the same tests for the sync and the
>>>>> async interface but I can migrate them soon.
>>>>>
>>>>>
>>>>> 2) Reviewing the org.jbpm.task.service package I found all the
>>>>> UserGroupCallback tests and the class called BaseTestNoUserGroupSetup,
>>>>> which basically run almost
>>>>> all the test using no hardcoded users and using the UserCallbacks
>>>>> resolutions. Talking yesterday with Tiho, we both agree that we should
>>>>> remove the tests
>>>>> that are using hardcoded users and just leave the one that are using
>>>>> callbacks to avoid running unnecessary tests. Just doing this we will
>>>>> remove a lot of overhead
>>>>> and we can have a simplified way of organizing and running the tests.
>>>>> I've moved all the UserGroupCallback tests to the async package and migrate
>>>>> them to use the AsyncTaskService instead of the TaskClient.
>>>>>
>>>>> 3) I've created a package called org.jbpm.task.identity to place the
>>>>> LDAP stuff which is ignored and the UserGroupCallBack stuff that is not
>>>>> using the TaskService/TaskClient stuff, when I was doing that I notice that
>>>>> those tests uses some properties files that needs to be placed inside the
>>>>> same package structure to be picked up, for that reason I've moved two
>>>>> classes inside src/main/java to the following new
>>>>> package: org.jbpm.task.identity -> UserGroupCallbackManager,
>>>>> UserGroupCallback, DefaultUserGroupCallbackImpl, LDAPUserGroupCallbackImpl,
>>>>> which I believe that is better than have the UserGroupCallback stuff mixed
>>>>> with the task.service stuff. I notice that the
>>>>> package: org.jbpm.task.service is a wild area, that we should avoid as much
>>>>> as possible. I know that this is a change that can impact in other modules
>>>>> like the jbpm-console but I think that it will avoid future troubles. I
>>>>> really need your feedback on this.. to see if you guys think that this can
>>>>> cause a lot of troubles.
>>>>>
>>>>> 4) for the same reason as 1 I've commented out all the tests
>>>>> inside org.jbpm.task.service.test, those were using the TaskClient and
>>>>> because the async and sync test are already provided we don't miss
>>>>> anything. The only thing that we need to do inside
>>>>> the org.jbpm.task.service.test package is to align these tests to cover all
>>>>> the base async and sync tests, which is not the case right now, but it's
>>>>> simple to do it.
>>>>>
>>>>> 5) I've added covertura to the jbpm-human-task-core project to do an
>>>>> initial analysis about what we are covering with our tests. Attached is the
>>>>> initial chart that I would love to see improved in the following months :)
>>>>>
>>>>>
>>>>> 6) I need to work on the other modules to propagate these changes as
>>>>> well, but for doing that I need your feedback on the previous points, I
>>>>> think that during the weekend I will be able to finish the other modules,
>>>>> if we all are OK with this suggestions.
>>>>>
>>>>> Cheers
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> - MyJourney @ http://salaboy.wordpress.com
>>>>> - Co-Founder @ http://www.jugargentina.org
>>>>> - Co-Founder @ http://www.jbug.com.ar
>>>>>
>>>>> - Salatino "Salaboy" Mauricio -
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> jBPM/Drools developer
>>>>> Utrecht, the Netherlands
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> - MyJourney @ http://salaboy.wordpress.com
>>>> - Co-Founder @ http://www.jugargentina.org
>>>> - Co-Founder @ http://www.jbug.com.ar
>>>>
>>>> - Salatino "Salaboy" Mauricio -
>>>>
>>>>
>>>> _______________________________________________
>>>> jbpm-dev mailing list
>>>> jbpm-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jbpm-dev
>>>>
>>>>
>>>
>>>
>>> --
>>> jBPM/Drools developer
>>> Utrecht, the Netherlands
>>>
>>>
>>
>>
>> --
>> - MyJourney @ http://salaboy.wordpress.com
>> - Co-Founder @ http://www.jugargentina.org
>> - Co-Founder @ http://www.jbug.com.ar
>>
>> - Salatino "Salaboy" Mauricio -
>>
>>
>
>
> --
> - MyJourney @ http://salaboy.wordpress.com
> - Co-Founder @ http://www.jugargentina.org
> - Co-Founder @ http://www.jbug.com.ar
>
> - Salatino "Salaboy" Mauricio -
>
>
--
- MyJourney @ http://salaboy.wordpress.com
- Co-Founder @ http://www.jugargentina.org
- Co-Founder @ http://www.jbug.com.ar
- Salatino "Salaboy" Mauricio -
11 years, 11 months
jbpm human task core tests refactorings <- feedback plz!
by Mauricio Salatino
Hi guys,
I was working yesterday trying to understand why we have 390 test running
inside jbpm-human-task-core and if they are really necessary.
This is my initial approach so forgive me if I'm missing something, the
following notes and changes are what I found until now:
1) All the test classes using directly TaskClient should be removed, now
everything should go through TaskService and AsyncTaskService
test which are placed inside async and sync. For that reason all the test
inside org.jbpm.task.service are commented out.
I've checked that all the test classes that were using TaskClient now has
their correspondency inside the org.jbpm.task.service.base.async package.
Where the only important change is from TaskClient to AsyncTaskService. We
were running the same tests for both wasting a lot of time.
Now the base.sync package tests everything using the TaskService interface.
Right now there are not the same tests for the sync and the
async interface but I can migrate them soon.
2) Reviewing the org.jbpm.task.service package I found all the
UserGroupCallback tests and the class called BaseTestNoUserGroupSetup,
which basically run almost
all the test using no hardcoded users and using the UserCallbacks
resolutions. Talking yesterday with Tiho, we both agree that we should
remove the tests
that are using hardcoded users and just leave the one that are using
callbacks to avoid running unnecessary tests. Just doing this we will
remove a lot of overhead
and we can have a simplified way of organizing and running the tests. I've
moved all the UserGroupCallback tests to the async package and migrate them
to use the AsyncTaskService instead of the TaskClient.
3) I've created a package called org.jbpm.task.identity to place the LDAP
stuff which is ignored and the UserGroupCallBack stuff that is not using
the TaskService/TaskClient stuff, when I was doing that I notice that those
tests uses some properties files that needs to be placed inside the same
package structure to be picked up, for that reason I've moved two classes
inside src/main/java to the following new package: org.jbpm.task.identity
-> UserGroupCallbackManager, UserGroupCallback,
DefaultUserGroupCallbackImpl, LDAPUserGroupCallbackImpl, which I believe
that is better than have the UserGroupCallback stuff mixed with the
task.service stuff. I notice that the package: org.jbpm.task.service is a
wild area, that we should avoid as much as possible. I know that this is a
change that can impact in other modules like the jbpm-console but I think
that it will avoid future troubles. I really need your feedback on this..
to see if you guys think that this can cause a lot of troubles.
4) for the same reason as 1 I've commented out all the tests
inside org.jbpm.task.service.test, those were using the TaskClient and
because the async and sync test are already provided we don't miss
anything. The only thing that we need to do inside
the org.jbpm.task.service.test package is to align these tests to cover all
the base async and sync tests, which is not the case right now, but it's
simple to do it.
5) I've added covertura to the jbpm-human-task-core project to do an
initial analysis about what we are covering with our tests. Attached is the
initial chart that I would love to see improved in the following months :)
6) I need to work on the other modules to propagate these changes as well,
but for doing that I need your feedback on the previous points, I think
that during the weekend I will be able to finish the other modules, if we
all are OK with this suggestions.
Cheers
--
- MyJourney @ http://salaboy.wordpress.com
- Co-Founder @ http://www.jugargentina.org
- Co-Founder @ http://www.jbug.com.ar
- Salatino "Salaboy" Mauricio -
11 years, 11 months
jbpm/bpmn2 resources, blogs, etc
by Mauricio Salatino
Hi guys,
I was looking forward to create a blog post with all the jBPM5 resources
and blog posts that I can find out there,
Do you mind sending me the links to your blogs?
Sorry for not having them, but is for that reason that I want to put them
all together so I have a single place to update them in the future.
I will probably put the list also in the wiki, but for some reason it looks
like wordpress get indexed better than the wiki and the forums.
Cheers
--
- MyJourney @ http://salaboy.wordpress.com
- Co-Founder @ http://www.jugargentina.org
- Co-Founder @ http://www.jbug.com.ar
- Salatino "Salaboy" Mauricio -
11 years, 11 months
Re: [jbpm-dev] human task exceptions
by Mauricio Salatino
We don't need, but that was my initial question.
We wrap the Runtime Exception of the server and we propagate TaskException,
which should not longer extends Runtime Exception and we add the Exception
to the interface, or we keep using RuntimeExceptions
and strongly documents that the user will need to call all these methods in
a try/catch block if they want to build real apps, which I believe that is
not as good as the IDE forcing them to catch TaskExceptions.
I will definitely check the Script solution and then we will need to decide
if documenting that is enough or we move the exception to the TaskService
and AsyncTaskService interface.
Cheers
On Fri, May 11, 2012 at 9:31 AM, Kris Verlaenen <kris.verlaenen(a)gmail.com>wrote:
> Having a specific exception definitely would be useful, as it would
> allow you to add context, like doing a getTask() or getCommand() or
> whatever we believe is valid (as the user might not know anymore what
> he asked). Note that we recently did something similar in master for
> exceptions when executing a script, where we then add info about what
> process instance etc.
>
> If TaskException extends RuntimeException, I suppose we don't really
> have to declare it in the interfaces?
>
> Kris
>
> On Fri, May 11, 2012 at 2:05 PM, Mauricio Salatino <salaboy(a)gmail.com>
> wrote:
> >
> >
> > On Thu, May 10, 2012 at 4:20 PM, Mauricio Salatino <salaboy(a)gmail.com>
> > wrote:
> >>
> >> Hi guys,
> >> I was reviewing the Human Task Module and more specifically the HornetQ
> >> implementation.
> >> I was writing some tests to check the behavior after a logical failure
> in
> >> the server side and I reach a point where some design questions appear:
> >>
> >> The following line tries to start a task which doesn't exist in the
> >> server:
> >>
> >> client.start(3, "");
> >>
> >> Where client is -> TaskService.
> >>
> >> This leads to a Runtime Exception in the client side with a clear
> >> message:
> >> "Command OperationRequest faild due to No Task with ID 3 was found!.
> >> Please contact task server administrator." <-- not sure about the
> >> administrator part
> >>
> >> I understand that we are throwing a Runtime Exception to be able to not
> >> declare the exception inside the TaskService interface, but...
> >> For real implementations the user will be forced to do the following:
> >>
> >> try{
> >> client.start(3, "");
> >> }catch(Exception e){
> >> assertEquals("Command OperationRequest faild due to No
> Task
> >> with ID 3 was found!. Please contact task server administrator.",
> >> e.getMessage());
> >> // or notify the UI about the error using that message.
> >> }
> >> No matter the method that the user calls in the client UIs the try/catch
> >> block will need to be included in order to not break the app.
> >> So my question is: we already have the TaskException class which extends
> >> RuntimeException, there are not too many implementations, but we surely
> can
> >> add
> >> the TaskPersistence exception, logical exceptions, etc.
> >> In my perspective adding the exception to both interfaces (TaskService
> and
> >> AsyncTaskService) will provide a more clear approach to the users that
> in
> >> the end will
> >> need to add the try catch no matter why.
> >>
> >> In my opinion, this is just the first step of providing our clients a
> way
> >> to notify the errors to their UIs.
> >>
> >> Looking forward for your comments and feedback!
> >>
> >> Cheers
> >>
> >> --
> >> - MyJourney @ http://salaboy.wordpress.com
> >> - Co-Founder @ http://www.jugargentina.org
> >> - Co-Founder @ http://www.jbug.com.ar
> >>
> >> - Salatino "Salaboy" Mauricio -
> >>
> >
> >
> >
> > --
> > - MyJourney @ http://salaboy.wordpress.com
> > - Co-Founder @ http://www.jugargentina.org
> > - Co-Founder @ http://www.jbug.com.ar
> >
> > - Salatino "Salaboy" Mauricio -
> >
>
--
- MyJourney @ http://salaboy.wordpress.com
- Co-Founder @ http://www.jugargentina.org
- Co-Founder @ http://www.jbug.com.ar
- Salatino "Salaboy" Mauricio -
11 years, 11 months
human task exceptions
by Mauricio Salatino
Hi guys,
I was reviewing the Human Task Module and more specifically the HornetQ
implementation.
I was writing some tests to check the behavior after a logical failure in
the server side and I reach a point where some design questions appear:
The following line tries to start a task which doesn't exist in the server:
client.start(3, "");
Where client is -> TaskService.
This leads to a Runtime Exception in the client side with a clear message:
"Command OperationRequest faild due to No Task with ID 3 was found!. Please
contact task server administrator." <-- not sure about the administrator
part
I understand that we are throwing a Runtime Exception to be able to not
declare the exception inside the TaskService interface, but...
For real implementations the user will be forced to do the following:
try{
client.start(3, "");
}catch(Exception e){
assertEquals("Command OperationRequest faild due to No Task
with ID 3 was found!. Please contact task server administrator.",
e.getMessage());
// or notify the UI about the error using that message.
}
No matter the method that the user calls in the client UIs the try/catch
block will need to be included in order to not break the app.
So my question is: we already have the TaskException class which extends
RuntimeException, there are not too many implementations, but we surely can
add
the TaskPersistence exception, logical exceptions, etc.
In my perspective adding the exception to both interfaces (TaskService and
AsyncTaskService) will provide a more clear approach to the users that in
the end will
need to add the try catch no matter why.
In my opinion, this is just the first step of providing our clients a way
to notify the errors to their UIs.
Looking forward for your comments and feedback!
Cheers
--
- MyJourney @ http://salaboy.wordpress.com
- Co-Founder @ http://www.jugargentina.org
- Co-Founder @ http://www.jbug.com.ar
- Salatino "Salaboy" Mauricio -
11 years, 11 months
