Yes. There seems to be event handling missing for some of the conditions.
I will for now go with firing the CDI event at the application layer. Would want to utilise the Cargo Domain object itself.
On 13-Aug-2013, at 12:25 PM, Reza Rahman <reza.rahman_at_oracle.com> wrote:
> Taking a closer look, it might be best to raise the CDI event at the end of inspectCargo. Looking at the code, I'm a bit worried if the event handling was ported over correctly from Hibernate to JPA. I'll take a look this week if I can to make sure it is correct. CargoRepository.store may need to be tweaked to handle both insert and update. Otherwise, it may be best to write another repository method that just does update (perhaps cleaner).
>
> Also, in order to retain semantic clarity, you may want to raise an event called CargoInspected or CargoHandled that either wraps a tracking ID or the Cargo domain object itself. Up to you...
>
> On 8/12/2013 7:39 AM, Vijay Nair wrote:
>> With regards to the publishing of the socket events for the live transport status and last known location, I have some doubts/questions.
>>
>> The CargoHandledConsumer currently listens for messages on the "CargoHandledQueue" Destination. I was thinking of firing a CDI event once the message has been inspected by the Default Cargo Tracker Service similar to Bruno's technique described here -> https://blogs.oracle.com/brunoborges/entry/integrating_websockets_and_jms_with
>>
>> Can I change the return type of "inspectCargo" to return the Cargo instance so that I can fire the CDI event with the Cargo itself as the payload ? Is this the right approach? Am I missing something fundamental ?
>>
>> Thanks..Vijay
>