Testing CDI Route

classic Classic list List threaded Threaded
7 messages Options
Oli
Reply | Threaded
Open this post in threaded view
|

Testing CDI Route

Oli
Hello camel experts,

I'm using camel inside of wildfly swarm application and having trouble to create a working test with CamelCdiRunner. I've followed the example from camel documentation but the test I've created fails with the error:

java.lang.NullPointerException
        at org.wildfly.swarm.cdi.StageConfigBean.getBeanClass(StageConfigBean.java:48)

Now, I realize that it is might be wildfly swarm issue (or my fault :D), but I hope that there is the way to test the route without involving wildfly swarm at all. That's why I've used CamelCdiRunner.

Here is demo project with the test.

https://doc-08-1o-docs.googleusercontent.com/docs/securesc/ha0ro937gcuc7l7deffksulhg5h7mbp1/g6huv41c8phejsrv7f9djrkie28con92/1478181600000/04138686178860852595/*/0B48lpc4O6VLJam5TLTZoc3VCZG8?e=download

Thank you

- oli
Reply | Threaded
Open this post in threaded view
|

Re: Testing CDI Route

astefanutti
Hi Oli,

CamelCdiRunner bootstraps a Weld SE container so that you can easily test your Camel CDI code with a bare minimal CDI container. If you want to test your Camel CDI code with WildFly Swarm, you may need to rely on Arquillian or what WildFly Swarm provides as testing framework. You may find some examples in the WildFly Swarm project, like https://github.com/wildfly-swarm/wildfly-swarm-examples/tree/master/camel/camel-cdi.

Hope that helps.

Antonin

> On 03 Nov 2016, at 15:30, Oli <[hidden email]> wrote:
>
> Hello camel experts,
>
> I'm using camel inside of wildfly swarm application and having trouble to
> create a working test with CamelCdiRunner. I've followed the example from
> camel documentation but the test I've created fails with the error:
>
> java.lang.NullPointerException
> at
> org.wildfly.swarm.cdi.StageConfigBean.getBeanClass(StageConfigBean.java:48)
>
> Now, I realize that it is might be wildfly swarm issue (or my fault :D), but
> I hope that there is the way to test the route without involving wildfly
> swarm at all. That's why I've used CamelCdiRunner.
>
> Here is demo project with the test.
>
> https://doc-08-1o-docs.googleusercontent.com/docs/securesc/ha0ro937gcuc7l7deffksulhg5h7mbp1/g6huv41c8phejsrv7f9djrkie28con92/1478181600000/04138686178860852595/*/0B48lpc4O6VLJam5TLTZoc3VCZG8?e=download
>
> Thank you
>
> - oli
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Testing-CDI-Route-tp5789709.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Oli
Reply | Threaded
Open this post in threaded view
|

Re: Testing CDI Route

Oli
Hi Antonin,

in other words, CamelCdiRunner would do the job? Why it doesn't work for me? The test class:

@RunWith(CamelCdiRunner.class)
@Beans(classes = Route.class)
public class RouteTest {

    void advice(
            @Observes CamelContextStartingEvent event,
            @Uri("mock:test") MockEndpoint messages,
            ModelCamelContext context) throws Exception {

        context.getRouteDefinition("route")
                .adviceWith(context, new AdviceWithRouteBuilder() {
                    @Override
                    public void configure() {
                        replaceFromWith("direct:start");
                        weaveById("mybean").replace().to("mock:mybean");
                    }
                });
    }

    @Test
    /**
     * testing if the bean was properly mocked
     */
    public void testRoute(
            @Uri("direct:in") ProducerTemplate producer,
            @Uri("mock:mybean") MockEndpoint mock) throws InterruptedException {

        mock.expectedMessageCount(1);
        mock.expectedBodiesReceived("bar");
        producer.sendBody("bar");
        MockEndpoint.assertIsSatisfied(5L, TimeUnit.SECONDS, mock);
    }

}
Reply | Threaded
Open this post in threaded view
|

Re: Testing CDI Route

astefanutti
Hi Oli,

Indeed, your test class should work. However, it seems the WildFly Swarm plugin generates some other classes, like org.wildfly.swarm.cdi.StageConfigBean, that are deployed as bean classes and that seems to require some execution context. The CamelCdiRunner starts a Weld SE container with its default discovery mode enabled, hence those classes being deployed as well. IMHO, it’d be better to align with the testing approach recommended by WildFly Swarm as that is likely to make your life easier in the long run.

Antonin

> On 03 Nov 2016, at 17:06, Oli <[hidden email]> wrote:
>
> Hi Antonin,
>
> in other words, CamelCdiRunner would do the job? Why it doesn't work for me?
> The test class:
>
> @RunWith(CamelCdiRunner.class)
> @Beans(classes = Route.class)
> public class RouteTest {
>
>    void advice(
>            @Observes CamelContextStartingEvent event,
>            @Uri("mock:test") MockEndpoint messages,
>            ModelCamelContext context) throws Exception {
>
>        context.getRouteDefinition("route")
>                .adviceWith(context, new AdviceWithRouteBuilder() {
>                    @Override
>                    public void configure() {
>                        replaceFromWith("direct:start");
>                        weaveById("mybean").replace().to("mock:mybean");
>                    }
>                });
>    }
>
>    @Test
>    /**
>     * testing if the bean was properly mocked
>     */
>    public void testRoute(
>            @Uri("direct:in") ProducerTemplate producer,
>            @Uri("mock:mybean") MockEndpoint mock) throws
> InterruptedException {
>
>        mock.expectedMessageCount(1);
>        mock.expectedBodiesReceived("bar");
>        producer.sendBody("bar");
>        MockEndpoint.assertIsSatisfied(5L, TimeUnit.SECONDS, mock);
>    }
>
> }
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Testing-CDI-Route-tp5789709p5789714.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Oli
Reply | Threaded
Open this post in threaded view
|

Re: Testing CDI Route

Oli
I see... I've tried the approach recommended by wildfly swarm, but it didn't work for me either. The examples are very basic and don't involve any injecting and mocking of the parts of the route.
Reply | Threaded
Open this post in threaded view
|

Re: Testing CDI Route

astefanutti
I would expect your testing logic to work fine in an Arquillian test. What error do you face?

> On 04 Nov 2016, at 09:37, Oli <[hidden email]> wrote:
>
> I see... I've tried the approach recommended by wildfly swarm, but it didn't
> work for me either. The examples are very basic and don't involve any
> injecting and mocking of the parts of the route.
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Testing-CDI-Route-tp5789709p5789738.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Oli
Reply | Threaded
Open this post in threaded view
|

Re: Testing CDI Route

Oli
It would work, if there were no third-party dependencies. I deliberately used google guava to demostrate this
Caused by: java.lang.NoClassDefFoundError: com/google/common/collect/ImmutableMap

That is because Deployment was JavaArchive. So, I've tried to create WARArchive, which can include dependencies: ShrinkWrap.create(WARArchive.class, "democdi.war").addPackages(true, "com.democdi").addAllDependencies();

In this case the error is:
Caused by: java.lang.RuntimeException: Found extension impl class org.wildfly.swarm.undertow.internal.WARArchiveImpl not assignable to extension interface org.wildfly.swarm.undertow.WARArchive


So, in summary it would work with JavaArchive deployment without thirt-party dependencies.