I agree with Reza
On 08/12/2013 01:49 PM, Reza Rahman wrote:
> I'm on the road at the moment, so please do excuse the brevity.
>
> Using the CDI event bus (vs JMS) is definitely the way to do since you do not need durability or asynchronous processing in this case. Where to put the event trigger is not clear. If we see it as an event related to persistence I would simply put it in the repository layer. Otherwise, I would put it in the application layer. I don't think it really fits in the domain or interface layers (the MDBs are really sort of in an internal interface layer).
>
> I would definitely put the event observer in the same interface component as the WebSocket end point. Anything else is probably overkill.
>
> Hope this helps. I'll try to dig a bit deeper as soon as I get to my hotel room in the evening and send more specific comments.
>
> Sent from my iPhone
>
> On Aug 12, 2013, at 7:39 AM, Vijay Nair <vijay.nair_at_oracle.com> 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
--
|Bruno Borges (twitter @brunoborges)
Principal Product Manager | Java WebLogic Coherence GlassFish
Oracle LAD PM Team | Cloud Application Foundation
+55 11 5187 6514 (Work) | +55 11 99564 9058 (Mobi)|