The JMS spec (unlike the EJB spec) doesn't define a container - it simply defines an application API which can be used
in any Java EE container or in Java SE.
My feeling is that JMS shouldn't be defining a new container: if people need to be able to embed Java EE services such
as a JNDI server, a JMS server, or the processing of resource definition annotations into their application then we
should be asking the Java EE platform EG to define a suitable container
Nigel
On 30/07/2012 16:17, Antonio Goncalves wrote:
> Not much really. If you look at the EJBContainer API (
> http://docs.oracle.com/javaee/6/api/javax/ejb/embeddable/EJBContainer.html ) it just gives you the ability to create a
> container (and start it), close the container and get the JNDI context. Once the container is
> started programmatically, you get all the features of a runtime container (in the case of JMS it's sending/receiving
> messages, QoS like message delivery, MDBs... and so on).
>
> This is the test case I would like to write :
>
> @Test
> public void shouldSendAMessage() throws Exception {
> // Creates a JMS Container (Broker)
> JMSContainer jmsContainer = JMSContainer.createJMSContainer();
> Context ctx = jmsContainer.getContext();
>
> // Looks up for connection factory and queue
> ConnectionFactory connectionFactory = (ConnectionFactory ) ctx.lookup("java:global/jms/MyConnFact");
> Queue queue = (Queue) ctx.lookup("java:global/jms/MyQueue");
>
> // Creates needed connection and session
> Connection connection = connectionFactory.createConnection();
> Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
> MessageProducer producer = session.createProducer(queue);
>
> // Sends an object message to the queue
> TextMessage message = session.createTextMessage("my message");
> producer.send(message);
>
> jmsContainer.close();
> }
>
> And the JMS Container, at startup, would introspect all the classes defined in the classpath and find something like
> this :
>
> @JMSConnectionFactoryDefinition( name="java:global/jms/MyConnFact", resourceType="javax.jms.QueueConnectionFactory")
> @JMSDestinationDefinition( name="java:global/jms/MyQueue", resourceType="javax.jms.Queue")
> public class JMSResources {
>
> }
>
> This is just a basic example. What do you think of being able to do something like that ?
>
> Antonio
>
> On Mon, Jul 30, 2012 at 4:38 PM, Nigel Deakin <nigel.deakin_at_oracle.com <mailto:nigel.deakin_at_oracle.com>> wrote:
>
> On 30/07/2012 14:23, Antonio Goncalves wrote:
>
>
>
> I haven't followed the JMS 2.0 specification, so sorry if this topic has been discussed.
>
> Since EJB 3.0 and its EJBContainer API, life for integration test has been made easy (and even easier
> with tools
> such as
> Arquillian). I've contacted several time the Servlet 3.1 EG to have such API (a WebContainer API to
> start, stop,
> deploy... servlets will help for testing) and was wondering if an embedded JMSContainer API was on the
> roadmap ?
> Today
> integration testing with JMS/MDB is impossible in a standard way but possible with proprietary tools.
> EJBContainer is
> not intended to work with MDBs so I was wondering if the JMS EG had something in mind in terms of
> embedded JMS
> containers.
>
> Thanks
> Antonio
>
>
> What features would an "embedded JMS container" offer?
>
> Nigel
>
>
> On 30/07/2012 14:56, Antonio Goncalves wrote:
>
> It will offer a standard API to start/stop a JMS Broker. You can then, in an integration test, start a JMS Broker
> programmatically, define a Destination and Factory (using the new @JMSDestination annotations), send a message to
>
> this destination, received a message, check that the received message is ok, integration test is green, and
> then we
> close the JMS Broker programmatically at the end of the test. Like the EJBContainer, this will just be an API and
>
> the implementation would just be a jar file in your classpath.
>
>
> Thanks. Apart from the the ability to start and stop the JMS server, and the ability to define Java EE resources
> using @JMSConnectionFactoryDefinition and @JMSDestinationDefinition annotations (if that's what you were referring
> to), what other Java EE features would such a container offer? @Resource annotations? A transaction manager?
> Session beans? MDBs? Connection pooling? CDI?
>
> Nigel
>
>
>
>
>
>
> --
> Antonio Goncalves
> Software architect and Java Champion
>
> Web site <http://www.antoniogoncalves.org> | Twitter <http://twitter.com/agoncal> | LinkedIn
> <http://www.linkedin.com/in/agoncal> | Paris JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>