6:29 a.m.
----- Original Message -----
From: "Max Andersen" <manderse(a)redhat.com>
To: "Stuart Douglas" <sdouglas(a)redhat.com>
Cc: undertow-dev(a)lists.jboss.org, "Pete Muir" <pmuir(a)redhat.com>
Sent: Tuesday, 6 August, 2013 12:21:08 PM
Subject: Re: Undertow development mode
>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?
+1000
>> >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.
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.
>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?
I think so yes, if it doesn't adds too much overhead (note, I assume you mean
on the exception pages, not on every page?)
It would only add overhead on error, and only if the server was set to display stack
traces.
>> >- 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.
does this mean all content is actually copied somewhere or is just a inmemory
cache ?
In memory, basically it is cached in direct buffers, and if the ServletOutputStream has
not been wrapped Undertow basically has a pass through mechanism to allow them to be
written directly to the NIO Channel.
All of the incremental development stuff we got relies on the server not
caching when things are deployed exploded.
I will fix this in the next undertow release, and hopefully without any performance cost
if you are using JDK7.
Stuart
Actually think some customers uses that feature (doesn't make it right, just
saying its probably used more than you would hope ;)
>> >- 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.
redeploys is the most relevant one for dev mode i would think - but across
restarts would for sure be a nice bonus ;)
>
>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
>>
>>
>>