[undertow-dev] Undertow development mode

Stuart Douglas sdouglas at redhat.com
Mon Aug 5 03:30:15 EDT 2013


Ok, I will update my PR to be consistent with this, although it may take a little bit of time to implement all the polling functionality. 

Stuart

----- Original Message -----
> From: "Jason Greene" <jason.greene at redhat.com>
> To: "David M. Lloyd" <david.lloyd at redhat.com>
> Cc: undertow-dev at 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 at redhat.com> 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 at redhat.com>
> >>> To: "Tomaž Cerar" <tomaz.cerar at gmail.com>
> >>> Cc: "Stuart Douglas" <sdouglas at redhat.com>, "Pete Muir"
> >>> <pmuir at redhat.com>, "Burr Sutter" <bsutter at redhat.com>, "Max
> >>> Andersen" <manderse at redhat.com>, undertow-dev at 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 at 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 at 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 at 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 at gmail.com>
> >>>>>>> To: "Pete Muir" <pmuir at redhat.com>
> >>>>>>> Cc: undertow-dev at lists.jboss.org, "Max Andersen"
> >>>>>>> <manderse at redhat.com>,
> >>>>>>> "Burr Sutter" <bsutter at 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 at 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 at 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 at lists.jboss.org
> >>>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>>>>>> 
> >>>>>>> 
> >>>>>>> _______________________________________________
> >>>>>>> undertow-dev mailing list
> >>>>>>> undertow-dev at lists.jboss.org
> >>>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>>>>> 
> >>>>>> _______________________________________________
> >>>>>> undertow-dev mailing list
> >>>>>> undertow-dev at lists.jboss.org
> >>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>>> 
> >>> 
> >> 
> >> _______________________________________________
> >> undertow-dev mailing list
> >> undertow-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >> 
> > 
> > 
> > --
> > - DML
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
> 



More information about the undertow-dev mailing list