Syncope-1_0_X - Build # 87 - Still Unstable
The Apache Jenkins build system has built Syncope-1_0_X (build #87) Status: Still Unstable Check console output at https://builds.apache.org/job/Syncope-1_0_X/87/ to view the results.
Syncope-trunk - Build # 377 - Still Unstable
The Apache Jenkins build system has built Syncope-trunk (build #377) Status: Still Unstable Check console output at https://builds.apache.org/job/Syncope-trunk/377/ to view the results.
Syncope-trunk - Build # 378 - Fixed
The Apache Jenkins build system has built Syncope-trunk (build #378) Status: Fixed Check console output at https://builds.apache.org/job/Syncope-trunk/378/ to view the results.
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 are other alternatives? Perhaps it might make sense to keep a simple HTTP header anyway, for the receivers to be optionally able to quickly check the exception type without having to read the response, and also return the body with all the details, including the actual exception type, so that the whole info can then be analyzed on the client side after the request has been completed, so one more possible option :-) Hi, I like this (c) option as well: 1. ExceptionType + elements in the HTTP header (like as now) 2. HTML (short) body with more verbose description, possibly localized (1) could be used by 3rd party REST clients while (2) could be used to provide better error message for admin console. Hi, I'm rereading and I guess I may've repeated what Andrei already suggested with his option a) :-) Either way, looks like we all in agreement Cheers, Sergey Regards.
Syncope-1_0_X - Build # 88 - Fixed
The Apache Jenkins build system has built Syncope-1_0_X (build #88) Status: Fixed Check console output at https://builds.apache.org/job/Syncope-1_0_X/88/ to view the results.
[jira] [Commented] (SYNCOPE-242) Resolve dependency cycles between persistence and the rest of syncope core
[ https://issues.apache.org/jira/browse/SYNCOPE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13532345#comment-13532345 ] Jean-Baptiste Onofré commented on SYNCOPE-242: -- I reviewed the patch: - syntax looks good - design looks good as well It sounds fine for me. @Francesco, let me know if you want that I apply the patch. Resolve dependency cycles between persistence and the rest of syncope core -- Key: SYNCOPE-242 URL: https://issues.apache.org/jira/browse/SYNCOPE-242 Project: Syncope Issue Type: Improvement Affects Versions: 1.0.3-incubating Reporter: Christian Schneider Fix For: 1.1.0 Attachments: SYNCOPE-242-1.patch, SYNCOPE-242-2.patch, SYNCOPE-242-fromtgz.patch, syncope_core_after.png, syncope_core_before.png, syncope.tgz When analysing if we could move the persistence and persistence impl into separate modules I found that there are a lot of dependency cycles in the syncope core module. I have added a structure 101 diagram of the cycles to the issue so you can take a look. Especially the cycles between persistence and the rest of core are important as they prevent us from moving these packages out of core. I have already done some experimentations how to solve the cycles and am pretty sure I can fix that. -- 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-242) Resolve dependency cycles between persistence and the rest of syncope core
[ https://issues.apache.org/jira/browse/SYNCOPE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré reassigned SYNCOPE-242: Assignee: Jean-Baptiste Onofré Resolve dependency cycles between persistence and the rest of syncope core -- Key: SYNCOPE-242 URL: https://issues.apache.org/jira/browse/SYNCOPE-242 Project: Syncope Issue Type: Improvement Affects Versions: 1.0.3-incubating Reporter: Christian Schneider Assignee: Jean-Baptiste Onofré Fix For: 1.1.0 Attachments: SYNCOPE-242-1.patch, SYNCOPE-242-2.patch, SYNCOPE-242-fromtgz.patch, syncope_core_after.png, syncope_core_before.png, syncope.tgz When analysing if we could move the persistence and persistence impl into separate modules I found that there are a lot of dependency cycles in the syncope core module. I have added a structure 101 diagram of the cycles to the issue so you can take a look. Especially the cycles between persistence and the rest of core are important as they prevent us from moving these packages out of core. I have already done some experimentations how to solve the cycles and am pretty sure I can fix that. -- 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-242) Resolve dependency cycles between persistence and the rest of syncope core
[ https://issues.apache.org/jira/browse/SYNCOPE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13532348#comment-13532348 ] Jean-Baptiste Onofré commented on SYNCOPE-242: -- OK, fine, I will. Thanks. Resolve dependency cycles between persistence and the rest of syncope core -- Key: SYNCOPE-242 URL: https://issues.apache.org/jira/browse/SYNCOPE-242 Project: Syncope Issue Type: Improvement Affects Versions: 1.0.3-incubating Reporter: Christian Schneider Assignee: Jean-Baptiste Onofré Fix For: 1.1.0 Attachments: SYNCOPE-242-1.patch, SYNCOPE-242-2.patch, SYNCOPE-242-fromtgz.patch, syncope_core_after.png, syncope_core_before.png, syncope.tgz When analysing if we could move the persistence and persistence impl into separate modules I found that there are a lot of dependency cycles in the syncope core module. I have added a structure 101 diagram of the cycles to the issue so you can take a look. Especially the cycles between persistence and the rest of core are important as they prevent us from moving these packages out of core. I have already done some experimentations how to solve the cycles and am pretty sure I can fix that. -- 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-255) Hide Global Password/Account/Sync policy in security resource selections
[ https://issues.apache.org/jira/browse/SYNCOPE-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated SYNCOPE-255: --- Fix Version/s: 1.0.5 Hide Global Password/Account/Sync policy in security resource selections Key: SYNCOPE-255 URL: https://issues.apache.org/jira/browse/SYNCOPE-255 Project: Syncope Issue Type: Improvement Components: console Affects Versions: 1.0.4 Environment: Any Reporter: Denis Signoretto Priority: Minor Fix For: 1.0.5 related discussion: http://syncope-user.1051894.n5.nabble.com/Differences-about-simple-and-global-password-and-account-policies-td5706812.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] [Created] (SYNCOPE-256) Update Rest exception mapper to Apache CXF
Andrei Shakirin created SYNCOPE-256: --- Summary: Update Rest exception mapper to Apache CXF Key: SYNCOPE-256 URL: https://issues.apache.org/jira/browse/SYNCOPE-256 Project: Syncope Issue Type: Improvement Components: client, core Environment: CXF branch Reporter: Andrei Shakirin Assignee: Jan Bernhardt Spring exception mapper is replaced to CXF one and configured as provider in rest endpoint and client. Converting of exceptions to HTTP error codes on service side is also done by exception mapper. -- 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
