Le 10/04/2024 à 09:03, Gaetan a écrit :
Hi Florian ! Thanks for the answer
I agree that migrating Tomcat isn't mandatory for the initial task. It
just feels cleaner that way, so that we don't have two http servers
running in the framework. But it made me think that OFBiz would have
to migrate at some point.
> updating Tomcat is no small thing
Indeed. But now would be as good a time as any ? And i have some time
so spend into it now.
Sure, I just question the fact that this important discussion (updating
tomcat, which leads to a lot of work/implications) occurs via a remote
task. It may need its own thread (updating tomcat : yes ? no ? why ? how
? people insights about this subject).
Your point stays valid though.
On 4/10/24 08:31, Florian Motteau wrote:
Hi Gaetan,
I would ask if using the prometheus java client's embedded http
server is such a bad thing that we need to update OFBiz Tomcat and
face the huge consequences of this update. I'm not fully aware of all
the implications here, but my 2ct would be to reconsider this point,
because updating Tomcat is no small thing, and if i understand
correctly you won't get any added value for your main goal (expose
data).
Beside this, it will still be possible to update your plugin once the
community has updated Tomcat (maybe separate the topics : the plugin,
and the OFBiz Tomcat migration update ?).
Le 09/04/2024 à 17:13, Gaetan a écrit :
Hi everyone. I'm working on UEL engine migration (OFBIZ-12991 [1]).
Why ?
It starts from the idea of creating a Prometheus plugin, allowing to
expose data to grafana. There is a lib that exists in java. [2]
This lib comes with an integrated httpserver but it would be much
cleaner to use the tomcat server already present in OFBiz, but the
java lib uses jakarta, making it imcompatible with Tomcat 9 (the
current version in OFBiz) that still uses javax.
For OFBiz to be able to switch to Tomcat 10, we need to switch to
javax to jakarta.
And OFBiz uses a library for UEL that has had no update in the last
10 years, and still uses javax [3]
The thing is that we still need (IMO) to have custom overrides of
libraries that implements UEL. All UEL implementation cases i saw
still won't allow for auto-vivify. [4] [4bis]
This would prevent some uses of null map keys in XML scripting from
what i understand. I don't know if it's a big change, or regression.
Now my problem is that i don't know how to procede. The work of
migrating the library has been done but not merged (yet ?) [5]
I can't find an other library that would suit the existing code
without having to re-write a lot of code.
I think i understand some of it currently works, but i can't figure
out how to keep going after that.
One possibility would be to see if we can use jakarta vanilla EL [6].
An other possibility could be to have both javax and jakarta (for
some time) to give us some time for migration.
Any thoughts ?
Gaetan
[1] https://issues.apache.org/jira/projects/OFBIZ/issues/OFBIZ-12991
[2] https://github.com/prometheus/client_java
[3] https://mvnrepository.com/artifact/de.odysseus.juel/juel-impl
[4]
https://github.com/apache/ofbiz-framework/blob/6039526c744e1a75e5c40b553de964041f386531/framework/base/src/main/java/org/apache/ofbiz/base/util/string/UelUtil.java#L461
[4bis] https://en.wikipedia.org/wiki/Autovivification
[5] https://github.com/beckchr/juel/pull/104
[6]https://jakarta.ee/specifications/expression-language/4.0/jakarta-expression-language-spec-4.0
PS: Thanks Gil for helping me get some clarity in this VAST subject
