RE: Build # 439 - Failure
Hi, Any ideas why this build yesterday was failed? Do not get it, all tests seems to be ok ... Seems that failure was caused by my change: Integrated in Syncope-trunk #439 (See [https://builds.apache.org/job/Syncope-trunk/439/]) [SYNCOPE-268] Make rest integration tests re-runnable (Revision 1433920) Result = FAILURE ashakirin : Files : * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/TaskTestITCase.java Andrei. -Original Message- From: Apache Jenkins Server [mailto:jenk...@builds.apache.org] Sent: Mittwoch, 16. Januar 2013 14:26 To: dev@syncope.apache.org; ashaki...@apache.org Subject: Syncope-trunk - Build # 439 - Failure The Apache Jenkins build system has built Syncope-trunk (build #439) Status: Failure Check console output at https://builds.apache.org/job/Syncope-trunk/439/ to view the results.
Re: [Discussion] CXF migration (branches)
On 17/01/2013 09:13, Jan Bernhardt wrote: Hi syncoper, Our mail system is working again :) Nice: next time please also consider Nabble [1] to post to this ML - only remember to register with the same e-mail address you are subscribed to dev@. As Christian already stated, we have 4 developers currently with time budged to get the CXF migration done. We cannot delay this task without massive re-planning time constrains... Sorry Jan, I don't think this fact is inline with community-driven development. This community discussed and established a roadmap with some releases [2]: this roadmap can be reviewed over time, of course, but it remains the driver for this project's activities, indeed. In the roadmap, the release 1.1.0 comes *before* 1.2.0, and we have currently agreed to proceed to the final CXF migration in the latter. Unfortunately, however, there is still plenty of issues to be closed for 1.1.0. I am personally happy that people is interested in making Syncope working with CXF and OSGi but I am sincerely worried of the fact that the actual core features - i.e. what Syncope does, not how it communicates with external or how it is deployed - and related documentation are left behind. I am also worried about the sentence reported by Christian below: We currently have the plan to finish the CXF migration during the next 1.5 weeks with 4 developers. The issue is a little urgent as from February on our normal product development team would like to take over and focus on making Syncope work nicely in OSGi. I hope this does not mean that you will disappear once the CXF migration is done, it would be very bad for Syncope. And, for my curiosity: who is the normal product development team? Are you part of it? Are the people from this team already part of this project (Syncope)? But the good news is, that I found a way how we could solve this dilemma ;-) The main problem (as mentioned earlier) with SVN is merging of renamed files. So my proposal would be to not rename any classes within a development branch. But instead leaving Controller classes as they are, and introducing new *ServiceImpl classes in addition to that. The current implementation of those *ServiceImpl classes would be to call matching methods of Controller classes (basically same idea for server side as we already applied on client side with SpringServiceProxy classes). Once we all agree with new ServiceInterfaces and switching from Spring webservices to CXF we can copy code from controller classes and place this code in *ServiceImpl classes and then delete controller classes. The advantage of this proposal is, that we can make all REST Services run in CXF and Spring at the same time, without any conflicts! If other syncope committers agree we could even make these changes in trunk and release this as an early preview in 1.1.0. But even if not, we can get the migration done in a branch and then merge branch back to trunk after 1.1.0 release. If, as it seems there is no other way out, I'd propose to move back the CXF migration to 1.1.0 (as actually OSGi is still there) so that no additional branch is created. This is valid as long as Spring MVC interfaces are still working as now, as you said above. In this way we will have a very fat 1.1.0 release, but at least we will be free to make a release when we feel it's ready. Later than currently expected, of course. However some changes could be done in trunk anyway, like removing client in package names: org.apache.syncope.client.mod -- org.apache.syncope.mod org.apache.syncope.client.report -- org.apache.syncope.report org.apache.syncope.client.search -- org.apache.syncope.search org.apache.syncope.client.to -- org.apache.syncope.to org.apache.syncope.client.validation -- org.apache.syncope.validation Could you please give a rationale for this? Currently, any submodule's root package reflects its own name: e.g. org.apache.syncope.core / org.apache.syncope.console / org.apache.syncope.client Regards. -Original Message- From: Christian Schneider [mailto:cschneider...@gmail.com] On Behalf Of Christian Schneider Sent: Mittwoch, 16. Januar 2013 18:48 To: dev@syncope.apache.org Subject: Re: [Discussion] CXF migration (branches) Jan contacted me that the E-Mail Server in the Bonn office is currently down so he can not reply himself at the moment. So I am replying what he wrote me via Skype: We currently have the plan to finish the CXF migration during the next 1.5 weeks with 4 developers. The issue is a little urgent as from february on our normal product development team would like to take over and focus on making Syncope work nicely in OSGi. At this point we should have finished the CXF migration. Of course we can delay things a little but not too much without affecting our whole planning. Christian On 16.01.2013 16:08, Francesco Chicchiriccò wrote: On 16/01/2013 15:50, Jan Bernhardt wrote: Hi Syncopers, all
Syncope-1_0_X - Build # 107 - Fixed
The Apache Jenkins build system has built Syncope-1_0_X (build #107) Status: Fixed Check console output at https://builds.apache.org/job/Syncope-1_0_X/107/ to view the results.
Re: [Discussion] CXF migration (branches)
On 17.01.2013 10:05, Francesco Chicchiriccò wrote: On 17/01/2013 09:13, Jan Bernhardt wrote: As Christian already stated, we have 4 developers currently with time budged to get the CXF migration done. We cannot delay this task without massive re-planning time constrains... Sorry Jan, I don't think this fact is inline with community-driven development. This community discussed and established a roadmap with some releases [2]: this roadmap can be reviewed over time, of course, but it remains the driver for this project's activities, indeed. In the roadmap, the release 1.1.0 comes *before* 1.2.0, and we have currently agreed to proceed to the final CXF migration in the latter. Unfortunately, however, there is still plenty of issues to be closed for 1.1.0. I am personally happy that people is interested in making Syncope working with CXF and OSGi but I am sincerely worried of the fact that the actual core features - i.e. what Syncope does, not how it communicates with external or how it is deployed - and related documentation are left behind. I am also worried about the sentence reported by Christian below: We currently have the plan to finish the CXF migration during the next 1.5 weeks with 4 developers. The issue is a little urgent as from February on our normal product development team would like to take over and focus on making Syncope work nicely in OSGi. I hope this does not mean that you will disappear once the CXF migration is done, it would be very bad for Syncope. And, for my curiosity: who is the normal product development team? Are you part of it? Are the people from this team already part of this project (Syncope)? Hi, I will explain a bit how our team structure is. Andrei, Jan, Christian Schmüling and me are currently working on a large project that will go for several years. So we are a bit separated from normal product development. Still most we do will go into the open source projects. In fact I am only working 50% on the project and 50% in the Apache Team. The rest of our people is either working on the Apache Team or in our TESB Runtime Team. So while we are working on the same projects we have different management and of course slightly different goals. From the apache team your already know Jean Baptiste and Colm. I fully agree that our internal committment (we are doing scrum) is not always in line with community development and we are aware of that. As syncope is community driven our internal plan of course can only be a proposal for the community. During our project we will be active in different communities over time. So we will not always work on syncope but I am pretty sure that over time we will continue to put considerable efforts into syncope. Christian
RE: [Discussion] CXF migration (branches)
Hi Francesco, -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Donnerstag, 17. Januar 2013 10:05 To: dev@syncope.apache.org Subject: Re: [Discussion] CXF migration (branches) On 17/01/2013 09:13, Jan Bernhardt wrote: Hi syncoper, Our mail system is working again :) Nice: next time please also consider Nabble [1] to post to this ML - only remember to register with the same e-mail address you are subscribed to dev@. This is what I did yesterday, but unfortunately I could also not receive the confirmation mail from nabble... As Christian already stated, we have 4 developers currently with time budged to get the CXF migration done. We cannot delay this task without massive re-planning time constrains... Sorry Jan, I don't think this fact is inline with community-driven development. I don't see a conflict with community-driven development. The community can provide new features and extensions in topics they have a special interest and skillset in. Of course including these new features in a release (or trunk) needs to be aligned with other community members. But I think it is rather common that companies get engaged in Apache projects and that they focus on providing some extensions they need in their business. As long as the community agrees that these features are valuable; I don't see a problem here. This community discussed and established a roadmap with some releases [2]: this roadmap can be reviewed over time, of course, but it remains the driver for this project's activities, indeed. In the roadmap, the release 1.1.0 comes *before* 1.2.0, and we have currently agreed to proceed to the final CXF migration in the latter. Unfortunately, however, there is still plenty of issues to be closed for 1.1.0. I am personally happy that people is interested in making Syncope working with CXF and OSGi but I am sincerely worried of the fact that the actual core features - i.e. what Syncope does, not how it communicates with external or how it is deployed - and related documentation are left behind. I am also worried about the sentence reported by Christian below: We currently have the plan to finish the CXF migration during the next 1.5 weeks with 4 developers. The issue is a little urgent as from February on our normal product development team would like to take over and focus on making Syncope work nicely in OSGi. I hope this does not mean that you will disappear once the CXF migration is done, it would be very bad for Syncope. I can understand your worries. And no, we will not disappear once CXF migration is done. But of course we will spend less time in Syncope topics as currently. The last few weeks I was working more or less every day with syncope topics. This was fine, since Syncope topics matched with our current project goals. But talend understands that a committership requires continues activity within these projects. Thus I'll be able to continue working on Syncope topics (not aligned with project topics), once CXF migration is done. Of course not 5 days a week. And, for my curiosity: who is the normal product development team? Are you part of it? Are the people from this team already part of this project (Syncope)? No. Our product team has not really started working with syncope. We just told them, that they should, because Syncope has already some nice features and an even greater potential. ;-) But the good news is, that I found a way how we could solve this dilemma ;-) The main problem (as mentioned earlier) with SVN is merging of renamed files. So my proposal would be to not rename any classes within a development branch. But instead leaving Controller classes as they are, and introducing new *ServiceImpl classes in addition to that. The current implementation of those *ServiceImpl classes would be to call matching methods of Controller classes (basically same idea for server side as we already applied on client side with SpringServiceProxy classes). Once we all agree with new ServiceInterfaces and switching from Spring webservices to CXF we can copy code from controller classes and place this code in *ServiceImpl classes and then delete controller classes. The advantage of this proposal is, that we can make all REST Services run in CXF and Spring at the same time, without any conflicts! If other syncope committers agree we could even make these changes in trunk and release this as an early preview in 1.1.0. But even if not, we can get the migration done in a branch and then merge branch back to trunk after 1.1.0 release. If, as it seems there is no other way out, I'd propose to move back the CXF migration to 1.1.0 (as actually OSGi is still there) so that no additional branch is created. This is valid as long as Spring MVC interfaces are still working as now, as you said above. Yes, Spring MVC interfaces will not be affected. In
[jira] [Commented] (SYNCOPE-241) Move persistence and persistence impl into separate modules
[ https://issues.apache.org/jira/browse/SYNCOPE-241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13556110#comment-13556110 ] Christian Schneider commented on SYNCOPE-241: - Just committed the change SYNCOPE-241 Moving PropagationActions back into core.propagation. Created impl package to avoid cycles http://svn.apache.org/viewvc?view=revisionrevision=r1434636 Next I will work on the two misplaced sync classes in persistence. Move persistence and persistence impl into separate modules --- Key: SYNCOPE-241 URL: https://issues.apache.org/jira/browse/SYNCOPE-241 Project: Syncope Issue Type: Improvement Components: core Affects Versions: 1.0.3-incubating Reporter: Christian Schneider Fix For: 1.1.0 Attachments: SYNCOPE-241-2.patch, SYNCOPE-241-3.patch, SYNCOPE-241-4.patch, SYNCOPE-241-5.patch, SYNCOPE-241-6.patch, SYNCOPE-241.patch The core module currently contains many parts of syncope. This makes it bigger and more complex than necessary. A possible modularization is to move the internal model (org.apache.syncope.core.persistence*) and the persistence impl (org.apache.syncope.core.persistence.impl) out of core and into separate modules. One big advantage would be that the jpa code enhancements would then run in the model module only. Currently we run into some problems in the cxf migration when running the rest itests in core that may be caused by eclipse overwriting the enhanced classes with plain classes. If the model (peristence) classes are in a separate module we could leave it out of eclipse and so this would be no issue anymore. Another advantage would be that the persistence tests could run in the persistence impl module so when working on the core they would not have to run each time. -- 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-241) Move persistence and persistence impl into separate modules
[ https://issues.apache.org/jira/browse/SYNCOPE-241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13556113#comment-13556113 ] Francesco Chicchiriccò commented on SYNCOPE-241: Very nice: looking forward to the sync classes, then (and I guess you could close this issue at that point, right?) Move persistence and persistence impl into separate modules --- Key: SYNCOPE-241 URL: https://issues.apache.org/jira/browse/SYNCOPE-241 Project: Syncope Issue Type: Improvement Components: core Affects Versions: 1.0.3-incubating Reporter: Christian Schneider Fix For: 1.1.0 Attachments: SYNCOPE-241-2.patch, SYNCOPE-241-3.patch, SYNCOPE-241-4.patch, SYNCOPE-241-5.patch, SYNCOPE-241-6.patch, SYNCOPE-241.patch The core module currently contains many parts of syncope. This makes it bigger and more complex than necessary. A possible modularization is to move the internal model (org.apache.syncope.core.persistence*) and the persistence impl (org.apache.syncope.core.persistence.impl) out of core and into separate modules. One big advantage would be that the jpa code enhancements would then run in the model module only. Currently we run into some problems in the cxf migration when running the rest itests in core that may be caused by eclipse overwriting the enhanced classes with plain classes. If the model (peristence) classes are in a separate module we could leave it out of eclipse and so this would be no issue anymore. Another advantage would be that the persistence tests could run in the persistence impl module so when working on the core they would not have to run each time. -- 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: [Discussion] New REST Service Interfaces - Entitlements
Hi Syncoper, The following changes are proposed regarding AuthenticationController: === Renaming Service === Rename AuthenticationController to EntitlementService(Impl), since containing methods have little to nothing to do with authentication. It is only about Entitlements... === Changing response Type === listEntitlements() returns a ListString whereas getEntitlements() returns a SetString. From my point of view both methods should return a SET since entitlements have no order and cannot exists or be assigned more than once. Due to some JAX-B / JAX-RS limitations, it is not possible to return a collection with primitive data types in java. A wrapper class is required, e.g. SetEntitlementTO. EntitlementTO can be modeled in one of two ways: Option 1: EntitlementTOs EntitlementTOROLE_ADMIN/EntitlementTO EntitlementTOROLE_SUPERUSER/EntitlementTO /EntitlementTOs Option 2: EntitlementTOs EntitlementTO nameROLE_ADMIN/name /EntitlementTO EntitlementTO name ROLE_SUPERUSER /name /EntitlementTO /EntitlementTOs Option 1 matches more or less current marshaling. I personally would prefer Option 2 because this would give us the opportunity to easily extend EntitlementTO at a later point (if needed) without becoming incompatible with previous version. WDYT? All of these changes will not apply to current Spring Controller/Services, but only future CXF REST Service. So AuthenticationController will not be renamed now, and responsetype of AuthenticationController will not change. Changes only apply for new Service Interface and (Proxy) Implementation. Best regards. Jan
RE: [Discussion] New REST Service Interfaces - Entitlements
And what I forgott to mention: listEntitlements and getEntitlements are not very self-explanatory. A better name would be getAllEntitlements and getMyEntitlements. Regards. Jan -Original Message- From: Jan Bernhardt [mailto:jbernha...@talend.com] Sent: Donnerstag, 17. Januar 2013 14:04 To: dev@syncope.apache.org Subject: RE: [Discussion] New REST Service Interfaces - Entitlements Hi Syncoper, The following changes are proposed regarding AuthenticationController: === Renaming Service === Rename AuthenticationController to EntitlementService(Impl), since containing methods have little to nothing to do with authentication. It is only about Entitlements... === Changing response Type === listEntitlements() returns a ListString whereas getEntitlements() returns a SetString. From my point of view both methods should return a SET since entitlements have no order and cannot exists or be assigned more than once. Due to some JAX-B / JAX-RS limitations, it is not possible to return a collection with primitive data types in java. A wrapper class is required, e.g. SetEntitlementTO. EntitlementTO can be modeled in one of two ways: Option 1: EntitlementTOs EntitlementTOROLE_ADMIN/EntitlementTO EntitlementTOROLE_SUPERUSER/EntitlementTO /EntitlementTOs Option 2: EntitlementTOs EntitlementTO nameROLE_ADMIN/name /EntitlementTO EntitlementTO name ROLE_SUPERUSER /name /EntitlementTO /EntitlementTOs Option 1 matches more or less current marshaling. I personally would prefer Option 2 because this would give us the opportunity to easily extend EntitlementTO at a later point (if needed) without becoming incompatible with previous version. WDYT? All of these changes will not apply to current Spring Controller/Services, but only future CXF REST Service. So AuthenticationController will not be renamed now, and responsetype of AuthenticationController will not change. Changes only apply for new Service Interface and (Proxy) Implementation. Best regards. Jan
Re: [Discussion] New REST Service Interfaces - Entitlements
Il giorno 17/gen/2013, alle ore 14.03, Jan Bernhardt ha scritto: Hi Syncoper, The following changes are proposed regarding AuthenticationController: === Renaming Service === Rename AuthenticationController to EntitlementService(Impl), since containing methods have little to nothing to do with authentication. It is only about Entitlements... Why not AuthorizationController or AccessController? I'd prefer the first one. May be this controller will be improved to add access controller features int the next future (please, take a look at the roadmap). === Changing response Type === listEntitlements() returns a ListString whereas getEntitlements() returns a SetString. From my point of view both methods should return a SET since entitlements have no order and cannot exists or be assigned more than once. Agree Due to some JAX-B / JAX-RS limitations, it is not possible to return a collection with primitive data types in java. A wrapper class is required, e.g. SetEntitlementTO. EntitlementTO can be modeled in one of two ways: Option 1: EntitlementTOs EntitlementTOROLE_ADMIN/EntitlementTO EntitlementTOROLE_SUPERUSER/EntitlementTO /EntitlementTOs Option 2: EntitlementTOs EntitlementTO nameROLE_ADMIN/name /EntitlementTO EntitlementTO name ROLE_SUPERUSER /name /EntitlementTO /EntitlementTOs Option 1 matches more or less current marshaling. I personally would prefer Option 2 because this would give us the opportunity to easily extend EntitlementTO at a later point (if needed) without becoming incompatible with previous version. Agree with you for the reason given above. WDYT? All of these changes will not apply to current Spring Controller/Services, but only future CXF REST Service. So AuthenticationController will not be renamed now, and responsetype of AuthenticationController will not change. Changes only apply for new Service Interface and (Proxy) Implementation. Good. Regards, F.
[jira] [Resolved] (SYNCOPE-199) Refocus on user deletion page
[ https://issues.apache.org/jira/browse/SYNCOPE-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Di Sabatino Di Diodoro resolved SYNCOPE-199. -- Resolution: Fixed http://svn.apache.org/viewvc?rev=1434678view=rev Refocus on user deletion page - Key: SYNCOPE-199 URL: https://issues.apache.org/jira/browse/SYNCOPE-199 Project: Syncope Issue Type: Improvement Reporter: Colm O hEigeartaigh Assignee: Marco Di Sabatino Di Diodoro Priority: Trivial Fix For: 1.1.0 SYNCOPE-189 added the ability to close a window on pressing ESC. It would be nice when deleting a user to automatically reselect the deletion page, so that the user can just press ESC to close the window. Currently you need to click on the deletion page before pressing ESC. -- 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: svn commit: r1434684 - in /syncope/trunk/archetype: pom.xml src/main/resources/archetype-resources/core/src/main/resources/activiticontent.xml src/main/resources/archetype-resources/core/src/main/
On 17/01/2013 15:37, Christian Schneider wrote: I added the code to copy them too. I just committed them as they were reported changed. Should I delete the files and tell svn to ignore them? Just updated svn:ignore + removed again all local archetype resources from SVN. I will open an issue to change the resource population for archetype in order to be more robust to this kind of changes. I found that the AbstractDAOTests can not simply create the Activiti properties as the table is not there when we omit the spring xml to initialize Activiti. So I wanted to make the ContentLoader more flexible. This way I was able to replace the xsl based removal of Activiti properties by a java based one. I think this is better than xsl as it is more obvious to see in the code. It took me a while to see that the xsl does this... Did you take into any account the export procedure for subsequent re-import when changing this logic? Have you tried how this behaves in overlays generated from the archetype? Now we don't have any more a single content.xml (as generated by export generates) but two separate content.xml and activiticontent.xml I will open another issue to verify how export / import procedure will work after these changes. Regards. On 17.01.2013 15:32, Francesco Chicchiriccò wrote: On 17/01/2013 15:27, cschnei...@apache.org wrote: Author: cschneider Date: Thu Jan 17 14:27:33 2013 New Revision: 1434684 URL: http://svn.apache.org/viewvc?rev=1434684view=rev Log: SYNCOPE-241 Adding new activiticontent.xml to archetype Why this activiticontent.xml? Why removing the XSLT dynamic from core pom.xml? Moreover: please consider that archetype resources must be copied from core and console as part of the build process and not statically committed as you've just did for content.xml and activiticontent.xml. Regards. -- Dott. Francesco Chicchiriccò Tel +393290573276 Amministratore unico @ Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 085973 http://www.tirasa.net ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/ To Iterate is Human, to Recurse, Divine (James O. Coplien, Bell Labs) -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[jira] [Updated] (SYNCOPE-278) Verify export / import
[ https://issues.apache.org/jira/browse/SYNCOPE-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated SYNCOPE-278: --- Fix Version/s: 1.1.0 Verify export / import -- Key: SYNCOPE-278 URL: https://issues.apache.org/jira/browse/SYNCOPE-278 Project: Syncope Issue Type: Task Reporter: Francesco Chicchiriccò Fix For: 1.1.0 Verify how exporting / importing db content is working after latest modifications, against all supported DBMS. -- 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-278) Verify export / import
Francesco Chicchiriccò created SYNCOPE-278: -- Summary: Verify export / import Key: SYNCOPE-278 URL: https://issues.apache.org/jira/browse/SYNCOPE-278 Project: Syncope Issue Type: Task Reporter: Francesco Chicchiriccò Verify how exporting / importing db content is working after latest modifications, against all supported DBMS. -- 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-278) Verify export / import
[ https://issues.apache.org/jira/browse/SYNCOPE-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated SYNCOPE-278: --- Description: Verify how exporting / importing db content is working after latest modifications from SYNCOPE-241, against all supported DBMS. (was: Verify how exporting / importing db content is working after latest modifications, against all supported DBMS.) Verify export / import -- Key: SYNCOPE-278 URL: https://issues.apache.org/jira/browse/SYNCOPE-278 Project: Syncope Issue Type: Task Reporter: Francesco Chicchiriccò Fix For: 1.1.0 Verify how exporting / importing db content is working after latest modifications from SYNCOPE-241, against all supported DBMS. -- 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-199) Refocus on user deletion page
[ https://issues.apache.org/jira/browse/SYNCOPE-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13556237#comment-13556237 ] Colm O hEigeartaigh commented on SYNCOPE-199: - Thanks for the fix! Colm. Refocus on user deletion page - Key: SYNCOPE-199 URL: https://issues.apache.org/jira/browse/SYNCOPE-199 Project: Syncope Issue Type: Improvement Reporter: Colm O hEigeartaigh Assignee: Marco Di Sabatino Di Diodoro Priority: Trivial Fix For: 1.1.0 SYNCOPE-189 added the ability to close a window on pressing ESC. It would be nice when deleting a user to automatically reselect the deletion page, so that the user can just press ESC to close the window. Currently you need to click on the deletion page before pressing ESC. -- 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-241) Move persistence and persistence impl into separate modules
[ https://issues.apache.org/jira/browse/SYNCOPE-241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13556248#comment-13556248 ] Hudson commented on SYNCOPE-241: Integrated in Syncope-trunk #448 (See [https://builds.apache.org/job/Syncope-trunk/448/]) SYNCOPE-241 Adding new activiticontent.xml to archetype (Revision 1434684) SYNCOPE-241 Move SyncActions and SyncResult back into core.sync. Create impl package to avoid cycles. Improve ContentLoader to optionally load activiti properties (Revision 1434683) Result = SUCCESS cschneider : Files : * /syncope/trunk/archetype/pom.xml * /syncope/trunk/archetype/src/main/resources/archetype-resources/core/src/main/resources/activiticontent.xml * /syncope/trunk/archetype/src/main/resources/archetype-resources/core/src/main/resources/content.xml cschneider : Files : * /syncope/trunk/core/pom.xml * /syncope/trunk/core/src/main/java/org/apache/syncope/core/init/ImplementationClassNamesLoader.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/init/JobInstanceLoader.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/beans/SyncActions.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/beans/SyncResult.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/beans/SyncTask.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/dao/impl/ContentLoader.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/dao/impl/ResourceDAOImpl.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/validation/entity/SyncTaskValidator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/propagation/impl/LDAPMembershipPropagationActions.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/sync/DefaultSyncActions.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/sync/LDAPMembershipSyncActions.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/sync/SyncActions.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/sync/SyncJob.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/sync/SyncResult.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/sync/SyncopeSyncResultHandler.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/sync/impl * /syncope/trunk/core/src/main/java/org/apache/syncope/core/sync/impl/LDAPMembershipSyncActions.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/sync/impl/SyncJob.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/sync/impl/SyncopeSyncResultHandler.java * /syncope/trunk/core/src/main/resources/activiticontent.xml * /syncope/trunk/core/src/main/resources/content.xml * /syncope/trunk/core/src/test/java/org/apache/syncope/core/persistence/dao/impl/TestDbInitializer.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/TaskTestITCase.java * /syncope/trunk/core/src/test/resources/content.xml * /syncope/trunk/core/src/test/resources/noopworkflow/stripActivitiFromContent.xsl Move persistence and persistence impl into separate modules --- Key: SYNCOPE-241 URL: https://issues.apache.org/jira/browse/SYNCOPE-241 Project: Syncope Issue Type: Improvement Components: core Affects Versions: 1.0.3-incubating Reporter: Christian Schneider Fix For: 1.1.0 Attachments: SYNCOPE-241-2.patch, SYNCOPE-241-3.patch, SYNCOPE-241-4.patch, SYNCOPE-241-5.patch, SYNCOPE-241-6.patch, SYNCOPE-241.patch The core module currently contains many parts of syncope. This makes it bigger and more complex than necessary. A possible modularization is to move the internal model (org.apache.syncope.core.persistence*) and the persistence impl (org.apache.syncope.core.persistence.impl) out of core and into separate modules. One big advantage would be that the jpa code enhancements would then run in the model module only. Currently we run into some problems in the cxf migration when running the rest itests in core that may be caused by eclipse overwriting the enhanced classes with plain classes. If the model (peristence) classes are in a separate module we could leave it out of eclipse and so this would be no issue anymore. Another advantage would be that the persistence tests could run in the persistence impl module so when working on the core they would not have to run each time. -- 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-199) Refocus on user deletion page
[ https://issues.apache.org/jira/browse/SYNCOPE-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13556249#comment-13556249 ] Hudson commented on SYNCOPE-199: Integrated in Syncope-trunk #448 (See [https://builds.apache.org/job/Syncope-trunk/448/]) SYNCOPE-199 Fix ability to close a modal page on pressing ESC key (Revision 1434678) Result = SUCCESS mdisabatino : Files : * /syncope/trunk/console/src/main/java/org/apache/syncope/console/commons/CloseOnESCBehavior.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/ApprovalModalPage.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/BaseModalPage.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/ConfigurationModalPage.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/ConnectorModalPage.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/DerivedSchemaModalPage.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/DisplayAttributesModalPage.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/MembershipModalPage.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/NotificationModalPage.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/PolicyModalPage.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/ReportExecResultDownloadModalPage.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/ReportModalPage.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/ReportletConfModalPage.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/ResourceModalPage.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/ResultStatusModalPage.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/RoleModalPage.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/RoleSelectModalPage.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/SchemaModalPage.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/StatusModalPage.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/TaskModalPage.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/UserModalPage.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/UserOwnerSelectModalPage.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/VirtualSchemaModalPage.java * /syncope/trunk/console/src/main/resources/org/apache/syncope/console/pages/BaseModalPage.html Refocus on user deletion page - Key: SYNCOPE-199 URL: https://issues.apache.org/jira/browse/SYNCOPE-199 Project: Syncope Issue Type: Improvement Reporter: Colm O hEigeartaigh Assignee: Marco Di Sabatino Di Diodoro Priority: Trivial Fix For: 1.1.0 SYNCOPE-189 added the ability to close a window on pressing ESC. It would be nice when deleting a user to automatically reselect the deletion page, so that the user can just press ESC to close the window. Currently you need to click on the deletion page before pressing ESC. -- 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: svn commit: r1434684 - in /syncope/trunk/archetype: pom.xml src/main/resources/archetype-resources/core/src/main/resources/activiticontent.xml src/main/resources/archetype-resources/core/src/main/
On 17.01.2013 15:46, Francesco Chicchiriccò wrote: On 17/01/2013 15:37, Christian Schneider wrote: I added the code to copy them too. I just committed them as they were reported changed. Should I delete the files and tell svn to ignore them? Just updated svn:ignore + removed again all local archetype resources from SVN. I will open an issue to change the resource population for archetype in order to be more robust to this kind of changes. I found that the AbstractDAOTests can not simply create the Activiti properties as the table is not there when we omit the spring xml to initialize Activiti. So I wanted to make the ContentLoader more flexible. This way I was able to replace the xsl based removal of Activiti properties by a java based one. I think this is better than xsl as it is more obvious to see in the code. It took me a while to see that the xsl does this... Did you take into any account the export procedure for subsequent re-import when changing this logic? Have you tried how this behaves in overlays generated from the archetype? Now we don't have any more a single content.xml (as generated by export generates) but two separate content.xml and activiticontent.xml I will open another issue to verify how export / import procedure will work after these changes. Hi Francesco, I am not aware how it works in the archetype. Can you explain shortly how the export works? I thought that we simply use the content.xml as a kind of template in the archetype and people would later simply change it. If it is a bigger issue I can revert the changes. They are not necessary for the issue SYNCOPE-241. Btw. I found that the ImportExport class mixes two things that seem to be quite independent. What do you think about splitting ImportExport into an ImportContent class and an ExportContent class? As far as I understood these functionalities seem to share no code in the ImportExport class. Regards Christian
RE: [Discussion] New REST Service Interfaces - Entitlements
Hi Jan, === Renaming Service === Rename AuthenticationController to EntitlementService(Impl), since containing methods have little to nothing to do with authentication. It is only about Entitlements... +1 for Entitlement, -1 for Service. I would keep names consistently, if use EntitlementService name, than rename all controllers to services inclusive package name (but I suggest to do it on the later phase). === Changing response Type === listEntitlements() returns a ListString whereas getEntitlements() returns a SetString. Option 1: EntitlementTOs EntitlementTOROLE_ADMIN/EntitlementTO EntitlementTOROLE_SUPERUSER/EntitlementTO /EntitlementTOs Option 2: EntitlementTOs EntitlementTO nameROLE_ADMIN/name /EntitlementTO EntitlementTO name ROLE_SUPERUSER /name /EntitlementTO /EntitlementTOs +1 for Option 2 And what I forgott to mention: listEntitlements and getEntitlements are not very self-explanatory. A better name would be getAllEntitlements and getMyEntitlements. +1 Cheers, Andrei.
Re: [Discussion] New REST Service Interfaces - Entitlements
On 17.01.2013 14:43, Fabio Martelli wrote: Il giorno 17/gen/2013, alle ore 14.03, Jan Bernhardt ha scritto: Hi Syncoper, The following changes are proposed regarding AuthenticationController: === Renaming Service === Rename AuthenticationController to EntitlementService(Impl), since containing methods have little to nothing to do with authentication. It is only about Entitlements... Why not AuthorizationController or AccessController? I'd prefer the first one. May be this controller will be improved to add access controller features int the next future (please, take a look at the roadmap). I agree with the names Fabio proposed. If it is planned to put more Authorization stuff in there then it makes sense to not have Entitlement in the name. Like Andrei proposed we should either rename all controllers to Service or none. If we rename them partly people will be confused. === Changing response Type === listEntitlements() returns a ListString whereas getEntitlements() returns a SetString. From my point of view both methods should return a SET since entitlements have no order and cannot exists or be assigned more than once. Agree I also agree with Set. Due to some JAX-B / JAX-RS limitations, it is not possible to return a collection with primitive data types in java. A wrapper class is required, e.g. SetEntitlementTO. EntitlementTO can be modeled in one of two ways: Option 1: EntitlementTOs EntitlementTOROLE_ADMIN/EntitlementTO EntitlementTOROLE_SUPERUSER/EntitlementTO /EntitlementTOs Option 2: EntitlementTOs EntitlementTO nameROLE_ADMIN/name /EntitlementTO EntitlementTO name ROLE_SUPERUSER /name /EntitlementTO /EntitlementTOs Option 1 matches more or less current marshaling. I personally would prefer Option 2 because this would give us the opportunity to easily extend EntitlementTO at a later point (if needed) without becoming incompatible with previous version. Agree with you for the reason given above. Not sure about this one as I do not know how probable it is that we have more attributes in Entitlement. Btw. I would rather name the xml element Entitlement than EntitlementTO as the fact that it is a transfer object is not important on the xml level. Christian WDYT? All of these changes will not apply to current Spring Controller/Services, but only future CXF REST Service. So AuthenticationController will not be renamed now, and responsetype of AuthenticationController will not change. Changes only apply for new Service Interface and (Proxy) Implementation. Good. Regards, F.
Re: [Discussion] CXF migration (branches)
On 17/01/2013 10:54, Jan Bernhardt wrote: Hi Francesco, [...] If, as it seems there is no other way out, I'd propose to move back the CXF migration to 1.1.0 (as actually OSGi is still there) so that no additional branch is created. This is valid as long as Spring MVC interfaces are still working as now, as you said above. Yes, Spring MVC interfaces will not be affected. Fine, as written elsewhere by Andrei in this mail thread it seems we have agreed about it: would you please adjust JIRA issues accordingly? In this way we will have a very fat 1.1.0 release, but at least we will be free to make a release when we feel it's ready. Later than currently expected, of course. When do you expect the 1.1.0 release? Since CXF related task will be done until end of this month, why do you think that this will delay the release? Just take a look at issues opened today... consolidation takes time, especially when keeping making architectural-level refactorings. However some changes could be done in trunk anyway, like removing client in package names: org.apache.syncope.client.mod -- org.apache.syncope.mod org.apache.syncope.client.report -- org.apache.syncope.report org.apache.syncope.client.search -- org.apache.syncope.search org.apache.syncope.client.to -- org.apache.syncope.to org.apache.syncope.client.validation -- org.apache.syncope.validation Could you please give a rationale for this? Currently, any submodule's root package reflects its own name: e.g. org.apache.syncope.core / org.apache.syncope.console / org.apache.syncope.client Almost all classes in client module are not specific to the client, but rather needed on client and server side, since they contain classes for exchanging data between client and server. Hence client module could better be renamed to common module. There is a JIRA ticket to eventually have a rich client in syncope, but currently I can only see a client in the console module in package org.apache.syncope.console.rest. Ok then why not introducing this new common maven submodule (as said in the past) with root package org.apache.syncope.common and then start moving away packages from client? Regards. -Original Message- From: Christian Schneider [mailto:cschneider...@gmail.com] On Behalf Of Christian Schneider Sent: Mittwoch, 16. Januar 2013 18:48 To: dev@syncope.apache.org Subject: Re: [Discussion] CXF migration (branches) Jan contacted me that the E-Mail Server in the Bonn office is currently down so he can not reply himself at the moment. So I am replying what he wrote me via Skype: We currently have the plan to finish the CXF migration during the next 1.5 weeks with 4 developers. The issue is a little urgent as from february on our normal product development team would like to take over and focus on making Syncope work nicely in OSGi. At this point we should have finished the CXF migration. Of course we can delay things a little but not too much without affecting our whole planning. Christian On 16.01.2013 16:08, Francesco Chicchiriccò wrote: On 16/01/2013 15:50, Jan Bernhardt wrote: Hi Syncopers, all preparation tasks are more or less done for CXF migration, so next we would like to start with actual CXF migration. Since we are planning to release Syncope 1.1.0 soon I can see two reasonable solutions to continue. 1. Creating a release branch for 1.1.0 and making sure this branch is stable and give it some time for additional test before official stable release will take place. CXF migration would start directly in trunk. 2. Creating a CXF branch and continue working on trunk for 1.1.0 release. I would prefer option 1 best. I think having a release branch prior to office release is a good practice in general. I expect quite some refactoring during CXF migration (which is not mandatory in all cases but expedient), for example renaming some packages (removing client from Types, TOs, ... since they are rather common classes used on server and client site than specific only to the client) and I would also like to rename *Controller classes to *ServiceImpl since these classes do not act as controller for a workflow or GUI but rather offer some REST services. SVN has some limitations to handle renamed files when it comes to merging updates. Thus it could be quite painful to keep a cxf branch in sync with trunk. WDYT? Could we start a release branch? Hi Jan, I generally agree with (1) even though I am not sure whether Syncope 1.1.0 release can actually happen soon: there is still a considerable number of issues to be solved (~20) and many changes introduced by SYNCOPE-241 SYNCOPE-259 SYNCOPE-268 (all still open) need to consolidate a bit. From the other side, 46+ issues have already been resolved in 1.1.0 and this would instead suggest pushing 1.1.0 for releasing soon. Finally, please consider that even with option (1) there will be some bugfixing in the 1_1_X branch (i.e. the current trunk) for long time; this will
[jira] [Updated] (SYNCOPE-229) Allow to change the bundle version associated to an existing connector instance
[ https://issues.apache.org/jira/browse/SYNCOPE-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated SYNCOPE-229: --- Summary: Allow to change the bundle version associated to an existing connector instance (was: When updating, allow to replace the connector instance associated to a given external resource) Allow to change the bundle version associated to an existing connector instance --- Key: SYNCOPE-229 URL: https://issues.apache.org/jira/browse/SYNCOPE-229 Project: Syncope Issue Type: Improvement Reporter: Francesco Chicchiriccò Fix For: 1.1.0 This is currently not possible: the connector instance can only be selected during external resource creation and cannot be changed any more. This has been done for the sake of safety, since the schema mapping is completely dependent on the underlying connector instance; from the other side, in this way it is hard, for example, to manage connector bundle upgrades (see [1]). It would be nice then to allow this kind of change, even at the price of scratching out the existing schema mapping of the resource being updated. [1] http://syncope-user.1051894.n5.nabble.com/csvdir-connector-td5706733.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] [Commented] (SYNCOPE-266) Password should be provided again at resource subscription time if a Password schema mapping for that resource exists
[ https://issues.apache.org/jira/browse/SYNCOPE-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13556403#comment-13556403 ] Hudson commented on SYNCOPE-266: Integrated in Syncope-1_0_X #110 (See [https://builds.apache.org/job/Syncope-1_0_X/110/]) SYNCOPE-266 - Fix for the branch 1_0_X (Revision 1434780) Result = SUCCESS fmartelli : Files : * /syncope/branches/1_0_X/core/src/main/java/org/apache/syncope/core/rest/data/UserDataBinder.java * /syncope/branches/1_0_X/core/src/test/java/org/apache/syncope/core/rest/UserTestITCase.java Password should be provided again at resource subscription time if a Password schema mapping for that resource exists --- Key: SYNCOPE-266 URL: https://issues.apache.org/jira/browse/SYNCOPE-266 Project: Syncope Issue Type: Improvement Components: core Affects Versions: 1.0.4, 1.0.5, 1.1.0 Reporter: fabio martelli Assignee: fabio martelli Fix For: 1.0.5, 1.1.0 In case of new resource subscription (explicitly or implicitly), password should be mandatory if and only if a mapping for internal attribute Password exists for that resource. If the new subscribed resource doesn't require password value, then a new password specification shouldn't be required. -- 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-266) Password should be provided again at resource subscription time if a Password schema mapping for that resource exists
[ https://issues.apache.org/jira/browse/SYNCOPE-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13556417#comment-13556417 ] Hudson commented on SYNCOPE-266: Integrated in Syncope-trunk #450 (See [https://builds.apache.org/job/Syncope-trunk/450/]) SYNCOPE-266 merged (Revision 1434790) Result = SUCCESS fmartelli : Files : * /syncope/trunk * /syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/data/UserDataBinder.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/UserTestITCase.java Password should be provided again at resource subscription time if a Password schema mapping for that resource exists --- Key: SYNCOPE-266 URL: https://issues.apache.org/jira/browse/SYNCOPE-266 Project: Syncope Issue Type: Improvement Components: core Affects Versions: 1.0.4, 1.0.5, 1.1.0 Reporter: fabio martelli Assignee: fabio martelli Fix For: 1.0.5, 1.1.0 In case of new resource subscription (explicitly or implicitly), password should be mandatory if and only if a mapping for internal attribute Password exists for that resource. If the new subscribed resource doesn't require password value, then a new password specification shouldn't be required. -- 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
