Announcement Announcement Module
No announcement yet.
Caused by: com.sun.jndi.ldap.LdapCtx Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Caused by: com.sun.jndi.ldap.LdapCtx

    Somehow the LDAP context is getting into flow scope. Anyone seen this before when getting an ldap exception? I'm trying to handle the exception like:

    <transition to="userManagerDetail" on-exception="">
                <set attribute="passwordError" value="'Please try another password.'" scope="flash"/>

  • #2
    Could it be that NamingException.resolvedObj is a reference to something that is not serializable, like LdapCtx for example?
    Last edited by ulsa; Mar 13th, 2007, 01:58 PM.


    • #3
      That was exactly it. I overrode the handle method in my custom class extending TransitionExecutingStateExceptionHandler with:

          public ViewSelection handle( FlowExecutionException e, RequestControlContext context ) {
              Throwable rootCause = findRootCause( e );
              if ( NamingException.class.isAssignableFrom( rootCause.getClass() ) ) {
                  NamingException ne = ( NamingException ) rootCause;
                  ne.setResolvedObj( null );
              return super.handle( e, context );


      • #4
        I have an idea of how to solve this problem in a generic way. I write a custom writeObject(ObjectOutputStream) method for the base exception class in Spring LDAP. In that method, I try to find out whether there is any chance that resolvedObj in the original causing NamingException might be serializable. If not, then I temporarily set resolvedObj to null, call the default serialization, and restore resolvedObj. When the exception is put together on the other side, the resolvedObj reference will be set to null. This way a non-serializable resolvedObj in a NamingException will not break the serialization.

        What scenarios do we have? Well, storing an exception in some kind of web scope seems to be one scenario. Another scenario is remote method calls that fail and send back the exception over the wire. In that case, you really don't want the serialization to fail just because some "helpful" object in NamingException happens to be non-serializable.