Re: GIT mirror
Side question: I've seen the GIT mirror is also on github: is there anything special to do to map ASF ids with github's? Thanks. On 06/02/2013 11:42, Colm O hEigeartaigh wrote: Hi all, I take it there are no objections if I go ahead and ask INFRA to create a GIT mirror of the Apache Syncope SVN tree? http://git.apache.org/ http://wiki.apache.org/general/GitAtApache It doesn't have any implications beyond allowing committers to use git-svn if they prefer. Colm. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[jira] [Updated] (SYNCOPE-265) Ensure that Syncope test data is consistent
[ https://issues.apache.org/jira/browse/SYNCOPE-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated SYNCOPE-265: --- Description: This task is to ensure that the test data is consistent since it is used for embedded mode [1] and in standalone distribution (as per SYNCOPE-206). For example, Users do not conform to the Schema: currently user1 is missing values for the required attributes surname and userId. [1] https://cwiki.apache.org/confluence/display/SYNCOPE/Run+Syncope+in+embedded+mode was: This task is to ensure that the test data is consistent since it is used for embedded mode [1] and in standalone distribution (as per SYNCOPE-). For example, Users do not conform to the Schema: currently user1 is missing values for the required attributes surname and userId. [1] https://cwiki.apache.org/confluence/display/SYNCOPE/Run+Syncope+in+embedded+mode Ensure that Syncope test data is consistent --- Key: SYNCOPE-265 URL: https://issues.apache.org/jira/browse/SYNCOPE-265 Project: Syncope Issue Type: Task Reporter: Colm O hEigeartaigh Assignee: Massimiliano Perrone Priority: Minor Fix For: 1.1.0 This task is to ensure that the test data is consistent since it is used for embedded mode [1] and in standalone distribution (as per SYNCOPE-206). For example, Users do not conform to the Schema: currently user1 is missing values for the required attributes surname and userId. [1] https://cwiki.apache.org/confluence/display/SYNCOPE/Run+Syncope+in+embedded+mode -- 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-265) Ensure that Syncope test data is consistent
[ https://issues.apache.org/jira/browse/SYNCOPE-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13573330#comment-13573330 ] Francesco Chicchiriccò commented on SYNCOPE-265: Since the scope of this issue seems to be broader than originally expected, I've updated title and description accordingly. Ensure that Syncope test data is consistent --- Key: SYNCOPE-265 URL: https://issues.apache.org/jira/browse/SYNCOPE-265 Project: Syncope Issue Type: Task Reporter: Colm O hEigeartaigh Assignee: Massimiliano Perrone Priority: Minor Fix For: 1.1.0 This task is to ensure that the test data is consistent since it is used for embedded mode [1] and in standalone distribution (as per SYNCOPE-206). For example, Users do not conform to the Schema: currently user1 is missing values for the required attributes surname and userId. [1] https://cwiki.apache.org/confluence/display/SYNCOPE/Run+Syncope+in+embedded+mode -- 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-265) Ensure that Syncope test data is consistent
[ https://issues.apache.org/jira/browse/SYNCOPE-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13573420#comment-13573420 ] Hudson commented on SYNCOPE-265: Integrated in Syncope-trunk #72 (See [https://builds.apache.org/job/Syncope-trunk/72/]) [SYNCOPE-265] Renaming ws-target-resource-3 to ws-target-resource-timeout (Revision 1443410) [SYNCOPE-265] ldap connector: configuration was valid, the problem was an incorrect handling of empty properties during check() (Revision 1443400) Result = SUCCESS ilgrosso : Files : * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/UserTestITCase.java * /syncope/trunk/core/src/test/resources/content.xml ilgrosso : Files : * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/ConnectorModalPage.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/panels/ResourceConnConfPanel.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/rest/ConnectorRestClient.java * /syncope/trunk/console/src/main/resources/org/apache/syncope/console/pages/panels/ResourceConnConfPanel.html Ensure that Syncope test data is consistent --- Key: SYNCOPE-265 URL: https://issues.apache.org/jira/browse/SYNCOPE-265 Project: Syncope Issue Type: Task Reporter: Colm O hEigeartaigh Assignee: Massimiliano Perrone Priority: Minor Fix For: 1.1.0 This task is to ensure that the test data is consistent since it is used for embedded mode [1] and in standalone distribution (as per SYNCOPE-206). For example, Users do not conform to the Schema: currently user1 is missing values for the required attributes surname and userId. [1] https://cwiki.apache.org/confluence/display/SYNCOPE/Run+Syncope+in+embedded+mode -- 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
Syncope-trunk - Build # 73 - Unstable
The Apache Jenkins build system has built Syncope-trunk (build #73) Status: Unstable Check console output at https://builds.apache.org/job/Syncope-trunk/73/ to view the results.
Syncope-trunk - Build # 74 - Aborted
The Apache Jenkins build system has built Syncope-trunk (build #74) Status: Aborted Check console output at https://builds.apache.org/job/Syncope-trunk/74/ to view the results.
Re: Wicket question
Hi Fabio, Thanks for your reply. The problem is that the FieldPanel template is constructed and cloned before the Virtual Attribute is selected from the Drop Down list. Therefore, if it is a new attribute that is being added, we don't know at the point of cloning whether the Virtual Attribute name that will be selected will be read-only or not. Once the selection is made, I have no way of setting ReadOnly on the cloned object. Does that make sense? Colm. On Thu, Feb 7, 2013 at 8:54 AM, Fabio Martelli fabio.marte...@gmail.comwrote: Il giorno 04/feb/2013, alle ore 18.39, Colm O hEigeartaigh ha scritto: Hi all, Perhaps this is extremely obvious... I'm running into a problem with a fix for SYNCOPE-215. Essentially there is a drop down list of Virtual attribute names, and I want to make the corresponding text field read-only if the Virtual attribute that is selected is read-only. The DropDownChoice object in VirtualAttributesPanel already has an onblur component that allows me to see what was selected. The problem is that the Panel object corresponding to the text field, is passed through to a MultiValueSelectorPanel object, which clones it: final FieldPanel fieldPanel = panelTemplate.clone(); So even if I call setReadOnly on the panel in VirtualAttributesPanel, the text field does not turn read-only. Is there an obvious way to solve this problem? Hi Colm, I think that setReadOnly method on the field panel template should solve your problem. The clone method is overridden into FildPanel class. This method set the read only value explicitly: panel.setReadOnly(isReadOnly()); Have you already tried by calling the setReadOnly method on the field panel template? Best regards, F. -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
Re: Wicket question
Il giorno 07/feb/2013, alle ore 16.51, Colm O hEigeartaigh ha scritto: Hi Fabio, Thanks for your reply. The problem is that the FieldPanel template is constructed and cloned before the Virtual Attribute is selected from the Drop Down list. Therefore, if it is a new attribute that is being added, we don't know at the point of cloning whether the Virtual Attribute name that will be selected will be read-only or not. Once the selection is made, I have no way of setting ReadOnly on the cloned object. Does that make sense? You are perfectly right. Please, try with getView().setEnabled(false) F. Colm. On Thu, Feb 7, 2013 at 8:54 AM, Fabio Martelli fabio.marte...@gmail.comwrote: Il giorno 04/feb/2013, alle ore 18.39, Colm O hEigeartaigh ha scritto: Hi all, Perhaps this is extremely obvious... I'm running into a problem with a fix for SYNCOPE-215. Essentially there is a drop down list of Virtual attribute names, and I want to make the corresponding text field read-only if the Virtual attribute that is selected is read-only. The DropDownChoice object in VirtualAttributesPanel already has an onblur component that allows me to see what was selected. The problem is that the Panel object corresponding to the text field, is passed through to a MultiValueSelectorPanel object, which clones it: final FieldPanel fieldPanel = panelTemplate.clone(); So even if I call setReadOnly on the panel in VirtualAttributesPanel, the text field does not turn read-only. Is there an obvious way to solve this problem? Hi Colm, I think that setReadOnly method on the field panel template should solve your problem. The clone method is overridden into FildPanel class. This method set the read only value explicitly: panel.setReadOnly(isReadOnly()); Have you already tried by calling the setReadOnly method on the field panel template? Best regards, F. -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
[jira] [Assigned] (SYNCOPE-307) Virtual Attributes don't propagated in case of update during synchronization
[ https://issues.apache.org/jira/browse/SYNCOPE-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] fabio martelli reassigned SYNCOPE-307: -- Assignee: fabio martelli Virtual Attributes don't propagated in case of update during synchronization Key: SYNCOPE-307 URL: https://issues.apache.org/jira/browse/SYNCOPE-307 Project: Syncope Issue Type: Bug Components: core Affects Versions: 1.0.6, 1.1.0 Reporter: fabio martelli Assignee: fabio martelli Fix For: 1.0.6, 1.1.0 UC: * Suppose two resources A and B; * Suppose to synchronize from A; * Suppose to have virtual attributes mapped just on B; * Suppose to retrieve a user to be updated locally and to be created new on B (thanks to an ad-hoc user template). User will be updated locally and created on B but its virtual attribute values won't be propagated on B. The bug is into the virtual attribute management during sync and propagation: in the UC provided above, the 'populate' method of the class AttributableOperations will never provide virtual attributes to be used by SyncJob to create the update propagation task. -- 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-307) Virtual Attributes don't propagated in case of update during synchronization
[ https://issues.apache.org/jira/browse/SYNCOPE-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13573658#comment-13573658 ] fabio martelli commented on SYNCOPE-307: Looking at the code I was thinking that a fast fix for this issue wouldn't be so easy. I can see just a solution: in case of the scenario in object, we have to retrieve all virtual attribute values required. Unfortunately this action is very expensive: virtual attribute values will be searched remotely, on the external resources. Since we already perform several connection towards one or more resource during a synchronization (to retrieve before/after object, to create/update/delete, to check availability, ) I do think we have to avoid further useless connection. I would implement a very simple virtual attribute cache with the aim to reduce a lot the number of query performed on the resources in order to retrieve virtual attribute values. Whit this new feature I should fix this issue as well. If no one will shout at me before tomorrow I will go on with this idea/implementation. Virtual Attributes don't propagated in case of update during synchronization Key: SYNCOPE-307 URL: https://issues.apache.org/jira/browse/SYNCOPE-307 Project: Syncope Issue Type: Bug Components: core Affects Versions: 1.0.6, 1.1.0 Reporter: fabio martelli Assignee: fabio martelli Fix For: 1.0.6, 1.1.0 UC: * Suppose two resources A and B; * Suppose to synchronize from A; * Suppose to have virtual attributes mapped just on B; * Suppose to retrieve a user to be updated locally and to be created new on B (thanks to an ad-hoc user template). User will be updated locally and created on B but its virtual attribute values won't be propagated on B. The bug is into the virtual attribute management during sync and propagation: in the UC provided above, the 'populate' method of the class AttributableOperations will never provide virtual attributes to be used by SyncJob to create the update propagation task. -- 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-154) Virtual attribute cache
[ https://issues.apache.org/jira/browse/SYNCOPE-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] fabio martelli updated SYNCOPE-154: --- Fix Version/s: (was: 2.0.0) 1.1.0 Virtual attribute cache --- Key: SYNCOPE-154 URL: https://issues.apache.org/jira/browse/SYNCOPE-154 Project: Syncope Issue Type: Improvement Reporter: Francesco Chicchiriccò Fix For: 1.1.0 Provide a simple cache for virtual attribute values in order to avoid to query external resources every 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-307) Virtual Attributes don't propagated in case of update during synchronization
[ https://issues.apache.org/jira/browse/SYNCOPE-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13573667#comment-13573667 ] fabio martelli commented on SYNCOPE-307: Right! Virtual Attributes don't propagated in case of update during synchronization Key: SYNCOPE-307 URL: https://issues.apache.org/jira/browse/SYNCOPE-307 Project: Syncope Issue Type: Bug Components: core Affects Versions: 1.0.6, 1.1.0 Reporter: fabio martelli Assignee: fabio martelli Fix For: 1.0.6, 1.1.0 UC: * Suppose two resources A and B; * Suppose to synchronize from A; * Suppose to have virtual attributes mapped just on B; * Suppose to retrieve a user to be updated locally and to be created new on B (thanks to an ad-hoc user template). User will be updated locally and created on B but its virtual attribute values won't be propagated on B. The bug is into the virtual attribute management during sync and propagation: in the UC provided above, the 'populate' method of the class AttributableOperations will never provide virtual attributes to be used by SyncJob to create the update propagation task. -- 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-154) Virtual attribute cache
[ https://issues.apache.org/jira/browse/SYNCOPE-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] fabio martelli updated SYNCOPE-154: --- Fix Version/s: 1.0.6 Virtual attribute cache --- Key: SYNCOPE-154 URL: https://issues.apache.org/jira/browse/SYNCOPE-154 Project: Syncope Issue Type: Improvement Reporter: Francesco Chicchiriccò Fix For: 1.0.6, 1.1.0 Provide a simple cache for virtual attribute values in order to avoid to query external resources every 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-258) Java class as sync policy correlation rule
[ https://issues.apache.org/jira/browse/SYNCOPE-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13573798#comment-13573798 ] Hudson commented on SYNCOPE-258: Integrated in Syncope-trunk #75 (See [https://builds.apache.org/job/Syncope-trunk/75/]) Fix for SYNCOPE-258 (Revision 1443475) SYNCOPE-258 Fixing incorrect annotations for jaxb (Revision 1443445) Result = UNSTABLE fmartelli : Files : * /syncope/trunk/client/src/main/java/org/apache/syncope/client/services/proxy/PolicyServiceProxy.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/services/PolicyService.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/to/CorrelationRuleClassTO.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/types * /syncope/trunk/common/src/main/java/org/apache/syncope/common/types/ConflictResolutionAction.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/util/CollectionWrapper.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/panels/PolicyBeanPanel.java * /syncope/trunk/console/src/main/java/org/apache/syncope/console/rest/PolicyRestClient.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/controller/PolicyController.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/services/PolicyServiceImpl.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/PolicyTestITCase.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/TaskTestITCase.java * /syncope/trunk/core/src/test/resources/content.xml cschneider : Files : * /syncope/trunk/common/src/main/java/org/apache/syncope/common/types/SyncPolicySpec.java Java class as sync policy correlation rule -- Key: SYNCOPE-258 URL: https://issues.apache.org/jira/browse/SYNCOPE-258 Project: Syncope Issue Type: Improvement Components: console, core Affects Versions: 1.1.0 Reporter: fabio martelli Assignee: fabio martelli Fix For: 1.1.0 Give the possibility to specify a java class for the sync policy to implement a custom correlation rule. If specified, this custom rule should be evaluated in place of correlation attributes rule. -- 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 (Introducing Apache CXF WS Stack)
[ https://issues.apache.org/jira/browse/SYNCOPE-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13573799#comment-13573799 ] Hudson commented on SYNCOPE-231: Integrated in Syncope-trunk #75 (See [https://builds.apache.org/job/Syncope-trunk/75/]) SYNCOPE-231 Fixing some more issues with the jaxrs services (Revision 1443594) Result = UNSTABLE cschneider : Files : * /syncope/trunk/client/src/main/java/org/apache/syncope/client/services/proxy/SpringServiceProxy.java * /syncope/trunk/common/src/main/java/org/apache/syncope/common/services/ConfigurationService.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/services/ConfigurationServiceImpl.java * /syncope/trunk/core/src/main/java/org/apache/syncope/core/services/ReportServiceImpl.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/AuthenticationTestITCase.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/ConfigurationTestITCase.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/ReportTestITCase.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/jaxrs/CXFPatchedAuthenticator.java * /syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/jaxrs/ConfigurationTestITCaseJAXRS.java Using Standard JAX-RS API in Syncope (Introducing Apache CXF WS Stack) -- 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.1.0 Attachments: TaskService.patch Current REST Interfaces are based on Spring Webservice framework. Goal of this task is to replace Spring with CXF and to relay on JAX-B and JAX-RS annotations rather then Spring annotations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: dbDump in ReportService and ConfigurationService
+1
Best regards.
Jan
-Original Message-
From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
Sent: Donnerstag, 7. Februar 2013 10:36
To: dev@syncope.apache.org
Subject: Re: dbDump in ReportService and ConfigurationService
On 06/02/2013 12:08, Jan Bernhardt wrote:
Hi Francesco,
From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
Hi all,
I am currently completing some modifications started yesterday with
ConfigurationServiceProxy.dbExport() that will involve some
refactoring on console's HttpResourceStream and also to core's
ReportTestITCase.
Basically, I would like to encapsulate the logic for handling streams
(content.xml and reports in various formats) in the relevant service
proxies.
While doing this, I've just noticed that ReportSevice has
@GET
@Path(executions/{executionId}/dbDump)
Response exportExecutionResult(@PathParam(executionId) Long
executionId,
@QueryParam(format) ReportExecExportFormat fmt);
while ConfigurationService has
@GET
@Path(dbDump)
Response dbExport();
Any special reason for this dbDump?
No there is no special reason for dbDump. (Code looks to me, as if this is
what happens here.) I only tried to find a consistent manner, who to title a
downloadable stream. I'm completely open for any
suggestions/improvements for a different URL path.
What about
@GET
@Path(executions/{executionId}/stream)
Response exportExecutionResult(@PathParam(executionId) Long
executionId,
@QueryParam(format) ReportExecExportFormat fmt);
and
@GET
@Path(stream)
Response dbExport();
?
Regards.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
RE: Add a new method into the PolicyService
Hi Fabio,
-Original Message-
From: Fabio Martelli [mailto:fabio.marte...@gmail.com]
Sent: Donnerstag, 7. Februar 2013 11:04
To: dev@syncope.apache.org
Subject: Add a new method into the PolicyService
Hi All,
I have to add a new rest method to retrieve sync policy correlation rules.
As you can see this info is just related to the sync policies.
Since the PolicyService take the policy type as part of the path
(@Path(policies/{type})) how do you suggest to introduce a client method
to retrieve this info?
Should I do something like the following
@GET
@Path(correlationRules)
ListString getCorrelationRules(@PathParam(type) PolicyType type);
throwing an IllegalArgumentException in case of password or account type?
Since PolicyType is part of the URL and not part of a POST body, I would
suggest to rather throw a NotFoundException. This way a user will just get
notified that there are no correlationRules available for any other kind of
policy. (Caller doesn't need to know which part of the URL is mapped to a
parameter, thus I think not found fits better in this case.)
Please be aware of my sample above to insert a @Path annotation. Otherwise you
will have two methods for the same URL pattern (in this case list operation).
Of course you can also use @Path(rules) if you like to shorten URL a little
bit. Here is a sample of how the complete URL will look like:
http://localhost:9080:/syncope/policies/sync/rules -- This will call your
method
http://localhost:9080:/syncope/policies/password/rules -- 404 NotFound
http://localhost:9080:/syncope/policies/xyzABC/rules -- 404 NotFound
http://localhost:9080:/syncope/policies/sync/someURL -- 404 NotFound
http://localhost:9080:/syncope/policies/sync -- Returns list of available sync
policies
What are the best practices for this scenario?
Throw IllegalArgumentException if payload if message is corrupt
and throw NotFoundException if URL does not match a valid useCase.
Best regards.
Jan
Best regards,
F.
