Yes, we already talked about that on the EE EG. Most of the members agree
that EE should only have one container (instead of a Web container, EJB
container, CDI container...) that gives you several services (persistence,
messaging, injection...). But it looks like we won't hit the target for
this release. In that case we will have a single API for an embedded
container that would be able to access all these services (including JMS
for example).
Antonio
On Mon, Jul 30, 2012 at 7:09 PM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> 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>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>
>
>
--
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>