On Dec 15, 2009, at 12:28 PM, Yoryos wrote:
> I think that I've also included a tweaked version of the jersey's
> Servlet class. I modified just the filter method, and used jersey as
> a filter and not a servlet.
Yes.
> I can have a look at it today when I'll get back home. I've played a
> lot with the whole situation and don't really remember witch version
> of the project I've attached.
>
OK.
> At last a forward call on the requestdispatcher will fail if the
> container have send some data to the user already. This means if you
> use the forward method within a jsp it will most likely fail.
I was not using "forward" from within a jsp i was using:
<c:import ... />
from within a JSP referenced in the Viewable returned by a resource
method. Such import statements silently fail for any path.
> For inclusion we you *must* use the include method of the
> requestdispatcher.
>
RequestDispatcherWrapper.include method is never called, at least in
the version of ExtendedJSPTemplateProcessor you attached to the issue:
@Override
public void writeTo(String resolvedPath, Object model,
OutputStream out) throws IOException {
// Commit previous writing
out.flush();
RequestDispatcher d =
servletContext.getRequestDispatcher(resolvedPath);
if (d == null) {
throw new ContainerException("No request dispatcher for:
" + resolvedPath);
}
d = new RequestDispatcherWrapper(d, model, hc);
try {
d.forward(requestInvoker.get(), responseInvoker.get());
} catch (Exception e) {
throw new ContainerException(e);
}
}
This proves at least that when the index.jsp imports that forwarding
works, because otherwise the views would not get processed and included.
> I'll revision the attachment today. Of course If you have anything
> more on that, just include them to have a look!
>
I think i may send something simple in the afternoon to help clarify
things.
Paul.
> Regards,
> Yoryos
>
>
> On Tue, Dec 15, 2009 at 13:06, Paul Sandoz <Paul.Sandoz_at_sun.com>
> wrote:
>
> On Dec 15, 2009, at 11:56 AM, Paul Sandoz wrote:
>
>>
>> On Dec 15, 2009, at 11:15 AM, Yoryos wrote:
>>
>>> Hi again!
>>>
>>> On Tue, Dec 15, 2009 at 11:31, Paul Sandoz <Paul.Sandoz_at_sun.com>
>>> wrote:
>>>
>>> On Dec 14, 2009, at 10:28 PM, Yoryos wrote:
>>>
>>>> Hi Paul,
>>>>
>>>> I will try to create a proof of concept tag.
>>>>
>>>
>>> Thanks, i may try and do some investigations as well today since i
>>> am proposing this. But, i have to fully admit i do not have much
>>> experience writing custom tags!
>>>
>>>
>>> It's been a while since I last had to deal with jsp tags, but they
>>> are not rocket science! I'll look at it when I'll find some free
>>> time. I'm sure it will not be very hard!
>>>
>>
>> OK. I have just played around with your sample and if i do not
>> register your ExtendedJSPTemplateProcessor and modify Jersey's
>> RequestDispatcherWrapper such that the include methods is
>> implemented as follows:
>>
>> public void include(ServletRequest req, ServletResponse rsp)
>> throws ServletException, IOException {
>> ResolvedViewable rv =
>> (ResolvedViewable
>> )hc
>> .getProperties().get("com.sun.jersey.spi.template.ResolvedViewable");
>>
>> req.setAttribute("httpContext", hc);
>> req.setAttribute("resolvingClass", rv.getResolvingClass());
>> req.setAttribute("it", it);
>> req.setAttribute("_basePath", basePath);
>> req.setAttribute("_request", req);
>> req.setAttribute("_response", rsp);
>> d.include(req,rsp);
>> }
>>
>
> Clarification: the above does not actually require any modification
> because Jersey's JSPTemplateProcessor always calls the forward on
> the dispatcher. Thus some tweaks to the ServletContainer.filter
> method may be all that is required.
>
> Paul.
>
>> then i include multiple views in the index.jsp, for example:
>>
>> <h4>Include simpleresource</h4>
>> <c:import url="/simpleresource/" />
>>
>> <h4>Include anotherresource</h4>
>> <c:import url="/anotherresource/" />
>>
>> Then "it" gets resolved correctly for each include.
>>
>> However, if a view is returned from a resource method that includes
>> another view then that include fails, in the sense that nothing is
>> included. I think this is because the ExtendedServletContainer
>> needs to be tweaked to recognize "re-entrant" inclusion so that the
>> ServletContainer.service method is invoked. If that is possible it
>> might well be possible to support layered inclusions without a
>> custom tag.
>>
>> Does that make sense?
>>
>> Would it help if i attach a modified version of your sample?
>>
>>
>>>
>>>> Of course I still think that to be able to name the model is a
>>>> good idea. Maybe I'm affected by the way grails works with the
>>>> model!
>>>>
>>>
>>> Interesting. Do you know what advantages that brings to Grails?
>>>
>>> Well as I said I'm affected. That doesn't mean that there is so
>>> much advantages or there isn't any workaround on this or even that
>>> this is the way it should be. But most times I don't have only one
>>> model per page. This is true for stuff like xml and json responses
>>> but in most cases when dealing with html responses (witch is the
>>> case of most of the webapps) you will have to also include other
>>> resources and use many models per request.
>>>
>>> Of course you can create your jaxrs classes to provide you with
>>> the model you may need (so you can do a it.somemodel) with getters
>>> (and use inheritance and composition for complex pages witch would
>>> need complex model) or create a map with all the stuff you need
>>> and pass this map as a model. You can even then tweak the map
>>> instead of creating new one for other included resources.
>>>
>>> The only problem is that java is not so expressive and a creation
>>> of a map just to pass a model to the view isn't very clean. I mean
>>> consider:
>>>
>>> Map model = new HashMap()
>>> model.put('key1', somevalue1)
>>> model.put('key2', somevalue2)
>>> model.put('key3', somevalue3)
>>> return new Viewable(path, model)
>>>
>>> to the grails/groovy equivalent:
>>> return [key1:somevalue1, key2:somevalue2, key3:somevalue3]
>>>
>>
>> OK. Note that you can use Groovy with JAX-RS and Jersey.
>>
>>
>>> At last I don't find really handy the use of 'it' inside the
>>> views. For example when you have to deal with books in a
>>> bookstore, using BookList as your model name would be really
>>> helpful for anyone reading the jsp to understand that has to
>>> probably deal with a List of Books (List<Book>)
>>>
>>
>> Good point.
>>
>>
>>> Of course I find much more cleaner and easier to use the way
>>> jersey (and generally jaxrs implementation) deal with url mapping
>>> than grails does, and this a reason using it!
>>>
>>> I can understand that these issues doesn't have anything to do
>>> with JAXRS directly, but if someone want to use it as a web
>>> framework and not just an easy way to communicate with xml, I
>>> think that stuff like that matters. By the way am I the only one
>>> that uses jersey as a web framework?
>>>
>>
>> No. I am actually surprised at the level of use given that degree
>> of documentation and time spent on it :-) We have not focused
>> enough resources on this area but i believe it holds a lot of
>> promise.
>>
>>
>>>
>>>
>>> From your initial proposal i understand that model naming is
>>> required so that models from different views do not conflict. If
>>> we can avoid such a conflict by other means then what advantages
>>> would such naming give us?
>>>
>>>
>>> As you can understand it is not a workaround in order for my
>>> initial proposal to work right! It is something that I thing will
>>> help the expressiveness of the view mechanism as is right now.
>>> That doesn't mean that is the way to go. I would really like to
>>> hear opinions from people using the jersey on that. It is not
>>> something that you can't do with it, but I'm sure anyone will
>>> benefit from such an improvement.
>>
>>
>> OK.
>>
>> Paul.
>
>