You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by James Chaplin <jc...@apache.org> on 2020/08/01 14:26:13 UTC

Re: StrutsBoot

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, "info@flyingfischer.ch" <in...@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 <ya...@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-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org