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:
us...@infra.apache.org
