Re: Camel 3.x and multiple contexts

[Ronald Feicht <ro...@scsynergy.de>]

Hi Raymond,

thank you for your answer. We have dismissed the option you mention 
because, although that would separate Camel contexts, it would introduce 
a plethora of new problems:
We would need to interact with the operating system (OS) to create, 
remove, start, stop, restart and monitor the external processes or 
Docker containers. As it is now, if our application is running we can 
rest assured every customer's camel context is up and running until the 
application shuts down or we delete the customer.
Interacting with the OS would require different code for Linux and 
Windows machines, maybe even for different Windows or Linux versions.
Not to mention the security considerations when doing command line calls.

If nobody has a better idea we will just have to stay with Camel 2.x for 
as long as possible and then switch to something completely different, 
something that has context separation built-in. Has anybody got a 
recommendation for a replacement for Camel?

Best regards
Ronny

On 3/31/20 3:57 PM, ski n wrote:
> Hi Ronald,
>
> I can't tell about the separation within Camel. I can however say how I see
> how this is done. For example separate the integration from the application
> and then start every integration in a separate process or Docker container
>
> Kind regards,
>
> Raymond
>
> Op di 31 mrt. 2020 om 15:04 schreef Ronald Feicht <
> ronald.feicht@scsynergy.de>:
>
>> 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.feicht@scsynergy.com
>> Sitz der Gesellschaft Bodenheim, HRB 8830, Amtsgericht Mainz,
>> Geschäftsführer: Christian Reichert
>>

-- 
*sc synergy GmbH*
Hilgestrasse 14 | 55294 Bodenheim | Deutschland
Fon: +49 6135 71691 - 000 | Fax: +49 6135 71691 - 199
http://www.scsynergy.com | ronald.feicht@scsynergy.com
Sitz der Gesellschaft Bodenheim, HRB 8830, Amtsgericht Mainz, 
Geschäftsführer: Christian Reichert