You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Al Maw <wi...@almaw.com> on 2007/05/31 20:04:53 UTC
VOTE: Configuring DEPLOYMENT/DEVELOPMENT mode.
Hi folks,
I've been thinking a lot about this lately.
Current issues:
===============
- We default to DEVELOPMENT and we should make it more obvious that you
should set DEPLOYMENT for production servers.
- We currently provide the following methods to configure which mode
you run in:
- Set a System property.
- Set a servlet context param.
- Set a filter param.
If you don't fit into any of those, it makes life difficult - you
don't want to just call configure(DEPLOYMENT) in your init() method,
because then configure() is called twice - once by Wicket internally,
probably in default DEVELOPMENT mode, and once by you manually. This
results in a bunch of DEVELOPMENT mode stuff running on your live
environment, and it's not that obvious that this is what's going on.
(See WICKET-6, where even JBQ doesn't seem to entirely get this.)
To avoid this, you need to override internalInit(), which is a right
pain, as although the one in WebApplication doesn't do much, the one
in Application does (adds all the component resolvers, etc.) and
you'd need to keep things in sync. Ugh. All the configure() methods
are final, too, so it's not an option to munge the value and then
call super() with it, either.
Proposal:
=========
I think we should have a pull model for this. In other words, we should
make Application#getConfigurationType() abstract and call that to get
the type. We then let people handle this however they want.
Advantages:
- More discoverable as it's an abstract method, like getHomePage().
- Much more flexible for configuration.
- More "Wicket-like".
- Less code for us to maintain.
Disadvantages:
- The 1.3 migration guide gets a little larger. ;-)
Err, can I call a vote on this please?
[ ] Yes, great idea, let's get it into 1.3.0-beta2
[ ] No, that's rubbish, because...
Regards,
Al
--
Alastair Maw
Wicket-biased blog at http://herebebeasties.com
Re: VOTE: Configuring DEPLOYMENT/DEVELOPMENT mode.
Posted by "Philip A. Chapman" <pc...@pcsw.us>.
That was web 0.5 beta wasn't it? :-D
On Fri, 2007-06-01 at 01:53 +0200, Martijn Dashorst wrote:
> Or <marque><blink><font color="red">
>
> Aah... those old web 1.0 days...
>
> Martijn
>
> On 6/1/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > Yeah, good idea. Too bad we can't use <blink> ;)
> >
> > Eelco
> >
> >
> > On 5/31/07, Al Maw <wi...@almaw.com> wrote:
> > > Eelco Hillenius wrote:
> > > >> +1... But just to make sure: is the DEPLOYMENT configuration going to be
> > > >> default?
> > > >
> > > > Nope, DEVELOPMENT is the default (see one of the other threads this week).
> > >
> > > But I'll make the log warning larger while I'm there.
> > >
> > > Something like this should do the trick:
> > >
> > > ********************************************************************
> > > *** WARNING: Wicket is running in DEVELOPMENT mode. ***
> > > *** ^^^^^^^^^^^ ***
> > > *** Do NOT deploy to your live server(s) without changing this. ***
> > > *** See Application#getConfigurationType() for more information. ***
> > > ********************************************************************
> > >
> > > We could even log it to System.err, so Eclipse makes it red. I can't see
> > > any objection to System.err logging in dev mode. If someone deploys in
> > > production their app server admin might even come and clobber them with
> > > a big stick. ;-)
> > >
> > > What do you think?
> > >
> > > Al
> > >
> >
>
>
--
Philip A. Chapman
Desktop and Web Application Development:
Java, .NET, PostgreSQL, MySQL, MSSQL
Linux, Windows 2000, Windows XP
Re: VOTE: Configuring DEPLOYMENT/DEVELOPMENT mode.
Posted by Martijn Dashorst <ma...@gmail.com>.
Or <marque><blink><font color="red">
Aah... those old web 1.0 days...
Martijn
On 6/1/07, Eelco Hillenius <ee...@gmail.com> wrote:
> Yeah, good idea. Too bad we can't use <blink> ;)
>
> Eelco
>
>
> On 5/31/07, Al Maw <wi...@almaw.com> wrote:
> > Eelco Hillenius wrote:
> > >> +1... But just to make sure: is the DEPLOYMENT configuration going to be
> > >> default?
> > >
> > > Nope, DEVELOPMENT is the default (see one of the other threads this week).
> >
> > But I'll make the log warning larger while I'm there.
> >
> > Something like this should do the trick:
> >
> > ********************************************************************
> > *** WARNING: Wicket is running in DEVELOPMENT mode. ***
> > *** ^^^^^^^^^^^ ***
> > *** Do NOT deploy to your live server(s) without changing this. ***
> > *** See Application#getConfigurationType() for more information. ***
> > ********************************************************************
> >
> > We could even log it to System.err, so Eclipse makes it red. I can't see
> > any objection to System.err logging in dev mode. If someone deploys in
> > production their app server admin might even come and clobber them with
> > a big stick. ;-)
> >
> > What do you think?
> >
> > Al
> >
>
--
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.6 contains a very important fix. Download Wicket now!
http://wicketframework.org
Re: VOTE: Configuring DEPLOYMENT/DEVELOPMENT mode.
Posted by Eelco Hillenius <ee...@gmail.com>.
Yeah, good idea. Too bad we can't use <blink> ;)
Eelco
On 5/31/07, Al Maw <wi...@almaw.com> wrote:
> Eelco Hillenius wrote:
> >> +1... But just to make sure: is the DEPLOYMENT configuration going to be
> >> default?
> >
> > Nope, DEVELOPMENT is the default (see one of the other threads this week).
>
> But I'll make the log warning larger while I'm there.
>
> Something like this should do the trick:
>
> ********************************************************************
> *** WARNING: Wicket is running in DEVELOPMENT mode. ***
> *** ^^^^^^^^^^^ ***
> *** Do NOT deploy to your live server(s) without changing this. ***
> *** See Application#getConfigurationType() for more information. ***
> ********************************************************************
>
> We could even log it to System.err, so Eclipse makes it red. I can't see
> any objection to System.err logging in dev mode. If someone deploys in
> production their app server admin might even come and clobber them with
> a big stick. ;-)
>
> What do you think?
>
> Al
>
Re: VOTE: Configuring DEPLOYMENT/DEVELOPMENT mode.
Posted by Al Maw <wi...@almaw.com>.
Eelco Hillenius wrote:
>> +1... But just to make sure: is the DEPLOYMENT configuration going to be
>> default?
>
> Nope, DEVELOPMENT is the default (see one of the other threads this week).
But I'll make the log warning larger while I'm there.
Something like this should do the trick:
********************************************************************
*** WARNING: Wicket is running in DEVELOPMENT mode. ***
*** ^^^^^^^^^^^ ***
*** Do NOT deploy to your live server(s) without changing this. ***
*** See Application#getConfigurationType() for more information. ***
********************************************************************
We could even log it to System.err, so Eclipse makes it red. I can't see
any objection to System.err logging in dev mode. If someone deploys in
production their app server admin might even come and clobber them with
a big stick. ;-)
What do you think?
Al
Re: VOTE: Configuring DEPLOYMENT/DEVELOPMENT mode.
Posted by Eelco Hillenius <ee...@gmail.com>.
> +1... But just to make sure: is the DEPLOYMENT configuration going to be
> default?
Nope, DEVELOPMENT is the default (see one of the other threads this week).
Eelco
Re: VOTE: Configuring DEPLOYMENT/DEVELOPMENT mode.
Posted by Bruno Borges <br...@gmail.com>.
+1... But just to make sure: is the DEPLOYMENT configuration going to be
default?
--
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(11) 8565-7739
(11) 3055-2060
(48) 8404-1300
On 5/31/07, Jean-Baptiste Quenot <jb...@apache.org> wrote:
>
> * Al Maw:
> > - We default to DEVELOPMENT and we should make it more obvious that you
> > should set DEPLOYMENT for production servers.
>
> +1 many people I know deploy their application in DEVELOPMENT
> mode. The Wicket control panel should be visible in development
> mode without the possibility to turn it off, like you mentioned in
> WICKET-599.
>
> > - We currently provide the following methods to configure which mode
> > you run in:
> > - Set a System property.
> > - Set a servlet context param.
> > - Set a filter param.
> >
> > If you don't fit into any of those, it makes life difficult - you
> > don't want to just call configure(DEPLOYMENT) in your init() method,
> > because then configure() is called twice - once by Wicket internally,
> > probably in default DEVELOPMENT mode, and once by you manually. This
> > results in a bunch of DEVELOPMENT mode stuff running on your live
> > environment, and it's not that obvious that this is what's going on.
> > (See WICKET-6, where even JBQ doesn't seem to entirely get this.)
>
> Yes I get it entirely but you didn't mention that in the issue
> description (that configure() is called twice) so it was not very
> clear.
>
> > Err, can I call a vote on this please?
> > [x] Yes, great idea, let's get it into 1.3.0-beta2
> > [ ] No, that's rubbish, because...
>
> +1 for getConfigurationType() with a default implementation for
> backwards compatibility.
> --
> Jean-Baptiste Quenot
> aka John Banana Qwerty
> http://caraldi.com/jbq/
>
Re: VOTE: Configuring DEPLOYMENT/DEVELOPMENT mode.
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* Al Maw:
> - We default to DEVELOPMENT and we should make it more obvious that you
> should set DEPLOYMENT for production servers.
+1 many people I know deploy their application in DEVELOPMENT
mode. The Wicket control panel should be visible in development
mode without the possibility to turn it off, like you mentioned in
WICKET-599.
> - We currently provide the following methods to configure which mode
> you run in:
> - Set a System property.
> - Set a servlet context param.
> - Set a filter param.
>
> If you don't fit into any of those, it makes life difficult - you
> don't want to just call configure(DEPLOYMENT) in your init() method,
> because then configure() is called twice - once by Wicket internally,
> probably in default DEVELOPMENT mode, and once by you manually. This
> results in a bunch of DEVELOPMENT mode stuff running on your live
> environment, and it's not that obvious that this is what's going on.
> (See WICKET-6, where even JBQ doesn't seem to entirely get this.)
Yes I get it entirely but you didn't mention that in the issue
description (that configure() is called twice) so it was not very
clear.
> Err, can I call a vote on this please?
> [x] Yes, great idea, let's get it into 1.3.0-beta2
> [ ] No, that's rubbish, because...
+1 for getConfigurationType() with a default implementation for
backwards compatibility.
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Re: VOTE: Configuring DEPLOYMENT/DEVELOPMENT mode.
Posted by Johan Compagner <jc...@gmail.com>.
yes move the code thats now in internalInit to get the configuration type
to application/webapplication.
Was the proposal that we need to implement it always?
and then do all the things themselfs what we do now?
thats horrible
johan
On 5/31/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> > Proposal:
> > =========
> > I think we should have a pull model for this. In other words, we should
> > make Application#getConfigurationType() abstract and call that to get
> > the type. We then let people handle this however they want.
>
> I'm fine with that method, but why make it abstract? I think it's
> better to provide an implementation, which by default looks for the
> filter parameter and possibly - as an override - the system property.
> If people want to pin the type down, they can override the method and
> return what they like.
>
> Eelco
>
Re: VOTE: Configuring DEPLOYMENT/DEVELOPMENT mode.
Posted by Eelco Hillenius <ee...@gmail.com>.
> Proposal:
> =========
> I think we should have a pull model for this. In other words, we should
> make Application#getConfigurationType() abstract and call that to get
> the type. We then let people handle this however they want.
I'm fine with that method, but why make it abstract? I think it's
better to provide an implementation, which by default looks for the
filter parameter and possibly - as an override - the system property.
If people want to pin the type down, they can override the method and
return what they like.
Eelco
Re: VOTE: Configuring DEPLOYMENT/DEVELOPMENT mode.
Posted by Al Maw <wi...@almaw.com>.
Johan Compagner wrote:
> is fine by me as long as the current stuff keeps working
> like the system property which i use all the time
> because i always set it directly in deployment but in my launch configs i
> set it back with a system property
I guess we could implement a getDefaultConfigurationType() function
which you could delegate to, which would maintain the current
functionality as-is.
So "upgrading"/migrating would be as simple as:
public String getConfigurationType()
{
return getDefaultConfigurationType();
}
But at least it makes it obvious what's going on, and you can ctrl+click
through to the method to see what happens by default. This would be in
the javadoc, obviously.
Regards,
Al
--
Alastair Maw
Wicket-biased blog at http://herebebeasties.com
Re: VOTE: Configuring DEPLOYMENT/DEVELOPMENT mode.
Posted by Johan Compagner <jc...@gmail.com>.
is fine by me as long as the current stuff keeps working
like the system property which i use all the time
because i always set it directly in deployment but in my launch configs i
set it back with a system property
johan
On 5/31/07, Al Maw <wi...@almaw.com> wrote:
>
> Hi folks,
>
> I've been thinking a lot about this lately.
>
> Current issues:
> ===============
> - We default to DEVELOPMENT and we should make it more obvious that you
> should set DEPLOYMENT for production servers.
>
> - We currently provide the following methods to configure which mode
> you run in:
> - Set a System property.
> - Set a servlet context param.
> - Set a filter param.
>
> If you don't fit into any of those, it makes life difficult - you
> don't want to just call configure(DEPLOYMENT) in your init() method,
> because then configure() is called twice - once by Wicket internally,
> probably in default DEVELOPMENT mode, and once by you manually. This
> results in a bunch of DEVELOPMENT mode stuff running on your live
> environment, and it's not that obvious that this is what's going on.
> (See WICKET-6, where even JBQ doesn't seem to entirely get this.)
> To avoid this, you need to override internalInit(), which is a right
> pain, as although the one in WebApplication doesn't do much, the one
> in Application does (adds all the component resolvers, etc.) and
> you'd need to keep things in sync. Ugh. All the configure() methods
> are final, too, so it's not an option to munge the value and then
> call super() with it, either.
>
>
> Proposal:
> =========
> I think we should have a pull model for this. In other words, we should
> make Application#getConfigurationType() abstract and call that to get
> the type. We then let people handle this however they want.
>
> Advantages:
> - More discoverable as it's an abstract method, like getHomePage().
> - Much more flexible for configuration.
> - More "Wicket-like".
> - Less code for us to maintain.
>
> Disadvantages:
> - The 1.3 migration guide gets a little larger. ;-)
>
> Err, can I call a vote on this please?
> [ ] Yes, great idea, let's get it into 1.3.0-beta2
> [ ] No, that's rubbish, because...
>
>
>
> Regards,
>
> Al
>
> --
> Alastair Maw
> Wicket-biased blog at http://herebebeasties.com
>