RE: Persistence id generation strategy: TABLE vs AUTO
I have digged into the NotificationTestITCase problem a little bit more and
discovered the following:
Initial load (context.xml) creates two notifications with id= 100 and 101.
It seems that AUTO generation strategy, used in Notification now, starts with
ID=101 (not sure how to influence on it).
Therefore, if 101 Notification is not deleted, every create attempt fails with
error:
Unique index or primary key violation: PRIMARY_KEY_A ON
PUBLIC.NOTIFICATION(ID); SQL statement:
INSERT INTO PUBLIC.Notification (ID, RECIPIENTATTRNAME, RECIPIENTATTRTYPE,
SELFASRECIPIENT, SENDER, SUBJECT, TEMPLATE, TRACELEVEL, XMLABOUT,
XMLRECIPIENTS) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?) [23505-170] {prepstmnt
1643545237 INSERT INTO PUBLIC.Notification (ID, RECIPIENTATTRNAME,
RECIPIENTATTRTYPE, SELFASRECIPIENT, SENDER, SUBJECT, TEMPLATE, TRACELEVEL,
XMLABOUT, XMLRECIPIENTS) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)} [code=23505,
state=23505]
It makes create() and issueSYNCOPE83() tests depending on delete() test, that
deletes Notification with id=101.
Suggestion: leave it as it is for CXF migration step (re-runnable delete() will
check for notification id=101 and delete it only if it is exists, if not -
create and delete other notification).
After migration change Notification id generation strategy to Table (defined in
orm.xml) and start index from 1000. It makes NotificationTestITCase tests more
stable and helps to avoid check for 101 in delete(). Fix must be verified for
all supported DBs. Corresponded JIRA issue will be created for it.
Does it sounds reasonable?
Cheers,
Andrei.
-Original Message-
From: Andrei Shakirin [mailto:ashaki...@talend.com]
Sent: Freitag, 11. Januar 2013 12:01
To: dev@syncope.apache.org
Subject: RE: Persistence id generation strategy: TABLE vs AUTO
Hi,
Fabio and Francesco: thanks for the fast feedback.
I cannot remember the good reason for this differences but it there was
...
In our experience with Apache Syncope (especially at the beginning)
there
are troubles with AUTO generated id in case of high concurrence.
Not only: some specific table generator associated to a given entity
(or set of
entities) were defined, and defined in orm.xml, not by annotations -
in order to give more flexibility when dealing with specific
requirements in id generation.
I also have not nice experience with AUTO strategy under high concurrency.
The question was more in following direction: does it make sense potentially
to use TABLE (in orm.xml) also for AbstractDerAttr, AbstractVirAttr,
Notification, UserRequest or there is good reason to keep them with AUTO
annotation?
I cannot be sure about the reason but, please, consider that
integration
tests are interdependent: the order and the existence of a certain
test are often fundamental.
Exactly, here's why text execution order is fixed.
Consider that integration tests were added over time and that their
number is starting to be quite considerable...
Yep, already see it from @FixMethodOrder annotation and from tests logic.
I am trying to found more or less reliable solution to keep
NotificationITTestCase re-runnable (SYNCOPE-268) - will investigate the
problem additionally and inform about result.
Cheers,
Andrei.
Regards.
Cheers,
Andrei.
(1)https://issues.apache.org/jira/browse/SYNCOPE-268
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
[jira] [Updated] (SYNCOPE-241) Move persistence and persistence impl into separate modules
[ https://issues.apache.org/jira/browse/SYNCOPE-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated SYNCOPE-241: Attachment: (was: SYNCOPE-241-4.patch) Move persistence and persistence impl into separate modules --- Key: SYNCOPE-241 URL: https://issues.apache.org/jira/browse/SYNCOPE-241 Project: Syncope Issue Type: Improvement Components: core Affects Versions: 1.0.3-incubating Reporter: Christian Schneider Fix For: 1.1.0 Attachments: SYNCOPE-241-2.patch, SYNCOPE-241-3.patch, SYNCOPE-241.patch The core module currently contains many parts of syncope. This makes it bigger and more complex than necessary. A possible modularization is to move the internal model (org.apache.syncope.core.persistence*) and the persistence impl (org.apache.syncope.core.persistence.impl) out of core and into separate modules. One big advantage would be that the jpa code enhancements would then run in the model module only. Currently we run into some problems in the cxf migration when running the rest itests in core that may be caused by eclipse overwriting the enhanced classes with plain classes. If the model (peristence) classes are in a separate module we could leave it out of eclipse and so this would be no issue anymore. Another advantage would be that the persistence tests could run in the persistence impl module so when working on the core they would not have to run each time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Cosole REST Service Client implements Serializable ?
Hi Syncopers, I'm currently updating syncope console to use new REST Service Interface (with old Spring proxy variant). And since my Eclipse is complaining about a missing serialVersionUID I was wondering why does BaseRestClient implements Serializable? Is there any need to make the rest client persistent to store in a DB or send it over the wire? I would like to remove implements Serializable since it looks wrong to me, but before I do this, I would like to double check with you, if there is a special reason for this and thus a need to keep this interface. Best regards. Jan
Re: Cosole REST Service Client implements Serializable ?
On 14/01/2013 10:02, Jan Bernhardt wrote: Hi Syncopers, I'm currently updating syncope console to use new REST Service Interface (with old Spring proxy variant). And since my Eclipse is complaining about a missing serialVersionUID I was wondering why does BaseRestClient implements Serializable? Is there any need to make the rest client persistent to store in a DB or send it over the wire? I would like to remove implements Serializable since it looks wrong to me, but before I do this, I would like to double check with you, if there is a special reason for this and thus a need to keep this interface. Hi Jan, everything that's part of a Wicket component (like pages, for example) must be Serializable. Hence, please keep this feature. Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[jira] [Commented] (SYNCOPE-272) Apache Syncope updates all attributes from an user
[ https://issues.apache.org/jira/browse/SYNCOPE-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13552520#comment-13552520 ] Marco Di Sabatino Di Diodoro commented on SYNCOPE-272: -- Fix for 1_0_X http://svn.apache.org/viewvc?view=revisionrevision=1432844 Apache Syncope updates all attributes from an user -- Key: SYNCOPE-272 URL: https://issues.apache.org/jira/browse/SYNCOPE-272 Project: Syncope Issue Type: Bug Components: core Affects Versions: 1.0.5 Reporter: Marco Di Sabatino Di Diodoro Assignee: Marco Di Sabatino Di Diodoro Fix For: 1.0.5, 1.1.0 Attachments: testissueSYNCOPE272.patch During synchronization task, Apache Syncope updates all attributes from an user, specially the attributes that come from the synched resource and the calculed attributes(JEXL) of the user template. If an attribute is not present in the schema mapping of the synched resource, but is present in the user template with null value, Apache Syncope clear the attribute value. If an attribute of the user template is not valued, it must not be considered. I attach a test for solve this issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SYNCOPE-241) Move persistence and persistence impl into separate modules
[ https://issues.apache.org/jira/browse/SYNCOPE-241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13552524#comment-13552524 ] Francesco Chicchiriccò commented on SYNCOPE-241: Christian, the updated SYNCOPE-241-4.patch looks generally fine to me. Some remarks: 1. Could you please remove commented entries in core/src/test/resources/testpersistence.xml? I also find the name of this file (given its purpose) quite confusing. 2. There is still some Activity (instead of Activiti) referenced in ContentLoader 3. There are some FindBugs warnings about not being able to correctly clean up InputStream in ContentLoader 4. (Not included in this patch but somewhere before) there are some redundant public abstract in interface methods (AccountPolicyEnforcer, for example) 5. I don't like much the idea of adding interface / implementation (UserSuspender / WorkflowUserSuspender) for a very specific non-functional need like as in this case. As you pointed out, this is just used in AccountPolicyEnforcerImpl, so why don't you just consolidate this in there? 6. Given the refactory for SpringContextInitializer, for uniformity purpose I would rename WorkflowLoader to WorkflowInstanceLoader and WorkflowSetup to WorkflowLoader (including loadWorkflowAdapters() to load()) Thanks. Move persistence and persistence impl into separate modules --- Key: SYNCOPE-241 URL: https://issues.apache.org/jira/browse/SYNCOPE-241 Project: Syncope Issue Type: Improvement Components: core Affects Versions: 1.0.3-incubating Reporter: Christian Schneider Fix For: 1.1.0 Attachments: SYNCOPE-241-2.patch, SYNCOPE-241-3.patch, SYNCOPE-241-4.patch, SYNCOPE-241.patch The core module currently contains many parts of syncope. This makes it bigger and more complex than necessary. A possible modularization is to move the internal model (org.apache.syncope.core.persistence*) and the persistence impl (org.apache.syncope.core.persistence.impl) out of core and into separate modules. One big advantage would be that the jpa code enhancements would then run in the model module only. Currently we run into some problems in the cxf migration when running the rest itests in core that may be caused by eclipse overwriting the enhanced classes with plain classes. If the model (peristence) classes are in a separate module we could leave it out of eclipse and so this would be no issue anymore. Another advantage would be that the persistence tests could run in the persistence impl module so when working on the core they would not have to run each time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SYNCOPE-272) During sync null attributes from template are considered
[ https://issues.apache.org/jira/browse/SYNCOPE-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated SYNCOPE-272: --- Summary: During sync null attributes from template are considered (was: Apache Syncope updates all attributes from an user) During sync null attributes from template are considered Key: SYNCOPE-272 URL: https://issues.apache.org/jira/browse/SYNCOPE-272 Project: Syncope Issue Type: Bug Components: core Affects Versions: 1.0.5 Reporter: Marco Di Sabatino Di Diodoro Assignee: Marco Di Sabatino Di Diodoro Fix For: 1.0.5, 1.1.0 Attachments: testissueSYNCOPE272.patch During synchronization task, Apache Syncope updates all attributes from an user, specially the attributes that come from the synched resource and the calculed attributes(JEXL) of the user template. If an attribute is not present in the schema mapping of the synched resource, but is present in the user template with null value, Apache Syncope clear the attribute value. If an attribute of the user template is not valued, it must not be considered. I attach a test for solve this issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SYNCOPE-272) During sync null attributes from template are considered
[ https://issues.apache.org/jira/browse/SYNCOPE-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated SYNCOPE-272: --- Description: During execution of synchronization tasks, all user attributes are considered for update, with values coming from the syncing resource and from evaluated JEXL properties in the user template. If an attribute is not present in the schema mapping of the syncing resource but is present in the user template with null value, the value is cleared and the attribute removed. This is not correct: if an attribute of the user template has no value, it must not be considered. A test for proving this issue is attached. was: During synchronization task, Apache Syncope updates all attributes from an user, specially the attributes that come from the synched resource and the calculed attributes(JEXL) of the user template. If an attribute is not present in the schema mapping of the synched resource, but is present in the user template with null value, Apache Syncope clear the attribute value. If an attribute of the user template is not valued, it must not be considered. I attach a test for solve this issue. During sync null attributes from template are considered Key: SYNCOPE-272 URL: https://issues.apache.org/jira/browse/SYNCOPE-272 Project: Syncope Issue Type: Bug Components: core Affects Versions: 1.0.5 Reporter: Marco Di Sabatino Di Diodoro Assignee: Marco Di Sabatino Di Diodoro Fix For: 1.0.5, 1.1.0 Attachments: testissueSYNCOPE272.patch During execution of synchronization tasks, all user attributes are considered for update, with values coming from the syncing resource and from evaluated JEXL properties in the user template. If an attribute is not present in the schema mapping of the syncing resource but is present in the user template with null value, the value is cleared and the attribute removed. This is not correct: if an attribute of the user template has no value, it must not be considered. A test for proving this issue is attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SYNCOPE-241) Move persistence and persistence impl into separate modules
[ https://issues.apache.org/jira/browse/SYNCOPE-241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13552534#comment-13552534 ] Christian Schneider commented on SYNCOPE-241: - 1. I removed the commented out entries. I chose the name as the context is there for the persistence tests. Do you have a better idea how to name it? 2. Removed these 3. I checked the code of loadXml and indeed there are cases where it does not close the inputStream. I added safe close calls to all occurences 4. I removed the ones I found 5. I removed the interfaces for PasswordPolicyEnforcer and AccountPolicyEnforcer as they were indeed only used there. You proposed to consolidate the implementation in AccountPolicyEnforcerImpl. I think this is not possible as the implementation uses classes outside the persistence packages I prepared. Of course we could add these packages but then we would soon end with the whole core in there 6. Renamed the classes Move persistence and persistence impl into separate modules --- Key: SYNCOPE-241 URL: https://issues.apache.org/jira/browse/SYNCOPE-241 Project: Syncope Issue Type: Improvement Components: core Affects Versions: 1.0.3-incubating Reporter: Christian Schneider Fix For: 1.1.0 Attachments: SYNCOPE-241-2.patch, SYNCOPE-241-3.patch, SYNCOPE-241-4.patch, SYNCOPE-241.patch The core module currently contains many parts of syncope. This makes it bigger and more complex than necessary. A possible modularization is to move the internal model (org.apache.syncope.core.persistence*) and the persistence impl (org.apache.syncope.core.persistence.impl) out of core and into separate modules. One big advantage would be that the jpa code enhancements would then run in the model module only. Currently we run into some problems in the cxf migration when running the rest itests in core that may be caused by eclipse overwriting the enhanced classes with plain classes. If the model (peristence) classes are in a separate module we could leave it out of eclipse and so this would be no issue anymore. Another advantage would be that the persistence tests could run in the persistence impl module so when working on the core they would not have to run each time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SYNCOPE-273) Role deletion inhibit existing notifications updates
Denis Signoretto created SYNCOPE-273: Summary: Role deletion inhibit existing notifications updates Key: SYNCOPE-273 URL: https://issues.apache.org/jira/browse/SYNCOPE-273 Project: Syncope Issue Type: Bug Components: console Affects Versions: 1.0.4 Reporter: Denis Signoretto Step to reproduce the bug: 1) Create a new role 2) Create a new notification that use previously created role as membership relation in About recipients 3) Save notification 4) Drop the role 5) Try to edit notification assigning a new role 6) Save notification 7) Edit notification again: previously assigned role in step 5 it's not reported as current assigned role -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SYNCOPE-273) Role deletion inhibit existing notification updates
[ https://issues.apache.org/jira/browse/SYNCOPE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Signoretto updated SYNCOPE-273: - Summary: Role deletion inhibit existing notification updates (was: Role deletion inhibit existing notifications updates) Role deletion inhibit existing notification updates --- Key: SYNCOPE-273 URL: https://issues.apache.org/jira/browse/SYNCOPE-273 Project: Syncope Issue Type: Bug Components: console Affects Versions: 1.0.4 Reporter: Denis Signoretto Step to reproduce the bug: 1) Create a new role 2) Create a new notification that use previously created role as membership relation in About recipients 3) Save notification 4) Drop the role 5) Try to edit notification assigning a new role 6) Save notification 7) Edit notification again: previously assigned role in step 5 it's not reported as current assigned role -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SYNCOPE-241) Move persistence and persistence impl into separate modules
[ https://issues.apache.org/jira/browse/SYNCOPE-241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13552553#comment-13552553 ] Francesco Chicchiriccò commented on SYNCOPE-241: About (1), commented beans are still there (in SYNCOPE-241-5.patch). Anyway, what about renaming it to persistenceTestEnv.xml? About (5), I understand that my proposal is not effective given your purpose; please find an alternative avoiding to add single-purpose interface / implementation. Move persistence and persistence impl into separate modules --- Key: SYNCOPE-241 URL: https://issues.apache.org/jira/browse/SYNCOPE-241 Project: Syncope Issue Type: Improvement Components: core Affects Versions: 1.0.3-incubating Reporter: Christian Schneider Fix For: 1.1.0 Attachments: SYNCOPE-241-2.patch, SYNCOPE-241-3.patch, SYNCOPE-241-4.patch, SYNCOPE-241-5.patch, SYNCOPE-241.patch The core module currently contains many parts of syncope. This makes it bigger and more complex than necessary. A possible modularization is to move the internal model (org.apache.syncope.core.persistence*) and the persistence impl (org.apache.syncope.core.persistence.impl) out of core and into separate modules. One big advantage would be that the jpa code enhancements would then run in the model module only. Currently we run into some problems in the cxf migration when running the rest itests in core that may be caused by eclipse overwriting the enhanced classes with plain classes. If the model (peristence) classes are in a separate module we could leave it out of eclipse and so this would be no issue anymore. Another advantage would be that the persistence tests could run in the persistence impl module so when working on the core they would not have to run each time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
R: Little console usability refactoring proposal
-Messaggio originale- Da: Fabio Martelli [mailto:fabio.marte...@gmail.com] Inviato: giovedì 10 gennaio 2013 18:34 A: dev@syncope.apache.org Oggetto: Re: Little console usability refactoring proposal Il giorno 10/gen/2013, alle ore 17.42, Denis Signoretto ha scritto: Hi Syncopers, After using Syncope console for a while, IMHO, I would like to propose a little refactor. Under the Task tab there are 4 sub tabs. Propagation Task and Notification task are similar and show related executed jobs occured. Synchronization Task and Scheduled Task have a different usability approach. Their main function it's for new Synchronization and Scheduled Task creation while jobs execution it's hidden under edit icon. I would like to propose a refactor where all (Propagation | Notification | Synchronization | Scheduled) task show the executed jobs moving Synchronization and Scheduled Task creation under Configuration (like notification). If under Configuration ther's no space left for all tabs, a common main Policies tab could be created to group (password | account | synchronization) policies. Hi Denis, I don't like so much this refactoring. I'd prefer to maintain tasks all together. But this is just my personal opinion. Hi Fabio, I agree and I can understand your point of view. At the moment I'll just limit to expose my personal thoughs (base on my experience) that I can summaryze in: - Propagation and Notification tasks show the execute jobs. I could be useful to have respectively the possibility to filter by specific Resource or Notification - Synchronization and Scheduled tasks requires 4 clicks to get the list of executed task (tasks - synch tasks - edit - executions) I'm realizing the solution it's probably not a little refactory... :) Regards. Denis Regards, F. http://www.intesys.it/firme/logo_intesys.jpg Denis Signoretto | Senior Project Manager Intesys - Via Roveggia 122 A - 37136 Verona Tel. 045 503663 | Fax 045 503604 denis.signore...@intesys.it www.intesys.it http://www.intesys.it/ Le informazioni contenute nella presente e-mail e nei suoi allegati potrebbero essere confidenziali/riservate e sono dirette unicamente ai destinatari sopra indicati. In caso di ricezione da parte di persona diversa è vietato qualunque tipo di divulgazione o copia anche parziale. Chi riceva questo messaggio per errore è pregato di inoltrarlo al mittente e di cancellare questa e-mail. This e-mail and its attachments may contain confidential/reserved information and is intended only for the use of the address(es) named above. If the reader of this message is not the intended recipient of this message, please note that distribution or copying of this communication is forbidden. Anyone who receives this communication in error should return it immediately to the sender and delete the message.
[jira] [Resolved] (SYNCOPE-272) During sync null attributes from template are considered
[ https://issues.apache.org/jira/browse/SYNCOPE-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Di Sabatino Di Diodoro resolved SYNCOPE-272. -- Resolution: Fixed http://svn.apache.org/viewvc?rev=1432929view=rev During sync null attributes from template are considered Key: SYNCOPE-272 URL: https://issues.apache.org/jira/browse/SYNCOPE-272 Project: Syncope Issue Type: Bug Components: core Affects Versions: 1.0.5 Reporter: Marco Di Sabatino Di Diodoro Assignee: Marco Di Sabatino Di Diodoro Fix For: 1.0.5 Attachments: testissueSYNCOPE272.patch During execution of synchronization tasks, all user attributes are considered for update, with values coming from the syncing resource and from evaluated JEXL properties in the user template. If an attribute is not present in the schema mapping of the syncing resource but is present in the user template with null value, the value is cleared and the attribute removed. This is not correct: if an attribute of the user template has no value, it must not be considered. A test for proving this issue is attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
New member
Hi all together. I'm Christian Schmuelling, working for Talend and I'll support the team for the cxf implementation. @Francesco Could you please grant me access to developers part in the wiki? With best regards Christian
[jira] [Resolved] (SYNCOPE-172) Role propagation / synchronization
[ https://issues.apache.org/jira/browse/SYNCOPE-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò resolved SYNCOPE-172. Resolution: Fixed http://svn.apache.org/viewvc?rev=1432990view=rev Role propagation / synchronization -- Key: SYNCOPE-172 URL: https://issues.apache.org/jira/browse/SYNCOPE-172 Project: Syncope Issue Type: Sub-task Reporter: Francesco Chicchiriccò Assignee: Francesco Chicchiriccò Fix For: 1.1.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SYNCOPE-241) Move persistence and persistence impl into separate modules
[ https://issues.apache.org/jira/browse/SYNCOPE-241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13552885#comment-13552885 ] Francesco Chicchiriccò commented on SYNCOPE-241: Christian, if you are absolutely sure that there is no better solution for the moment... Move persistence and persistence impl into separate modules --- Key: SYNCOPE-241 URL: https://issues.apache.org/jira/browse/SYNCOPE-241 Project: Syncope Issue Type: Improvement Components: core Affects Versions: 1.0.3-incubating Reporter: Christian Schneider Fix For: 1.1.0 Attachments: SYNCOPE-241-2.patch, SYNCOPE-241-3.patch, SYNCOPE-241-4.patch, SYNCOPE-241-5.patch, SYNCOPE-241.patch The core module currently contains many parts of syncope. This makes it bigger and more complex than necessary. A possible modularization is to move the internal model (org.apache.syncope.core.persistence*) and the persistence impl (org.apache.syncope.core.persistence.impl) out of core and into separate modules. One big advantage would be that the jpa code enhancements would then run in the model module only. Currently we run into some problems in the cxf migration when running the rest itests in core that may be caused by eclipse overwriting the enhanced classes with plain classes. If the model (peristence) classes are in a separate module we could leave it out of eclipse and so this would be no issue anymore. Another advantage would be that the persistence tests could run in the persistence impl module so when working on the core they would not have to run each time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SYNCOPE-273) Role deletion inhibits notification update
[ https://issues.apache.org/jira/browse/SYNCOPE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated SYNCOPE-273: --- Summary: Role deletion inhibits notification update (was: Role deletion inhibit existing notification updates) Role deletion inhibits notification update -- Key: SYNCOPE-273 URL: https://issues.apache.org/jira/browse/SYNCOPE-273 Project: Syncope Issue Type: Bug Components: console Affects Versions: 1.0.4 Reporter: Denis Signoretto Fix For: 1.0.5, 1.1.0 Step to reproduce the bug: 1) Create a new role 2) Create a new notification that use previously created role as membership relation in About recipients 3) Save notification 4) Drop the role 5) Try to edit notification assigning a new role 6) Save notification 7) Edit notification again: previously assigned role in step 5 it's not reported as current assigned role -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (SYNCOPE-273) Role deletion inhibits notification update
[ https://issues.apache.org/jira/browse/SYNCOPE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò reassigned SYNCOPE-273: -- Assignee: Francesco Chicchiriccò Role deletion inhibits notification update -- Key: SYNCOPE-273 URL: https://issues.apache.org/jira/browse/SYNCOPE-273 Project: Syncope Issue Type: Bug Components: console Affects Versions: 1.0.4 Reporter: Denis Signoretto Assignee: Francesco Chicchiriccò Fix For: 1.0.5, 1.1.0 Step to reproduce the bug: 1) Create a new role 2) Create a new notification that use previously created role as membership relation in About recipients 3) Save notification 4) Drop the role 5) Try to edit notification assigning a new role 6) Save notification 7) Edit notification again: previously assigned role in step 5 it's not reported as current assigned role -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
