[jira] [Updated] (SYNCOPE-231) Using Standard JAX-RS API in Syncope (Replace Spring Webservice Stack with Apache CXF)
[ https://issues.apache.org/jira/browse/SYNCOPE-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Bernhardt updated SYNCOPE-231: -- Attachment: TaskService.patch I do not understand why this patch (TaskService) breaks UserTestITCase.issueSYNCOPE279() Test... Can someone (smarter than me) support? Using Standard JAX-RS API in Syncope (Replace Spring Webservice Stack with Apache CXF) -- Key: SYNCOPE-231 URL: https://issues.apache.org/jira/browse/SYNCOPE-231 Project: Syncope Issue Type: Improvement Components: console, core Reporter: Jan Bernhardt Assignee: Jan Bernhardt Fix For: 1.2.0 Attachments: TaskService.patch Current REST Interfaces are based on Spring Webservice framework. Goal of this task is to replace Spring with CXF and to relay on JAX-B and JAX-RS annotations rather then Spring annotations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SYNCOPE-275) Upgrade Spring to 3.2
[ https://issues.apache.org/jira/browse/SYNCOPE-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated SYNCOPE-275: --- Fix Version/s: (was: 1.2.0) 1.1.0 Upgrade Spring to 3.2 - Key: SYNCOPE-275 URL: https://issues.apache.org/jira/browse/SYNCOPE-275 Project: Syncope Issue Type: Sub-task Affects Versions: 1.0.4, 1.1.0 Reporter: Francesco Chicchiriccò Fix For: 1.1.0 Spring 3.2.0 has been out for a while now; this new release introduces some non-trivial changes to Spring MVC's content negotiation [1]. SYNCOPE-286 will remove Spring MVC (but will keep the rest of Spring dependencies) so Spring upgrade should be smooth. [1] http://static.springsource.org/spring-framework/docs/3.2.0.RELEASE/spring-framework-reference/html/new-in-3.2.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SYNCOPE-275) Upgrade Spring to 3.2.1
[ https://issues.apache.org/jira/browse/SYNCOPE-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated SYNCOPE-275: --- Description: Spring 3.2.0 has been out for a while now; this new release introduces some non-trivial changes to Spring MVC's content negotiation [1]. However, since 3.2.1 (see [2] fore more details), the upgrading issue from 3.1 is fixed. [1] http://static.springsource.org/spring-framework/docs/3.2.0.RELEASE/spring-framework-reference/html/new-in-3.2.html [2] https://jira.springsource.org/browse/SPR-10119 was: Spring 3.2.0 has been out for a while now; this new release introduces some non-trivial changes to Spring MVC's content negotiation [1]. SYNCOPE-286 will remove Spring MVC (but will keep the rest of Spring dependencies) so Spring upgrade should be smooth. [1] http://static.springsource.org/spring-framework/docs/3.2.0.RELEASE/spring-framework-reference/html/new-in-3.2.html Summary: Upgrade Spring to 3.2.1 (was: Upgrade Spring to 3.2) Upgrade Spring to 3.2.1 --- Key: SYNCOPE-275 URL: https://issues.apache.org/jira/browse/SYNCOPE-275 Project: Syncope Issue Type: Sub-task Affects Versions: 1.0.4, 1.1.0 Reporter: Francesco Chicchiriccò Fix For: 1.1.0 Spring 3.2.0 has been out for a while now; this new release introduces some non-trivial changes to Spring MVC's content negotiation [1]. However, since 3.2.1 (see [2] fore more details), the upgrading issue from 3.1 is fixed. [1] http://static.springsource.org/spring-framework/docs/3.2.0.RELEASE/spring-framework-reference/html/new-in-3.2.html [2] https://jira.springsource.org/browse/SPR-10119 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SYNCOPE-275) Upgrade Spring to 3.2.1
[ https://issues.apache.org/jira/browse/SYNCOPE-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated SYNCOPE-275: --- Issue Type: Improvement (was: Sub-task) Parent: (was: SYNCOPE-285) Upgrade Spring to 3.2.1 --- Key: SYNCOPE-275 URL: https://issues.apache.org/jira/browse/SYNCOPE-275 Project: Syncope Issue Type: Improvement Affects Versions: 1.0.4, 1.1.0 Reporter: Francesco Chicchiriccò Assignee: Francesco Chicchiriccò Fix For: 1.1.0 Spring 3.2.0 has been out for a while now; this new release introduces some non-trivial changes to Spring MVC's content negotiation [1]. However, since 3.2.1 (see [2] fore more details), the upgrading issue from 3.1 is fixed. [1] http://static.springsource.org/spring-framework/docs/3.2.0.RELEASE/spring-framework-reference/html/new-in-3.2.html [2] https://jira.springsource.org/browse/SPR-10119 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SYNCOPE-231) Using Standard JAX-RS API in Syncope (Replace Spring Webservice Stack with Apache CXF)
[ https://issues.apache.org/jira/browse/SYNCOPE-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13562588#comment-13562588 ] Hudson commented on SYNCOPE-231: Integrated in Syncope-trunk #7 (See [https://builds.apache.org/job/Syncope-trunk/7/]) [SYNCOPE-231] * Adding JAX-B Annotations for all missing TO and Enum Type classes (Revision 1438426) [SYNCOPE-231] * Adding ResourceService * Adding JAX-B Annotations * Code cleanup (according to Checkstyle and PMD) (Revision 1438409) Result = SUCCESS jbernhardt : Files : * /syncope/trunk/common/src/main/java/org/apache/syncope/common/to/AbstractExecTO.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/to/LoggerTO.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/to/NotificationTO.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/to/PropagationRequestTO.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/to/ReportExecTO.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/to/ReportTO.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/to/ValidatorTO.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/to/WorkflowDefinitionTO.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/to/WorkflowFormPropertyTO.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/to/WorkflowFormTO.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/types/AuditElements.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/types/AuditLoggerName.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/types/CipherAlgorithm.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/types/ConflictResolutionAction.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/types/ConnParameterType.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/types/ConnectorCapability.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/types/EntityViolationType.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/types/ReportExecExportFormat.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/types/ReportExecStatus.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/types/SyncopeClientExceptionType.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/types/SyncopeLoggerLevel.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/types/SyncopeLoggerType.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/types/WorkflowFormPropertyType.java jbernhardt : Files : * /syncope/trunk/client/src/main/java/org/apache/syncope/client/services/proxy/ResourceServiceProxy.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/services/ResourceService.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/to/MappingItemTO.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/to/MappingTO.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/to/PropagationActionClassTO.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/to/ResourceTO.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/types/IntMappingType.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/util/CollectionWrapper.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/rest/ResourceRestClient.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/rest/TaskRestClient.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/services/ResourceServiceImpl.java * /syncope/trunk/core/src/main/resources/restContext.xml * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/ConnInstanceTestITCase.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/ResourceTestITCase.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/UserTestITCase.java Using Standard JAX-RS API in Syncope (Replace Spring Webservice Stack with Apache CXF) -- Key: SYNCOPE-231 URL: https://issues.apache.org/jira/browse/SYNCOPE-231 Project: Syncope Issue Type: Improvement Components: console, core Reporter: Jan Bernhardt Assignee: Jan Bernhardt Fix For: 1.2.0 Attachments: TaskService.patch Current REST Interfaces are based on Spring Webservice framework. Goal of this task is to replace Spring with CXF and to relay on JAX-B and JAX-RS annotations rather then Spring annotations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more
[jira] [Commented] (SYNCOPE-289) Prepare CXF Rest integration tests migration
[ https://issues.apache.org/jira/browse/SYNCOPE-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13562608#comment-13562608 ] Francesco Chicchiriccò commented on SYNCOPE-289: Prior to latest modifications to org.apache.syncope.core.rest.AbstractTest, I was able to run a specific IT case by running (for example) mvn -Pdev -DwaitForCheck=false -Dit.test=UserTestITCase#issueSYNCOPE279 Now instead I get java.lang.Exception: No tests found matching Method issueSYNCOPE279(org.apache.syncope.core.rest.UserTestITCase) from org.junit.internal.requests.ClassRequest@6740568 Do you have any idea about how to restore the former feature? Prepare CXF Rest integration tests migration Key: SYNCOPE-289 URL: https://issues.apache.org/jira/browse/SYNCOPE-289 Project: Syncope Issue Type: Sub-task Components: console, core Reporter: Andrei Shakirin Assignee: Andrei Shakirin Fix For: 1.1.0 Moving back to 1.1.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SYNCOPE-289) Prepare CXF Rest integration tests migration
[ https://issues.apache.org/jira/browse/SYNCOPE-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13562611#comment-13562611 ] Andrei Shakirin commented on SYNCOPE-289: - I am afraid it cased by @RunWith(Parameterized.class) annotation, was introduced to run all CXF integration tests twice for XML and JSON content type. I will see is it possible somehow to marry this annotation with -Dit.test=... Prepare CXF Rest integration tests migration Key: SYNCOPE-289 URL: https://issues.apache.org/jira/browse/SYNCOPE-289 Project: Syncope Issue Type: Sub-task Components: console, core Reporter: Andrei Shakirin Assignee: Andrei Shakirin Fix For: 1.1.0 Moving back to 1.1.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SYNCOPE-135) Password reset
[ https://issues.apache.org/jira/browse/SYNCOPE-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13562618#comment-13562618 ] Massimiliano Perrone commented on SYNCOPE-135: -- Hi guys, this morning I have examined in details this issue and its effects on the architecture. IMHO password reset is more related to authentication rather than simple identity management (for example an authentication module that returns only one entitlement [possibility to modify password] to authenticated user). So I would link this issue to authentication feature issue (SYNCOPE-160). Massimiliano Password reset -- Key: SYNCOPE-135 URL: https://issues.apache.org/jira/browse/SYNCOPE-135 Project: Syncope Issue Type: New Feature Reporter: Francesco Chicchiriccò Fix For: 1.1.0 Provide password reset feature, that can be accessed either trough the console and via REST call. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SYNCOPE-135) Password reset
[ https://issues.apache.org/jira/browse/SYNCOPE-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13562625#comment-13562625 ] Francesco Chicchiriccò commented on SYNCOPE-135: Agree to move this issue as subtask of SYNCOPE-160: I can hardly imagine to implement general password reset without a deep refactoring in the authentication / authorization mechanisms. Moreover, don't forget that use-case limited password reset can be currently implemented (see an example [1]) at workflow-level. [1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=30738815 Password reset -- Key: SYNCOPE-135 URL: https://issues.apache.org/jira/browse/SYNCOPE-135 Project: Syncope Issue Type: New Feature Reporter: Francesco Chicchiriccò Fix For: 1.1.0 Provide password reset feature, that can be accessed either trough the console and via REST call. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (SYNCOPE-135) Password reset
+1 M On Jan 25, 2013, at 1:23 PM, Francesco Chicchiriccò (JIRA) wrote: [ https://issues.apache.org/jira/browse/SYNCOPE-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13562625#comment-13562625 ] Francesco Chicchiriccò commented on SYNCOPE-135: Agree to move this issue as subtask of SYNCOPE-160: I can hardly imagine to implement general password reset without a deep refactoring in the authentication / authorization mechanisms. Moreover, don't forget that use-case limited password reset can be currently implemented (see an example [1]) at workflow-level. [1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=30738815 Password reset -- Key: SYNCOPE-135 URL: https://issues.apache.org/jira/browse/SYNCOPE-135 Project: Syncope Issue Type: New Feature Reporter: Francesco Chicchiriccò Fix For: 1.1.0 Provide password reset feature, that can be accessed either trough the console and via REST call. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira -- Dott. Marco Di Sabatino Di Diodoro Tel. +39 3939065570 Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 085973 http://www.tirasa.net Apache Syncope PMC Member http://people.apache.org/~mdisabatino
[jira] [Commented] (SYNCOPE-135) Password reset
[ https://issues.apache.org/jira/browse/SYNCOPE-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13562664#comment-13562664 ] Marco Di Sabatino Di Diodoro commented on SYNCOPE-135: -- +1 M -- Dott. Marco Di Sabatino Di Diodoro Tel. +39 3939065570 Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 085973 http://www.tirasa.net Apache Syncope PMC Member http://people.apache.org/~mdisabatino Password reset -- Key: SYNCOPE-135 URL: https://issues.apache.org/jira/browse/SYNCOPE-135 Project: Syncope Issue Type: New Feature Reporter: Francesco Chicchiriccò Fix For: 1.1.0 Provide password reset feature, that can be accessed either trough the console and via REST call. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SYNCOPE-135) Password reset
[ https://issues.apache.org/jira/browse/SYNCOPE-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated SYNCOPE-135: --- Issue Type: Sub-task (was: New Feature) Parent: SYNCOPE-160 Password reset -- Key: SYNCOPE-135 URL: https://issues.apache.org/jira/browse/SYNCOPE-135 Project: Syncope Issue Type: Sub-task Reporter: Francesco Chicchiriccò Fix For: 1.1.0 Provide password reset feature, that can be accessed either trough the console and via REST call. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SYNCOPE-136) Password required for resource subscription
[
https://issues.apache.org/jira/browse/SYNCOPE-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò updated SYNCOPE-136:
---
Description:
Currently, cleartext password is always required when subscribing to a new
external resource.
However, in some cases (for example when passwords are stored with some
symmetric algorithm) this can be avoided.
For example, it could be:
Case 1: 2-way (a.k.a. symmetric) password cipher algorithm is configured in
Syncope
Use decrypted password from SyncopeUser to subscribe new resource.
Case 2: 1-way (a.k.a. hash or asymmetric) password cipher algorithm is
configured in Syncope and no clear-text password is available (for example,
passed via UserMod or provided by a synchronizing resource)
Provide, on a resource-basis, a mean to configure how new password should be
generated:
* constant
* random password generation (compliant with resource password policy, if
present - see SYNCOPE-121)
* provide custom Java class
Discussion thread:
http://syncope-dev.1063484.n5.nabble.com/new-password-issue-td5589622.html
was:
Currently, cleartext password is always required when subscribing to a new
external resource.
However, in some cases (for example when passwords are stored with some
symmetric algorithm) this can be avoided.
For example, it could be:
Case 1: 2-way (a.k.a. symmetric) password cipher algorithm is configured in
Syncope
Use decrypted password from SyncopeUser to subscribe new resource.
Case 2: 1-way (a.k.a. hash or asymmetric) password cipher algorithm is
configured in Syncope and no clear-text password is available (for example,
passed via UserMod or provided by a synchronizing resource)
Provide, on a resource-basis, a mean to configure how new password should be
generated:
* constant@Test
public void issueSYNCOPE122() {
// 1. create user on testdb and testdb2
UserTO userTO = getSampleTO(syncope...@apache.org);
userTO.getResources().clear();
userTO.addResource(resource-testdb);
userTO.addResource(resource-testdb2);
userTO = userService.create(userTO);
assertNotNull(userTO);
assertTrue(userTO.getResources().contains(resource-testdb));
assertTrue(userTO.getResources().contains(resource-testdb2));
final String pwdOnSyncope = userTO.getPassword();
ConnObjectTO userOnDb =
resourceService.getConnector(resource-testdb,
AttributableType.USER, userTO.getUsername());
final AttributeTO pwdOnTestDbAttr =
userOnDb.getAttributeMap().get(OperationalAttributes.PASSWORD_NAME);
assertNotNull(pwdOnTestDbAttr);
assertNotNull(pwdOnTestDbAttr.getValues());
assertFalse(pwdOnTestDbAttr.getValues().isEmpty());
final String pwdOnTestDb =
pwdOnTestDbAttr.getValues().iterator().next();
ConnObjectTO userOnDb2 =
resourceService.getConnector(resource-testdb2,
AttributableType.USER, userTO.getUsername());
final AttributeTO pwdOnTestDb2Attr =
userOnDb2.getAttributeMap().get(OperationalAttributes.PASSWORD_NAME);
assertNotNull(pwdOnTestDb2Attr);
assertNotNull(pwdOnTestDb2Attr.getValues());
assertFalse(pwdOnTestDb2Attr.getValues().isEmpty());
final String pwdOnTestDb2 =
pwdOnTestDb2Attr.getValues().iterator().next();
// 2. request to change password only on testdb (no Syncope, no testdb2)
UserMod userMod = new UserMod();
userMod.setId(userTO.getId());
userMod.setPassword(getUUIDString());
PropagationRequestTO pwdPropRequest = new PropagationRequestTO();
pwdPropRequest.addResource(resource-testdb);
userMod.setPwdPropRequest(pwdPropRequest);
userTO = userService.update(userMod.getId(), userMod);
// 3a. verify that password hasn't changed on Syncope
assertEquals(pwdOnSyncope, userTO.getPassword());
// 3b. verify that password *has* changed on testdb
userOnDb = resourceService.getConnector(resource-testdb,
AttributableType.USER, userTO.getUsername());
final AttributeTO pwdOnTestDbAttrAfter =
userOnDb.getAttributeMap().get(OperationalAttributes.PASSWORD_NAME);
assertNotNull(pwdOnTestDbAttrAfter);
assertNotNull(pwdOnTestDbAttrAfter.getValues());
assertFalse(pwdOnTestDbAttrAfter.getValues().isEmpty());
assertNotEquals(pwdOnTestDb,
pwdOnTestDbAttrAfter.getValues().iterator().next());
// 3c. verify that password hasn't changed on testdb2
userOnDb2 = resourceService.getConnector(resource-testdb2,
AttributableType.USER, userTO.getUsername());
final AttributeTO pwdOnTestDb2AttrAfter =
userOnDb2.getAttributeMap().get(OperationalAttributes.PASSWORD_NAME);
assertNotNull(pwdOnTestDb2AttrAfter);
assertNotNull(pwdOnTestDb2AttrAfter.getValues());
[jira] [Updated] (SYNCOPE-136) Password required for resource subscription
[
https://issues.apache.org/jira/browse/SYNCOPE-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò updated SYNCOPE-136:
---
Description:
Currently, cleartext password is always required when subscribing to a new
external resource.
However, in some cases (for example when passwords are stored with some
symmetric algorithm) this can be avoided.
For example, it could be:
Case 1: 2-way (a.k.a. symmetric) password cipher algorithm is configured in
Syncope
Use decrypted password from SyncopeUser to subscribe new resource.
Case 2: 1-way (a.k.a. hash or asymmetric) password cipher algorithm is
configured in Syncope and no clear-text password is available (for example,
passed via UserMod or provided by a synchronizing resource)
Provide, on a resource-basis, a mean to configure how new password should be
generated:
* constant@Test
public void issueSYNCOPE122() {
// 1. create user on testdb and testdb2
UserTO userTO = getSampleTO(syncope...@apache.org);
userTO.getResources().clear();
userTO.addResource(resource-testdb);
userTO.addResource(resource-testdb2);
userTO = userService.create(userTO);
assertNotNull(userTO);
assertTrue(userTO.getResources().contains(resource-testdb));
assertTrue(userTO.getResources().contains(resource-testdb2));
final String pwdOnSyncope = userTO.getPassword();
ConnObjectTO userOnDb =
resourceService.getConnector(resource-testdb,
AttributableType.USER, userTO.getUsername());
final AttributeTO pwdOnTestDbAttr =
userOnDb.getAttributeMap().get(OperationalAttributes.PASSWORD_NAME);
assertNotNull(pwdOnTestDbAttr);
assertNotNull(pwdOnTestDbAttr.getValues());
assertFalse(pwdOnTestDbAttr.getValues().isEmpty());
final String pwdOnTestDb =
pwdOnTestDbAttr.getValues().iterator().next();
ConnObjectTO userOnDb2 =
resourceService.getConnector(resource-testdb2,
AttributableType.USER, userTO.getUsername());
final AttributeTO pwdOnTestDb2Attr =
userOnDb2.getAttributeMap().get(OperationalAttributes.PASSWORD_NAME);
assertNotNull(pwdOnTestDb2Attr);
assertNotNull(pwdOnTestDb2Attr.getValues());
assertFalse(pwdOnTestDb2Attr.getValues().isEmpty());
final String pwdOnTestDb2 =
pwdOnTestDb2Attr.getValues().iterator().next();
// 2. request to change password only on testdb (no Syncope, no testdb2)
UserMod userMod = new UserMod();
userMod.setId(userTO.getId());
userMod.setPassword(getUUIDString());
PropagationRequestTO pwdPropRequest = new PropagationRequestTO();
pwdPropRequest.addResource(resource-testdb);
userMod.setPwdPropRequest(pwdPropRequest);
userTO = userService.update(userMod.getId(), userMod);
// 3a. verify that password hasn't changed on Syncope
assertEquals(pwdOnSyncope, userTO.getPassword());
// 3b. verify that password *has* changed on testdb
userOnDb = resourceService.getConnector(resource-testdb,
AttributableType.USER, userTO.getUsername());
final AttributeTO pwdOnTestDbAttrAfter =
userOnDb.getAttributeMap().get(OperationalAttributes.PASSWORD_NAME);
assertNotNull(pwdOnTestDbAttrAfter);
assertNotNull(pwdOnTestDbAttrAfter.getValues());
assertFalse(pwdOnTestDbAttrAfter.getValues().isEmpty());
assertNotEquals(pwdOnTestDb,
pwdOnTestDbAttrAfter.getValues().iterator().next());
// 3c. verify that password hasn't changed on testdb2
userOnDb2 = resourceService.getConnector(resource-testdb2,
AttributableType.USER, userTO.getUsername());
final AttributeTO pwdOnTestDb2AttrAfter =
userOnDb2.getAttributeMap().get(OperationalAttributes.PASSWORD_NAME);
assertNotNull(pwdOnTestDb2AttrAfter);
assertNotNull(pwdOnTestDb2AttrAfter.getValues());
assertFalse(pwdOnTestDb2AttrAfter.getValues().isEmpty());
assertEquals(pwdOnTestDb2,
pwdOnTestDb2AttrAfter.getValues().iterator().next());
}
}
* random password generation (compliant with resource password policy, if
present - see SYNCOPE-121)
* provide custom Java class
Discussion thread:
http://syncope-dev.1063484.n5.nabble.com/new-password-issue-td5589622.html
was:
Currently, cleartext password is always required when subscribing to a new
external resource.
However, in some cases (for example when passwords are stored with some
symmetric algorithm) this can be avoided.
For example, it could be:
Case 1: 2-way (a.k.a. symmetric) password cipher algorithm is configured in
Syncope
Use decrypted password from SyncopeUser to subscribe new resource.
Case 2: 1-way (a.k.a. hash or asymmetric) password cipher algorithm is
configured in Syncope and no clear-text password is available (for example,
passed via UserMod or provided by a
[jira] [Commented] (SYNCOPE-231) Using Standard JAX-RS API in Syncope (Replace Spring Webservice Stack with Apache CXF)
[ https://issues.apache.org/jira/browse/SYNCOPE-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13562732#comment-13562732 ] Hudson commented on SYNCOPE-231: Integrated in Syncope-trunk #9 (See [https://builds.apache.org/job/Syncope-trunk/9/]) [SYNCOPE-231] * RoleService (Revision 1438530) [SYNCOPE-231] * Adding RoleService (Revision 1438507) Result = SUCCESS jbernhardt : Files : * /syncope/trunk/client/src/main/java/org/apache/syncope/client/services/proxy/RoleServiceProxy.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/rest/RoleRestClient.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/services/RoleServiceImpl.java jbernhardt : Files : * /syncope/trunk/client/src/main/java/org/apache/syncope/client/services/proxy/RoleServiceProxy.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/services/RoleService.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/SyncopeSession.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/rest/RoleRestClient.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/AuthenticationTestITCase.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/NotificationTestITCase.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/RoleTestITCase.java Using Standard JAX-RS API in Syncope (Replace Spring Webservice Stack with Apache CXF) -- Key: SYNCOPE-231 URL: https://issues.apache.org/jira/browse/SYNCOPE-231 Project: Syncope Issue Type: Improvement Components: console, core Reporter: Jan Bernhardt Assignee: Jan Bernhardt Fix For: 1.2.0 Attachments: TaskService.patch Current REST Interfaces are based on Spring Webservice framework. Goal of this task is to replace Spring with CXF and to relay on JAX-B and JAX-RS annotations rather then Spring annotations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SYNCOPE-290) Typed SyncopeConf
Francesco Chicchiriccò created SYNCOPE-290: -- Summary: Typed SyncopeConf Key: SYNCOPE-290 URL: https://issues.apache.org/jira/browse/SYNCOPE-290 Project: Syncope Issue Type: Improvement Reporter: Francesco Chicchiriccò Fix For: 1.2.0 Currently SyncopeConf instances are String, String pairs: this has of course various drawbacks (no check for mandatory values, enums not available, ...) It should be relatively easy to create a set of SSchema / SAttr / SAttrValue / SAttrUniqueValue (similar to what currently available for user / membership / role) to replace the current SyncopeConf. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Discuss: Rest interface for UserRequestService
When doing the CXF version of the UserRequestService I found that our
current UserRequestController does not really follow the rest ideas.
The problem is that it does follow the idea of doing CRUD operations on
resources. Some methods work with userId others with requestId. So for
example the are create, update and delete operations but they
do not mean the UserRequest but the underlying user.
So I worked out a new interface that purely works on UserRequest and
only supports POST, READ and DELETE. So basically if you want to create
or delete or update a user you will POST a UserRequestTO in all cases.
I added constructors to the UserRequestTO to make the use cases simpler.
request to create a user: userRequestService.create(new
UserRequestTO(userTO));
request to update a user: userRequestService.create(new
UserRequestTO(userMod));
request to delete a user: userRequestService.create(new
UserRequestTO(userTO.getId()));
So what do you think about this?
The only thing I really struggled with is the old isCreateAllowed
method. I implemented this using @Options and return the boolean in a
custom header. I am not sure if this is really the best way to do this
but it
follows the rest principles quite closely. The alternative would be to
do a get on a magic path like in the current spring service.
Best regards
Christian
--
Current Interface:
@RequestMapping(method = RequestMethod.POST, value = /create)
public UserRequestTO create(@RequestBody final UserTO userTO);
@RequestMapping(method = RequestMethod.POST, value = /update)
public UserRequestTO update(@RequestBody final UserMod userMod);
@RequestMapping(method = RequestMethod.GET, value = /delete/{userId})
public UserRequestTO delete(@PathVariable(userId) final Long userId)
@RequestMapping(method = RequestMethod.GET, value = /list)
public ListUserRequestTO list();
@RequestMapping(method = RequestMethod.GET, value = /read/{requestId})
public UserRequestTO read(@PathVariable(requestId) final Long requestId);
@RequestMapping(method = RequestMethod.GET, value =
/deleteRequest/{requestId})
public UserRequestTO deleteRequest(@PathVariable(requestId) final Long
requestId);
New interface for CXF Service:
@Path(requests/user)
public interface UserRequestService {
public static final String SYNCOPE_CREATE_ALLOWED =
Syncope-Create-Allowed;
@OPTIONS
Response getOptions();
@POST
Response create(UserRequestTO userRequestTO);
@GET
ListUserRequestTO list();
@GET
@Path({requestId})
UserRequestTO read(@PathParam(requestId) Long requestId);
@DELETE
@Path({requestId})
void delete(@PathParam(requestId) Long requestId);
}
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
[jira] [Commented] (SYNCOPE-122) Password change on an external resource only
[ https://issues.apache.org/jira/browse/SYNCOPE-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13562800#comment-13562800 ] Hudson commented on SYNCOPE-122: Integrated in Syncope-trunk #10 (See [https://builds.apache.org/job/Syncope-trunk/10/]) [SYNCOPE-122] core implementation completed, now moving to console (Revision 1438543) Result = SUCCESS ilgrosso : Files : * /syncope/trunk/common/src/main/java/org/apache/syncope/common/mod/UserMod.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/Login.java * /syncope/trunk/console/src/main/resources/applicationContext.xml * /syncope/trunk/core/pom.xml * /syncope/trunk/core/src/main/java/org/apache/syncope/core/connid/ConnObjectUtil.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/propagation/PropagationByResource.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/propagation/impl/AbstractPropagationTaskExecutor.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/propagation/impl/PriorityPropagationTaskExecutor.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/propagation/impl/PropagationManager.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/controller/ResourceController.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/controller/UserController.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/AbstractTest.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/UserTestITCase.java * /syncope/trunk/core/src/test/resources/content.xml * /syncope/trunk/core/src/test/resources/restClientContext.xml Password change on an external resource only Key: SYNCOPE-122 URL: https://issues.apache.org/jira/browse/SYNCOPE-122 Project: Syncope Issue Type: New Feature Reporter: Francesco Chicchiriccò Assignee: Francesco Chicchiriccò Fix For: 1.1.0 Give option to change password only on one or more connected external resources; currently it's only possible to change password on Syncope core and then propagate accordingly to the connected external resources. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Revision 1438558 broke completely the admin console authentication
Hi all, I was working on the admin console, saw the commit of revision 1438558, updated and... completely locked out. When starting the admin console via mvn -Pdev I have in the logs a long stacktrace ending with: Caused by: java.lang.NullPointerException: null at org.apache.syncope.client.services.proxy.UserRequestServiceProxy.getOptions(UserRequestServiceProxy.java:41) As a natural consequence, *all* Selenium tests are failing. I am currently trying to understand what's happened and how to fix it quickly, since it is completely *blocking*. Once again, please take care with your commits and check if you aren't breaking anything *before* committing. Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: Discuss: Rest interface for UserRequestService
On 25/01/2013 16:56, Christian Schneider wrote:
When doing the CXF version of the UserRequestService I found that our
current UserRequestController does not really follow the rest ideas.
The problem is that it does follow the idea of doing CRUD operations on
resources. Some methods work with userId others with requestId. So for
example the are create, update and delete operations but they
do not mean the UserRequest but the underlying user.
So I worked out a new interface that purely works on UserRequest and
only supports POST, READ and DELETE. So basically if you want to create
or delete or update a user you will POST a UserRequestTO in all cases.
Problem: you've already made all these changes *without* discussing this
before, once again not taking into any account the domain requirements
nor the compatibility with existing components, but only the technology
aspects.
We must fix this ASAP.
Regards.
I added constructors to the UserRequestTO to make the use cases simpler.
request to create a user: userRequestService.create(new
UserRequestTO(userTO));
request to update a user: userRequestService.create(new
UserRequestTO(userMod));
request to delete a user: userRequestService.create(new
UserRequestTO(userTO.getId()));
So what do you think about this?
The only thing I really struggled with is the old isCreateAllowed
method. I implemented this using @Options and return the boolean in a
custom header. I am not sure if this is really the best way to do this
but it
follows the rest principles quite closely. The alternative would be to
do a get on a magic path like in the current spring service.
Best regards
Christian
--
Current Interface:
@RequestMapping(method = RequestMethod.POST, value = /create)
public UserRequestTO create(@RequestBody final UserTO userTO);
@RequestMapping(method = RequestMethod.POST, value = /update)
public UserRequestTO update(@RequestBody final UserMod userMod);
@RequestMapping(method = RequestMethod.GET, value = /delete/{userId})
public UserRequestTO delete(@PathVariable(userId) final Long userId)
@RequestMapping(method = RequestMethod.GET, value = /list)
public ListUserRequestTO list();
@RequestMapping(method = RequestMethod.GET, value = /read/{requestId})
public UserRequestTO read(@PathVariable(requestId) final Long requestId);
@RequestMapping(method = RequestMethod.GET, value =
/deleteRequest/{requestId})
public UserRequestTO deleteRequest(@PathVariable(requestId) final Long
requestId);
New interface for CXF Service:
@Path(requests/user)
public interface UserRequestService {
public static final String SYNCOPE_CREATE_ALLOWED =
Syncope-Create-Allowed;
@OPTIONS
Response getOptions();
@POST
Response create(UserRequestTO userRequestTO);
@GET
ListUserRequestTO list();
@GET
@Path({requestId})
UserRequestTO read(@PathParam(requestId) Long requestId);
@DELETE
@Path({requestId})
void delete(@PathParam(requestId) Long requestId);
}
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: Discuss: Rest interface for UserRequestService
Hi Christian
On 25/01/13 15:56, Christian Schneider wrote:
When doing the CXF version of the UserRequestService I found that our
current UserRequestController does not really follow the rest ideas.
The problem is that it does follow the idea of doing CRUD operations on
resources. Some methods work with userId others with requestId. So for
example the are create, update and delete operations but they
do not mean the UserRequest but the underlying user.
So I worked out a new interface that purely works on UserRequest and
only supports POST, READ and DELETE. So basically if you want to create
or delete or update a user you will POST a UserRequestTO in all cases.
I added constructors to the UserRequestTO to make the use cases simpler.
request to create a user: userRequestService.create(new
UserRequestTO(userTO));
request to update a user: userRequestService.create(new
UserRequestTO(userMod));
request to delete a user: userRequestService.create(new
UserRequestTO(userTO.getId()));
So what do you think about this?
IMHO it would be nicer to avoid overloading proxy create request to
mean different things, definitely would not use create to mean
delete - perhaps it is a typo, the interface below suggests it might
be ? Would also use update() for updates
Just my 2c :-)
Sergey
The only thing I really struggled with is the old isCreateAllowed
method. I implemented this using @Options and return the boolean in a
custom header. I am not sure if this is really the best way to do this
but it
follows the rest principles quite closely. The alternative would be to
do a get on a magic path like in the current spring service.
Best regards
Christian
--
Current Interface:
@RequestMapping(method = RequestMethod.POST, value = /create)
public UserRequestTO create(@RequestBody final UserTO userTO);
@RequestMapping(method = RequestMethod.POST, value = /update)
public UserRequestTO update(@RequestBody final UserMod userMod);
@RequestMapping(method = RequestMethod.GET, value = /delete/{userId})
public UserRequestTO delete(@PathVariable(userId) final Long userId)
@RequestMapping(method = RequestMethod.GET, value = /list)
public ListUserRequestTO list();
@RequestMapping(method = RequestMethod.GET, value = /read/{requestId})
public UserRequestTO read(@PathVariable(requestId) final Long requestId);
@RequestMapping(method = RequestMethod.GET, value =
/deleteRequest/{requestId})
public UserRequestTO deleteRequest(@PathVariable(requestId) final Long
requestId);
New interface for CXF Service:
@Path(requests/user)
public interface UserRequestService {
public static final String SYNCOPE_CREATE_ALLOWED =
Syncope-Create-Allowed;
@OPTIONS
Response getOptions();
@POST
Response create(UserRequestTO userRequestTO);
@GET
ListUserRequestTO list();
@GET
@Path({requestId})
UserRequestTO read(@PathParam(requestId) Long requestId);
@DELETE
@Path({requestId})
void delete(@PathParam(requestId) Long requestId);
}
Re: Discuss: Rest interface for UserRequestService
On 25.01.2013 17:07, Francesco Chicchiriccò wrote: On 25/01/2013 16:56, Christian Schneider wrote: When doing the CXF version of the UserRequestService I found that our current UserRequestController does not really follow the rest ideas. The problem is that it does follow the idea of doing CRUD operations on resources. Some methods work with userId others with requestId. So for example the are create, update and delete operations but they do not mean the UserRequest but the underlying user. So I worked out a new interface that purely works on UserRequest and only supports POST, READ and DELETE. So basically if you want to create or delete or update a user you will POST a UserRequestTO in all cases. Problem: you've already made all these changes *without* discussing this before, once again not taking into any account the domain requirements nor the compatibility with existing components, but only the technology aspects. We must fix this ASAP. I also thought about this and if I should rather wait. My change only affects the new interface. So the old controller stays the same and stays active. The change should not affect anyone who uses the current spring based rest interface. As we already use the new interface in the console and the tests these are of course affected but this should be only internal. If you prefer I can roll back and wait for the result of the discussion. Best regards Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: Discuss: Rest interface for UserRequestService
On 25.01.2013 17:11, Sergey Beryozkin wrote: Hi Christian On 25/01/13 15:56, Christian Schneider wrote: When doing the CXF version of the UserRequestService I found that our current UserRequestController does not really follow the rest ideas. The problem is that it does follow the idea of doing CRUD operations on resources. Some methods work with userId others with requestId. So for example the are create, update and delete operations but they do not mean the UserRequest but the underlying user. So I worked out a new interface that purely works on UserRequest and only supports POST, READ and DELETE. So basically if you want to create or delete or update a user you will POST a UserRequestTO in all cases. I added constructors to the UserRequestTO to make the use cases simpler. request to create a user: userRequestService.create(new UserRequestTO(userTO)); request to update a user: userRequestService.create(new UserRequestTO(userMod)); request to delete a user: userRequestService.create(new UserRequestTO(userTO.getId())); So what do you think about this? IMHO it would be nicer to avoid overloading proxy create request to mean different things, definitely would not use create to mean delete - perhaps it is a typo, the interface below suggests it might be ? Would also use update() for updates Just my 2c :-) Honestly I was confused by the old interface in the same way. Basically the idea is that the UserRequestService handles UserRequest resources. A UserRequest is a request to do something on a user it is not directly an operation on a user. So I used create in the meaning to create a new UserRequest like you would create a workflow instance. Of course the meaning of this request can be to delete a user at a later point but we are still creating a UserRequest at this point. So I think a POST of a new UserRequest is the right thing to do. Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: Discuss: Rest interface for UserRequestService
On 25/01/13 16:18, Christian Schneider wrote: On 25.01.2013 17:11, Sergey Beryozkin wrote: Hi Christian On 25/01/13 15:56, Christian Schneider wrote: When doing the CXF version of the UserRequestService I found that our current UserRequestController does not really follow the rest ideas. The problem is that it does follow the idea of doing CRUD operations on resources. Some methods work with userId others with requestId. So for example the are create, update and delete operations but they do not mean the UserRequest but the underlying user. So I worked out a new interface that purely works on UserRequest and only supports POST, READ and DELETE. So basically if you want to create or delete or update a user you will POST a UserRequestTO in all cases. I added constructors to the UserRequestTO to make the use cases simpler. request to create a user: userRequestService.create(new UserRequestTO(userTO)); request to update a user: userRequestService.create(new UserRequestTO(userMod)); request to delete a user: userRequestService.create(new UserRequestTO(userTO.getId())); So what do you think about this? IMHO it would be nicer to avoid overloading proxy create request to mean different things, definitely would not use create to mean delete - perhaps it is a typo, the interface below suggests it might be ? Would also use update() for updates Just my 2c :-) Honestly I was confused by the old interface in the same way. Basically the idea is that the UserRequestService handles UserRequest resources. A UserRequest is a request to do something on a user it is not directly an operation on a user. So I used create in the meaning to create a new UserRequest like you would create a workflow instance. Of course the meaning of this request can be to delete a user at a later point but we are still creating a UserRequest at this point. So I think a POST of a new UserRequest is the right thing to do. Sure, whatever makes sense from the flow perspective is better be supported well at the API level, agreed, it is just that we have create overloaded, we can have different proxy methods mapped to different URI patterns, example, update() - @POST @Path(/users/update), create() - @POST @Path(/users/create), would still be @POST but different function names at the API level Cheers, Sergey Christian
Re: Discuss: Rest interface for UserRequestService
On 25.01.2013 17:18, Francesco Chicchiriccò wrote: I also thought about this and if I should rather wait. My change only affects the new interface. So the old controller stays the same and stays active. The change should not affect anyone who uses the current spring based rest interface. As we already use the new interface in the console and the tests these are of course affected but this should be only internal. If you prefer I can roll back and wait for the result of the discussion. For the moment it would be enough for me to have again a working admin console, as it used to be before of this commit. Regards. I will take care of this. I hoped to not affect the console. If I cant fix it easily I will roll back. Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: Discuss: Rest interface for UserRequestService
On 25/01/2013 17:28, Christian Schneider wrote: On 25.01.2013 17:18, Francesco Chicchiriccò wrote: I also thought about this and if I should rather wait. My change only affects the new interface. So the old controller stays the same and stays active. The change should not affect anyone who uses the current spring based rest interface. As we already use the new interface in the console and the tests these are of course affected but this should be only internal. If you prefer I can roll back and wait for the result of the discussion. For the moment it would be enough for me to have again a working admin console, as it used to be before of this commit. Regards. I will take care of this. I hoped to not affect the console. If I cant fix it easily I will roll back. I am about to commit a temporary workaround: take your time and fix it properly, please. Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[Discuss] Way to parameterize integration tests
Hi, One more topic to discuss: Currently integration tests run using communication using JSON contentType only. For new CXF-based tests we are going to run every tests twice: with XML and JSON [1]. JUnit proposes elegant solution using parameterized tests: http://junit.sourceforge.net/javadoc/org/junit/runners/Parameterized.html . Basically it works fine, but unfortunately (as Francesco already noted) individual tests cannot be executed from Surefire or Failsafe plugins as well as from some IDEs. The problem is that Parameterized runner expect individual test description in form ClassName#MethodName[Number]. This form cannot be specified in maven command line, because method name will be not correctly resolved. I do not see any acceptable solution for Parameterized runner now and propose following alternatives: 1. Create two classes per each test inherited from common parent for all CXF tests (e.g. AuthenticationTestXMLTestITCase, AuthenticationTestJsonTestITCase). Always run both variants. 2. Leave single test classes and configure contentType in AbstractTest with default value JSON. Normally run only JSON tests (like now). Make XML tests runnable via separate profile / configuration. 3.... WDYT? Regards, Andrei. [1] https://issues.apache.org/jira/browse/SYNCOPE-289
[jira] [Commented] (SYNCOPE-231) Using Standard JAX-RS API in Syncope (Replace Spring Webservice Stack with Apache CXF)
[ https://issues.apache.org/jira/browse/SYNCOPE-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13562831#comment-13562831 ] Hudson commented on SYNCOPE-231: Integrated in Syncope-trunk #11 (See [https://builds.apache.org/job/Syncope-trunk/11/]) SYNCOPE-231 Adding UserRequestService for CXF (Revision 1438558) Result = SUCCESS cschneider : Files : * /syncope/trunk/client/src/main/java/org/apache/syncope/client/services/proxy/UserRequestServiceProxy.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/services/UserRequestService.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/to/UserRequestOptionsTO.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/to/UserRequestTO.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/Login.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/rest/UserRequestRestClient.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/controller/UserRequestController.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/services/UserRequestServiceImpl.java * /syncope/trunk/core/src/main/resources/restContext.xml * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/UserRequestTestITCase.java Using Standard JAX-RS API in Syncope (Replace Spring Webservice Stack with Apache CXF) -- Key: SYNCOPE-231 URL: https://issues.apache.org/jira/browse/SYNCOPE-231 Project: Syncope Issue Type: Improvement Components: console, core Reporter: Jan Bernhardt Assignee: Jan Bernhardt Fix For: 1.2.0 Attachments: TaskService.patch Current REST Interfaces are based on Spring Webservice framework. Goal of this task is to replace Spring with CXF and to relay on JAX-B and JAX-RS annotations rather then Spring annotations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Discuss] Way to parameterize integration tests
On 25/01/2013 17:39, Andrei Shakirin wrote: Hi, One more topic to discuss: Currently integration tests run using communication using JSON contentType only. For new CXF-based tests we are going to run every tests twice: with XML and JSON [1]. JUnit proposes elegant solution using parameterized tests: http://junit.sourceforge.net/javadoc/org/junit/runners/Parameterized.html . Basically it works fine, but unfortunately (as Francesco already noted) individual tests cannot be executed from Surefire or Failsafe plugins as well as from some IDEs. The ability we've had so far to execute a single IT case is of fundamental importance to speed up the development process. The problem is that Parameterized runner expect individual test description in form ClassName#MethodName[Number]. This form cannot be specified in maven command line, because method name will be not correctly resolved. I do not see any acceptable solution for Parameterized runner now and propose following alternatives: 1. Create two classes per each test inherited from common parent for all CXF tests (e.g. AuthenticationTestXMLTestITCase, AuthenticationTestJsonTestITCase). Always run both variants. 2. Leave single test classes and configure contentType in AbstractTest with default value JSON. Normally run only JSON tests (like now). Make XML tests runnable via separate profile / configuration. +1 I don't like the idea of duplicating test cases, so if we have an easy way to activate contentType = XML it would be acceptable. 3.... Regards. [1] https://issues.apache.org/jira/browse/SYNCOPE-289 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
