Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 60523 invoked from network); 24 Mar 2008 16:19:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 24 Mar 2008 16:19:30 -0000 Received: (qmail 44198 invoked by uid 500); 24 Mar 2008 16:19:28 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 44165 invoked by uid 500); 24 Mar 2008 16:19:28 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 44154 invoked by uid 99); 24 Mar 2008 16:19:28 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 24 Mar 2008 09:19:28 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 24 Mar 2008 16:18:57 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 69421234C0A4 for ; Mon, 24 Mar 2008 09:17:24 -0700 (PDT) Message-ID: <1619467819.1206375444429.JavaMail.jira@brutus> Date: Mon, 24 Mar 2008 09:17:24 -0700 (PDT) From: "Icky Dude (JIRA)" To: dev@directory.apache.org Subject: [jira] Commented: (DIRSERVER-1154) Declaration and instantiation of refService in ServerLdapContext limits extensibility In-Reply-To: <858867647.1206139644959.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on 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 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.