[undertow-dev] Undertow development mode

Jason Greene jason.greene at redhat.com
Wed Jul 31 10:42:01 EDT 2013 

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 at redhat.com> 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 at gmail.com
>> <mailto: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
>>> <mailto: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
>>>    <mailto: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
>>>    <mailto:tomaz.cerar at gmail.com>>
>>>>> To: "Pete Muir" <pmuir at redhat.com <mailto:pmuir at redhat.com>>
>>>>> Cc: undertow-dev at lists.jboss.org
>>>    <mailto:undertow-dev at lists.jboss.org>, "Max Andersen"
>>>    <manderse at redhat.com <mailto:manderse at redhat.com>>, "Burr Sutter"
>>>    <bsutter at redhat.com <mailto: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
>>>    <mailto: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
>>>    <mailto: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 <mailto:undertow-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> undertow-dev mailing list
>>>>> undertow-dev at lists.jboss.org <mailto:undertow-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>> 
>>>> _______________________________________________
>>>> undertow-dev mailing list
>>>> undertow-dev at lists.jboss.org <mailto: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
>> 
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> 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

More information about the undertow-dev mailing list