Output Wickets Paths, better as a context parameter than servlet init parameter

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Output Wickets Paths, better as a context parameter than servlet init parameter

Wouter Danes-2

Hi,

 

Been playing with the option to output wicket paths from the CMS for selenium testing of CMS functionality.

I ran into an issue: there is no way to externalize servlet initialization parameters without proxying the servlet with some proxy class that delegates.

 

So I propose that we introduce a context parameter which will be checked if the servlet init parameter doesn’t exist. This context parameter can be set from the server.xml, which means that I can build one WAR and define on the environments themselves whether or not to output these paths.

 

So f.ex on D, T and A environments I can turn it on, on Production I can turn it off, but I can build one WAR and deploy it everywhere.

If you all (Frank especially) agree, I can commit some code to make this work.

 

Met vriendelijke groet / Yours sincerely,

 

---

Wouter Danes

Solutions Architect

Hinttech

 

T: +31 6 1158 8264

E: [hidden email]

@wouterdanes

 


_______________________________________________
Hippo-cms7-user mailing list and forums
http://www.onehippo.org/cms7/support/forums.html
Reply | Threaded
Open this post in threaded view
|

Re: Output Wickets Paths, better as a context parameter than servlet init parameter

Frank van Lankvelt
On Fri, Mar 15, 2013 at 2:52 PM, Wouter Danes <[hidden email]> wrote:

> Hi,
>
>
>
> Been playing with the option to output wicket paths from the CMS for
> selenium testing of CMS functionality.
>
> I ran into an issue: there is no way to externalize servlet initialization
> parameters without proxying the servlet with some proxy class that
> delegates.
>
>
>
> So I propose that we introduce a context parameter which will be checked if
> the servlet init parameter doesn’t exist. This context parameter can be set
> from the server.xml, which means that I can build one WAR and define on the
> environments themselves whether or not to output these paths.
>
>
>
> So f.ex on D, T and A environments I can turn it on, on Production I can
> turn it off, but I can build one WAR and deploy it everywhere.
>
> If you all (Frank especially) agree, I can commit some code to make this
> work.
>
>
makes sense; being able to deploy the same war to production that's
used in the integration tests sounds like the right thing to do.

If you can make the implementation backwards compatible then please go ahead.

cheers, Frank

>
> Met vriendelijke groet / Yours sincerely,
>
>
>
> ---
>
> Wouter Danes
>
> Solutions Architect
>
> Hinttech
>
>
>
> T: +31 6 1158 8264
>
> E: [hidden email]
>
> @wouterdanes
>
>
>
>
> _______________________________________________
> Hippo-cms7-user mailing list and forums
> http://www.onehippo.org/cms7/support/forums.html



--
Amsterdam - Oosteinde 11, 1017 WT Amsterdam
Boston - 1 Broadway, Cambridge, MA 02142

US +1 877 414 4776 (toll free)
Europe +31(0)20 522 4466
www.onehippo.com
_______________________________________________
Hippo-cms7-user mailing list and forums
http://www.onehippo.org/cms7/support/forums.html