Hi You can run as many camel contexts as you like in a JVM.
For example on WildFly or Karaf you can just deploy multiple XML files (deployments) each with their own <camelContext>. In other word manage each customer in their own xml file and have them separated. Then each deployment is per customer and they can manage that as now, eg stop/start routes and whatnot. It was just that in a single XML file you could have multiple <camelContext> which is bad design as then they end up in the same deployment and have shared lifecycle, and also its harder to separate resources between them as they may end up picking up the same resources (eg a data source) as some camel components have built in defaults to lookup default resources and use them and so on. Its a bad design and practice. And separation is recommended as individual deployment units in your application server. Then the application server manages proper lifecycles, separate classloading and resources etc. And this is also where the world is going with cloud and containers to have separate processes. And also to get better help for your situation then it would help to show more exactly what you do today, and provide some examples. That help everybody to better understand. On Tue, Mar 31, 2020 at 3:04 PM Ronald Feicht <ronald.fei...@scsynergy.de> wrote: > > Hello everyone, > > with version 3 Camel has dropped support for multiple Camel contexts, > which we have been using extensively. Our software may be licensed as > on-premises or as cloud service and offers every customer the option of > using Camel to e. g. import files from email servers (or FTP or REST > etc.) or publish files / data via REST / SQL / SMB etc. to external servers. > > With Camel 2.x we created a separate Camel context for each customer to > ensure that: > 1. every customer can choose a meaningful route id (e. g. > "text-extraction" or "invoices") without duplicates causing errors > 2. customers may only edit their own configuration and start / stop > their own routes / context > 3. customers do not have access to other customers' routes (e. g. by > allowing the "vm" component to only address routes within the same context) > 3. configuration errors do not cause Camel processing of other customers > to stop working > 4. we can just copy a customer's Camel configuration from our cloud > system to an on-premises system or vice versa if the customer wishes to > change his license > 5. our support team may quickly and easily help in configuring or > troubleshooting Camel without having to identify which routes belong to > whom first > > So, my question is: With Camel 3+ how may we achieve the same separation > of services? Info: We use Wildfly application server as environment for > our code to run (on Linux and Windows). > > Best regards > Ronny > -- > *sc synergy GmbH* > Hilgestrasse 14 | 55294 Bodenheim | Deutschland > Fon: +49 6135 71691 - 000 | Fax: +49 6135 71691 - 199 > http://www.scsynergy.com | ronald.fei...@scsynergy.com > Sitz der Gesellschaft Bodenheim, HRB 8830, Amtsgericht Mainz, > Geschäftsführer: Christian Reichert -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
