On 24/08/2015 18:42, Antonio Goncalves wrote:
Nigel, what do you mean by :
"The application must obtain an instance of the JMS listener bean using dependency
injection"
In your examples, it looks like a CDI bean cannot start listening if not injected :
@WebServlet("/myjmsservlet1")
public class MyJMSServlet1 extends HttpServlet {
*@Inject MyDepScopeListenerBean* myDepScopeListenerBean;
public void service(ServletRequest req, ServletResponse res) throws IOException,
ServletException {
...
}
}
Did I understand well ? Is this the case ? Just like a MDB, I would like a CDI bean to
start listening to a message
without being injected, as soon as the application starts.
My starting point is that these are normal CDI beans which are created just like any other
CDI bean. The bean's
postCreate behaviour (inserted by the extension) would connect to the JMS provider and
start listening for messages. The
bean's preDestroy behaviour would stop listening for messages and disconnect from the
JMS provider.
As I understand it, if you want to create a CDI managed bean (so that it is managed by
CDI) then you have to inject it
into some code somewhere.
Additionally, if the bean is normal scoped, you have to trigger lazy instantiation by
calling a method on the injected
bean proxy (e.g. toString()).
Something like :
*@ApplicationScoped*
public class MyListenerBean{
@JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC
)
public void deliver(Message message) {
...
}
}
If I understand things correctly, if this is a normal CDI bean then this alone is not
sufficient to cause an instance of
the bean to be created.
You also need to
(1) inject it into some other bean
(2) create that other bean and
(3) call a method on the MyListenerBean to trigger lazy initialisation.
I'm trying to avoid getting ahead of myself here. My current proposals simply apply to
normal CDI managed beans created
in the normal way (via injection and lazy initialisation). But I could certainly see a
benefit in extending this to
allow JMS listener beans to be created in other ways. In particular:
(a) Creating the bean instance as soon as the bean into which it is injected enters a new
scope rather than waiting for
the application to call a method on it (so-called eager initialisation). That sounds
relatively straightforward to me;
this could either be a new standard CDI feature available to all normal-scoped beans, or
something specific to beans
annotated with @JMSListener.
(b) Creating the bean instance without the need to inject it anywhere. As you suggest, in
the case of ApplicationScoped
beans this would make JMS listener beans more like MDBs. But it might be equally useful to
support this for other normal
scopes. For example, could we annotate a @RequestScoped bean so that every time a new
request scope started, an instance
of the bean for that scope was automatically created?
Or if we manage to get the @Startup annotation to Commons Annotation
:
*@Startup*
public class MyListenerBean{
@JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC
)
public void deliver(Message message) {
...
}
}
That looks as if it's tied to ApplicationScoped. I'd rather look for something
more general.
Thanks for your comments so far. You're raising issues I have been thinking about for
some time.
Nigel
Just thinking here
Antonio
On Mon, Aug 24, 2015 at 6:30 PM, Nigel Deakin <nigel.deakin(a)oracle.com
<mailto:nigel.deakin@oracle.com>> wrote:
Over in the JMS 2.1 expert group I've just published some proposals to allow any
CDI managed bean in a Java EE
application to listen for JMS messages. This would be implemented as a standard CDI
portable extension and would
become
a mandatory part of a full Java EE 8 application server.
I would welcome any comments from the CDI spec experts here. If you're interested
in helping, please take a look at
https://java.net/projects/jms-spec/pages/CDIBeansAsJMSListeners
and send comments or questions to me or to the public users(a)jms-spec.java.net
<mailto:users@jms-spec.java.net> alias.
Thanks,
Nigel
JMS 2.1 specification lead
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the code under
the Apache License, Version 2
(
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on
this list, the provider waives
all patent and other intellectual property rights inherent in such information.
--
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site <
http://www.antoniogoncalves.org> | Twitter
<
http://twitter.com/agoncal> | LinkedIn
<
http://www.linkedin.com/in/agoncal> | Pluralsight
<
http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris JUG
<
http://www.parisjug.org> | Devoxx
France <
http://www.devoxx.fr>