I thought it was better to have two different deployment and production
profiles/installs.
The production profile would make sure you create all the appropriate
passwords and accounts (i.e. the admin console), generate or import SSL
keys, lock down other security holes (like the stack traces in HTTP
responses), and performance tune as appropriate. Basically not allow
you to boot the App Server until all this information is configured.
Dev profile would have the admin console all set up with a default user.
Have self-signed SSL keys all set up for things like HTTPS. Have
verbose logging of stack traces, etc...
On 7/31/2013 10:11 AM, Tomaž Cerar 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(a)redhat.com
<mailto:jgreene@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(a)redhat.com
<mailto:sdouglas@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(a)gmail.com
<mailto:tomaz.cerar@gmail.com>>
>> To: "Pete Muir" <pmuir(a)redhat.com
<mailto:pmuir@redhat.com>>
>> Cc: undertow-dev(a)lists.jboss.org
<mailto:undertow-dev@lists.jboss.org>, "Max Andersen"
<manderse(a)redhat.com <mailto:manderse@redhat.com>>, "Burr
Sutter"
<bsutter(a)redhat.com <mailto:bsutter@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(a)redhat.com
<mailto:pmuir@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(a)redhat.com
<mailto:manderse@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(a)lists.jboss.org <mailto:undertow-dev@lists.jboss.org>
>>
https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev(a)lists.jboss.org <mailto:undertow-dev@lists.jboss.org>
>>
https://lists.jboss.org/mailman/listinfo/undertow-dev
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org <mailto:undertow-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/undertow-dev
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev