Hi all, Thank you very much to everyone who participated in the discussion.
Since everyone agreed to one of the two options, I have prepared a PR that implements the changes https://github.com/apache/ofbiz-framework/pull/1609 If anyone would like to review the changes, I would be very grateful. Otherwise I am looking to merge the PR in the next few days. Best regards, Konstantinos Marinos On Fri, Jul 31, 2026 at 6:40 AM Ratnesh Upadhyay <[email protected]> wrote: > +1 > > Thanks & Regards, > Ratnesh Upadhyay > > On Thu, 30 Jul 2026 at 15:50, Deepak Dixit <[email protected]> wrote: > > > +1 > > > > Thanks & Regards > > -- > > Deepak Dixit > > ofbiz.apache.org > > > > > > On Thu, Jul 30, 2026 at 3:35 PM Jacopo Cappellato < > > [email protected]> wrote: > > > > > As a side note, one advantage of removing the export=true feature from > > > the rest-api plugin is that it will make the implementation of that > > > plugin simpler (because this feature requires special handling). > > > > > > Jacopo > > > > > > On Thu, Jul 30, 2026 at 10:22 AM Michael Brohl < > [email protected] > > > > > > wrote: > > > > > > > > +1 > > > > > > > > Thanks, > > > > > > > > Michael Brohl > > > > > > > > ecomify GmbH - www.ecomify.de > > > > > > > > > > > > Am 29.07.26 um 09:14 schrieb Mridul Pathak: > > > > > I prefer the first approach. It's better to have a single way to > > > expose any > > > > > service as a REST endpoint through rest.xml. Those already using > the > > > > > current feature will need to migrate anyway. > > > > > > > > > > Thanks > > > > > Mridul Pathak > > > > > > > > > > On Wed, Jul 29, 2026 at 1:29 AM Konstantinos Marinos < > > > [email protected]> > > > > > wrote: > > > > > > > > > >> Hi all, > > > > >> > > > > >> I was hoping to start a discussion about the current interaction > of > > > setting > > > > >> export="true" in a service definition in regards to the recently > > added > > > > >> rest-api module in the framework. The same flag that existed > before > > > > >> (export="true") now additionally exposes a service definition as a > > > REST > > > > >> endpoint. This is one of the ways to create a REST endpoint (the > > other > > > > >> major one being a *.rest.xml definition file) but since the > > component > > > is > > > > >> now part of the framework, this could have unintended > consequences. > > > > >> > > > > >> My biggest concern is that developers might not immediately > realise > > > that > > > > >> this one flag is used for similar but distinct use cases and this > > > might not > > > > >> be the desired behaviour for all new or previously exported > > services. > > > > >> > > > > >> In order to avoid implicitly exposing services with potentially > > > unintended > > > > >> consequences, I am reaching out for your thoughts on the following > > > > >> alternative actions: > > > > >> > > > > >> * We remove the feature of defining REST endpoints in this matter > > > > >> completely. Previously existing usages of export="true" remain > > > unaffected > > > > >> and REST endpoints can be defined by dedicated rest.xml files. > > > > >> > > > > >> * We create a separate flag in the service definition (e.g. > > > > >> export-api="true") that only controls the auto discovery and > > creation > > > of > > > > >> these REST endpoints. The two export features are then decoupled > > from > > > each > > > > >> other and by setting the new flag in the service definition, clear > > > intent > > > > >> is communicated by the developers. > > > > >> > > > > >> What do you think about these two options? > > > > >> > > > > >> If you are already using this feature to create REST endpoints or > > > plan to > > > > >> use it in the future, please let me know as well, as it would mean > > > that the > > > > >> second option has merit and it is the least destructive change of > > the > > > two. > > > > >> > > > > >> Thank you and best regards, > > > > >> Konstantinos Marinos > > > > >> > > > > > > > > -- > > Best Regards, > Ratnesh Upadhyay > > *HotWax Systems* > *Enterprise open source experts* > > http://www.hotwaxsystems.com >
