Wilhelmsen Tor Iver wrote:
>
> The ThreadLocal objects are static, yes, but the actual objects stored
> there are per thread and thus not static.
>
My thoughts exactly
Wilhelmsen Tor Iver wrote:
>
> The Application instance is shared between all users, but in this case
> there is no user st
Reinhard Nägele wrote:
>
> I don't think it is a good idea to have multiple applications in one
> war.
>
Well according to Igor It's not an issue, as wicket-examples makes use of
it. Although it does not use the Servlet but rather the Filter, (don't know
if that could make a difference)
Rein
> I don't think it is a good idea to have multiple applications in one
> war. Wicket stores static state in ThreadLocals (Application, Session,
> etc.).
The ThreadLocal objects are static, yes, but the actual objects stored there
are per thread and thus not static.
> All apps in the same war sh
I don't think it is a good idea to have multiple applications in one
war. Wicket stores static state in ThreadLocals (Application, Session,
etc.). All apps in the same war share the same ClassLoader and thus the
same static ThreadLocal instances. There might be circumstances when the
state some
Oh and I excluded the session code for the simple reason, that I dont think
it is relevant, as it is the applications that get mixed up
fstof wrote:
>
>
> Igor Vaynberg-2 wrote:
>>
>>
>> a reproducible test case :)
>>
>> -igor
>>
>>
>
> If I could reproduce it I'm pretty sure I would hav
Igor Vaynberg-2 wrote:
>
>
> a reproducible test case :)
>
> -igor
>
>
If I could reproduce it I'm pretty sure I would have been able to solve it
:) The thing is It happens like once a week, and we have not seen it happen
in any of our DEV/PRE environments
Zilvinas Vilutis wrote:
>
>
1. No one will steal your non-working code - that's for sure :)
2. Try to explain the scenario in more details. Are you using Spring
Security or just wicket? What brings you to the app after login -
component.continueToOriginalDestination() ?
Žilvinas Vilutis
Mobile: (+370) 652 38353
E-mail:
That is what I noticed when I looked at the code, so I cant really tell why
that could be an issue
We are using WicketServlet because WebSphere 6.1 has issues with the filter
(not 100% sure what the issue is, but it does not work with the filter)
Wilhelmsen Tor Iver wrote:
>
> Any reason you u
> BUMP...
>
>
> Anyone? we run wicket 1.4.9
Any reason you use WicketServlet instead of WicketFilter? We use multiple apps
in a war and that works fine in the filter case. In fact it seems that
WicketServlet delegates to an internal WicketFilter anyway...
- Tor Iver
