(Tidying up the top-posting...)
...I see it really nice to not rely only on annotation - and aligned
most specs - since sometimes you just want to either be able to rely on a
loop or a custom config to register your listeners. Annotations are too
rigid for such cases.
Obviously, if users don't want to use CDI (or MDBs, which are
declarative), then they would use the normal JMS API. The existing
API to register an async message listener isn't good enough,
and we may improve it in JMS 2.1, but that's not something that
I'd want to bother the people on cdi-dev with.
Integrating it in CDI lifecycle through an event allow CDI users to
use it in the right phase of the container boot so it is still important
IMO and avoid all users to have their own custom listener for it -
@Initialized(AppScoped.class). Also allow to enrich the API through the event
itself making things smoother IMO.
I'm sorry I don't understand you.
I thought you were asking about an API which does not use annotation.
Both are needed (like websocket spec). Annotation one is nice for
code and/or simple libs but relying on CDI allows to simplify the wiring since you
can reuse CDI beans under the hood ie have an implicit connection factory if
there is a single one etc which is not possible in fully SE context.
Can you explain the distinction you're making here? You seem to be suggesting two
alternatives, using "annotation" and
"relying on CDI". What would an application which uses CDI but which doesn't
use annotation look like?