You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Icky Dude (JIRA)" <ji...@apache.org> on 2008/03/21 23:47:24 UTC

[jira] Created: (DIRSERVER-1154) Declaration and instantiation of refService in ServerLdapContext limits extensibility

Declaration and instantiation of refService in ServerLdapContext limits extensibility
-------------------------------------------------------------------------------------

                 Key: DIRSERVER-1154
                 URL: https://issues.apache.org/jira/browse/DIRSERVER-1154
             Project: Directory ApacheDS
          Issue Type: Bug
          Components: core
    Affects Versions: bigbang
            Reporter: Icky Dude
             Fix For: bigbang


I ran into a problem that I think needs some simple design work or a simple fix.  For my project is is not necessary to handle referrals, so I decided to simply eliminate the ReferralIntercepter from my InterceptorChain.  As soon as I did this, myDirectoryService started crapping on a NullPointerException buried in the bowels of the DefaultSearchHandler (something I definitely don't want to mess with for my project).

1) At DefaultSearchHandler.java:357 of  there is an instantiation of a new SearchResponseIterator.  
2) The constructor for SearchResponseIterator calls ServerLdapContex.isReferral() at SearchResponseItereator:117
3) ServerLdapContext.isReferral() results in a NPE at ServerLdapContext.java:264 unless your DirectoryService's InterceptorChain includes a ReferralInterceptor.  Take a look at the constructor and you'll see why:

public ServerLdapContext( DirectoryService service, Hashtable<String, Object> env ) throws NamingException
{
    super( service, env );
    refService = ( ( ReferralInterceptor ) service.getInterceptorChain().get( ReferralInterceptor.class.getName() ) );
}

Is there any chance that we can simply Check refService for null before it's used ServerLdapContext.isReferral().  If it's refService==null, return false?

There's also similar a similar problem in PartitionNexusProxy.java:891 and 901.  Here the code checks the chain for null, and returns, but it doesn't check the for null before invoking the interceptor method. 

Here's the patch:

$ svn diff ServerLdapContext.java 
Index: ServerLdapContext.java
===================================================================
--- ServerLdapContext.java      (revision 638966)
+++ ServerLdapContext.java      (working copy)
@@ -261,7 +261,11 @@
      */
     public boolean isReferral( String name ) throws NamingException
     {
-        return refService.isReferral( name );
+       if( refService == null )
+        {
+               return false;
+        }
+       return refService.isReferral( name );
     }
 
     /**
@@ -272,7 +276,11 @@
      */
     public boolean isReferral( LdapDN name ) throws NamingException
     {
-        return refService.isReferral( name );
+        if( refService == null )
+        {
+               return false;
+        }
+       return refService.isReferral( name );


$ svn diff PartitionNexusProxy.java
Index: PartitionNexusProxy.java
===================================================================
--- PartitionNexusProxy.java    (revision 638966)
+++ PartitionNexusProxy.java    (working copy)
@@ -889,6 +889,10 @@
     {
         InterceptorChain chain = service.getInterceptorChain();
         EventInterceptor interceptor = ( EventInterceptor ) chain.get( EventInterceptor.class.getName() );
+        if( interceptor == null )
+        {
+               return;
+        }
         interceptor.addNamingListener( ctx, name, filter, searchControls, namingListener );
     }
 
@@ -901,6 +905,10 @@
             return;
         }
         EventInterceptor interceptor = ( EventInterceptor ) chain.get( EventInterceptor.class.getName() );
+        if( interceptor == null )
+        {
+               return;
+        }
         interceptor.removeNamingListener( ctx, namingListener );
     }
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (DIRSERVER-1154) Declaration and instantiation of refService in ServerLdapContext limits extensibility

Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/DIRSERVER-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581219#action_12581219 ] 

Emmanuel Lecharny commented on DIRSERVER-1154:
----------------------------------------------

I don't think this patch is enough. 

FYI, the way referrals are handled in ADS is far from being perfect, but at least, it's fast. The idea is to avoid a complex checking everytime. We are caching the referral's DN in order to avoid to check the existence of a specific attribute in the entry being manipulated. 

