You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Julian Sinai <js...@gmail.com> on 2011/08/08 21:14:26 UTC
Wicket filter chain and other servlets
Hi, I really could use some advice on how to solve this problem:
In our webapp, we have a wicket filter as well as a couple of other
servlets. The url pattern for the wicket filter is the usual /*. The problem
is that because of this, all urls, including those of the other servlets, go
through the wicket filter, which is causing problems. Specifically, we are
using spring, so wicket's SpringComponentInjector wraps the beans, which
sometimes results in the exception below.
The real solution is to separate the other servlets into another webapp, but
because of time constraints we can't do that. We also can't easily change
our urls to assign a unique pattern to the wicket urls (although the other
servlets do have unique patterns), because it will adversely affect users.
Is there a way to solve this problem in web.xml? Use wicket servlet instead
of wicket filter?
org.apache.wicket.WicketRuntimeException: There is no application attached to
current thread http-8443-7
at org.apache.wicket.Application.get(Application.java:179)
...
at
WICKET_com.hytrust.arc.TrustedHostMgr$$EnhancerByCGLIB$$eded0a19.refreshAllPolicy(<generated>)
...
at
com.hytrust.proxy.vmware.VIMHandlerServlet.doPost(VIMHandlerServlet.java:47)
Any help is appreciated.
Julian
Re: Wicket filter chain and other servlets
Posted by Dan Retzlaff <dr...@gmail.com>.
You should just be able to see where that TrustedHostMgr variable is coming
from.
On Mon, Aug 8, 2011 at 1:39 PM, Julian Sinai <js...@gmail.com> wrote:
> Dan, thanks for your reply. You may be right, though I can't imagine what
> could be putting the proxy somewhere the servlet can access it. I'll take
> another look. And your suggestion to put a breakpoint in the
> SpringComponentInjector is a good one.
>
> Julian
> On Mon, Aug 8, 2011 at 12:49 PM, Dan Retzlaff <dr...@gmail.com> wrote:
>
> > On second thought, both instantiating a Component and requesting
> injection
> > would blow up immediately without an Application set. So I have to think
> > something in your Wicket application is putting the proxy somewhere the
> > servlet can access it.
> >
> >
>
Re: Wicket filter chain and other servlets
Posted by Julian Sinai <js...@gmail.com>.
Dan, thanks for your reply. You may be right, though I can't imagine what
could be putting the proxy somewhere the servlet can access it. I'll take
another look. And your suggestion to put a breakpoint in the
SpringComponentInjector is a good one.
Julian
On Mon, Aug 8, 2011 at 12:49 PM, Dan Retzlaff <dr...@gmail.com> wrote:
> On second thought, both instantiating a Component and requesting injection
> would blow up immediately without an Application set. So I have to think
> something in your Wicket application is putting the proxy somewhere the
> servlet can access it.
>
>
Re: Wicket filter chain and other servlets
Posted by Dan Retzlaff <dr...@gmail.com>.
On second thought, both instantiating a Component and requesting injection
would blow up immediately without an Application set. So I have to think
something in your Wicket application is putting the proxy somewhere the
servlet can access it.
On Mon, Aug 8, 2011 at 12:46 PM, Dan Retzlaff <dr...@gmail.com> wrote:
> If Wicket doesn't have a mount for a given URL, the WicketFilter doesn't do
> anything more than pass the request through as if it weren't even there. So
> I don't think your problem is filter configuration.
>
> Your non-Wicket servlet is probably instantiating a Wicket component or
> using InjectorHolder.getInjector().inject() in your other servlet. I would
> breakpoint the SpringComponentInject.inject() method to see how it's getting
> called for non-Wicket requests. (Or maybe at startup.)
>
>
> On Mon, Aug 8, 2011 at 12:29 PM, Julian Sinai <js...@gmail.com> wrote:
>
>> Hi Dan
>>
>> I don't understand the reason either, but clearly it's happening. My best
>> guess is what I said in my original post: the non-wicket servlets are
>> going
>> through the wicket filter.
>> Julian
>> On Mon, Aug 8, 2011 at 12:23 PM, Dan Retzlaff <dr...@gmail.com>
>> wrote:
>>
>> > Hi Julian,
>> >
>> > I'm not quite understanding your setup. How did your non-Wicket servlet
>> get
>> > a Wicket-proxied Spring bean?
>> >
>> > Dan
>> >
>> >
>> > On Mon, Aug 8, 2011 at 12:14 PM, Julian Sinai <js...@gmail.com> wrote:
>> >
>> >> Hi, I really could use some advice on how to solve this problem:
>> >>
>> >> In our webapp, we have a wicket filter as well as a couple of other
>> >> servlets. The url pattern for the wicket filter is the usual /*. The
>> >> problem
>> >> is that because of this, all urls, including those of the other
>> servlets,
>> >> go
>> >> through the wicket filter, which is causing problems. Specifically, we
>> are
>> >> using spring, so wicket's SpringComponentInjector wraps the beans,
>> which
>> >> sometimes results in the exception below.
>> >>
>> >> The real solution is to separate the other servlets into another
>> webapp,
>> >> but
>> >> because of time constraints we can't do that. We also can't easily
>> change
>> >> our urls to assign a unique pattern to the wicket urls (although the
>> other
>> >> servlets do have unique patterns), because it will adversely affect
>> users.
>> >> Is there a way to solve this problem in web.xml? Use wicket servlet
>> >> instead
>> >> of wicket filter?
>> >>
>> >> org.apache.wicket.WicketRuntimeException: There is no application
>> attached
>> >> to
>> >> current thread http-8443-7
>> >> at org.apache.wicket.Application.get(Application.java:179)
>> >>
>> >> ...
>> >>
>> >>
>> >> at
>> >>
>> >>
>> WICKET_com.hytrust.arc.TrustedHostMgr$$EnhancerByCGLIB$$eded0a19.refreshAllPolicy(<generated>)
>> >>
>> >> ...
>> >>
>> >>
>> >> at
>> >>
>> >>
>> com.hytrust.proxy.vmware.VIMHandlerServlet.doPost(VIMHandlerServlet.java:47)
>> >>
>> >>
>> >> Any help is appreciated.
>> >> Julian
>> >>
>> >
>> >
>>
>
>
Re: Wicket filter chain and other servlets
Posted by Dan Retzlaff <dr...@gmail.com>.
If Wicket doesn't have a mount for a given URL, the WicketFilter doesn't do
anything more than pass the request through as if it weren't even there. So
I don't think your problem is filter configuration.
Your non-Wicket servlet is probably instantiating a Wicket component or
using InjectorHolder.getInjector().inject() in your other servlet. I would
breakpoint the SpringComponentInject.inject() method to see how it's getting
called for non-Wicket requests. (Or maybe at startup.)
On Mon, Aug 8, 2011 at 12:29 PM, Julian Sinai <js...@gmail.com> wrote:
> Hi Dan
>
> I don't understand the reason either, but clearly it's happening. My best
> guess is what I said in my original post: the non-wicket servlets are going
> through the wicket filter.
> Julian
> On Mon, Aug 8, 2011 at 12:23 PM, Dan Retzlaff <dr...@gmail.com> wrote:
>
> > Hi Julian,
> >
> > I'm not quite understanding your setup. How did your non-Wicket servlet
> get
> > a Wicket-proxied Spring bean?
> >
> > Dan
> >
> >
> > On Mon, Aug 8, 2011 at 12:14 PM, Julian Sinai <js...@gmail.com> wrote:
> >
> >> Hi, I really could use some advice on how to solve this problem:
> >>
> >> In our webapp, we have a wicket filter as well as a couple of other
> >> servlets. The url pattern for the wicket filter is the usual /*. The
> >> problem
> >> is that because of this, all urls, including those of the other
> servlets,
> >> go
> >> through the wicket filter, which is causing problems. Specifically, we
> are
> >> using spring, so wicket's SpringComponentInjector wraps the beans,
> which
> >> sometimes results in the exception below.
> >>
> >> The real solution is to separate the other servlets into another webapp,
> >> but
> >> because of time constraints we can't do that. We also can't easily
> change
> >> our urls to assign a unique pattern to the wicket urls (although the
> other
> >> servlets do have unique patterns), because it will adversely affect
> users.
> >> Is there a way to solve this problem in web.xml? Use wicket servlet
> >> instead
> >> of wicket filter?
> >>
> >> org.apache.wicket.WicketRuntimeException: There is no application
> attached
> >> to
> >> current thread http-8443-7
> >> at org.apache.wicket.Application.get(Application.java:179)
> >>
> >> ...
> >>
> >>
> >> at
> >>
> >>
> WICKET_com.hytrust.arc.TrustedHostMgr$$EnhancerByCGLIB$$eded0a19.refreshAllPolicy(<generated>)
> >>
> >> ...
> >>
> >>
> >> at
> >>
> >>
> com.hytrust.proxy.vmware.VIMHandlerServlet.doPost(VIMHandlerServlet.java:47)
> >>
> >>
> >> Any help is appreciated.
> >> Julian
> >>
> >
> >
>
Re: Wicket filter chain and other servlets
Posted by Martin Funk <ma...@googlemail.com>.
the web.xml might help
Am 08.08.2011 um 21:29 schrieb Julian Sinai:
> Hi Dan
>
> I don't understand the reason either, but clearly it's happening. My best
> guess is what I said in my original post: the non-wicket servlets are going
> through the wicket filter.
> Julian
> On Mon, Aug 8, 2011 at 12:23 PM, Dan Retzlaff <dr...@gmail.com> wrote:
>
>> Hi Julian,
>>
>> I'm not quite understanding your setup. How did your non-Wicket servlet get
>> a Wicket-proxied Spring bean?
>>
>> Dan
>>
>>
>> On Mon, Aug 8, 2011 at 12:14 PM, Julian Sinai <js...@gmail.com> wrote:
>>
>>> Hi, I really could use some advice on how to solve this problem:
>>>
>>> In our webapp, we have a wicket filter as well as a couple of other
>>> servlets. The url pattern for the wicket filter is the usual /*. The
>>> problem
>>> is that because of this, all urls, including those of the other servlets,
>>> go
>>> through the wicket filter, which is causing problems. Specifically, we are
>>> using spring, so wicket's SpringComponentInjector wraps the beans, which
>>> sometimes results in the exception below.
>>>
>>> The real solution is to separate the other servlets into another webapp,
>>> but
>>> because of time constraints we can't do that. We also can't easily change
>>> our urls to assign a unique pattern to the wicket urls (although the other
>>> servlets do have unique patterns), because it will adversely affect users.
>>> Is there a way to solve this problem in web.xml? Use wicket servlet
>>> instead
>>> of wicket filter?
>>>
>>> org.apache.wicket.WicketRuntimeException: There is no application attached
>>> to
>>> current thread http-8443-7
>>> at org.apache.wicket.Application.get(Application.java:179)
>>>
>>> ...
>>>
>>>
>>> at
>>>
>>> WICKET_com.hytrust.arc.TrustedHostMgr$$EnhancerByCGLIB$$eded0a19.refreshAllPolicy(<generated>)
>>>
>>> ...
>>>
>>>
>>> at
>>>
>>> com.hytrust.proxy.vmware.VIMHandlerServlet.doPost(VIMHandlerServlet.java:47)
>>>
>>>
>>> Any help is appreciated.
>>> Julian
>>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket filter chain and other servlets
Posted by Julian Sinai <js...@gmail.com>.
Hi Dan
I don't understand the reason either, but clearly it's happening. My best
guess is what I said in my original post: the non-wicket servlets are going
through the wicket filter.
Julian
On Mon, Aug 8, 2011 at 12:23 PM, Dan Retzlaff <dr...@gmail.com> wrote:
> Hi Julian,
>
> I'm not quite understanding your setup. How did your non-Wicket servlet get
> a Wicket-proxied Spring bean?
>
> Dan
>
>
> On Mon, Aug 8, 2011 at 12:14 PM, Julian Sinai <js...@gmail.com> wrote:
>
>> Hi, I really could use some advice on how to solve this problem:
>>
>> In our webapp, we have a wicket filter as well as a couple of other
>> servlets. The url pattern for the wicket filter is the usual /*. The
>> problem
>> is that because of this, all urls, including those of the other servlets,
>> go
>> through the wicket filter, which is causing problems. Specifically, we are
>> using spring, so wicket's SpringComponentInjector wraps the beans, which
>> sometimes results in the exception below.
>>
>> The real solution is to separate the other servlets into another webapp,
>> but
>> because of time constraints we can't do that. We also can't easily change
>> our urls to assign a unique pattern to the wicket urls (although the other
>> servlets do have unique patterns), because it will adversely affect users.
>> Is there a way to solve this problem in web.xml? Use wicket servlet
>> instead
>> of wicket filter?
>>
>> org.apache.wicket.WicketRuntimeException: There is no application attached
>> to
>> current thread http-8443-7
>> at org.apache.wicket.Application.get(Application.java:179)
>>
>> ...
>>
>>
>> at
>>
>> WICKET_com.hytrust.arc.TrustedHostMgr$$EnhancerByCGLIB$$eded0a19.refreshAllPolicy(<generated>)
>>
>> ...
>>
>>
>> at
>>
>> com.hytrust.proxy.vmware.VIMHandlerServlet.doPost(VIMHandlerServlet.java:47)
>>
>>
>> Any help is appreciated.
>> Julian
>>
>
>
Re: Wicket filter chain and other servlets
Posted by Dan Retzlaff <dr...@gmail.com>.
Hi Julian,
I'm not quite understanding your setup. How did your non-Wicket servlet get
a Wicket-proxied Spring bean?
Dan
On Mon, Aug 8, 2011 at 12:14 PM, Julian Sinai <js...@gmail.com> wrote:
> Hi, I really could use some advice on how to solve this problem:
>
> In our webapp, we have a wicket filter as well as a couple of other
> servlets. The url pattern for the wicket filter is the usual /*. The
> problem
> is that because of this, all urls, including those of the other servlets,
> go
> through the wicket filter, which is causing problems. Specifically, we are
> using spring, so wicket's SpringComponentInjector wraps the beans, which
> sometimes results in the exception below.
>
> The real solution is to separate the other servlets into another webapp,
> but
> because of time constraints we can't do that. We also can't easily change
> our urls to assign a unique pattern to the wicket urls (although the other
> servlets do have unique patterns), because it will adversely affect users.
> Is there a way to solve this problem in web.xml? Use wicket servlet instead
> of wicket filter?
>
> org.apache.wicket.WicketRuntimeException: There is no application attached
> to
> current thread http-8443-7
> at org.apache.wicket.Application.get(Application.java:179)
>
> ...
>
>
> at
>
> WICKET_com.hytrust.arc.TrustedHostMgr$$EnhancerByCGLIB$$eded0a19.refreshAllPolicy(<generated>)
>
> ...
>
>
> at
>
> com.hytrust.proxy.vmware.VIMHandlerServlet.doPost(VIMHandlerServlet.java:47)
>
>
> Any help is appreciated.
> Julian
>