On 14/08/2012 15.28, Colm O hEigeartaigh wrote:
Thanks Francesco! Two queries on the JIRAs:
a) Shouldn't the issues also have "1.1.0-incubating" as the fix-for
version?
Correct (I guess): hence the fix should be committed on the 1_0_X
branch, then merged into the trunk, right?
I'll make the necessary corrections on JIRA.
b) Is SYNCOPE-186 really suitable for a 1.0.1-incubating release
given that it is more of a refactor and not a bug as such?
Hum, you're right: fixing this as well.
Regards.
On Tue, Aug 14, 2012 at 9:45 AM, Francesco Chicchiriccò
<[email protected] <mailto:[email protected]>> wrote:
On 13/08/2012 18.05, Francesco Chicchiriccò wrote:
On 13/08/2012 17.57, Colm O hEigeartaigh wrote:
Hi Francesco,
Thanks for looking into this! The issues sound good to me - will
you open the JIRAs or do you want me to do it?
As you prefer.
Done: SYNCOPE-183 SYNCOPE-184 SYNCOPE-185 SYNCOPE-186 and SYNCOPE-187.
Regards.
Should we also create a JIRA for the fact that the deletion
error is not reported on the users console screen?
Ah, forgot this: of course, this is also to be opened, taking
also care that all the surrounding conditions are reported.
Basic question = Is there an easy way of configuring Syncope
(embedded or otherwise) to launch with no pre-existing
User/Schema/Connectors/Resources/etc. configured, but with all
of the Connectors available? So for example if you just want to
launch Syncope in an embedded mode and add your own schemas
etc., but without having to manually delete all of the existing
schemas/users/etc?
Consider that Syncope performs initialization of its own
repository when the underlying db is found empty (i.e. always in
embedded mode) by loading:
* core/src/test/resources/content.xml (embedded)
* core/src/main/resources/content.xml (real-world)
This means that if you want no
"User/Schema/Connectors/Resources/etc.", you can just play with
the correspondent content.xml in your overlay's sources. This can
be done in a couple of ways:
1. edit the XML source file
2. make all configurations via console and then export the
customized content with Configuration -> Export DB content
Regards.
On Mon, Aug 13, 2012 at 4:27 PM, Francesco Chicchiriccò
<[email protected] <mailto:[email protected]>> wrote:
On 13/08/2012 16.45, Francesco Chicchiriccň wrote:
On 13/08/2012 16.20, Colm O hEigeartaigh wrote:
Done, thanks. Two other related questions re
potential bugs:
1) I created a new user and assigned a (LDAP)
Resource. It propagated successfully + I can see the
new user in the backend resource. However, when I
edit the user in Syncope I see:
Syncope Newuser active icon
Apache DS resource cn=Newuser,ou=users,ou=system
undefined icon
Why does an "undefined icon" appear when the
propagation was successful?
Could you take a look at the propagation task that was
created for this operation (create user on LDAP
resource)? There should be an execution, possibly
reporting an error message.
The "undefined icon" means that the LDAP resource did
not return any status information about that user.
Is your LDAP resource 'propagation primary'? Is
enforcing mandatory constraints?
2) I created a new user and assigned a (LDAP)
Resource. It propagated successfully. However if I
try to delete in the Syncope users console, nothing
happens + no error message appears. Looking at logs
I see:
14:27:10.868 WARN
org.springframework.web.client.RestTemplate - GET
request for
"http://localhost:9080/syncope/rest/user/delete/105";
resulted in 400 (Bad Request); invoking error handler
14:27:10.869 WARN
org.apache.wicket.protocol.http.WebSession -
Component-targetted feedback message was left
unrendered. This could be because you are missing a
FeedbackPanel on the page. Message: [FeedbackMessage
message = "{[Propagation [Apache DS resource]], }",
reporter = listResult, level = ERROR]
When I look at the Core log I see:
SEVERE: Servlet.service() for servlet
[syncope-core-rest] in context with path [/syncope]
threw exception [Request processing failed; nested
exception is
org.apache.syncope.core.propagation.PropagationException:
Exception during provision on resource Apache DS
resource
[LDAP: error code 68 - Attempt to move entry onto
itself.]] with root cause
org.apache.syncope.core.propagation.PropagationException:
Exception during provision on resource Apache DS
resource
[LDAP: error code 68 - Attempt to move entry onto
itself.]
at
org.apache.syncope.core.propagation.PropagationManager.execute(PropagationManager.java:577)
So there are potentially two bugs here:
a) The error is not reported on the Users Console
screen.
This is an error for sure.
b) User deletion does not appear to be working.
I could only delete the user when I removed the
Resource from the user first.
I suspect that there is some issue when creating this
user on LDAP (possibly an incomplete mapping?): are you
running an embedded environment with provided test
configuration or have you defined everything from scratch?
Hi Colm,
I've just tried your procedure above in the embedded
environment and confirmed all you've found.
Summarizing, I would open the following issues (affecting
1.0.1-incubating and 1.1.0-incubating):
1. 'Enforce mandatory constraints' is not working
firstname is mapped to cn with mandatoryCondition == 'true'
on LDAP resource, but Syncope doesn't warn if firstname is
not provided
2. LDAP test connector is not configured for providing
status information
No conf value is provided for LDAP connector's
statusManagementClass
Note: this is not a problem itself, and is also the reason
why you see the 'undefined icon'; anyway, it would be nice
to provide a complete configuration
3. Could not delete an user with LDAP resource
An update operation is issued instead of delete, returning
the following exception:
17:00:11.708 DEBUG
org.identityconnectors.framework.api.operations.UpdateApiOp.update
Exception:
org.identityconnectors.framework.common.exceptions.ConnectorException:
javax.naming.NameAlreadyBoundException: [LDAP: error code 68
- Attempt to move entry onto itself.]; remaining name
'[email protected] <mailto:[email protected]>,ou=people,o=isp'
[...]
4. Build reference flows for propagation and synchronization
The code behind propagation and synchronization layers is
getting bigger and plenty of flow exceptions: a
reorganization - backed by some reference flows to be
summarized as wiki pages - is needed.
WDYT?
--
Francesco Chicchiriccò
ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member
http://people.apache.org/~ilgrosso/
