Announcement Announcement Module
No announcement yet.
OperationNotSupportedException thrown for account expired Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • OperationNotSupportedException thrown for account expired

    Using: spring-ldap 1.2
    Platform: AIX jdk 1.4.2 against Novell eDIR ldap server (I currently do not know what the version is)

    I am using the canLogin() code that has been posted on this forum here.

    When an account has been expired I get a javax.naming.OperationNotSupportedException exception.

    I was wondering if there isn't a more accurate exception for expired accounts?

    If not I was wondering if sping-ldap has such a feature as the core spring framework for mapping SQL errors to an exception hieracy and being able to provide your own error codes in a external mapping file. Or to start with injecting your own mapping strategy.

    Using this I would be able to catch the OperationNotSupportedException and parse the error message and determine that this is an account expired error and throw my own AccountExpired exception.

    BTW: Novell have their error codes listed here:

    My exception:
    FAILED --- User [JCHR0001] account is expired.; nested e
    xception is org.springframework.ldap.OperationNotSupportedExce ption: [LDAP: error code 53 - NDS error: log account expired (-220)]; nested exc
    eption is javax.naming.OperationNotSupportedException: [LDAP: error code 53 - NDS error: log account expired (-220)]|

  • #2
    In previous versions we used to have our own translated exception hierarchy. Later on we figured that the NamingException hierarchy is pretty detailed itself, so we decided to take the approach used in Spring's JMS support: we provide an unchecked mirror of the NamingException hierarchy, keeping the current translation, but allowing the developer to just catch the exceptions he likes.

    So what you'll need to do is catch the OperationNotSupportedException in the canLogin() code, and then rethrow a more appropriate exception if desired.


    • #3
      Thanks for the prompt reply.

      To solve the problem I had to catch the entire OperatinsNotSupportException and return my own kind of exception.

      I was wondering where in the first place if the real caused exception is thrown? Is it the SUN ldapbp.jar that causes this?

      Well what caught me on the wrong foot was that there is a nice exception for Authentication exceptions and I was imagined that a locked or expired account should thrown this kind of exception and not the OperationsNotSupported.

      Also the name OperationsNotSupported got me thinking that it could be because I was using a Novell LDAP server and no specific Novell java client and thus the generic SUN ldap .jar would not support this nicely and therefore just throw a kind of OperationsNotSupported meaning that it's "we do not know the real problem but hey we just throw this one instead". Just as if all the hazzle with the SQLException from the different RDBMS vendors - that Spring now nicely have a mapping/translations for.