Great :) Thanks! Carsten
> -----Original Message----- > From: Unico Hommes [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 17, 2004 2:41 PM > To: [EMAIL PROTECTED] > Subject: Re: NPE in AbstractCachingProcessingPipeline > > The section fixes > http://issues.apache.org/bugzilla/show_bug.cgi?id=31012 which > is a serious bug in itself. > > Anyway, I have found out why toCacheSourceValidities could be > null when cachedResponse is not. Apparently this happens when > the pipeline is not yet expired. I have committed a better fix. > > -- > Unico > > Carsten Ziegeler wrote: > > >Hmm, this is imho not the best solutions. Preventing NPEs by null > >checking smells a little bit :) If the section has been > added recently > >than that author should now if a null for the object is a > valid case or > >not; otherwise we should better remove the section for the release. > > > >Carsten > > > > > > > >>-----Original Message----- > >>From: Unico Hommes [mailto:[EMAIL PROTECTED] > >>Sent: Tuesday, November 16, 2004 4:00 PM > >>To: [EMAIL PROTECTED] > >>Subject: Re: NPE in AbstractCachingProcessingPipeline > >> > >>The section that causes the NPE was added recently. If you say that > >>there are situations where it causes an NPE then I believe you > >>immediately. The code is rather incomprehensible to me as > well to say > >>the least. Lots of side effects and null states that are > supposed to > >>signal some sort of situation that are probably not even > clear to the > >>original author anymore. I guess I'll add a null check for this > >>situation, when SVN is up again that is. > >> > >>-- > >>Unico > >> > >>Jon Evans wrote: > >> > >> > >> > >>>Hi, > >>> > >>>Bugzilla appears to be broken... > >>> > >>> > >>>I've been chasing down a problem where the portal I'm > >>> > >>> > >>developing would > >> > >> > >>>work fine for a few iterations, then it would break and bits of it > >>>would be replaced with "The coplet xxx is currently > >>> > >>> > >>unavailable". The > >> > >> > >>>NPE logged in error.log was pretty hard to track down, in > the end I > >>>had to step through the code. > >>> > >>>I tracked it down to the function > >>> > >>> > >>getValidityForEventPipeline(), the > >> > >> > >>>first section of which reads: > >>> > >>> > >>> > >>>> if (this.cachedResponse != null) { > >>>> final AggregatedValidity validity = new > >>>>AggregatedValidity(); > >>>> > >>>> for (int i=0; i < this.toCacheSourceValidities.length; > >>>>i++) { > >>>> validity.add(this.toCacheSourceValidities[i]); > >>>> } > >>>> return validity; > >>>> > >>>> > >>>The problem seems to be that this.toCacheSourceValidities > is null. > >>>This would point to the fact that setupValidities() has never been > >>>called - or it's internal state is such that > >>> > >>> > >>setupValidities() ends up > >> > >> > >>>setting toCacheSourceValidities to null. I don't know > >>> > >>> > >>anything about > >> > >> > >>>the lifecycle of an AbstractCachingProcessingPipeline so I > wouldn't > >>>know where to track that down. > >>> > >>>If a !=null test is added to getValidityForEventPipeline(): > >>> > >>> > >>> > >>>> if (this.cachedResponse != null) { > >>>> final AggregatedValidity validity = new > >>>>AggregatedValidity(); > >>>> > >>>> if (this.toCacheSourceValidities != null) { > >>>> for (int i=0; i < > >>>>this.toCacheSourceValidities.length; i++) { > >>>> validity.add(this.toCacheSourceValidities[i]); > >>>> } > >>>> } > >>>> return validity; > >>>> > >>>> > >>>then it seems to work (at least, my portal doesn't seem to keep > >>>falling over any more). > >>> > >>>If my patch isn't correct then I'd be happy to track this down > >>>further, if someone could point me in the right direction > with some > >>>more information about how an > >>> > >>> > >>AbstractCachingProcessingPipeline gets > >> > >> > >>>constructed, and at what point in its lifecycle setupValidities() > >>>should be called. > >>> > >>>I'd appreciate some feedback / help on this one! > >>> > >>>Thanks, > >>> > >>>Jon > >>> > >>> > >>> > >> > >> > > > > > > > >