If you want to remove the referral interceptor, you are clearly exposed to NPE just because the ServerLdapContext is using this cache (because it's faster to do so). 

Hre, the main issue is that we are managing this cache within the ReferralInterceptor, while it should be transversal. I don't really like the idea of calling an interceptor's method from outside of this interceptor, as an interceptor is supposed to isolate its code. 

We will add a new cache system soon, and we will delegate such a verification to another subsystem, but this is not exactly a 5 minutes kind of job.

I would suggest that you keep the referral interceptor in place at the moment.



> Declaration and instantiation of refService in ServerLdapContext limits extensibility
> -------------------------------------------------------------------------------------
>
>                 Key: DIRSERVER-1154
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-1154
>             Project: Directory ApacheDS
>          Issue Type: Bug
>          Components: core
>    Affects Versions: bigbang
>            Reporter: Icky Dude
>             Fix For: bigbang
>
>
> I ran into a problem that I think needs some simple design work or a simple fix.  For my project is is not necessary to handle referrals, so I decided to simply eliminate the ReferralIntercepter from my InterceptorChain.  As soon as I did this, myDirectoryService started crapping on a NullPointerException buried in the bowels of the DefaultSearchHandler (something I definitely don't want to mess with for my project).
> 1) At DefaultSearchHandler.java:357 of  there is an instantiation of a new SearchResponseIterator.  
> 2) The constructor for SearchResponseIterator calls ServerLdapContex.isReferral() at SearchResponseItereator:117
> 3) ServerLdapContext.isReferral() results in a NPE at ServerLdapContext.java:264 unless your DirectoryService's InterceptorChain includes a ReferralInterceptor.  Take a look at the constructor and you'll see why:
> public ServerLdapContext( DirectoryService service, Hashtable<String, Object> env ) throws NamingException
> {
>     super( service, env );
>     refService = ( ( ReferralInterceptor ) service.getInterceptorChain().get( ReferralInterceptor.class.getName() ) );
> }
> Is there any chance that we can simply Check refService for null before it's used ServerLdapContext.isReferral().  If it's refService==null, return false?
> There's also similar a similar problem in PartitionNexusProxy.java:891 and 901.  Here the code checks the chain for null, and returns, but it doesn't check the for null before invoking the interceptor method. 
> Here's the patch:
> $ svn diff ServerLdapContext.java 
> Index: ServerLdapContext.java
> ===================================================================
> --- ServerLdapContext.java      (revision 638966)
> +++ ServerLdapContext.java      (working copy)
> @@ -261,7 +261,11 @@
>       */
>      public boolean isReferral( String name ) throws NamingException
>      {
> -        return refService.isReferral( name );
> +       if( refService == null )
> +        {
> +               return false;
> +        }
> +       return refService.isReferral( name );
>      }
>  
>      /**
> @@ -272,7 +276,11 @@
>       */
>      public boolean isReferral( LdapDN name ) throws NamingException
>      {
> -        return refService.isReferral( name );
> +        if( refService == null )
> +        {
> +               return false;
> +        }
> +       return refService.isReferral( name );
> $ svn diff PartitionNexusProxy.java
> Index: PartitionNexusProxy.java
> ===================================================================
> --- PartitionNexusProxy.java    (revision 638966)
> +++ PartitionNexusProxy.java    (working copy)
> @@ -889,6 +889,10 @@
>      {
>          InterceptorChain chain = service.getInterceptorChain();
>          EventInterceptor interceptor = ( EventInterceptor ) chain.get( EventInterceptor.class.getName() );
> +        if( interceptor == null )
> +        {
> +               return;
> +        }
>          interceptor.addNamingListener( ctx, name, filter, searchControls, namingListener );
>      }
>  
> @@ -901,6 +905,10 @@
>              return;
>          }
>          EventInterceptor interceptor = ( EventInterceptor ) chain.get( EventInterceptor.class.getName() );
> +        if( interceptor == null )
> +        {
> +               return;
> +        }
>          interceptor.removeNamingListener( ctx, namingListener );
>      }
>  }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Closed: (DIRSERVER-1154) Declaration and instantiation of refService in ServerLdapContext limits extensibility

Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/DIRSERVER-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alex Karasulu closed DIRSERVER-1154.
------------------------------------

    Resolution: Fixed

