Re: setting up one-to-many relation for LDAP, result in Exception when fetching

Gustavo Adolfo Pizano Mon, 11 May 2009 06:05:41 -0700

Hello Dave.

This are the results, Im trying the get all the XWSContacts from the XWSContactsGroup called GOEN

{\rtf1\ansi\ansicpg1252\cocoartf949\cocoasubrtf430
{\fonttbl\f0\fnil\fcharset0 Monaco;}
{\colortbl;\red255\green255\blue255;}
\paperw11900\paperh16840\margl1440\margr1440\vieww20520\viewh16900\viewkind0
\deftab720
\pard\pardeftab720


\f0\fs22 \cf0 => access_allowed: search access to "cn=887-Goen,cn=GOEN,cn=Contacts,o=xws" "objectClass" requested\
<= root access granted\
<= test_filter 6\
<= test_filter_and 6\
<= test_filter 6\
=> send_search_entry: conn 100 dn="cn=887-Goen,cn=GOEN,cn=Contacts,o=xws"\
=> access_allowed: read access to "cn=887-Goen,cn=GOEN,cn=Contacts,o=xws" "entry" requested\
<= root access granted\
=> access_allowed: read access to "cn=887-Goen,cn=GOEN,cn=Contacts,o=xws" "cn" requested\
<= root access granted\
=> access_allowed: read access to "cn=887-Goen,cn=GOEN,cn=Contacts,o=xws" "companyName" requested\
<= root access granted\
=> access_allowed: read access to "cn=887-Goen,cn=GOEN,cn=Contacts,o=xws" "contactMode" requested\
<= root access granted\
=> access_allowed: read access to "cn=887-Goen,cn=GOEN,cn=Contacts,o=xws" "contactStatus" requested\
<= root access granted\
=> access_allowed: read access to "cn=887-Goen,cn=GOEN,cn=Contacts,o=xws" "objectClass" requested\
<= root access granted\
ber_flush: 224 bytes to sd 15\
  0000:  30 81 dd 02 01 02 64 81  d7 04 25 63 6e 3d 38 38   0.....d...%cn=88  \
  0010:  37 2d 47 6f 65 6e 2c 63  6e 3d 47 4f 45 4e 2c 63   7-Goen,cn=GOEN,c  \
  0020:  6e 3d 43 6f 6e 74 61 63  74 73 2c 6f 3d 78 77 73   n=Contacts,o=xws  \
  0030:  30 81 ad 30 10 04 02 63  6e 31 0a 04 08 38 38 37   0..0...cn1...887  \
  0040:  2d 47 6f 65 6e 30 15 04  0b 63 6f 6d 70 61 6e 79   -Goen0...company  \
  0050:  4e 61 6d 65 31 06 04 04  47 6f 65 6e 30 18 04 0b   Name1...Goen0...  \
  0060:  63 6f 6e 74 61 63 74 4d  6f 64 65 31 09 04 07 43   contactMode1...C  \
  0070:  6f 6d 70 61 6e 79 30 19  04 0d 63 6f 6e 74 61 63   ompany0...contac  \
  0080:  74 53 74 61 74 75 73 31  08 04 06 41 63 74 69 76   tStatus1...Activ  \
  0090:  65 30 4d 04 0b 6f 62 6a  65 63 74 43 6c 61 73 73   e0M..objectClass  \
  00a0:  31 3e 04 0a 78 77 73 43  6f 6e 74 61 63 74 04 0d   1>..xwsContact..  \
  00b0:  69 6e 65 74 4f 72 67 50  65 72 73 6f 6e 04 14 6f   inetOrgPerson..o  \
  00c0:  72 67 61 6e 69 7a 61 74  69 6f 6e 61 6c 50 65 72   rganizationalPer  \
  00d0:  73 6f 6e 04 06 70 65 72  73 6f 6e 04 03 74 6f 70   son..person..top  \
ldap_write: want=224, written=224\
  0000:  30 81 dd 02 01 02 64 81  d7 04 25 63 6e 3d 38 38   0.....d...%cn=88  \
  0010:  37 2d 47 6f 65 6e 2c 63  6e 3d 47 4f 45 4e 2c 63   7-Goen,cn=GOEN,c  \
  0020:  6e 3d 43 6f 6e 74 61 63  74 73 2c 6f 3d 78 77 73   n=Contacts,o=xws  \
  0030:  30 81 ad 30 10 04 02 63  6e 31 0a 04 08 38 38 37   0..0...cn1...887  \
  0040:  2d 47 6f 65 6e 30 15 04  0b 63 6f 6d 70 61 6e 79   -Goen0...company  \
  0050:  4e 61 6d 65 31 06 04 04  47 6f 65 6e 30 18 04 0b   Name1...Goen0...  \
  0060:  63 6f 6e 74 61 63 74 4d  6f 64 65 31 09 04 07 43   contactMode1...C  \
  0070:  6f 6d 70 61 6e 79 30 19  04 0d 63 6f 6e 74 61 63   ompany0...contac  \
  0080:  74 53 74 61 74 75 73 31  08 04 06 41 63 74 69 76   tStatus1...Activ  \
  0090:  65 30 4d 04 0b 6f 62 6a  65 63 74 43 6c 61 73 73   e0M..objectClass  \
  00a0:  31 3e 04 0a 78 77 73 43  6f 6e 74 61 63 74 04 0d   1>..xwsContact..  \
  00b0:  69 6e 65 74 4f 72 67 50  65 72 73 6f 6e 04 14 6f   inetOrgPerson..o  \
  00c0:  72 67 61 6e 69 7a 61 74  69 6f 6e 61 6c 50 65 72   rganizationalPer  \
  00d0:  73 6f 6e 04 06 70 65 72  73 6f 6e 04 03 74 6f 70   son..person..top  \
conn=100 op=1 ENTRY dn="cn=887-goen,cn=goen,cn=contacts,o=xws"\
<= send_search_entry: conn 100 exit.\
=> test_filter\
    AND\
=> test_filter_and\
=> test_filter\
    EQUALITY\
=> access_allowed: search access to "cn=28-Korfalt,cn=GOEN,cn=Contacts,o=xws" "objectClass" requested\
<= root access granted\
<= test_filter 6\
<= test_filter_and 6\
<= test_filter 6\
=> send_search_entry: conn 100 dn="cn=28-Korfalt,cn=GOEN,cn=Contacts,o=xws"\
=> access_allowed: read access to "cn=28-Korfalt,cn=GOEN,cn=Contacts,o=xws" "entry" requested\
<= root access granted\
=> access_allowed: read access to "cn=28-Korfalt,cn=GOEN,cn=Contacts,o=xws" "contactStatus" requested\
<= root access granted\
=> access_allowed: read access to "cn=28-Korfalt,cn=GOEN,cn=Contacts,o=xws" "objectClass" requested\
<= root access granted\
=> access_allowed: read access to "cn=28-Korfalt,cn=GOEN,cn=Contacts,o=xws" "givenName" requested\
<= root access granted\
=> access_allowed: read access to "cn=28-Korfalt,cn=GOEN,cn=Contacts,o=xws" "contactMode" requested\
<= root access granted\
=> access_allowed: read access to "cn=28-Korfalt,cn=GOEN,cn=Contacts,o=xws" "sn" requested\
<= root access granted\
=> access_allowed: read access to "cn=28-Korfalt,cn=GOEN,cn=Contacts,o=xws" "companyName" requested\
<= root access granted\
=> access_allowed: read access to "cn=28-Korfalt,cn=GOEN,cn=Contacts,o=xws" "cn" requested\
<= root access granted\
ber_flush: 282 bytes to sd 15\
  0000:  30 82 01 16 02 01 02 64  82 01 0f 04 27 63 6e 3d   0......d....'cn=  \
  0010:  32 38 2d 4b 6f 72 66 61  6c 74 2c 63 6e 3d 47 4f   28-Korfalt,cn=GO  \
  0020:  45 4e 2c 63 6e 3d 43 6f  6e 74 61 63 74 73 2c 6f   EN,cn=Contacts,o  \
  0030:  3d 78 77 73 30 81 e3 30  19 04 0d 63 6f 6e 74 61   =xws0..0...conta  \
  0040:  63 74 53 74 61 74 75 73  31 08 04 06 41 63 74 69   ctStatus1...Acti  \
  0050:  76 65 30 4d 04 0b 6f 62  6a 65 63 74 43 6c 61 73   ve0M..objectClas  \
  0060:  73 31 3e 04 0a 78 77 73  43 6f 6e 74 61 63 74 04   s1>..xwsContact.  \
  0070:  0d 69 6e 65 74 4f 72 67  50 65 72 73 6f 6e 04 14   .inetOrgPerson..  \
  0080:  6f 72 67 61 6e 69 7a 61  74 69 6f 6e 61 6c 50 65   organizationalPe  \
  0090:  72 73 6f 6e 04 06 70 65  72 73 6f 6e 04 03 74 6f   rson..person..to  \
  00a0:  70 30 15 04 09 67 69 76  65 6e 4e 61 6d 65 31 08   p0...givenName1.  \
  00b0:  04 06 4d 61 72 74 69 6e  30 17 04 0b 63 6f 6e 74   ..Martin0...cont  \
  00c0:  61 63 74 4d 6f 64 65 31  08 04 06 50 65 72 73 6f   actMode1...Perso  \
  00d0:  6e 30 0f 04 02 73 6e 31  09 04 07 4b 6f 72 66 61   n0...sn1...Korfa  \
  00e0:  6c 74 30 22 04 0b 63 6f  6d 70 61 6e 79 4e 61 6d   lt0"..companyNam  \
  00f0:  65 31 13 04 11 44 69 74  61 6c 20 53 74 61 76 20   e1...Dital Stav   \
  0100:  73 2e 72 2e 6f 2e 30 12  04 02 63 6e 31 0c 04 0a   s.r.o.0...cn1...  \
  0110:  32 38 2d 4b 6f 72 66 61  6c 74                     28-Korfalt        \
ldap_write: want=282, written=282\
  0000:  30 82 01 16 02 01 02 64  82 01 0f 04 27 63 6e 3d   0......d....'cn=  \
  0010:  32 38 2d 4b 6f 72 66 61  6c 74 2c 63 6e 3d 47 4f   28-Korfalt,cn=GO  \
  0020:  45 4e 2c 63 6e 3d 43 6f  6e 74 61 63 74 73 2c 6f   EN,cn=Contacts,o  \
  0030:  3d 78 77 73 30 81 e3 30  19 04 0d 63 6f 6e 74 61   =xws0..0...conta  \
  0040:  63 74 53 74 61 74 75 73  31 08 04 06 41 63 74 69   ctStatus1...Acti  \
  0050:  76 65 30 4d 04 0b 6f 62  6a 65 63 74 43 6c 61 73   ve0M..objectClas  \
  0060:  73 31 3e 04 0a 78 77 73  43 6f 6e 74 61 63 74 04   s1>..xwsContact.  \
  0070:  0d 69 6e 65 74 4f 72 67  50 65 72 73 6f 6e 04 14   .inetOrgPerson..  \
  0080:  6f 72 67 61 6e 69 7a 61  74 69 6f 6e 61 6c 50 65   organizationalPe  \
  0090:  72 73 6f 6e 04 06 70 65  72 73 6f 6e 04 03 74 6f   rson..person..to  \
  00a0:  70 30 15 04 09 67 69 76  65 6e 4e 61 6d 65 31 08   p0...givenName1.  \
  00b0:  04 06 4d 61 72 74 69 6e  30 17 04 0b 63 6f 6e 74   ..Martin0...cont  \
  00c0:  61 63 74 4d 6f 64 65 31  08 04 06 50 65 72 73 6f   actMode1...Perso  \
  00d0:  6e 30 0f 04 02 73 6e 31  09 04 07 4b 6f 72 66 61   n0...sn1...Korfa  \
  00e0:  6c 74 30 22 04 0b 63 6f  6d 70 61 6e 79 4e 61 6d   lt0"..companyNam  \
  00f0:  65 31 13 04 11 44 69 74  61 6c 20 53 74 61 76 20   e1...Dital Stav   \
  0100:  73 2e 72 2e 6f 2e 30 12  04 02 63 6e 31 0c 04 0a   s.r.o.0...cn1...  \
  0110:  32 38 2d 4b 6f 72 66 61  6c 74                     28-Korfalt        \
conn=100 op=1 ENTRY dn="cn=28-korfalt,cn=goen,cn=contacts,o=xws"\
<= send_search_entry: conn 100 exit.\
send_ldap_result: conn=100 op=1 p=3\
send_ldap_result: err=0 matched="" text=""\
send_ldap_response: msgid=2 tag=101 err=0\
ber_flush: 14 bytes to sd 15\
  0000:  30 0c 02 01 02 65 07 0a  01 00 04 00 04 00         0....e........    \
ldap_write: want=14, written=14\
  0000:  30 0c 02 01 02 65 07 0a  01 00 04 00 04 00         0....e........    \
conn=100 op=1 SEARCH RESULT tag=101 err=0 nentries=2 text=\
daemon: activity on 1 descriptor\
}

Im not LDAP guy also, my boss is, he checked those results and said that form the LDAP side the response is going good, the server is returning good the information.

Also, since I'm not an LDAP guy, what exactly is in the cn attribute? Is it the user's name or what? What other attributes are available? What do you get if you iterate over the dn attribute of the Contacts?

cn is the common name, which is unique.

doing a .toString(). gives me this...

<xws.app.components.eo.XWSContact pk:"cn=GOEN,cn=Contacts">

which is the part after each cn of th XWSContacts..

example.

XWS

-Contacts (cn=Contacts) : rdn: cn=Contacts / dn: cn=Contacts,o=xws

-GOEN(cn=GOEN) rdn :cn=GOEN, cn=Contacts / dn: cn=GOEN, cn=Contacts,o=xws

-28-Korfalt (cn= 28-Korfalt) rdn: cn= 28-Korfalt,cn=Contacts / dn: cn= 28-Korfalt,cn=Contacts,o=xws

-887-Goen (cn=887 Goen)

my base is o=xws..

well as I said Im not a LDAP guy also but so far this is what I understand form reading the doc of the JDNI adaptor for WO

Any Ideas??? what might be happening?

Gustavo

On May 11, 2009, at 2:42 PM, David Avendasora wrote:

On May 11, 2009, at 8:21 AM, Gustavo Adolfo Pizano wrote:

UPDATE:

I have checked the console of LDAP, and in fact its returning all the results, but something interesting is that the first return result is the one that Im getting n-times.

Can you paste those results here?

Also, since I'm not an LDAP guy, what exactly is in the cn attribute? Is it the user's name or what? What other attributes are available? What do you get if you iterate over the dn attribute of the Contacts?

What if you just log the contact.toSring() instead of contact.cn() ? That should show you if you are _really_ getting the same EO over and over again.

Dave

so somehow EOF or JNDI plugin is ignoring the other results.

:S

now im lost. :S :(

Gustavo

On May 11, 2009, at 2:11 PM, Gustavo Adolfo Pizano wrote:

Hello Dave.

I tried with XWSContactsGroups and had the same results, Im gonna try to be more clear of what Im doing:

There must be something in the WSContacts already that refers back to the XWSContactGroup. You should use that existing attribute as the FK.
There is no such an attribute in the LDAP server for XWSContact, or XWSContactsGroup.
all turns around the DN. after reading the documentation of the JNDI plugin for webobjects, it says that the relativeDistinguishName (rdn) is a attribute that acts as a PK (comparing to a SQL server) but this is a string and its not auto-generated(there is a work around). so ie.

XWSContactsGroup DN's

cn=Apple,cn=Contacts,o=xws

Apple is a XWSContactGroup, the rdn is cn=Apple,cn=Contacts and the base search is o=xws.

with the qualifier I created I specify (correct me if Im wrong),

qqual = new ERXKeyValueQualifier(XWSContactsGroup.RELATIVE_DISTINGUISHED_NAME_KEY,
EOQualifier.QualifierOperatorContains,"cn=Contacts");

NSArray<XWSContactsGroup> gl = XWSContactsGroup.fetchXWSContactsGroups(ec, qqual,
new NSArray(new Object[]{ EOSortOrdering.sortOrderingWithKey(XWSContactsGroup.CN_KEY, EOSortOrdering.CompareAscending)}));

I want all the XWSContactsGroup that are inside the XWSContactGroup with rdn: Contacts, including this last one (which is the parent group)

and when I want to check the cn of wach object in the array, well, I get n-times the cn of one of the XWSContactGroup.

So, you are getting the number of records you'd expect, but they are all same XWSContact? That sounds extremely odd. What data are you expecting to be in the "cn" attribute of the XWSContact?

the cn attribute is the current name of that element.

IT IS ODD. why should I get the right number of elements but all the same elements.

I have tried doing it trough objectswithfetchspecification, but well it does nothing different, I was doing the same as the _XXX.java class does in int he fetch method.

odd odd odd... dont get it why.

maybe somebody will?...

Gus

On May 11, 2009, at 1:48 PM, David Avendasora wrote:

On May 11, 2009, at 7:10 AM, Gustavo Adolfo Pizano wrote:

Hello David.

Yes in fact I have realized about that.. in the LDAP there is no FK attribute, and I can't modify the schema, so I need to come with something.

There must be something in the WSContacts already that refers back to the XWSContactGroup. You should use that existing attribute as the FK.

I have done the following to fetch all XWSContacts in a specific XWSCntacGroup.

EOQualifier qqual = new ERXKeyValueQualifier(XWSContact.RELATIVE_DISTINGUISHED_NAME_KEY,
EOQualifier.QualifierOperatorCaseInsensitiveLike,"cn=Dolis,cn=Contacts");
NSArray<XWSContact> cs= XWSContact.fetchXWSContacts(ec, qqual,null);

What attribute in XWSContatGroup would contain "cn=Dolis,cn=Contacts"?

when I check the size of the NSArray, I see it has 18 elements, which in fact checking the LDAP server it's true...

Okay, so it looks like that should be the FK, why can't you use that then?

BUT!, when I do the following to check the cn of all the XWSContacts :
for(int i =0 ;i < cs.size(); i++)
{
System.out.println(cs.objectAtIndex(i).cn());
}

On a completely side note, here's a much nicer way of doing the for loop (if you are using WO 5.4 or WO 5.3 with WOnder):

for (XWSContact aContact : cs)
{
System.out.println(aContact.cn());
}

I get the follwoing:

7764-Sucharov‡
7764-Sucharov‡
7764-Sucharov‡
7764-Sucharov‡
7764-Sucharov‡
7764-Sucharov‡
7764-Sucharov‡
7764-Sucharov‡
7764-Sucharov‡
7764-Sucharov‡
7764-Sucharov‡
7764-Sucharov‡
7764-Sucharov‡
7764-Sucharov‡
7764-Sucharov‡
7764-Sucharov‡
7764-Sucharov‡
7764-Sucharov‡

which is one of the XWSContact with is inside the group I specify in the Qualifier... I dunno what's wrong with the qualifier.. :S

So, you are getting the number of records you'd expect, but they are all same XWSContact? That sounds extremely odd. What data are you expecting to be in the "cn" attribute of the XWSContact?

Dave

Any clue?

Gustavo

On May 11, 2009, at 12:52 PM, David Avendasora wrote:

Hi Gustavo,

I have never done any LDAP stuff, but I see a couple things that don't sound or look quite right. Maybe they are, but I figure it can't hurt to make some observations. See below:

On May 11, 2009, at 4:38 AM, Gustavo Adolfo Pizano wrote:

Hello again, and sorry for disturbing so much, but this topic is giving me a headache due that is first time I work with LDAP and not an WO/EOF expert.

I have two Entity (reversed engineered form the LDAP server) called XWSContactsGroup and XWSContact.

XWSContactgroup can have more XWSContactsGroup ObjClass inside and XWSContact also. so it will look like.

-XWS (root)
-Contacts (XWSContactsGroup)

-Apple.(XWSContactsGroup)
-Gustavo Pizano

-XWS(XWSContactsGroup)
-Veronica Pizano
-Carolina Pizano

-PhotoCenter(XWSContactsGroup)
-Gilbert Pizano
etc.

When I try to set the relations in EOModeler, I just did it as I normally did with a SQL server, it palced a FK called XWSContactsGroupID and the respectively relationships.

Are you saying that when you added the relationship in Entity Modeler, it added a FK attribute that is not actually in the LDAP server? Entity Modeler gives you the option to specify what the PK and FK are maually, and if you don't it can create new ones. I don't think you want it creating new ones. Go back to Entity Modeler and select the relationship and make sure the source and destination attributes of the relationship are the correct attributes - the same ones that the LDAP server will use to join the records together.

When I do the fetch of one XWSContactsGroup, let say i.e , and I try to get what it has inside, in this case more XWSContactsGroup, I get hte following exception. :
com.webobjects.jndiadaptor.JNDIAdaptorException: Cannot get type with name relativeDistinguishedName for attribute xWSContactsGroupID

Above you say the FK is called "XWSContactsGroupID" and here it's complaining about "xWSContactsGroupID" (note the lowercase "x"). Could that be causing problems?

I checked, and it seems weird to me that, of course the relativeDistinguishedName att (pk) will never be the same,

How can a PK never be the same? Isn't it the identifier of the record in the LDAP record? How can that change without breaking lots of stuff?

Dave

so how can I set up the relationship and against what, to make it work properly?, or should I connect directly to the server avoiding the EOF?

Thanks again,

Gustavo Pizano
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com

This email sent to [email protected]

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to [email protected]

Re: setting up one-to-many relation for LDAP, result in Exception when fetching

Reply via email to