I just added the patch for SYNCOPE-241. The separation of the API seems to work fine.
I also added an issue https://issues.apache.org/jira/browse/SYNCOPE-259 to track introducing a UserService and switch the tests and client code to it. As you see from the UserTestITCase the change is quite small. I only added the JAXRS API and was able to switch the test without touching any other code. I think that the interface would even make sense if we would not intend to switch to CXF as it removes a lot of repetitive use of the RestTemplate and makes the test more readable. As a next step I will do the change on the console module and the other tests that use the user rest service. Christian On 21.12.2012 10:09, Francesco Chicchiriccò wrote: > On 21/12/2012 09:59, Christian Schneider wrote: >> Hi Francesco, >> >> it is a good idea to release a 1.1.0 version before we introduce the cxf >> depdendencies. >> >> What parts of our plan do you think can go into trunk and what should >> wait till after the 1.1.0 release? >> >> My proposal is this: >> >> On 20.12.2012 17:08, Francesco Chicchiriccò wrote: >>> On 20/12/2012 16:44, Andrei Shakirin wrote: >>>> Hi, >>>> >>>> We just finished CXF migration POC for users and roles: it is >>>> successful and we approximately know how much efforts we need for >>>> complete migration. >>>> I would like to discuss the steps we are going to do for complete >>>> migration in next year. >>>> >>>> >>>> 1. Prerequisites >>>> >>>> a) Finishing persistence refactoring >>>> (https://issues.apache.org/jira/browse/SYNCOPE-241, >>>> https://issues.apache.org/jira/browse/SYNCOPE-242 ) >> Before 1.1.0 > > Agreed, especially because SYNCOPE-242 is already fixed ;-) > >>>> b) Resolve ConnId CXF dependencies problem >>>> (https://issues.apache.org/jira/browse/SYNCOPE-251 ) >> After 1.1.0 > > Agreed. > >>>> 2. Steps >>>> >>>> a) Introduce interfaces for all controllers in >>>> org.apache.syncope.core.rest.controller (the same way as for user and >>>> role in cxf branch). Interfaces will contain JAX-RS annotations. >>>> Commit interfaces to trunk >>>> >> Before 1.1.0 (if time permits) >>>> b) Provide temporary implementation of interfaces (step a) for >>>> "old" spring based rest implementation (based on spring >>>> restTemplate). Commit implementations to trunk >>>> >> Before 1.1.0 (if time permits) >>>> c) Refactor core rest integration tests to use controller >>>> interfaces instead restTemplate. All rest tests must be successful. >>>> Commit refactored tests to trunk. This step helps to prepare tests to >>>> be used with CXF without breaking them >>>> >> Before 1.1.0 (if time permits) > > Agreed only if the whole step 2 (a, b and c) is done at once and if > additional dependencies are very limited (only for JAX-RS annotations). > Otherwise, the whole step 2 should be moved after 1.1.0. > >> All the rest should be delayed till after 1.1.0 >>>> d) Add CXF dependencies, CXF Rest service configuration, >>>> exception mappers and jaxb/json providers, but do not activate them. >>>> Commit them to trunk >>>> >>>> e) Update TO classes for JAXB marshalling (if necessary) and >>>> keep spring marshalling working with the same TO classes. Commit it >>>> to trunk. If keeping JAXB marshalling parallel to spring is too >>>> complicate, this step will be done in cxf-migration branch after step >>>> (f) >>>> >>>> f) Create cxf-migration branch >>>> >>>> g) Activate using CXF Rest for controller interfaces instead >>>> temporary spring based implementation created on step (b). Fix >>>> possible problems >>>> >>>> h) Update console to use CXF Rest. Fix possible problems >>>> >>>> i) Merge cxf-migration branch with trunk >>>> >>>> Our idea is to keep cxf-migration branch possibly short time, split >>>> migration on some small steps and keep the tests and whole system >>>> running in between. >>>> Does this plan make sense? Any other suggestions / ideas? >> Basically my proposal is to put into 1.1.0 all steps that have a low >> risk and provide some benefits. I think it will be good to convert a lot >> of the tests beforehand to the interfaces as this will make it easier to >> backport changes >> to 1.1.x later. >> >> Apart from the above things what is the plan for 1.1.0? Is it feature >> complete already or do you want to get some more features in? > > As wrote yesterday, we should review all issues currently targeted to > 1.1.0 and decide whether to keep or move to next releases. > > Regards. >