This has been removed in the refactoring process to remove JNDI's role in the core.  The core JNDI provider Is just now a wrapper around the DirectoryService but it does not support referrals at all.  The frontend does though.  There is another JIRA issue out there for referral handling in the JNDI provider.  If you use the core provider you'll have to handle referrals yourself since the core provider just treats them as any other entry.

> Declaration and instantiation of refService in ServerLdapContext limits extensibility
> -------------------------------------------------------------------------------------
>
>                 Key: DIRSERVER-1154
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-1154
>             Project: Directory ApacheDS
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.5.4
>            Reporter: Icky Dude
>            Assignee: Alex Karasulu
>             Fix For: 1.5.4
>
>
> I ran into a problem that I think needs some simple design work or a simple fix.  For my project is is not necessary to handle referrals, so I decided to simply eliminate the ReferralIntercepter from my InterceptorChain.  As soon as I did this, myDirectoryService started crapping on a NullPointerException buried in the bowels of the DefaultSearchHandler (something I definitely don't want to mess with for my project).
> 1) At DefaultSearchHandler.java:357 of  there is an instantiation of a new SearchResponseIterator.  
> 2) The constructor for SearchResponseIterator calls ServerLdapContex.isReferral() at SearchResponseItereator:117
> 3) ServerLdapContext.isReferral() results in a NPE at ServerLdapContext.java:264 unless your DirectoryService's InterceptorChain includes a ReferralInterceptor.  Take a look at the constructor and you'll see why:
> public ServerLdapContext( DirectoryService service, Hashtable<String, Object> env ) throws NamingException
> {
>     super( service, env );
>     refService = ( ( ReferralInterceptor ) service.getInterceptorChain().get( ReferralInterceptor.class.getName() ) );
> }
> Is there any chance that we can simply Check refService for null before it's used ServerLdapContext.isReferral().  If it's refService==null, return false?
> There's also similar a similar problem in PartitionNexusProxy.java:891 and 901.  Here the code checks the chain for null, and returns, but it doesn't check the for null before invoking the interceptor method. 
> Here's the patch:
> $ svn diff ServerLdapContext.java 
> Index: ServerLdapContext.java
> ===================================================================
> --- ServerLdapContext.java      (revision 638966)
> +++ ServerLdapContext.java      (working copy)
> @@ -261,7 +261,11 @@
>       */
>      public boolean isReferral( String name ) throws NamingException
>      {
> -        return refService.isReferral( name );
> +       if( refService == null )
> +        {
> +               return false;
> +        }
> +       return refService.isReferral( name );
>      }
>  
>      /**
> @@ -272,7 +276,11 @@
>       */
>      public boolean isReferral( LdapDN name ) throws NamingException
>      {
> -        return refService.isReferral( name );
> +        if( refService == null )
> +        {
> +               return false;
> +        }
> +       return refService.isReferral( name );
> $ svn diff PartitionNexusProxy.java
> Index: PartitionNexusProxy.java
> ===================================================================
> --- PartitionNexusProxy.java    (revision 638966)
> +++ PartitionNexusProxy.java    (working copy)
> @@ -889,6 +889,10 @@
>      {
>          InterceptorChain chain = service.getInterceptorChain();
>          EventInterceptor interceptor = ( EventInterceptor ) chain.get( EventInterceptor.class.getName() );
> +        if( interceptor == null )
> +        {
> +               return;
> +        }
>          interceptor.addNamingListener( ctx, name, filter, searchControls, namingListener );
>      }
>  
> @@ -901,6 +905,10 @@
>              return;
>          }
>          EventInterceptor interceptor = ( EventInterceptor ) chain.get( EventInterceptor.class.getName() );
> +        if( interceptor == null )
> +        {
> +               return;
> +        }
>          interceptor.removeNamingListener( ctx, namingListener );
>      }
>  }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Assigned: (DIRSERVER-1154) Declaration and instantiation of refService in ServerLdapContext limits extensibility

Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/DIRSERVER-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alex Karasulu reassigned DIRSERVER-1154:
----------------------------------------

    Assignee: Alex Karasulu

