On Aug 27, 2010, at 9:58 PM, Bill de hÓra wrote:
> Hi Paul,
>
> thanks! That's interesting - filter(/*).through worked here as well -
> I'll do some digging into what Guice is doing, perhaps it's related to
> this: http://code.google.com/p/google-guice/issues/detail?id=372.
>
Might also be related to:
http://code.google.com/p/google-guice/source/detail?r=1137
http://code.google.com/p/google-guice/issues/detail?id=455
372 and 455 are marked as fixed in the trunk.
But there is another one:
http://code.google.com/p/google-guice/issues/detail?id=522
I wish Guice would have some regular external point releases.
Paul.
> Bill
>
> On Fri, 2010-08-27 at 17:16 +0200, Paul Sandoz wrote:
>> Hi Bill,
>>
>> I can get it to work for the particular case of:
>>
>> @Override
>> protected void configureServlets() {
>> Map<String, String> params = new HashMap<String,
>> String>();
>> params.put(PackagesResourceConfig.PROPERTY_PACKAGES,
>> "com.foo");
>> params.put(ResourceConfig.FEATURE_TRACE, "true");
>>
>> params.put(ServletContainer.FEATURE_FILTER_FORWARD_ON_404, "true");
>>
>> filter("/*").through(GuiceContainer.class, params);
>> }
>>
>> Where there is no path "api" distinguishing between the web page area
>> the the Jersey stuff. See attached.
>>
>> It does not work if i replace the filter with a servlet. Or replace
>> "/
>> *" with "/api/*".
>>
>> I think there may be a bug in Guice when using a request dispatcher
>> to
>> forward.
>>
>> I debugged and verified that the JSPTemplateProcess resolves the JSPs
>> and gets invoked by the ViewableMessageBodyWriter.
>>
>> The code in JSPTemplateProcess is fairly standard stuff:
>>
>> public void writeTo(String resolvedPath, Viewable viewable,
>> OutputStream out) throws IOException {
>> // Commit the status and headers to the HttpServletResponse
>> out.flush();
>>
>> RequestDispatcher d =
>> servletContext.getRequestDispatcher(resolvedPath);
>> if (d == null) {
>> throw new ContainerException("No request dispatcher for:
>> " + resolvedPath);
>> }
>>
>> d = new RequestDispatcherWrapper(d, basePath, hc, viewable);
>>
>> try {
>> d.forward(requestInvoker.get(), responseInvoker.get());
>> } catch (Exception e) {
>> throw new ContainerException(e);
>> }
>> }
>>
>> So the forward is getting swallowed by Guice and i dunno what is
>> happening at that level. Requires more debugging.
>>
>> Paul.
>>
>>
>>
>>
>> On Aug 27, 2010, at 4:02 PM, Bill de hÓra wrote:
>>
>>> Hi,
>>>
>>> I'm having trouble get Viewable JSPs to work in 1.3. All GETs result
>>> in
>>> 404.
>>>
>>> I'm configuring Jersey via Guice as follows
>>>
>>> [[[
>>> public class ResourceBindingModule extends ServletModule
>>> {
>>> public ResourceBindingModule() {
>>> }
>>>
>>> @Override
>>> protected void configureServlets() {
>>> Map<String, String> params = new HashMap<String,
>>> String>();
>>> params.put(PackagesResourceConfig.PROPERTY_PACKAGES,
>>> "com.foo");
>>> params.put(ResourceConfig.FEATURE_TRACE, "true");
>>>
>>> serve("/api/
>>> *").with
>>> (com.sun.jersey.guice.spi.container.servlet.GuiceContainer.class,
>>> params);
>>> }
>>> }
>>> ]]]
>>>
>>> And I've copied in IndexManagementServlet
>>> (http://jersey.576304.n2.nabble.com/problem-with-jsp-Viewable-not-being-evaluated-td4101170.html
>>> ) to test things:
>>>
>>> [[[
>>> @Path("manager")
>>> @Produces({"text/html", "application/xhtml+xml", "application/xml"})
>>> public class IndexManagementServlet {
>>>
>>> @GET
>>> @Path("count")
>>> public Viewable index() {
>>> return new Viewable("/count", "THE MODEL");
>>> }
>>> }
>>> ]]]
>>>
>>> with count.jsp placed where it should be - I can access it directly
>>> as a
>>> JSP. I can see the index() method was found and the Viewable was
>>> matched
>>> to ViewableMessageBodyWriter:
>>>
>>> [[[
>>> HTTP/1.1 404 Not Found
>>> Server: Apache-Coyote/1.1
>>> X-Jersey-Trace-000: accept root resource classes: "/manager/count"
>>> X-Jersey-Trace-001: match path "/manager/count" -> "/application
>>> \.wadl(/.*)?", "/oauth2/foo(/.*)?", "/WebLogout(/.*)?",
>>> "/WebLogin(/.*)?", "/manager(/.*)?", "/account(/.*)?", "/
>>> oauth2(/.*)?",
>>> "/wrap(/.*)?", "(/.*)?"
>>> X-Jersey-Trace-002: accept right hand path
>>> java.util.regex.Matcher[pattern=/manager(/.*)? region=0,14
>>> lastmatch=/manager/count]: "/manager/count" -> "/manager" : "/count"
>>> X-Jersey-Trace-003: accept resource: "manager" -> @Path("/manager")
>>> com.foo.webauth.web.resource.IndexManagementServlet_at_1b0b765
>>> X-Jersey-Trace-004: match path "/count" -> "/count(/)?", ""
>>> X-Jersey-Trace-005: accept right hand path
>>> java.util.regex.Matcher[pattern=/count(/)? region=0,6 lastmatch=/
>>> count]:
>>> "/count" -> "/count" : ""
>>> X-Jersey-Trace-006: accept sub-resource methods: "manager" : "/
>>> count",
>>> GET -> com.foo.webauth.web.resource.IndexManagementServlet_at_1b0b765
>>> X-Jersey-Trace-007: matched sub-resource method: @Path("/count")
>>> public
>>> com.sun.jersey.api.view.Viewable
>>> com.foo.webauth.web.resource.IndexManagementServlet.index()
>>> X-Jersey-Trace-008: matched message body writer:
>>> com.sun.jersey.api.view.Viewable_at_1ddc55f, "text/html" ->
>>> com.sun.jersey.server.impl.template.ViewableMessageBodyWriter_at_354093
>>> Content-Type: text/html;charset=utf-8
>>> Content-Length: 1006
>>> Date: Fri, 27 Aug 2010 13:37:13 GMT
>>> ]]]
>>>
>>> But after that, a 404. Is this something to do with being configured
>>> via
>>> Guice?
>>>
>>> Bill
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>