Re: Escaping in Velocity templates for notifications
On 24/03/2014 17:03, Guido Wimmel wrote: Hi Francesco, ok - if it's considered useful, I can have a closer look at it. I've opened a corresponding JIRA issue (https://issues.apache.org/jira/browse/SYNCOPE-487). Possibly I have time for this this week, but I cannot promise. I don't think adding the Velocity tools to the context passed to the generation is possible without modifying the NotificationManager, as I do not see a way to affect the context only by configuring the Velocity engine (which seems consistent with the information in the link [3] you posted). If I can provide a suggested implementation, should this be against 1_1_X or trunk? I'd say you can start with 1_1_X, but then it absolutely needs to be ported to trunk as well. Should I provide a patch file first? Only if you want to get some review, otherwise... you're committer a now ;-) Regards. Gesendet: Dienstag, 11. März 2014 um 08:59 Uhr Von: Francesco Chicchiriccò ilgro...@apache.org An: dev@syncope.apache.org Betreff: Re: Escaping in Velocity templates for notifications On 11/03/2014 08:36, Francesco Chicchiriccò wrote: On 10/03/2014 15:55, Guido Wimmel wrote: Hi, we have the requirement that the username in a notification mail must be URL-encoded (as part of a link inside the mail). Is there a way to do this in Syncope currently? As far as I understand the code generating the mails (NotificationManager), probably not? If not, a way to achieve this could be to add the Velocity EscapeTool [1] to the Velocity context before executing the template. This could be generalized by making NotificationManager extensible such that the creation of the Velocity context can be modified, and possibly providing an implementation that adds the Velocity toolbox, maybe in a similar way as in Spring MVC [2]. What do you think? Hi Guido, +1, adding such feature seems noticeable. Only, I was wondering whether you can add the EscapeTool to the Velocity context just via Spring configuration: as you can see, in fact, the NotificationManager autowires the VelocityEngine from the following Spring bean (defined in workflowContext.xml): bean id=velocityEngine class=org.springframework.ui.velocity.VelocityEngineFactoryBean property name=velocityProperties value resource.loader=class class.resource.loader.class=org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader /value /property /bean I am not sure of the way to do this, but it seems logical to me that [1] (which seems to be provided by Maven dependency velocity-tools::velocity-tools-generic::1.4) can be injected into the velocityEngine bean above without affecting the actual NotificationManager Java code: am I wrong? Update: I've found that the latest stable version of Velocity Tools seems to be dependency groupIdorg.apache.velocity/groupId artifactIdvelocity-tools/artifactId version2.0/version /dependency Moreover, the approach shown in [3] (more or less the one that I suggest above) seems to be problematic: could you please check? Regards. [1] http://velocity.apache.org/tools/devel/generic/EscapeTool.html [2] http://docs.spring.io/spring/docs/3.2.8.RELEASE/javadoc-api/org/springframework/web/servlet/view/velocity/VelocityViewResolver.html [3] http://stackoverflow.com/questions/14237862/how-get-velocityengine-with-velocity-tools-in-spring-3 -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PMC http://people.apache.org/~ilgrosso/
Re: Need a concept to integrate RFID access control with Apache Syncope
Hi, please subscribe to either dev@syncope.apache.org (or u...@syncope.apache.org which would better suit this kind of requests) otherwise any post from you will go moderated and you likely won't get any response. I'd suggest you to subscribe to u...@syncope.apache.org by sending an empty e-mail to user-subscr...@syncope.apache.org and following instructions, then to re-submit this question there. At that point you can post your requests either via mail or the Nabble forum at http://syncope-user.1051894.n5.nabble.com/ Best regards. On 14/03/2014 09:39, faisal wrote: Hi guys, Please help me to understand a concept and a confirmation from you experts that i need to implement an access control based on RFID (Radio Frequency Identification) system. Its basically a device which will work on network and user will show the card on this device and the reader will read its ID and authentication happens. Is there a kind of possibility to integrate and map this IDs with user id which will create on Syncope. Please dont get mad on me. I am just a new one to this product. Please give me some light or an advice to get me out of this problem. Regards Faisal -- View this message in context: http://syncope-dev.1063484.n5.nabble.com/Need-a-concept-to-integrate-RFID-access-control-with-Apache-Syncope-tp5714992.html Sent from the syncope-dev mailing list archive at Nabble.com. -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PPMC http://people.apache.org/~ilgrosso/
Re: Escaping in Velocity templates for notifications
On 10/03/2014 15:55, Guido Wimmel wrote: Hi, we have the requirement that the username in a notification mail must be URL-encoded (as part of a link inside the mail). Is there a way to do this in Syncope currently? As far as I understand the code generating the mails (NotificationManager), probably not? If not, a way to achieve this could be to add the Velocity EscapeTool [1] to the Velocity context before executing the template. This could be generalized by making NotificationManager extensible such that the creation of the Velocity context can be modified, and possibly providing an implementation that adds the Velocity toolbox, maybe in a similar way as in Spring MVC [2]. What do you think? Hi Guido, +1, adding such feature seems noticeable. Only, I was wondering whether you can add the EscapeTool to the Velocity context just via Spring configuration: as you can see, in fact, the NotificationManager autowires the VelocityEngine from the following Spring bean (defined in workflowContext.xml): bean id=velocityEngine class=org.springframework.ui.velocity.VelocityEngineFactoryBean property name=velocityProperties value resource.loader=class class.resource.loader.class=org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader /value /property /bean I am not sure of the way to do this, but it seems logical to me that [1] (which seems to be provided by Maven dependency velocity-tools::velocity-tools-generic::1.4) can be injected into the velocityEngine bean above without affecting the actual NotificationManager Java code: am I wrong? Regards. [1] http://velocity.apache.org/tools/devel/generic/EscapeTool.html [2] http://docs.spring.io/spring/docs/3.2.8.RELEASE/javadoc-api/org/springframework/web/servlet/view/velocity/VelocityViewResolver.html -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PPMC http://people.apache.org/~ilgrosso/
Re: Escaping in Velocity templates for notifications
On 11/03/2014 08:36, Francesco Chicchiriccò wrote: On 10/03/2014 15:55, Guido Wimmel wrote: Hi, we have the requirement that the username in a notification mail must be URL-encoded (as part of a link inside the mail). Is there a way to do this in Syncope currently? As far as I understand the code generating the mails (NotificationManager), probably not? If not, a way to achieve this could be to add the Velocity EscapeTool [1] to the Velocity context before executing the template. This could be generalized by making NotificationManager extensible such that the creation of the Velocity context can be modified, and possibly providing an implementation that adds the Velocity toolbox, maybe in a similar way as in Spring MVC [2]. What do you think? Hi Guido, +1, adding such feature seems noticeable. Only, I was wondering whether you can add the EscapeTool to the Velocity context just via Spring configuration: as you can see, in fact, the NotificationManager autowires the VelocityEngine from the following Spring bean (defined in workflowContext.xml): bean id=velocityEngine class=org.springframework.ui.velocity.VelocityEngineFactoryBean property name=velocityProperties value resource.loader=class class.resource.loader.class=org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader /value /property /bean I am not sure of the way to do this, but it seems logical to me that [1] (which seems to be provided by Maven dependency velocity-tools::velocity-tools-generic::1.4) can be injected into the velocityEngine bean above without affecting the actual NotificationManager Java code: am I wrong? Update: I've found that the latest stable version of Velocity Tools seems to be dependency groupIdorg.apache.velocity/groupId artifactIdvelocity-tools/artifactId version2.0/version /dependency Moreover, the approach shown in [3] (more or less the one that I suggest above) seems to be problematic: could you please check? Regards. [1] http://velocity.apache.org/tools/devel/generic/EscapeTool.html [2] http://docs.spring.io/spring/docs/3.2.8.RELEASE/javadoc-api/org/springframework/web/servlet/view/velocity/VelocityViewResolver.html [3] http://stackoverflow.com/questions/14237862/how-get-velocityengine-with-velocity-tools-in-spring-3 -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PPMC http://people.apache.org/~ilgrosso/
Re: Two minor issues
On 05/03/2014 17:05, Colm O hEigeartaigh wrote: Hi all, Hi Colm, Two minor things I've noticed with the latest release that are possibly bugs. a) The 1.1.6 standalone Tomcat distribution does not preserve execution permissions on the scripts in /bin. Possibly it never did + I didn't notice it before ;-) In any case I had to chmod +x the .sh files to get it to run. Unfortunately, this is a known problem of the ZIP archive [1]. b) There is no facility in the schema section of the console to delete all attributes. Is this an oversight? It's possibly to delete all users, connectors, roles, tasks, resources, etc. I guess this is due to the fact that deleting an attribute schema would imply deleting all attributes of all entities (users, roles or memberships) for that schema: Fabio, could you confirm this? Regards. [1] https://cwiki.apache.org/confluence/display/SYNCOPE/Run+Syncope+standalone+distribution#RunSyncopestandalonedistribution-Running -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PPMC http://people.apache.org/~ilgrosso/
[ANN] Apache Syncope 1.1.6 released
The Apache Syncope team is pleased to announce the release of Syncope 1.1.6. Apache Syncope is an Open Source system for managing digital identities in enterprise environments, implemented in JEE technology . The release will be available within 24h from: http://syncope.apache.org/downloads.html The full change log is available here: http://ur1.ca/gpa27 We welcome your help and feedback. For more information on how to report problems, and to get involved, visit the project website at http://syncope.apache.org/ The Apache Syncope Team
Re: Persistence Layer in Syncope, Table Creation, orm.xml, content.xml
On 24/02/2014 21:13, Oliver Wulff wrote: Hi Francesco I guess that one could rewrite ContentLoader, ContentUpgrader and ContentExporter to work with EntityManager and thus remove spring-jdbc from main dependencies (it will still be used by integration tests code). I decided to use the JPA Layer instead of JDBC Template to initially load the db https://issues.apache.org/jira/browse/FEDIZ-78 But I don't have to write a ContextLoader then anymore as I can configure all the entity beans in an isolated spring configuration file, load it and call persist on all object types in a certain order: http://svn.apache.org/viewvc/cxf/fediz/trunk/services/idp/src/main/java/org/apache/cxf/fediz/service/idp/service/jpa/DBLoaderSpring.java?view=markup Wouldn't that not make sense for Syncope as well? This approach looks interesting, indeed: are you going to experiment with it in Syncope trunk? The OpenJPA also supports to create the indexes - well in a proprietary way till JPA 2.1 is officially supported. This is very interesting as well: upgrading to JPA 2.1 as soon as OpenJPA supports it officially is definitely in our aims, I'd say. Regards. From: Oliver Wulff [owu...@talend.com] Sent: 05 January 2014 14:44 To: dev@syncope.apache.org Subject: RE: Persistence Layer in Syncope, Table Creation, orm.xml, content.xml OpenJPA is initialized via Spring in persistenceContextEMFactory.xml: as you can read from there, the OpenJpaVendorAdapter is configured with 'generateDdl' true. Even this was set to true (in my case for Fediz IDP) it didn't create the table therefore I thought there must be something else missing. Thanks Oli From: Francesco Chicchiriccò [ilgro...@apache.org] Sent: 03 January 2014 14:06 To: dev@syncope.apache.org Subject: Re: Persistence Layer in Syncope, Table Creation, orm.xml, content.xml On 03/01/2014 13:56, Oliver Wulff wrote: Thanks for your feedback. I didn't find where you configure OpenJPA to create the tables when the spring context is created. You do all the initialization work in SpringContextInitializer which also loads the table if empty. OpenJPA is initialized via Spring in persistenceContextEMFactory.xml: as you can read from there, the OpenJpaVendorAdapter is configured with 'generateDdl' true. I've used an ApplicationListener and used JPA to insert the records into the tables which will also create tables implicitly. Will try to write a JPA based ContentLoader to fill the data. Good news: in case, please do it with reference to trunk (not 1_1_X branch). Regards. From: Francesco Chicchiriccò [ilgro...@apache.org] Sent: 31 December 2013 09:14 To: dev@syncope.apache.org Subject: Re: Persistence Layer in Syncope, Table Creation, orm.xml, content.xml On 30/12/2013 21:44, Oliver Wulff wrote: Hi there I'm looking into adding a persistence layer to the Apache Fediz Identity Provider and used the persistence layer in Syncope as a good reference. Nevertheless, I got a few questions... Hey, looks cool :-) 1) JPA creates the tables when the first entity is added - usually triggered by a REST call. They won't be created when the spring application context is loaded. The Syncope ContentLoader does only add rows to existing tables and creates indexes and views, but no tables. How did you workaround this? OpenJPA is configured in Syncope to create tables when Spring context is loaded (you can experiment this by providing an empty content.xml or by disabling the ContentLoader). 2) What was the reason for you to create an orm.xml instead of using annotations only? The general policy was to use orm.xml for all configurable parameters that would have been instead stuck as annotation parameters in the source code. For example: putting table generators in orm.xml lets you easily configure the initial value to pick without changing the source code. This is very useful in Syncope since it is meant to be used via WAR overlays. 3) You introduced your own semantic of a file to import default data (content.xml). I assume you did not use an SQL script to be independent of the database? Correct. But why did you use the JDBC template instead of the JPA layer? Hum, that's a nice question, probably related to the evolution that ContentLoader had from original (pre-ASF) DBUnit. I guess that one could rewrite ContentLoader, ContentUpgrader and ContentExporter to work with EntityManager and thus remove spring-jdbc from main dependencies (it will still be used by integration tests code). Regards. -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PPMC http://people.apache.org/~ilgrosso/
Re: [VOTE] Apache Syncope 1.1.6
On 22/02/2014 17:44, Francesco Chicchiriccò wrote: I've created a 1.1.6 release, with the following artifacts up for a vote: SVN source tag (r1570853): https://svn.apache.org/repos/asf/syncope/tags/syncope-1.1.6/ List of changes: https://svn.apache.org/repos/asf/syncope/tags/syncope-1.1.6/CHANGES Maven staging repo: https://repository.apache.org/content/repositories/orgapachesyncope-1000/ Source release (checksums and signatures are available at the same location): http://repository.apache.org/content/repositories/orgapachesyncope-1000/org/apache/syncope/syncope/1.1.6/syncope-1.1.6-source-release.zip Staging site: http://syncope.apache.org/1.1.6/ 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) +1 Regards. -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PPMC http://people.apache.org/~ilgrosso/
[VOTE] Apache Syncope 1.1.6
I've created a 1.1.6 release, with the following artifacts up for a vote: SVN source tag (r1570853): https://svn.apache.org/repos/asf/syncope/tags/syncope-1.1.6/ List of changes: https://svn.apache.org/repos/asf/syncope/tags/syncope-1.1.6/CHANGES Maven staging repo: https://repository.apache.org/content/repositories/orgapachesyncope-1000/ Source release (checksums and signatures are available at the same location): http://repository.apache.org/content/repositories/orgapachesyncope-1000/org/apache/syncope/syncope/1.1.6/syncope-1.1.6-source-release.zip Staging site: http://syncope.apache.org/1.1.6/ 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ò Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PPMC http://people.apache.org/~ilgrosso/
[DISCUSS] Apache Syncope 1.1.6
Discussion thread for vote on 1.1.6 release, with SVN source tag (r1570853). For more information on the release process, check out http://www.apache.org/dev/release.html Some of the things to check before voting are: - does mvn apache-rat:check pass on the source - can you build the contents of source release zip and SVN tag - do all of the staged jars/wars/zips contain the required LICENSE and NOTICE files - are all of the staged jars/wars/zips signed and the signature verifiable - is the signing key in the project's KEYS file and on a public server (i.e. http://www.apache.org/dist/syncope/) -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PPMC http://people.apache.org/~ilgrosso/
Work for next major release 1.2.0
Hi fellow Syncopers, lately we have been experimenting a very quiet period around here (take a look at diagram showing at http://syncope.markmail.org to get a confirmation). I know this just probably means that everyone - including me - is busy with other (likely paid) tasks, but I want to point out that, even though a nice amount of great features has been embodied in 1.2.0-SNAPSHOT, there is still a lot to do [1]. Maybe not everything (as discussed in [2]), but still *a lot*. Please, anyone interested in contributing to reach this goal, step in: there's much to do! Regards. [1] https://issues.apache.org/jira/issues/?jql=project%20%3D%20SYNCOPE%20AND%20fixVersion%20%3D%20%221.2.0%22%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20ORDER%20BY%20status%20DESC%2C%20priority%20DESC [2] http://markmail.org/message/nv2v4s5f7sofdiwe -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PPMC http://people.apache.org/~ilgrosso/
Re: RestServiceExceptionMapper
On 26/01/2014 23:09, Oliver Wulff wrote: Hi there I noticed that Syncope gives more detailed exception information back in the RestServiceExceptionMapper by using the enum SyncopeClientExceptionType. The exception information is returned in the HTTP response header 'ExceptionType'. I've found in some sources ([1],[2]) that this kind of information could be returned in the http header X-Application-Error-Code and X-Application-Error-Info. What do you think about considering to change the header in 1.2 to X-Application-Error-Code instead of ExceptionType? What do you think about it? Hi Oliver, I've been searching for some more references about X-Application-Error-Code and X-Application-Error-Info HTTP headers and it looks they do have some consensus out there. As you will see, things are quite different in trunk (1.2.0-SNAPSHOT) - see [3] and [4] - and should already be in the direction of your proposed change. The only problem I could see is in case of composite exceptions [5] where multiple exception headers need to be returned and there should be some mechanism for binding the error-code with info information. Anyway, please file an improvement on JIRA targeted to 1.2.0. Regards. [1] https://github.com/FriendsOfSymfony/FOSRestBundle/issues/280 [2] http://www.taliferro.com/29-rest-services-tips/ [3] http://svn.apache.org/repos/asf/syncope/trunk/client/src/main/java/org/apache/syncope/client/rest/RestClientExceptionMapper.java [4]http://svn.apache.org/repos/asf/syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/utils/RestServiceExceptionMapper.java [5] http://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/SyncopeClientCompositeException.java -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: Persistence Layer in Syncope, Table Creation, orm.xml, content.xml
On 03/01/2014 13:56, Oliver Wulff wrote: Thanks for your feedback. I didn't find where you configure OpenJPA to create the tables when the spring context is created. You do all the initialization work in SpringContextInitializer which also loads the table if empty. OpenJPA is initialized via Spring in persistenceContextEMFactory.xml: as you can read from there, the OpenJpaVendorAdapter is configured with 'generateDdl' true. I've used an ApplicationListener and used JPA to insert the records into the tables which will also create tables implicitly. Will try to write a JPA based ContentLoader to fill the data. Good news: in case, please do it with reference to trunk (not 1_1_X branch). Regards. From: Francesco Chicchiriccò [ilgro...@apache.org] Sent: 31 December 2013 09:14 To: dev@syncope.apache.org Subject: Re: Persistence Layer in Syncope, Table Creation, orm.xml, content.xml On 30/12/2013 21:44, Oliver Wulff wrote: Hi there I'm looking into adding a persistence layer to the Apache Fediz Identity Provider and used the persistence layer in Syncope as a good reference. Nevertheless, I got a few questions... Hey, looks cool :-) 1) JPA creates the tables when the first entity is added - usually triggered by a REST call. They won't be created when the spring application context is loaded. The Syncope ContentLoader does only add rows to existing tables and creates indexes and views, but no tables. How did you workaround this? OpenJPA is configured in Syncope to create tables when Spring context is loaded (you can experiment this by providing an empty content.xml or by disabling the ContentLoader). 2) What was the reason for you to create an orm.xml instead of using annotations only? The general policy was to use orm.xml for all configurable parameters that would have been instead stuck as annotation parameters in the source code. For example: putting table generators in orm.xml lets you easily configure the initial value to pick without changing the source code. This is very useful in Syncope since it is meant to be used via WAR overlays. 3) You introduced your own semantic of a file to import default data (content.xml). I assume you did not use an SQL script to be independent of the database? Correct. But why did you use the JDBC template instead of the JPA layer? Hum, that's a nice question, probably related to the evolution that ContentLoader had from original (pre-ASF) DBUnit. I guess that one could rewrite ContentLoader, ContentUpgrader and ContentExporter to work with EntityManager and thus remove spring-jdbc from main dependencies (it will still be used by integration tests code). Regards. -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: Persistence Layer in Syncope, Table Creation, orm.xml, content.xml
On 30/12/2013 21:44, Oliver Wulff wrote: Hi there I'm looking into adding a persistence layer to the Apache Fediz Identity Provider and used the persistence layer in Syncope as a good reference. Nevertheless, I got a few questions... Hey, looks cool :-) 1) JPA creates the tables when the first entity is added - usually triggered by a REST call. They won't be created when the spring application context is loaded. The Syncope ContentLoader does only add rows to existing tables and creates indexes and views, but no tables. How did you workaround this? OpenJPA is configured in Syncope to create tables when Spring context is loaded (you can experiment this by providing an empty content.xml or by disabling the ContentLoader). 2) What was the reason for you to create an orm.xml instead of using annotations only? The general policy was to use orm.xml for all configurable parameters that would have been instead stuck as annotation parameters in the source code. For example: putting table generators in orm.xml lets you easily configure the initial value to pick without changing the source code. This is very useful in Syncope since it is meant to be used via WAR overlays. 3) You introduced your own semantic of a file to import default data (content.xml). I assume you did not use an SQL script to be independent of the database? Correct. But why did you use the JDBC template instead of the JPA layer? Hum, that's a nice question, probably related to the evolution that ContentLoader had from original (pre-ASF) DBUnit. I guess that one could rewrite ContentLoader, ContentUpgrader and ContentExporter to work with EntityManager and thus remove spring-jdbc from main dependencies (it will still be used by integration tests code). Regards. -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [REQUEST] Checking admin console on trunk
On 30/12/2013 10:28, Marco Di Sabatino Di Diodoro wrote: Hi, Il giorno 29/dic/2013, alle ore 15:30, Fabio Martelli fabio.marte...@gmail.com ha scritto: Il 27/12/2013 15:33, Francesco Chicchiriccò ha scritto: Hi all, in the last days I've been cleaning up the admin console code on trunk with a couple of targets: (a) using SpinnerFieldPanel (a field panel using JQuery UI's spinner [1]) everywhere possible and (b) remove Xlint:unchecked compiler warnings. I did some careful tests (besides Selenium's of course), but since I had to make a lot of (often non-trivial) changes, it would be cool if someone can take some time to intensively check all admin console features. I find two errors: 1) I edit a policy and change type to Global Policy, the core returns an internal server error. This also affects 1_1_X, hence it is again unrelated to my latest changes; anyway I've opened SYNCOPE-466. 2) After executing a report, select the type of report to download, Apache Syncope returns a Wicket Error. Just fixed in http://svn.apache.org/r1554177 Regards. [1] http://jqueryui.com/spinner/ I'm not sure if you can be interested by https://issues.apache.org/jira/browse/SYNCOPE-465 Regards, F. -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: Fwd: [PROPOSAL] ProvisioningManager refactoring
On 23/12/2013 16:59, Hadrian Zbarcea wrote: [resent from my a.o account] Hi, As previously discussed, Giacomo started a proof of concept on github [1] to investigate the feasibility of implementing a declarative and more flexible processing of user lifecycle events using Camel routes. The poc is progressing rather well and core to the idea is a new ProvisioningManager interface that abstracts the event handling away from the UserController. This has proven to work (see code on github), but it led us the following proposal: 1. Make the ProvisioningManager interface Camel independent 2. Implement a DefaultProvisioningManager that keeps intact the current (hardcoded) functionality. 3. Move the camel based functionality into a separate CamelProvisioningManager. 4. Move the CamelProvisioningManager and all camel related functionality into a separate module (jar). The intent is to: a. Keep the syncope core simple and not cluttered with unnecessary functionality. b. Make the provisioning pluggable. c. Keep the core unit testing simple and isolated d. Keep the camel related functionality separate (and easier to unit test) The same approach would go for roles as well. Thoughts? Hi Hadrian, I've taken a look at implementation at [1] and it seems very interesting. I also think that your proposal of encapsulating the provisioning logic into a separate, overridable, ProvisioningManager seems very good. Having a separate, camel-enabled, module is also wise and could be taken as starting point for some more refactoring of the core (by extracting Activiti-related stuff, for example). Hence, my +1 to your whole proposal. Regards. [1] https://github.com/Tirasa/SyncopeCamel -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: Status of Apache Camel integration proposal
far can be easily changed: I will be very happy of any suggestion! WDYT? [1] http://syncope-dev.1063484.n5.nabble.com/Proposal-An-Apache-Camel-Integratation-Proposal-td5714531.html [2] http://www.slideshare.net/giacomolm/camel-proposaltirasa [3] https://github.com/Tirasa/SyncopeCamel -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: BasicDataSource usage in persistence.xml
On 10/12/2013 08:57, Guido Wimmel wrote:
Hi Oliver,
Gesendet: Montag, 09. Dezember 2013 um 22:22 Uhr
Von: Oliver Wulff owu...@talend.com
@Guido, is the property connectionProperties sufficient which is a semi-colon
separated string:
http://commons.apache.org/proper/commons-dbcp/configuration.html
No, connectionProperties only sets properties on the JDBC driver, not on the
connection pool.
If the persistence.properties file is considered to be too polluted with too
many connection pool
settings, I see two possibilities:
* only make the most important ones configurable externally (I've suggested
some below);
people who want to change more settings can still overwrite
persistenceContext.xml; and/or
* use the Spring default mechanism for properties
(i.e.${jpa.pool.maxActive:8}); thus the properties that keep their default
value can be omitted in the properties file, with the disadvantage that one
does not immediately see that they are configurable, and the advantage that
there is no need to change the configuration file of existing Syncope
installations. I'd would be even better if one could make Spring not set the
value at all (i.e. use DBCP's default) if not specified, but I don't think this
is possible.
WDYT?
Hi Guido,
I'd say latter option (e.g. Spring properties with default values) is
fine: would you mind to grab Oliver's patch, apply your changes and
re-attach?
@Francesco: I'd be interested in why ISOLATION_READ_COMMITTED was chosen to be
set explicitly as a transaction level (but only on localDataSource, not jndi) -
was there a specific reason?
A quick search of mail archives (via http://syncope.markmail.org) gave
this commit (released as part of 1.0.2-incubating)
http://svn.apache.org/viewvc?view=revisionrevision=1392392
which is bound to
https://issues.apache.org/jira/browse/SYNCOPE-124
https://issues.apache.org/jira/browse/SYNCOPE-202
SYNCOPE-202 in particular refers to integration tests problems with
MySQL (and Oracle): here's why the isolation level was set to the
DataSource that was supposed - till this discussion - to be only used
for integration tests.
This fact also leads to the consideration that before committing any
patch, all supported DBMS needs to be checked.
BTW, one can also set the default transaction isolation on dbcp directly (but then either
as an int value or with some Spring tricks to refer to a constant). This may be more
robust; in the IsolationLevelDataSourceAdapter javadoc there's a warning that one must
make sure that the target DataSource properly cleans up such transaction
state (though no idea if this applies in our case).
Hum, not sure either of what that means: anyway in general I'd say DBCP
is good enough for cleaning up its stuff.
Regards.
@Francesco: I understand your concern. On the other hand you could argue that
the jpa.properties file becomes completely BasicDataSource dependent. But maybe
the connectionProperties property is sufficient.
Thanks
Oli
From: Francesco Chicchiriccò [ilgro...@apache.org]
Sent: 09 December 2013 09:29
To: dev@syncope.apache.org
Subject: Re: BasicDataSource usage in persistence.xml
On 08/12/2013 14:54, Oliver Wulff wrote:
Hi there
JIRA raised and patch applied:
https://issues.apache.org/jira/browse/SYNCOPE-460[https://issues.apache.org/jira/browse/SYNCOPE-460]
WRT the BasicDataSource properties... what do you think about adding only
connectionProperties which could be a file with the BasicDataSource properties.
Patch looks fine, thanks!
I would avoid proliferating of properties file that would make harder
times with generation from archetype, so I'd keep with adding entries in
persistence.properties.
I will wait till we come to an agreement before applying your patch.
Regards.
From: Francesco Chicchiriccò [ilgro...@apache.org]
Sent: 06 December 2013 16:21
To: dev@syncope.apache.org
Subject: Re: BasicDataSource usage in persistence.xml
On 06/12/2013 16:17, Guido Wimmel wrote:
Hi,
I wouldn't keep Oliver from providing a patch wrt. his original request,
if he'd like to ;-)
Though if not, I can possibly also provide something - maybe next week.
I'm only unsure about which of the connection pool settings exactly should
be externalized into properties,
I'd say _any_ available property.
and about the isolation level setting (maybe one
could make this configurable as well, with default READ_COMMITTED?).
+1
For whoever will take care of this: please
(1) consider *all* persistence.properties found under core/
(2) include commons-dbcp 1.4 as direct dependency either in root
pom.xml (dependencyManagement/) and core/pom.xml.
Regards.
Gesendet: Freitag, 06. Dezember 2013 um 15:38 Uhr
Von: Oliver Wulff owu...@talend.com
An: dev@syncope.apache.org dev@syncope.apache.org
Betreff: RE: BasicDataSource usage in persistence.xml
Will do ;-)
Cheers
Oli
Re: BasicDataSource usage in persistence.xml
On 05/12/2013 21:47, Oliver Wulff wrote:
Hi there
Hi Oliver,
Wouldn't it make sense to use a BasicDataSource instead of
DriverManagerDataSource as it is also recommended from Spring:
http://docs.spring.io/spring/docs/current/spring-framework-reference/html/jdbc.html#jdbc-connections
Short answer: Yes, why not?
Long answer follows.
The localDataSource bean in persistenceContext.xml is there for
providing a DataSource for non-production usage: unit and integration
tests, various development profiles [1], embedded mode [2] and
standalone distribution [3].
As you can see from syncopeContext.xml, things are arranged so that at
first a JNDI lookup for a proper DataSource is performed: this becomes
of fundamental importance in production environments, as we suggest [4].
Moreover, usage of BasicDataSource implies commons-dbcp dependency,
which is currently indirectly pulled in by Activiti
(org.activiti:activiti-spring, exactly).
Hence, I am +-0 for this change.
Instead of this:
bean id=localDataSource
class=org.springframework.jdbc.datasource.IsolationLevelDataSourceAdapter
property name=targetDataSource
bean
class=org.springframework.jdbc.datasource.DriverManagerDataSource
property name=driverClassName value=${jpa.driverClassName}/
property name=url value=${jpa.url}/
property name=username value=${jpa.username}/
property name=password value=${jpa.password}/
/bean
/property
property name=isolationLevelName value=ISOLATION_READ_COMMITTED/
/bean
we can configure this bean:
bean id=localDataSource
class=org.springframework.jdbc.datasource.IsolationLevelDataSourceAdapter
property name=targetDataSource
bean class=org.apache.commons.dbcp.BasicDataSource
destroy-method=close
property name=driverClassName value=${jpa.driverClassName}/
property name=url value=${jpa.url}/
property name=username value=${jpa.username}/
property name=password value=${jpa.password}/
/bean
/property
property name=isolationLevelName value=ISOLATION_READ_COMMITTED/
/bean
If you like such change, please file an issue and attach a patch there.
Regards.
[1] http://syncope.apache.org/building.html#More_build_profiles
[2]
https://cwiki.apache.org/confluence/display/SYNCOPE/Run+Syncope+in+embedded+mode
[3]
https://cwiki.apache.org/confluence/display/SYNCOPE/Run+Syncope+standalone+distribution
[4]
https://cwiki.apache.org/confluence/display/SYNCOPE/Run+Syncope+in+real+environments#RunSyncopeinrealenvironments-Usedatasource
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: [Proposal] An Apache Camel Integratation Proposal
Hey Hadrian and Giacomo, how things are proceeding? Are you facing some weird issues? Are you close to the target? Please keep us informed about your progresses :-) Regards. On 21/11/2013 08:37, Francesco Chicchiriccò wrote: On 20/11/2013 20:12, Hadrian Zbarcea wrote: I saw the proposal on user@camel and it sounds great. I see potential fringe benefits for the Camel project as well and volunteer to help out. Great to hear! I think I've found you on GitHub: if you agree, I'd add you as committer to https://github.com/Tirasa/SyncopeCamel I can provide some (more) guidance to Syncope internals, if needed. Summarizing: Giacomo, Hadrian (and anyone else interested) will be building a PoC - based on referenced proposal - on the above mentioned GitHub repository. This mailing list will be used for any related discussion (if you agree, I will enable the mail notification from GitHub to dev@). Once done, we will start discussing whether to a start a complete implementation (somewhere in the official Syncope SVN) based on PoC results. Do you (or anyone else here at dev@) see any problem with this working model? I am proposing this way (instead of a bare dedicate branch on SVN) mainly because Giacomo is not committer (for Hadrian, being an ASF member, there would be no issue). WDYT (especially fellow PMC members)? Regards. On 11/20/2013 11:25 AM, Francesco Chicchiriccò wrote: Hi all, in order to be able to freely experiment with this proposal, I've created an almost empty repository at GitHub https://github.com/Tirasa/SyncopeCamel where Giacomo will be soon push a simple overlay project, based on Syncope 1.2.0-SNAPSHOT. The idea is to override there some Syncope components (UserController, RoleController, ...) and introduce the ProvisioningManager - being still able to successfully run the relevant integration tests. Once we've get a working PoC there, we could start discussing whether to perform a full implementation here, and also the pmost suitable way to accept Giacomo's contribution. WDYT? Regards. On 20/11/2013 15:24, Giacomo Lamonaco wrote: Thanks for your reply! I really appreciate your interest. I'm planning to release a POC in the next months, before the end of February, because i can work on it only two days for week. I will keep you updated in the next weeks. Best Regards. - Messaggio originale - Da: Colm O hEigeartaigh cohei...@apache.org A: dev@syncope.apache.org Inviato: Mercoledì, 20 novembre 2013 14:52:00 Oggetto: Re: [Proposal] An Apache Camel Integration Proposal It looks pretty cool! It's great to see the further integration of Syncope with other Apache projects (e.g. CXF). What sort of time frame do you envisage for this task + for what version of Syncope - 1.2/1.3? Colm. On Wed, Nov 20, 2013 at 11:25 AM, giacomolm giacomo.lamon...@tirasa.netwrote: I forgot the most important part .. what do you think ? giacomolm wrote Hi, Apache Syncope is a great solution for Identity Management. In this month I analyzed some use cases that led me to reflect about the flexibility of provisioning process to adapt to various (and sometimes very cumbersome) deployment scenarios. The questions is: How well Syncope orchestrates the provisioning? The problem is that Syncope lacks of a provisioning manager: this component could allow an easy and fully customizable definition of provisioning control logic. My proposal [1] consists in a redefinition of the (user and role) controller concept, through the Apache Camel framework. Why this framework? I think that Camel fits the need of easy control logic definition. Moreover Camel supports a wide range of external components: it means that it can be easily integrated with existing frameworks, like Activiti. [1] http://www.slideshare.net/giacomolm/camel-proposaltirasa -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: BasicDataSource usage in persistence.xml
On 06/12/2013 12:49, Guido Wimmel wrote:
Hi Oliver,
FYI: we use such a setup (with dbcp.BasicDataSource) in our project, thus
avoiding the need to
configure a data source in the container. This works fine; also with our own
unit/integration tests.
We also used the standard MySQL isolation level (REPEATABLE_READ), as we had
problems with our standard
MySQL configuration related to Binary Logs (InnoDB is limited to row-logging
when transaction isolation level
is READ_COMMITTED or READ_UNCOMMITTED). This also works fine, but probably the
explicit setting of
READ_COMMITTED as a transaction level was chosen on purpose.
We externalized some more properties of BasicDataSource (testOnBorrow,
testOnReturn, removeAbandoned,
initialSize, maxActive, minIdle, removeAbandoned,
timeBetweenEvictionRunsMillis, minEvictableIdleTimeMillis,
validationQuery). IMO, at least the size parameters (initialSize, maxActive,
minIdle) and the validation query
(which can be database specific) should be configurable via properties.
BasicDataSource should also probably be a direct
Maven dependency then.
I'd be +1 for this change, as it would spare us the need of overwriting
persistenceContext.xml ;-)
Well, what are you still waiting for providing a patch, then? ;-)
Von: Francesco Chicchiriccò ilgro...@apache.org
Hi there
Hi Oliver,
Wouldn't it make sense to use a BasicDataSource instead of
DriverManagerDataSource as it is also recommended from Spring:
http://docs.spring.io/spring/docs/current/spring-framework-reference/html/jdbc.html#jdbc-connections
Short answer: Yes, why not?
Long answer follows.
The localDataSource bean in persistenceContext.xml is there for
providing a DataSource for non-production usage: unit and integration
tests, various development profiles [1], embedded mode [2] and
standalone distribution [3].
As you can see from syncopeContext.xml, things are arranged so that at
first a JNDI lookup for a proper DataSource is performed: this becomes
of fundamental importance in production environments, as we suggest [4].
Moreover, usage of BasicDataSource implies commons-dbcp dependency,
which is currently indirectly pulled in by Activiti
(org.activiti:activiti-spring, exactly).
Hence, I am +-0 for this change.
Instead of this:
bean id=localDataSource
class=org.springframework.jdbc.datasource.IsolationLevelDataSourceAdapter
property name=targetDataSource
bean class=org.springframework.jdbc.datasource.DriverManagerDataSource
property name=driverClassName value=${jpa.driverClassName}/
property name=url value=${jpa.url}/
property name=username value=${jpa.username}/
property name=password value=${jpa.password}/
/bean
/property
property name=isolationLevelName value=ISOLATION_READ_COMMITTED/
/bean
we can configure this bean:
bean id=localDataSource
class=org.springframework.jdbc.datasource.IsolationLevelDataSourceAdapter
property name=targetDataSource
bean class=org.apache.commons.dbcp.BasicDataSource
destroy-method=close
property name=driverClassName value=${jpa.driverClassName}/
property name=url value=${jpa.url}/
property name=username value=${jpa.username}/
property name=password value=${jpa.password}/
/bean
/property
property name=isolationLevelName value=ISOLATION_READ_COMMITTED/
/bean
If you like such change, please file an issue and attach a patch there.
Regards.
[1] http://syncope.apache.org/building.html#More_build_profiles
[2]
https://cwiki.apache.org/confluence/display/SYNCOPE/Run+Syncope+in+embedded+mode
[3]
https://cwiki.apache.org/confluence/display/SYNCOPE/Run+Syncope+standalone+distribution
[4]
https://cwiki.apache.org/confluence/display/SYNCOPE/Run+Syncope+in+real+environments#RunSyncopeinrealenvironments-Usedatasource
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: Syncope client 1.2.0 vs 1.1.x
On 04/12/2013 09:54, Nicola Baiocco wrote: Hi Francesco, As described in https://cwiki.apache.org/confluence/display/SYNCOPE/REST+API+upgrade in 1.1.x there are two REST interfaces an old one (Spring based) under /rest and a new one (CXF based) under /cxf, meanwhile in Syncope 1.2.0 there's only one implementation under /rest ( as mentioned here: http://blog.tirasa.net/blogs/index.php/ilgrosso/java-rest-client-library-for), is correct? Is /cxf provisional only for 1.1.x versions? Hi, you are right: 1.1.X: /rest (Spring MVC) and /cxf (CXF) 1.2.X: /rest (CXF) This will be of course mentioned in the migration guide to 1.2.X [1], currently empty. Regards. [1] https://cwiki.apache.org/confluence/display/SYNCOPE/Upgrade+from+1.1.X+to+1.2.X -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [DISCUSS] JavaFX or Swing to Apache Syncope installer GUI
On 02/12/2013 10:37, Massimiliano Perrone wrote: Hi dev, I would like to close this issue [1]. IMO the only two possible way are: 1) Swing; 2) JavaFX. I found several debate about the topic JavaFX vs Swing and the better answer on it are [2] [3]. In summary: *) Java 6 will not run JavaFX 2 out of the box. *) From OpenJDK website: The project intends to file a JSR in the Java SE 9 timeframe and hopes to eventually be part of the JDK proper. *) JavaFX 2 offers good integration with Java Webstart So, I would have liked to use JavaFX but I think that the right choice is to use Swing. Any other suggestion? Hi Max, generally speaking, I must agree with you: JavaFX 2 could be nice, but is not the ideal solution either for not being natively supported by Java 6 and possibly for other weird license issues that can come out from Oracle. Why don't you give a chance to IzPack [4]? It seems to be widely used, and has a good license (AL 2.0). Regards. [1] https://issues.apache.org/jira/browse/SYNCOPE-143 [2] http://stackoverflow.com/questions/1318645/javafx-or-swing [3] http://stackoverflow.com/questions/13696061/will-java-6-latest-run-javafx-2-out-of-the-bo [4] http://izpack.org/ -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Roadmap reorganization
On 28/11/2013 14:31, Massimiliano Perrone wrote: On 11/28/2013 02:17 PM, Francesco Chicchiriccò wrote: Hi all, while the release of maintenance version 1.1.5 is ongoing, I am realizing that the set additions currently scheduled for 1.2.0 [1] is probably too large. A consistent number of new things has already been implemented in 1.2.0 (mainly related to RESTful cleanup + various upgrades and enhancements) and, if you take a look at what is missing [2], you will see some sparse items, including the most noticeable SYNCOPE-119 (Realm-based authorization) which actually hides a large set of activities. This made me think that 1.2.0 will be ready for Q1 2013, i.e. almost a year after 1.1.0 - which is probably too long. Other considerations: * SYNCOPE-300 (and SYNCOPE-349 by consequence) could fit better in 1.2.0 due to its REST characteristics * 1.2.0 currently depends on CXF 3.0.0 and LOG4J2 snapshots * SYNCOPE-152 depends on Directory's eSCIMo - which still has to get its first release Hence my proposal: 1. move SYNCOPE-300 and SYNCOPE-349 to 1.2.0 Why not in 1.3.0? As said above, SYNCOPE-300 is again related to the RESTful interface, and since this seems to be the major theme of 1.2.0... 2. create new release 1.3.0 Virtuoso +1 3. move SYNCOPE-119 to 1.3.0 +1 4. keep working on 1.2.0 until CXF and LOG4J2 publish their stable releases, then move any residual issue from 1.2.0 to 1.3.0. +1 WDYT? [1] https://cwiki.apache.org/confluence/display/SYNCOPE/Roadmap#Roadmap-1.2.0%28Intermezzo%29 [2] https://issues.apache.org/jira/issues/?jql=project+%3D+SYNCOPE+AND+fixVersion+%3D+%221.2.0%22+AND+status+%3D+Open+ORDER+BY+priority+DESC -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: 1.1.5 release?
On 26/11/2013 21:02, Oliver Wulff wrote: Hi there Is there a plan to release 1.1.5 soon? Hi Oliver, currently there is only a single issue left for 1.1.5 (SYNCOPE-442): AFAIK, Fabio is currently working on it so, as soon as he is able to resolve it, I'd think we can start the release process. Regards. -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[Tirasa/SyncopeCamel] d653f0: Fixing travis.yml
Branch: refs/heads/master Home: https://github.com/Tirasa/SyncopeCamel Commit: d653f0945bacb75419f86f97809c85e4af876006 https://github.com/Tirasa/SyncopeCamel/commit/d653f0945bacb75419f86f97809c85e4af876006 Author: Francesco Chicchiriccò ilgro...@apache.org Date: 2013-11-21 (Thu, 21 Nov 2013) Changed paths: M .travis.yml Log Message: --- Fixing travis.yml
Re: [Proposal] An Apache Camel Integratation Proposal
Hi all, in order to be able to freely experiment with this proposal, I've created an almost empty repository at GitHub https://github.com/Tirasa/SyncopeCamel where Giacomo will be soon push a simple overlay project, based on Syncope 1.2.0-SNAPSHOT. The idea is to override there some Syncope components (UserController, RoleController, ...) and introduce the ProvisioningManager - being still able to successfully run the relevant integration tests. Once we've get a working PoC there, we could start discussing whether to perform a full implementation here, and also the pmost suitable way to accept Giacomo's contribution. WDYT? Regards. On 20/11/2013 15:24, Giacomo Lamonaco wrote: Thanks for your reply! I really appreciate your interest. I'm planning to release a POC in the next months, before the end of February, because i can work on it only two days for week. I will keep you updated in the next weeks. Best Regards. - Messaggio originale - Da: Colm O hEigeartaigh cohei...@apache.org A: dev@syncope.apache.org Inviato: Mercoledì, 20 novembre 2013 14:52:00 Oggetto: Re: [Proposal] An Apache Camel Integration Proposal It looks pretty cool! It's great to see the further integration of Syncope with other Apache projects (e.g. CXF). What sort of time frame do you envisage for this task + for what version of Syncope - 1.2/1.3? Colm. On Wed, Nov 20, 2013 at 11:25 AM, giacomolm giacomo.lamon...@tirasa.netwrote: I forgot the most important part .. what do you think ? giacomolm wrote Hi, Apache Syncope is a great solution for Identity Management. In this month I analyzed some use cases that led me to reflect about the flexibility of provisioning process to adapt to various (and sometimes very cumbersome) deployment scenarios. The questions is: How well Syncope orchestrates the provisioning? The problem is that Syncope lacks of a provisioning manager: this component could allow an easy and fully customizable definition of provisioning control logic. My proposal [1] consists in a redefinition of the (user and role) controller concept, through the Apache Camel framework. Why this framework? I think that Camel fits the need of easy control logic definition. Moreover Camel supports a wide range of external components: it means that it can be easily integrated with existing frameworks, like Activiti. [1] http://www.slideshare.net/giacomolm/camel-proposaltirasa -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [Proposal] An Apache Camel Integratation Proposal
On 20/11/2013 20:12, Hadrian Zbarcea wrote: I saw the proposal on user@camel and it sounds great. I see potential fringe benefits for the Camel project as well and volunteer to help out. Great to hear! I think I've found you on GitHub: if you agree, I'd add you as committer to https://github.com/Tirasa/SyncopeCamel I can provide some (more) guidance to Syncope internals, if needed. Summarizing: Giacomo, Hadrian (and anyone else interested) will be building a PoC - based on referenced proposal - on the above mentioned GitHub repository. This mailing list will be used for any related discussion (if you agree, I will enable the mail notification from GitHub to dev@). Once done, we will start discussing whether to a start a complete implementation (somewhere in the official Syncope SVN) based on PoC results. Do you (or anyone else here at dev@) see any problem with this working model? I am proposing this way (instead of a bare dedicate branch on SVN) mainly because Giacomo is not committer (for Hadrian, being an ASF member, there would be no issue). WDYT (especially fellow PMC members)? Regards. On 11/20/2013 11:25 AM, Francesco Chicchiriccò wrote: Hi all, in order to be able to freely experiment with this proposal, I've created an almost empty repository at GitHub https://github.com/Tirasa/SyncopeCamel where Giacomo will be soon push a simple overlay project, based on Syncope 1.2.0-SNAPSHOT. The idea is to override there some Syncope components (UserController, RoleController, ...) and introduce the ProvisioningManager - being still able to successfully run the relevant integration tests. Once we've get a working PoC there, we could start discussing whether to perform a full implementation here, and also the pmost suitable way to accept Giacomo's contribution. WDYT? Regards. On 20/11/2013 15:24, Giacomo Lamonaco wrote: Thanks for your reply! I really appreciate your interest. I'm planning to release a POC in the next months, before the end of February, because i can work on it only two days for week. I will keep you updated in the next weeks. Best Regards. - Messaggio originale - Da: Colm O hEigeartaigh cohei...@apache.org A: dev@syncope.apache.org Inviato: Mercoledì, 20 novembre 2013 14:52:00 Oggetto: Re: [Proposal] An Apache Camel Integration Proposal It looks pretty cool! It's great to see the further integration of Syncope with other Apache projects (e.g. CXF). What sort of time frame do you envisage for this task + for what version of Syncope - 1.2/1.3? Colm. On Wed, Nov 20, 2013 at 11:25 AM, giacomolm giacomo.lamon...@tirasa.netwrote: I forgot the most important part .. what do you think ? giacomolm wrote Hi, Apache Syncope is a great solution for Identity Management. In this month I analyzed some use cases that led me to reflect about the flexibility of provisioning process to adapt to various (and sometimes very cumbersome) deployment scenarios. The questions is: How well Syncope orchestrates the provisioning? The problem is that Syncope lacks of a provisioning manager: this component could allow an easy and fully customizable definition of provisioning control logic. My proposal [1] consists in a redefinition of the (user and role) controller concept, through the Apache Camel framework. Why this framework? I think that Camel fits the need of easy control logic definition. Moreover Camel supports a wide range of external components: it means that it can be easily integrated with existing frameworks, like Activiti. [1] http://www.slideshare.net/giacomolm/camel-proposaltirasa -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: Scheduled identity task
On 18/11/2013 16:09, Timo Hatakka wrote: Hi, do you have any plans to implement a feature which would make it possible to force user recalculation in a given point in time. For example employee role would be taken away just after job contract has finished. We try to implement everything by event based processing and this feature is needed for starting or terminating time based things which do not have own event. Something like deferred task and deferred task scanner in another (past) product. If not, any good ideas how to implement the functionality? A quite simple but not so pretty idea is to include a timestamp attribute to user and export this to DB table and then do syncing by simulating events by custom scripted sql adapted. Adapter's sync method should give only those lines which has timestamp which is newer than timestamp which was processed in previous run but which are not in the future. Of course we need a lot of logic to implement role set evaluation but it is another question. I suppose it can be done at least in activiti workflow. Hi, there is no currently no support nor plans for having a sort of time machine (if I've got you correctly), e.g. database versioning. You might, however, empower some other features to (partially) reach your goals: 1. Scheduled tasks [1], e.g. classes whose execution can be scheduled for checking a given condition and, when matching, perform some pre-defined logic 2. Audit: with latest improvements being developed as part of SYNCOPE-422 (that will be delivered as part of Syncope 1.1.5), you will be able to save in the audit tables some important values upon execution of almost any available operation; then you will need to develop something for fetching such data and use it for your own purpose. HTH Regards. [1] https://cwiki.apache.org/confluence/display/SYNCOPE/ScheduledTaskJobClass -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: Stacktrace in logging on a 404.
On 18/11/2013 18:04, Jesse van Bekkum wrote: Hi We have connected another IDM system to syncope. Hi, I'm curious: which system is this another IDM? When provisioning a user this system first checks if a user already exists (GET by username) and then sends a create or update. When the get on the user fails, syncope returns a 404, but it also writes a log message on error level. This fills the whole log with stack traces for a situation that is not really exceptional. This increases the risk that real errors are missed, and decreases performance. Wouldn't it be better to write this error to a much lower level, or to not throw an exception at all? Attempting to read a non-existing user is actually an error; moreover, the returning HTTP status is consequence of throwing a NotFoundException from source code (see UserDataBinder#getUserFromId [1]) that is then catch by syncopeClientError.jsp (Spring MVC) or RestServiceExceptionMapper (CXF) and transformed into 404. Or if that is not possible, to add a clean way to check for the existence of a user? Oh yes. just search for a user with that username (or id) and check that the matching list is empty. HTH Regards. [1] https://svn.apache.org/repos/asf/syncope/branches/1_1_X/core/src/main/java/org/apache/syncope/core/rest/data/UserDataBinder.java -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[DISCUSS] Remove Jenkins integration with JIRA
Hi all, recently we've got back the feature of generating JIRA comments from SVN commits, disabled a while ago as you might remember because of some malfunctioning of that plugin. At that time we requested to enable the Jenkins integration with JIRA in order to have some automatic mechanism to bind commits (mentioned by Jenkins builds) to JIRA issues. Nowadays this is no more necessary; moreover, Jenkins often fails for various reasons - most times it is just some network issue while deploying artifacts to Nexus - but we end up with some ugly FAILURE comments on our JIRA issues. Hence my proposal: request INFRA to disable the Jenkins2JIRA integration and manually handle Jenkins failures - as we are doing currently. I remember that, driven by our github mirror, we also have Travis [1] taking care of CI. WDYT? [1] https://travis-ci.org/apache/syncope -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Fwd: [jira] [Created] (INFRA-6993) Enable svn2Jira (or git2Jira if not possible) for Syncope
Hi all, FYI, I've requested our infra team to re-enable the subversion / JIRA integration we used to have, that was disable at some point due to internal problems. Regards. Original Message Subject: [jira] [Created] (INFRA-6993) Enable svn2Jira (or git2Jira if not possible) for Syncope Date: Tue, 12 Nov 2013 07:49:17 + (UTC) From: Francesco Chicchiriccò (JIRA) j...@apache.org To: ilgro...@apache.org Message Title Francesco Chicchiriccò https://issues.apache.org/jira/secure/ViewProfile.jspa?name=ilgrosso *created* an issue Infrastructure https://issues.apache.org/jira/browse/INFRA / Task https://issues.apache.org/jira/browse/INFRA-6993 INFRA-6993 https://issues.apache.org/jira/browse/INFRA-6993 Enable svn2Jira (or git2Jira if not possible) for Syncope https://issues.apache.org/jira/browse/INFRA-6993 Issue Type: Task Task Assignee: Unassigned Components: Jenkins, JIRA, Subversion Created:12/Nov/13 07:48 Priority: Major Major Reporter: Francesco Chicchiriccò https://issues.apache.org/jira/secure/ViewProfile.jspa?name=ilgrosso Please re-enable for Syncope the feature of adding comments to JIRA issues upon SVN commits: we used to have it until it was disabled for some malfunctioning; if still generating problems for SVN, please enable the same feature for our git mirror. https://svn.apache.org/repos/asf/syncope/ git://git.apache.org/syncope.git Thanks for your support. Add Comment https://issues.apache.org/jira/browse/INFRA-6993#add-comment Add Comment https://issues.apache.org/jira/browse/INFRA-6993#add-comment This message was sent by Atlassian JIRA (v6.1#6144-sha1:2e50328) Atlassian logo
Re: [DISCUSS] RESTful best practices
Hi,
my recent commit [3] for SYNCOPE-425 should have applied all applicable
RESTful best practices plus most of what discussed below: see issue
comments for more details.
Please double check the changes I've made to services and let me know if
you still found any anomaly.
Regards.
On 16/10/2013 10:22, Francesco Chicchiriccò wrote:
Hi,
replying to this old thread, trying to catch some interest about this
topic.
I'd like to create an issue for improving the current UserService on
trunk [2] with the following modifications:
1. add a couple of 'resolve' methods which allows to obtain an user id
from its username and vice versa:
1a. GET /{userId}/username
1b. GET /{username}/userId
2. remove any {username} related method
3. add PUT /status/{userId} with UserStatusMod argument, where
UserStatusMod is a new transfer object encapsulating any status change
request (possibly not limited to current 'activate', 'suspend',
'reactivate').
4. remove 'activate', 'suspend', 'reactivate' methods
5. (side change) remove UserTO#setStatus in order to avoid confusion
on this topic (status cannot be directly set when creating or updating
user, it's up to workflow definition); internal methods will use
reflection for this purpose
WDYT?
Regards.
On 07/08/2013 09:24, Francesco Chicchiriccò wrote:
Hi all,
[1] reports that User Service Interface in Version 1.1.0 is still
not applying some major RESTful best practices. Therefore refactoring
for release = 1.2.0 is most likely.
Does anyone remember what is still missing? Shall we restart such
discussion?
Regards.
[1]
https://cwiki.apache.org/confluence/display/SYNCOPE/REST+API+upgrade#RESTAPIupgrade-UserService
[2]
https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/services/UserService.java
[3] http://svn.apache.org/r1537047
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: [DISCUSS] RESTful services enhancements
On 30/10/2013 16:08, Sergey Beryozkin wrote: Hi Francesco On 30/10/13 12:53, Francesco Chicchiriccò wrote: Hi all, as you might have seen, I've just opened SYNCOPE-429 and SYNCOPE-430 with a couple of proposal to enhance our RESTful services, with support for ETag, If*, and Prefer HTTP headers, at least for users, roles and resources. The only issue is that JAX-RS has no explicit support for Prefer so I guess it will have to be done with some custom code Hi Sergey, do you mean that there is a way to automagically handle ETag with JAX-RS or are you referring to - say - methods like ResponseBuilder.tag()? If the latter, this would only mean usage of ResponseBuilder.header() / WebClient.header() instead of dedicated methods, correct? Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Fwd: [CONF] Apache Syncope Roadmap
Hi all, as you might have noticed, I have reviewed some issues' fix version and consequently our roadmap. If you have any question or would like to propose any further change, let's discuss here. Regards. Original Message Subject:[CONF] Apache Syncope Roadmap Date: Thu, 24 Oct 2013 07:58:00 + (UTC) From: Francesco Chicchiricco (Confluence) conflue...@apache.org Reply-To: dev@syncope.apache.org To: comm...@syncope.apache.org Roadmap https://cwiki.apache.org/confluence/display/SYNCOPE/Roadmap Page *edited* by Francesco Chicchiricco https://cwiki.apache.org/confluence/display/%7Eilgrosso Changes (15) ... h2. 1.2.0 (Intermezzo) Release date: Q3 2013 Release date: Q1 2014 h3. Issues ... # [[SYNCOPE-150|https://issues.apache.org/jira/browse/SYNCOPE-150]] Rich client library # [[SYNCOPE-151|https://issues.apache.org/jira/browse/SYNCOPE-151]] Document RESTful services # [[SYNCOPE-145|https://issues.apache.org/jira/browse/SYNCOPE-145]] Configurable user request approval # [[SYNCOPE-152|https://issues.apache.org/jira/browse/SYNCOPE-152]] Support SCIM REST API h2. 1.3.0 2.0.0 (Jazz) Release date: Q4 20134 h3. Issues _See updated list on project's [JIRA|https://issues.apache.org/jira/browse/SYNCOPE/fixforversion/123225068#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel]._ # [[SYNCOPE-139|https://issues.apache.org/jira/browse/SYNCOPE-139]] Support OpenICF connector bundles ... # [[SYNCOPE-142|https://issues.apache.org/jira/browse/SYNCOPE-142]] Asynchronous propagation # [[SYNCOPE-143|https://issues.apache.org/jira/browse/SYNCOPE-143]] GUI installer # [[SYNCOPE-145|https://issues.apache.org/jira/browse/SYNCOPE-145]] Configurable user request approval # [[SYNCOPE-300|https://issues.apache.org/jira/browse/SYNCOPE-300]] Supporting Feed Item Query Language (FIQL) h2. 2.0.0 (Virtuoso) Release date: Q2 2014 h3. Issues _See updated list on project's [JIRA|https://issues.apache.org/jira/browse/SYNCOPE/fixforversion/12322508#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel]._ # [[SYNCOPE-149|https://issues.apache.org/jira/browse/SYNCOPE-149]] Easier and cleaner way to override REST methods # [[SYNCOPE-152|https://issues.apache.org/jira/browse/SYNCOPE-152]] Support SCIM REST API # [[SYNCOPE-155|https://issues.apache.org/jira/browse/SYNCOPE-155]] Better way to override console components # [[SYNCOPE-156|https://issues.apache.org/jira/browse/SYNCOPE-156]] New admin UI h2. 2.1.0 (Rapsodia) Release date: Q3 2014 h3. Issues _See updated list on project's [JIRA|https://issues.apache.org/jira/browse/SYNCOPE/fixforversion/12322509#selectedTab=com.atlassian.jira.plugin.system.project:version-issues-panel]._ # [[SYNCOPE-157|https://issues.apache.org/jira/browse/SYNCOPE-157]] Upgrade tools # [[SYNCOPE-158|https://issues.apache.org/jira/browse/SYNCOPE-158]] CLI admin tool # [[SYNCOPE-159|https://issues.apache.org/jira/browse/SYNCOPE-159]] Bulk operations via REST API h2. 3.0.0 (Maggiore) Release date: Q4 2014 Release date: ? h3. Issues ... h2. 4.0.0 (Notturno) Release date: Q2 2015 Release date: ? h3. Issues ... Full Content This page is a scratchpad for ongoing discussion at dev@syncope.apache.org * 1.2.0 (Intermezzo) #Roadmap-1.2.0%28Intermezzo%29 * 2.0.0 (Jazz) #Roadmap-2.0.0%28Jazz%29 * 3.0.0 (Maggiore) #Roadmap-3.0.0%28Maggiore%29 * 4.0.0 (Notturno) #Roadmap-4.0.0%28Notturno%29 1.2.0 (Intermezzo) Release date: Q1 2014 Issues /See updated list on project's JIRA https://issues.apache.org/jira/browse/SYNCOPE/fixforversion/12322505#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel./ 1. [SYNCOPE-15 https://issues.apache.org/jira/browse/SYNCOPE-15] Manage creator, lastmodifier and approvers information about each SyncopeUser bean 2. [SYNCOPE-119 https://issues.apache.org/jira/browse/SYNCOPE-119] Realm-based authorization 3. [SYNCOPE-120 https://issues.apache.org/jira/browse/SYNCOPE-120] Avoid duplication in console's authorization management 4. [SYNCOPE-129 https://issues.apache.org/jira/browse/SYNCOPE-129] Delegation 5. [SYNCOPE-131 https://issues.apache.org/jira/browse/SYNCOPE-131] Assign membership and role schemas to either all memberships / roles or only some memberships / roles 6. [SYNCOPE-132 https://issues.apache.org/jira/browse/SYNCOPE-132] Don't expose some REST list methods for anonymous 7. [SYNCOPE-133 https://issues.apache.org/jira/browse/SYNCOPE-133] Add UserRequestController.execute() that will execute the provided UserRequest and remove it on success 8. [SYNCOPE-134 https://issues.apache.org/jira/browse/SYNCOPE-134] User, role and membership properties for derived schemas 9. [SYNCOPE-123 https://issues.apache.org/jira/browse/SYNCOPE-123] Binary schema 10. [SYNCOPE-270 https://issues.apache.org/jira/browse/SYNCOPE-270] Encrypted
Re: [DISCUSS] RESTful best practices
Hi,
replying to this old thread, trying to catch some interest about this topic.
I'd like to create an issue for improving the current UserService on
trunk [2] with the following modifications:
1. add a couple of 'resolve' methods which allows to obtain an user id
from its username and vice versa:
1a. GET /{userId}/username
1b. GET /{username}/userId
2. remove any {username} related method
3. add PUT /status/{userId} with UserStatusMod argument, where
UserStatusMod is a new transfer object encapsulating any status change
request (possibly not limited to current 'activate', 'suspend',
'reactivate').
4. remove 'activate', 'suspend', 'reactivate' methods
5. (side change) remove UserTO#setStatus in order to avoid confusion on
this topic (status cannot be directly set when creating or updating
user, it's up to workflow definition); internal methods will use
reflection for this purpose
WDYT?
Regards.
On 07/08/2013 09:24, Francesco Chicchiriccò wrote:
Hi all,
[1] reports that User Service Interface in Version 1.1.0 is still not
applying some major RESTful best practices. Therefore refactoring for
release = 1.2.0 is most likely.
Does anyone remember what is still missing? Shall we restart such
discussion?
Regards.
[1]
https://cwiki.apache.org/confluence/display/SYNCOPE/REST+API+upgrade#RESTAPIupgrade-UserService
[2]
https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/services/UserService.java
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: Issue with Rest Call for VerifyPassword
On 05/10/2013 15:18, ram...@actouch.com wrote:
Hi,
Kindly help me resolve the issue in VerifyPassword Rest
call.
We are trying to use Syncope for Authentication. Trying to
integrate with the custom build application for user management. Trying
to call
rest service for verification of password.
REST API:
/rest/verifyPassword/{Username}
we are trying to pass user name as
email id username field in the UserController is getting
truncated.
Ex: username as te...@mail.com it is getting truncated as test1@mail
Kindly help us to resolve this issue. Is there any setup change is
required for this. Any configuration needs to be change or is this is a
bug.
Hi Ramesh,
an issue like yours popped in a while ago [1]: due to the way how Spring
MVC does content negotiation, you need to explicitly include the
content-type suffix in cases like yours:
/rest/verifyPassword/te...@mail.com.json?password=aPassword
Anyway, I urge to warn you that such method is deprecated and will not
be available in 1.2.X: please use Basic-Authentication and GET
/users/self to verify authentication and retrieve user object including
assigned roles (as reported by [2]).
Regards.
[1] http://markmail.org/message/hunpzbedncafp6gv
[2]
https://cwiki.apache.org/confluence/display/SYNCOPE/REST+API+upgrade#RESTAPIupgrade-UserService
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: [INFO] Integration of Syncope directly in Karaf
On 04/10/2013 10:11, Jean-Baptiste Onofré wrote: Hi Francesco, my comments inline: this sounds simply great! I guess you are working on trunk, right? Trunk, Yes. - first add a SyncopeLoginModule in Karaf in order to leverage directly Syncope natively and deeply into Karaf Very very interesting: if you need any support with this, just ask. I will ! Thanks. - provide a properties file connector in Syncope Why don't you leverage the existing CSV connector [1] for this purpose? We use it even for Syncope core integration tests. Good idea. The purpose is to mimic the PropertiesLoginModule that we have in Karaf. Thanks to that, we would be able to remove the Karaf login modules to directly leverage Syncope (of course, when the users install it). Oh, now I got it: Karaf's PropertiesLoginModule is a JAAS login module: so when you say 'a properties file connector in Syncope' you mean a JAAS login module for Karaf deferring the actual authentication to Syncope. Am I wrong? Regards. [1] https://connid.atlassian.net/wiki/display/BASE/CSV+Directory -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [INFO] Integration of Syncope directly in Karaf
On 04/10/2013 14:04, Jean-Baptiste Onofré wrote: You read in my mind Francesco ;) You are right, it's exactly what I plan to do. Cool: looking forward to see it in action, then. Regards. On 10/04/2013 02:03 PM, Francesco Chicchiriccò wrote: On 04/10/2013 10:11, Jean-Baptiste Onofré wrote: Hi Francesco, my comments inline: this sounds simply great! I guess you are working on trunk, right? Trunk, Yes. - first add a SyncopeLoginModule in Karaf in order to leverage directly Syncope natively and deeply into Karaf Very very interesting: if you need any support with this, just ask. I will ! Thanks. - provide a properties file connector in Syncope Why don't you leverage the existing CSV connector [1] for this purpose? We use it even for Syncope core integration tests. Good idea. The purpose is to mimic the PropertiesLoginModule that we have in Karaf. Thanks to that, we would be able to remove the Karaf login modules to directly leverage Syncope (of course, when the users install it). Oh, now I got it: Karaf's PropertiesLoginModule is a JAAS login module: so when you say 'a properties file connector in Syncope' you mean a JAAS login module for Karaf deferring the actual authentication to Syncope. Am I wrong? Regards. [1] https://connid.atlassian.net/wiki/display/BASE/CSV+Directory -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: OpenJPA dependency overlaps?
On 04/10/2013 16:48, Guido Wimmel wrote:
Hi,
I'm not an OpenJPA expert, but can it be the case that all OpenJPA classes needed by
Syncope that are included in openjpa-2.2.2.jar are also included in
{openjpa-kernel-2.2.2.jar, openjpa-jdbc-2.2.2.jar, openjpa-lib-2.2.2.jar,
openjpa-persistence-2.2.2.jar, openjpa-persistence-jdbc-2.2.2.jar}?
When I remove the dependency to org.apache.openjpa:openjpa in core/pom.xml, the build is still successful.
The new war file does not contain openjpa-2.2.2.jar and stax-api-1.0-2.jar
anymore. Otherwise it seems to be identical.
stax-api-1.0.2.jar is a dependency of openjpa-2.2.2.jar but also seems to be
unnecessary, as these classes seem to be included
in xml-apis-1.4.01.jar.
Removing the dependency reduces the war file size by 4 MB.
Maybe there is a relation to https://issues.apache.org/jira/browse/SYNCOPE-85 ?
If this is a valid possible improvement, I can open a JIRA issue.
Definitely yes: I cannot think of any single reason why
openjpa-2.2.2.jar is included as dependency; please go ahead.
Regards.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: [VOTE] Apache Syncope 1.1.4
On 27/09/2013 10:50, Francesco Chicchiriccò wrote: I've created a 1.1.4 release, with the following artifacts up for a vote: SVN source tag (r1526805): https://svn.apache.org/repos/asf/syncope/tags/syncope-1.1.4/ List of changes: https://svn.apache.org/repos/asf/syncope/tags/syncope-1.1.4/CHANGES Maven staging repo: https://repository.apache.org/content/repositories/orgapachesyncope-105/ Source release (checksums and signatures are available at the same location): https://repository.apache.org/content/repositories/orgapachesyncope-105/org/apache/syncope/syncope/1.1.4/syncope-1.1.4-source-release.zip Staging site: http://syncope.apache.org/1.1.4/ 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) +1 Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[RESULT][VOTE] Apache Syncope 1.1.4
Hi all, after more than 72 hours, the vote for Syncope 1.1.4 [1] *passes* with 4 PMC + 1 non-PMC votes. +1 (PMC / binding) * Fabio Martelli * Massimiliano Perrone * Colm O hEigeartaigh * Francesco Chicchiriccò +1 (non binding) * Andrea Patricelli 0 none -1 none Thanks to everyone participating. I will now copy this release to Syncope' dist directory and promote the artifacts to the central Maven repository. Best regards. [1] http://markmail.org/message/ibjfrjmxkvlo7tqz -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[VOTE] Apache Syncope 1.1.4
I've created a 1.1.4 release, with the following artifacts up for a vote: SVN source tag (r1526805): https://svn.apache.org/repos/asf/syncope/tags/syncope-1.1.4/ List of changes: https://svn.apache.org/repos/asf/syncope/tags/syncope-1.1.4/CHANGES Maven staging repo: https://repository.apache.org/content/repositories/orgapachesyncope-105/ Source release (checksums and signatures are available at the same location): https://repository.apache.org/content/repositories/orgapachesyncope-105/org/apache/syncope/syncope/1.1.4/syncope-1.1.4-source-release.zip Staging site: http://syncope.apache.org/1.1.4/ 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/
[DISCUSS] Apache Syncope 1.1.4
Discussion thread for vote on version release, with SVN source tag (r1526805). For more information on the release process, check out http://www.apache.org/dev/release.html Some of the things to check before voting are: - does mvn apache-rat:check pass on the source - can you build the contents of source release zip and SVN tag - do all of the staged jars/wars/zips contain the required LICENSE and NOTICE files - are all of the staged jars/wars/zips signed and the signature verifiable - is the signing key in the project's KEYS file and on a public server (i.e. http://www.apache.org/dist/syncope/) Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Apache Syncope 1.1.4
On 27/09/2013 14:33, Colm O hEigeartaigh wrote: +1. Hi Colm, thanks for voting; for the records, this is the [DISCUSS] thread, so can you please cast your vote on the associated [VOTE] thread http://markmail.org/message/ibjfrjmxkvlo7tqz Thanks again! Regards. On Fri, Sep 27, 2013 at 9:51 AM, Francesco Chicchiriccò ilgro...@apache.orgwrote: Discussion thread for vote on version release, with SVN source tag (r1526805). For more information on the release process, check out http://www.apache.org/dev/release.html Some of the things to check before voting are: - does mvn apache-rat:check pass on the source - can you build the contents of source release zip and SVN tag - do all of the staged jars/wars/zips contain the required LICENSE and NOTICE files - are all of the staged jars/wars/zips signed and the signature verifiable - is the signing key in the project's KEYS file and on a public server (i.e. http://www.apache.org/dist/syncope/) Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[DISCUSS] Authentication features (WAS: Release Maggiore and authentication modules)
Hi all, sorry for crossposting: let's keep this discusson on dev@, so please remove user@ from any future reply. Rgeards. On 23/09/2013 14:22, Strunk, Wolfgang wrote: Hi all, Starting a discussion thread in the developer sounds good. We have to consider that there actually will be three things to consider: -Login to Syncope (this is where Shiro could come into play) -SSO to Syncope -Provide access management features via Syncope. I would not mix things up and propose to keep discussion about the latter out of Syncope. Probably there will be customers combining Syncope with SSO products (e.g. CAS http://www.jasig.org/cas or OpenAM http://openam.forgerock.org/) , but building it in to Syncope bears the risk to lose focus. Wolfgang -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[DISCUSS] Time for 1.1.4?
Hi all, I have just noticed that 1.1.4 got 11 issues resolved [1] including some relevant fixes; moreover, there are no left open and 1.1.3 was issued a couple of months ago. Hence I was wondering: isn't this time for a new release? Any thought / objection? Regards. [1] https://issues.apache.org/jira/browse/SYNCOPE/fixforversion/12324763#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: EntityValidationInterceptor / log level of bean validation errors
On 18/09/2013 10:31, Fabio Martelli wrote: Il 10/09/2013 15:18, Francesco Chicchiriccò ha scritto: On 10/09/2013 13:27, Guido Wimmel wrote: Hi, currently, EntityValidationInterceptor logs bean validation errors with log level ERROR. I think bean validation errors can be part of normal system behaviour (e.g. a user registers itself or is registered by an admin and accidentally or unknowingly enters invalid data and then gets an error message on the UI). We configured our system to send notifications to the operations team on ERROR log events and would have to filter this one out. I'd suggest turning the log level to WARN or maybe even INFO, but it can also be that I have overlooked some use cases where ERROR would indeed be appropriate. Hum, not sure I agree: are you suggesting that a bean validation error is not an actual operational error, hence it shouldn't be logged as ERROR? I can hardly figure them out as WARN... Someone else's opinion? Maybe, WARN is better. I have to agree with Guido. Well, time brought some more wisdom to me as well: I agree with the proposed change. Regards. @Guido can you open a new issue and attach the patch? -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: How to run Syncope tests correctly
On 20/08/2013 11:33, Sergey Beryozkin wrote: Hi- On 20/08/13 10:46, Francesco Chicchiriccò wrote: On 19/08/2013 17:56, Francesco Chicchiriccò wrote: On 19/08/2013 16:20, Sergey Beryozkin wrote: Hi I'm looking into reproducing the CXF related test failures reported by Francesco and I'm struggling to get the test failing consistently. I've just seen them failing in the core module, then I went to core, tried mvn test -Dtest=SchemaTestITCase and it fails with the connection failures, next I do mvn clean install in the core, I see all tests passing. How do I get the tests failing consistently for me ? The easiest path: 1. mvn -pskipTests (from root) 2. mvn clean verify (from core subdirectory) If you want to run just a single integration test (always from core subdirectory): mvn -Pdev -Dit.test=SchemaTestITCase Forgot to mention: if instead you want to start the full integration test environment (with JPDA debug enabled) so that you can run any integration test you like from your favorite IDE, just launch (again from core subdirectory): mvn -Pdebug OK, thanks for the info above. Hum, guess this kind of information should fine some place on the website: any volunteer? Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: How to run Syncope tests correctly
On 19/08/2013 17:56, Francesco Chicchiriccò wrote: On 19/08/2013 16:20, Sergey Beryozkin wrote: Hi I'm looking into reproducing the CXF related test failures reported by Francesco and I'm struggling to get the test failing consistently. I've just seen them failing in the core module, then I went to core, tried mvn test -Dtest=SchemaTestITCase and it fails with the connection failures, next I do mvn clean install in the core, I see all tests passing. How do I get the tests failing consistently for me ? The easiest path: 1. mvn -pskipTests (from root) 2. mvn clean verify (from core subdirectory) If you want to run just a single integration test (always from core subdirectory): mvn -Pdev -Dit.test=SchemaTestITCase Forgot to mention: if instead you want to start the full integration test environment (with JPDA debug enabled) so that you can run any integration test you like from your favorite IDE, just launch (again from core subdirectory): mvn -Pdebug Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: How to run Syncope tests correctly
On 19/08/2013 16:20, Sergey Beryozkin wrote: Hi I'm looking into reproducing the CXF related test failures reported by Francesco and I'm struggling to get the test failing consistently. I've just seen them failing in the core module, then I went to core, tried mvn test -Dtest=SchemaTestITCase and it fails with the connection failures, next I do mvn clean install in the core, I see all tests passing. How do I get the tests failing consistently for me ? The easiest path: 1. mvn -pskipTests (from root) 2. mvn clean verify (from core subdirectory) If you want to run just a single integration test (always from core subdirectory): mvn -Pdev -Dit.test=SchemaTestITCase Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: javax.ws.rs-api version?
On 08/08/2013 14:47, Sergey Beryozkin wrote: Hi On 07/08/13 08:22, Francesco Chicchiriccò wrote: Hi all, currently javax.ws.rs-api version is set to 2.0-m15 either on trunk and 1_1_X, while 2.0 is available. When trying to update such dependency, a lot of compile errors are reported, mainly due to some missing classes: any clue about what should be done? CXF 3.0.0 (due in a couple of months) has a 2.0 final API dep, there will be a minor migration effort when moving to it, I can help if needed, CXF 2.7.x actually depends on 2.0-m10, and most of the core features/API is the same between it and the final one Thanks Sergey, CXF 3.0.0 looks much closer than Syncope 1.2.0, so I guess this is just fine, especially including your help for migration. Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
javax.ws.rs-api version?
Hi all, currently javax.ws.rs-api version is set to 2.0-m15 either on trunk and 1_1_X, while 2.0 is available. When trying to update such dependency, a lot of compile errors are reported, mainly due to some missing classes: any clue about what should be done? Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[DISCUSS] RESTful best practices
Hi all, [1] reports that User Service Interface in Version 1.1.0 is still not applying some major RESTful best practices. Therefore refactoring for release = 1.2.0 is most likely. Does anyone remember what is still missing? Shall we restart such discussion? Regards. [1] https://cwiki.apache.org/confluence/display/SYNCOPE/REST+API+upgrade#RESTAPIupgrade-UserService -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: Add index on task.executed?
Hi, in our Syncope installation (1.1.3 on Tomcat/MySQL) we observed long execution times (1s) for TaskDAO.findToExec(), which is called periodically from NotificationJob to determine which notifications should be sent. According to our analysis, this is due to the fact that TaskDAO.findToExec() performs a full scan on all entries of the task table with DTYPE=NotificationTask (which could be a large number as all executed tasks are kept), although only very few tasks are selected (those with executed=0). Creating an index on task.executed solved this problem. Would it be a good idea to add such an index to the indexes added by default to the database (via indexes.xml)? +1 Would you mind to file an issue on JIRA and provide a patch against the branch 1_1_X? Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[DISCUSS] Replace logback with log4j 2
Hi all, I have recently read a stunning post from Christian Grobmeier [1] and I was thinking why not to switch the trunk (1.2.0) from logback to log4j 2 (with new AsyncLoggers, of course!). I was also thinking to keep the SLF4J layer, so that code changes would be minimal. Besides performance benefit, we will also increase our non-ASF dependency level. WDYT? [1] http://www.grobmeier.de/log4j-2-performance-close-to-insane-20072013.html#.Ue0KLRe9hyc -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Replace logback with log4j 2
On 22/07/2013 14:29, Oliver Wulff wrote: I assume there are no dependencies within the code which would allow the users to still give the option to use logback? There are also direct references in the source code to Logback internal classes (the LoggerController, for example) since the SLF4J APIs do not expose methods for programmatically changing appender's level. I don't see very meaningful for end users to keep with logback, Syncope is not a general purpose framework for which it can make sense to choice that. log4j 2 is still in beta. Do we know when it should be released? Soon, as far as they claim (they've already reach beta 8!), and anyway before than 1.2.0 sees the light. Regards. From: cschneider...@gmail.com [cschneider...@gmail.com] on behalf of Christian Schneider [ch...@die-schneider.net] Sent: 22 July 2013 13:30 To: dev@syncope.apache.org Subject: Re: [DISCUSS] Replace logback with log4j 2 +1 For switching to log4j. I would also keep the slf4j layer. This minimizes direct dependencies on the log framework and also works great in OSGi. Christian 2013/7/22 Francesco Chicchiriccò ilgro...@apache.org Hi all, I have recently read a stunning post from Christian Grobmeier [1] and I was thinking why not to switch the trunk (1.2.0) from logback to log4j 2 (with new AsyncLoggers, of course!). I was also thinking to keep the SLF4J layer, so that code changes would be minimal. Besides performance benefit, we will also increase our non-ASF dependency level. WDYT? [1] http://www.grobmeier.de/log4j-**2-performance-close-to-insane-** 20072013.html#.Ue0KLRe9hychttp://www.grobmeier.de/log4j-2-performance-close-to-insane-20072013.html#.Ue0KLRe9hyc -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[NOTICE] Huge commit coming on trunk
Hi all, I had a couple of days to play with the trunk and I have took the chance to upgrade some legacy dependencies: 1. commons-lang 2.6 - commons-lang3 3.1 2. jackson 1.9.12 - 2.2.2 (for this I had to upgrade CXF to 2.7.6-SNAPSHOT as well, but 2.7.6 should be on its way, so no problems) Unfortunately Activiti 5.13 is still pulling in the legacy versions of these dependencies, but I am trying to manage this with Activiti team [1] (if you have an account there, please log in an vote, it will help grabbing their attention). Besides this, I have also started some experiments with JSON and CXF that lead to some interaction with Sergey on the CXF user list [2]. As you can imagine, I have changed a lot of files; however all tests (including -Pjaxrs) are still working fine. I was wondering if someone else has some pending changes that would be affected by my commit, hence this mail. If there are no objections in the meanwhile, I will commit my changes in the afternoon. Regards. [1] http://jira.codehaus.org/browse/ACT-1747 [2] http://cxf.547215.n5.nabble.com/Cannot-deserialize-JSON-via-JacksonJaxbJsonProvider-that-works-via-Jackson-s-ObjectMapperm-anyway-td5731029.html -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [NOTICE] Huge commit coming on trunk
Done [3]. At the moment: 1. all Spring MVC tests pass 2. all CXF tests pass with application/xml 3. CXF tests with application/json: Tests run: 222, Failures: 0, Errors: 53, Skipped: 1 I am confident that most - while not all - JSON failures will be solved by Sergey's fix on CXF [2], when available. Regards. On 18/07/2013 09:38, Francesco Chicchiriccò wrote: Hi all, I had a couple of days to play with the trunk and I have took the chance to upgrade some legacy dependencies: 1. commons-lang 2.6 - commons-lang3 3.1 2. jackson 1.9.12 - 2.2.2 (for this I had to upgrade CXF to 2.7.6-SNAPSHOT as well, but 2.7.6 should be on its way, so no problems) Unfortunately Activiti 5.13 is still pulling in the legacy versions of these dependencies, but I am trying to manage this with Activiti team [1] (if you have an account there, please log in an vote, it will help grabbing their attention). Besides this, I have also started some experiments with JSON and CXF that lead to some interaction with Sergey on the CXF user list [2]. As you can imagine, I have changed a lot of files; however all tests (including -Pjaxrs) are still working fine. I was wondering if someone else has some pending changes that would be affected by my commit, hence this mail. If there are no objections in the meanwhile, I will commit my changes in the afternoon. Regards. [1] http://jira.codehaus.org/browse/ACT-1747 [2] http://cxf.547215.n5.nabble.com/Cannot-deserialize-JSON-via-JacksonJaxbJsonProvider-that-works-via-Jackson-s-ObjectMapperm-anyway-td5731029.html [3] http://svn.apache.org/r1504477 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [VOTE] Apache Syncope 1.1.3
On 12/07/2013 11:04, Francesco Chicchiriccò wrote: I've created a 1.1.3 release, with the following artifacts up for a vote: SVN source tag (r1502456): https://svn.apache.org/repos/asf/syncope/tags/syncope-1.1.3/ List of changes: https://svn.apache.org/repos/asf/syncope/tags/syncope-1.1.3/CHANGES Maven staging repo: https://repository.apache.org/content/repositories/orgapachesyncope-136/ Source release (checksums and signatures are available at the same location): https://repository.apache.org/content/repositories/orgapachesyncope-136/org/apache/syncope/syncope/1.1.3/syncope-1.1.3-source-release.zip Staging site: http://syncope.apache.org/1.1.3/ 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) +1 Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[ANN] Apache Syncope 1.1.3 released
The Apache Syncope team is pleased to announce the release of Syncope 1.1.3. Apache Syncope is an Open Source system for managing digital identities in enterprise environments, implemented in JEE technology . The release will be available within 24h from: http://syncope.apache.org/downloads.html The full change log is available here: http://s.apache.org/2L4 We welcome your help and feedback. For more information on how to report problems, and to get involved, visit the project website at http://syncope.apache.org/ The Apache Syncope Team
Re: Is there any documentation on branding?
On 23/06/2013 17:31, Gary Gardner wrote: How do you brand Syncope for your specific organization? We would need to brand Syncope's Self-Registration and other portions of Syncope. Is this possible? Is there documentation or a readme on this? Any help would be appreciated. Hi, there is no specific documentation for Syncope about this: I guess that the relevant ASF-wide documentation must be taken into account, starting (but not limited to) [1] - with practical reference to [2]. Since I am not a lawyer, however, I ask other devs to come and comment, if they know more. Anyway, if in doubt, you can directly ask the Apache Software Foundation legal staff [3]. Regards. [1] http://www.apache.org/foundation/marks/ [2] http://www.apache.org/foundation/marks/faq/ [3] http://www.apache.org/foundation/mailinglists.html#foundation-legal -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: Syncope 1.1.0 - Resource of Roles are not persisted?
On 20/06/2013 09:29, Ernst Vorsteveld wrote: Hi, In Syncope I create a Role and attach one resource. When I retrieve the Role, and choose the Resources tab, the selected resources listbox is empty. When I try to retrieve the Role with a rest call, I also get an empty resources list. Can anybody tell me if this is a problem in the 1.1.0 version? Yes, as reported by warning at [1] (this issue is [2] in particular). You can choose whether upgrade to 1.1.1 or to apply the provided workaround. Regards. [1] https://cwiki.apache.org/confluence/display/SYNCOPE/Create+a+new+Syncope+project#CreateanewSyncopeproject-Stablereleases [2] https://issues.apache.org/jira/browse/SYNCOPE-356 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Fwd: [SECURITY] Frame injection vulnerability in published Javadoc
Hi all, I am forwarding the attached e-mail here for notification: please take a look at it before continuing here. As you might see, we had only 2 problematic files ([1] and [2]) that I have already fixed and committed via [3]. Regards. [1] http://syncope.apache.org/apidocs/1.0/index.html [2] http://syncope.apache.org/apidocs/1.1/index.html [3] https://github.com/olamy/JavadocUpdaterTool Original Message Subject:[SECURITY] Frame injection vulnerability in published Javadoc Date: Thu, 20 Jun 2013 09:29:23 +0100 From: Mark Thomas ma...@apache.org Reply-To: infrastruct...@apache.org infrastruct...@apache.org To: committ...@apache.org CC: r...@apache.org Hi All, Oracle has announced [1], [2] a frame injection vulnerability in Javadoc generated by Java 5, Java 6 and Java 7 before update 22. The infrastructure team has completed a scan of our current project websites and identified over 6000 instances of vulnerable Javadoc distributed across most TLPs. The chances are the project(s) you contribute to is(are) affected. A list of projects and the number of affected Javadoc instances per project is provided at the end of this e-mail. Please take the necessary steps to fix any currently published Javadoc and to ensure that any future Javadoc published by your project does not contain the vulnerability. The announcement by Oracle includes a link to a tool that can be used to fix Javadoc without regeneration. The infrastructure team is investigating options for preventing the publication of vulnerable Javadoc. The issue is public and may be discussed freely on your project's dev list. Thanks, Mark (ASF Infra) [1] http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html [2] http://www.kb.cert.org/vuls/id/225657 Project Instances abdera.apache.org 1 accumulo.apache.org 2 activemq.apache.org 105 any23.apache.org13 archiva.apache.org 4 archive.apache.org 13 aries.apache.org7 avro.apache.org 23 axis.apache.org 5 beehive.apache.org 16 bval.apache.org 12 camel.apache.org786 cayenne.apache.org 4 chemistry.apache.org6 click.apache.org3 cocoon.apache.org 6 commons.apache.org 34 continuum.apache.org9 creadur.apache.org 19 crunch.apache.org 4 ctakes.apache.org 2 curator.apache.org 4 cxf.apache.org 6 db.apache.org 39 directory.apache.org4 empire-db.apache.org1 felix.apache.org5 flume.apache.org5 geronimo.apache.org 241 giraph.apache.org 6 gora.apache.org 3 hadoop.apache.org 21 hbase.apache.org2 hive.apache.org 4 hivemind.apache.org 10 incubator.apache.org355 jackrabbit.apache.org 9 jakarta.apache.org 39 james.apache.org53 jena.apache.org 5 juddi.apache.org3 lenya.apache.org46 logging.apache.org 111 lucene.apache.org 713 manifoldcf.apache.org 112 marmotta.apache.org 1 maven.apache.org1623 maventest.apache.org1178 mina.apache.org 2 mrunit.apache.org 3 myfaces.apache.org 348 nutch.apache.org8 oltu.apache.org 11 oodt.apache.org 1 ooo-site.apache.org 1 oozie.apache.org10 openjpa.apache.org 20 opennlp.apache.org 9 pdfbox.apache.org 1 pig.apache.org 7 pivot.apache.org1 poi.apache.org 1 portals.apache.org 35 river.apache.org2 santuario.apache.org1 shale.apache.org55 shiro.apache.org3 sling.apache.org2 sqoop.apache.org4 struts.apache.org 190 subversion.apache.org 3 synapse.apache.org 1 syncope.apache.org 2 tapestry.apache.org 6 tika.apache.org 9 tiles.apache.org12 turbine.apache.org 100 tuscany.apache.org 4 uima.apache.org 12 velocity.apache.org 41 whirr.apache.org2 wicket.apache.org 3 wink.apache.org 13 ws.apache.org 22 xalan.apache.org1 xerces.apache.org 5 xml.apache.org 1 xmlbeans.apache.org 3 zookeeper.apache.org18
IMPORTANT: Major Confluence Upgrade Coming Soon. Please review test instance now.
Hi All, If your project has a Confluence Wiki then this is an IMPORTANT announcement for you and your project. Please read this email carefully. NOTICE: The ASF Confluence instance is planned to be upgraded this Saturday 22nd June 2013. Judging by the time taken to upgrade the test instance, please expect the service to be in a down or read only state for the entire day. This email is to let you know that a test upgrade has already occurred and is live for you to play with now. This gives us all an opportunity to test for stability as well as any upgrade/plugin issues that might have happened along the way. Our current confluence wiki is at version 3.4.9 from way back in February 2011 and Atlassian have released a further 45 updates along the way, including another 2 major versions. The test instance has been upgraded several times along the way, with database surgery, operating system and server changes along the way. There have been casualties. Most notably is the Autoexport Plugin has had to be disabled permanently as during extensive testing, this plugin stopped working on version 4.3. Templates and Macros are also affected with major changes from wiki markup to xhtml amongst other things. Some plugins survived with upgrades all the way whilst some have been decommissioned/replaced or have changed to 'paid for' versions that we need to sort out licensing for. Nothing major that I can tell, but that's where you lot come in with your testing of your own spaces. Please familiarise yourself with what's new in Confluence 5.1 at https://confluence.atlassian.com/display/DOC/Confluence+5.1+Release+Notes and also take a good look around our upgraded test instance. Do not worry about mucking anything up on the test instance as that is what it is there for. Any changes/additions made will be lost on Saturday when a new migration will take place. The current confluence version will remain online in a read only state until the new version is completed. A jira ticket has been raised at https://issues.apache.org/jira/browse/INFRA-6406 where projects can add comments on any issues they are having with the test instance as compared to their old site. Just problems only please, do not turn it into a how to use confluence 5 thread. In addition, if there are any features that you currently use that do not work in the test instance, please replicate the feature in the current production TEST space so that I can test them all in the one place along the way. (Ask if you need create page permissions to cwiki.apache.org/confluence/display/TEST ) It may be possible in the future to replace Autoexport by playing around with the API to export the pages but this is not a priority, nor is it supported. We warned projects long ago that the Autoexport Tool would be incompatible with future Confluence versions and that time has now come. Ok so, please test and report to the Jira Issue mentioned anything amiss with your space. Go tohttps://cwiki2.apache.org/confluence and have a play around. You have 3 DAYS to report anything you find. Thanks Gavin (ASF Infra) -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: Requirements for SYNCOPE-143 the GUI Installer
On 11/06/2013 17:22, Jesal wrote: Dear All, Hoping to help contribute to the project. Setting up a mail on Dev as recommended by Francesco What should be the requirements for the GUI Installer SYNCOPE-143. If we can specify the requirements, hopefully I can start investigating what needs to be done to implement the functionality with a lot of help from all you guys :) Hi Jesal, some thoughts about a GUI installer. 1. Java Swing application enabled to work on a running JEE container for: 1a. configuring JNDI Datasource 1b. deploying Syncope webapps Alternatively, one can think of two web installers instead (one for core and one for console), already deployed on a running JEE container 2. Comes with base syncope.war and syncope-console.war 3. Lets select and install ConnId connector bundles from the Internet This at first glance; any more thoughts? Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: Problems running CXF Tests
On 11/06/2013 12:04, Jan Bernhardt wrote: Can someone confirm these test issues, or is it just me? Can you try with the different build profiles reported above? I did as suggested and my test results are: * 2 Errors and 3 Failures for the first run * 14 Errors and 6 Failures for the second run Hi Jan, I don't have Eclipse, but I've tested whether IT can be re-run safely this way: 1. modified core/src/test/resources/persistence.properties by setting jpa.url=jdbc:h2:syncopedb;DB_CLOSE_DELAY=-1 (this will use non-volatile H2 db for tests) 2. run mvn -Pjaxrs from core directory twice, got no errors Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: Problems running CXF Tests
On 11/06/2013 09:06, Jan Bernhardt wrote: Hello Syncopers, Hi Jan, I'm still struggling with my current task to remove Spring MVC and completely switch to CXF. https://issues.apache.org/jira/browse/SYNCOPE-286 My problem is not to remove Spring MVC but to get all test running again. Hopefully someone else can support me with this task. Here is my current state: 1) I checked out the current trunk version 2) I run mvn clean install -Pjaxrs -- All test run OK jaxrs is a profile only defined in core/pom.xml, you'd better 2a) mvn clean install from the root directory 2b) mvn -Pjaxrs from the core directory 3) I run mvn clean verify -DskipTest in core and cancel the execution while cargo:start command is executed. I don't understand this step: why are you doing this at all? 4) I run mvn cargo:run You'd better run mvn -Pdebug from the core directory for this: it starts Tomcat with all test configurations but without running any actual test (and with JPDA enabled on port 8000, it might be useful when developing). 5) I start JUnit test manually (org.apache.syncope.core.rest.jaxrs) in my Eclipse IDE -- 2 Errors and 4 Failures 6) I rerun JUnit test -- 14 Errors and 6 Assertion failures I haven't done any changes to the code at this point. But without being successful in running JUnit test in my IDE manually, I cannot make any changes to the code, remove Spring MVC and thus break our build. Especially the ability to rerun test is quite important to me to speed up development time. All this was working without problems after CXF migration was complete. But unfortunately it is not any longer. Can someone confirm these test issues, or is it just me? Can you try with the different build profiles reported above? Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: CXF problem deploying Syncope in Glasshfish
On 03/06/2013 10:28, Jan Bernhardt wrote: Hi Francesco, My issue here is that not all services are running normally with xml encoding. Only JSON is working without problems. One example is WorkflowService: /** * @param kind Kind can be USER or ROLE only! * @return Returns existing tasks for matching kind. */ @GET @Path(tasks) ListString getDefinedTasks(@PathParam(kind) AttributableType kind); ListString is not supported as a XML response for a webservice request, because JAX-B does not know how to marshal this kind of primitive data type (String does not contain any JAX-B annotations). It looks like that the UnitTest is only testing JSON encoding. To verify my issue, just take a look at: http://localhost:9080/syncope/cxf/workflows/USER/tasks.xml You will get a response like this: No message body writer has been found for response class ArrayList. Ah ok, but AFAIK this (XML) has always been problematic, even before 1.1.0: Sergey, can you confirm? Regards. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Montag, 3. Juni 2013 09:08 To: dev@syncope.apache.org Subject: Re: CXF problem deploying Syncope in Glasshfish On 03/06/2013 08:47, Jan Bernhardt wrote: Hi Massimiliano, I'm glad to see you found the solution yourself. Good job! I'm currently working on SYNCOPE-286 to remove Spring MVC, my problem here is that it looks like that a couple of recent changes to trunk have broken the cxf build / tests. I hope to resolve these issues by tomorrow. Hi Jan, which errors are you getting with CXF on trunk? I've just checked and don't have any error when building mvn -Pjaxrs on core (either trunk and 1_1_X) with both OpenJDK 1.6 and 1.7 on GNU / Linux. Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: CXF problem deploying Syncope in Glasshfish
On 03/06/2013 10:45, Jan Bernhardt wrote: Hi Francesco this is correct. We had a couple of other issues with XML but mainly because of the parallel usage of Spring MVC. After removing Spring MVC (and fixing current workarounds), we should be able to get CXF running 100% compatible with JSON and XML. For example I will have to refactor: ListString getDefinedTasks(@PathParam(kind) AttributableType kind); To something like this: ListWorkflowTask getDefinedTasks(@PathParam(kind) AttributableType kind); Understood: this wrapping has been done for other methods, so +1 for me. Regards. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Montag, 3. Juni 2013 10:35 To: dev@syncope.apache.org Subject: Re: CXF problem deploying Syncope in Glasshfish On 03/06/2013 10:28, Jan Bernhardt wrote: Hi Francesco, My issue here is that not all services are running normally with xml encoding. Only JSON is working without problems. One example is WorkflowService: /** * @param kind Kind can be USER or ROLE only! * @return Returns existing tasks for matching kind. */ @GET @Path(tasks) ListString getDefinedTasks(@PathParam(kind) AttributableType kind); ListString is not supported as a XML response for a webservice request, because JAX-B does not know how to marshal this kind of primitive data type (String does not contain any JAX-B annotations). It looks like that the UnitTest is only testing JSON encoding. To verify my issue, just take a look at: http://localhost:9080/syncope/cxf/workflows/USER/tasks.xml You will get a response like this: No message body writer has been found for response class ArrayList. Ah ok, but AFAIK this (XML) has always been problematic, even before 1.1.0: Sergey, can you confirm? Regards. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Montag, 3. Juni 2013 09:08 To: dev@syncope.apache.org Subject: Re: CXF problem deploying Syncope in Glasshfish On 03/06/2013 08:47, Jan Bernhardt wrote: Hi Massimiliano, I'm glad to see you found the solution yourself. Good job! I'm currently working on SYNCOPE-286 to remove Spring MVC, my problem here is that it looks like that a couple of recent changes to trunk have broken the cxf build / tests. I hope to resolve these issues by tomorrow. Hi Jan, which errors are you getting with CXF on trunk? I've just checked and don't have any error when building mvn -Pjaxrs on core (either trunk and 1_1_X) with both OpenJDK 1.6 and 1.7 on GNU / Linux. Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: Rest call workflow
On 23/05/2013 12:15, Timothy wrote:
Hi Fabio,
thanks for the reply! I have edited the workflow in console-management. I
replaced the default workflow doing case 2 with the workflow from [1] and
pressed save. When I make a new user, I get following message
Error:{[Workflow [couldn't instantiate class
org.apache.syncope.core.workflow.activiti.Create]]}
Timothy,
[1] works for Apache Syncope 1.0.X - I have just added some warning there.
You might want to adapt it to Apache Syncope 1.1.X but you would need to
change some information like as package for Java classes.
For example,
org.apache.syncope.core.workflow.activiti.Create
is now
org.apache.syncope.core.workflow.user.activiti.task.Create
HTH
Regards.
P.S. Someone else has already [2] invited you to post such questions to
the user mailing list (not here, the dev mailing list), please follow
his advice, thanks.
[1] https://cwiki.apache.org/SYNCOPE/self-registration-password-reset.html
[2]
http://syncope-dev.1063484.n5.nabble.com/MySQL-Synchronization-tp5713710p5713713.html
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: [jira] [Commented] (SYNCOPE-340) Translate items of Syncope UI and config files labels for Portuguese language
On 17/05/2013 03:00, Bruno Moura wrote: Hi Massimiliano Unfortunately isn't allowed to attach a file in the jira I believe because the status this issue, anyway I'm sending it by email for you. Bruno, Massimiliano, any update to this? There is still no ''CrontabContainer_pt_BR.properties in the console sources. Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
License header for new files (WAS: Re: svn commit: r1484085 - in /syncope/branches/1_1_X/console/src/main: java/org/apache/syncope/console/commons/ java/org/apache/syncope/console/pages/panels/ resour
the License for the + * specific language governing permissions and limitations + * under the License. */ package org.apache.syncope.console.pages.panels; Modified: syncope/branches/1_1_X/console/src/main/resources/org/apache/syncope/console/markup/html/CrontabContainer.properties URL: http://svn.apache.org/viewvc/syncope/branches/1_1_X/console/src/main/resources/org/apache/syncope/console/markup/html/CrontabContainer.properties?rev=1484085r1=1484084r2=1484085view=diff == --- syncope/branches/1_1_X/console/src/main/resources/org/apache/syncope/console/markup/html/CrontabContainer.properties (original) +++ syncope/branches/1_1_X/console/src/main/resources/org/apache/syncope/console/markup/html/CrontabContainer.properties Sat May 18 10:25:22 2013 @@ -1,17 +1,19 @@ -# Copyright 2013 The Apache Software Foundation. +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# License); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at # -# Licensed under the Apache License, Version 2.0 (the License); -# you may not use this file except in compliance with the License. -# You may obtain a copy of the License at +# http://www.apache.org/licenses/LICENSE-2.0 # -# http://www.apache.org/licenses/LICENSE-2.0 -# -# Unless required by applicable law or agreed to in writing, software -# distributed under the License is distributed on an AS IS BASIS, -# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -# See the License for the specific language governing permissions and -# limitations under the License. - +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. selOpt1=Unschedule selOpt2=Every 5 minutes selOpt3=Fire at 12pm (noon) every day Modified: syncope/branches/1_1_X/console/src/main/resources/org/apache/syncope/console/markup/html/CrontabContainer_it.properties URL: http://svn.apache.org/viewvc/syncope/branches/1_1_X/console/src/main/resources/org/apache/syncope/console/markup/html/CrontabContainer_it.properties?rev=1484085r1=1484084r2=1484085view=diff == --- syncope/branches/1_1_X/console/src/main/resources/org/apache/syncope/console/markup/html/CrontabContainer_it.properties (original) +++ syncope/branches/1_1_X/console/src/main/resources/org/apache/syncope/console/markup/html/CrontabContainer_it.properties Sat May 18 10:25:22 2013 @@ -1,17 +1,19 @@ -# Copyright 2013 The Apache Software Foundation. +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# License); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at # -# Licensed under the Apache License, Version 2.0 (the License); -# you may not use this file except in compliance with the License. -# You may obtain a copy of the License at +# http://www.apache.org/licenses/LICENSE-2.0 # -# http://www.apache.org/licenses/LICENSE-2.0 -# -# Unless required by applicable law or agreed to in writing, software -# distributed under the License is distributed on an AS IS BASIS, -# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -# See the License for the specific language governing permissions and -# limitations under the License. - +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. selOpt1=Non schedulato selOpt2=Ogni 5 minuti selOpt3=Lanciato ogni giorno a mezzanotte -- -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: LDAP Synchronization
On 16/05/2013 16:44, Timothy wrote: Hi, it's me again :) I'm still trying to configure LDAP synchronization. I have followed the [1] guide but when I select org.apache.syncope.core.propagation.impl.LDAPMembershipPropagationActions as Actions Class in the sync task, I get the message that I shoud enable a replication plugin under configuration. Can't seem to find the thing though Where is such message coming from? It sounds strange. LDAPMembershipPropagationActions will enable the propagation of memberships from Syncope to LDAP, e.g. when creating user A with role R in Syncope, user A will be assigned to role R in LDAP as well, under some conditions. However, when I select org.apache.syncope.core.propagation.impl.DefaultSyncActions as Actions Class the synchronization works in one way. Users I have created in OpenDJ are visible in Syncope but any changes I do in Syncope have no effect in OpenDJ. Synchronized users are not assigned any resource by default: you will need to change the user template [2] for the LDAP synchronization task so that every new user synchronized from LDAP will also get the LDAP resource assigned. This will enable the propagation to LDAP of any modification occuring on Syncope. Anyway, have you read the Changelog section towards the end of [1]? There is something related to OpenDJ. Regards. [1] http://blog.tirasa.net/blogs/index.php/ilgrosso/unlock-full-ldap-features-in [2] https://cwiki.apache.org/confluence/display/SYNCOPE/Tasks#Tasks-SpecifyUserTemplate -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: Numberformatexception EntryUUID
On 16/05/2013 15:37, Timothy Persoon wrote: Hi all, I'm trying to propagate Syncope with LDAP (OpenDJ) but when I execute the task, Syncope throws an error exception on the field EntryUUID. The error is numberformatexception and EntryUUID is a string. Anybody knows what could cause this? I have attached the logoutput as screenshot Hi Timothy, you probably need to set Uid Attribute to cn (defaults to entryUUID) in the LDAP connector configuration. See more information about configuring Syncope and LDAP at [1]. HTH Regards. [1] http://blog.tirasa.net/blogs/index.php/ilgrosso/unlock-full-ldap-features-in -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: Spring 3.1.4
On 08/05/2013 09:51, Colm O hEigeartaigh wrote: Hi all, I'm experimenting with using Syncope (1.1.X) with Spring 3.1.4. I've also added a cglib 2.2.2 dependency to core. I get a small number of test failures in core: AttributableSearchTest.searchByPageAndSize:186 expected:1 but was:0 AttributableSearchTest.searchByUsernameAndFullname:320 expected:2 but was:0 AttributableSearchTest.searchByUsernameAndId:273 expected:1 but was:0 AttributableSearchTest.searchByIsNull:224 expected:4 but was:0 AttributableSearchTest.searchByBoolean:156 expected:1 but was:0 AttributableSearchTest.searchById:337 expected:1 but was:0 AttributableSearchTest.searchWithLikeCondition:119 expected:1 but was:0 AttributableSearchTest.searchByResource:253 expected:1 but was:0 AttributableSearchTest.searchWithNotCondition:134 expected:4 but was:0 AttributableSearchTest.issue202:376 expected:2 but was:0 AttributableSearchTest.searchByMembership:203 expected:2 but was:0 AttributableSearchTest.issueSYNCOPE46:413 expected:1 but was:0 AttributableSearchTest.searchByRolenameAndId:297 expected:1 but was:0 AttributableSearchTest.issueSYNCOPE95:79 expected:1 but was:0 Some NotificationTests fail as well. Any ideas why these tests are failing? Manually adding CGLib should break the Spring's application context loading. Any particular reason why you added this back (it used to be there but I've removed as part of some Spring dependency upgrade - see [1])? [1] https://jira.springsource.org/browse/SPR-9669 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: Spring 3.1.4
Il 08/05/2013 10:41, Colm O hEigeartaigh ha scritto: If I don't add cglib then all of the core tests fail with: java.lang.IllegalStateException: Failed to load ApplicationContext at org.springframework.aop.framework.DefaultAopProxyFactory.createAopProxy(DefaultAopProxyFactory.java:67) I've search through commits: I think you'd need to revert at least [2] and [3] in order to be able to work with Spring 3.1.X on Syncope 1_1_X. Regards. On Wed, May 8, 2013 at 9:55 AM, Francesco Chicchiriccòilgro...@apache.org wrote: On 08/05/2013 09:51, Colm O hEigeartaigh wrote: Hi all, I'm experimenting with using Syncope (1.1.X) with Spring 3.1.4. I've also added a cglib 2.2.2 dependency to core. I get a small number of test failures in core: AttributableSearchTest.**searchByPageAndSize:186 expected:1 but was:0 AttributableSearchTest.**searchByUsernameAndFullname:**320 expected:2 but was:0 AttributableSearchTest.**searchByUsernameAndId:273 expected:1 but was:0 AttributableSearchTest.**searchByIsNull:224 expected:4 but was:0 AttributableSearchTest.**searchByBoolean:156 expected:1 but was:0 AttributableSearchTest.**searchById:337 expected:1 but was:0 AttributableSearchTest.**searchWithLikeCondition:119 expected:1 but was:0 AttributableSearchTest.**searchByResource:253 expected:1 but was:0 AttributableSearchTest.**searchWithNotCondition:134 expected:4 but was:0 AttributableSearchTest.**issue202:376 expected:2 but was:0 AttributableSearchTest.**searchByMembership:203 expected:2 but was:0 AttributableSearchTest.**issueSYNCOPE46:413 expected:1 but was:0 AttributableSearchTest.**searchByRolenameAndId:297 expected:1 but was:0 AttributableSearchTest.**issueSYNCOPE95:79 expected:1 but was:0 Some NotificationTests fail as well. Any ideas why these tests are failing? Manually adding CGLib should break the Spring's application context loading. Any particular reason why you added this back (it used to be there but I've removed as part of some Spring dependency upgrade - see [1])? [1] https://jira.springsource.org/**browse/SPR-9669https://jira.springsource.org/browse/SPR-9669 [2] http://svn.apache.org/viewvc?view=revisionrevision=1438506 [3] http://svn.apache.org/viewvc?view=revisionrevision=1467904 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [VOTE] Apache Syncope 1.1.1
On 29/04/2013 20:53, Francesco Chicchiriccò wrote: I've created a 1.1.1 release, with the following artifacts up for a vote: SVN source tag (r1477131): https://svn.apache.org/repos/asf/syncope/tags/syncope-1.1.1/ List of changes: https://svn.apache.org/repos/asf/syncope/tags/syncope-1.1.1/CHANGES Maven staging repo: https://repository.apache.org/content/repositories/orgapachesyncope-148/ Source release (checksums and signatures are available at the same location): https://repository.apache.org/content/repositories/orgapachesyncope-148/org/apache/syncope/syncope/1.1.1/syncope-1.1.1-source-release.zip Staging site: http://syncope.apache.org/1.1.1/ 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) +1 Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[RESULT] [VOTE] Apache Syncope 1.1.1
Hi all, after 72 hours, the vote for Syncope 1.1.1 [1] *passes* with 5 PMC + 1 non-PMC votes. +1 (PMC / binding) * Fabio Martelli * Marco Di Sabatino * Massimiliano Perrone * Colm O hEigeartaigh * Francesco Chicchiriccò +1 (non binding) * Oliver Wulff 0 none -1 none Thanks to everyone participating. I will now copy this release to Syncope' dist directory and promote the artifacts to the central Maven repository. Best regards. [1] http://syncope-dev.1063484.n5.nabble.com/VOTE-Apache-Syncope-1-1-1-tt5713648.html -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[ANN] Apache Syncope 1.1.1 released
The Apache Syncope team is pleased to announce the release of Syncope 1.1.1. Apache Syncope is an Open Source system for managing digital identities in enterprise environments, implemented in JEE technology . The release will be available within 24h from: http://syncope.apache.org/downloads.html The full change log is available here: ttp://s.apache.org/cp0 We welcome your help and feedback. For more information on how to report problems, and to get involved, visit the project website at http://syncope.apache.org/ The Apache Syncope Team
Work start on 1.2.0?
Hi all, it is already some time since the source trunk is set to 1.2.0-SNAPSHOT, hence anyone is already able to start working on 1.2.0 issues [1], including the full removal of Spring MVC stuff: who wants to be the first? ;-) Moreover, our roadmap [2] says 1.2.0 is expected for Q2 2013: I don't think this is a reachable target, given the amount of issues and the remaining time (2 months), so I'd propose to shift forward any expected release date of at least one quarter. WDYT? [1] https://issues.apache.org/jira/browse/SYNCOPE/fixforversion/12322505#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel [2] https://cwiki.apache.org/confluence/display/SYNCOPE/Roadmap#Roadmap-1.2.0%28Intermezzo%29 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[VOTE] Apache Syncope 1.1.1
I've created a 1.1.1 release, with the following artifacts up for a vote: SVN source tag (r1477131): https://svn.apache.org/repos/asf/syncope/tags/syncope-1.1.1/ List of changes: https://svn.apache.org/repos/asf/syncope/tags/syncope-1.1.1/CHANGES Maven staging repo: https://repository.apache.org/content/repositories/orgapachesyncope-148/ Source release (checksums and signatures are available at the same location): https://repository.apache.org/content/repositories/orgapachesyncope-148/org/apache/syncope/syncope/1.1.1/syncope-1.1.1-source-release.zip Staging site: http://syncope.apache.org/1.1.1/ 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/
[DISCUSS] Apache Syncope 1.1.1
Discussion thread for vote on 1.1.1 release, with SVN source tag (r1477131). For more information on the release process, check out http://www.apache.org/dev/release.html Some of the things to check before voting are: - does mvn apache-rat:check pass on the source - can you build the contents of source release zip and SVN tag - do all of the staged jars/wars/zips contain the required LICENSE and NOTICE files - are all of the staged jars/wars/zips signed and the signature verifiable - is the signing key in the project's KEYS file and on a public server (i.e. http://www.apache.org/dist/syncope/) -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: svn commit: r1471566 - in /syncope/trunk/console/src/main/java/org/apache/syncope/console/pages: EditUserModalPage.java UserModalPage.java panels/ResourcesPanel.java panels/RolePanel.java
),
-new ListModelString(allResources), statusPanel);
-add(resourcesPalette);
-}
-
-public ResourcesPanel(final String id, final RoleTO roleTO) {
-this(id, (AbstractAttributableTO) roleTO);
+AjaxPalettePanelString resourcesPalette = null;
-ListString selectedResources = new
ArrayListString(roleTO.getResources());
-Collections.sort(selectedResources);
+if (attributableTO instanceof UserTO) {
+resourcesPalette = new
AjaxRecordingPalettePanelString(resourcesPalette,
+new PropertyModelListString(attributableTO,
resources),
+new ListModelString(allResources),
builder.statusPanel);
+} else if (attributableTO instanceof RoleTO) {
+ListString selectedResources = new
ArrayListString(((RoleTO) attributableTO).getResources());
+Collections.sort(selectedResources);
-final AjaxPalettePanelString resourcesPalette = new
AjaxPalettePanelString(resourcesPalette,
-new PropertyModelListString(roleTO, resources),
-new ListModelString(allResources));
+resourcesPalette = new
AjaxPalettePanelString(resourcesPalette,
+new PropertyModelListString(attributableTO,
resources), new ListModelString(allResources));
+}
add(resourcesPalette);
+
}
private class AjaxRecordingPalettePanelT extends AjaxPalettePanelT
{
Modified:
syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/panels/RolePanel.java
URL:
http://svn.apache.org/viewvc/syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/panels/RolePanel.java?rev=1471566r1=1471565r2=1471566view=diff
==
---
syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/panels/RolePanel.java
(original)
+++
syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/panels/RolePanel.java
Wed Apr 24 18:00:35 2013
@@ -119,7 +119,8 @@ public class RolePanel extends Panel {
// Resources container
//
-this.add(new ResourcesPanel(resources,
roleTO).setOutputMarkupId(true));
+this.add(new
ResourcesPanel.ResourcesPanelBuilder(resources).attributableTO(roleTO).build()
+.setOutputMarkupId(true));
//
ListModelString selectedEntitlements = new
ListModelString(roleTO.getEntitlements());
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: [VOTE] Apache Syncope 1.0.8
On 18/04/2013 11:05, Francesco Chicchiriccò wrote: 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) +1 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
RESULT] [VOTE] Apache Syncope 1.0.8
Hi all, after 72 hours, the vote for Syncope 1.0.8 [1] *passes* with 5 PMC + 1 non-PMC votes. +1 (PMC / binding) * Fabio Martelli * Marco Di Sabatino Di Diodoro * Massimiliano Perrone * Colm O hEigeartaigh * Francesco Chicchiriccò +1 (non binding) * Andrei Shakirin 0 none -1 none Thanks to everyone participating. I will now copy this release to Syncope' dist directory and promote the artifacts to the central Maven repository. Best regards. [1] http://syncope-dev.1063484.n5.nabble.com/VOTE-Apache-Syncope-1-0-8-tt5713559.html -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[ANN] Apache Syncope 1.0.8 released
The Apache Syncope team is pleased to announce the release of Syncope 1.0.8. Apache Syncope is an Open Source system for managing digital identities in enterprise environments, implemented in JEE technology . The release will be available within 24h from: http://syncope.apache.org/downloads.html The full change log is available here: http://s.apache.org/QTR We welcome your help and feedback. For more information on how to report problems, and to get involved, visit the project website at http://syncope.apache.org/ The Apache Syncope Team
Re: Console Log Settings lost after Syncope restart
On 19/04/2013 11:21, Denis Signoretto wrote: Hi Syncopers, I'm using Syncope 1.0.7. I have seen that changing log levels of Console are lost after a Syncope restart while Core Log changes are maintaned. It's correct? It is expected: console log settings are only dependent con console's logback.xml. Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: R: Console Log Settings lost after Syncope restart
On 19/04/2013 12:48, Denis Signoretto wrote: At first I thought it wasn't so intuitive for an administrator. After same thought I agree with the choice. Console it's a separate component and don't depends on db, so it's a good idea leave his settings separated by syncope core. (I guess this is the main reason behind this choice). Correct :-) I have added some info about it at the documentation [1]. Feel free to adjust it. Thanks! Regards. [1] - https://cwiki.apache.org/confluence/display/SYNCOPE/Log+levels -Messaggio originale- Da: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Inviato: venerdì 19 aprile 2013 11:38 A: dev@syncope.apache.org Oggetto: Re: Console Log Settings lost after Syncope restart On 19/04/2013 11:21, Denis Signoretto wrote: Hi Syncopers, I'm using Syncope 1.0.7. I have seen that changing log levels of Console are lost after a Syncope restart while Core Log changes are maintaned. It's correct? It is expected: console log settings are only dependent con console's logback.xml. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[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/
[DISCUSS] Apache Syncope 1.0.8
Discussion thread for vote on 1.0.8 release, with SVN source tag (r1469201). For more information on the release process, check out http://www.apache.org/dev/release.html Some of the things to check before voting are: - does mvn apache-rat:check pass on the source - can you build the contents of source release zip and SVN tag - do all of the staged jars/wars/zips contain the required LICENSE and NOTICE files - are all of the staged jars/wars/zips signed and the signature verifiable - is the signing key in the project's KEYS file and on a public server (i.e. http://www.apache.org/dist/syncope/) -- 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
Gents, any news about this? Regards. On 02/04/2013 14:53, Colm O hEigeartaigh wrote: Sounds good thanks! Colm. On Tue, Apr 2, 2013 at 1:16 PM, Francesco Chicchiriccò ilgro...@apache.orgwrote: On 02/04/2013 13:55, Colm O hEigeartaigh wrote: Hi Francesco, We have not been able to sort out the OSGi issues as of yet. One of the problems seems to be a conflict between the different versions of Spring used by Syncope + CXF, which is resulting in the exceptions reported in SYNCOPE-337. For the moment I propose moving SYNCOPE-337 to 1.1.1. If we can't fix the OSGi issues in a relatively simple way then we can move it to 1.2. I would like to keep the changes made as part of SYNCOPE-203 in place, as it doesn't affect the Tomcat deployment + it would require additional changes on some downstream code that we have. Fine to me: I'll proceed then to: 1. create new branch 1_1_X from trunk + set trunk version to 1.2.0-SNAPSHOT 2. create Jenkins job for 1_1_X 3. create JIRA version 1.1.1 4. move SYNCOPE-337 to 1.1.1 Nothing will be done in respect of SYNCOPE-203. Regards. On Tue, Apr 2, 2013 at 8:00 AM, ilgrosso ilgro...@apache.org wrote: Colm O hEigeartaigh wrote 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? Hi Colm, is there any progress about this? I think we should be able to at least think starting the 1.1.0 release process this week, hence understanding how to handle the OSGi features is quite important right now. Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [Passed] apache/syncope#17 (trunk - 57330d9)
On 17/04/2013 11:58, Colm O hEigeartaigh wrote: Is there any way to subscribe the Travis CI to the mailing list? I keep on getting moderation requests for these mails. Me too :-( I have already subscribed notificati...@travis-ci.org to dev@ but I guess that the moderation request is due to some kind of spam filtering. BTW, I've finally been able to make a successful Travis CI build ;-) (it was only matter of build process duration) I will ask Jukka for how they handle this at Jackrabbit. Regards. On Wed, Apr 17, 2013 at 10:54 AM, Travis CI notificati...@travis-ci.orgwrote: Build Update for apache/syncope - Build: #17 Status: Passed Duration: 34 minutes and 23 seconds Commit: 57330d9 (trunk) Author: Francesco Chicchiricc�� Message: Merge from 1_1_X git-svn-id: https://svn.apache.org/repos/asf/syncope/trunk@146880913f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/syncope/compare/11aafa098faf...57330d965bb4 View the full build log and details: https://travis-ci.org/apache/syncope/builds/6409315 -- You can configure recipients for build notifications in your .travis.yml file. See http://about.travis-ci.org/docs/user/build-configuration -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: Info about provisioning
On 15/04/2013 13:09, Denis Signoretto wrote: Hi Syncopers, I'm using Syncope 1.0.X. I just would like to have a confirmation about how user attributes provisioning occurs. If some user attributes are changes the provisioning process updates all user attributes or only chaged attributes? By my trials it seems the former. It's right? You are right for 1.0.X This has been optimized in 1.1.X. Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [DISCUSS] ConnectorService, Java 7 and @MatrixParam
FYI, I have opened SYNCOPE-358 for this. Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [VOTE] Apache Syncope 1.1.0
On 05/04/2013 13:29, Francesco Chicchiriccò wrote: I've created a 1.1.0 release, with the following artifacts up for a vote: SVN source tag (r1464912): http://svn.apache.org/repos/asf/syncope/tags/syncope-1.1.0/ List of changes: http://svn.apache.org/repos/asf/syncope/tags/syncope-1.1.0/CHANGES Maven staging repo: https://repository.apache.org/content/repositories/orgapachesyncope-066/ Source release (checksums and signatures are available at the same location): https://repository.apache.org/content/repositories/orgapachesyncope-066/org/apache/syncope/syncope/1.1.0/syncope-1.1.0-source-release.zip Staging site: http://syncope.apache.org/1.1.0/ 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) +1 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: Git repo now available
On 05/04/2013 16:24, Francesco Chicchiriccò wrote: On 03/04/2013 10:58, Colm O hEigeartaigh wrote: Hi all, The Syncope git repo is now available: http://git.apache.org/syncope.git/ Please also see the following page for information about how to set up a git project at Apache: http://wiki.apache.org/general/GitAtApache Very nice. I am still waiting for the eventual mirroring to GitHub but it still does not seem available [1]: this would let us set up a nice Travis CI job, as discussed earlier. FYI, the GitHub repo [1] is now working. Regards. [1 https://github.com/apache/syncope -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[RESULT] [VOTE] Apache Syncope 1.1.0
Hi all, after 72 hours, the vote for Syncope 1.1.0 [1] *passes* with 5 PMC + 2 non-PMC votes. +1 (PMC / binding) * Fabio Martelli * Massimiliano Perrone * Colm O hEigeartaigh * Jan Bernhardt * Francesco Chicchiriccò +1 (non binding) * Andrei Shakirin * Christian Schneider 0 none -1 none Thanks to everyone participating. I will now copy this release to Syncope' dist directory and promote the artifacts to the central Maven repository. Best regards. [1] http://syncope-dev.1063484.n5.nabble.com/VOTE-Apache-Syncope-1-1-0-tt5713446.html -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[ANN] Apache Syncope 1.1.0 released
The Apache Syncope team is pleased to announce the release of Syncope 1.1.0. Apache Syncope is an Open Source system for managing digital identities in enterprise environments, implemented in JEE technology . The release will be available within 24h from: http://syncope.apache.org/downloads.html The full change log is available here: http://s.apache.org/P8C We welcome your help and feedback. For more information on how to report problems, and to get involved, visit the project website at http://syncope.apache.org/ The Apache Syncope Team
Re: Git repo now available
On 03/04/2013 10:58, Colm O hEigeartaigh wrote: Hi all, The Syncope git repo is now available: http://git.apache.org/syncope.git/ Please also see the following page for information about how to set up a git project at Apache: http://wiki.apache.org/general/GitAtApache Very nice. I am still waiting for the eventual mirroring to GitHub but it still does not seem available [1]: this would let us set up a nice Travis CI job, as discussed earlier. Regards. [1 https://github.com/apache/syncope -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