> Declaration and instantiation of refService in ServerLdapContext limits extensibility
> -------------------------------------------------------------------------------------
>
>                 Key: DIRSERVER-1154
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-1154
>             Project: Directory ApacheDS
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.5.4
>            Reporter: Icky Dude
>            Assignee: Alex Karasulu
>             Fix For: 1.5.4
>
>
> I ran into a problem that I think needs some simple design work or a simple fix.  For my project is is not necessary to handle referrals, so I decided to simply eliminate the ReferralIntercepter from my InterceptorChain.  As soon as I did this, myDirectoryService started crapping on a NullPointerException buried in the bowels of the DefaultSearchHandler (something I definitely don't want to mess with for my project).
> 1) At DefaultSearchHandler.java:357 of  there is an instantiation of a new SearchResponseIterator.  
> 2) The constructor for SearchResponseIterator calls ServerLdapContex.isReferral() at SearchResponseItereator:117
> 3) ServerLdapContext.isReferral() results in a NPE at ServerLdapContext.java:264 unless your DirectoryService's InterceptorChain includes a ReferralInterceptor.  Take a look at the constructor and you'll see why:
> public ServerLdapContext( DirectoryService service, Hashtable<String, Object> env ) throws NamingException
> {
>     super( service, env );
>     refService = ( ( ReferralInterceptor ) service.getInterceptorChain().get( ReferralInterceptor.class.getName() ) );
> }
> Is there any chance that we can simply Check refService for null before it's used ServerLdapContext.isReferral().  If it's refService==null, return false?
> There's also similar a similar problem in PartitionNexusProxy.java:891 and 901.  Here the code checks the chain for null, and returns, but it doesn't check the for null before invoking the interceptor method. 
> Here's the patch:
> $ svn diff ServerLdapContext.java 
> Index: ServerLdapContext.java
> ===================================================================
> --- ServerLdapContext.java      (revision 638966)
> +++ ServerLdapContext.java      (working copy)
> @@ -261,7 +261,11 @@
>       */
>      public boolean isReferral( String name ) throws NamingException
>      {
> -        return refService.isReferral( name );
> +       if( refService == null )
> +        {
> +               return false;
> +        }
> +       return refService.isReferral( name );
>      }
>  
>      /**
> @@ -272,7 +276,11 @@
>       */
>      public boolean isReferral( LdapDN name ) throws NamingException
>      {
> -        return refService.isReferral( name );
> +        if( refService == null )
> +        {
> +               return false;
> +        }
> +       return refService.isReferral( name );
> $ svn diff PartitionNexusProxy.java
> Index: PartitionNexusProxy.java
> ===================================================================
> --- PartitionNexusProxy.java    (revision 638966)
> +++ PartitionNexusProxy.java    (working copy)
> @@ -889,6 +889,10 @@
>      {
>          InterceptorChain chain = service.getInterceptorChain();
>          EventInterceptor interceptor = ( EventInterceptor ) chain.get( EventInterceptor.class.getName() );
> +        if( interceptor == null )
> +        {
> +               return;
> +        }
>          interceptor.addNamingListener( ctx, name, filter, searchControls, namingListener );
>      }
>  
> @@ -901,6 +905,10 @@
>              return;
>          }
>          EventInterceptor interceptor = ( EventInterceptor ) chain.get( EventInterceptor.class.getName() );
> +        if( interceptor == null )
> +        {
> +               return;
> +        }
>          interceptor.removeNamingListener( ctx, namingListener );
>      }
>  }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (DIRSERVER-1154) Declaration and instantiation of refService in ServerLdapContext limits extensibility

