Paul,
Would it be possible to extend this interface to take relative and
absolute paths so I can more easily get hold of specific classes on the
same server?
interface Resource
{
public <T> getResource(Class<T> input);
// These method will throw a suitable run time exception if the
resource class doesn't match
// ideally the input should be able to be an interface in these cases
// The path is relative to the current resource can also but
absolute with relation to the root
// of the jersey application if the path starts with a "/"
public <T> getResource(Class<T> input, String path);
// For the moment if the URI is for another server then fail
// Ideally if provided with an interface would use client proxying
code.
public <T> getResource(Class<T> input, URI uri);
}
This could really help writing HATEOAS style clients.
Gerard
On 27/11/2009 13:04, Paul Sandoz wrote:
> Hi,
>
> What app server are you using.
>
> It sort of works (see attached for a modification of the helloworld
> web app sample) at least on Tomcat for forward but it blows up with a
> Stack Overflow when include is performed as the resource method that
> invoked the include is recursively called.
>
> However, Jersey is not currently designed to support re-entrant
> requests on the same thread. This is because Jersey does not have a
> concept of a thread local stack or the notion of re-entry so thread
> local variables are not invalidated.
>
> Viewable will not do what you require as that is designed for forward
> to a JSP file.
>
> Could you log an issue?
>
> I think the right approach is to support internal forwarding such that
> either the type or the output stream and you return a Forward type. Or
> inject a RequestInvocationContext class to perform re-entrant requests.
>
> I am not sure that using the design of forwarding is the right
> approach and instead one may design the resource classes for
> appropriate reuse in different contexts without having to make
> re-entrant requests/responses. Of course i could be wrong about this!
> Re-entrant requests are very useful for validating URLs sent by the
> client.
>
>
> There may be a work around. If ResourceB is something you can
> instantiate independently of the path it serves you can get an
> instance by using:
>
> @Context ResourceContext rc;
>
> ...
>
> ResourceB rc = rc.getResource(ResourceB.class);
>
> from which you can call methods on the ResourceB instance.
>
> Note that in 1.1.5-ea-SNAPSHOT you can do the following instead:
>
> @Inject ResourceB rc
>
> Paul.
>
>
>
>
> On Nov 27, 2009, at 1:10 PM, ookigaijin wrote:
>
>>
>> version: 1.1.3-ea
>>
>> Uff, I'm struggling with that one. Basically, there is a resource A
>> with say
>> @Path("resourceA") and all I want to do is to forward/include (either
>> will
>> do for me) to the resourceB @Path("resourceB"). All I need to get
>> hold of is
>> the output stream of the response in the resourceA after the dispatch.
>>
>> in pure servlet way it's an old trivial
>> getRequestDispatcher("/path/to/resource/").include(req,res) or
>> forward().
>>
>> Using @Context HttpServletRequest and getting dispatcher and forwarding
>> works fine to a point. The resource B gets executed allrite, but the
>> forward
>> call never returns, falling into some dodgy internal tangle I suppose
>> that
>> eventually runs JVM out of heap (not even stack).
>> WebApplication.handleRequest gets executed.
>> Viewable, although close, doesn't seem to do the trick.
>>
>> Anyone ever tried that?
>>
>> Cheers,
>> mac
>> --
>> View this message in context:
>> http://n2.nabble.com/Forward-or-include-from-one-resource-to-another-no-JSP-tp4075435p4075435.html
>>
>> Sent from the Jersey mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> 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
--
Gerard Davison | Senior Principal Software Engineer | +44 118 924 5095
Oracle JDeveloper Web Service, Spring, Weblogic SCA Tooling Development
Oracle Corporation UK Ltd is a company incorporated in England& Wales.
Company Reg. No. 1782505.
Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA.
Blog http://kingsfleet.blogspot.com