> What "fields" are you referring to? fields on VacationDays or fields
> on Employee? or do you mean method parameters?
Fields of the Employee object, yes.
> What "get()" method are you referring to? Employee.get() or
> VacationDays.get()?
The Employee get method.
> I presume your URI path is something like "/employee/1/vacationdays"
> thus the Employee.get() will never be called because the URI
> does not
> point to the correct resource it points to the vacation days resource.
getMatchedResource() returns a list of resource objects with the correct
types involved in the resource path, but not "resolved"; perhaps my
mistake was not invoking get) manually on the Employee object in order
to get the data object the resource represents... My confusion ws
probably triggered by the mistake of having the resource classes extend
the bean classes, which I have dropped now.
> In the method Employee.getVacationDays() do you want to pass
> the value
> of the "id" path param to VacationDays?
Well, I was expecting to find it in the list from getMatchedResources(),
but perhaps I misread the following javadocs:
http://www.jboss.org/file-access/default/members/resteasy/freezone/docs/
1.0.0.GA/javadocs/javax/ws/rs/core/UriInfo.html#getMatchedResources()
The following also seems to indicate that the actual Employee object is
supposed to be resolved first
http://www.jboss.org/file-access/default/members/resteasy/freezone/docs/
1.0.0.GA/userguide/html/JAX-RS_Resource_Locators_and_Sub_Resources.html
Or is this a difference between how Sun and JBoss interpret the spec?
Note: I have not yet tried to plug in RestEasy or CXF instead.
> 2) by reusing @PathParam in the VacationDays.get method:
>
> @GET
> public Response get(@PathParam("id") String id, @Context
> UriInfo info) {
Probably the best approach, yes (though I used constructors) if we later
decide current sub-resources should move elsewhere in the resource
hierarchies.
> In sub-resource locators it is the responsibility of the application
> to instantiate a resource class. Jersey will not inject onto
> constructors or fields of the instance returned.
I was instantiating it, but when it is later used then the resource path
seems absent...
I solved the problem by passing the id down the "pipe" and returning
(thus configured) resource objects in the @Path-annotated methods. So
now I have:
Employees.java: Root resource for /employees, handles queries and {id}
resources
Employee.java: Is the type used for /employees/{id}, id passed in
constructor, handles vacationdays sub-resource, get method returns
EmployeeBean
VacationDays: Type used for Employee's vacationdays, id passed in
constructor, get method returns VacationDaysBean
Thanks for the help! I am getting somewhere now... :)