Posted by "Icky Dude (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/DIRSERVER-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581585#action_12581585 ] 

Icky Dude commented on DIRSERVER-1154:
--------------------------------------


I agree that the idea of calling the interceptor's method from outside is not optimal -- hence the suggestion that it might be worth some redesign here.  I'm still confused as to why you think the patch wouldn't eliminate the NPE for those that would like to exclude the ReferralInterceptor.  I don't see any other use of the transient ReferralInterceptor other than in the isReferral() method.  My testing shows that the patch does eliminate the NPE.  

Though I completely agree about the implementation of a new cache system (outside the ReferralInterceptor), I don't see how the proposed patch would hurt things in the mean-time.



> Declaration and instantiation of refService in ServerLdapContext limits extensibility
> -------------------------------------------------------------------------------------
>
>                 Key: DIRSERVER-1154
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-1154
>             Project: Directory ApacheDS
>          Issue Type: Bug
>          Components: core
>    Affects Versions: bigbang
>            Reporter: Icky Dude
>             Fix For: bigbang
>
>
> I ran into a problem that I think needs some simple design work or a simple fix.  For my project is is not necessary to handle referrals, so I decided to simply eliminate the ReferralIntercepter from my InterceptorChain.  As soon as I did this, myDirectoryService started crapping on a NullPointerException buried in the bowels of the DefaultSearchHandler (something I definitely don't want to mess with for my project).
> 1) At DefaultSearchHandler.java:357 of  there is an instantiation of a new SearchResponseIterator.  
> 2) The constructor for SearchResponseIterator calls ServerLdapContex.isReferral() at SearchResponseItereator:117
> 3) ServerLdapContext.isReferral() results in a NPE at ServerLdapContext.java:264 unless your DirectoryService's InterceptorChain includes a ReferralInterceptor.  Take a look at the constructor and you'll see why:
> public ServerLdapContext( DirectoryService service, Hashtable<String, Object> env ) throws NamingException
> {
>     super( service, env );
>     refService = ( ( ReferralInterceptor ) service.getInterceptorChain().get( ReferralInterceptor.class.getName() ) );
> }
> Is there any chance that we can simply Check refService for null before it's used ServerLdapContext.isReferral().  If it's refService==null, return false?
> There's also similar a similar problem in PartitionNexusProxy.java:891 and 901.  Here the code checks the chain for null, and returns, but it doesn't check the for null before invoking the interceptor method. 
> Here's the patch:
> $ svn diff ServerLdapContext.java 
> Index: ServerLdapContext.java
> ===================================================================
> --- ServerLdapContext.java      (revision 638966)
> +++ ServerLdapContext.java      (working copy)
> @@ -261,7 +261,11 @@
>       */
>      public boolean isReferral( String name ) throws NamingException
>      {
> -        return refService.isReferral( name );
> +       if( refService == null )
> +        {
> +               return false;
> +        }
> +       return refService.isReferral( name );
>      }
>  
>      /**
> @@ -272,7 +276,11 @@
>       */
>      public boolean isReferral( LdapDN name ) throws NamingException
>      {
> -        return refService.isReferral( name );
> +        if( refService == null )
> +        {
> +               return false;
> +        }
> +       return refService.isReferral( name );
> $ svn diff PartitionNexusProxy.java
> Index: PartitionNexusProxy.java
> ===================================================================
> --- PartitionNexusProxy.java    (revision 638966)
> +++ PartitionNexusProxy.java    (working copy)
> @@ -889,6 +889,10 @@
>      {
>          InterceptorChain chain = service.getInterceptorChain();
>          EventInterceptor interceptor = ( EventInterceptor ) chain.get( EventInterceptor.class.getName() );
> +        if( interceptor == null )
> +        {
> +               return;
> +        }
>          interceptor.addNamingListener( ctx, name, filter, searchControls, namingListener );
>      }
>  
> @@ -901,6 +905,10 @@
>              return;
>          }
>          EventInterceptor interceptor = ( EventInterceptor ) chain.get( EventInterceptor.class.getName() );
> +        if( interceptor == null )
> +        {
> +               return;
> +        }
>          interceptor.removeNamingListener( ctx, namingListener );
>      }
>  }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (DIRSERVER-1154) Declaration and instantiation of refService in ServerLdapContext limits extensibility

Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/DIRSERVER-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alex Karasulu updated DIRSERVER-1154:
-------------------------------------

    Fix Version/s:     (was: 1.5.3)
                   1.5.4

