camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (CAMEL-154) Improper wiring of camel context using Spring
Date Tue, 25 Sep 2007 15:53:22 GMT

     [ https://issues.apache.org/activemq/browse/CAMEL-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Hiram Chirino resolved CAMEL-154.
---------------------------------

       Resolution: Fixed
    Fix Version/s: 1.2.0

Patch applied rev 579301

> Improper wiring of camel context using Spring
> ---------------------------------------------
>
>                 Key: CAMEL-154
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-154
>             Project: Apache Camel
>          Issue Type: Bug
>          Components: camel-spring
>    Affects Versions: 1.2.0
>            Reporter: Hadrian Zbarcea
>            Assignee: Hadrian Zbarcea
>             Fix For: 1.2.0
>
>         Attachments: camel-154.patch
>
>
> When using spring to wire camel components, the whole magic is driven by org.springframework.context.support.AbstractApplicationContext.refresh().
> At about line 327 the xml file is read and at some point AbstractApplicationContext.doParse
is called.  What is notable is that we use parseUsingJaxb (line 135) instead of the spring
way of doing things, and then we still use 
> BeanDefinitionParser(s) to build the BeanDefinition(s).
> On a sample context definition like the one in the unit tests:
>   <camelContext id="camel" xmlns="http://activemq.apache.org/camel/schema/spring">
>     <beanPostProcessor/>
>     <endpoint id="endpoint1" uri="direct:start"/>
>     <endpoint id="endpoint2" uri="mock:end"/>
>     <route>
>       <from ref="endpoint1"/>
>       <to ref="endpoint2"/>
>     </route>
>   </camelContext>
> The jaxb parser instantiates the BeanPostProcessor, endpoints, the RouteType, From/ToTypes
properly, but the BeanPostProcessor is not injected with the camelContext and applicationContext,
obviously.
> Later on in AbstractApplicationContext.refresh() during the registerBeanPostProcessors()
call (line 337) spring figures out that it needs to instantiate the BeanPostProcessor first
and use it before it initializes the other beans.  So far so good, but in doing so there are
2 major problems.
> 1. It uses the BeanDefinition instead of the instance already created during jaxb parsing.
> 2. There is a chicken and egg situation; while it initializes "camel:beanPostProcessor",
it looks for a "camel" bean which isn't registered yet.  The model for it does exist though,
so a new instance of the CamelContextFactoryBean gets instantiated (and the id now is null
instead of "camel" as in the spring xml).
> I wrestled with this and couldn't figure out a solution.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message