I think the problem is that the generateSubResource method doesn't
look at resource methods, i.e. it is missing the following block of
code from generateResource:
// for each resource method
Map<String, Param> wadlResourceParams = new HashMap<String,
Param>();
for (AbstractResourceMethod m : r.getResourceMethods()) {
com.sun.research.ws.wadl.Method wadlMethod =
generateMethod(wadlResourceParams, m);
wadlResource.getMethodOrResource().add(wadlMethod);
}
// add parameters that are associated with the resource PATH
template
for (Param wadlParam : wadlResourceParams.values()) {
wadlResource.getParam().add(wadlParam);
}
Probably the best way to tackle this is to add a variant of
generateResource that takes the resource path as a parameter rather
than taking it from the AbstractResource and call that instead.
Marc.
On Jun 11, 2008, at 9:06 AM, Martin Grotzke wrote:
> Hi Marc,
>
> On Tue, 2008-06-10 at 12:45 -0400, Marc Hadley wrote:
>> On Jun 10, 2008, at 12:39 PM, Martin Grotzke wrote:
>>>
>>> I would suggest to first support the most common use case - IMHO
>>> this is
>>> a concrete class that is returned from a sub-resource locator
>>> without
>>> thinking about possibly existing subclasses. This would make lots of
>>> users happy.
>>
>> +1
> Cool :)
>
> Though Paul and other devs didn't vote until now I want to ask if you
> can have a look at the WadlGenerator as I tried to achieve exactly
> this,
> but unfortunately without success [1] ;)
>
> Thanx in advance,
> cheers,
> Martin
>
>
> [1] https://jersey.dev.java.net/servlets/ReadMsg?listName=users&msgNo=1555
>
>
>>
>> Marc.
>>
>>>
>>>>
>>>> E.g. the subresource locator might have a declared return type of
>>>> UserResource but actually return a SuperUserResource (extends
>>>> UserResource) that has extra capabilities.
>>>>
>>>> Marc.
>>>>
>>>>> To me it looks like this:
>>>>> - we have a root resource UsersResource with @Path("/users")
>>>>> - this has a sub-resource locator "UsersResource.getUser" with
>>>>> @Path("{username}") that returns a UserResource
>>>>> - The UserResource has the path "{username}" as context and
>>>>> several
>>>>> resource methods (UserResource.getUser, UserResource.updateUser
>>>>> etc.), sub-resource methods and sub-resource locators.
>>>>>
>>>>> So the UserResource has the context path "/users/{username}" and
>>>>> all
>>>>> resource methods, sub-resource methods and sub-resource locators
>>>>> of
>>>>> the
>>>>> UserResource are related to this path.
>>>>>
>>>>> I'd say we have all information that we need.
>>>>>
>>>>> Why do we not know, what concrete resource classes are returned
>>>>> from a
>>>>> sub-resource locator? UserResource is the return type of the
>>>>> sub-resource locator and seems very concrete to me :)
>>>>>
>>>>> What is the actual problem then? Probably I'm missing s.th. :)
>>>>>
>>>>> Cheers,
>>>>> Martin
>>>>>
>>>>>
>>>>>>
>>>>>> Marc.
>>>>>>
>>>>>> ---
>>>>>> Marc Hadley <marc.hadley at sun.com>
>>>>>> CTO Office, Sun Microsystems.
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>>
>>>>
>>>> ---
>>>> Marc Hadley <marc.hadley at sun.com>
>>>> CTO Office, Sun Microsystems.
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>
>> ---
>> Marc Hadley <marc.hadley at sun.com>
>> CTO Office, Sun Microsystems.
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.