Need to review this but BB is now 1.5.4.  Will look at in next release.

> Declaration and instantiation of refService in ServerLdapContext limits extensibility
> -------------------------------------------------------------------------------------
>
>                 Key: DIRSERVER-1154
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-1154
>             Project: Directory ApacheDS
>          Issue Type: Bug
>          Components: core
>    Affects Versions: bigbang
>            Reporter: Icky Dude
>             Fix For: 1.5.4
>
>
> I ran into a problem that I think needs some simple design work or a simple fix.  For my project is is not necessary to handle referrals, so I decided to simply eliminate the ReferralIntercepter from my InterceptorChain.  As soon as I did this, myDirectoryService started crapping on a NullPointerException buried in the bowels of the DefaultSearchHandler (something I definitely don't want to mess with for my project).
> 1) At DefaultSearchHandler.java:357 of  there is an instantiation of a new SearchResponseIterator.  
> 2) The constructor for SearchResponseIterator calls ServerLdapContex.isReferral() at SearchResponseItereator:117
> 3) ServerLdapContext.isReferral() results in a NPE at ServerLdapContext.java:264 unless your DirectoryService's InterceptorChain includes a ReferralInterceptor.  Take a look at the constructor and you'll see why:
> public ServerLdapContext( DirectoryService service, Hashtable<String, Object> env ) throws NamingException
> {
>     super( service, env );
>     refService = ( ( ReferralInterceptor ) service.getInterceptorChain().get( ReferralInterceptor.class.getName() ) );
> }
> Is there any chance that we can simply Check refService for null before it's used ServerLdapContext.isReferral().  If it's refService==null, return false?
> There's also similar a similar problem in PartitionNexusProxy.java:891 and 901.  Here the code checks the chain for null, and returns, but it doesn't check the for null before invoking the interceptor method. 
> Here's the patch:
> $ svn diff ServerLdapContext.java 
> Index: ServerLdapContext.java
> ===================================================================
> --- ServerLdapContext.java      (revision 638966)
> +++ ServerLdapContext.java      (working copy)
> @@ -261,7 +261,11 @@
>       */
>      public boolean isReferral( String name ) throws NamingException
>      {
> -        return refService.isReferral( name );
> +       if( refService == null )
> +        {
> +               return false;
> +        }
> +       return refService.isReferral( name );
>      }
>  
>      /**
> @@ -272,7 +276,11 @@
>       */
>      public boolean isReferral( LdapDN name ) throws NamingException
>      {
> -        return refService.isReferral( name );
> +        if( refService == null )
> +        {
> +               return false;
> +        }
> +       return refService.isReferral( name );
> $ svn diff PartitionNexusProxy.java
> Index: PartitionNexusProxy.java
> ===================================================================
> --- PartitionNexusProxy.java    (revision 638966)
> +++ PartitionNexusProxy.java    (working copy)
> @@ -889,6 +889,10 @@
>      {
>          InterceptorChain chain = service.getInterceptorChain();
>          EventInterceptor interceptor = ( EventInterceptor ) chain.get( EventInterceptor.class.getName() );
> +        if( interceptor == null )
> +        {
> +               return;
> +        }
>          interceptor.addNamingListener( ctx, name, filter, searchControls, namingListener );
>      }
>  
> @@ -901,6 +905,10 @@
>              return;
>          }
>          EventInterceptor interceptor = ( EventInterceptor ) chain.get( EventInterceptor.class.getName() );
> +        if( interceptor == null )
> +        {
> +               return;
> +        }
>          interceptor.removeNamingListener( ctx, namingListener );
>      }
>  }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (DIRSERVER-1154) Declaration and instantiation of refService in ServerLdapContext limits extensibility

Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/DIRSERVER-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emmanuel Lecharny updated DIRSERVER-1154:
-----------------------------------------

    Fix Version/s:     (was: bigbang)
                   1.5.3

