• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: mysterious LDAP problem and "why doesn't EOAdaptorDebugEnabled log LDAP too?"
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mysterious LDAP problem and "why doesn't EOAdaptorDebugEnabled log LDAP too?"


  • Subject: Re: mysterious LDAP problem and "why doesn't EOAdaptorDebugEnabled log LDAP too?"
  • From: Benjamin J Doherty <email@hidden>
  • Date: Fri, 14 Oct 2005 15:42:13 -0500

On Oct 14, 2005, at 12:45 PM, Chuck Hill wrote:

I've figured out that the problem lies in the homePostalAddress attribute for this entry. It's not blank for this entry, and other entries where it is blank are saved with no hassle. (The debug.log is locking against (!(homePhone=*))(?=undefined)(! (initials=*)), and homePostalAddress is the only attribute between the two named ones alphabetically. Can anyone give me some ideas of what to twiddle? This is a D2JC application.


I'd check the model for that attribute. Is it missing an external name or is the name not consistent with the LDAP store?

The model was reverse engineered from the LDAP schema by EOModeler, but I checked anyway and it's spelled precisely the same way. EOF will correctly fetch the attribute, so the naming is correct. It just can't save it.


I've done some more experimentation and figured out this. If an entry which does not already have that attribute (homePostalAddress) defined is loaded by EOF, that attribute can be created and saved. No error. However, if I work with an entry that has that attribute, I cannot save it. It doesn't matter whether I change that attribute or not, because EOF wants to use that attribute for locking. However, even if I chose not to use that attribute for locking, I still need to have the power to edit that attribute.

I can change other attributes with impunity. So far, it seems that EOF doesn't like the postalAddress LDAP syntax. That's unfortunate, because lots of great LDAP schemas (inetOrgPerson in my case) have attributes which use that syntax!

uh, that is Adaptor with an -or at the end, not an -er. :-)

I have that correct too. But EOF just doesn't log its LDAP transaction data. Here's the output:


[2005-10-14 15:26:38 CDT] <WorkerThread2> Context factory cache is already clear
[2005-10-14 15:26:38 CDT] <WorkerThread2> Connecting: {plugInClassName = "com.webobjects.jndiadaptor.LDAPPlugIn"; timeout = "3600"; scope = "Subtree"; username = "cn=Manager,dc=dot,dc=org"; authenticationMethod = "Simple"; password = "<omitted from log>"; serverUrl = "ldap://mandela.dot.org/dc=dot,dc=org";; initialContextFactory = "com.sun.jndi.ldap.LdapCtxFactory"; }
[2005-10-14 15:26:38 CDT] <WorkerThread2> Creating plug-in com.webobjects.jndiadaptor.LDAPPlugIn for JNDIAdaptor@1968174
[2005-10-14 15:27:03 CDT] <WorkerThread2> === Begin Internal Transaction
[2005-10-14 15:27:03 CDT] <WorkerThread2> === Rollback Internal Transaction
[2005-10-14 15:27:48 CDT] <WorkerThread2> === Begin Internal Transaction
[2005-10-14 15:27:48 CDT] <WorkerThread2> === Commit Internal Transaction
[2005-10-14 15:29:15 CDT] <WorkerThread2> === Begin Internal Transaction
[2005-10-14 15:29:15 CDT] <WorkerThread2> === Commit Internal Transaction
[2005-10-14 15:29:18 CDT] <WorkerThread2> === Begin Internal Transaction
[2005-10-14 15:29:18 CDT] <WorkerThread2> === Commit Internal Transaction
[2005-10-14 15:29:22 CDT] <WorkerThread2> === Begin Internal Transaction
[2005-10-14 15:29:22 CDT] <WorkerThread2> === Commit Internal Transaction



Attachment: smime.p7s
Description: S/MIME cryptographic signature

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References: 
 >mysterious LDAP problem and "why doesn't EOAdaptorDebugEnabled log LDAP too?" (From: Benjamin J Doherty <email@hidden>)
 >Re: mysterious LDAP problem and "why doesn't EOAdaptorDebugEnabled log LDAP too?" (From: Chuck Hill <email@hidden>)

  • Prev by Date: Re: Redirect from within Session
  • Next by Date: PosgreSQL & NSTimestamp
  • Previous by thread: Re: mysterious LDAP problem and "why doesn't EOAdaptorDebugEnabled log LDAP too?"
  • Next by thread: Re: [solved] mysterious LDAP problem and "why doesn't EOAdaptorDebugEnabled log LDAP too?"
  • Index(es):
    • Date
    • Thread