I've been using DS annotations and XML Blueprint. If I can ditch Blueprint
for CDI in 2.17, that might be a nice upgrade honestly.

On 27 August 2016 at 14:04, Brad Johnson <[email protected]>
wrote:

> The Camel 2.17 CDI implementation will automatically pick up the
> RouteBuilders. I was kicking the tires on it and was very pleased. The
> RouteBuilders in turn pick up their dependencies from either in bundle
> annotated beans and providers or from external OSGi services.  Pretty slick.
>
> Matt, do you use the XML version of DS or annotations?
>
> Brad
>
> On Sat, Aug 27, 2016 at 1:49 PM, Matt Sicker <[email protected]> wrote:
>
>> I've been using the Java DSL route builders, and you still need to use
>> Blueprint just to load them via <contextScan/> in the <camelContext/>
>> element.
>>
>> On 27 August 2016 at 13:44, Brad Johnson <[email protected]>
>> wrote:
>>
>>> I assume you mean  blueprint XML routebuilders and not Java DSL
>>> routebuilders?  I've used the XML approach for a long time.
>>> CamelBlueprintTestSupport has gotten much better but it still has
>>> limitations on multiple contexts and I find I'm commonly debugging the
>>> tests as much as making the code run right.  It is also a bit slow and will
>>> hang on occasions.
>>>
>>> The only issue I've noticed with CDI and the OSGi annotations is that
>>> the CamelRunner for CDI uses Weld while the pax-cdi doesn't.  That might be
>>> an issue.  CamelSCR still feels half baked.
>>>
>>> But I don't have hard and fast opinions about it and am interested in
>>> different perspectives.
>>>
>>> On Sat, Aug 27, 2016 at 1:17 PM, Johan Edstrom <[email protected]>
>>> wrote:
>>>
>>>> I actually personally passionately hate not using RouteBuilders so
>>>> for me BP really is about inversion of control and I prefer argument
>>>> to properties so I can easily test the same code, not to mention
>>>> I never have to dig for a NPE bean wiring in large systems.
>>>>
>>>>
>>>> /je
>>>>
>>>> On Aug 27, 2016, at 11:44 AM, Brad Johnson <
>>>> [email protected]> wrote:
>>>>
>>>> Agreed that it is philosophical and can be contentious.  I just started
>>>> using CDI via pax-cdi and Camel because Camel 2.17 has better support. Also
>>>> I think the pax-cdi that Guillame and I think JB Onofre created are
>>>> relatively new. So I've just started using and have a project using it
>>>> without any Blueprint XML which I've been using for the past number of
>>>> years.  That required a switch to using the Java DSL for the routebuilder
>>>> but I didn't find that too painful.
>>>>
>>>> Brad
>>>>
>>>> On Sat, Aug 27, 2016 at 12:22 PM, Johan Edstrom <[email protected]>
>>>> wrote:
>>>>
>>>>> I’ve never seen DS used in the wild other than in places where say
>>>>> central infrastructure IT provides container services and frameworks.
>>>>>
>>>>> Still have to see a lot of CDI use and with PaaS offerings and Spring
>>>>> revamps and a lot of push BP is from what I gather the only viable
>>>>> alternative.
>>>>>
>>>>> Just my 0.02c.
>>>>>
>>>>> Since most developers out there just see it as a tool or necessary evil
>>>>> in a corporate setting, they don’t really grok services,
>>>>> registrations, proxies,
>>>>> NamespaceHandlers, SPI providers and so on anyways.
>>>>>
>>>>> I think it is a very philosophical debate.
>>>>>
>>>>> /je
>>>>>
>>>>> > On Aug 27, 2016, at 10:45 AM, Brad Johnson <
>>>>> [email protected]> wrote:
>>>>> >
>>>>> > While I understand the benefits of DS I'm wondering if it makes much
>>>>> difference for end users. I mean if I were creating a library for commons,
>>>>> XStream, Beanio or something else then it makes a lot of sense to expose 
>>>>> it
>>>>> via DS.
>>>>> >
>>>>> > But when creating end user bundles with Camel routes, beans,
>>>>> interfaces, and OSGi services the service damping provided by blueprint
>>>>> seems like a positive benefit in that one doesn't have to worry about 
>>>>> start
>>>>> up order.
>>>>> >
>>>>> > That's doubly true now that I've been working with pax-cdi and
>>>>> Camel.  I'd say the development time is cut in half.  The
>>>>> OSGiSeriviceProvider (sp?) annotation still uses blueprint proxies behind
>>>>> the scenes but I don't think that's a problem.  What it does do is
>>>>> eliminate the need for all the XML configuration which can result in typos
>>>>> and other issues.
>>>>> >
>>>>> > What are the views on this?
>>>>> >
>>>>> > Brad
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Matt Sicker <[email protected]>
>>
>
>


-- 
Matt Sicker <[email protected]>

Reply via email to