[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