[
https://issues.apache.org/activemq/browse/CAMEL-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=59416#action_59416
]
Karl Palsson commented on CAMEL-2730:
-------------------------------------
Further, this is caused by the notes at the bottom of:
http://camel.apache.org/recipient-list.html
If you use {code} blah().recipientList().method(beanName, methodName);{code}
You may NOT use {...@recipientlist}} annotation.
So if you want to use the _same_ method in a _different_ route, like:
{code}.multicast()
.to("bean:beanName?method=methodName", "seda:makeErrorLog");
{code}
Then you either need to duplicate the method, or find a new way of following
the DSL to do the multicast you expect.
Working as designed? sure. Working in a manner that was predictable, no. I
don't think I could agree with that.
> test: Singleton bean creation not allowed while the singletons of this
> factory are in destruction (Do not request a bean from a BeanFactory in
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-2730
> URL: https://issues.apache.org/activemq/browse/CAMEL-2730
> Project: Apache Camel
> Issue Type: Bug
> Components: camel-core, camel-spring-integration
> Affects Versions: 2.2.0
> Reporter: Karl Palsson
>
> I have the following two routes...
> {code}
> from("seda:errorQueue")
> .multicast()
> // unhappy with this, toooo fragile...
> .to("bean:fakeOutputChooser?method=chooseError",
> "seda:makeErrorLog");
> from("seda:makeErrorLog")
> .process(new Processor() {
> public void process(Exchange exchange) throws Exception {
> ErrorFileEntry efr = new ErrorFileEntry("blah");
> exchange.getIn().setBody(efr);
> }
> })
> .to("velocity:/templates/ErrorLog.vm")
> .recipientList().method("fakeOutputChooser", "chooseErrorLog");
> {code}
> I'm trying to test that when I send things into {{seda:errorQueue}} that the
> text is written directly out 2 endpoints, the one chosen by the method
> "chooseError" on the bean "fakeOutputChooser" and _also_ that the velocity
> templated error log gets written to the endpoint chosen by "chooseErrorLog"
> on the same bean.
> In the past, I didn't use any of this "outputChoosing" and just straight up
> to() routes using plain "file:" endpoints, and I tested it by hand. I'm now
> using the spring test support, to try and automatically test that my output
> choosing logic is working. (I now have to pick a different file endpoint
> based on some exchange headers)
> I've got the tests all working for most cases, but the following case fails
> completely....
> {code}
> @Test
> @DirtiesContext
> public void testErrorPath() throws Exception {
> String someBody = "this will fail because of 4213 in the body";
> errorOutput.expectedBodiesReceived(someBody);
> ErrorFileEntry errorBody = new ErrorFileEntry("Mon Jul 26 14:11:25
> 2010", "something", "awerawer", "1231");
> errorLog.expectedBodiesReceived(errorBody);
> directInput.sendBodyAndHeader("direct:input_365", someBody,
> Exchange.FILE_NAME, "blah");
> errorOutput.assertIsSatisfied();
> errorLog.assertIsSatisfied();
> }
> {code}
> the errorOutput check passes, but the errorLog check fails, it never received
> any messages. This is caused by the following debug from spring..
> {quote}
> [org.apache.camel.processor.Pipeline:Camel thread 1: seda://makeErrorLog] -
> <Message exchange has failed so breaking out of pipeline: Exchange[Message:
> Mon May 17 16:58:16 2010
> blah
> Arbitrary Error from Fake conax module,1
> ] Exception: org.apache.camel.language.bean.RuntimeBeanExpressionException:
> Failed to invoke method: chooseErrorLog on fakeOutputChooser due to:
> org.springframework.beans.factory.BeanCreationNotAllowedException: Error
> creating bean with name 'fakeOutputChooser': Singleton bean creation not
> allowed while the singletons of this factory are in destruction (Do not
> request a bean from a BeanFactory in a destroy method implementation!)>
> {quote}
> The stack trace is gone by the time it gets logged, but it's thrown at
> BeanExpression.evaluate() line 74 in the 2.2 release code.
> (processor.process(newExchange)
> I suspect this is because the spring context is torn down, and camel test
> support is just waiting for things to finish before it can start verifying?
> If I'm just doing it completely wrong, by all means point me in the right
> direction :)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
