Hi Francesco,
I've tried to go the reg-exp route, e.g.:
@RequestMapping(method = RequestMethod.GET, value =
"/deleteByUsername/{username:.*}")
public UserTO delete(@PathVariable final String username)
The username String gets picked up correctly
("[email protected]"). However, I see another error in the
logs:
SEVERE: Servlet.service() for servlet [syncope-core-rest] in context
with path [/syncope] threw exception [Could not resolve view with name
'user/deleteByUsername/delete.by.username@apache' in servlet with name
'syncope-core-rest'] with root cause
javax.servlet.ServletException: Could not resolve view with name
'user/deleteByUsername/delete.by.username@apache' in servlet with name
'syncope-core-rest'
Any ideas?
Colm.
2012/4/6 Francesco Chicchiriccò <[email protected]>:
> On 05/04/2012 17:44, Colm O hEigeartaigh wrote:
>> Actually I've run into a problem when using
>> "/deleteByUsername/{username}", where "username" is an email-address.
>> Spring is truncating the @PathVariable and removing the ".org" at the
>> end of the email address. Any ideas? I tried setting
>> "useDefaultSuffixPattern" to false in the
>> DefaultAnnotationHandlerMapping object defined in restContext.xml, but
>> this seemed to cause other problems.
>
> Yes, because Syncope empowers ".json" and ".xml" Spring views.
>
> What do you think about the regexp solution proposed at
> http://stackoverflow.com/questions/3526523/spring-mvc-pathvariable-getting-truncated
> ?
>
> Cheers.
>
>> On Thu, Apr 5, 2012 at 3:24 PM, Colm O hEigeartaigh <[email protected]>
>> wrote:
>>> Hi Francesco,
>>>
>>>> /read/{userId}
>>>> /readByUsername/{username}
>>>> /delete/{userId}
>>>> /deleteByUsername/{username}
>>> Makes sense - I'll follow your suggestion.
>>>
>>> Colm.
>>>
>>> 2012/4/4 Francesco Chicchiriccò <[email protected]>:
>>>> On 04/04/2012 15:27, Colm O hEigeartaigh wrote:
>>>>> Hi,
>>>>>
>>>>> There is an inconsistency in the REST API as discussed on Syncope-42.
>>>>> For example, both read and delete follow the same pattern for userIds
>>>>> and usernames:
>>>>>
>>>>> - /read/{userId}
>>>>> - /read?username=X
>>>>>
>>>>> Francesco suggested the following:
>>>>>
>>>>>
>>>>> https://issues.apache.org/jira/browse/SYNCOPE-42?focusedCommentId=13245457&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13245457
>>>>>
>>>>> However, the first approach does not seem to work, as he suspected.
>>>>> However, if we move to the latter suggestion, this will cause
>>>>> additional inconsistencies with other methods, such as
>>>>> "user/reactivate/{userId}".
>>>>>
>>>>> /read?userId={userId}
>>>>> /read?username={username}
>>>>> /delete?userId={userId}
>>>>> /delete?username={username}
>>>>>
>>>>> Any suggestions on the best way to proceed?
>>>>
>>>> Hi Colm,
>>>> moving everything to the "request parameter" way (i.e. the latter above)
>>>> can
>>>> have some unexpected side effects on the other 16 REST controllers (besides
>>>> UserController).
>>>>
>>>> I mean, if we decide to change /read/{userId} to /read?userId={userId}, we
>>>> will end up by changing also /read/{notificationId} and so on.
>>>>
>>>> From the other side, keeping the situation as is for UserController leads
>>>> to
>>>> an unacceptable inconsistency, as pointed out by you: hence my proposal is
>>>> to have:
>>>>
>>>> /read/{userId}
>>>> /readByUsername/{username}
>>>> /delete/{userId}
>>>> /deleteByUsername/{username}
>>>>
>>>>
>>>> We can do the same duplication for each REST method taking {userId} as
>>>> parameter.
>>>>
>>>> All this situation only affects UserController, since SyncopeUser is the
>>>> only entity having a primary key (Long id) and a field with UNIQUE NOT NULL
>>>> constraint (String username).
>>>>
>>>> Regards.
> --
> Francesco Chicchiriccò
>
> Apache Cocoon PMC and Apache Syncope PPMC Member
> http://people.apache.org/~ilgrosso/
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
