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

- Display stack traces in error pages. We do not do this by default for security reasons.

- Disable caching so file changes are picked up straight away

- 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.

I was wondering if anyone had any ideas for other features we could add to make development easier?

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&gt; 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

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

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

But the ideal behaviour for development and production is different. In development you want stack traces to be displayed, in production mode you don't. In development mode you want changes to your files to show up straight away, in production mode you want to cache as much as possible. You would never run a production server with debugging enabled, but it is very useful for development, and I think this is basically the same thing. Stuart ----- Original Message ----- > 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 >> > _______________________________________________ undertow-dev mailing list undertow-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/undertow-dev

From: "Jason Greene" <jason.greene(a)redhat.com&gt; To: "David M. Lloyd" <david.lloyd(a)redhat.com&gt; Cc: undertow-dev(a)lists.jboss.org Sent: Friday, 2 August, 2013 10:41:32 PM Subject: Re: [undertow-dev] Undertow development mode So I did some more detailed research on this, and my position is still that we should improve usability without requiring modes. Let me go through each item one by one. 1. JSP Development Mode a. Currently does: - Reports detailed compilation errors - Scans for changes to JSP files - Potentially settable *per app* b. What I think we should be doing: - If exploded - JDK7 file change notification service (fallback to polling) - If connection is local[1] - display compilation errors - Provide a global and app setting to set (local-only, always, never) for reporting - Notify the user on a footnote of our default 500 pages how to configure this, perhaps link into the console 2. JSF Development Stage a. Currently does: - Reconfigures your app - HAS NO EFFECT ON FILE SCANNING (it's on regardless of stage) b. What I think we should be doing: - We should never set the JSF development stage, it's a per app setting and should remain so. 3. JSF FACELETS_REFRESH_PERIOD a. Currently does: - Sets an app specific file scan interval - Defaults to 2ms b. What I think we should be doing: - If exploded - JDK7 file change notification service (fallback to polling) 4. Servlet stack traces on HTTP 500 etc a. Currently does: logs them only b. What I think we should be doing: - Add a per app setting and global (local-only[1], always, never) for reporting - Notify the user on a footnote of our default 500 pages how to configure this, perhaps link into the console 5. Server-Based File Caching a. Currently does: - polling or no-polling b. What I think we should be doing: - If exploded/directory based - JDK7 file change notification service (fallback to polling) 6. FS session persistence on shutdown a. Currently does: - AFAIK not existent b. What I think we should be doing: - enable it by default - add an option to disable 7. Admin console authentication a. Currently does: - Requires a login, but guides user on how to create one - Has a ridiculous password policy b. What I think we should be doing: - We should avoid become worm-ware again and keep the login requirement - We should make the policy more forgiving (e.g. "this is a bad password, are you sure?") - In the future, we should look into a web based password creation by cutting and pasting a random token from the log file 8. Application debug logging a. Currently does: - Supports a category specified logging level on the command line - Supports logging in deployment configuration b. What I think we should be doing - Not much more, maybe extra tooling support to help with this. 9. Request dumping a. Currently does: - No dumping b. What I think we should be doing - No dumping, its a lot of data, users should specifically enable what they want to dump [1] Local detection is that the request source address matches a loopback ip address (e.g. 127.0.0.x) and does not contain a X-Forwarded-For value (indicates a proxy/lb) On Jul 31, 2013, at 10:22 AM, David M. Lloyd <david.lloyd(a)redhat.com&gt; wrote: > I agree with Jason on this one. I think there is some value in a > blanket "developer" profile but not enough clearly-defined universal > requirements to justify it being one flag (whose meaning will no doubt > change over time, making it even more unsuitable). > > Bill has a good point that the admin isn't going to know every knob and > switch to turn for development mode. I think that we should tackle this > in two ways: first through a development profile example XML, and second > through documentation. > > Also to Jason's point, many of these features absolutely should not be > developer-only, like JSP and static content change detection; if we have > failed to make these work well for production, we need to try a bit > harder. We do have some options like using a JDK 7 watch service, which > should scale reasonably well for this kind of thing, and for JDK 6 fall > back to something more basic or even disabling it. > > Likewise (for the JDK 6 case) I think we can afford the performance cost > of checking cache timestamps every 10-30s or so. > > I think that yes we want developers to have the convenience of enabling > developer friendly features, but the server really should be developer > friendly in the above ways by default. If someone has a real world > (non-benchmark) case that requires the extra tiny fraction of CPU that > the above changes would cost, then they can explicitly disable these > things. Otherwise they should never even know about them. > > On 07/31/2013 09:22 AM, Stuart Douglas wrote: >> But the ideal behaviour for development and production is different. >> >> In development you want stack traces to be displayed, in production mode >> you don't. In development mode you want changes to your files to show up >> straight away, in production mode you want to cache as much as possible. >> >> You would never run a production server with debugging enabled, but it is >> very useful for development, and I think this is basically the same >> thing. >> >> Stuart >> >> ----- Original Message ----- >>> 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 >>>> >>> >> >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev >> > > > -- > - DML > _______________________________________________ > undertow-dev mailing list > undertow-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat _______________________________________________ undertow-dev mailing list undertow-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/undertow-dev

What's not user friendly is having the admin to know each and every config option that would effect security and performance tuning. Great for generating consultant revenue, but not so user friendly admin-wise. On 7/31/2013 10:19 AM, Jason Greene wrote: > 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 > <mailto:tomaz.cerar@gmail.com>> 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 >> <mailto:jgreene@redhat.com>> 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 >> <mailto:sdouglas@redhat.com>> 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 >> <mailto:tomaz.cerar@gmail.com>> >>>> To: "Pete Muir" <pmuir(a)redhat.com <mailto:pmuir@redhat.com>> >>>> Cc: undertow-dev(a)lists.jboss.org >> <mailto:undertow-dev@lists.jboss.org>, "Max Andersen" >> <manderse(a)redhat.com <mailto:manderse@redhat.com>>, "Burr Sutter" >> <bsutter(a)redhat.com <mailto:bsutter@redhat.com>> >>>> 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 >> <mailto:pmuir@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 >> <mailto:manderse@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 <mailto:undertow-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>>> >>>> >>>> _______________________________________________ >>>> undertow-dev mailing list >>>> undertow-dev(a)lists.jboss.org <mailto:undertow-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>> >>> _______________________________________________ >>> undertow-dev mailing list >>> undertow-dev(a)lists.jboss.org <mailto:undertow-dev@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 > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ undertow-dev mailing list undertow-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/undertow-dev

I certainly agree there. The big problem though is no one agrees what goes into a production profile. As an example some say you must disable the FS scanner, but we have many customers that use it for production. Another example is in EAP we set an arbitrary -Xmx == 1G. That might be right for some apps, not right for others. We probably should rely on ergonomics to properly tune that particular setting. What I have been advocating is that we have shouldn't require lots of tiny tuning. We should have defaults, or auto-tuned/platform tuned values that work very well in all cases (something like ergonomics). On Jul 31, 2013, at 9:28 AM, Bill Burke <bburke(a)redhat.com&gt; wrote: > What's not user friendly is having the admin to know each and every > config option that would effect security and performance tuning. Great > for generating consultant revenue, but not so user friendly admin-wise. > > On 7/31/2013 10:19 AM, Jason Greene wrote: >> 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 >> <mailto:tomaz.cerar@gmail.com>> 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 >>> <mailto:jgreene@redhat.com>> 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 >>> <mailto:sdouglas@redhat.com>> 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 >>> <mailto:tomaz.cerar@gmail.com>> >>>>> To: "Pete Muir" <pmuir(a)redhat.com <mailto:pmuir@redhat.com>> >>>>> Cc: undertow-dev(a)lists.jboss.org >>> <mailto:undertow-dev@lists.jboss.org>, "Max Andersen" >>> <manderse(a)redhat.com <mailto:manderse@redhat.com>>, "Burr Sutter" >>> <bsutter(a)redhat.com <mailto:bsutter@redhat.com>> >>>>> 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 >>> <mailto:pmuir@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 >>> <mailto:manderse@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 <mailto:undertow-dev@lists.jboss.org> >>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> undertow-dev mailing list >>>>> undertow-dev(a)lists.jboss.org <mailto:undertow-dev@lists.jboss.org> >>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>>> >>>> _______________________________________________ >>>> undertow-dev mailing list >>>> undertow-dev(a)lists.jboss.org <mailto:undertow-dev@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 >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > undertow-dev mailing list > undertow-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat

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 <mailto:jgreene@redhat.com>> 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 <mailto:sdouglas@redhat.com>> 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 <mailto:tomaz.cerar@gmail.com>> >> To: "Pete Muir" <pmuir(a)redhat.com <mailto:pmuir@redhat.com>> >> Cc: undertow-dev(a)lists.jboss.org <mailto:undertow-dev@lists.jboss.org>, "Max Andersen" <manderse(a)redhat.com <mailto:manderse@redhat.com>>, "Burr Sutter" <bsutter(a)redhat.com <mailto:bsutter@redhat.com>> >> 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 <mailto:pmuir@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 <mailto:manderse@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 <mailto:undertow-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/undertow-dev >> >> >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev(a)lists.jboss.org <mailto:undertow-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/undertow-dev > > _______________________________________________ > undertow-dev mailing list > undertow-dev(a)lists.jboss.org <mailto:undertow-dev@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

> > 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. The problem is that this is slow, checking timestamps on files is a relatively expensive operation. Considering that the majority of people will not want to change JSP files in production it does not seem like a good idea to make them pay the performance cost.

> Being able to recycle sessions is actually useful in production as well. I disagree. In production you would want to use infinispan clustering, or session passivation to offload sessions to disk when you have a lot of sessions. I do not think there would be much demand for saving sessions across a single server restart (for one thing your site will be down while the restart is happening). The idea of this is to provide a simple, easy to use 'best effort' session persistence, for production grade session persistence customers should be using infinispan.

> > 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". Development mode is always going to be massively slower. For example when serving straight HTML serving straight from a cache can be several times faster than performing a timestamp check and then serving from the cache.

I really don't think we will have any issue with people benchmarking development mode, and I would like to think that 99%+ of developers are smart enough to realise that such a benchmark would be useless. > > On the other hand I could totally see a "show stack traces option" or even > "extra diagnostics". This relies on the user both knowing how to enable these options, and more importantly actually knowing that they are there to be enabled in the first place. With this switch when the user clicks 'start' in JBDS we can make sure they get the best development experience out of the box. Stuart > > > 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 >

From: "Pete Muir" <pmuir(a)redhat.com&gt; To: "Max Andersen" <manderse(a)redhat.com&gt; Cc: "Stuart Douglas" <sdouglas(a)redhat.com&gt;, undertow-dev(a)lists.jboss.org, "Burr Sutter" <bsutter(a)redhat.com&gt; Sent: Wednesday, 31 July, 2013 2:46:40 PM Subject: Re: Undertow development mode 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&gt; 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 > >

Perhaps this is understood but I will state it for clarity purposes... :-) The end-user wants his logging at DEBUG level But the app server itself at INFO (or whatever we deem the default to be).

