You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Gaetan <ga...@nereide.fr> on 2024/04/09 15:13:15 UTC
UEL migration
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
Re: UEL migration
Posted by Gaetan <ga...@nereide.fr>.
Good point. I'll start a new thread focused on Tomcat.
On 4/10/24 10:24, Jacques Le Roux wrote:
> Le 10/04/2024 à 09:45, Florian Motteau a écrit :
>> 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).
>
> +1
>
> Jacques
>
Re: UEL migration
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 10/04/2024 à 09:45, Florian Motteau a écrit :
> 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).
+1
Jacques
Re: UEL migration
Posted by Florian Motteau <fl...@motteau-martins.net>.
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
>>>
Re: UEL migration
Posted by Gaetan <ga...@nereide.fr>.
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.
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
>>
Re: UEL migration
Posted by Florian Motteau <fl...@nereide.fr>.
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
>
--
Florian Motteau
Co-entrepreneur Néréide
information@nereide.fr
8 rue des Déportés 37000 TOURS
Std: 02 47 50 30 54
www.nereide.fr
Réseau Libre-Entreprise