<div dir="ltr"><div><div>What I am bit worried about is that this would introduce &quot;development-mode&quot; flags for every subsystem in bit different way.<br></div><div>And we would end up with similar confusion as with runtime statistics stuff we currently have.<br>
</div><div>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.<br></div><div><br>Also if we are making sure that recycling http sessions work then same should work for SFSB &amp; scoped CDI beans (@ApplicationScoped)<br>
<br><br> <br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 31, 2013 at 4:04 PM, Jason Greene <span dir="ltr">&lt;<a href="mailto:jgreene@redhat.com" target="_blank">jgreene@redhat.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I am really not a fan of this big global switch idea.<br>
<br>
First off, a number of things that people enabled with &quot;development&quot; 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.<br>

<br>
Second, development will become an excuse to stick slow performing things in it. You combine that with people hard coding the default, and it&#39;s not long before benchmarks are comparing different app server&#39;s &quot;development mode&quot;.<br>

<br>
On the other hand I could totally see a &quot;show stack traces option&quot; or even &quot;extra diagnostics&quot;.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Jul 31, 2013, at 8:27 AM, Stuart Douglas &lt;<a href="mailto:sdouglas@redhat.com">sdouglas@redhat.com</a>&gt; wrote:<br>
<br>
&gt; 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.<br>

&gt;<br>
&gt; Stuart<br>
&gt;<br>
&gt;<br>
&gt; ----- Original Message -----<br>
&gt;&gt; From: &quot;Tomaž Cerar&quot; &lt;<a href="mailto:tomaz.cerar@gmail.com">tomaz.cerar@gmail.com</a>&gt;<br>
&gt;&gt; To: &quot;Pete Muir&quot; &lt;<a href="mailto:pmuir@redhat.com">pmuir@redhat.com</a>&gt;<br>
&gt;&gt; Cc: <a href="mailto:undertow-dev@lists.jboss.org">undertow-dev@lists.jboss.org</a>, &quot;Max Andersen&quot; &lt;<a href="mailto:manderse@redhat.com">manderse@redhat.com</a>&gt;, &quot;Burr Sutter&quot; &lt;<a href="mailto:bsutter@redhat.com">bsutter@redhat.com</a>&gt;<br>

&gt;&gt; Sent: Wednesday, 31 July, 2013 3:16:30 PM<br>
&gt;&gt; Subject: Re: [undertow-dev] Undertow development mode<br>
&gt;&gt;<br>
&gt;&gt; We need to add this development flag on higher level then just undertow<br>
&gt;&gt; subsystem.<br>
&gt;&gt;<br>
&gt;&gt; It should be server-wide configuration.<br>
&gt;&gt; this would enable also other subsystems to behave differently, like the jsf<br>
&gt;&gt; about forcing jsf/facelets development.<br>
&gt;&gt;<br>
&gt;&gt; maybe we can add this to top level element of server? aka &lt;server<br>
&gt;&gt; xmlns=&quot;urn:jboss:domain:2.0&quot; development-mode=&quot;true&quot;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Max for now this is mgmt configuration for servlet-container but we could<br>
&gt;&gt; easily set default value to be passed from system property.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Wed, Jul 31, 2013 at 2:46 PM, Pete Muir &lt; <a href="mailto:pmuir@redhat.com">pmuir@redhat.com</a> &gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Adding Burr.<br>
&gt;&gt;<br>
&gt;&gt; One idea would be to alter the logging config to log DEBUG messages by<br>
&gt;&gt; default in this mode?<br>
&gt;&gt;<br>
&gt;&gt; On 31 Jul 2013, at 13:12, Max Andersen &lt; <a href="mailto:manderse@redhat.com">manderse@redhat.com</a> &gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;&gt; First off Stuart - can I give you a hug ? This is awesome!<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; How is this flag set ? it should be do able via a startup flag and not<br>
&gt;&gt;&gt; require to invoke some management operation after the startup to be really<br>
&gt;&gt;&gt; useful.<br>
&gt;&gt;&gt; i.e. --dev command line flag.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; In Wildfly upstream I am introducing a &#39;development mode&#39; flag (it is<br>
&gt;&gt;&gt;&gt; actually in Alpha3 as well, but I am going to change how it is<br>
&gt;&gt;&gt;&gt; represented in the model).<br>
&gt;&gt;&gt;&gt; Basically the idea with this is that when this flag is set the server<br>
&gt;&gt;&gt;&gt; behaves in a way that is much more developer friendly, but is not<br>
&gt;&gt;&gt;&gt; suitable for production use. So far the changes are:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; - Set JSP development mode<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Great - so this means Wildfly will recompile .jsp files when changed,<br>
&gt;&gt;&gt; correct ? Anything else ?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; - Display stack traces in error pages. We do not do this by default for<br>
&gt;&gt;&gt;&gt; security reasons.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Cool.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; - Disable caching so file changes are picked up straight away<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Okey - haven&#39;t really noticed caching happening in the past though (except<br>
&gt;&gt;&gt; when VFS was put in front of seam ear&#39;s in AS5 days).<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; - Optionally persist session information across redeployments (still needs<br>
&gt;&gt;&gt;&gt; a little bit of work), which should prevent a developer from having to<br>
&gt;&gt;&gt;&gt; re-log in every time they redeploy.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; AWESOME x infinity!<br>
&gt;&gt;&gt;&gt; I was wondering if anyone had any ideas for other features we could add to<br>
&gt;&gt;&gt;&gt; make development easier?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; JSF/facelets have a development mode too if I recall? maybe that makes<br>
&gt;&gt;&gt; sense too ?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; /max<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; undertow-dev mailing list<br>
&gt;&gt; <a href="mailto:undertow-dev@lists.jboss.org">undertow-dev@lists.jboss.org</a><br>
&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/undertow-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/undertow-dev</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; undertow-dev mailing list<br>
&gt;&gt; <a href="mailto:undertow-dev@lists.jboss.org">undertow-dev@lists.jboss.org</a><br>
&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/undertow-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/undertow-dev</a><br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; undertow-dev mailing list<br>
&gt; <a href="mailto:undertow-dev@lists.jboss.org">undertow-dev@lists.jboss.org</a><br>
&gt; <a href="https://lists.jboss.org/mailman/listinfo/undertow-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/undertow-dev</a><br>
</div></div></blockquote></div><br></div>