On Jul 31, 2013, at 9:18 AM, Stuart Douglas wrote: > > > ----- Original Message ----- >> From: "Pete Muir" <pmuir(a)redhat.com&gt; >> To: "Max Andersen" <manderse(a)redhat.com&gt; >> Cc: "Stuart Douglas" <sdouglas(a)redhat.com&gt;, undertow-dev(a)lists.jboss.org, "Burr Sutter" <bsutter(a)redhat.com&gt; >> Sent: Wednesday, 31 July, 2013 2:46:40 PM >> Subject: Re: Undertow development mode >> >> Adding Burr. >> >> One idea would be to alter the logging config to log DEBUG messages by >> default in this mode? > > I think the only issue with this would be that DEBUG can be very verbose, and unless you are chasing down a specific problem it is often not very useful (and makes it more likely that important log messages will not be noticed due to the noise). > > Stuart > >> >> On 31 Jul 2013, at 13:12, Max Andersen <manderse(a)redhat.com&gt; 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 >>> >>> >> >>

On 31/07/2013, at 14.46, Pete Muir <pmuir(a)redhat.com&gt; 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&gt; 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

Unfortunately at the moment this is enabled via a management op, or adding <development-mode/> into standalone.xml (this actually allows you to control which development mode features you want).

What about if I did something like: <development-mode enabled="${jboss.development.mode:false}" /> And had that in the default config, this would allow you to effectively set this via a -D option on the command line?

