syncope-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Massimiliano Perrone <massimiliano.perr...@tirasa.net>
Subject Re: ConfigurationLogic behavior
Date Tue, 13 Oct 2015 12:52:53 GMT


Il 13/10/2015 13:03, Francesco Chicchiriccò ha scritto:
> On 13/10/2015 12:50, Massimiliano Perrone wrote:
>> Hi all,
>> I found this "strange" behavior working with ConfigurationService class.
>>
>> When I try to delete a configuration I get always a valid response 
>> also when the configuration key doesn't exist (while I was expecting 
>> a NotFound error).
>> Reading the code I found below difference from (1) ConfigurationLogic 
>> and, for instance, (2) SchemaLogic classes:
>>
>> (1)
>> @PreAuthorize("hasRole('" + Entitlement.CONFIGURATION_DELETE + "')")
>>     public void delete(final String schema) {
>>         confDAO.delete(schema);
>>     }
>>
>> (2)
>> @PreAuthorize("hasRole('" + Entitlement.SCHEMA_DELETE + "')")
>>     public void delete(final SchemaType schemaType, final String 
>> schemaName) {
>>         if (!doesSchemaExist(schemaType, schemaName)) {
>>             throw new NotFoundException(schemaType + "/" + schemaName);
>>         }
>>
>>         switch (schemaType) {
>>             case VIRTUAL:
>>                 virSchemaDAO.delete(schemaName);
>>                 break;
>>
>>             case DERIVED:
>>                 derSchemaDAO.delete(schemaName);
>>                 break;
>>
>>             case PLAIN:
>>             default:
>>                 plainSchemaDAO.delete(schemaName);
>>         }
>>     }
>>
>> As you can read the second class has a control on schema existence, 
>> the first one hasn't.
>> It is the right behavior?
>
> Nice catch: please open an issue - and possibly provide a fix as well 
> if you can; essentially, the method above should become similar to 
> [1]  or [2].

Hi Francesco,
following your suggestion I added the check before the delete operation, 
it seems to work but...

But developing the test for it I found that the exception isn't the 
expected one. As you can read below to catch the exception I added the 
generic Exception class (3) so, printed the class name, I found that it 
is a javax.xml.ws.WebServiceException exception (4).

Furthermore during the CLI development I had to always catch the 
WebServiceException exception but, until now, I thought it was the right 
exception to catch, but now I have some doubts.


(3)
try {
             configurationService.delete("nonExistent");
             fail("NOT POSSIBLE");
         } catch (SyncopeClientException e) {
             assertEquals(Response.Status.NOT_FOUND, 
e.getType().getResponseStatus());
         } catch (Exception e) {
             e.printStackTrace();
             fail(e.getMessage() + " C " + e.getClass());
         }

(4)
java.lang.AssertionError: Remote exception with status code: NOT_FOUND C 
class javax.xml.ws.WebServiceException


>
> Regards.
>
> [1] 
> https://github.com/apache/syncope/blob/master/core/logic/src/main/java/org/apache/syncope/core/logic/RoleLogic.java#L88-L100
> [2] 
> https://github.com/apache/syncope/blob/master/core/logic/src/main/java/org/apache/syncope/core/logic/RealmLogic.java#L85-L96
>

-- 
Massimiliano Perrone
Tel +39 393 9121310

Tirasa S.r.l.
Viale D'Annunzio 267 - 65127 Pescara
Tel +39 0859116307 / FAX +39 0859111173
http://www.tirasa.net

"L'apprendere molte cose non insegna l'intelligenza"
(Eraclito)


Mime
View raw message