[jira] [Commented] (SYNCOPE-285) Complete CXF migration
[ https://issues.apache.org/jira/browse/SYNCOPE-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13720587#comment-13720587 ] Andrei Shakirin commented on SYNCOPE-285: - Hi Francesco, As far as I remember it was not really a defect. The problem is following: there are two methods with the same path: Complete CXF migration -- Key: SYNCOPE-285 URL: https://issues.apache.org/jira/browse/SYNCOPE-285 Project: Syncope Issue Type: Bug Reporter: Francesco Chicchiriccò Fix For: 1.2.0 Complete the migration to Apache CXF. -- 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-285) Complete CXF migration
[ https://issues.apache.org/jira/browse/SYNCOPE-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13720596#comment-13720596 ] Andrei Shakirin commented on SYNCOPE-285: - +1 from me. Can not believe that we finally close issue-285, we must really celebrate that!!! :) Complete CXF migration -- Key: SYNCOPE-285 URL: https://issues.apache.org/jira/browse/SYNCOPE-285 Project: Syncope Issue Type: Bug Reporter: Francesco Chicchiriccò Fix For: 1.2.0 Complete the migration to Apache CXF. -- 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-285) Complete CXF migration
[ https://issues.apache.org/jira/browse/SYNCOPE-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13720643#comment-13720643 ] Andrei Shakirin commented on SYNCOPE-285: - Hi Francesco, I think these methods have different path parameter type (Long and TaksType) and CXF can select method on the base of this. But in list() methods path parameter types are identical, so no chance to distinguish them without analyses of query params. Regards, Andrei. Complete CXF migration -- Key: SYNCOPE-285 URL: https://issues.apache.org/jira/browse/SYNCOPE-285 Project: Syncope Issue Type: Bug Reporter: Francesco Chicchiriccò Fix For: 1.2.0 Complete the migration to Apache CXF. -- 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-246) Remove collection setters in transfer objects for JAXB marshalling
[
https://issues.apache.org/jira/browse/SYNCOPE-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13718310#comment-13718310
]
Andrei Shakirin commented on SYNCOPE-246:
-
Hi Francesco,
I try to explain the issue: originally we have a problem because JAXB and
Spring MVC work differently with list members of java beans:
- Spring MVC uses normal setter to set a list value
- JAXB uses only getter to return the list and custom code adds / removes
elements.
The problem was that if we leave setter for lists in bean, JAXB tries to set
the same list object through the setter and code in setter clears list content,
so list will be empty:
public void setEntitlements(final ListString entitlements) {
this.entitlements.clear();
if (entitlements != null !entitlements.isEmpty()) {
this.entitlements.addAll(entitlements);
}
}
Therefore Christian adds workaround that checks if list object is the same
(JAXB case) and do nothing in that case:
public void setEntitlements(final ListString entitlements) {
if (this.entitlements != entitlements) {
this.entitlements.clear();
if (entitlements != null !entitlements.isEmpty()) {
this.entitlements.addAll(entitlements);
}
}
}
But actually, clean final solution will be to remove list setters from TO
objects at all. That is possible only when we do not support Spring MVC REST
anymore.
Regards,
Andrei.
Remove collection setters in transfer objects for JAXB marshalling
--
Key: SYNCOPE-246
URL: https://issues.apache.org/jira/browse/SYNCOPE-246
Project: Syncope
Issue Type: Sub-task
Components: core
Affects Versions: 1.1.0
Environment: CXF branch
Reporter: Andrei Shakirin
Assignee: Christian Schneider
Fix For: 1.2.0
XML payload will be marshaled/unmarshaled using JAXB by migration to CXF Rest
frontend.
JAXB works with collections in a little bit different way as Spring Rest
marshaling.
JAXB uses only getter for the list (assumes that list is initialized due
object creation) and adds elements into the list obtained by getter by
unmarshaling. It doesn't need setter at all.
The problem is that actual implementation of transfer objects doesn't work
with JAXB.
If TO provide setter for collection, JAXB gets the list, adds the elements
and additionally calls setter for this list. As far as setter logic cleans
the TO collection, the result collection is always empty.
Solution is remove setters for collections in TOs by migration on CXF Rest.
I find it also better from security and encapsulation aspects.
Regards,
Andrei.
--
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: [VOTE] Apache Syncope 1.0.8
+1 (non-binding) -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Donnerstag, 18. April 2013 11:06 To: dev@syncope.apache.org Subject: [VOTE] Apache Syncope 1.0.8 I've created a 1.0.8 release, with the following artifacts up for a vote: SVN source tag (r1469201): https://svn.apache.org/repos/asf/syncope/tags/syncope-1.0.8/ List of changes: https://svn.apache.org/repos/asf/syncope/tags/syncope-1.0.8/CHANGES Maven staging repo: https://repository.apache.org/content/repositories/orgapachesyncope-116/ Source release (checksums and signatures are available at the same location): https://repository.apache.org/content/repositories/orgapachesyncope- 116/org/apache/syncope/syncope-root/1.0.8/syncope-root-1.0.8-source- release.zip Staging site: http://syncope.apache.org/1.0.8/ PGP release keys (signed using 273DF287): http://www.apache.org/dist/syncope/KEYS Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
RE: [DISCUSS] ConnectorService, Java 7 and @MatrixParam
Hi Francesco,
Hi all,
we had some discussion in the past about random errors with Java 7 and the
-Pjaxrs Maven profile.
Today I have updated CXF from 2.7.3 to 2.7.4 and most of such errors seems
to disappear (I've been executing some times -Pjaxrs with either OpenJDK 7
and Oracle JDK 7 on different platforms).
Cool!
Only two remain, in ConnInstanceTestITCase, when calling
connectorService.list(null)
This call is intentioned to be routed to ConnectorServiceImpl.list(null),
while
instead it goes to
ConnectorService.readByResource(null): I guess that CXF gets confused by
the JAX-RS annotations on ConnectorService:
@GET
ListConnInstanceTO list(@QueryParam(lang) String lang);
@GET
ConnInstanceTO readByResource(@MatrixParam(resourceName) String
resourceName);
with null param, in fact, there seems to be no way find the right match.
Why don't we have instead
@GET
@Path({resourceName})
ConnInstanceTO readByResource(@PathParam(resourceName) String
resourceName);
? This should solve the issue, but I guess there is some best practice here,
so
here's why I am asking.
For the moment I have changed, in ConnInstanceTestITCase the calls above
to
connectorService.list()
and this makes the tests run smoothly.
Currently CXF method selection is extended by
org.apache.syncope.core.rest.utils.QueryResourceInfoComperator.
This comparator additionally analyses Query and Matrix parameters to select a
correct method.
I do not exactly remember the reason why it was done this way.
However I tend to use classic path selection for readByResource() as well.
Resource name is reasonable path parameter.
Final remark: why ConnectorService (and derived) instead of
ConnInstanceService (and derived)? Connectors and ConnInstance (e.g.
connector instances) are distinct in Syncope.
Not sure ... the name seems to be ConnectorService from beginning. Will ping
Jan regarding it.
Regards,
Andrei.
Regards.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
RE: [DISCUSS] Migrating users from 1.0.X to 1.1.0
+1 for extending SyncopeAuthenticationProvider. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Freitag, 29. März 2013 08:48 To: dev@syncope.apache.org Subject: Re: [DISCUSS] Migrating users from 1.0.X to 1.1.0 On 28/03/2013 18:58, Guido Irrelevant wrote: Hi all, I am currently reviewing [1] as part of SYNCOPE-276 and I've just realized that, since SYNCOPE-51 removed support for MD5 (as password cipher algorithm), we might have a considerable upgrade problem. What about an existing 1.0.X installation with MD5 passwords? When upgrading to 1.1.0, any user won't be able to authenticate any more because the values of 'password' column in 'SyncopeUser' table cannot be verified with any of available cipher algorithm. What can we suggest as best practice in this case? IMO we can provide a class extending SyncopeAuthenticationProvider [2], able to check authentication for MD5 users and leaving to SyncopeAuthenticationProvider for the rest. This new authenticator can be then configured in securityContext.xml [3] allowing people to keep this as temporary workaround, until all users have changed their password with the new configured cipher algorithm. WDYT? Can you think of a better alternative? If I understand it correctly, the disadvantage of this approach would be that the hash of a user stays vulnerable until she changes her password. This is rather the rationale behind SYNCOPE-51. The problem I am discussing here is how to deal with existing Syncope 1.0.X installations willing to migrate to upcoming 1.1.0, when MD5 was chosen for user passwords. IMO a more secure but also more complicated approach for migration would be to rehash the MD5 password hashes in a secure way. It seems that Drupal followed such an approach: http://drupal.org/node/1349758 If one wants to have hashes based on a standard algorithms, one could in addition change such a rehashed hash to a standard (e.g. bcrypt) hash once the user logs in and Syncope sees the password in clear (possibly this could also be done by SyncopeAuthenticationProvider). http://blog.jgc.org/2012/06/one-way-to-fix-your-rubbish-password.html describes such an approach. There also was an interesting discussion on migration of MD5 passwords on stackoverflow: http://stackoverflow.com/questions/10771198/migrate-old-md5- passwords- to-bcrypt-passwords This possibility is very interesting indeed, but I see it as complementary to the solution I've proposed above: once we will provide a special authenticator for dealing with old MD5 passwords, one could decide to extend it in his own project in order to deal with more sophisticated approaches (like rehashing proposed by you). We might add this possibility (including URL references) to the migration wiki page [1] that I am going to complete soon as per SYNCOPE-276. Thanks for contributing. Regards. [1] https://cwiki.apache.org/confluence/display/SYNCOPE/Upgrade+instruction s -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
RE: [PROPOSAL] Move full OSGi support to 1.2.0
Hi Francesco, I don't see why the merges for SYNCOPE-203 need to be reverted as they are not breaking anything. I would prefer to leave things as they are but not claim full OSGi support in the 1.1.0 release. I guess you are concerned that these issues will hold up the 1.1.0 release and so I propose the following. Give us until the end of the week to find a solution for SYNCOPE-337 (and any related problems). If we have not found a solution by then, then this JIRA can be moved to the next release (1.1.1 if it can be considered a bug based on 1.1.0, otherwise 1.2). Does this work? Colm. +1 On Tue, Mar 19, 2013 at 2:40 PM, Francesco Chicchiriccò ilgro...@apache.org wrote: Hi all, currently we have on trunk (e.g. 1.1.0-SNAPSHOT) a first OSGi support for all modules as per SYNCOPE-203. However, this seems not to be working (see SYNCOPE-337), even if changing the build for generating MANIFEST.MF according to the ones attached there. From the other side, this problem appear to be expected since SYNCOPE-204 is planned only for 1.2.0. Basically, I see for 1.1.0 a quite incoherent situation in which OSGi is half-supported. Since we are getting close to releasing stable 1.1.0, my proposal is to reopen SYNCOPE-203, revert the provided changes and to move SYNCOPE-203, SYNCOPE-204 and SYNCOPE-337 to 1.2.0. We can contextually copy the current trunk to a new 1_1_X branch, move trunk version to 1.2.0-SNAPSHOT and re-apply immediately the changes from SYNCOPE-203 there. WDYT? -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~**ilgrosso/http://people.apache.org/~ilgros so/ -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
RE: policys/ ?!?
Thanks: it is also for me the chance to get a bit insight this new CXF layer that will be soon the only layer available. OK, then just ping us if you have any problems with a fix. Andrei. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Freitag, 8. März 2013 09:10 To: dev@syncope.apache.org Subject: Re: policys/ ?!? On 07/03/2013 23:41, Andrei Shakirin wrote: Hi Francesco, As Sergei already explained, JAXB produces this name from annotation @XmlRootElement(name = policy) in PolicyTO class. In case of ListT extends PolicyTO it adds s suffix to root element name. I will care about the solution. Thanks: it is also for me the chance to get a bit insight this new CXF layer that will be soon the only layer available. Regards. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Donnerstag, 7. März 2013 13:45 To: dev@syncope.apache.org Subject: policys/ ?!? Hi all, I have just noticed that the root XML element when listing policies via CXF is policys instead of policies I couldn't easily (= grep) find how to change this: anyone can provide some hint? Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
RE: policys/ ?!?
I was not proposing myself for this, only to learn from your fix ;-) Are you still available for caring about the solution Ah .. ok ;-) Sure, will create Jira and fix it. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Sonntag, 10. März 2013 16:35 To: dev@syncope.apache.org Subject: Re: policys/ ?!? On 10/03/2013 16:10, Andrei Shakirin wrote: Thanks: it is also for me the chance to get a bit insight this new CXF layer that will be soon the only layer available. OK, then just ping us if you have any problems with a fix. I was not proposing myself for this, only to learn from your fix ;-) Are you still available for caring about the solution? Regards. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Freitag, 8. März 2013 09:10 To: dev@syncope.apache.org Subject: Re: policys/ ?!? On 07/03/2013 23:41, Andrei Shakirin wrote: Hi Francesco, As Sergei already explained, JAXB produces this name from annotation @XmlRootElement(name = policy) in PolicyTO class. In case of ListT extends PolicyTO it adds s suffix to root element name. I will care about the solution. Thanks: it is also for me the chance to get a bit insight this new CXF layer that will be soon the only layer available. Regards. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Donnerstag, 7. März 2013 13:45 To: dev@syncope.apache.org Subject: policys/ ?!? Hi all, I have just noticed that the root XML element when listing policies via CXF is policys instead of policies I couldn't easily (= grep) find how to change this: anyone can provide some hint? Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
RE: policys/ ?!?
Hi Francesco, As Sergei already explained, JAXB produces this name from annotation @XmlRootElement(name = policy) in PolicyTO class. In case of ListT extends PolicyTO it adds s suffix to root element name. I will care about the solution. Regards, Andrei. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Donnerstag, 7. März 2013 13:45 To: dev@syncope.apache.org Subject: policys/ ?!? Hi all, I have just noticed that the root XML element when listing policies via CXF is policys instead of policies I couldn't easily (= grep) find how to change this: anyone can provide some hint? Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
RE: [DISCUSS] REST: create turns into update for some entities
Hi Francesco, +1 for issue. Find it also quite dangerous, create() should throw exception if entity already exists, 409 Conflict will be corresponded HTTP error code in this case. Regards, Andrei. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Freitag, 22. Februar 2013 14:44 To: dev@syncope.apache.org Subject: Re: [DISCUSS] REST: create turns into update for some entities I have opened SYNCOPE-323 for this. Regards. On 22/02/2013 12:43, Francesco Chicchiriccò wrote: Hi all, I have recently found that some REST create requests are treated as update. For example, try to create a new schema on the admin console and provide a name of another existing schema: you won't get any warning; only, the existing schema definition will be completely replaced by the newly inserted entry. After some investigations, I've found that this happens for external resources, schema, derived schema and virtual schema. Such entities have in common the fact that the JPA @Id is non-generated. The way how saving is handled (via EntityManager#merge()) finally turns an expected create into an update. I don't find such behavior as correct, hence I would propose to throw an exception, in the REST create methods for the entities named above, in case the key of the entity being created is already present. Do you see any problem with this? -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
RE: [DISCUSS] JAXRS integration tests
Hi Francesco, Option (1) is OK for me, would ask committers to take care of -Pjaxrs as well as selenium profile for console and post to mailing list in case of any problems regarding jaxrs integration tests. Cheers, Andrei. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Freitag, 8. Februar 2013 18:13 To: dev@syncope.apache.org Subject: Re: [DISCUSS] JAXRS integration tests On 08/02/2013 16:54, Andrei Shakirin wrote: Hi, We have finally all JAX-RS integration tests green. To minimize the risk of breaking JAX-RS interface by further 1.1.0 changes/fixes, I would propose any of two ways: 1. Just ask all committers to run -Pjaxrs profile before any 1.1.0 commit 2. Activate JAX-RS tests additionally to Spring MVC tests in integration build (that make build 3 min longer). Any thoughts? Obvious consideration: (1) has less impact, (2) is safer. Being a choice necessary, I'd think to put this on the same level of the selenium profile for console and go for (1). Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
RE: [jira] [Commented] (SYNCOPE-136) Password required for resource subscription
Hi Francesco,
Could you please care about re-run ability also in new integration tests?
UserTestITCase.readWithMailAddressAsUserName() should look like:
@Test
public void readWithMailAddressAsUserName() {
UserTO userTO = createUser(getUniqueSampleTO(m...@domain.org));
userTO = userService.read(userTO.getUsername());
assertNotNull(userTO);
}
Otherwise we will break fixed [1] again and again.
Regards,
Andrei.
[1] https://issues.apache.org/jira/browse/SYNCOPE-268
-Original Message-
From: Hudson (JIRA) [mailto:j...@apache.org]
Sent: Freitag, 1. Februar 2013 16:58
To: dev@syncope.apache.org
Subject: [jira] [Commented] (SYNCOPE-136) Password required for resource
subscription
[ https://issues.apache.org/jira/browse/SYNCOPE-
136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
tabpanelfocusedCommentId=13568825#comment-13568825 ]
Hudson commented on SYNCOPE-136:
Integrated in Syncope-trunk #58 (See
[https://builds.apache.org/job/Syncope-trunk/58/])
[SYNCOPE-136] Feature implemented, test cases added (Revision 1441482)
Result = SUCCESS
ilgrosso :
Files :
* /syncope/trunk
*
/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/
ResourceTO.java
*
/syncope/trunk/common/src/main/java/org/apache/syncope/common/typ
es/CipherAlgorithm.java
*
/syncope/trunk/console/src/main/java/org/apache/syncope/console/pages
/panels/ResourceDetailsPanel.java
*
/syncope/trunk/console/src/main/resources/org/apache/syncope/console/
pages/ResourceModalPage.properties
*
/syncope/trunk/console/src/main/resources/org/apache/syncope/console/
pages/ResourceModalPage_it.properties
*
/syncope/trunk/console/src/main/resources/org/apache/syncope/console/
pages/panels/ResourceDetailsPanel.html
*
/syncope/trunk/core/src/main/java/org/apache/syncope/core/connid/Pass
wordGenerator.java
*
/syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/
beans/ExternalResource.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/
beans/user/SyncopeUser.java
*
/syncope/trunk/core/src/main/java/org/apache/syncope/core/propagation
/impl/PropagationManager.java
*
/syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/data/Re
sourceDataBinder.java
*
/syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/data/Us
erDataBinder.java
*
/syncope/trunk/core/src/main/java/org/apache/syncope/core/security/Enc
odePasswordCLI.java
*
/syncope/trunk/core/src/main/java/org/apache/syncope/core/security/Syn
copeAuthenticationProvider.java
*
/syncope/trunk/core/src/main/java/org/apache/syncope/core/util/Mapping
Util.java
*
/syncope/trunk/core/src/main/java/org/apache/syncope/core/util/Passwor
dEncoder.java
*
/syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/UserTest
ITCase.java
*
/syncope/trunk/core/src/test/java/org/apache/syncope/core/security/Pass
wordEncoderTest.java
* /syncope/trunk/core/src/test/resources/content.xml
Password required for resource subscription
---
Key: SYNCOPE-136
URL: https://issues.apache.org/jira/browse/SYNCOPE-136
Project: Syncope
Issue Type: Improvement
Reporter: Francesco Chicchiriccò
Assignee: Francesco Chicchiriccò
Fix For: 1.1.0
Currently, cleartext password is always required when subscribing to a new
external resource.
However, in some cases (for example when passwords are stored with
some symmetric algorithm) this can be avoided.
For example, it could be:
Case 1: 2-way (a.k.a. symmetric) password cipher algorithm is
configured in Syncope Use decrypted password from SyncopeUser to
subscribe new resource.
Case 2: 1-way (a.k.a. hash or asymmetric) password cipher algorithm is
configured in Syncope and no clear-text password is available (for example,
passed via UserMod or provided by a synchronizing resource) Provide, on a
resource-basis, a mean to configure how new password should be
generated:
* constant
* random password generation (compliant with resource password
policy, if present - see SYNCOPE-121)
* provide custom Java class
Discussion thread:
http://syncope-dev.1063484.n5.nabble.com/new-password-issue-
td5589622.
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-136) Password required for resource subscription
[
https://issues.apache.org/jira/browse/SYNCOPE-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13574406#comment-13574406
]
Andrei Shakirin commented on SYNCOPE-136:
-
Hi Francesco,
Could you please care about re-run ability also in new integration tests?
UserTestITCase.readWithMailAddressAsUserName() should look like:
@Test
public void readWithMailAddressAsUserName() {
UserTO userTO = createUser(getUniqueSampleTO(m...@domain.org));
userTO = userService.read(userTO.getUsername());
assertNotNull(userTO);
}
Otherwise we will break fixed [1] again and again.
Regards,
Andrei.
[1] https://issues.apache.org/jira/browse/SYNCOPE-268
Password required for resource subscription
---
Key: SYNCOPE-136
URL: https://issues.apache.org/jira/browse/SYNCOPE-136
Project: Syncope
Issue Type: Improvement
Reporter: Francesco Chicchiriccò
Assignee: Francesco Chicchiriccò
Fix For: 1.1.0
Currently, cleartext password is always required when subscribing to a new
external resource.
However, in some cases (for example when passwords are stored with some
symmetric algorithm) this can be avoided.
For example, it could be:
Case 1: 2-way (a.k.a. symmetric) password cipher algorithm is configured in
Syncope
Use decrypted password from SyncopeUser to subscribe new resource.
Case 2: 1-way (a.k.a. hash or asymmetric) password cipher algorithm is
configured in Syncope and no clear-text password is available (for example,
passed via UserMod or provided by a synchronizing resource)
Provide, on a resource-basis, a mean to configure how new password should be
generated:
* constant
* random password generation (compliant with resource password policy, if
present - see SYNCOPE-121)
* provide custom Java class
Discussion thread:
http://syncope-dev.1063484.n5.nabble.com/new-password-issue-td5589622.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] [Resolved] (SYNCOPE-289) Prepare CXF Rest integration tests migration
[ https://issues.apache.org/jira/browse/SYNCOPE-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Shakirin resolved SYNCOPE-289. - Resolution: Fixed Prepare CXF Rest integration tests migration Key: SYNCOPE-289 URL: https://issues.apache.org/jira/browse/SYNCOPE-289 Project: Syncope Issue Type: Sub-task Components: console, core Reporter: Andrei Shakirin Assignee: Andrei Shakirin Fix For: 1.1.0 Moving back to 1.1.0 -- 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
[Report] CXF migration status
Hi, Would like to shortly report status of CXF migration: It is basically finished. We still have 2 Failures and 4 Errors in JAXRS tests - it should be fixed in next days (the reason of two is already clear). Still open for 1.1.0 (SYNCOPE -231): 1) Fix rest errors in tests (6) 2) Finishing documentation 3) Configure (but not activate) CXF client for console 4) Release Notes Open for 1.2.0: 1) Final review of REST interfaces 2) Clean Spring MVC interfaces, proxies and tests 3) Uncomment Jackson annotations for abstract types 4) Activate CXF client in console 5) Release Notes Cheers, Andrei. P.S: I will not be active next two weeks because of vacation. See you again at the end of February.
RE: IncompatiblePolicyException was made unchecked
Hi Francesco, You're right about [1] and [2] - only, I have just realized now, working on SYNCOPE-136, that ignoring this exception can be very dangerous during the propagation process. And having it checked helps definitely in this sense. Let's put it the other way round: why have it unchecked? 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. If user have real possibility to improve the situation, exception should be checked. Not sure about IncompatiblePolicyException: is it related to passwords format only? In this case I tend to change exception back to checked, because user can react on exception and try again with improved password. Cheers, Andrei. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Freitag, 1. Februar 2013 14:37 To: dev@syncope.apache.org Subject: Re: IncompatiblePolicyException was made unchecked On 01/02/2013 14:33, Andrei Shakirin wrote: Hi Francesco, I thought it was agreed in [1]. Have seen no objections in [2]. You're right about [1] and [2] - only, I have just realized now, working on SYNCOPE-136, that ignoring this exception can be very dangerous during the propagation process. And having it checked helps definitely in this sense. Do you have reasons to keep this exception checked? Let's put it the other way round: why have it unchecked? Regards. [1] https://cwiki.apache.org/confluence/display/SYNCOPE/Remote+Exceptions [2] http://syncope-dev.1063484.n5.nabble.com/Exception-propagation-in- Rest -interface-HTTP-header-vs-body-for-details-td5711482.html -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Freitag, 1. Februar 2013 14:12 To: dev@syncope.apache.org Subject: IncompatiblePolicyException was made unchecked Hi all, I've just noticed that IncompatiblePolicyException, created checked [1] is now unchecked: any reason for this? [1] http://svn.apache.org/viewvc/incubator/syncope/trunk/core/src/main/ja va /org/apache/syncope/core/util/IncompatiblePolicyException.java?view=m ar kuppathrev=1401200 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
RE: IncompatiblePolicyException was made unchecked
Can we agree on something here? My +1 for checked -Original Message- From: Christian Schneider [mailto:cschneider...@gmail.com] On Behalf Of Christian Schneider Sent: Freitag, 1. Februar 2013 15:14 To: dev@syncope.apache.org Subject: Re: IncompatiblePolicyException was made unchecked Sorry about the long explanation that is completely unrelated to this special case but I think the discussion checked vs unchecked exceptions is a general thing so I write a general reasoning... In general checked Exceptions force the user of an API to handle an exception at exactly the point where it happens. Often thoughit is much easier to let an exception bubble up the stack to a general place where exceptions are handled. Checked exceptions also force to Map an exception at every layer of an application. The reason is that simply throwing exceptions over layer boundaries violates encapsulation. So my way of handling checked exceptions is: where they are forced upon me by an API I map them to an unchecked Exception as soon as possible to limit their effect / damage. I have found a nice explanation on this article http://www.javacodegeeks.com/2012/03/why-should-you-use-unchecked- exceptions.html In his famous book, *Clean code: a handbook of agile software craftsmanship*[3 http://books.google.co.in/books/about/Clean_code.html?id=dwSfGQAAC AAJ redir_esc=y], Robert C. Martin writes the below lines supporting Unchecked Exceptions. /The debate is over. For years Java programmers have debated over the benefits and liabilities //of checked exceptions. When checked exceptions were introduced in the first version //of Java, they seemed like a great idea. The signature of every method would list all of the //exceptions that it could pass to its caller. Moreover, these exceptions were part of the type/ /of the method. Your code literally wouldn't compile if the signature didn't match what your //code could do./ / / /At the time, we thought that checked exceptions were a great idea; and yes, they can //yield some benefit. However, it is clear now that they aren't necessary for the production of //robust software. C# doesn't have checked exceptions, and despite valiant attempts, C++ //doesn't either. Neither do Python or Ruby. Yet it is possible to write robust software in all //of these languages. Because that is the case, we have to decide---really---whether checked //exceptions are worth their price./ / / Here some more similar articles: http://tapestryjava.blogspot.in/2011/05/tragedy-of-checked- exceptions.html http://blogs.atlassian.com/2011/05/exceptions_are_bad/ http://misko.hevery.com/2009/09/16/checked-exceptions-i-love-you-but- you-have-to-go/ Christian Am 01.02.2013 14:36, schrieb Francesco Chicchiriccò: On 01/02/2013 14:33, Andrei Shakirin wrote: Hi Francesco, I thought it was agreed in [1]. Have seen no objections in [2]. You're right about [1] and [2] - only, I have just realized now, working on SYNCOPE-136, that ignoring this exception can be very dangerous during the propagation process. And having it checked helps definitely in this sense. Do you have reasons to keep this exception checked? Let's put it the other way round: why have it unchecked? Regards. [1] https://cwiki.apache.org/confluence/display/SYNCOPE/Remote+Exceptions [2] http://syncope-dev.1063484.n5.nabble.com/Exception-propagation-in- Res t-interface-HTTP-header-vs-body-for-details-td5711482.html -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Freitag, 1. Februar 2013 14:12 To: dev@syncope.apache.org Subject: IncompatiblePolicyException was made unchecked Hi all, I've just noticed that IncompatiblePolicyException, created checked [1] is now unchecked: any reason for this? [1] http://svn.apache.org/viewvc/incubator/syncope/trunk/core/src/main/j ava /org/apache/syncope/core/util/IncompatiblePolicyException.java?view= mar kuppathrev=1401200 -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com
RE: [DISCUSS] SchemaType and SchemaService
Hi, Related topic: I going to use AttributableType in WorkflowService instead strings user and role. Any objections? Regards, Andrei. -Original Message- From: Jan Bernhardt [mailto:jbernha...@talend.com] Sent: Donnerstag, 31. Januar 2013 09:58 To: dev@syncope.apache.org Subject: [DISCUSS] SchemaType and SchemaService Hi Syncoper, We know three different schema types in syncope normal Schema, derived Schema and virtual Schema. In Spring REST Interface these schemas are mapped to three different controllers which are basically doing the same thing, just for each type. Therefore I only created a single SchemaService for new CXF REST Service, capable of handling all three kinds. To distinguish with type of Schema should be handled (e.g. returned for a list operation) I created a new enum SchemaType. The topic to discuss however is, that in org.apache.syncope.common.types there is already a class named SchemaType containing data types for (user, role, membership) schema values (e.g. String, Long, Date, ...). My proposal would be to rename existing SchemaType class to EntitySchemaType (similar to EntityViolationType) and move SchemaType currently included in SchemaService Interface to org.apache.syncope.common.types.SchemaType. Any objections? Best regards. Jan
RE: [DISCUSS] SchemaType and SchemaService
None if you take care in the code that AttirbutableType can also be MEMBERSHIP in general while in the workflow context this is naturally meaningless. Sure, it will BadRequest in case of MEMBERSHIP. Andrei. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Donnerstag, 31. Januar 2013 11:48 To: dev@syncope.apache.org Subject: Re: [DISCUSS] SchemaType and SchemaService On 31/01/2013 11:30, Andrei Shakirin wrote: Hi, Related topic: I going to use AttributableType in WorkflowService instead strings user and role. Any objections? None if you take care in the code that AttirbutableType can also be MEMBERSHIP in general while in the workflow context this is naturally meaningless. Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
RE: svn commit: r1440904 - in /syncope/trunk: build-tools/src/main/resources/org/apache/syncope/ client/src/main/java/org/apache/syncope/client/services/proxy/ common/src/main/java/org/apache/syncope/
Hi Francesco,
I care about it ...
Andrei.
-Original Message-
From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
Sent: Donnerstag, 31. Januar 2013 12:50
To: dev@syncope.apache.org
Subject: Re: svn commit: r1440904 - in /syncope/trunk: build-
tools/src/main/resources/org/apache/syncope/
client/src/main/java/org/apache/syncope/client/services/proxy/
common/src/main/java/org/apache/syncope/common/services/
common/src/main/java/org/apache/syn...
Hi Andrei,
as stated by latest failures on Jenkins, it seems that your commit broke the
build, in particular your modification to
core/src/main/resources/restContent.xml adds a reference to
workflowServiceImpl that cannot be resolved by Spring.
Have you forgotten to commit something else or just to run the testsuite
before committing? ;-)
I have just reverted this change to make the build succeed again (at least on
JDK 1.6, but this is another story...): if you still need it, please take
care that
everything is still working before committing.
Regards.
On 31/01/2013 11:58, ashaki...@apache.org wrote:
Author: ashakirin
Date: Thu Jan 31 10:58:31 2013
New Revision: 1440904
URL: http://svn.apache.org/viewvc?rev=1440904view=rev
Log:
[SYNCOPE-231] Added WorkflowServiceImpl and Test
Modified:
syncope/trunk/build-
tools/src/main/resources/org/apache/syncope/checkstyle.xml
syncope/trunk/client/src/main/java/org/apache/syncope/client/services/pr
oxy/WorkflowServiceProxy.java
syncope/trunk/common/src/main/java/org/apache/syncope/common/servi
ces/WorkflowService.java
syncope/trunk/common/src/main/java/org/apache/syncope/common/util/
CollectionWrapper.java
syncope/trunk/console/src/main/java/org/apache/syncope/console/rest/N
otificationRestClient.java
syncope/trunk/console/src/main/java/org/apache/syncope/console/rest/W
orkflowRestClient.java
syncope/trunk/core/src/main/resources/restContext.xml
syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/Workflow
TestITCase.java
Modified:
syncope/trunk/build-
tools/src/main/resources/org/apache/syncope/checks
tyle.xml
URL:
http://svn.apache.org/viewvc/syncope/trunk/build-tools/src/main/resour
ces/org/apache/syncope/checkstyle.xml?rev=1440904r1=1440903r2=1440
90
4view=diff
==
---
syncope/trunk/build-
tools/src/main/resources/org/apache/syncope/checks
tyle.xml (original)
+++ syncope/trunk/build-
tools/src/main/resources/org/apache/syncope/ch
+++ eckstyle.xml Thu Jan 31 10:58:31 2013
@@ -177,7 +177,7 @@ under the License.
!-- Checks for common coding problems --
!-- See http://checkstyle.sf.net/config_coding.html --
!--module name=AvoidInlineConditionals/--
-module name=DoubleCheckedLocking/!-- MY FAVOURITE --
+!--module name=DoubleCheckedLocking/--!-- MY FAVOURITE --
module name=EmptyStatement/
module name=EqualsHashCode/
module name=HiddenField
Modified:
syncope/trunk/client/src/main/java/org/apache/syncope/client/services/
proxy/WorkflowServiceProxy.java
URL:
http://svn.apache.org/viewvc/syncope/trunk/client/src/main/java/org/ap
ache/syncope/client/services/proxy/WorkflowServiceProxy.java?rev=14409
04r1=1440903r2=1440904view=diff
==
---
syncope/trunk/client/src/main/java/org/apache/syncope/client/services/
proxy/WorkflowServiceProxy.java (original)
+++ syncope/trunk/client/src/main/java/org/apache/syncope/client/servi
+++ ces/proxy/WorkflowServiceProxy.java Thu Jan 31 10:58:31 2013
@@ -22,6 +22,7 @@ import java.util.Arrays;
import java.util.List;
import org.apache.syncope.common.services.WorkflowService;
import org.apache.syncope.common.to.WorkflowDefinitionTO;
+import org.apache.syncope.common.types.AttributableType;
import org.springframework.web.client.RestTemplate;
public class WorkflowServiceProxy extends SpringServiceProxy
implements WorkflowService { @@ -31,17 +32,19 @@ public class
WorkflowServiceProxy extend
}
@Override
-public WorkflowDefinitionTO getDefinition(final String type) {
-return getRestTemplate().getForObject(baseUrl +
workflow/definition/ + type, WorkflowDefinitionTO.class);
+public WorkflowDefinitionTO getDefinition(final AttributableType type)
{
+return getRestTemplate().getForObject(baseUrl +
workflow/definition/ + type.name().toLowerCase(),
+WorkflowDefinitionTO.class);
}
@Override
-public void updateDefinition(final String type, final
WorkflowDefinitionTO definition) {
-getRestTemplate().put(baseUrl + workflow/definition/ + type,
definition);
+public void updateDefinition(final AttributableType type, final
WorkflowDefinitionTO
[DISCUSS] Two Jira issues for Exceptions
Hi, We have implemented two proposals from [1] by CXF migration. I am going to create Jira issues for rest two: 1) Mapping to SyncopeClientCompositeException on client side 2) Mapping low level exceptions in core and schedule them to 1.3.0? Any objections? Regards, Andrei. [1] https://cwiki.apache.org/confluence/display/SYNCOPE/Remote+Exceptions
[jira] [Created] (SYNCOPE-303) Mapping to SyncopeClientCompositeException on client side
Andrei Shakirin created SYNCOPE-303: --- Summary: Mapping to SyncopeClientCompositeException on client side Key: SYNCOPE-303 URL: https://issues.apache.org/jira/browse/SYNCOPE-303 Project: Syncope Issue Type: Improvement Components: common, core Reporter: Andrei Shakirin Fix For: 1.2.0 Actually almost all exceptions with status BAD_REQUEST and NOT_FOUND are mapped to SyncopeClientCompositeErrorException on the client side. It is absolutely OK for composite exceptions containing number of sub-exceptions (like validation and propagation), however for some single exceptions it makes more sense to map not to SyncopeClientCompositeErrorException, but directly to corresponded exception type. Candidates are: Deadlock ExistingResource DataIntegrityViolation GenericPersistence UnauthorizedRole Proposed mapping makes exception processing more easy and effective. https://cwiki.apache.org/confluence/display/SYNCOPE/Remote+Exceptions -- 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-304) Mapping low level exceptions in core
Andrei Shakirin created SYNCOPE-304: --- Summary: Mapping low level exceptions in core Key: SYNCOPE-304 URL: https://issues.apache.org/jira/browse/SYNCOPE-304 Project: Syncope Issue Type: Improvement Components: core Reporter: Andrei Shakirin Fix For: 1.2.0 Actually service layer processes three relative low level exceptions from persistence: org.apache.ibatis.exceptions.PersistenceException; org.springframework.orm.jpa.JpaSystemException; javax.persistence.PersistenceException Suggestion: abstract service implementation from persistence a little bit more and wrap these three exceptions in high level Syncope PersistenceException. From my perspective it helps for the cases when Syncope will support alternative persistence technologies like Hibernate JPA, EclipseLink JPA or even LDAP, JCR, non-SQL DBs. https://cwiki.apache.org/confluence/display/SYNCOPE/Remote+Exceptions -- 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=13565221#comment-13565221 ] Andrei Shakirin commented on SYNCOPE-231: - Andrei, any news about the errors with JDK 1.7? Hi Francesco, It seems that I have found the reason: see discussion [Question] Problem with test UsertTestITCase.issueSYNCOPE279. I will test it additionally after the Fabio fix. Problem with AUTO generation strategy scares me a little bit - sometimes errors are not reproducible and very time consuming in analyses. What do you think about proposal in our discussion? Andrei. 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 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
[jira] [Created] (SYNCOPE-298) Persistence beans: change AUTO Id generation strategy to TABLE
Andrei Shakirin created SYNCOPE-298: --- Summary: Persistence beans: change AUTO Id generation strategy to TABLE Key: SYNCOPE-298 URL: https://issues.apache.org/jira/browse/SYNCOPE-298 Project: Syncope Issue Type: Improvement Components: core Reporter: Andrei Shakirin Fix For: 1.2.0 Currently AUTO Id generation strategy works unstable under high load/concurrency conditions at least for H2 DB. [1], [2] Possible solution of this problem is migration AUTO to TABLE Id generation strategy for all persistence domain objects. [1] http://syncope-dev.1063484.n5.nabble.com/Question-Problem-with-test-UsertTestITCase-issueSYNCOPE279-tt5712389.html [2] http://syncope-dev.1063484.n5.nabble.com/Persistence-id-generation-strategy-TABLE-vs-AUTO-td5711813.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-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=13565426#comment-13565426 ] Andrei Shakirin commented on SYNCOPE-231: - I am merging it now. Unfortunately one more test in UserTestITCase doesn't run now, because of the same AbstractVirAttribute AUTO Id generation strategy problem :( Andrei. 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
[jira] [Commented] (SYNCOPE-289) Prepare CXF Rest integration tests migration
[ https://issues.apache.org/jira/browse/SYNCOPE-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13564155#comment-13564155 ] Andrei Shakirin commented on SYNCOPE-289: - Hi Francesco, Yep, it is expected at the moment. Currently only ConfigurationITTestCaseJAXRS is green. As I wrote in my commit comment, JAXRS tests are checked-in despite errors to be visible for all committers. We are working to fix them ASAP. Currently you can use ConfigurationITTestCaseJAXRS to experiment with conetntType. Regards, Andrei. Prepare CXF Rest integration tests migration Key: SYNCOPE-289 URL: https://issues.apache.org/jira/browse/SYNCOPE-289 Project: Syncope Issue Type: Sub-task Components: console, core Reporter: Andrei Shakirin Assignee: Andrei Shakirin Fix For: 1.1.0 Moving back to 1.1.0 -- 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: [Question] Problem with test UsertTestITCase.issueSYNCOPE279
: Montag, 28. Januar 2013 16:42 To: dev@syncope.apache.org Subject: Re: [Question] Problem with test UsertTestITCase.issueSYNCOPE279 Hi Andrei, answers and comment inline. Il giorno 28/gen/2013, alle ore 16.09, Andrei Shakirin ha scritto: Hi, I am analysing problem regarding UsertTestITCase.issueSYNCOPE279(). It is reproducible in following situations: 1) Run it as single test: mvn -Pdev -DwaitForCheck=false -Dit.test= UserTestITCase# issueSYNCOPE279 Wow, strange, I implemented using these options ... Because of some reasons this test is succeed in case if AuthenticationTestITCase,ResourceTestITCase,RoleTestITCase,SchemaTestIT Case,UserRequestTestITCase were executed before (interesting :) ) This is really strange. issueSYNCOPE279 shouldn't have any dependency. Please, take a look at the code: it simply create a new profile giving it an ad- hoc resource (never used before). 2) If all core integration tests is running under JDK 1.7 3) With some other conditions. My analysis shows that the end reason is that SOAP connector (using CXF client) receives HTML as response for test() invocation: 15:47:46.041 DEBUG org.identityconnectors.framework.api.operations.GetApiOp.getObject Exception: javax.xml.ws.soap.SOAPFaultException: Response was of unexpected text/html ContentType. Incoming portion of HTML stream: OK at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:156) ~[cxf-rt-frontend-jaxws-2.7.0.jar:2.7.0] at $Proxy196.checkAlive(Unknown Source) ~[na:na] at org.connid.bundles.soap.WebServiceConnection.test(WebServiceConnectio n.java:89) ~[na:na] at org.connid.bundles.soap.WebServiceConnector.checkAlive(WebServiceCon nector.java:169) ~[na:na] at org.identityconnectors.framework.impl.api.local.ConnectorPoolManager$Co nnectorPoolHandler.testObject(ConnectorPoolManager.java:105) ~[framework-internal-1.3.2.jar:na] This exception occurs after the Timeout. It is thrown by the zombie task. Therefore propagation of resource ws-target-resource-3 is failed with following error: 15:46:55.221 ERROR org.apache.syncope.core.propagation.impl.AbstractPropagationTaskExecuto r - Exception during provision on resource ws-target-resource-3 org.apache.syncope.core.propagation.TimeoutException: Request timeout at org.apache.syncope.core.propagation.impl.ConnectorFacadeProxy.getObjec t(ConnectorFacadeProxy.java:380) ~[ConnectorFacadeProxy.class:na] at org.apache.syncope.core.propagation.impl.AbstractPropagationTaskExecuto r.getRemoteObject(AbstractPropagationTaskExecutor.java:438) ~[AbstractPropagationTaskExecutor.class:na] at org.apache.syncope.core.propagation.impl.AbstractPropagationTaskExecuto r.execute(AbstractPropagationTaskExecutor.java:288) ~[AbstractPropagationTaskExecutor.class:na] This is the expected exception: it should be handled and returned as a SyncopeClientErrorException. Could you give a hint how to investigate this connector invocation error? To which instance SOAP connector sends test() request? Why it sometimes answers with HTML? It is not a really soap resource: it is a servlet returning OK after a delay of 60 seconds. Syncope shouldn't take care of the result because it comes after the timeout. Regards, F.
RE: [Discuss] Way to parameterize integration tests
Hi Francesco, 2. Leave single test classes and configure contentType in AbstractTest with default value JSON. Normally run only JSON tests (like now). Make XML tests runnable via separate profile / configuration. +1 Will redesign it in this way and will try to commit until Monday. Andrei. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Freitag, 25. Januar 2013 18:01 To: dev@syncope.apache.org Subject: Re: [Discuss] Way to parameterize integration tests On 25/01/2013 17:39, Andrei Shakirin wrote: Hi, One more topic to discuss: Currently integration tests run using communication using JSON contentType only. For new CXF-based tests we are going to run every tests twice: with XML and JSON [1]. JUnit proposes elegant solution using parameterized tests: http://junit.sourceforge.net/javadoc/org/junit/runners/Parameterized.html . Basically it works fine, but unfortunately (as Francesco already noted) individual tests cannot be executed from Surefire or Failsafe plugins as well as from some IDEs. The ability we've had so far to execute a single IT case is of fundamental importance to speed up the development process. The problem is that Parameterized runner expect individual test description in form ClassName#MethodName[Number]. This form cannot be specified in maven command line, because method name will be not correctly resolved. I do not see any acceptable solution for Parameterized runner now and propose following alternatives: 1. Create two classes per each test inherited from common parent for all CXF tests (e.g. AuthenticationTestXMLTestITCase, AuthenticationTestJsonTestITCase). Always run both variants. 2. Leave single test classes and configure contentType in AbstractTest with default value JSON. Normally run only JSON tests (like now). Make XML tests runnable via separate profile / configuration. +1 I don't like the idea of duplicating test cases, so if we have an easy way to activate contentType = XML it would be acceptable. 3.... Regards. [1] https://issues.apache.org/jira/browse/SYNCOPE-289 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[jira] [Commented] (SYNCOPE-289) Prepare CXF Rest integration tests migration
[ https://issues.apache.org/jira/browse/SYNCOPE-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13562611#comment-13562611 ] Andrei Shakirin commented on SYNCOPE-289: - I am afraid it cased by @RunWith(Parameterized.class) annotation, was introduced to run all CXF integration tests twice for XML and JSON content type. I will see is it possible somehow to marry this annotation with -Dit.test=... Prepare CXF Rest integration tests migration Key: SYNCOPE-289 URL: https://issues.apache.org/jira/browse/SYNCOPE-289 Project: Syncope Issue Type: Sub-task Components: console, core Reporter: Andrei Shakirin Assignee: Andrei Shakirin Fix For: 1.1.0 Moving back to 1.1.0 -- 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
[Discuss] Way to parameterize integration tests
Hi, One more topic to discuss: Currently integration tests run using communication using JSON contentType only. For new CXF-based tests we are going to run every tests twice: with XML and JSON [1]. JUnit proposes elegant solution using parameterized tests: http://junit.sourceforge.net/javadoc/org/junit/runners/Parameterized.html . Basically it works fine, but unfortunately (as Francesco already noted) individual tests cannot be executed from Surefire or Failsafe plugins as well as from some IDEs. The problem is that Parameterized runner expect individual test description in form ClassName#MethodName[Number]. This form cannot be specified in maven command line, because method name will be not correctly resolved. I do not see any acceptable solution for Parameterized runner now and propose following alternatives: 1. Create two classes per each test inherited from common parent for all CXF tests (e.g. AuthenticationTestXMLTestITCase, AuthenticationTestJsonTestITCase). Always run both variants. 2. Leave single test classes and configure contentType in AbstractTest with default value JSON. Normally run only JSON tests (like now). Make XML tests runnable via separate profile / configuration. 3.... WDYT? Regards, Andrei. [1] https://issues.apache.org/jira/browse/SYNCOPE-289
RE: [Discussion] Prepare CXF Rest integration tests migration
Looks good: how would you implement this? A separate CXF IT maven profile? Yep, profile will be optimal solution from my perspective. Andrei. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Donnerstag, 24. Januar 2013 11:29 To: dev@syncope.apache.org Subject: Re: [Discussion] Prepare CXF Rest integration tests migration On 24/01/2013 10:57, Andrei Shakirin wrote: Hi, Do you have any objections, if I prepare and commit duplicates of rest integration tests for JAX-RS (CXF) in separate package, but wouldn't activate them in 1.1.0. The reason: it makes more easy for us to check CXF migration at least manually and avoid side effects in 1.1.0. Looks good: how would you implement this? A separate CXF IT maven profile? Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[jira] [Commented] (SYNCOPE-289) Prepare CXF Rest integration tests migration
[ https://issues.apache.org/jira/browse/SYNCOPE-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13561641#comment-13561641 ] Andrei Shakirin commented on SYNCOPE-289: - Should be fixed now, sorry for inconvenience Prepare CXF Rest integration tests migration Key: SYNCOPE-289 URL: https://issues.apache.org/jira/browse/SYNCOPE-289 Project: Syncope Issue Type: Sub-task Components: console, core Reporter: Andrei Shakirin Assignee: Andrei Shakirin Fix For: 1.1.0 Moving back to 1.1.0 -- 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-282) Implement JAX-RS exception mapper for server side
[ https://issues.apache.org/jira/browse/SYNCOPE-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Shakirin resolved SYNCOPE-282. - Resolution: Fixed Implement JAX-RS exception mapper for server side - Key: SYNCOPE-282 URL: https://issues.apache.org/jira/browse/SYNCOPE-282 Project: Syncope Issue Type: Sub-task Components: console, core Reporter: Andrei Shakirin Assignee: Andrei Shakirin Fix For: 1.2.0 Actually exceptions are mapped to error codes directly in servlet response inside jsp code. Task will introduce standard JAX-RS exception mapper for service exceptions. Mapping is documented in https://cwiki.apache.org/confluence/display/SYNCOPE/Remote+Exceptions. -- 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: [DISCUSS] New REST Service Interfaces - ConfigurationService
+1 URL Location in Response header (as usual) and ResourceID (Long or String) in HTTP response body. I would even put ResourceID to HTTP header as well. It is relative small and is kind of object metadata - that corresponds HTTP Header spec. Cheers, Andrei. -Original Message- From: Jan Bernhardt [mailto:jbernha...@talend.com] Sent: Mittwoch, 23. Januar 2013 10:41 To: dev@syncope.apache.org Subject: RE: [DISCUSS] New REST Service Interfaces - ConfigurationService -Original Message- From: Andrei Shakirin [mailto:ashaki...@talend.com] Sent: Mittwoch, 23. Januar 2013 10:38 To: dev@syncope.apache.org Subject: RE: [DISCUSS] New REST Service Interfaces - ConfigurationService Hi, I generally agree with the concept of returning created with the location in create methods. The problem is though that our service interface has no method to get the object based on the location. Pragmatic solution is returning URI as well as business object ID in Response object. In that case we avoid building URI / extracting ID from URI manually. +1 URL Location in Response header (as usual) and ResourceID (Long or String) in HTTP response body. Cheers, Andrei. -Original Message- From: Christian Schneider [mailto:cschneider...@gmail.com] On Behalf Of Christian Schneider Sent: Mittwoch, 23. Januar 2013 10:01 To: dev@syncope.apache.org Subject: Re: [DISCUSS] New REST Service Interfaces - ConfigurationService Hi Jan, I generally agree with the concept of returning created with the location in create methods. The problem is though that our service interface has no method to get the object based on the location. So we either have to change our client and interface to work with resource uris instead of ids or we have to return the id of the object in the create method. So perhaps we can return the location for true restful clients and the id in the entity of the response for people using the interface. Christian On 23.01.2013 09:06, Jan Bernhardt wrote: Hi Syncoper, here are the proposed changes for our Configuration Service: * Changing Create response type to javax.ws.rs.core.Response. This way we can set response HTTP Status code (201 created) without requiring HttpServletResponse as method parameter. Also according to best RESTful practices instead of returning newly created object directly, only URL for new Object (Configuration) will be returned. Console does not even care about created response, thus network traffic can be reduced, by not sending object (configuration). If consumer does care about new object he can easily follow provided URL (in response) and retrieve new object. * Changed ModelAndView response type to SetValidatorTO / SetMailTemplateTO and introduced wrapper TO classes for ValidatorTO and MailTemplateTO. * Changed return type from update() and delete() to void, since console does not even care about it, and I think this should be best practice anyway, since consumer knows updates object already and does not care about deleted ones, therefore there is no need to send them over the network. Any objections? Best regards. Jan
[Question] Trunk build problem (archetype)
Hi, I am currently cannot build archetype (Apache Syncope sample project) from trunk with an error: [INFO] [ERROR] Unknown lifecycle phase #. You must specify a valid lifecycle ... I see the similar problem in Jenkins build for 1_0_X branch, but not for the trunk. Has anybody clue how to fix it? Regards, Andrei.
[jira] [Resolved] (SYNCOPE-256) Update Rest exception mapper to Apache CXF
[ https://issues.apache.org/jira/browse/SYNCOPE-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Shakirin resolved SYNCOPE-256. - Resolution: Fixed Update Rest exception mapper to Apache CXF -- Key: SYNCOPE-256 URL: https://issues.apache.org/jira/browse/SYNCOPE-256 Project: Syncope Issue Type: Sub-task Components: client, core Environment: CXF branch Reporter: Andrei Shakirin Assignee: Andrei Shakirin Fix For: 1.1.0 Attachments: ExceptionMapper.patch, ExceptionMapperService.patch, ExceptionMapperUserTests.patch, syncopeClientError.jsp.patch, Unauthorized.patch 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
[jira] [Created] (SYNCOPE-289) Prepare CXF Rest integration tests migration
Andrei Shakirin created SYNCOPE-289: --- Summary: Prepare CXF Rest integration tests migration Key: SYNCOPE-289 URL: https://issues.apache.org/jira/browse/SYNCOPE-289 Project: Syncope Issue Type: Sub-task Reporter: Andrei Shakirin Assignee: Andrei Shakirin -- 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-289) Prepare CXF Rest integration tests migration
[ https://issues.apache.org/jira/browse/SYNCOPE-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13560758#comment-13560758 ] Andrei Shakirin commented on SYNCOPE-289: - Hi Francesco, It is not very important, but I tend to have this issue in 1.1.0. It is not migration itself, but only preparation (create client configuration in restClientContext.xml, add AbstractTest class for CXF, etc). JAX-RS based tests will be not activated as we have agreed, only prepared and used internally until 1.2.0. Regards, Andrei. Prepare CXF Rest integration tests migration Key: SYNCOPE-289 URL: https://issues.apache.org/jira/browse/SYNCOPE-289 Project: Syncope Issue Type: Sub-task Components: console, core Reporter: Andrei Shakirin Assignee: Andrei Shakirin Fix For: 1.2.0 -- 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-289) Prepare CXF Rest integration tests migration
[ https://issues.apache.org/jira/browse/SYNCOPE-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Shakirin updated SYNCOPE-289: Fix Version/s: (was: 1.2.0) 1.1.0 Description: Moving back to 1.1.0 Prepare CXF Rest integration tests migration Key: SYNCOPE-289 URL: https://issues.apache.org/jira/browse/SYNCOPE-289 Project: Syncope Issue Type: Sub-task Components: console, core Reporter: Andrei Shakirin Assignee: Andrei Shakirin Fix For: 1.1.0 Moving back to 1.1.0 -- 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-289) Prepare CXF Rest integration tests migration
[ https://issues.apache.org/jira/browse/SYNCOPE-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Shakirin updated SYNCOPE-289: Issue Type: Bug (was: Sub-task) Parent: (was: SYNCOPE-231) Prepare CXF Rest integration tests migration Key: SYNCOPE-289 URL: https://issues.apache.org/jira/browse/SYNCOPE-289 Project: Syncope Issue Type: Bug Components: console, core Reporter: Andrei Shakirin Assignee: Andrei Shakirin Fix For: 1.1.0 Moving back to 1.1.0 -- 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: [Question] ApplicationContextProvider in UnitTests
Hi, Regarding the ResourceDataTest, I have sporadically one of three problems: 1) java.lang.OutOfMemoryError: PermGen space 2) Test and JVM hang 3) The forked VM terminated without saying properly goodbye. VM crash or System.exit called. For me it looks like memory problem with unpredictable exit. Setting JVM -XX:MaxPermSize for surefire doesn't help. Cheers, Andrei. -Original Message- From: Marco Di Sabatino Di Diodoro [mailto:marco.disabat...@tirasa.net] Sent: Dienstag, 22. Januar 2013 09:42 To: dev@syncope.apache.org Subject: Re: [Question] ApplicationContextProvider in UnitTests Hi Jan On Jan 22, 2013, at 9:27 AM, Jan Bernhardt wrote: -Original Message- From: Jan Bernhardt [mailto:jbernha...@talend.com] Sent: Montag, 21. Januar 2013 17:50 To: dev@syncope.apache.org Subject: RE: [Question] ApplicationContextProvider in UnitTests Hi, Since last SVN update, I cannot build syncope on my system, due to never ending UnitTests. Which update? Was this incorporated in latest Jenkins build? [1] I guess my problems are related to: Revision 1436375 by ilgrosso: [SYNCOPE-249] core: extension for propagation implemented Hum, strange: this change was incorporated in [1] by Jenkins. Really strange... I had to revert all changes from today, to be able building syncope again... Today I even got MaxPermGenSize errors for old revision (1435892) and Surefire plugin terminates my VM... I have the same problem: java.lang.OutOfMemoryError: PermGen space M After adding @Ignore to org.apache,syncope.core.rest.data.ResourceDataTest I was able to build trunk version again... All this is very strange. Not sure if this is because of a Java VM update? I'm using Java version: 1.6.0_25, vendor: Sun Microsystems Inc. on Windows 7 64 bit Andrei told me yesterday that he was having similar problems (at this time I was still able to build syncope without any problems)... Anyone else? Are we able to get the windows test running on Jenkins [1] again, or do we need to talk to infrastructure? It looks like that this project still tries to work with incubator SVN URL [2]. Best regards. Jan [1] https://builds.apache.org/view/S-Z/view/Syncope/job/Syncope-windows/ [2] ERROR: Failed to update http://svn.apache.org/repos/asf/incubator/syncope/trunk I'll investigate into this issue more by tomorrow. Regards. Jan Since I'm having problems with persistence tests. I will try to checkout earlier version and see if I can build this one. While trying to investigate into this issue, I tried to run unit test in my eclipse IDE. Most test are ok, but some fail due to a NullpointerException. This exception is caused because ApplicationContextProvider.getApplicationContext() is null. Analysing spring config and code, I cannot see/understand where/who is the ApplicationContextProvider.ctx initialized? Any help is very welcome, as well as a feedback, if you can still make clean install without problems? ApplicationContextProvider is initialized after Spring context set up since it implements ApplicationContextAware. Understood. Thanks. Best regards. Jan [1] https://builds.apache.org/view/S-Z/view/Syncope/job/Syncope- trunk/464/ -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/ -- Dott. Marco Di Sabatino Di Diodoro Tel. +39 3939065570 Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 085973 http://www.tirasa.net Apache Syncope PMC Member http://people.apache.org/~mdisabatino
RE: [Question] ApplicationContextProvider in UnitTests
Thanks Francesco, Problem is resolved! Andrei. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Dienstag, 22. Januar 2013 11:06 To: dev@syncope.apache.org Subject: Re: [Question] ApplicationContextProvider in UnitTests On 22/01/2013 10:11, Francesco Chicchiriccò wrote: On 22/01/2013 09:36, Francesco Chicchiriccò wrote: [...] I'll make some more investigations on different platforms and JDKs (6 / 7) and let you know. I've just been able to make several successful builds from a fresh trunk checkout with either OpenJDK 6 (1.6.0_24-b24) and OpenJDK 7 (1.7.0_09-b30) on Linux with MAVEN_OPTS=-Xms512m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=512m I'll investigate now on Window$ Everything should be fine now, after my latest commit (1436825); I've successfully tested on Windows and MacOSX- thanks Virtualbox ;-) Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[Discussion] Rest package names
Hi, I would like to make a proposal regarding some Rest package names: 1. Core services implementations: org.apache.syncope.core.services (actually org.apache.syncope.core.services.impl). Impl ending doesn't bring additional information and doesn't recommended by java best practices. rest is deliberately not in package name, because implementation is basically independent from Rest and can be potentially reused for other remote interfaces. 2. Resource comparators and server exception mapper: org.apache.syncope.core.rest.utils (actually org.apache.syncope.core.rest). It makes purpose of these classes more clear. 3. Client exception mapper: org.apache.syncope.client.rest.utils (unfortunately cannot be combined with server mapper, because server exception mapper have a lot of dependencies of core specific exceptions). WDYT? Regards, Andrei.
RE: [Discussion] Rest package names
Hi Christian, 2. Resource comparators and server exception mapper: org.apache.syncope.core.rest.utils (actually org.apache.syncope.core.rest). It makes purpose of these classes more clear. Generally I don't like util packages. I would put these helpers into the same package as the service impls as they are only referenced from there. They are referenced not from service package, but from spring service configuration. Theoretically they can be used with some different service implementations. Perhaps helpers sounds better as utils? 3. Client exception mapper: org.apache.syncope.client.rest.utils (unfortunately cannot be combined with server mapper, because server exception mapper have a lot of dependencies of core specific exceptions). Why not client.rest? If we keep the client proxy classes in some form we could also put it there. I would like to keep it symmetric with core, otherwise it will be confusing. Cheers, Andrei. -Original Message- From: Christian Schneider [mailto:cschneider...@gmail.com] On Behalf Of Christian Schneider Sent: Montag, 21. Januar 2013 11:00 To: dev@syncope.apache.org Subject: Re: [Discussion] Rest package names On 21.01.2013 10:29, Andrei Shakirin wrote: Hi, I would like to make a proposal regarding some Rest package names: 1. Core services implementations: org.apache.syncope.core.services (actually org.apache.syncope.core.services.impl). Impl ending doesn't bring additional information and doesn't recommended by java best practices. rest is deliberately not in package name, because implementation is basically independent from Rest and can be potentially reused for other remote interfaces. Impl is a default name in OSGi to mark the package as private. So I think it is not against best practices. In this special case I agree though as the service api is defined in org.apache.syncope.services. So the core part in org.apache.syncope.core.services is already enough to separate those two packages. 2. Resource comparators and server exception mapper: org.apache.syncope.core.rest.utils (actually org.apache.syncope.core.rest). It makes purpose of these classes more clear. Generally I don't like util packages. I would put these helpers into the same package as the service impls as they are only referenced from there. 3. Client exception mapper: org.apache.syncope.client.rest.utils (unfortunately cannot be combined with server mapper, because server exception mapper have a lot of dependencies of core specific exceptions). Why not client.rest? If we keep the client proxy classes in some form we could also put it there. Christian
RE: [Discussion] Rest package names
The classes are referenced from the spring config but they belong to the impl classes so why introduce a new package? Basically we can leave exception mapper and resource comparator in core.services, there is one thing that make me unsure: Exception mapper and resource comparator depend from CXF, service implementations basically not. Does it make sense to mix these classes in one package? Regards, Andrei. -Original Message- From: Christian Schneider [mailto:cschneider...@gmail.com] On Behalf Of Christian Schneider Sent: Montag, 21. Januar 2013 11:25 To: dev@syncope.apache.org Subject: Re: [Discussion] Rest package names On 21.01.2013 11:14, Andrei Shakirin wrote: Hi Christian, 2. Resource comparators and server exception mapper: org.apache.syncope.core.rest.utils (actually org.apache.syncope.core.rest). It makes purpose of these classes more clear. Generally I don't like util packages. I would put these helpers into the same package as the service impls as they are only referenced from there. They are referenced not from service package, but from spring service configuration. Theoretically they can be used with some different service implementations. Perhaps helpers sounds better as utils? The classes are referenced from the spring config but they belong to the impl classes so why introduce a new package? 3. Client exception mapper: org.apache.syncope.client.rest.utils (unfortunately cannot be combined with server mapper, because server exception mapper have a lot of dependencies of core specific exceptions). Why not client.rest? If we keep the client proxy classes in some form we could also put it there. I would like to keep it symmetric with core, otherwise it will be confusing. Makes sense to make it similar to core. That is why I propose to also avoid the util if we avoid it in core. Of course if we choose util in core then it makes sense to do the same on the client side. 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] [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
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
[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
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] 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.
[Question] Tasks related questions
Hi, I have two questions regarding tasks in context of SYNCOPE-268: 1) Is there easy way to create Notification and Propagation tasks? Tests issueSyncope81() and deal() delete preconfigured Propagation task (id=1) and Notification task (id=8). To make tests re-runnable I need to recreate them, but cannot find easy way to do it. 2) Is it possible to stop sync task without deleting it? Cheers, Andrei.
RE: [Question] Tasks related questions
Hi Francesco and Fabio, I hope you wouldn't use DAOs into integration test; I don't like it so much. While I find this wrong too, I can add that this is not even possible because the integration test classes do not have access to core's EntityManager. Sure, DAO is no way for rest integration tests. The easiest way to create a PropagationTask or a NotificationTask is then to create an user or a role. Thanks, will try it. This scenario will be even more realistic as preconfigured Propagation Notification Tasks. 2) Is it possible to stop sync task without deleting it? No way as far as I know. Task management is handled by Quartz. Confirm: tasks are executed as Quartz jobs. It conforms my finding, but I already found workaround. Thanks for support! Regards, Andrei. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Mittwoch, 16. Januar 2013 13:12 To: dev@syncope.apache.org Subject: Re: [Question] Tasks related questions On 16/01/2013 13:03, Fabio Martelli wrote: Il giorno 16/gen/2013, alle ore 11.57, Andrei Shakirin ha scritto: Hi, I have two questions regarding tasks in context of SYNCOPE-268: 1) Is there easy way to create Notification and Propagation tasks? Tests issueSyncope81() and deal() delete preconfigured Propagation task (id=1) and Notification task (id=8). To make tests re-runnable I need to recreate them, but cannot find easy way to do it. Hi Andrei, the easiest way is by DAO. Actually I cannot see any alternative: no rest method are exposed to explicitly create Propagation/Notification tasks. PropagationTask instances are created by the PropagationManager, NotificationTask instances by the NotificationManager. This takes place in UserController and RoleController, when users or roles are created / updated / deleted. There is absolutely no functional reason to expose REST methods to create PropagationTask or NotificationTask instances. The easiest way to create a PropagationTask or a NotificationTask is then to create an user or a role. I hope you wouldn't use DAOs into integration test; I don't like it so much. While I find this wrong too, I can add that this is not even possible because the integration test classes do not have access to core's EntityManager. 2) Is it possible to stop sync task without deleting it? No way as far as I know. Task management is handled by Quartz. Confirm: tasks are executed as Quartz jobs. Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
RE: Persistence id generation strategy: TABLE vs AUTO
I have digged into the NotificationTestITCase problem a little bit more and
discovered the following:
Initial load (context.xml) creates two notifications with id= 100 and 101.
It seems that AUTO generation strategy, used in Notification now, starts with
ID=101 (not sure how to influence on it).
Therefore, if 101 Notification is not deleted, every create attempt fails with
error:
Unique index or primary key violation: PRIMARY_KEY_A ON
PUBLIC.NOTIFICATION(ID); SQL statement:
INSERT INTO PUBLIC.Notification (ID, RECIPIENTATTRNAME, RECIPIENTATTRTYPE,
SELFASRECIPIENT, SENDER, SUBJECT, TEMPLATE, TRACELEVEL, XMLABOUT,
XMLRECIPIENTS) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?) [23505-170] {prepstmnt
1643545237 INSERT INTO PUBLIC.Notification (ID, RECIPIENTATTRNAME,
RECIPIENTATTRTYPE, SELFASRECIPIENT, SENDER, SUBJECT, TEMPLATE, TRACELEVEL,
XMLABOUT, XMLRECIPIENTS) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)} [code=23505,
state=23505]
It makes create() and issueSYNCOPE83() tests depending on delete() test, that
deletes Notification with id=101.
Suggestion: leave it as it is for CXF migration step (re-runnable delete() will
check for notification id=101 and delete it only if it is exists, if not -
create and delete other notification).
After migration change Notification id generation strategy to Table (defined in
orm.xml) and start index from 1000. It makes NotificationTestITCase tests more
stable and helps to avoid check for 101 in delete(). Fix must be verified for
all supported DBs. Corresponded JIRA issue will be created for it.
Does it sounds reasonable?
Cheers,
Andrei.
-Original Message-
From: Andrei Shakirin [mailto:ashaki...@talend.com]
Sent: Freitag, 11. Januar 2013 12:01
To: dev@syncope.apache.org
Subject: RE: Persistence id generation strategy: TABLE vs AUTO
Hi,
Fabio and Francesco: thanks for the fast feedback.
I cannot remember the good reason for this differences but it there was
...
In our experience with Apache Syncope (especially at the beginning)
there
are troubles with AUTO generated id in case of high concurrence.
Not only: some specific table generator associated to a given entity
(or set of
entities) were defined, and defined in orm.xml, not by annotations -
in order to give more flexibility when dealing with specific
requirements in id generation.
I also have not nice experience with AUTO strategy under high concurrency.
The question was more in following direction: does it make sense potentially
to use TABLE (in orm.xml) also for AbstractDerAttr, AbstractVirAttr,
Notification, UserRequest or there is good reason to keep them with AUTO
annotation?
I cannot be sure about the reason but, please, consider that
integration
tests are interdependent: the order and the existence of a certain
test are often fundamental.
Exactly, here's why text execution order is fixed.
Consider that integration tests were added over time and that their
number is starting to be quite considerable...
Yep, already see it from @FixMethodOrder annotation and from tests logic.
I am trying to found more or less reliable solution to keep
NotificationITTestCase re-runnable (SYNCOPE-268) - will investigate the
problem additionally and inform about result.
Cheers,
Andrei.
Regards.
Cheers,
Andrei.
(1)https://issues.apache.org/jira/browse/SYNCOPE-268
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
RE: Persistence id generation strategy: TABLE vs AUTO
Hi, Fabio and Francesco: thanks for the fast feedback. I cannot remember the good reason for this differences but it there was ... In our experience with Apache Syncope (especially at the beginning) there are troubles with AUTO generated id in case of high concurrence. Not only: some specific table generator associated to a given entity (or set of entities) were defined, and defined in orm.xml, not by annotations - in order to give more flexibility when dealing with specific requirements in id generation. I also have not nice experience with AUTO strategy under high concurrency. The question was more in following direction: does it make sense potentially to use TABLE (in orm.xml) also for AbstractDerAttr, AbstractVirAttr, Notification, UserRequest or there is good reason to keep them with AUTO annotation? I cannot be sure about the reason but, please, consider that integration tests are interdependent: the order and the existence of a certain test are often fundamental. Exactly, here's why text execution order is fixed. Consider that integration tests were added over time and that their number is starting to be quite considerable... Yep, already see it from @FixMethodOrder annotation and from tests logic. I am trying to found more or less reliable solution to keep NotificationITTestCase re-runnable (SYNCOPE-268) - will investigate the problem additionally and inform about result. Cheers, Andrei. Regards. Cheers, Andrei. (1)https://issues.apache.org/jira/browse/SYNCOPE-268 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[jira] [Commented] (SYNCOPE-259) Create transitional Service interfaces and switch tests and console to use them
[ https://issues.apache.org/jira/browse/SYNCOPE-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13551076#comment-13551076 ] Andrei Shakirin commented on SYNCOPE-259: - For PolicyService, SchemaService and TaskService there are two possibilities to marshal / unmarshal Collections containing abstract type: 1) Use Jackson JSON provider and Jackson specific annotation @JsonTypeInfo. Jackson additionally sends class information with each collection element 2) Use CXF JSONProvider and jaxbElementClassNames property. (2) way is more attractive from my perspective, because we are not depends on Jackson. Create transitional Service interfaces and switch tests and console to use them --- Key: SYNCOPE-259 URL: https://issues.apache.org/jira/browse/SYNCOPE-259 Project: Syncope Issue Type: Improvement Components: client, console, core Affects Versions: 1.1.0 Reporter: Christian Schneider Assignee: Jan Bernhardt Fix For: 1.1.0 Attachments: PolicyService.patch, ResourceService-1428511.patch, ResourceService.patch, SYNCOPE-259.patch As preparation of the change to use CXF instead of Spring MVC REST controllers this issue is to introduce transitional service interfaces (like as UserService). The UserService interface should later be used in the core to provide the UserController and on the console to access the service remotely. To make the transition easier the idea is to already introduce the interface upfront and change all tests and the console to use it. Before the switch the implementation of the interface will simply use the restTemplate under the covers. This to be applied similarly to all Spring MVC REST controllers. -- 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-259) Create transitional Service interfaces and switch tests and console to use them
[ https://issues.apache.org/jira/browse/SYNCOPE-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13543754#comment-13543754 ] Andrei Shakirin commented on SYNCOPE-259: - Hi Jan, Thanks, looks perfect now. (3): make sense to rename all paths of other services too: e.g. roles, users, loggers, configurations, etc? (4): as far as check verifies connection (LDAP, DB, WS, etc) I personally find names verify or check better as validate. Validate IMO related more to argument validity. Create transitional Service interfaces and switch tests and console to use them --- Key: SYNCOPE-259 URL: https://issues.apache.org/jira/browse/SYNCOPE-259 Project: Syncope Issue Type: Improvement Components: client, console, core Affects Versions: 1.1.0 Reporter: Christian Schneider Assignee: Jan Bernhardt Fix For: 1.1.0 Attachments: ResourceService-1428511.patch, ResourceService.patch, SYNCOPE-259.patch As preparation of the change to use CXF instead of Spring MVC REST controllers this issue is to introduce transitional service interfaces (like as UserService). The UserService interface should later be used in the core to provide the UserController and on the console to access the service remotely. To make the transition easier the idea is to already introduce the interface upfront and change all tests and the console to use it. Before the switch the implementation of the interface will simply use the restTemplate under the covers. This to be applied similarly to all Spring MVC REST controllers. -- 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] [Issue Comment Deleted] (SYNCOPE-259) Create transitional Service interfaces and switch tests and console to use them
[ https://issues.apache.org/jira/browse/SYNCOPE-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Shakirin updated SYNCOPE-259: Comment: was deleted (was: yep, connectorStatus sounds better (it not always physical connection)) Create transitional Service interfaces and switch tests and console to use them --- Key: SYNCOPE-259 URL: https://issues.apache.org/jira/browse/SYNCOPE-259 Project: Syncope Issue Type: Improvement Components: client, console, core Affects Versions: 1.1.0 Reporter: Christian Schneider Assignee: Jan Bernhardt Fix For: 1.1.0 Attachments: ResourceService-1428511.patch, ResourceService.patch, SYNCOPE-259.patch As preparation of the change to use CXF instead of Spring MVC REST controllers this issue is to introduce transitional service interfaces (like as UserService). The UserService interface should later be used in the core to provide the UserController and on the console to access the service remotely. To make the transition easier the idea is to already introduce the interface upfront and change all tests and the console to use it. Before the switch the implementation of the interface will simply use the restTemplate under the covers. This to be applied similarly to all Spring MVC REST controllers. -- 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-259) Create transitional Service interfaces and switch tests and console to use them
[
https://issues.apache.org/jira/browse/SYNCOPE-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13543790#comment-13543790
]
Andrei Shakirin commented on SYNCOPE-259:
-
Hi Jan,
Why do you think @GET is not appropriate for this operation? It is idempotent
and safe (there is not any modifications in resource status). As far as I can
see implementation not only validates arguments, but tries to establish (or
check) physical connection to backend.
For me GET /resources/{resourcename}/connectorStatus exactly reflects operation
semantic. Am I wrong?
Create transitional Service interfaces and switch tests and console to use
them
---
Key: SYNCOPE-259
URL: https://issues.apache.org/jira/browse/SYNCOPE-259
Project: Syncope
Issue Type: Improvement
Components: client, console, core
Affects Versions: 1.1.0
Reporter: Christian Schneider
Assignee: Jan Bernhardt
Fix For: 1.1.0
Attachments: ResourceService-1428511.patch, ResourceService.patch,
SYNCOPE-259.patch
As preparation of the change to use CXF instead of Spring MVC REST
controllers this issue is to introduce transitional service interfaces (like
as UserService).
The UserService interface should later be used in the core to provide the
UserController and on the console to access the service remotely.
To make the transition easier the idea is to already introduce the interface
upfront and change all tests and the console to use it. Before the switch the
implementation of the interface will simply use the restTemplate under the
covers.
This to be applied similarly to all Spring MVC REST controllers.
--
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-259) Create transitional Service interfaces and switch tests and console to use them
[ https://issues.apache.org/jira/browse/SYNCOPE-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13542833#comment-13542833 ] Andrei Shakirin commented on SYNCOPE-259: - I will start with ResourceController (ResourceService) today Create transitional Service interfaces and switch tests and console to use them --- Key: SYNCOPE-259 URL: https://issues.apache.org/jira/browse/SYNCOPE-259 Project: Syncope Issue Type: Improvement Components: client, console, core Affects Versions: 1.1.0 Reporter: Christian Schneider Assignee: Jan Bernhardt Fix For: 1.1.0 Attachments: SYNCOPE-259.patch As preparation of the change to use CXF instead of Spring MVC REST controllers this issue is to introduce transitional service interfaces (like as UserService). The UserService interface should later be used in the core to provide the UserController and on the console to access the service remotely. To make the transition easier the idea is to already introduce the interface upfront and change all tests and the console to use it. Before the switch the implementation of the interface will simply use the restTemplate under the covers. This to be applied similarly to all Spring MVC REST controllers. -- 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-259) Create transitional Service interfaces and switch tests and console to use them
[ https://issues.apache.org/jira/browse/SYNCOPE-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Shakirin updated SYNCOPE-259: Attachment: ResourceService.patch Added patch for ResourceService. Essential changes in JAX-RS annotations: 1) update. Operation is mapped to HTTP put instead post (as far as I can see update is idempotent); resourceName is added to URL - it allows also rename resource 2) delete. Operation is mapped to HTTP delete instead get. 3) check. Operation is mapped to HTTP get as far as it is save and idempotent Two operations check() and getPropagationActionsClasses() seems not to be directly related to resources. - check() validates connection instance and for me it is candidate for ConnInstanceService. Actually test for check() operation located in ConnInstancetestITCase. - getPropagationActionsClasses() returns list of class names for PROPAGATION_ACTIONS from classloader. Not sure that this operation should be in ResourceService. At the moment I leave both operations in ResourceService. Create transitional Service interfaces and switch tests and console to use them --- Key: SYNCOPE-259 URL: https://issues.apache.org/jira/browse/SYNCOPE-259 Project: Syncope Issue Type: Improvement Components: client, console, core Affects Versions: 1.1.0 Reporter: Christian Schneider Assignee: Jan Bernhardt Fix For: 1.1.0 Attachments: ResourceService.patch, SYNCOPE-259.patch As preparation of the change to use CXF instead of Spring MVC REST controllers this issue is to introduce transitional service interfaces (like as UserService). The UserService interface should later be used in the core to provide the UserController and on the console to access the service remotely. To make the transition easier the idea is to already introduce the interface upfront and change all tests and the console to use it. Before the switch the implementation of the interface will simply use the restTemplate under the covers. This to be applied similarly to all Spring MVC REST controllers. -- 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-251) Fix Dependency issues with ConnID Bundle deployment
[ https://issues.apache.org/jira/browse/SYNCOPE-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Shakirin updated SYNCOPE-251: Attachment: cxf-deps.patch Fix Dependency issues with ConnID Bundle deployment Key: SYNCOPE-251 URL: https://issues.apache.org/jira/browse/SYNCOPE-251 Project: Syncope Issue Type: Sub-task Components: core Environment: Linked issue on ConnId: http://code.google.com/p/connid/issues/detail?id=55 Reporter: Jan Bernhardt Assignee: Jan Bernhardt Fix For: 1.2.0 Attachments: cxf-deps.patch SOAP ConnID Bundle contains CXF dependencies, which cause Classloading issues when migrating Syncope to CXF, Currently maven-dependency-plugin:copy is used to generate bundle jars, but this plugin does not support to exclude transitive dependencies. Maybe another maven plugin (maven-assembly-plugin ?) can be used to exclude CXF dependencies from SOAP ConnID Bundle. -- 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-251) Fix Dependency issues with ConnID Bundle deployment
[ https://issues.apache.org/jira/browse/SYNCOPE-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13535808#comment-13535808 ] Andrei Shakirin commented on SYNCOPE-251: - Hi Francesco, Jan is in vacation until new year, I try the answer your question. The easiest way to reproduce the issue is just to add cxf dependencies in pom file (I attach patch for the trunk with cxf deps). You will see that some tests (depending on soap connector) will be failed. If you manually remove cxf jars from ConnId soap bundle in local maven repository and run tests again - they will be green. CXF branch still has some failures in integration tests, we are working on it (basically we successfully migrated UserController and RoleController, but as far as other tests still using old rest interface to access Users and Roles, there are some failures). Regarding the ConnId problem, I see 3 alternatives: 1) Produce two versions of ConnId bundles: with and without dependencies 2) Make classloading in ConnId configurable: provide a possibility to switch off lib/ jars from class loader 3) Experiment with non-default CXF bus (although Dan Kulp expects problem with this approach) Andrei. Fix Dependency issues with ConnID Bundle deployment Key: SYNCOPE-251 URL: https://issues.apache.org/jira/browse/SYNCOPE-251 Project: Syncope Issue Type: Sub-task Components: core Environment: Linked issue on ConnId: http://code.google.com/p/connid/issues/detail?id=55 Reporter: Jan Bernhardt Assignee: Jan Bernhardt Fix For: 1.2.0 Attachments: cxf-deps.patch SOAP ConnID Bundle contains CXF dependencies, which cause Classloading issues when migrating Syncope to CXF, Currently maven-dependency-plugin:copy is used to generate bundle jars, but this plugin does not support to exclude transitive dependencies. Maybe another maven plugin (maven-assembly-plugin ?) can be used to exclude CXF dependencies from SOAP ConnID Bundle. -- 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-256) Update Rest exception mapper to Apache CXF
[ https://issues.apache.org/jira/browse/SYNCOPE-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Shakirin updated SYNCOPE-256: Attachment: Unauthorized.patch Updates for exception mappers + integration test for unauthorized access Update Rest exception mapper to Apache CXF -- Key: SYNCOPE-256 URL: https://issues.apache.org/jira/browse/SYNCOPE-256 Project: Syncope Issue Type: Sub-task Components: client, core Environment: CXF branch Reporter: Andrei Shakirin Assignee: Jan Bernhardt Fix For: 1.1.0 Attachments: ExceptionMapper.patch, ExceptionMapperService.patch, ExceptionMapperUserTests.patch, syncopeClientError.jsp.patch, Unauthorized.patch 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
[jira] [Updated] (SYNCOPE-256) Update Rest exception mapper to Apache CXF
[ https://issues.apache.org/jira/browse/SYNCOPE-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Shakirin updated SYNCOPE-256: Attachment: ExceptionMapperUserTests.patch Updated UserTestItCase for CXF ExceptionMapper Update Rest exception mapper to Apache CXF -- Key: SYNCOPE-256 URL: https://issues.apache.org/jira/browse/SYNCOPE-256 Project: Syncope Issue Type: Sub-task Components: client, core Environment: CXF branch Reporter: Andrei Shakirin Assignee: Jan Bernhardt Attachments: ExceptionMapper.patch, ExceptionMapperService.patch, ExceptionMapperUserTests.patch 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
[jira] [Updated] (SYNCOPE-256) Update Rest exception mapper to Apache CXF
[ https://issues.apache.org/jira/browse/SYNCOPE-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Shakirin updated SYNCOPE-256: Attachment: syncopeClientError.jsp.patch Hi Jan, Two test cases are failed because of following refactoring in branch: two exceptions (InvalidSearchConditions and UnauthorizedRole) were moved to other package, but syncopeClientError.jsp was not updated correspondingly. As far as both tests called Resource controller that is not migrated to CXF - jsp page is invoked to map exceptions to http error code. Patch for jsp page is attached. Cheers, Andrei. Update Rest exception mapper to Apache CXF -- Key: SYNCOPE-256 URL: https://issues.apache.org/jira/browse/SYNCOPE-256 Project: Syncope Issue Type: Sub-task Components: client, core Environment: CXF branch Reporter: Andrei Shakirin Assignee: Jan Bernhardt Attachments: ExceptionMapper.patch, ExceptionMapperService.patch, ExceptionMapperUserTests.patch, syncopeClientError.jsp.patch 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
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.
[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
RE: [DISCUSS] Re: Extract syncope system/integration tests into separate project
Hi Francesco, I still see some benefits to extract integration tests applying to whole web application from real unit tests checking logic located only in current module. I agree that it is not urgent task at the moment, although it will make my development cycle faster even now. Do you have any concerns if I create jira for this with minor priority? Cheers, Andrei. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Dienstag, 11. Dezember 2012 11:25 To: dev@syncope.apache.org Subject: Re: [DISCUSS] Re: Extract syncope system/integration tests into separate project On 10/12/2012 10:40, Andrei Shakirin wrote: Hi Francesco, Yep, we need kind of plan to synchronize our work. I see the following order: 1. Merge the DEV_ROLE_PROVISIONING (Francesco) 2. Separate persistence layer SYNCOPE-241, SYNCOPE-242 (Christian) 3. Extract integration/system tests (Andrei) 4. Merge CXF branch (Jan, Christian, Andrei) For (4) some work still should be done, so I see this merge in the next year. What do you think? It sounds fine, as long as we agree that (3) is a good thing for the project, as it happened for (1), (2) and (4) :-) Regarding integration/system tests, I have some reasons to move them into separate maven module: 1) Integration and system tests are normally use not the single, but multiple modules (in syncope soon it will be core and persistence modules, further even more) Correct, but I don't see any reason to not keep the integration tests bundled with the module providing the REST interface. With maven, src/test is for tests and src/main for actual source code, isn't it? ;-) 2) Actually running integration tests takes about 3 mins, but I expect it will grow in the future. For me it is a reason to separate fast JUnit tests and integration tests to make development cycle shorter. It could be, but I don't see any reason for worrying about this now. 3) Integration and system tests normally require specific dependencies and logic: cargo plugin, unzip/copy web application, etc. Syncope can also be tested with different servlet containers (tomcat, glassfish, TomEE+, etc). I think placing this deps and logic in one project and reusing it has some benefits. Syncope core can be already tested against many servlet containers and many DBMSes (I went into more details about this in [1]). 4) Separate module for systests is kind of common practice in many apache projects: CXF, Camel, Karaf. Therefore separation can make understanding of Syncope build process more easy for communities from other apache projects. The projects you are mentioning are frameworks, and I see perfectly normal that for testing a framework you need to build test applications; but Syncope core is a web application, not a framework. What is your opinion? My concerns stand still; mainly, I don't see the point of having a Maven artifact like org.apache.syncope:syncope-core-integration-tests. Regards. [1] http://syncope-dev.1063484.n5.nabble.com/Introducing-myself-and-a- proposal-to-modularize-the-core-tp5711268p5711283.html -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Montag, 10. Dezember 2012 09:57 To: dev@syncope.apache.org Subject: [DISCUSS] Re: Extract syncope system/integration tests into separate project Hi all, let's try to make some order :-) The current situation is: 1. I am about to merge the DEV_ROLE_PROVISIONING branch into the trunk 2. Jan (with help from Christian) will then merge the cxf branch into the trunk and also apply some refactoring (see SYNCOPE-241 and SYNCOPE-242) by splitting the core module After (2) will have completed, we can think to discuss about additional refactoring, IMO. Now, I am not completely sure about the proposed refactoring, especially after what I expect from (2): could you please give more details about the benefits? For example, I am not sure that moving test classes and resources in separate modules (hence making such classes part of the release) is necessarily a good thing. Regards. On 10/12/2012 09:41, Andrei Shakirin wrote: Hi JB, I mean just maven module, sure :) What do you prefer as a name? a) itests b) systests Cheers, Andrei. -Original Message- From: Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Sent: Sonntag, 9. Dezember 2012 20:47 To: dev@syncope.apache.org Subject: Re: Extract syncope system/integration tests into separate project Hi Andrei, by separate project, you mean a real project (with its own release cycle, artifacts, svn repo, etc), or just a Maven module ? I don't think it's a good idea to have it in a separate real project as it's coupled to the others artifacts/modules/codebase. But a itest Maven module it's a good think (it's what we have most of projects
RE: [DISCUSS] Re: Extract syncope system/integration tests into separate project
No at all, even though I'd prefer to hear also someone else's though about this before getting into JIRA: it's only you, me and Christian so far... It was +1 from JB on Sunday, but not anymore. Interesting to hear Jan and Colm. Andrei. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Mittwoch, 12. Dezember 2012 10:48 To: dev@syncope.apache.org Subject: Re: [DISCUSS] Re: Extract syncope system/integration tests into separate project On 12/12/2012 10:44, Andrei Shakirin wrote: Hi Francesco, I still see some benefits to extract integration tests applying to whole web application from real unit tests checking logic located only in current module. I agree that it is not urgent task at the moment, although it will make my development cycle faster even now. Do you have any concerns if I create jira for this with minor priority? No at all, even though I'd prefer to hear also someone else's though about this before getting into JIRA: it's only you, me and Christian so far... Regards. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Dienstag, 11. Dezember 2012 11:25 To: dev@syncope.apache.org Subject: Re: [DISCUSS] Re: Extract syncope system/integration tests into separate project On 10/12/2012 10:40, Andrei Shakirin wrote: Hi Francesco, Yep, we need kind of plan to synchronize our work. I see the following order: 1. Merge the DEV_ROLE_PROVISIONING (Francesco) 2. Separate persistence layer SYNCOPE-241, SYNCOPE-242 (Christian) 3. Extract integration/system tests (Andrei) 4. Merge CXF branch (Jan, Christian, Andrei) For (4) some work still should be done, so I see this merge in the next year. What do you think? It sounds fine, as long as we agree that (3) is a good thing for the project, as it happened for (1), (2) and (4) :-) Regarding integration/system tests, I have some reasons to move them into separate maven module: 1) Integration and system tests are normally use not the single, but multiple modules (in syncope soon it will be core and persistence modules, further even more) Correct, but I don't see any reason to not keep the integration tests bundled with the module providing the REST interface. With maven, src/test is for tests and src/main for actual source code, isn't it? ;-) 2) Actually running integration tests takes about 3 mins, but I expect it will grow in the future. For me it is a reason to separate fast JUnit tests and integration tests to make development cycle shorter. It could be, but I don't see any reason for worrying about this now. 3) Integration and system tests normally require specific dependencies and logic: cargo plugin, unzip/copy web application, etc. Syncope can also be tested with different servlet containers (tomcat, glassfish, TomEE+, etc). I think placing this deps and logic in one project and reusing it has some benefits. Syncope core can be already tested against many servlet containers and many DBMSes (I went into more details about this in [1]). 4) Separate module for systests is kind of common practice in many apache projects: CXF, Camel, Karaf. Therefore separation can make understanding of Syncope build process more easy for communities from other apache projects. The projects you are mentioning are frameworks, and I see perfectly normal that for testing a framework you need to build test applications; but Syncope core is a web application, not a framework. What is your opinion? My concerns stand still; mainly, I don't see the point of having a Maven artifact like org.apache.syncope:syncope-core-integration-tests. Regards. [1] http://syncope-dev.1063484.n5.nabble.com/Introducing-myself-and-a- proposal-to-modularize-the-core-tp5711268p5711283.html -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Montag, 10. Dezember 2012 09:57 To: dev@syncope.apache.org Subject: [DISCUSS] Re: Extract syncope system/integration tests into separate project Hi all, let's try to make some order :-) The current situation is: 1. I am about to merge the DEV_ROLE_PROVISIONING branch into the trunk 2. Jan (with help from Christian) will then merge the cxf branch into the trunk and also apply some refactoring (see SYNCOPE-241 and SYNCOPE-242) by splitting the core module After (2) will have completed, we can think to discuss about additional refactoring, IMO. Now, I am not completely sure about the proposed refactoring, especially after what I expect from (2): could you please give more details about the benefits? For example, I am not sure that moving test classes and resources in separate modules (hence making such classes part of the release) is necessarily a good thing. Regards. On 10/12/2012 09:41, Andrei
RE: [DISCUSS] Re: Extract syncope system/integration tests into separate project
Hi Francesco, I would propose to close discussion with -1 for now without creating jira issue. If community will see this refactoring necessary in the future we can reopen the discussion. For sure we have actually more urgent and important things to process. Do you agree? Cheers, Andrei. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Mittwoch, 12. Dezember 2012 13:23 To: dev@syncope.apache.org Subject: Re: [DISCUSS] Re: Extract syncope system/integration tests into separate project On 12/12/2012 12:51, Colm O hEigeartaigh wrote: Like Christian, I'm +0 to this idea. In other words, I think it's probably a good idea, but don't have strong feelings either way ;-) The main advantage that I can see to doing this is that it may make core development a bit easier, by not having to run the integration tests all the time (incidentally: is there an easy way to skip the integration tests?). Sorry if I am saying something obvious but: * 'mvn clean package' will just stop before verify, hence not triggering the maven-failsafe-plugin * 'mvn clean verify -DskipTests' will avoid integration test execution but will start the environment (including Tomcat) anyway Alternatively, you should comment the executions element of the cargo- maven2-plugin in core/pom.xml AND pass -DskipTests We can, of course, define a specific profile in core/pom.xml with these settings. Francesco, do you have any specific objections to this proposal, or is it just that you are not convinced of the arguments in favour? I am 1. not convinced of some pros (speeding build time? With 3 mins?) 2. worried about fragmentation 3. not convinced of releasing Maven artifacts containing test classes as main content: what's the 'src/test' directory or the 'tests' classifier for, then? Anyway, if anyone can enlighten me about (2) and (3), I can be +0 as well. IMO it's not worth the hassle in arguing over this minor issue. If the pro argument I mentioned above is not agreed by everyone, then I propose we - 1 this proposal and move on. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[jira] [Created] (SYNCOPE-247) Use complete UUID as role name to avoid problems by test rerun
Andrei Shakirin created SYNCOPE-247: --- Summary: Use complete UUID as role name to avoid problems by test rerun Key: SYNCOPE-247 URL: https://issues.apache.org/jira/browse/SYNCOPE-247 Project: Syncope Issue Type: Improvement Environment: CXF branch Reporter: Andrei Shakirin Assignee: Jan Bernhardt Attachments: AbstractRoleTestITCase.java.patch Actually some of Role integration tests (issue 228, crud) cannot be rerun. Reason: only 8 first characters from UUID is used as role name, that causes name collisions. Patch for the CXF branch is attached. Regards, Andrei. -- 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
