5

I've googled around a good bit and tried to dig into Jersey source code, but as far as I can tell, Jersey does not support arbitrarily deep nesting of sub resources in conjunction with @Ref annotations.

Here's my set up:

MemberResource.java

@Component // Spring managed
@Scope("prototype")
@Validated
@Path("/member")
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
public class MemberResource extends BaseResource {

    @Autowired // Spring is injecting this sub resource
    private MemberFriendResource memberFriendResource;

    @Path("/{memberId}/friend/")
    public MemberFriendResource getMemberFriendResource() {
        return memberFriendResource;
    }

}

MemberFriendResource.java

@Component // Spring managed
@Scope("prototype")
@Validated
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
public class MemberFriendResource extends BaseResource {

    @GET
    public JResponse<FriendListRepresentation> getAllFriends() {
        // Code
    }


    @GET
    @Path("/recent")
    public JResponse<FriendListRepresentation> getRecentFriends() {
        // Code
    }
}

MemberRepresentation.java

public class MemberRepresentation {
    @Ref(resource=MemberResource.class, method="getMemberFriendResource", bindings = {
    @Binding(name="memberId", value="${instance.id}")
    })
    public URI allFriendsURI;

    @Ref(resource=MemberResource.class, method="??????????", bindings = {
    @Binding(name="memberId", value="${instance.id}")
    })
    public URI recentFriendsURI;
}

I want to have the recentFriendsURI dynamically generated just like the allFriendsURI (which itself does work, just to be clear). I realize that I can manually type out the path, along the lines of @Ref(value="/member/{memberId}/friend/recent", etc), but I would strongly, strongly prefer not to hard code my path strings in every random representation that needs the link.

Is it possible with Jersey to have a URI to a sub resource method injected with variables properly bound using the resource/method paradigm rather than typing out the String path?

I believe this question is trying to achieve a similar, but slightly different result.
This other question is, I think, a more specific form of my question. I'm looking for a solution that doesn't hard code the path and can be arbitrarily deep.

Community
  • 1
  • 1
Patrick
  • 2,672
  • 3
  • 31
  • 47

0 Answers0