Following up for posterity...
The workaround I'm going with is to create a per bundle CamelContext using
Blueprint. Each module adds routes to its own context and the onException
handlers can see the appropriate Exception classes. Messages are passed to
the core application's context using the vm:// component.
I will log this as a Camel bug - I don't think it makes sense that I *can*
use a private-package Processor in a context, but I can't define an On
Exception handler for a private-package Exception.
Paul
On Mon, 22 Jan 2024 at 16:34, Paul McCulloch wrote:
> Hi,
>
> I'm currently migrating an OSGI application from Camel 2.25 to 3.21. I've
> encountered a change in the way onException deals with the type it's asked
> to handle in an OSGI environment.
>
> In 2.25 the OnExceptionDefinition instance keeps a reference to the
> classes it's asked to handle (in the exceptionClasses field).
>
> In 3.x it just stores the names of the exception classes it should handle.
> When the ProcessorReifier builds the route it then loads the required
> classes named on the definition.
>
> My issue is that my camel context is created in one OSGi bundle (with one
> classloader) and the route added from a different bundle (with its own
> classloader). In 2.x this worked fine. In 3.x the route can't be started
> (as the context's classloader can't see the exception class).
>
> This design is used to permit plugin modules to add their own routes to
> the core application's context.
>
> Has anyone experienced the same issue and found a solution? I don't want
> to add Import-Package instructions to the bundle with the Camel Context -
> as this would break the plugin module design. Using DynamicImport-Package:
> * in my camel context bundle does resolve the issue but doesn't seem ideal
> - my plugin bundle should be resolving the exception class.
>
> Thanks,
> Paul
>
