Hi An app is classloader isolated, eg a WAR in Apache Tomcat, an OSGi bundle, a Spring Boot app, etc.
On Tue, Nov 29, 2022 at 9:18 AM Ephemeris Lappis <[email protected]> wrote: > 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. > -- Claus Ibsen ----------------- @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
