How about just allowing a class to be specified in the package scan? Some
kind of ContextAware scan handler that could process arbitrary classes? It
would be similar in many ways to a BeanPostProcessor and could default to
scanning for routes e.g.

<packageScan>
      <scanhandler>org.apache.camel.scan.ComponentScanHandler</scanhandler>
</packageScan>

with an interface along the lines of 

public interface ScanHandler{
   public void processDiscoveredClasses(Set<Class> matching);

// or even with instantiated instances

   public void processDiscoveredInstances(Set<T> matchingInstances);

}



Claus Ibsen-2 wrote:
> 
> On Mon, Jun 15, 2009 at 4:31 AM, Willem Jiang<willem.ji...@gmail.com>
> wrote:
>> Hi Stephen,
>>
>> Claus created a same requirement[1] as yours, but I like your scanner
>> with exclude and include option more :)
> Yeah Stephens works is really cool.
> 
> Now that we are into changing the DSL for route builder I have thought
> of introducing a uber tag for that
> As you can configure route builders as either a reference
> <rouuteBuilder> or using the scanner <packageScan>.
> 
> <routeBuilders>
>    <packageScan>
>       ...
>    </packageScan>
>    <routeBuilder ref="foo"/>
> </routeBuilders>
> 
> But this requires an extra XML tag and it makes the configuration a
> bit more verbose.
> And I guess its uncommon to use the combo of scanner and routeBuilder
> ref together?
> 
> 
>> Thanks for your contribution.
>>
>> [1]https://issues.apache.org/activemq/browse/CAMEL-1695
> 
> 
>>
>> Willem
>>
>> sgargan wrote:
>>> Claus,
>>>
>>> I've made a patch to allow the Ant like inclusion and exclusion you
>>> suggested. I've opened an improvement Jira ticket for it with a patch
>>> https://issues.apache.org/activemq/browse/CAMEL-1708.
>>>
>>> Please shout if there is anything you'd like changed with it.
>>>
>>> thx
>>>
>>> ste
>>>
>>>
>>> sgargan wrote:
>>>> Cheers Claus. The ant exclusions sound like a good idea. Let me take a
>>>> look at what that would involve.
>>>>
>>>> thx for your help,
>>>>
>>>> ste
>>>>
>>>>
>>>> Claus Ibsen-2 wrote:
>>>>> On Wed, Jun 10, 2009 at 10:42 PM, sgargan<sgar...@qualcomm.com> wrote:
>>>>>> In the 1.6 codeline it was possible to define routebuilders as beans
>>>>>> in
>>>>>> a
>>>>>> Spring context and have them wired into the camel context upon
>>>>>> intialization
>>>>>> e.g.
>>>>>>
>>>>>> <bean id="simpleHttpRoute" class="org.simple.SimpleHttpToFileRoute"
>>>>>> />
>>>>>>
>>>>>> This bean would have been added to the context when the following
>>>>>> block
>>>>>> of
>>>>>> code in in the  installRoutes method of the CamelContextFactoryBean
>>>>>> was
>>>>>> executed
>>>>>>
>>>>>>  protected void installRoutes() throws Exception {
>>>>>>        if (autowireRouteBuilders != null &&
>>>>>> autowireRouteBuilders.booleanValue()) {
>>>>>>            Map builders =
>>>>>> getApplicationContext().getBeansOfType(RouteBuilder.class, true,
>>>>>> true);
>>>>>>            if (builders != null) {
>>>>>>                for (Object builder : builders.values()) {
>>>>>>                    getContext().addRoutes((RouteBuilder) builder);
>>>>>>                }
>>>>>>            }
>>>>>>        }
>>>>>>
>>>>>> In the 2.0 codeline, this section has been removed (as part of a fix
>>>>>> for
>>>>>> the
>>>>>> following issue/feature http://bit.ly/n6ojs ) and the context defined
>>>>>> routes
>>>>>> do not get added. I was wondering what the reason was for dropping
>>>>>> this?
>>>>>> Was
>>>>>> it considered harmful?
>>>>> You can use the <routeBuilder ref="simpleHttpRoute"/> in
>>>>> <camelContext>.
>>>>>
>>>>> Yes it was considered to magical. What if you have 2 camel contextes
>>>>> then they would both
>>>>> load up all the route builders they could find as spring beans.
>>>>>
>>>>> And for users coming in to maintain the code would not be able to
>>>>> figure
>>>>> out
>>>>> how the routes are kick started.
>>>>>
>>>>> Yet alone the <package> could be a bit difficult to understand.
>>>>> That reminds me, maybe if it was named package-scan it would be easier
>>>>> to hint that.
>>>>>
>>>>>
>>>>>> I know the package scan can be used to initialise RouteBuilders it
>>>>>> finds
>>>>>> in
>>>>>> packages, but it can be annoying to exclude routes from this
>>>>>> mechanism,
>>>>>> for
>>>>>> instance where you have test RouteBuilders that happen to live in the
>>>>>> same
>>>>>> package in the test src tree, or where there are routes that
>>>>>> complicate
>>>>>> testing with setup and noise. Also in situations where you configure
>>>>>> the
>>>>>> RouteBean explicitly e.g. to inject values from properties files, it
>>>>>> is
>>>>>> much
>>>>>> cleaner to define the routes as beans.
>>>>> I have been wondering if we should add ANT files matcher here as well,
>>>>> so you can
>>>>> specify includes/excludes as well.
>>>>>
>>>>>> Short of adding my own CamelContextAwareBean to do the same, Is there
>>>>>> a
>>>>>> different mechanism to do setup Routes this way?
>>>>> Yes the <routeBuilder ref> tag.
>>>>>
>>>>>
>>>>>> Thanks in advance
>>>>>>
>>>>>> Stephen.
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/Autowiring-RouteBuilders-defined-as-beans-in-Spring.-tp23970613p23970613.html
>>>>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Claus Ibsen
>>>>> Apache Camel Committer
>>>>>
>>>>> Open Source Integration: http://fusesource.com
>>>>> Blog: http://davsclaus.blogspot.com/
>>>>> Twitter: http://twitter.com/davsclaus
>>>>>
>>>>>
>>>>
>>>
>>
>>
> 
> 
> 
> -- 
> Claus Ibsen
> Apache Camel Committer
> 
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Autowiring-RouteBuilders-defined-as-beans-in-Spring.-tp23970613p24062437.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Reply via email to