Re: [Resin-interest] Resin 4.0.33 not dispatching servlet-3.0?
On 12/13/12 3:56 AM, Rick Mann wrote: Hi guys. The .33 snapshot is instantiating my initializer correctly, and that code is calling this: ServletRegistration.Dynamic registration = servletContext.addServlet(servletName, dispatcherServlet); registration.setLoadOnStartup(1); registration.addMapping(new String[/]); That behavior is part of the spec. If the mapping already exists, the addMapping does nothing. It's not an override. I've added a bug report so we might special case the Resin defaults somehow, so those are overridable. -- Scott However, I don't see anything in the Caucho logging indicating that it registered a servlet (not sure if there is anything). I did see this, which doesn't seem right: [12-12-13 03:50:11.038] CONFIG com.caucho.server.dispatch.ServletMapper addUrlMapping: servlet-mapping / - resin-file It also doesn't respond to a request for http://localhost:8080/. I see this much: [12-12-13 03:50:22.636] FINER com.caucho.network.listen.TcpSocketLink requestAccept: TcpSocketLink[id=http://*:8080-5,http://*:8080,INIT] request-accept http://*:8080-5 (count=4, idle=3) [12-12-13 03:50:22.636] FINEST com.caucho.network.listen.TcpSocketLink startThread: TcpSocketLink[id=http://*:8080-5,http://*:8080,INIT] start thread resin-port-8080-22 (count=5, idle=4) [12-12-13 03:50:22.637] FINEST com.caucho.network.listen.TcpSocketLink initSocket: TcpSocketLink[id=1,app-0] starting connection TcpSocketLink[id=http://*:8080-1,http://*:8080,ACCEPT], total=5 [12-12-13 03:50:22.637] FINER com.caucho.network.listen.TcpSocketLink handleAcceptTaskImpl: TcpSocketLink[id=http://*:8080-1,http://*:8080,ACCEPT] accept from [::1]:8080 [12-12-13 03:50:22.645] FINE com.caucho.server.http.HttpRequest parseRequest: Http[app-0, 1] GET / HTTP/1.1 [12-12-13 03:50:22.645] FINE com.caucho.server.http.HttpRequest parseRequest: Http[app-0, 1] Remote-IP: [::1]:8080 [12-12-13 03:50:22.645] FINE com.caucho.server.http.HttpRequest parseHeaders: Http[app-0, 1] Host: localhost:8080 [12-12-13 03:50:22.645] FINE com.caucho.server.http.HttpRequest parseHeaders: Http[app-0, 1] User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/536.26.17 (KHTML, like Gecko) Version/6.0.2 Safari/536.26.17 [12-12-13 03:50:22.645] FINE com.caucho.server.http.HttpRequest parseHeaders: Http[app-0, 1] Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 [12-12-13 03:50:22.646] FINE com.caucho.server.http.HttpRequest parseHeaders: Http[app-0, 1] DNT: 1 [12-12-13 03:50:22.646] FINE com.caucho.server.http.HttpRequest parseHeaders: Http[app-0, 1] Cache-Control: max-age=0 [12-12-13 03:50:22.646] FINE com.caucho.server.http.HttpRequest parseHeaders: Http[app-0, 1] Accept-Language: en-us [12-12-13 03:50:22.646] FINE com.caucho.server.http.HttpRequest parseHeaders: Http[app-0, 1] Accept-Encoding: gzip, deflate [12-12-13 03:50:22.646] FINE com.caucho.server.http.HttpRequest parseHeaders: Http[app-0, 1] Cookie: __utma=111872281.1148524109.1354299737.1354304258.1355118330.3; __utmz=111872281.1354299737.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); JSESSIONID=aaaCemYsZ1z9x6D_VaoUt; uid=1; crucibleprefs1=D%3D1343201447093; remember=rmann:0:cb76f8d95c02b5fae41a3fa0206a927c [12-12-13 03:50:22.647] FINE com.caucho.server.http.HttpRequest parseHeaders: Http[app-0, 1] Connection: keep-alive [12-12-13 03:50:22.651] FINEST com.caucho.server.webapp.WebApp getRealPath: real-path / - /Users/rmann/Projects/Clients/RedBirdStudios/repo/web/trunk/target/build/ [12-12-13 03:50:22.651] FINEST com.caucho.server.webapp.ServletContextImpl getResourceAsStream: java.io.FileNotFoundException: /Users/rmann/Projects/Clients/RedBirdStudios/repo/web/trunk/target/build/ at com.caucho.vfs.JniFilePathImpl.openReadImpl(JniFilePathImpl.java:402) at com.caucho.vfs.Path.openRead(Path.java:1149) at com.caucho.server.webapp.ServletContextImpl.getResourceAsStream(ServletContextImpl.java:404) at com.caucho.server.dispatch.ServletMapper.mapServlet(ServletMapper.java:252) at com.caucho.server.webapp.WebApp.buildInvocation(WebApp.java:3906) at com.caucho.server.webapp.WebAppContainer.buildInvocation(WebAppContainer.java:781) at com.caucho.server.host.Host.buildInvocation(Host.java:752) at com.caucho.server.host.HostContainer.buildInvocation(HostContainer.java:319) at com.caucho.server.cluster.ServletService.buildInvocation(ServletService.java:1014) at com.caucho.server.dispatch.InvocationServer.buildInvocation(InvocationServer.java:247) at
Re: [Resin-interest] Resin 4.0.33 not dispatching servlet-3.0?
On Dec 13, 2012, at 11:32 , Scott Ferguson f...@caucho.com wrote: That behavior is part of the spec. If the mapping already exists, the addMapping does nothing. It's not an override. Wait, really? In my web.xml, I used to have: servlet servlet-nameDispatcher/servlet-name servlet-classorg.springframework.web.servlet.DispatcherServlet/servlet-class init-param param-namecontextConfigLocation/param-name param-value/WEB-INF/config/springWebDispatcherConfig.xml/param-value /init-param load-on-startup3/load-on-startup /servlet servlet-mapping servlet-nameDispatcher/servlet-name url-pattern//url-pattern /servlet-mapping And you're saying that the new hotness doesn't allow me to do that? Or is there a way to avoid the resin mapping? -- Rick ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4.0.33 not dispatching servlet-3.0?
Okay, so it sounds like I'll have to go back to pre-3.0 configuration for the foreseeable future. Hate to say it, because you guys do such great work, but it seems that as currently implemented, resin can't be used as a servlet 3.0 container. Let me ask this: the only URL I really need to run through Spring's DispatcherServet is /service/**. I had been running everything through it so my Spring controllers could handle everything, but I don't need that right now. Should I be able to register it for /service and get what I need? Also, is resin creating that ContextLoaderListener on its own? Sent from my iPhone On Dec 13, 2012, at 12:36, Scott Ferguson f...@caucho.com wrote: On 12/13/12 12:16 PM, Rick Mann wrote: On Dec 13, 2012, at 11:32 , Scott Ferguson f...@caucho.com wrote: That behavior is part of the spec. If the mapping already exists, the addMapping does nothing. It's not an override. Wait, really? In my web.xml, I used to have: ... And you're saying that the new hotness doesn't allow me to do that? Yep, the new spec feature works backwards from Resin's configuration behavior. (No, I don't know why they chose that definition.) Or is there a way to avoid the resin mapping? That's what the bug report would be. We'd have to add some kind of configuration or marker to let Resin's configuration be a lower priority. -- Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4.0.33 not dispatching servlet-3.0?
On 12/13/12 12:49 PM, Rick Mann wrote: Okay, so it sounds like I'll have to go back to pre-3.0 configuration for the foreseeable future. Hate to say it, because you guys do such great work, but it seems that as currently implemented, resin can't be used as a servlet 3.0 container. Let me ask this: the only URL I really need to run through Spring's DispatcherServet is /service/**. I had been running everything through it so my Spring controllers could handle everything, but I don't need that right now. Should I be able to register it for /service and get what I need? Yep. You can use /* as well. It's only exact matches that are rejected, and / exactly matches the default file servlet. Also, is resin creating that ContextLoaderListener on its own? I'm not sure what you mean. -- Scott Sent from my iPhone On Dec 13, 2012, at 12:36, Scott Ferguson f...@caucho.com wrote: On 12/13/12 12:16 PM, Rick Mann wrote: On Dec 13, 2012, at 11:32 , Scott Ferguson f...@caucho.com wrote: That behavior is part of the spec. If the mapping already exists, the addMapping does nothing. It's not an override. Wait, really? In my web.xml, I used to have: ... And you're saying that the new hotness doesn't allow me to do that? Yep, the new spec feature works backwards from Resin's configuration behavior. (No, I don't know why they chose that definition.) Or is there a way to avoid the resin mapping? That's what the bug report would be. We'd have to add some kind of configuration or marker to let Resin's configuration be a lower priority. -- Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
