Oups! I was on a trip the previous week, and I can see now that the issue
has been resolved! Thanks Paul! I'll try to test it. The least I can do as
didn't have time to spend on the custom tag the previous week!
On Tue, Dec 15, 2009 at 13:39, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
> 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.
>>
>>
>>
>
>