Postponed.

> Declaration and instantiation of refService in ServerLdapContext limits extensibility
> -------------------------------------------------------------------------------------
>
>                 Key: DIRSERVER-1154
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-1154
>             Project: Directory ApacheDS
>          Issue Type: Bug
>          Components: core
>    Affects Versions: bigbang
>            Reporter: Icky Dude
>             Fix For: 1.5.3
>
>
> I ran into a problem that I think needs some simple design work or a simple fix.  For my project is is not necessary to handle referrals, so I decided to simply eliminate the ReferralIntercepter from my InterceptorChain.  As soon as I did this, myDirectoryService started crapping on a NullPointerException buried in the bowels of the DefaultSearchHandler (something I definitely don't want to mess with for my project).
> 1) At DefaultSearchHandler.java:357 of  there is an instantiation of a new SearchResponseIterator.  
> 2) The constructor for SearchResponseIterator calls ServerLdapContex.isReferral() at SearchResponseItereator:117
> 3) ServerLdapContext.isReferral() results in a NPE at ServerLdapContext.java:264 unless your DirectoryService's InterceptorChain includes a ReferralInterceptor.  Take a look at the constructor and you'll see why:
> public ServerLdapContext( DirectoryService service, Hashtable<String, Object> env ) throws NamingException
> {
>     super( service, env );
>     refService = ( ( ReferralInterceptor ) service.getInterceptorChain().get( ReferralInterceptor.class.getName() ) );
> }
> Is there any chance that we can simply Check refService for null before it's used ServerLdapContext.isReferral().  If it's refService==null, return false?
> There's also similar a similar problem in PartitionNexusProxy.java:891 and 901.  Here the code checks the chain for null, and returns, but it doesn't check the for null before invoking the interceptor method. 
> Here's the patch:
> $ svn diff ServerLdapContext.java 
> Index: ServerLdapContext.java
> ===================================================================
> --- ServerLdapContext.java      (revision 638966)
> +++ ServerLdapContext.java      (working copy)
> @@ -261,7 +261,11 @@
>       */
>      public boolean isReferral( String name ) throws NamingException
>      {
> -        return refService.isReferral( name );
> +       if( refService == null )
> +        {
> +               return false;
> +        }
> +       return refService.isReferral( name );
>      }
>  
>      /**
> @@ -272,7 +276,11 @@
>       */
>      public boolean isReferral( LdapDN name ) throws NamingException
>      {
> -        return refService.isReferral( name );
> +        if( refService == null )
> +        {
> +               return false;
> +        }
> +       return refService.isReferral( name );
> $ svn diff PartitionNexusProxy.java
> Index: PartitionNexusProxy.java
> ===================================================================
> --- PartitionNexusProxy.java    (revision 638966)
> +++ PartitionNexusProxy.java    (working copy)
> @@ -889,6 +889,10 @@
>      {
>          InterceptorChain chain = service.getInterceptorChain();
>          EventInterceptor interceptor = ( EventInterceptor ) chain.get( EventInterceptor.class.getName() );
> +        if( interceptor == null )
> +        {
> +               return;
> +        }
>          interceptor.addNamingListener( ctx, name, filter, searchControls, namingListener );
>      }
>  
> @@ -901,6 +905,10 @@
>              return;
>          }
>          EventInterceptor interceptor = ( EventInterceptor ) chain.get( EventInterceptor.class.getName() );
> +        if( interceptor == null )
> +        {
> +               return;
> +        }
>          interceptor.removeNamingListener( ctx, namingListener );
>      }
>  }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.