Comment #6 on issue 2620 by jean.deruelle: Guaranteed Ordering Of Sip Event
Dispatch
http://code.google.com/p/mobicents/issues/detail?id=2620
with common agreement gvag solution is better suited
Chat log from IRC
<jeand> ok gvag thomasq the approaches are similar IMO
<jeand> gvag, what you propose is to inject beans that will take care of
the concerns like logging, billing etc
<gvag> right
<jeand> in the component of the application handling the INVITE
<vr_> this priority stuff sounds like SLEE stuff
<jeand> vr_, lol
<gvag> if a method register for @Invite then developer is using
communicationBean
<gvag> to handle the INVITE request
<gvag> and before could use the logging bean to log it
<gvag> etc
<gvag> Also during bootstrap we raise an exception
<gvag> if two methods found
<gvag> to observe the same event
<gvag> but this could be disabled with an option
<vr_> gvag, have tried IDE yet?
<vr_> most components can be hot deployed after bootstrap
<jeand> the good thing about this approach is that it removes some
boilerplate external wiring to specify the priorities
<vr_> would bypass validation i think
<jeand> without impairing the decoupling
<thomasq> and dependency injection is something the developer community is
already familiar with
<gvag> vr_, don't think so , you can implement afterBeanDiscovery and block
such methods
<jeand> and is one of the goal of CDI at its core
<gvag> the other way would be to disable the veto, so more than one
@Observes @Register
<gvag> and the developer is responsible
<gvag> to provide the final response at will
<jeand> gvag, it is possible as well
<jeand> the container will raise an exception if the final response has
already been sent
<gvag> jeand, what do you mean?
<vr_> gvag: IDEs really do a lot of hacks, not sure this is realiable,
especially in case of refreshing an already loaded component
<jeand> and the app developer tries to send another one for the same
request from another component
<gvag> jeand, right lets leave it to the container....
