RE: [Discussion] New REST Service Interfaces - Entitlements
Hi Andrei, === 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). Names will be Consistent. New CXF REST Services will all End with *Service. Old Spring Services currently ending with *Controller will eventually all vanish, once new Services are actually used (migration is complete). Best regards. Jan
RE: [Discussion] CXF migration (branches)
Hi Francesco, -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Donnerstag, 17. Januar 2013 17:47 To: dev@syncope.apache.org Subject: 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? I will take care of this. 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? +1 Supposed that no one disagrees, I will create a Jira ticket for this task and take care of this. Since this refactoring will effect most classes. I would do this Monday morning. So all committers could use the time until Sunday to get their changes committed and thus avoiding a bigger merging effort after this refactoring. But rather than introducing a new module I would like to rename client module to common (including client to common in package names). When I did my CXF PoC (see CXF branch), I noticed that all packages except for org.apache.syncope.client.http are needed in common. Syncope-150 will introduce a rich client library. My proposal would be to move org.apache.syncope.client.http to console, since org.apache.syncope.console.rest is in console and also rich client related. Once we take care of Syncope-150 we can (re)create a client module and then move both packages to this module. Does this sound reasonable? Best regards. Jan 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 push a consistent and constant merge work to be done between 1_1_X and new trunk. Given this situation, I would
RE: [Discussion] New REST Service Interfaces - Entitlements
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. I agree. Not using *TO ending would look nicer on transport layer. The question here is, should we also remove TO in Classnames, or just set a name in annotation, e.g. @XMLRootElement(name = entitlement) ? Christian
Re: [Discussion] New REST Service Interfaces - Entitlements
I would rather do it in the annotations. Internally we often have a internal class without TO and a transfer object that ends in TO. So I think it makes sense to differentiate them on the class level. Christian On 18.01.2013 09:51, Jan Bernhardt wrote: 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. I agree. Not using *TO ending would look nicer on transport layer. The question here is, should we also remove TO in Classnames, or just set a name in annotation, e.g. @XMLRootElement(name = entitlement) ? Christian
RE: [Discussion] New REST Service Interfaces - Entitlements
Names will be Consistent. New CXF REST Services will all End with *Service. Old Spring Services currently ending with *Controller will eventually all vanish, once new Services are actually used (migration is complete). Than is absolutely OK for me. + 1. Andrei. Best regards. Jan
[jira] [Updated] (SYNCOPE-268) Enable Rest IntegrationTests to run more than once (per build)
[
https://issues.apache.org/jira/browse/SYNCOPE-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Bernhardt updated SYNCOPE-268:
--
Assignee: Andrei Shakirin (was: Jan Bernhardt)
Enable Rest IntegrationTests to run more than once (per build)
--
Key: SYNCOPE-268
URL: https://issues.apache.org/jira/browse/SYNCOPE-268
Project: Syncope
Issue Type: Improvement
Components: core
Reporter: Jan Bernhardt
Assignee: Andrei Shakirin
Labels: test
Fix For: 1.1.0
Attachments: RerunnableRestIntegrationTests-1.patch,
RerunnableRestIntegrationTests-2.patch
Currently many Rest IntegrationTests can run only once. If you try to rerun
some Tests they will fail, due to the fact, that a resource with the same
same already exists, or that a resource was deleted previously and is not
available any longer. This works fine for mvn clean verify since all test
run exactly once. But for development phase this is inconvenient, because
while testing new features or other refactorings, one would like to run tests
several times (especially if they fail), without the need to
rebuild/package/deploy the whole core module.
Tasks of this JIRA ticket is to use random identifier for resources (user,
role, ...) to avoid collisions, when running tests multiple times. In some
cases it will also be preferable to use a try { } final { } statement to
cleanup previously created 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
[jira] [Commented] (SYNCOPE-268) Enable Rest IntegrationTests to run more than once (per build)
[
https://issues.apache.org/jira/browse/SYNCOPE-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13557213#comment-13557213
]
Andrei Shakirin commented on SYNCOPE-268:
-
Actually all tests are re-runnable except TaskTestITCase.deal().
I didn't find reliable way to create PropagationTask dynamically, execute it
and update it via taskService.report() how it done in test.
If there are no any objections I will close the issue.
Enable Rest IntegrationTests to run more than once (per build)
--
Key: SYNCOPE-268
URL: https://issues.apache.org/jira/browse/SYNCOPE-268
Project: Syncope
Issue Type: Improvement
Components: core
Reporter: Jan Bernhardt
Assignee: Andrei Shakirin
Labels: test
Fix For: 1.1.0
Attachments: RerunnableRestIntegrationTests-1.patch,
RerunnableRestIntegrationTests-2.patch
Currently many Rest IntegrationTests can run only once. If you try to rerun
some Tests they will fail, due to the fact, that a resource with the same
same already exists, or that a resource was deleted previously and is not
available any longer. This works fine for mvn clean verify since all test
run exactly once. But for development phase this is inconvenient, because
while testing new features or other refactorings, one would like to run tests
several times (especially if they fail), without the need to
rebuild/package/deploy the whole core module.
Tasks of this JIRA ticket is to use random identifier for resources (user,
role, ...) to avoid collisions, when running tests multiple times. In some
cases it will also be preferable to use a try { } final { } statement to
cleanup previously created 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
[jira] [Commented] (SYNCOPE-252) Update LICENSE / NOTICE files for any added or removed Maven dependency
[ https://issues.apache.org/jira/browse/SYNCOPE-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13557214#comment-13557214 ] Jan Bernhardt commented on SYNCOPE-252: --- I decided to use Jackson instead of Jettision, as this was used also by spring object mapper. So I only had to add Apache CXF dependencies. Hence I would expect that this task can be closed without making any changes to Licence and Notice. Am I correct, or do I need to check every cxf artifact for embedded components with different licenses ? Update LICENSE / NOTICE files for any added or removed Maven dependency --- Key: SYNCOPE-252 URL: https://issues.apache.org/jira/browse/SYNCOPE-252 Project: Syncope Issue Type: Sub-task Components: console, core Reporter: Francesco Chicchiriccò Fix For: 1.2.0 If you are adding (or removing) any non-ASF dependency, please take also care of LICENSE and NOTICE content either at root (included in source and JAR release files) and under legal_ext (for WAR and ZIP release files). -- 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-252) Update LICENSE / NOTICE files for any added or removed Maven dependency
[ https://issues.apache.org/jira/browse/SYNCOPE-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13557224#comment-13557224 ] Francesco Chicchiriccò commented on SYNCOPE-252: If you are only explicitly adding org.apache.* dependencies (like as CXF), no action is required on root LICENSE and NOTICE (but I see at least javax.ws.rs:javax.ws.rs-api:2.0-m15 in root POM). Anyway, you also have to take a look at generated WAR files (core / console / build-tools) and verify, for any JAR file included under WEB-INF/lib, if there is an entry in legal_ext/LICENSE and legal_ext/NOTICE. ASF JAR files are of course not to be considered during this check. Most of JAR files under some WEB-INF/lib have already their own entries in legal_ext's LICENSE and NOTICE, but new dependencies have possibly added something else. In all this I assume you haven't added any 3rd party source code. Update LICENSE / NOTICE files for any added or removed Maven dependency --- Key: SYNCOPE-252 URL: https://issues.apache.org/jira/browse/SYNCOPE-252 Project: Syncope Issue Type: Sub-task Components: console, core Reporter: Francesco Chicchiriccò Fix For: 1.2.0 If you are adding (or removing) any non-ASF dependency, please take also care of LICENSE and NOTICE content either at root (included in source and JAR release files) and under legal_ext (for WAR and ZIP release files). -- 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=13557241#comment-13557241 ] Hudson commented on SYNCOPE-231: Integrated in Syncope-trunk #452 (See [https://builds.apache.org/job/Syncope-trunk/452/]) [SYNCOPE-231] * Enabling some first CXF Webservices. * Code cleanup (adding final to method parameters) (Revision 1435135) Result = SUCCESS jbernhardt : Files : * /syncope/trunk/archetype * /syncope/trunk/client * /syncope/trunk/client/src/main/java/org/apache/syncope/client/to/ConfigurationTO.java * /syncope/trunk/client/src/main/java/org/apache/syncope/client/to/EntitlementTO.java * /syncope/trunk/client/src/main/java/org/apache/syncope/client/to/MailTemplateTO.java * /syncope/trunk/client/src/main/java/org/apache/syncope/client/to/ValidatorTO.java * /syncope/trunk/client/src/main/java/org/apache/syncope/client/util/CollectionWrapper.java * /syncope/trunk/client/src/main/java/org/apache/syncope/services/ConfigurationService.java * /syncope/trunk/client/src/main/java/org/apache/syncope/services/EntitlementService.java * /syncope/trunk/client/src/main/java/org/apache/syncope/services/proxy/ConfigurationServiceProxy.java * /syncope/trunk/client/src/main/java/org/apache/syncope/services/proxy/EntitlementServiceProxy.java * /syncope/trunk/client/src/main/java/org/apache/syncope/services/proxy/SpringServiceProxy.java * /syncope/trunk/console * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/Login.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/rest/AuthRestClient.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/rest/ConfigurationRestClient.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/rest/NotificationRestClient.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/rest/SchemaRestClient.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/rest/UserRestClient.java * /syncope/trunk/console/src/main/resources/applicationContext.xml * /syncope/trunk/core * /syncope/trunk/core/pom.xml * /syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/QueryResourceInfoComperator.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/RestServiceExceptionMapper.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/services * /syncope/trunk/core/src/main/java/org/apache/syncope/core/services/ConfigurationServiceImpl.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/services/ContextAware.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/services/DummyHTTPServletResponse.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/services/EntitlementServiceImpl.java * /syncope/trunk/core/src/main/resources/restContext.xml * /syncope/trunk/core/src/main/webapp/WEB-INF/web.xml * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/AuthenticationTestITCase.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/ConfigurationTestITCase.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/UserRequestTestITCase.java * /syncope/trunk/core/src/test/resources/restClientContext.xml * /syncope/trunk/pom.xml * /syncope/trunk/standalone 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 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] [Commented] (SYNCOPE-268) Enable Rest IntegrationTests to run more than once (per build)
[
https://issues.apache.org/jira/browse/SYNCOPE-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13557240#comment-13557240
]
Hudson commented on SYNCOPE-268:
Integrated in Syncope-trunk #452 (See
[https://builds.apache.org/job/Syncope-trunk/452/])
[SYNCOPE-268] Make rest integration tests re-runnable (Revision 1435132)
Result = SUCCESS
ashakirin :
Files :
*
/syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/TaskTestITCase.java
*
/syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/UserTestITCase.java
Enable Rest IntegrationTests to run more than once (per build)
--
Key: SYNCOPE-268
URL: https://issues.apache.org/jira/browse/SYNCOPE-268
Project: Syncope
Issue Type: Improvement
Components: core
Reporter: Jan Bernhardt
Assignee: Andrei Shakirin
Labels: test
Fix For: 1.1.0
Attachments: RerunnableRestIntegrationTests-1.patch,
RerunnableRestIntegrationTests-2.patch
Currently many Rest IntegrationTests can run only once. If you try to rerun
some Tests they will fail, due to the fact, that a resource with the same
same already exists, or that a resource was deleted previously and is not
available any longer. This works fine for mvn clean verify since all test
run exactly once. But for development phase this is inconvenient, because
while testing new features or other refactorings, one would like to run tests
several times (especially if they fail), without the need to
rebuild/package/deploy the whole core module.
Tasks of this JIRA ticket is to use random identifier for resources (user,
role, ...) to avoid collisions, when running tests multiple times. In some
cases it will also be preferable to use a try { } final { } statement to
cleanup previously created 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
RE: Exception propagation in Rest interface: HTTP header vs body for details
I don't understand why WorkflowException should be mapped to INTERNAL_SERVER_ERROR: you get workflow exceptions when something is not allowed within the current workflow instance, for example. There is no error on the server, the error is on the client asking for a workflow action not available for various reasons. As far as I see, WorkflowException also wraps ActivitiException thrown by runtimeService, that can indicate problems with Activiti engine. Anyway I do not have strong opinion regarding WorkflowException, if you think it is mostly causes by wrong client argument, let set it back to BAD_REQUEST. Similarly for PersistenceException - thrown for example when a duplicate key is found: this is not happening (under normal conditions) for a server fault but for a client's. Normally, in case of duplicate keys DataIntegrityViolationException is thrown (mapped to HTTP.CONFLICT). org.apache.ibatis.exceptions.PersistenceException can indicate following: - error building SqlSession; - error parsing SQL Mapper Configuration; - cache problem; - session problem; - transaction exception IMO it mostly caused by server errors as by wrong client request - not absolutely sure. Regards, Andrei. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Freitag, 18. Januar 2013 15:20 To: dev@syncope.apache.org Subject: Re: Exception propagation in Rest interface: HTTP header vs body for details On 18/01/2013 15:04, Andrei Shakirin wrote: Hi, From proposals regarding remote exceptions in [1], I am going to do the following during CXF migration: 1) Update HTTP mapping codes (see Mapping exceptions to HTTP codes) I don't understand why WorkflowException should be mapped to INTERNAL_SERVER_ERROR: you get workflow exceptions when something is not allowed within the current workflow instance, for example. There is no error on the server, the error is on the client asking for a workflow action not available for various reasons. Similarly for PersistenceException - thrown for example when a duplicate key is found: this is not happening (under normal conditions) for a server fault but for a client's. 2) Update some checked exceptions to runtime ones (see Checked vs Runtime exceptions) Sounds reasonable. Regards. -Original Message- From: Andrei Shakirin [mailto:ashaki...@talend.com] Sent: Montag, 7. Januar 2013 10:01 To: dev@syncope.apache.org Subject: RE: Exception propagation in Rest interface: HTTP header vs body for details I have tried to summarize remote exceptions mapping as well as some improvement ideas in [1]. [1] is also linked from [2]. Review, remarks, discussions are welcome. Cheers, Andrei. [1] https://cwiki.apache.org/confluence/display/SYNCOPE/Remote+Exceptions [2] https://cwiki.apache.org/confluence/display/SYNCOPE/REST+API+upgrade -Original Message- From: Andrei Shakirin [mailto:ashaki...@talend.com] Sent: Freitag, 14. Dezember 2012 09:37 To: dev@syncope.apache.org Subject: RE: Exception propagation in Rest interface: HTTP header vs body for details Yep, will go this way: keep current propagation one to one plus more verbose exception in HTTP body (perhaps on the second step). Thanks for participating in discussion. Cheers, Andrei. -Original Message- From: Sergey Beryozkin [mailto:sberyoz...@gmail.com] Sent: Donnerstag, 13. Dezember 2012 18:34 To: dev@syncope.apache.org Subject: Re: Exception propagation in Rest interface: HTTP header vs body for details On 13/12/12 16:45, Francesco Chicchiriccò wrote: On 13/12/2012 14:27, Sergey Beryozkin wrote: Hi On 13/12/12 12:42, Andrei Shakirin wrote: Hi, I am working on Rest interface migration (to Apache CXF) and analysing exception propagation from service to client. Actually SyncopeClientCompositeErrorException is sent using: a) ExceptionType HTTP header containing exception type (enumeration SyncopeClientExceptionType) b)ExceptionType.element HTTP header as list of strings for error details (that are used to fill SyncopeClientException.elements) I find that fine at the moment, as far as details information is only simple and short list of strings. Potentially it is possible to have more complex and long structures in exception details. Therefore the question is does it make sense to use HTTP header only for ExceptionType and send details in HTTP body? It means that we will change network protocol between client and service, not sure how critical it is for existing Syncope users. There are 2 alternatives: a) leave the propagation as it is: send type and details in HTTP headers. In the future additional information exceptional still can be sent with HTTP body. b) send only ExceptionType in HTTP header and details element in HTTP body. Do you have any preferences for (a) and (b) or there
[jira] [Commented] (SYNCOPE-252) Update LICENSE / NOTICE files for any added or removed Maven dependency
[ https://issues.apache.org/jira/browse/SYNCOPE-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13557253#comment-13557253 ] Jan Bernhardt commented on SYNCOPE-252: --- Yes, you are right, javax.ws.rs:javax.ws.rs-api:2.0-m15 was also added previously. I just checked the lib file which does not contain any LICENSE or NOTICE file. Since handling license issues is a rather new topic to me, what do I need to do here? Is a LICENSE / NOTICE not required here, since it is a javax package? And yes, no other 3rd party code was needed / added for CXF migration. Update LICENSE / NOTICE files for any added or removed Maven dependency --- Key: SYNCOPE-252 URL: https://issues.apache.org/jira/browse/SYNCOPE-252 Project: Syncope Issue Type: Sub-task Components: console, core Reporter: Francesco Chicchiriccò Fix For: 1.2.0 If you are adding (or removing) any non-ASF dependency, please take also care of LICENSE and NOTICE content either at root (included in source and JAR release files) and under legal_ext (for WAR and ZIP release files). -- 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-252) Update LICENSE / NOTICE files for any added or removed Maven dependency
[ https://issues.apache.org/jira/browse/SYNCOPE-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13557261#comment-13557261 ] Francesco Chicchiriccò commented on SYNCOPE-252: About javax.ws.rs-api, according to [1], license is CDDL 1.0 (or GPL, but this is not allowed): since the CDDL 1.0 has already been included in LICENSE and legal_ext/LICENSE, you don't need to change these. You still need, however, to update legal_ext/NOTICE with a copyright attribution to Oracle Corporation (read from [1]). About the rest (e.g. examine core / console / build-tools WAR files' WEB-INF/lib content), this has still to be done. This because, even though you haven't added anything but CXF deps, the Maven dependency resolution mechanism might have ended with some JAR file in WEB-INF/lib not yet captured in legal_ext's LICENSE and NOTICE. As said, any ASF JAR file can be skipped. [1] http://search.maven.org/remotecontent?filepath=javax/ws/rs/javax.ws.rs-api/2.0-m15/javax.ws.rs-api-2.0-m15.pom Update LICENSE / NOTICE files for any added or removed Maven dependency --- Key: SYNCOPE-252 URL: https://issues.apache.org/jira/browse/SYNCOPE-252 Project: Syncope Issue Type: Sub-task Components: console, core Reporter: Francesco Chicchiriccò Fix For: 1.2.0 If you are adding (or removing) any non-ASF dependency, please take also care of LICENSE and NOTICE content either at root (included in source and JAR release files) and under legal_ext (for WAR and ZIP release files). -- 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=13557307#comment-13557307 ] Hudson commented on SYNCOPE-231: Integrated in Syncope-trunk #454 (See [https://builds.apache.org/job/Syncope-trunk/454/]) [SYNCOPE-231] Moved implementation classes to impl sub-package. (Revision 1435174) Result = SUCCESS jbernhardt : Files : * /syncope/trunk/core/src/main/java/org/apache/syncope/core/services/ConfigurationServiceImpl.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/services/ContextAware.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/services/DummyHTTPServletResponse.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/services/EntitlementServiceImpl.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/services/impl * /syncope/trunk/core/src/main/java/org/apache/syncope/core/services/impl/ConfigurationServiceImpl.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/services/impl/ContextAware.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/services/impl/DummyHTTPServletResponse.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/services/impl/EntitlementServiceImpl.java * /syncope/trunk/core/src/main/resources/restContext.xml 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 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] [Commented] (SYNCOPE-280) Update some checked exceptions to runtime ones
[ https://issues.apache.org/jira/browse/SYNCOPE-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13557319#comment-13557319 ] Andrei Shakirin commented on SYNCOPE-280: - InvalidPolicyType will be also inherited from RuntimeException Update some checked exceptions to runtime ones -- Key: SYNCOPE-280 URL: https://issues.apache.org/jira/browse/SYNCOPE-280 Project: Syncope Issue Type: Improvement Reporter: Andrei Shakirin Assignee: Andrei Shakirin Accordingly Java Best Practices checked exceptions should be used only for conditions from which the caller can reasonably be expected to recover. Runtime exceptions should be used for preconditions violation and for programming errors. Candidates for checked exceptions are: - InvalidSearchConditionException - NotFoundException Candidates for runtime exceptions: - all Validation exceptions inherited from javax.validation.ValidationException - MissingConfKeyException - AccountPolicyException - PasswordPolicyException - PolicyEnforceException - IncompatiblePolicyException - UnauthorizedRoleException - PropagationException - ReportException - WorkflowException -- 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] [Resolved] (SYNCOPE-268) Enable Rest IntegrationTests to run more than once (per build)
[
https://issues.apache.org/jira/browse/SYNCOPE-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Shakirin resolved SYNCOPE-268.
-
Resolution: Fixed
Enable Rest IntegrationTests to run more than once (per build)
--
Key: SYNCOPE-268
URL: https://issues.apache.org/jira/browse/SYNCOPE-268
Project: Syncope
Issue Type: Improvement
Components: core
Reporter: Jan Bernhardt
Assignee: Andrei Shakirin
Labels: test
Fix For: 1.1.0
Attachments: RerunnableRestIntegrationTests-1.patch,
RerunnableRestIntegrationTests-2.patch
Currently many Rest IntegrationTests can run only once. If you try to rerun
some Tests they will fail, due to the fact, that a resource with the same
same already exists, or that a resource was deleted previously and is not
available any longer. This works fine for mvn clean verify since all test
run exactly once. But for development phase this is inconvenient, because
while testing new features or other refactorings, one would like to run tests
several times (especially if they fail), without the need to
rebuild/package/deploy the whole core module.
Tasks of this JIRA ticket is to use random identifier for resources (user,
role, ...) to avoid collisions, when running tests multiple times. In some
cases it will also be preferable to use a try { } final { } statement to
cleanup previously created 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
[jira] [Assigned] (SYNCOPE-244) Make external property file usage possible
[
https://issues.apache.org/jira/browse/SYNCOPE-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò reassigned SYNCOPE-244:
--
Assignee: Francesco Chicchiriccò
Make external property file usage possible
--
Key: SYNCOPE-244
URL: https://issues.apache.org/jira/browse/SYNCOPE-244
Project: Syncope
Issue Type: Improvement
Components: console
Affects Versions: 1.1.0
Reporter: Ernst Vorsteveld
Assignee: Francesco Chicchiriccò
Priority: Minor
Fix For: 1.1.0
Syncope console has a property file named configuration.properties, that
contains property values which are environment specific.
Everytime Syncope is installed on some servlet container, I need to do a
change property values in configuration.properties for the environment I am
working on and do a build.
I think that it is possible to move the configuration.properties out of the
build, and configure the properties in a file per environment.
We could do this by changing the
console/src/main/resources/applicationContext.xml.
Now the context file has for the configuration.properties file:
bean id=propertyConfigurer
class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
property name=locations
list
valueclasspath:configuration.properties/value
/list
/property
/bean
If we change this and add another bean:
bean id=propertyConfigurer2
class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
property name=order value=1/
property name=location
value=file:#{(systemProperties['user.home'] +
'/.configuration.properties')}/
property name=ignoreResourceNotFound value=true/
property name=ignoreUnresolvablePlaceholders value=true/
/bean
We only have to create a .configuration.properties file in the home directory
of the user that runs the servlet container on which syncope is deployed. If
the file is not found, it still the default configuration.properties file
from within the war file is used.
--
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
