Camel 3.x migration feedback

[Antoine DESSAIGNE <an...@gmail.com>]

Hello everybody,

I just wanted to share what we discovered while updating to Camel from 2.25
to 3.4. There was no blocker but some unexpected things that weren't in the
migration guide. Maybe we're doing it wrong, please tell me if there's a
better way.

Let's start with a bit of context. We're using multiple Camel contexts on
an OSGi platform and their configurations are stored in a database using
the XML format. Yes, OSGi and XML, they're no longer the cool kids on the
block but it's working really well :)

First, it's not possible to manually
call addRouteDefinitions(Collection<RouteDefinition>) on a brand
new OsgiDefaultCamelContext. The init() method called at the end of the
constructor since CAMEL-14399 initializes the context without routes,
routes added later seemed ignored. We managed to make it work by overriding
the init() method with a no-op method and calling init() after configuring
routes. I have to admit that I don't know if it's an issue or not, I don't
know the nominal case or the expected behavior.

Reifiers truly are a great improvement compared to Camel 2.x, they nicely
split execution model and runtime. We have custom processors and
expressions and we, unfortunately, discovered reifiers the hard way as
they're not documented in the migration guide. I have no clue on the proper
way to document them as they're quite technical and not everybody has
custom processors and expressions.

It was easy to add custom processor reifiers but harder to add expression
ones, we had to use a bit of reflection to access the map holding them,
there's no public accessor (should it have one?)

Speaking of expressions, it looks like it's not possible to have
expressions that aren't derived from an ExpressionDefinition, that aren't
configured as a String. We have many of them, they're quite useful
(especially in XML with different namespace), here is an exemple:
<u:date-parse pattern="dd MMMM yyyy" tz="UTC" locale="FR_FR">
    <simple>${body[date]}</simple>
</u:date-parse>

Lastly, I wanted to thank you all for your hard work. The new documentation
and migration guide are truly awesome and helped us a lot. You also did an
amazing job splitting the core into separate projects, it makes it much
cleaner.

That's all for me, have a nice day,

Antoine

Re: Camel 3.x migration feedback

[Jean-Baptiste Onofre <jb...@nanthrax.net>]

Hi Antoine,

First: OSGi/Karaf are still very cool kids ;) And we have a cool/interesting roadmap.

About your point:

- Even before it was not a good idea to call addRouteDefinitions, it’s better to go through addRoutes. For instance, that’s what I’m doing:


        camelContext = new OsgiDefaultCamelContext(context.getBundleContext());
        camelContext.setName("my-context");
        camelContext.start();
        camelContext.getRegistry().bind("my.bean", new MyBean());
        camelContext.addRoutes(new MyRoute());
        serviceRegistration = context.getBundleContext().registerService(CamelContext.class, camelContext, null);

Anyway, can you please create a Jira linked to CAMEL-14399, I will take a look.

About reifiers, clearly, we need to document this better (we mostly have the javadoc which is not so bad ;)).

Don’t hesitate to ping me about Camel Karaf roadmap (aka karamel) if you want some details.

Thanks,
Regards
JB

> Le 9 sept. 2020 à 21:16, Antoine DESSAIGNE <an...@gmail.com> a écrit :
> 
> Hello everybody,
> 
> I just wanted to share what we discovered while updating to Camel from 2.25
> to 3.4. There was no blocker but some unexpected things that weren't in the
> migration guide. Maybe we're doing it wrong, please tell me if there's a
> better way.
> 
> Let's start with a bit of context. We're using multiple Camel contexts on
> an OSGi platform and their configurations are stored in a database using
> the XML format. Yes, OSGi and XML, they're no longer the cool kids on the
> block but it's working really well :)
> 
> First, it's not possible to manually
> call addRouteDefinitions(Collection<RouteDefinition>) on a brand
> new OsgiDefaultCamelContext. The init() method called at the end of the
> constructor since CAMEL-14399 initializes the context without routes,
> routes added later seemed ignored. We managed to make it work by overriding
> the init() method with a no-op method and calling init() after configuring
> routes. I have to admit that I don't know if it's an issue or not, I don't
> know the nominal case or the expected behavior.
> 
> Reifiers truly are a great improvement compared to Camel 2.x, they nicely
> split execution model and runtime. We have custom processors and
> expressions and we, unfortunately, discovered reifiers the hard way as
> they're not documented in the migration guide. I have no clue on the proper
> way to document them as they're quite technical and not everybody has
> custom processors and expressions.
> 
> It was easy to add custom processor reifiers but harder to add expression
> ones, we had to use a bit of reflection to access the map holding them,
> there's no public accessor (should it have one?)
> 
> Speaking of expressions, it looks like it's not possible to have
> expressions that aren't derived from an ExpressionDefinition, that aren't
> configured as a String. We have many of them, they're quite useful
> (especially in XML with different namespace), here is an exemple:
> <u:date-parse pattern="dd MMMM yyyy" tz="UTC" locale="FR_FR">
>    <simple>${body[date]}</simple>
> </u:date-parse>
> 
> Lastly, I wanted to thank you all for your hard work. The new documentation
> and migration guide are truly awesome and helped us a lot. You also did an
> amazing job splitting the core into separate projects, it makes it much
> cleaner.
> 
> That's all for me, have a nice day,
> 
> Antoine

