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>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>