Re: openJDK 17 compatibility
On 11/04/24 14:12, Marco Naimoli wrote: Hello, I'm new to Apache Syncope; I've tried to test it using the standalone installation on a vanilla debian linux bookworm, using openJDK 17.0.10 It seems to work, but when I try to import a SAML IDP metadata it fails with the following error: InvalidEntity: Location must not be null Metadata are ok: using the embedded version built with maven, metadata are imported without problems. Clicking on the button to download the SP metadata doesn't do anything And the wa.log (don't know if it can be related) is full of the following error: ERROR org.springframework.scheduling.support.TaskUtils$LoggingErrorHandler - Unexpected error occurred in scheduled task java.lang.IllegalStateException: Syncope core is not yet ready I'm not sure, but I remember that the error "Location must not be null" was shown during some other operation, different from SAML configuration Any suggestions / help ? Hi Marco, glad of your interest in Apache Syncope. About JDK 17 compatibility, we have an active GitHub actions workflows on the 3_0_X branch (supposing you are running the latest stable 3.0.6). Moreover, my company is running several Syncope deployments on various flavors of OpenJDK 17. As far as I understand, all works as expected when you use the standalone ZIP but it fails when you deploy Syncope somewhere else. As suggested by the Getting Started guide [1], however you should be using the Maven archetype for an independent deployment, or the Docker images; there are further options, too, but it really depends on how much you are planning to customize or extend. Can you describe how did you get to deploy Syncope, including which components, which DBMS, which Java EE container, ... ? Regards. [1] https://syncope.apache.org/docs/3.0/getting-started.html#obtain-apache-syncope -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Member at The Apache Software Foundation Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail http://home.apache.org/~ilgrosso/
openJDK 17 compatibility
Hello, I'm new to Apache Syncope; I've tried to test it using the standalone installation on a vanilla debian linux bookworm, using openJDK 17.0.10 It seems to work, but when I try to import a SAML IDP metadata it fails with the following error: InvalidEntity: Location must not be null Metadata are ok: using the embedded version built with maven, metadata are imported without problems. Clicking on the button to download the SP metadata doesn't do anything And the wa.log (don't know if it can be related) is full of the following error: ERROR org.springframework.scheduling.support.TaskUtils$LoggingErrorHandler - Unexpected error occurred in scheduled task java.lang.IllegalStateException: Syncope core is not yet ready I'm not sure, but I remember that the error "Location must not be null" was shown during some other operation, different from SAML configuration Any suggestions / help ? Thank you Marco
Re: Propagation failure on update
- Le 28 Mar 24, à 9:38, Lionel SCHWARZ lionel.schw...@in2p3.fr a écrit : > - Le 27 Mar 24, à 8:19, Francesco Chicchiriccò ilgro...@apache.org a > écrit : > >> On 26/03/24 13:30, Lionel SCHWARZ wrote: >>> Dear all, >>> >>> After reading >>> https://syncope.apache.org/docs/reference-guide.html#propagation, >>> I ask myself a question: is there a way to avoid a User (or AnyObject) to be >>> modified in case the propagation task fails? >> >> Hi Lionel, >> that's exactly the purpose of setting a non-null priority onto an External >> Resource: >> >> > the execution of a given set of tasks is halted (and global failure is >> > reported) >> > whenever the first sequential task fails >> >> would mean exactly that. > Thanks Francesco, I'll try this. Hi Francesco and all, After investigations and tests, I could indeed check that the sequence of tasks stops when the first task fails. But there is a remaining question: the attribute on the Entity itself (the USER), the one which triggered the propagation, keeps changed. So we are in the situation where the User has an attribute different than values in the remote repos. Is there a way to do kind of rollback on the USER update in this case? Lionel smime.p7s Description: S/MIME Cryptographic Signature
