Re: Slight issue with classloading and DataImportHandler

[Brendan Grainger]

Awesome thank you very much and thanks for the very useful contribution.
Brendan

On Jun 19, 2008, at 12:52 AM, Noble Paul നോബിള്‍  
नोब्ळ् wrote:

aah!. We always assumed that people put the custom jars in the
WEB-INF/lib folder of solr webapp and hence they are automatically in
the classpath we shall make the necessary changes  .
--Noble

On Thu, Jun 19, 2008 at 10:06 AM, Brendan Grainger
<[EMAIL PROTECTED]> wrote:
Hi,

I am actually providing the fully qualified classname in the  
configuration
and I was still getting a ClassNotFoundException. If you look at  
the code in
SolrResourceLoader they actually explicitly add the jars in solr- 
home/lib to
the classloader:

static ClassLoader createClassLoader(File f, ClassLoader loader) {
  if( loader == null ) {
    loader = Thread.currentThread().getContextClassLoader();
  }
  if (f.canRead() && f.isDirectory()) {
    File[] jarFiles = f.listFiles();
    URL[] jars = new URL[jarFiles.length];
    try {
      for (int j = 0; j < jarFiles.length; j++) {
        jars[j] = jarFiles[j].toURI().toURL();
        log.info("Adding '" + jars[j].toString() + "' to Solr
classloader");
      }
      return URLClassLoader.newInstance(jars, loader);
    } catch (MalformedURLException e) {
      SolrException.log(log,"Can't construct solr lib class  
loader", e);
    }
  }
  log.info("Reusing parent classloader");
  return loader;
}


This seems to be me to be why my class is now found when I include my
utilities jar in solr-home/lib.

Thanks
Brendan

On Jun 18, 2008, at 11:49 PM, Noble Paul നോബിള്‍  
नोब्ळ् wrote:

hi,
DIH does not load class using the SolrResourceLoader. It tries a
Class.forName() with the name you provide if it fails it prepends
"org.apache.solr.handler.dataimport." and retries.

This is true for not just transformers but also for Entityprocessor,
DataSource and Evaluator

The reason for doing so is that we do not use any of the 'solr.'
packages in DIH. All our implementations fall into the default  
package
and we can directly use them w/o the package name.

So , if you are writing your own implementations use the default
package or provide the fully qualified class name.

--Noble

On Thu, Jun 19, 2008 at 8:09 AM, Jon Baer <[EMAIL PROTECTED]> wrote:

Thanks.  Yeah took me a while to figure out I needed to do  
something like
transformer="com.mycompany.solr.MyTransformer" on the entity  
before it
would
work ...

- Jon

On Jun 18, 2008, at 1:51 PM, Brendan Grainger wrote:

Hi,

I set up the new DataimportHandler last night to replace some  
custom
import code I'd written and so far I'm loving it thank you.

I had one issue you might want to know about it. I have some solr
extensions I've written and packaged in a jar which I place in:

solr-home/lib

as per:



http://wiki.apache.org/solr/SolrPlugins#head-59e2685df65335e82f8936ed55d260842dc7a4dc

This works well for my handlers but a custom Transformer I wrote  
and
packaged the same way was throwing a ClassNotFoundException. I  
tracked
it
down to the DocBuilder.loadClass method which was just doing a
Class.forName. Anyway, I fixed it for the moment by probably do
something
stupid and creating a SolrResourceLoader (which I imagine could  
be an
instance variable, but at 3am I just wanted to get it working).  
Anyway,
this
fixes the problem:

@SuppressWarnings("unchecked")
static Class loadClass(String name) throws  
ClassNotFoundException {
SolrResourceLoader loader = new SolrResourceLoader( null );
return loader.findClass(name);
// return Class.forName(name);
}

Brendan





--
--Noble Paul





--
--Noble Paul