Re: Slight issue with classloading and DataImportHandler
yes Brendan. I got your point. That is the very reason of moving to
SolrResourceLoader. From the next patch onwards you will be able to
load classes from solr-home/lib .
--Noble
On Sat, Jun 21, 2008 at 7:51 PM, Brendan Grainger
<[EMAIL PROTECTED]> wrote:
> Hi Noble,
>
> Just to be clear. It was not so that I could refer to my plugin class with
> solr. that I suggested using SolrResourceLoader, it's that the
> SolrResourceLoader loads the jars you put in solr-home/lib. If you don't do
> this you get a ClassNotFoundException. It's pretty well explained here:
>
> http://www.nabble.com/New-Feature:-$%7Bsolr.home%7D-lib--dir-for-%22plugins%22-tt7350634r5.html
>
> For the moment, I've altered you code to use the SolrResourceLoader for
> resolving classes and it's working well for me.
>
> Thanks again!
> Brendan
>
> On Jun 21, 2008, at 7:49 AM, Noble Paul നോബിള് नोब्ळ् wrote:
>
>> We plan to use SolrResourceLoader (next patch).. So anyone wishing to
>> plugin their classes can refer the classname with solr..
>> --Noble
>>
>>
>>
>> On Sat, Jun 21, 2008 at 3:06 AM, Chris Hostetter
>> <[EMAIL PROTECTED]> whi rote:
>>>
>>> : But we still prefer the usage of DIH package classes without any
>>> prefix.
>>> : type="HttpDataSource"
>>> : instead of
>>> : type="solr.HttpDataSource"
>>> :
>>> : But users must be able to load their classes using the
>>> "solr." format
>>>
>>> I'm not 100% certain what you mean by that last comment, but it seems
>>> like
>>> the the most straight forward appraoch that will confuse the least amount
>>> of people is for DIH to be consistent with the rest of Solr in how
>>> "plugins" are loaded. The helper methods already exist to make this
>>> easy in SolrResourceLoader...
>>>
>>> public Class findClass(String cname, String... subpackages)
>>> public Object newInstance(String cname, String ... subpackages)
>>>
>>> ...all DIH needs to do is pass the appropriate subpackage(s?) ...
>>> "handler.dataimport." (and maybe in some cases lists like
>>> {"handler.dataimport.", "handler.dataimport.transformer."} if that's the
>>> way the code winds up being organized)
>>>
>>>
>>>
>>> -Hoss
Re: Slight issue with classloading and DataImportHandler
Hi Noble,
Just to be clear. It was not so that I could refer to my plugin class
with solr. that I suggested using SolrResourceLoader, it's
that the SolrResourceLoader loads the jars you put in solr-home/lib.
If you don't do this you get a ClassNotFoundException. It's pretty
well explained here:
http://www.nabble.com/New-Feature:-$%7Bsolr.home%7D-lib--dir-for-%22plugins%22-tt7350634r5.html
For the moment, I've altered you code to use the SolrResourceLoader
for resolving classes and it's working well for me.
Thanks again!
Brendan
On Jun 21, 2008, at 7:49 AM, Noble Paul നോബിള്
नोब्ळ् wrote:
We plan to use SolrResourceLoader (next patch).. So anyone wishing to
plugin their classes can refer the classname with solr..
--Noble
On Sat, Jun 21, 2008 at 3:06 AM, Chris Hostetter
<[EMAIL PROTECTED]> whi rote:
: But we still prefer the usage of DIH package classes without any
prefix.
: type="HttpDataSource"
: instead of
: type="solr.HttpDataSource"
:
: But users must be able to load their classes using the
"solr." format
I'm not 100% certain what you mean by that last comment, but it
seems like
the the most straight forward appraoch that will confuse the least
amount
of people is for DIH to be consistent with the rest of Solr in how
"plugins" are loaded. The helper methods already exist to make this
easy in SolrResourceLoader...
public Class findClass(String cname, String... subpackages)
public Object newInstance(String cname, String ... subpackages)
...all DIH needs to do is pass the appropriate subpackage(s?) ...
"handler.dataimport." (and maybe in some cases lists like
{"handler.dataimport.", "handler.dataimport.transformer."} if
that's the
way the code winds up being organized)
-Hoss
--
--Noble Paul
Re: Slight issue with classloading and DataImportHandler
We plan to use SolrResourceLoader (next patch).. So anyone wishing to
plugin their classes can refer the classname with solr..
--Noble
On Sat, Jun 21, 2008 at 3:06 AM, Chris Hostetter
<[EMAIL PROTECTED]> whi rote:
>
> : But we still prefer the usage of DIH package classes without any prefix.
> : type="HttpDataSource"
> : instead of
> : type="solr.HttpDataSource"
> :
> : But users must be able to load their classes using the "solr."
> format
>
> I'm not 100% certain what you mean by that last comment, but it seems like
> the the most straight forward appraoch that will confuse the least amount
> of people is for DIH to be consistent with the rest of Solr in how
> "plugins" are loaded. The helper methods already exist to make this
> easy in SolrResourceLoader...
>
> public Class findClass(String cname, String... subpackages)
> public Object newInstance(String cname, String ... subpackages)
>
> ...all DIH needs to do is pass the appropriate subpackage(s?) ...
> "handler.dataimport." (and maybe in some cases lists like
> {"handler.dataimport.", "handler.dataimport.transformer."} if that's the
> way the code winds up being organized)
>
>
>
> -Hoss
>
>
--
--Noble Paul
Re: Slight issue with classloading and DataImportHandler
My guess, within the next 2 weeks. :)
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
> From: William Silva <[EMAIL PROTECTED]>
> To: solr-user@lucene.apache.org
> Sent: Friday, June 20, 2008 7:04:14 PM
> Subject: Re: Slight issue with classloading and DataImportHandler
>
> Hi,
> Who knows when it will be available in the nightly builds ?
> Thanks,
> William.
>
>
> On Fri, Jun 20, 2008 at 6:36 PM, Chris Hostetter
> wrote:
>
> >
> > : But we still prefer the usage of DIH package classes without any prefix.
> > : type="HttpDataSource"
> > : instead of
> > : type="solr.HttpDataSource"
> > :
> > : But users must be able to load their classes using the "solr."
> > format
> >
> > I'm not 100% certain what you mean by that last comment, but it seems like
> > the the most straight forward appraoch that will confuse the least amount
> > of people is for DIH to be consistent with the rest of Solr in how
> > "plugins" are loaded. The helper methods already exist to make this
> > easy in SolrResourceLoader...
> >
> > public Class findClass(String cname, String... subpackages)
> > public Object newInstance(String cname, String ... subpackages)
> >
> > ...all DIH needs to do is pass the appropriate subpackage(s?) ...
> > "handler.dataimport." (and maybe in some cases lists like
> > {"handler.dataimport.", "handler.dataimport.transformer."} if that's the
> > way the code winds up being organized)
> >
> >
> >
> > -Hoss
> >
> >
Re: Slight issue with classloading and DataImportHandler
Hi,
Who knows when it will be available in the nightly builds ?
Thanks,
William.
On Fri, Jun 20, 2008 at 6:36 PM, Chris Hostetter <[EMAIL PROTECTED]>
wrote:
>
> : But we still prefer the usage of DIH package classes without any prefix.
> : type="HttpDataSource"
> : instead of
> : type="solr.HttpDataSource"
> :
> : But users must be able to load their classes using the "solr."
> format
>
> I'm not 100% certain what you mean by that last comment, but it seems like
> the the most straight forward appraoch that will confuse the least amount
> of people is for DIH to be consistent with the rest of Solr in how
> "plugins" are loaded. The helper methods already exist to make this
> easy in SolrResourceLoader...
>
> public Class findClass(String cname, String... subpackages)
> public Object newInstance(String cname, String ... subpackages)
>
> ...all DIH needs to do is pass the appropriate subpackage(s?) ...
> "handler.dataimport." (and maybe in some cases lists like
> {"handler.dataimport.", "handler.dataimport.transformer."} if that's the
> way the code winds up being organized)
>
>
>
> -Hoss
>
>
Re: Slight issue with classloading and DataImportHandler
: But we still prefer the usage of DIH package classes without any prefix.
: type="HttpDataSource"
: instead of
: type="solr.HttpDataSource"
:
: But users must be able to load their classes using the "solr."
format
I'm not 100% certain what you mean by that last comment, but it seems like
the the most straight forward appraoch that will confuse the least amount
of people is for DIH to be consistent with the rest of Solr in how
"plugins" are loaded. The helper methods already exist to make this
easy in SolrResourceLoader...
public Class findClass(String cname, String... subpackages)
public Object newInstance(String cname, String ... subpackages)
...all DIH needs to do is pass the appropriate subpackage(s?) ...
"handler.dataimport." (and maybe in some cases lists like
{"handler.dataimport.", "handler.dataimport.transformer."} if that's the
way the code winds up being organized)
-Hoss
Re: Slight issue with classloading and DataImportHandler
We are using DIH in production . It is a planned feature for 1.3 realease. Let us see when it happens --Noble On Thu, Jun 19, 2008 at 7:35 PM, William Silva <[EMAIL PROTECTED]> wrote: > Hi, > Are you using DataImportHandler in a production environment ? > When it will be available in the nightly builds ? > Thanks, > William. > > > On Thu, Jun 19, 2008 at 3:12 AM, Noble Paul നോബിള് नोब्ळ् < > [EMAIL PROTECTED]> wrote: > >> We plan to use SolrResourceLoader (in the next patch) . That is the >> best way to go. >> >> But we still prefer the usage of DIH package classes without any prefix. >> type="HttpDataSource" >> instead of >> type="solr.HttpDataSource" >> >> But users must be able to load their classes using the "solr." >> format >> --Noble >> >> >> On Thu, Jun 19, 2008 at 10:57 AM, Chris Hostetter >> <[EMAIL PROTECTED]> 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 . >> > >> > It would be better to use the classloader from the SolrResourceLoader ... >> > that should be safe for anyone with any setup. >> > >> >>> 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. >> >... >> >>> 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. >> > >> > FWIW: there isn't relaly a "solr." package ... "solr." can be used as >> > an short form alias for the "likely package" when Solr resolves classes, >> > where the "likely package" varies by context and there can be multiple >> > options that it tries in order >> > >> > DIH could do the same thing, letting short form "solr." signify that >> > Transformers, Evaluators, etc are in the o.a.s.handler.dataimport >> package. >> > >> > the advantage of this over what it sounds like DIH currently does is that >> > if there is an o.a.s.handler.dataimport.WizWatTransformer but someone >> > wants to write their own (package less) WizWatTransformer they can and >> > refer to it simply as "WizWatTransformer" (whereas to use the one that >> > ships with DIH they would specify "solr.WizWatTransformer"). There's no >> > ambiguity as to which one someone means unless they create a package >> > called "solr" ... but then they'ed just be looking for trouble :) >> > >> > >> > >> > -Hoss >> > >> > >> >> >> >> -- >> --Noble Paul >> > -- --Noble Paul
Re: Slight issue with classloading and DataImportHandler
Hi, Are you using DataImportHandler in a production environment ? When it will be available in the nightly builds ? Thanks, William. On Thu, Jun 19, 2008 at 3:12 AM, Noble Paul നോബിള് नोब्ळ् < [EMAIL PROTECTED]> wrote: > We plan to use SolrResourceLoader (in the next patch) . That is the > best way to go. > > But we still prefer the usage of DIH package classes without any prefix. > type="HttpDataSource" > instead of > type="solr.HttpDataSource" > > But users must be able to load their classes using the "solr." > format > --Noble > > > On Thu, Jun 19, 2008 at 10:57 AM, Chris Hostetter > <[EMAIL PROTECTED]> 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 . > > > > It would be better to use the classloader from the SolrResourceLoader ... > > that should be safe for anyone with any setup. > > > >>> 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. > >... > >>> 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. > > > > FWIW: there isn't relaly a "solr." package ... "solr." can be used as > > an short form alias for the "likely package" when Solr resolves classes, > > where the "likely package" varies by context and there can be multiple > > options that it tries in order > > > > DIH could do the same thing, letting short form "solr." signify that > > Transformers, Evaluators, etc are in the o.a.s.handler.dataimport > package. > > > > the advantage of this over what it sounds like DIH currently does is that > > if there is an o.a.s.handler.dataimport.WizWatTransformer but someone > > wants to write their own (package less) WizWatTransformer they can and > > refer to it simply as "WizWatTransformer" (whereas to use the one that > > ships with DIH they would specify "solr.WizWatTransformer"). There's no > > ambiguity as to which one someone means unless they create a package > > called "solr" ... but then they'ed just be looking for trouble :) > > > > > > > > -Hoss > > > > > > > > -- > --Noble Paul >
Re: Slight issue with classloading and DataImportHandler
We plan to use SolrResourceLoader (in the next patch) . That is the best way to go. But we still prefer the usage of DIH package classes without any prefix. type="HttpDataSource" instead of type="solr.HttpDataSource" But users must be able to load their classes using the "solr." format --Noble On Thu, Jun 19, 2008 at 10:57 AM, Chris Hostetter <[EMAIL PROTECTED]> 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 . > > It would be better to use the classloader from the SolrResourceLoader ... > that should be safe for anyone with any setup. > >>> 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. >... >>> 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. > > FWIW: there isn't relaly a "solr." package ... "solr." can be used as > an short form alias for the "likely package" when Solr resolves classes, > where the "likely package" varies by context and there can be multiple > options that it tries in order > > DIH could do the same thing, letting short form "solr." signify that > Transformers, Evaluators, etc are in the o.a.s.handler.dataimport package. > > the advantage of this over what it sounds like DIH currently does is that > if there is an o.a.s.handler.dataimport.WizWatTransformer but someone > wants to write their own (package less) WizWatTransformer they can and > refer to it simply as "WizWatTransformer" (whereas to use the one that > ships with DIH they would specify "solr.WizWatTransformer"). There's no > ambiguity as to which one someone means unless they create a package > called "solr" ... but then they'ed just be looking for trouble :) > > > > -Hoss > > -- --Noble Paul
Re: Slight issue with classloading and DataImportHandler
: 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 . It would be better to use the classloader from the SolrResourceLoader ... that should be safe for anyone with any setup. >> 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. ... >> 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. FWIW: there isn't relaly a "solr." package ... "solr." can be used as an short form alias for the "likely package" when Solr resolves classes, where the "likely package" varies by context and there can be multiple options that it tries in order DIH could do the same thing, letting short form "solr." signify that Transformers, Evaluators, etc are in the o.a.s.handler.dataimport package. the advantage of this over what it sounds like DIH currently does is that if there is an o.a.s.handler.dataimport.WizWatTransformer but someone wants to write their own (package less) WizWatTransformer they can and refer to it simply as "WizWatTransformer" (whereas to use the one that ships with DIH they would specify "solr.WizWatTransformer"). There's no ambiguity as to which one someone means unless they create a package called "solr" ... but then they'ed just be looking for trouble :) -Hoss
Re: Slight issue with classloading and DataImportHandler
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
Re: Slight issue with classloading and DataImportHandler
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
Re: Slight issue with classloading and DataImportHandler
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
Re: Slight issue with classloading and DataImportHandler
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
Re: Slight issue with classloading and DataImportHandler
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
Slight issue with classloading and DataImportHandler
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