Re: Camel 3.x migration feedback

[Claus Ibsen <cl...@gmail.com>]

Hi

Thanks for the feedback.

The reifiers are intended as internal usage to help moduarilize Camel
itself - they are not part of the API in camel-api.
Well except for a little api we need for house-cleaning reifiers such
as when they are no longer needed in a closed-world environment.

They are pluggable as you may have noticed if you have ventured down
the inner code,
such as how we make camel-hystrix etc plugin with their reifier
implementation outside the core engine.

Language expressions have always been tied to ExpressionDefinition and
configurable from a string value.

I assume you have built a custom platform on top of Camel and as such
gone further than what normal Camel users would do, and is expected.

Good to hear the migration guide helped you and your team to get
onboard v3, as v2 is coming to a stop.

The migration guides can of course be adjusted if anyone stumble on
something that is wrong, or if worth to be mentioned (we likely have
missed something).

And also a shout out to the new 2.x -> 3.0 reporting tool from Windup
(will come for 3.x to 3.x also in the near future).
https://camel.apache.org/blog/2020/09/windup/



On Wed, Sep 9, 2020 at 9:16 PM Antoine DESSAIGNE
<an...@gmail.com> wrote:
>
> Hello everybody,
>
> I just wanted to share what we discovered while updating to Camel from 2.25
> to 3.4. There was no blocker but some unexpected things that weren't in the
> migration guide. Maybe we're doing it wrong, please tell me if there's a
> better way.
>
> Let's start with a bit of context. We're using multiple Camel contexts on
> an OSGi platform and their configurations are stored in a database using
> the XML format. Yes, OSGi and XML, they're no longer the cool kids on the
> block but it's working really well :)
>
> First, it's not possible to manually
> call addRouteDefinitions(Collection<RouteDefinition>) on a brand
> new OsgiDefaultCamelContext. The init() method called at the end of the
> constructor since CAMEL-14399 initializes the context without routes,
> routes added later seemed ignored. We managed to make it work by overriding
> the init() method with a no-op method and calling init() after configuring
> routes. I have to admit that I don't know if it's an issue or not, I don't
> know the nominal case or the expected behavior.
>
> Reifiers truly are a great improvement compared to Camel 2.x, they nicely
> split execution model and runtime. We have custom processors and
> expressions and we, unfortunately, discovered reifiers the hard way as
> they're not documented in the migration guide. I have no clue on the proper
> way to document them as they're quite technical and not everybody has
> custom processors and expressions.
>
> It was easy to add custom processor reifiers but harder to add expression
> ones, we had to use a bit of reflection to access the map holding them,
> there's no public accessor (should it have one?)
>
> Speaking of expressions, it looks like it's not possible to have
> expressions that aren't derived from an ExpressionDefinition, that aren't
> configured as a String. We have many of them, they're quite useful
> (especially in XML with different namespace), here is an exemple:
> <u:date-parse pattern="dd MMMM yyyy" tz="UTC" locale="FR_FR">
>     <simple>${body[date]}</simple>
> </u:date-parse>
>
> Lastly, I wanted to thank you all for your hard work. The new documentation
> and migration guide are truly awesome and helped us a lot. You also did an
> amazing job splitting the core into separate projects, it makes it much
> cleaner.
>
> That's all for me, have a nice day,
>
> Antoine



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2