Hi. My "vote" would also be to preserve XML configuration support for Struts in the future.
Keeping XML configuration as an option, even if a future annotations-based configuration mechanism is introduced, would keep things flexible (and probably make upgrades from older versions less painful). If an annotations-based configuration mechanism is introduced in the future, hopefully it would be possible to "mix-and-match" with XML configuration, based on developer preference. Having a way to map/represent any annotations-based configuration as an XML equivalent (e.g. for debugging) might be useful as well. Regards, James. On 2020/07/08 08:20:05, "i...@flyingfischer.ch" <i...@flyingfischer.ch> wrote: > I second NOT dropping XML configuration support. > > Best > Markus > > Am 08.07.20 um 09:19 schrieb Lukasz Lenart: > > wt., 7 lip 2020 o 16:37 Yasser Zamani <yasserzam...@apache.org> napisaĆ(a): > >> Yes it's awesome and I've also been thought for long time to add boot > >> and auto-config (because I've seen people have concerns about Struts > >> flexibility) but can't find enough time :( wdyt? Looks a huge workload > >> for me. Basically we should get rid off XMLs to annotations, add > >> auto-configs, make plugins better and easier to match each other, and as > >> you mentioned, improve score in benchmarks; to being adapted to modern > >> cloud-native environments I think. > > For now I would like to focus on starting an embedded Jetty. And XML > > is far better than clumsy annotations in your code tbh. At least you > > have all your configuration in one place and not scattered over the > > whole code base. I think we should rather use Java based configuration > > which is already available. Also it would be good to move JSP & tags > > support into a plugin or a dedicated subproject. Having this done, > > Struts2 Core can be a pure Http framework :) > > > > > > Kind regards > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org