[undertow-dev] Undertow development mode

David M. Lloyd david.lloyd at redhat.com
Wed Jul 31 11:22:37 EDT 2013


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


More information about the undertow-dev mailing list