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 <antoine.dessai...@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
