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