> >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 ? Nope, this is just the existing JSP development mode setting, its just that it will all be controlled by 1 flag now.

Do you think it would be useful to display additional information in these pages like session contents, request contents etc, sort of like the old seam 2 debug page?

> >- 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). Without this Undertow will cache static resources by default, so if you modify a html page it will not be picked up. We don't check for changes because checking the file timestamp is actually quite a slow operation.

> >- 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! At the moment this only works across redeploys, not restarts, although I should have it working for both fairly soon.

Stuart > > >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 > > >

> >> Great - so this means Wildfly will recompile .jsp files when changed, > >> correct > >> ? Anything else ? > > > >Nope, this is just the existing JSP development mode setting, its just that > >it will all be controlled by 1 flag now. > > dammn - any plans on allowing jsp files to be recompiled when changed ? I actually mean't no, it does not do anything else, the JSP development mode setting should allow JSP's to be recompiled.

> >> >- 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). > > > >Without this Undertow will cache static resources by default, so if you > >modify a html page it will not be picked up. We don't check for changes > >because checking the file timestamp is actually quite a slow operation. > > yikes - didn't realize undertow would do caching that way....:/ I may not be that obvious, because it takes a few hits (usually 5) for Undertow to decide to cache the page. The cache does support expiry due to max age, but at the moment it is disabled in the AS7 integration code. If you are deploying a non-exploded war I think that infinitive time to live makes sense, and will give you best performance. For exploded wars I have started working on a invalidation thing that works using JDK7 watch service, and falls back to polling on JDK6.

From: "Max Andersen" <manderse(a)redhat.com&gt; To: "Stuart Douglas" <sdouglas(a)redhat.com&gt; Cc: undertow-dev(a)lists.jboss.org, "Pete Muir" <pmuir(a)redhat.com&gt; Sent: Wednesday, 31 July, 2013 2:12:12 PM Subject: Re: Undertow development mode 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