Hello. We're looking for the constraints that may exist to migrate our projects from Camel 2.x to 3.x.
One of them is mentioned in https://camel.apache.org/manual/camel-3-migration-guide.html, about multiple Camel contexts in the same application. I'd like to be sure about what is an "application", and if we're impacted by such restrictions. An example of project structure : - An OSGi bundle as deployment unit (today managed as a RedHat Fuse profile, and planned to be managed as a Karaf feature. - Some beans to define some kind of data and specific EventNotifier implementations. - 1 blueprint to declare default properties (property-placeholder with the PID attached to the bundle) that may be overridden or not by deployments. Some properties defined once are used in different contexts. - 1 blueprint to instantiate beans or to reference external services - 1 blueprint with shared common routes with "vm" endpoints - 7 blueprints for 7 business groups of routes that rely on common services and use common properties and shared routes. Can we port this kind of projects to Camel 3.x as is, or should we change completely our design to move each Camel context in its own bundle, each bundle with its own configuration property file (duplicating entries), and as many features as bundles, multiplying dev-ops and production work ? Thanks in advance for your advice and help. Regards.
