ConnectionFactory exception Test de chameau JMS

Question

Je fais mes premiers pas avec Camel et travaille actuellement à l'écriture d'un simple test de junit en utilisant jms comme moyen de transport.

Voici un code que j'ai écrit:

public class FirstMockTest extends CamelTestSupport { 

    @Override 
    protected RoutesBuilder createRouteBuilder() throws Exception { 
     return new RouteBuilder() { 
      @Override 
      public void configure() throws Exception { 
       from("jms:topic:quote") 
         .to("mock:quote"); 
      } 
     }; 
    } 

    @Test 
    public void testMessageCount() throws InterruptedException { 
     MockEndpoint mockEndpoint = getMockEndpoint("mock:quote"); 
     mockEndpoint.setExpectedMessageCount(1); 
     template.sendBody("jms:topic:quote", "Camel rocks"); 
     mockEndpoint.assertIsSatisfied(); 
    } 
} 

En raison de connectionFactory manquante, je suis l'exception suivante:

org.apache.camel.FailedToCreateRouteException: Failed to create route route1: Route(route1)[[From[jms:topic:quote]] -> [To[mock:quote]]] because of connectionFactory must be specified 

Je suis en mesure de le corriger en ajoutant les lignes suivantes à mon itinéraire:

ConnectionFactory connectionFactory = 
    new ActiveMQConnectionFactory("vm://localhost?roker.persistent=false"); 
context.addComponent("jms", JmsComponent.jmsComponent(connectionFactory)); 

Mais je n'aime pas ajouter certains composants à mon contexte à l'intérieur de la route. Aussi, si je veux avoir un autre itinéraire, je devrai le refaire. Évidemment, il devrait y avoir une autre façon de dire mon test sur la fabrique de connexions.

Merci d'avance!

Answer 1

C'est une bonne idée de définir la fabrique de connexions JMS en dehors de votre contexte Camel et, si possible, de la réutiliser. Comment faire cela dépend de votre modèle de composant/environnement d'exécution.

Si vous utilisez une version Java SE qui prend en charge CDI, ce serait un choix évident. Vous définissez votre fabrique de connexions JMS en tant que composant nommé une fois et vous l'injectez partout où vous en avez besoin. Jetez un oeil à http://camel.apache.org/cdi.html et pour le soutien à l'essai http://camel.apache.org/cdi-testing.html

Si vous utilisez Spring, définir votre usine de connexion comme un grain de printemps et d'injecter partout où vous en avez besoin.

Si vous utilisez Java EE sur un serveur d'applications, vous définissez généralement la fabrique de connexions JMS à l'aide des mécanismes de ce serveur d'applications. Vous devez ensuite rechercher la fabrique de connexions JMS à l'aide de JNDI. Si vous exécutez un conteneur OSGi, vous devez définir la fabrique de connexions JMS dans son propre regroupement et l'exporter en tant que service OSGi. Dans l'ensemble de votre contexte Camel, importez ce serveur OSGi et injectez-le dans le contexte Camel.

Dans tous les cas ci-dessus, vous devez envisager d'utiliser une fabrique de connexions JMS groupée.

Pour CDI, le printemps et OSGi, un coup d'oeil à: http://activemq.apache.org/maven/5.14.5/apidocs/org/apache/activemq/jms/pool/PooledConnectionFactory.html

Pour Java EE la façon comment définir les paramètres de mise en commun dépend de votre serveur d'applications. Remarque: pour Java SE CDI et Spring, il ne devrait y avoir qu'un seul contexte Camel par application (vous pouvez cependant utiliser plusieurs routes). Donc, si la fabrique de connexions JMS n'est utilisée que dans ce contexte Camel, il n'y a pas beaucoup de réutilisation. Malgré cela, je pense toujours qu'il est préférable de définir la connexion JMS en dehors du contexte Camel dans un composant séparé. C'est, bien, plus propre.