Re: [undertow-dev] Undertow development mode

From: "Jason Greene" <jgreene(a)redhat.com&gt; To: "Tomaž Cerar" <tomaz.cerar(a)gmail.com&gt; Cc: "Stuart Douglas" <sdouglas(a)redhat.com&gt;, "Pete Muir" <pmuir(a)redhat.com&gt;, "Burr Sutter" <bsutter(a)redhat.com&gt;, "Max Andersen" <manderse(a)redhat.com&gt;, undertow-dev(a)lists.jboss.org Sent: Wednesday, 31 July, 2013 4:19:26 PM Subject: Re: [undertow-dev] Undertow development mode Yeah I get where you are coming from. What I am getting at is we should be producing a developer friendly production application server, not two servers "development" and "production" which behave completely differently On Jul 31, 2013, at 9:11 AM, Tomaž Cerar <tomaz.cerar(a)gmail.com&gt; wrote: > What I am bit worried about is that this would introduce "development-mode" > flags for every subsystem in bit different way. > And we would end up with similar confusion as with runtime statistics stuff > we currently have. > That would be even worse than having global switch, as people would go to > production with just some dev flags disabled but forgot about others... > much harder to debug / track. > > Also if we are making sure that recycling http sessions work then same > should work for SFSB & scoped CDI beans (@ApplicationScoped) > > > > > > On Wed, Jul 31, 2013 at 4:04 PM, Jason Greene <jgreene(a)redhat.com&gt; wrote: >> I am really not a fan of this big global switch idea. >> >> First off, a number of things that people enabled with "development" mode >> should just work. For example, jsp redeployment should work in either >> case. Being able to recycle sessions is actually useful in production as >> well. >> >> Second, development will become an excuse to stick slow performing things >> in it. You combine that with people hard coding the default, and it's not >> long before benchmarks are comparing different app server's "development >> mode". >> >> On the other hand I could totally see a "show stack traces option" or even >> "extra diagnostics". >> >> >> On Jul 31, 2013, at 8:27 AM, Stuart Douglas <sdouglas(a)redhat.com&gt; wrote: >> >> > Maybe the system property thing I suggested earlier would be enough, so >> > that we can just have in various places subsystems development mode >> > controlled by the jboss.development.mode system property, defaulting to >> > false. >> > >> > Stuart >> > >> > >> > ----- Original Message ----- >> >> From: "Tomaž Cerar" <tomaz.cerar(a)gmail.com&gt; >> >> To: "Pete Muir" <pmuir(a)redhat.com&gt; >> >> Cc: undertow-dev(a)lists.jboss.org, "Max Andersen" <manderse(a)redhat.com&gt;, >> >> "Burr Sutter" <bsutter(a)redhat.com&gt; >> >> Sent: Wednesday, 31 July, 2013 3:16:30 PM >> >> Subject: Re: [undertow-dev] Undertow development mode >> >> >> >> We need to add this development flag on higher level then just undertow >> >> subsystem. >> >> >> >> It should be server-wide configuration. >> >> this would enable also other subsystems to behave differently, like the >> >> jsf >> >> about forcing jsf/facelets development. >> >> >> >> maybe we can add this to top level element of server? aka <server >> >> xmlns="urn:jboss:domain:2.0" development-mode="true"> >> >> >> >> Max for now this is mgmt configuration for servlet-container but we >> >> could >> >> easily set default value to be passed from system property. >> >> >> >> >> >> >> >> On Wed, Jul 31, 2013 at 2:46 PM, Pete Muir < pmuir(a)redhat.com > wrote: >> >> >> >> >> >> Adding Burr. >> >> >> >> One idea would be to alter the logging config to log DEBUG messages by >> >> default in this mode? >> >> >> >> On 31 Jul 2013, at 13:12, Max Andersen < manderse(a)redhat.com > wrote: >> >> >> >>> First off Stuart - can I give you a hug ? This is awesome! >> >>> >> >>> How is this flag set ? it should be do able via a startup flag and not >> >>> require to invoke some management operation after the startup to be >> >>> really >> >>> useful. >> >>> i.e. --dev command line flag. >> >>> >> >>>> In Wildfly upstream I am introducing a 'development mode' flag (it is >> >>>> actually in Alpha3 as well, but I am going to change how it is >> >>>> represented in the model). >> >>>> Basically the idea with this is that when this flag is set the server >> >>>> behaves in a way that is much more developer friendly, but is not >> >>>> suitable for production use. So far the changes are: >> >>>> >> >>>> - Set JSP development mode >> >>> >> >>> Great - so this means Wildfly will recompile .jsp files when changed, >> >>> correct ? Anything else ? >> >>> >> >>>> - Display stack traces in error pages. We do not do this by default >> >>>> for >> >>>> security reasons. >> >>> >> >>> Cool. >> >>> >> >>>> - Disable caching so file changes are picked up straight away >> >>> >> >>> Okey - haven't really noticed caching happening in the past though >> >>> (except >> >>> when VFS was put in front of seam ear's in AS5 days). >> >>> >> >>>> - Optionally persist session information across redeployments (still >> >>>> needs >> >>>> a little bit of work), which should prevent a developer from having >> >>>> to >> >>>> re-log in every time they redeploy. >> >>> >> >>> AWESOME x infinity! >> >>>> I was wondering if anyone had any ideas for other features we could >> >>>> add to >> >>>> make development easier? >> >>> >> >>> JSF/facelets have a development mode too if I recall? maybe that makes >> >>> sense too ? >> >>> >> >>> /max >> >> >> >> >> >> _______________________________________________ >> >> undertow-dev mailing list >> >> undertow-dev(a)lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/undertow-dev >> >> >> >> >> >> _______________________________________________ >> >> undertow-dev mailing list >> >> undertow-dev(a)lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/undertow-dev >> > >> > _______________________________________________ >> > undertow-dev mailing list >> > undertow-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/undertow-dev >