Matej Knopp wrote:
Hi,
isn't there a better way to detect if applicaiton is being run inside
a portlat than checking for classes from portlet-api on classpath?
At filter or servlet init time? Not that I know...
The only sure way of knowing this is either specifying this through init parameters or delaying the portlet specific initialization until the first portlet
request coming through.
"Hard configuring" to use/initialize for a portlet context through init parameters seems logical, but it makes dual usage of a wicket app war for both portlet
and servlet environment without having to change the web.xml impossible (e.g. like for wicket-examples).
So I'd rather not go that route.
Delayed initialization until the first portlet request can easily be done of course, but I'm not sure of the consequences/side-effects of changing the rendering
strategy that late in the game, after which *servlet* based requests even may already have been served...
Do you have an opinion on this?
If we need to change this (and I agree the current implementation is a bit too
crude), my preference would be the delayed initialization.
Ate
If someone puts portlet-api by accident to classpath, wicket thinks it's
running in portlet environment, which have certain consequences, e.g.
the rendering strategy is REDIRECT_TO_RENDER, which is not really
preferred for non-portlet applications.
-Matej
