IChangeEventHandler and processing of changeevents
There seems to be something missing or something I'm misunderstanding
with the IChangeEventHandler support in Jazz.
From a component development standpoint, I should be able to simply
define a ChangeEventHandler extension point and associated
IChangeEventHandler implementation class. The proper assumtion from
here would be that there is an background job that automatically finds
new/unprocessed IChangeEvent's in the repo and lets each
IChangeEventHandler react.
However, this is not the case.
The ProcessService is the only background job that processes for new
change events, however its implementation is specific to process
IChangeEvents with a process area set. So I see a couple of issues here.
(1) If by default, this ProcessService.processChangeEvent should invoke
my IChangeEventHandler then the process area should be a required field
on IChangeEvent. Also there is no clear way of locating the
a process area for a particular artifact and this forces users to add
additional code.
(2) If the ProcessService.processChangeEvent is a specfic job for the
process component and its implementation is correct focusing on specfic
change events, then simply defining the extension point does nothing
during runtime as nothing will invoke the IChangeEventHandler
(3) If 2, then currently each developer wanting to take advantage of the
IChangeEventHandler extension point will have to define a service/async
task to do their own processing of IChangeEvents and looking at the
IProcessService.processChangEvent
as a code example, this is alot of code (locating of new change events,
managing of the IChangeEventHandler ext points, etc...)
So the conclusion is that there is currently alot of overhead of using
the IChangeEventHandler extension point. So what is the current
recommendation? All I want to do is (1) create a change event, (2)
implement something that will automatically get
called by jazz so I can process that change event.
Is there something I'm missing, or is this something that Jazz is missing?
with the IChangeEventHandler support in Jazz.
From a component development standpoint, I should be able to simply
define a ChangeEventHandler extension point and associated
IChangeEventHandler implementation class. The proper assumtion from
here would be that there is an background job that automatically finds
new/unprocessed IChangeEvent's in the repo and lets each
IChangeEventHandler react.
However, this is not the case.
The ProcessService is the only background job that processes for new
change events, however its implementation is specific to process
IChangeEvents with a process area set. So I see a couple of issues here.
(1) If by default, this ProcessService.processChangeEvent should invoke
my IChangeEventHandler then the process area should be a required field
on IChangeEvent. Also there is no clear way of locating the
a process area for a particular artifact and this forces users to add
additional code.
(2) If the ProcessService.processChangeEvent is a specfic job for the
process component and its implementation is correct focusing on specfic
change events, then simply defining the extension point does nothing
during runtime as nothing will invoke the IChangeEventHandler
(3) If 2, then currently each developer wanting to take advantage of the
IChangeEventHandler extension point will have to define a service/async
task to do their own processing of IChangeEvents and looking at the
IProcessService.processChangEvent
as a code example, this is alot of code (locating of new change events,
managing of the IChangeEventHandler ext points, etc...)
So the conclusion is that there is currently alot of overhead of using
the IChangeEventHandler extension point. So what is the current
recommendation? All I want to do is (1) create a change event, (2)
implement something that will automatically get
called by jazz so I can process that change event.
Is there something I'm missing, or is this something that Jazz is missing?
One answer
Jazz process specifications can contain snippets that talk about what should
(asynchronously) happen in reaction to particular types of change events.
The what is confined to change event handlers.
In order to allow the process specification to talk about the change events
components declare the events they issue by defining extensions to the
com.ibm.team.process.service.configurationPoints extension point. Components
ensure that these events are associated with the team areas that correctly
reflects the team area associations of the items these change events are
talking about.
In order to make change event handlers available for usage in a process
specification components declare their change event handlers by defining
extensions to the com.ibm.team.process.service.eventHandlers extension
point. Change event handlers that are being registered with the process
component have to implement the IChangeEventHandler interface.
The process component periodically checks whether new events of registered
types have been issued, retrieves the information from the active process
whether and which change event handlers to invoke and if there are any
invokes them.
Please note that this all implies that this mechanism is inappropriate when
a component has to react to change events in order to be functional. The
process specification can either list or omit event handlers; this is not
under the control of the component. In this case the component has to use to
mechanisms provided by the repository component, i.e. to declare it's own
async task processing change events. In jazz we have several instances of
this such as the work item component and also the process component which
uses the repository provided mechanisms to implement the model described
above.
Cheers, Kai
"Sachin Patel" <sppatel@us.ibm.com> wrote in message
news:fahg08$olm$1@localhost.localdomain...
(asynchronously) happen in reaction to particular types of change events.
The what is confined to change event handlers.
In order to allow the process specification to talk about the change events
components declare the events they issue by defining extensions to the
com.ibm.team.process.service.configurationPoints extension point. Components
ensure that these events are associated with the team areas that correctly
reflects the team area associations of the items these change events are
talking about.
In order to make change event handlers available for usage in a process
specification components declare their change event handlers by defining
extensions to the com.ibm.team.process.service.eventHandlers extension
point. Change event handlers that are being registered with the process
component have to implement the IChangeEventHandler interface.
The process component periodically checks whether new events of registered
types have been issued, retrieves the information from the active process
whether and which change event handlers to invoke and if there are any
invokes them.
Please note that this all implies that this mechanism is inappropriate when
a component has to react to change events in order to be functional. The
process specification can either list or omit event handlers; this is not
under the control of the component. In this case the component has to use to
mechanisms provided by the repository component, i.e. to declare it's own
async task processing change events. In jazz we have several instances of
this such as the work item component and also the process component which
uses the repository provided mechanisms to implement the model described
above.
Cheers, Kai
"Sachin Patel" <sppatel@us.ibm.com> wrote in message
news:fahg08$olm$1@localhost.localdomain...
There seems to be something missing or something I'm misunderstanding with
the IChangeEventHandler support in Jazz.
From a component development standpoint, I should be able to simply define
a ChangeEventHandler extension point and associated IChangeEventHandler
implementation class. The proper assumtion from here would be that there
is an background job that automatically finds new/unprocessed
IChangeEvent's in the repo and lets each IChangeEventHandler react.
However, this is not the case.
The ProcessService is the only background job that processes for new
change events, however its implementation is specific to process
IChangeEvents with a process area set. So I see a couple of issues here.
(1) If by default, this ProcessService.processChangeEvent should invoke my
IChangeEventHandler then the process area should be a required field on
IChangeEvent. Also there is no clear way of locating the
a process area for a particular artifact and this forces users to add
additional code.
(2) If the ProcessService.processChangeEvent is a specfic job for the
process component and its implementation is correct focusing on specfic
change events, then simply defining the extension point does nothing
during runtime as nothing will invoke the IChangeEventHandler
(3) If 2, then currently each developer wanting to take advantage of the
IChangeEventHandler extension point will have to define a service/async
task to do their own processing of IChangeEvents and looking at the
IProcessService.processChangEvent
as a code example, this is alot of code (locating of new change events,
managing of the IChangeEventHandler ext points, etc...)
So the conclusion is that there is currently alot of overhead of using the
IChangeEventHandler extension point. So what is the current
recommendation? All I want to do is (1) create a change event, (2)
implement something that will automatically get
called by jazz so I can process that change event.
Is there something I'm missing, or is this something that Jazz is missing?