But don't you run the risk of deploying a development version to
production by mistake?
If you simple start the container in production with the runtime flag,
it will be the same WAR (EAR) for both... no rebuild after testing.
Anyway, I'm sure it works :)
- Brill
On 24-Feb-09, at 12:26 PM,
On Thu, Feb 26, 2009 at 11:11 AM, Brill Pappin br...@pappin.ca wrote:
But don't you run the risk of deploying a development version to production
by mistake?
If you simple start the container in production with the runtime flag, it
will be the same WAR (EAR) for both... no rebuild after
chuckle so have I, as I think most developers have... :)
- Brill
On 26-Feb-09, at 2:18 PM, James Carman wrote:
On Thu, Feb 26, 2009 at 11:11 AM, Brill Pappin br...@pappin.ca
wrote:
But don't you run the risk of deploying a development version to
production
by mistake?
If you simple start
Hi,
It's been a long time since I've written in this mailing list.
Here's my question:
I was looking for a way to set the mode to DEVELOPMENT in the Jetty starter
while setting DEPLOYMENT in the web.xml.
I encountered the following thread:
If you're using Spring, you can set up your application instance in
your spring context and then use a PropertyPlaceholderConfigurer to
substitute in what you want. Wicketopia's archetype uses this method
(along with Maven profiles to choose which property files to include).
On Tue, Feb 24,
I am using tomcat. I just append -Dwicket.configuration=development on
the start script. Perhaps you can append it to the jetty start as
well.
On Tue, Feb 24, 2009 at 8:35 AM, Eyal Golan egola...@gmail.com wrote:
Hi,
It's been a long time since I've written in this mailing list.
Here's my
Thanks Marcelo and James.
I still prefer the solution we have come to:
In the web.xml put deployment and in the Jetty plugin (StartWebServer) put
the development.
My question was why Application.java doesn't have 'wicket.configuration' as
a static field.
Wouldn't it be nice?
Eyal Golan
IMO I like it the way it is because it makes it very simple to change
it at runtime... in your case you simply run jety, adding a param tot
eh comamnd line: eg.
java -Dwicket.configuration=deployment com.jetty.Start
I can do that easily at any time and reconfigure things on various
Already answered the static field thing... but just curious why you
think its better to have modify your source tree just to switch from
dev to prod?
Wouldn't your dev/qa/deploy cycle be simpler if you didn't have to
modify the source?
- Brill pappin
On 24-Feb-09, at 10:49 AM, Eyal Golan
On Tue, Feb 24, 2009 at 7:49 AM, Eyal Golan egola...@gmail.com wrote:
My question was why Application.java doesn't have 'wicket.configuration' as
a static field.
Wouldn't it be nice?
no, it wouldnt be nice. why would you have a name of a *system
property* defined as a public field? the usecase
Brill,
What I did is exactly so we don't need to change the source for dev / prod
environments.
When we develop we use the jetty plugin so we set hard-coded the environment
to DEVELOPMENT.
The production is a WAR (actually an EAR) file.
So the web.xml has configuration set to deployment.
That way
On Tue, Feb 24, 2009 at 11:49 AM, Eyal Golan egola...@gmail.com wrote:
Thanks Marcelo and James.
I still prefer the solution we have come to:
In the web.xml put deployment and in the Jetty plugin (StartWebServer) put
the development.
Thats a best practice AFAIK
My question was why
What do you mean? there is!
public static final String CONFIGURATION = configuration;
(Application.java line 119 on 1.3.5)
Exactly - I was looking for 'wicket.configuration' rather than just
'configuration.
BTW, there is a getConfigurationType() method in WebApplication, which
should not
13 matches
Mail list logo
