[GitHub] [camel-k] weimeilin79 commented on issue #1821: Support for POJO, bring it back!

[GitBox <gi...@apache.org>]

weimeilin79 commented on issue #1821:
URL: https://github.com/apache/camel-k/issues/1821#issuecomment-731590191


   Yes, I totally agree that we should not abuse it. But also we don’t want to completely wipe out the flexibility. In order for a better UX and more efficient engine, we need to take a closer look at their behaviour. Because sometimes I don’t code in a certain way, it’ll be good to take a look at some older issue and their problem repo to setup some rules? 
   
   > I am the one to be blamed for have introduced and then removed this feature.
   > 
   Not blaming :) Just want to know why? 
   
   > So what issues do we have by letting people adding any arbitrary code through camel-k ?
   > 
   > 1. each class is compiled in its own class-loader which make the resulting classes not visible from other classes (this has partially been solved but I don't want to bring yet another modular class-loader which greatly complicates things)
   
   What is the current limitation? In what situation could it be possible for people to do it?(Sorry not expert in Quarkus app. ) Do we have an example of how their code would need to have more class loaders?
   
   > 2. dependencies between classes is not taken into account and it will never be so the compilation may fail at runtime if any of your class depend on another class you have added (maybe you are lucky and the order do not unveil the problem but still, it is unpredictable)
   
   Pardon my ignorance, this problem is caused by the previous independent loader issue, right? 
   
   > 3. size of the resulting CR may exceed the limit resources have (bear in mind that all your sources are stored inside etcd)
   
   Yes, we’ll have to define some rules here. 
   
   > 4. consistency with other languages: should we support adding arbitrary js/groovy/kotlin code ?
   
   This probably will need some help from the experts doing these DSL, but most of people I see are doing Java or XML.. (some yaml)
    
   > 5. code is compiled at runtime, so every time the application starts, it will spend some time compiling your code which is not exactly what when your integration needs to quickly scale up
   
   Understood. This could be a warning. 
   > 6. you may miss the option to use native compilation
   > 
   
   Another possible option for users to decide. 
   > That said I can evaluate to re introduce this feature but certainly not in its previous incarnation and you need to help me to shape an UX that do not encourage users to abuse of this capability and does not introduce yet another unmaintainable feature.
   
   From reading the cons, IMHO the biggest problem is the class loaders, which could potentially may cause the application not runnable. Others I would think it’s more like an decision for users to decide. 
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org