And here is my actual code... Brian Frutchey Federal Solutions Architect M (703) 597-4875 E [email protected] Endeca 2100 Reston Parkway Ste 101 Reston, VA 20171 www.endeca.com find / analyze / understand
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Mck Sent: Friday, August 28, 2009 12:07 PM To: [email protected] Subject: Re: classloader issue > The only reason I can think of to cause this is that the classloader > for each search command is loading different copies of the same class, > which makes the result classes (though operationally the same) > different in the eyes of instanceof... This could be, if the commands are somehow each loading either of those SearchResult classes in a different order that Spi defines. Each skin has up to 17 classloaders (actually SpiClassLoaders) and the Spi enum defines how these are linked together. When loading a skin class from a skin a Spi is defined. If the class is not found in that Spi within the skin, then the same Spi is searched in the parent skin, up to the base skin generic.sesam. If still not found then the parent Spi is searched. The Spi's parent is the second argument in its constructor. If somehow each command is causing the same class to be loaded in a different order then it'll explain the problem. You need to find how the same class is loaded twice. What does the following give? grep " loaded by " .../sesam.log | grep FacetedSearchResult ~mck -- We are born naked, wet and hungry. Then things get worse. | semb.wever.org | sesat.no | finn.no |
FederatorRunHandler.java
Description: FederatorRunHandler.java
_______________________________________________ Kernel-development mailing list [email protected] http://sesat.no/mailman/listinfo/kernel-development
