Re: Wicket filter chain and other servlets
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 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 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
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 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
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 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 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 >> 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 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() >> >> >> >> ... >> >> >> >> >> >>at >> >> >> >> >> com.hytrust.proxy.vmware.VIMHandlerServlet.doPost(VIMHandlerServlet.java:47) >> >> >> >> >> >> Any help is appreciated. >> >> Julian >> >> >> > >> > >> > >
Re: Wicket filter chain and other servlets
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 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 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 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() > >> > >> ... > >> > >> > >>at > >> > >> > com.hytrust.proxy.vmware.VIMHandlerServlet.doPost(VIMHandlerServlet.java:47) > >> > >> > >> Any help is appreciated. > >> Julian > >> > > > > >
Re: Wicket filter chain and other servlets
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 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 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() >>> >>> ... >>> >>> >>> at >>> >>> com.hytrust.proxy.vmware.VIMHandlerServlet.doPost(VIMHandlerServlet.java:47) >>> >>> >>> Any help is appreciated. >>> Julian >>> >> >> - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket filter chain and other servlets
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 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 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() >> >> ... >> >> >>at >> >> com.hytrust.proxy.vmware.VIMHandlerServlet.doPost(VIMHandlerServlet.java:47) >> >> >> Any help is appreciated. >> Julian >> > >
Re: Wicket filter chain and other servlets
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 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() > > ... > > >at > > com.hytrust.proxy.vmware.VIMHandlerServlet.doPost(VIMHandlerServlet.java:47) > > > Any help is appreciated. > Julian >
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() ... at com.hytrust.proxy.vmware.VIMHandlerServlet.doPost(VIMHandlerServlet.java:47) Any help is appreciated. Julian
