Odd casting error in embedded Jetty container

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Odd casting error in embedded Jetty container

mbennett
I'm sure this is some config error, but I've checked a lot of things and
not finding much on Google.  Not sure if it's a jvm, maven, jetty or solr
config issue.

I'm running with a custom Solr 4.0.0 app under Jetty 8.1.2, with a clone of
the example directory tree.

The main error seems to be:
    java.lang.ClassCastException: class
org.apache.lucene.codecs.mockintblock.*MockFixedIntBlockPostingsFormat*
        ...
    at org.apache.lucene.util.NamedSPILoader.<init>(*NamedSPILoader*
.java:37)
    at org.apache.lucene.codecs.PostingsFormat.<clinit>(*PostingsFormat*
.java:44)

I've added jars to the class path, and iteratively stripped down my configs
to the bare essentials.

It's odd that it talks about a Mock class as I'd normally associate that
with unit tests; presumably that's part of the Service Loader mechanism.

Error logs:
WARNING: FAILED SolrRequestFilter: java.lang.ExceptionInInitializerError
java.lang.ExceptionInInitializerError
    at
org.apache.solr.core.SolrResourceLoader.reloadLuceneSPI(SolrResourceLoader.java:179)
    at
org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:113)
    at
org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:228)
    at org.apache.solr.core.Config.<init>(Config.java:94)
    at org.apache.solr.core.Config.<init>(Config.java:73)
    at
org.apache.solr.servlet.SolrDispatchFilter.<init>(SolrDispatchFilter.java:91)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
    at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
    at java.lang.Class.newInstance0(Class.java:355)
    at java.lang.Class.newInstance(Class.java:308)
    at
org.eclipse.jetty.servlet.ServletContextHandler$Context.createFilter(ServletContextHandler.java:951)
...
Caused by: java.lang.ClassCastException: class
org.apache.lucene.codecs.mockintblock.MockFixedIntBlockPostingsFormat
    at java.lang.Class.asSubclass(Class.java:3018)
    at
org.apache.lucene.util.SPIClassIterator.next(SPIClassIterator.java:126)
    at org.apache.lucene.util.NamedSPILoader.reload(NamedSPILoader.java:60)
    at org.apache.lucene.util.NamedSPILoader.<init>(NamedSPILoader.java:42)
    at org.apache.lucene.util.NamedSPILoader.<init>(NamedSPILoader.java:37)
    at
org.apache.lucene.codecs.PostingsFormat.<clinit>(PostingsFormat.java:44)
    ... 56 more

Later I see:
WARNING: FAILED
o.e.j.w.WebAppContext{/solr,file:.../},target/classes/jettyhome/webapps/solr.war:
java.lang.ExceptionInInitializerError
java.lang.ExceptionInInitializerError
    at
org.apache.solr.core.SolrResourceLoader.reloadLuceneSPI(SolrResourceLoader.java:179)
    at
org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:113)
    at
org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:228)
    at org.apache.solr.core.Config.<init>(Config.java:94)
    at org.apache.solr.core.Config.<init>(Config.java:73)
    at
org.apache.solr.servlet.SolrDispatchFilter.<init>(SolrDispatchFilter.java:91)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
    at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
    at java.lang.Class.newInstance0(Class.java:355)
    at java.lang.Class.newInstance(Class.java:308)
    at
org.eclipse.jetty.servlet.ServletContextHandler$Context.createFilter(ServletContextHandler.java:951)


--
Mark Bennett / New Idea Engineering, Inc. / [hidden email]
Direct: 408-733-0387 / Main: 866-IDEA-ENG / Cell: 408-829-6513
Reply | Threaded
Open this post in threaded view
|

Re: Odd casting error in embedded Jetty container

Erick Erickson
Sure looks like you're mixing up jars from old and new Solrs somehow. You've
stripped down the classpath, but what about the solr libraries? All the
things that
can be defined in <lib> directives in solrconfig.xml?

Not much help I know, but the best I can think of.
Erick


On Mon, Nov 26, 2012 at 7:38 PM, Mark Bennett <[hidden email]> wrote:

> I'm sure this is some config error, but I've checked a lot of things and
> not finding much on Google.  Not sure if it's a jvm, maven, jetty or solr
> config issue.
>
> I'm running with a custom Solr 4.0.0 app under Jetty 8.1.2, with a clone of
> the example directory tree.
>
> The main error seems to be:
>     java.lang.ClassCastException: class
> org.apache.lucene.codecs.mockintblock.*MockFixedIntBlockPostingsFormat*
>         ...
>     at org.apache.lucene.util.NamedSPILoader.<init>(*NamedSPILoader*
> .java:37)
>     at org.apache.lucene.codecs.PostingsFormat.<clinit>(*PostingsFormat*
> .java:44)
>
> I've added jars to the class path, and iteratively stripped down my configs
> to the bare essentials.
>
> It's odd that it talks about a Mock class as I'd normally associate that
> with unit tests; presumably that's part of the Service Loader mechanism.
>
> Error logs:
> WARNING: FAILED SolrRequestFilter: java.lang.ExceptionInInitializerError
> java.lang.ExceptionInInitializerError
>     at
>
> org.apache.solr.core.SolrResourceLoader.reloadLuceneSPI(SolrResourceLoader.java:179)
>     at
> org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:113)
>     at
> org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:228)
>     at org.apache.solr.core.Config.<init>(Config.java:94)
>     at org.apache.solr.core.Config.<init>(Config.java:73)
>     at
>
> org.apache.solr.servlet.SolrDispatchFilter.<init>(SolrDispatchFilter.java:91)
>     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>     at
>
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>     at
>
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>     at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>     at java.lang.Class.newInstance0(Class.java:355)
>     at java.lang.Class.newInstance(Class.java:308)
>     at
>
> org.eclipse.jetty.servlet.ServletContextHandler$Context.createFilter(ServletContextHandler.java:951)
> ...
> Caused by: java.lang.ClassCastException: class
> org.apache.lucene.codecs.mockintblock.MockFixedIntBlockPostingsFormat
>     at java.lang.Class.asSubclass(Class.java:3018)
>     at
> org.apache.lucene.util.SPIClassIterator.next(SPIClassIterator.java:126)
>     at org.apache.lucene.util.NamedSPILoader.reload(NamedSPILoader.java:60)
>     at org.apache.lucene.util.NamedSPILoader.<init>(NamedSPILoader.java:42)
>     at org.apache.lucene.util.NamedSPILoader.<init>(NamedSPILoader.java:37)
>     at
> org.apache.lucene.codecs.PostingsFormat.<clinit>(PostingsFormat.java:44)
>     ... 56 more
>
> Later I see:
> WARNING: FAILED
>
> o.e.j.w.WebAppContext{/solr,file:.../},target/classes/jettyhome/webapps/solr.war:
> java.lang.ExceptionInInitializerError
> java.lang.ExceptionInInitializerError
>     at
>
> org.apache.solr.core.SolrResourceLoader.reloadLuceneSPI(SolrResourceLoader.java:179)
>     at
> org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:113)
>     at
> org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:228)
>     at org.apache.solr.core.Config.<init>(Config.java:94)
>     at org.apache.solr.core.Config.<init>(Config.java:73)
>     at
>
> org.apache.solr.servlet.SolrDispatchFilter.<init>(SolrDispatchFilter.java:91)
>     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>     at
>
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>     at
>
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>     at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>     at java.lang.Class.newInstance0(Class.java:355)
>     at java.lang.Class.newInstance(Class.java:308)
>     at
>
> org.eclipse.jetty.servlet.ServletContextHandler$Context.createFilter(ServletContextHandler.java:951)
>
>
> --
> Mark Bennett / New Idea Engineering, Inc. / [hidden email]
> Direct: 408-733-0387 / Main: 866-IDEA-ENG / Cell: 408-829-6513
>
Reply | Threaded
Open this post in threaded view
|

Re: Odd casting error in embedded Jetty container

Alexandre Rafalovitch
I find it is best to troubleshoot path problems backwards. Run something
that logs every file access (SysInternal's Process Monitor on Windows,
truss/struss on *nix/Mac systems) and then grep for jars. You will see
exactly which jars are loaded from where and also which other jars the same
process looked for just before/after. That often can give you a hint of
where the requests are coming from. This method has a bit of a learning
curve the first time, but the time investment pays off really fast.

Shameless plus for - an old but still valid - presentation of mine on this:
http://www.infoq.com/presentations/maintaining-production-java-apps

Regards,
   Alex.

Personal blog: http://blog.outerthoughts.com/
LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch
- Time is the quality of nature that keeps events from happening all at
once. Lately, it doesn't seem to be working.  (Anonymous  - via GTD book)


On Tue, Nov 27, 2012 at 7:42 AM, Erick Erickson <[hidden email]>wrote:

> Sure looks like you're mixing up jars from old and new Solrs somehow.
> You've
> stripped down the classpath, but what about the solr libraries? All the
> things that
> can be defined in <lib> directives in solrconfig.xml?
>
> Not much help I know, but the best I can think of.
> Erick
>
>
> On Mon, Nov 26, 2012 at 7:38 PM, Mark Bennett <[hidden email]>
> wrote:
>
> > I'm sure this is some config error, but I've checked a lot of things and
> > not finding much on Google.  Not sure if it's a jvm, maven, jetty or solr
> > config issue.
> >
> > I'm running with a custom Solr 4.0.0 app under Jetty 8.1.2, with a clone
> of
> > the example directory tree.
> >
> > The main error seems to be:
> >     java.lang.ClassCastException: class
> > org.apache.lucene.codecs.mockintblock.*MockFixedIntBlockPostingsFormat*
> >         ...
> >     at org.apache.lucene.util.NamedSPILoader.<init>(*NamedSPILoader*
> > .java:37)
> >     at org.apache.lucene.codecs.PostingsFormat.<clinit>(*PostingsFormat*
> > .java:44)
> >
> > I've added jars to the class path, and iteratively stripped down my
> configs
> > to the bare essentials.
> >
> > It's odd that it talks about a Mock class as I'd normally associate that
> > with unit tests; presumably that's part of the Service Loader mechanism.
> >
> > Error logs:
> > WARNING: FAILED SolrRequestFilter: java.lang.ExceptionInInitializerError
> > java.lang.ExceptionInInitializerError
> >     at
> >
> >
> org.apache.solr.core.SolrResourceLoader.reloadLuceneSPI(SolrResourceLoader.java:179)
> >     at
> >
> org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:113)
> >     at
> >
> org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:228)
> >     at org.apache.solr.core.Config.<init>(Config.java:94)
> >     at org.apache.solr.core.Config.<init>(Config.java:73)
> >     at
> >
> >
> org.apache.solr.servlet.SolrDispatchFilter.<init>(SolrDispatchFilter.java:91)
> >     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> > Method)
> >     at
> >
> >
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> >     at
> >
> >
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> >     at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> >     at java.lang.Class.newInstance0(Class.java:355)
> >     at java.lang.Class.newInstance(Class.java:308)
> >     at
> >
> >
> org.eclipse.jetty.servlet.ServletContextHandler$Context.createFilter(ServletContextHandler.java:951)
> > ...
> > Caused by: java.lang.ClassCastException: class
> > org.apache.lucene.codecs.mockintblock.MockFixedIntBlockPostingsFormat
> >     at java.lang.Class.asSubclass(Class.java:3018)
> >     at
> > org.apache.lucene.util.SPIClassIterator.next(SPIClassIterator.java:126)
> >     at
> org.apache.lucene.util.NamedSPILoader.reload(NamedSPILoader.java:60)
> >     at
> org.apache.lucene.util.NamedSPILoader.<init>(NamedSPILoader.java:42)
> >     at
> org.apache.lucene.util.NamedSPILoader.<init>(NamedSPILoader.java:37)
> >     at
> > org.apache.lucene.codecs.PostingsFormat.<clinit>(PostingsFormat.java:44)
> >     ... 56 more
> >
> > Later I see:
> > WARNING: FAILED
> >
> >
> o.e.j.w.WebAppContext{/solr,file:.../},target/classes/jettyhome/webapps/solr.war:
> > java.lang.ExceptionInInitializerError
> > java.lang.ExceptionInInitializerError
> >     at
> >
> >
> org.apache.solr.core.SolrResourceLoader.reloadLuceneSPI(SolrResourceLoader.java:179)
> >     at
> >
> org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:113)
> >     at
> >
> org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:228)
> >     at org.apache.solr.core.Config.<init>(Config.java:94)
> >     at org.apache.solr.core.Config.<init>(Config.java:73)
> >     at
> >
> >
> org.apache.solr.servlet.SolrDispatchFilter.<init>(SolrDispatchFilter.java:91)
> >     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> > Method)
> >     at
> >
> >
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> >     at
> >
> >
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> >     at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> >     at java.lang.Class.newInstance0(Class.java:355)
> >     at java.lang.Class.newInstance(Class.java:308)
> >     at
> >
> >
> org.eclipse.jetty.servlet.ServletContextHandler$Context.createFilter(ServletContextHandler.java:951)
> >
> >
> > --
> > Mark Bennett / New Idea Engineering, Inc. / [hidden email]
> > Direct: 408-733-0387 / Main: 866-IDEA-ENG / Cell: 408-829-6513
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Odd casting error in embedded Jetty container

mbennett
Erik & Alex,

If it still sounds like jars to you two, I'll take another whack in that
direction.

From previous Google searches I thought I had already eliminated that, but
logging every gosh-darn-jar and reviewing the list makes sense.

--
Mark Bennett / New Idea Engineering, Inc. / [hidden email]
Direct: 408-733-0387 / Main: 866-IDEA-ENG / Cell: 408-829-6513


On Tue, Nov 27, 2012 at 6:04 AM, Alexandre Rafalovitch
<[hidden email]>wrote:

> I find it is best to troubleshoot path problems backwards. Run something
> that logs every file access (SysInternal's Process Monitor on Windows,
> truss/struss on *nix/Mac systems) and then grep for jars. You will see
> exactly which jars are loaded from where and also which other jars the same
> process looked for just before/after. That often can give you a hint of
> where the requests are coming from. This method has a bit of a learning
> curve the first time, but the time investment pays off really fast.
>
> Shameless plus for - an old but still valid - presentation of mine on this:
> http://www.infoq.com/presentations/maintaining-production-java-apps
>
> Regards,
>    Alex.
>
> Personal blog: http://blog.outerthoughts.com/
> LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch
> - Time is the quality of nature that keeps events from happening all at
> once. Lately, it doesn't seem to be working.  (Anonymous  - via GTD book)
>
>
> On Tue, Nov 27, 2012 at 7:42 AM, Erick Erickson <[hidden email]
> >wrote:
>
> > Sure looks like you're mixing up jars from old and new Solrs somehow.
> > You've
> > stripped down the classpath, but what about the solr libraries? All the
> > things that
> > can be defined in <lib> directives in solrconfig.xml?
> >
> > Not much help I know, but the best I can think of.
> > Erick
> >
> >
> > On Mon, Nov 26, 2012 at 7:38 PM, Mark Bennett <[hidden email]>
> > wrote:
> >
> > > I'm sure this is some config error, but I've checked a lot of things
> and
> > > not finding much on Google.  Not sure if it's a jvm, maven, jetty or
> solr
> > > config issue.
> > >
> > > I'm running with a custom Solr 4.0.0 app under Jetty 8.1.2, with a
> clone
> > of
> > > the example directory tree.
> > >
> > > The main error seems to be:
> > >     java.lang.ClassCastException: class
> > > org.apache.lucene.codecs.mockintblock.*MockFixedIntBlockPostingsFormat*
> > >         ...
> > >     at org.apache.lucene.util.NamedSPILoader.<init>(*NamedSPILoader*
> > > .java:37)
> > >     at
> org.apache.lucene.codecs.PostingsFormat.<clinit>(*PostingsFormat*
> > > .java:44)
> > >
> > > I've added jars to the class path, and iteratively stripped down my
> > configs
> > > to the bare essentials.
> > >
> > > It's odd that it talks about a Mock class as I'd normally associate
> that
> > > with unit tests; presumably that's part of the Service Loader
> mechanism.
> > >
> > > Error logs:
> > > WARNING: FAILED SolrRequestFilter:
> java.lang.ExceptionInInitializerError
> > > java.lang.ExceptionInInitializerError
> > >     at
> > >
> > >
> >
> org.apache.solr.core.SolrResourceLoader.reloadLuceneSPI(SolrResourceLoader.java:179)
> > >     at
> > >
> >
> org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:113)
> > >     at
> > >
> >
> org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:228)
> > >     at org.apache.solr.core.Config.<init>(Config.java:94)
> > >     at org.apache.solr.core.Config.<init>(Config.java:73)
> > >     at
> > >
> > >
> >
> org.apache.solr.servlet.SolrDispatchFilter.<init>(SolrDispatchFilter.java:91)
> > >     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> > > Method)
> > >     at
> > >
> > >
> >
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> > >     at
> > >
> > >
> >
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> > >     at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> > >     at java.lang.Class.newInstance0(Class.java:355)
> > >     at java.lang.Class.newInstance(Class.java:308)
> > >     at
> > >
> > >
> >
> org.eclipse.jetty.servlet.ServletContextHandler$Context.createFilter(ServletContextHandler.java:951)
> > > ...
> > > Caused by: java.lang.ClassCastException: class
> > > org.apache.lucene.codecs.mockintblock.MockFixedIntBlockPostingsFormat
> > >     at java.lang.Class.asSubclass(Class.java:3018)
> > >     at
> > > org.apache.lucene.util.SPIClassIterator.next(SPIClassIterator.java:126)
> > >     at
> > org.apache.lucene.util.NamedSPILoader.reload(NamedSPILoader.java:60)
> > >     at
> > org.apache.lucene.util.NamedSPILoader.<init>(NamedSPILoader.java:42)
> > >     at
> > org.apache.lucene.util.NamedSPILoader.<init>(NamedSPILoader.java:37)
> > >     at
> > >
> org.apache.lucene.codecs.PostingsFormat.<clinit>(PostingsFormat.java:44)
> > >     ... 56 more
> > >
> > > Later I see:
> > > WARNING: FAILED
> > >
> > >
> >
> o.e.j.w.WebAppContext{/solr,file:.../},target/classes/jettyhome/webapps/solr.war:
> > > java.lang.ExceptionInInitializerError
> > > java.lang.ExceptionInInitializerError
> > >     at
> > >
> > >
> >
> org.apache.solr.core.SolrResourceLoader.reloadLuceneSPI(SolrResourceLoader.java:179)
> > >     at
> > >
> >
> org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:113)
> > >     at
> > >
> >
> org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:228)
> > >     at org.apache.solr.core.Config.<init>(Config.java:94)
> > >     at org.apache.solr.core.Config.<init>(Config.java:73)
> > >     at
> > >
> > >
> >
> org.apache.solr.servlet.SolrDispatchFilter.<init>(SolrDispatchFilter.java:91)
> > >     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> > > Method)
> > >     at
> > >
> > >
> >
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> > >     at
> > >
> > >
> >
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> > >     at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> > >     at java.lang.Class.newInstance0(Class.java:355)
> > >     at java.lang.Class.newInstance(Class.java:308)
> > >     at
> > >
> > >
> >
> org.eclipse.jetty.servlet.ServletContextHandler$Context.createFilter(ServletContextHandler.java:951)
> > >
> > >
> > > --
> > > Mark Bennett / New Idea Engineering, Inc. / [hidden email]
> > > Direct: 408-733-0387 / Main: 866-IDEA-ENG / Cell: 408-829-6513
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Odd casting error in embedded Jetty container

mbennett
In reply to this post by Alexandre Rafalovitch
Hi Alex and Erick,

I added -verbose which shows every class load.

From the 12,000+ lines of output, I only see 4.0.0 jars, wrt lucene and
solr.

lucene-analyzers-common-4.0.0.jar from 2 places:
/Users/username/.m2/repository/org/apache/lucene/lucene-analyzers-common/4.0.0
/Users/username/project/branch/workspace/Project/solr-webapp/webapp/WEB-INF/lib/

lucene-core-4.0.0.jar from 2 places: .m2 and WEB-INF/lib

SolrJ is a bit interesting:
file:/Users/username/.m2/repository/org/apache/solr/solr-solrj/4.0.0/solr-solrj-4.0.0.jar
file:/Users/username/project/workspace/Project/solr-webapp/webapp/WEB-INF/lib/
*apache*-solr-solrj-4.0.0.jar
Notice the different spelling, the "apache-" prefix on the latter.

apache-solr-core-4.0.0.jar just from WEB-INF/lib

lucene-analyzers-kuromoji-4.0.0.jar and lucene-analyzers-smartcn-4.0.0.jar
only from .m2

lucene-test-framework-4.0.0.jar only from .m2




On Tue, Nov 27, 2012 at 6:04 AM, Alexandre Rafalovitch
<[hidden email]>wrote:

> I find it is best to troubleshoot path problems backwards. Run something
> that logs every file access (SysInternal's Process Monitor on Windows,
> truss/struss on *nix/Mac systems) and then grep for jars. You will see
> exactly which jars are loaded from where and also which other jars the same
> process looked for just before/after. That often can give you a hint of
> where the requests are coming from. This method has a bit of a learning
> curve the first time, but the time investment pays off really fast.
>
> Shameless plus for - an old but still valid - presentation of mine on this:
> http://www.infoq.com/presentations/maintaining-production-java-apps
>
> Regards,
>    Alex.
>
> Personal blog: http://blog.outerthoughts.com/
> LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch
> - Time is the quality of nature that keeps events from happening all at
> once. Lately, it doesn't seem to be working.  (Anonymous  - via GTD book)
>
>
> On Tue, Nov 27, 2012 at 7:42 AM, Erick Erickson <[hidden email]
> >wrote:
>
> > Sure looks like you're mixing up jars from old and new Solrs somehow.
> > You've
> > stripped down the classpath, but what about the solr libraries? All the
> > things that
> > can be defined in <lib> directives in solrconfig.xml?
> >
> > Not much help I know, but the best I can think of.
> > Erick
> >
> >
> > On Mon, Nov 26, 2012 at 7:38 PM, Mark Bennett <[hidden email]>
> > wrote:
> >
> > > I'm sure this is some config error, but I've checked a lot of things
> and
> > > not finding much on Google.  Not sure if it's a jvm, maven, jetty or
> solr
> > > config issue.
> > >
> > > I'm running with a custom Solr 4.0.0 app under Jetty 8.1.2, with a
> clone
> > of
> > > the example directory tree.
> > >
> > > The main error seems to be:
> > >     java.lang.ClassCastException: class
> > > org.apache.lucene.codecs.mockintblock.*MockFixedIntBlockPostingsFormat*
> > >         ...
> > >     at org.apache.lucene.util.NamedSPILoader.<init>(*NamedSPILoader*
> > > .java:37)
> > >     at
> org.apache.lucene.codecs.PostingsFormat.<clinit>(*PostingsFormat*
> > > .java:44)
> > >
> > > I've added jars to the class path, and iteratively stripped down my
> > configs
> > > to the bare essentials.
> > >
> > > It's odd that it talks about a Mock class as I'd normally associate
> that
> > > with unit tests; presumably that's part of the Service Loader
> mechanism.
> > >
> > > Error logs:
> > > WARNING: FAILED SolrRequestFilter:
> java.lang.ExceptionInInitializerError
> > > java.lang.ExceptionInInitializerError
> > >     at
> > >
> > >
> >
> org.apache.solr.core.SolrResourceLoader.reloadLuceneSPI(SolrResourceLoader.java:179)
> > >     at
> > >
> >
> org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:113)
> > >     at
> > >
> >
> org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:228)
> > >     at org.apache.solr.core.Config.<init>(Config.java:94)
> > >     at org.apache.solr.core.Config.<init>(Config.java:73)
> > >     at
> > >
> > >
> >
> org.apache.solr.servlet.SolrDispatchFilter.<init>(SolrDispatchFilter.java:91)
> > >     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> > > Method)
> > >     at
> > >
> > >
> >
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> > >     at
> > >
> > >
> >
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> > >     at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> > >     at java.lang.Class.newInstance0(Class.java:355)
> > >     at java.lang.Class.newInstance(Class.java:308)
> > >     at
> > >
> > >
> >
> org.eclipse.jetty.servlet.ServletContextHandler$Context.createFilter(ServletContextHandler.java:951)
> > > ...
> > > Caused by: java.lang.ClassCastException: class
> > > org.apache.lucene.codecs.mockintblock.MockFixedIntBlockPostingsFormat
> > >     at java.lang.Class.asSubclass(Class.java:3018)
> > >     at
> > > org.apache.lucene.util.SPIClassIterator.next(SPIClassIterator.java:126)
> > >     at
> > org.apache.lucene.util.NamedSPILoader.reload(NamedSPILoader.java:60)
> > >     at
> > org.apache.lucene.util.NamedSPILoader.<init>(NamedSPILoader.java:42)
> > >     at
> > org.apache.lucene.util.NamedSPILoader.<init>(NamedSPILoader.java:37)
> > >     at
> > >
> org.apache.lucene.codecs.PostingsFormat.<clinit>(PostingsFormat.java:44)
> > >     ... 56 more
> > >
> > > Later I see:
> > > WARNING: FAILED
> > >
> > >
> >
> o.e.j.w.WebAppContext{/solr,file:.../},target/classes/jettyhome/webapps/solr.war:
> > > java.lang.ExceptionInInitializerError
> > > java.lang.ExceptionInInitializerError
> > >     at
> > >
> > >
> >
> org.apache.solr.core.SolrResourceLoader.reloadLuceneSPI(SolrResourceLoader.java:179)
> > >     at
> > >
> >
> org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:113)
> > >     at
> > >
> >
> org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:228)
> > >     at org.apache.solr.core.Config.<init>(Config.java:94)
> > >     at org.apache.solr.core.Config.<init>(Config.java:73)
> > >     at
> > >
> > >
> >
> org.apache.solr.servlet.SolrDispatchFilter.<init>(SolrDispatchFilter.java:91)
> > >     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> > > Method)
> > >     at
> > >
> > >
> >
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> > >     at
> > >
> > >
> >
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> > >     at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> > >     at java.lang.Class.newInstance0(Class.java:355)
> > >     at java.lang.Class.newInstance(Class.java:308)
> > >     at
> > >
> > >
> >
> org.eclipse.jetty.servlet.ServletContextHandler$Context.createFilter(ServletContextHandler.java:951)
> > >
> > >
> > > --
> > > Mark Bennett / New Idea Engineering, Inc. / [hidden email]
> > > Direct: 408-733-0387 / Main: 866-IDEA-ENG / Cell: 408-829-6513
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Odd casting error in embedded Jetty container

Erick Erickson
Well, it was a nice theory..... Siiigggghhh....


On Tue, Nov 27, 2012 at 4:49 PM, Mark Bennett <[hidden email]> wrote:

> Hi Alex and Erick,
>
> I added -verbose which shows every class load.
>
> From the 12,000+ lines of output, I only see 4.0.0 jars, wrt lucene and
> solr.
>
> lucene-analyzers-common-4.0.0.jar from 2 places:
>
> /Users/username/.m2/repository/org/apache/lucene/lucene-analyzers-common/4.0.0
>
> /Users/username/project/branch/workspace/Project/solr-webapp/webapp/WEB-INF/lib/
>
> lucene-core-4.0.0.jar from 2 places: .m2 and WEB-INF/lib
>
> SolrJ is a bit interesting:
>
> file:/Users/username/.m2/repository/org/apache/solr/solr-solrj/4.0.0/solr-solrj-4.0.0.jar
>
> file:/Users/username/project/workspace/Project/solr-webapp/webapp/WEB-INF/lib/
> *apache*-solr-solrj-4.0.0.jar
> Notice the different spelling, the "apache-" prefix on the latter.
>
> apache-solr-core-4.0.0.jar just from WEB-INF/lib
>
> lucene-analyzers-kuromoji-4.0.0.jar and lucene-analyzers-smartcn-4.0.0.jar
> only from .m2
>
> lucene-test-framework-4.0.0.jar only from .m2
>
>
>
>
> On Tue, Nov 27, 2012 at 6:04 AM, Alexandre Rafalovitch
> <[hidden email]>wrote:
>
> > I find it is best to troubleshoot path problems backwards. Run something
> > that logs every file access (SysInternal's Process Monitor on Windows,
> > truss/struss on *nix/Mac systems) and then grep for jars. You will see
> > exactly which jars are loaded from where and also which other jars the
> same
> > process looked for just before/after. That often can give you a hint of
> > where the requests are coming from. This method has a bit of a learning
> > curve the first time, but the time investment pays off really fast.
> >
> > Shameless plus for - an old but still valid - presentation of mine on
> this:
> > http://www.infoq.com/presentations/maintaining-production-java-apps
> >
> > Regards,
> >    Alex.
> >
> > Personal blog: http://blog.outerthoughts.com/
> > LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch
> > - Time is the quality of nature that keeps events from happening all at
> > once. Lately, it doesn't seem to be working.  (Anonymous  - via GTD book)
> >
> >
> > On Tue, Nov 27, 2012 at 7:42 AM, Erick Erickson <[hidden email]
> > >wrote:
> >
> > > Sure looks like you're mixing up jars from old and new Solrs somehow.
> > > You've
> > > stripped down the classpath, but what about the solr libraries? All the
> > > things that
> > > can be defined in <lib> directives in solrconfig.xml?
> > >
> > > Not much help I know, but the best I can think of.
> > > Erick
> > >
> > >
> > > On Mon, Nov 26, 2012 at 7:38 PM, Mark Bennett <[hidden email]>
> > > wrote:
> > >
> > > > I'm sure this is some config error, but I've checked a lot of things
> > and
> > > > not finding much on Google.  Not sure if it's a jvm, maven, jetty or
> > solr
> > > > config issue.
> > > >
> > > > I'm running with a custom Solr 4.0.0 app under Jetty 8.1.2, with a
> > clone
> > > of
> > > > the example directory tree.
> > > >
> > > > The main error seems to be:
> > > >     java.lang.ClassCastException: class
> > > >
> org.apache.lucene.codecs.mockintblock.*MockFixedIntBlockPostingsFormat*
> > > >         ...
> > > >     at org.apache.lucene.util.NamedSPILoader.<init>(*NamedSPILoader*
> > > > .java:37)
> > > >     at
> > org.apache.lucene.codecs.PostingsFormat.<clinit>(*PostingsFormat*
> > > > .java:44)
> > > >
> > > > I've added jars to the class path, and iteratively stripped down my
> > > configs
> > > > to the bare essentials.
> > > >
> > > > It's odd that it talks about a Mock class as I'd normally associate
> > that
> > > > with unit tests; presumably that's part of the Service Loader
> > mechanism.
> > > >
> > > > Error logs:
> > > > WARNING: FAILED SolrRequestFilter:
> > java.lang.ExceptionInInitializerError
> > > > java.lang.ExceptionInInitializerError
> > > >     at
> > > >
> > > >
> > >
> >
> org.apache.solr.core.SolrResourceLoader.reloadLuceneSPI(SolrResourceLoader.java:179)
> > > >     at
> > > >
> > >
> >
> org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:113)
> > > >     at
> > > >
> > >
> >
> org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:228)
> > > >     at org.apache.solr.core.Config.<init>(Config.java:94)
> > > >     at org.apache.solr.core.Config.<init>(Config.java:73)
> > > >     at
> > > >
> > > >
> > >
> >
> org.apache.solr.servlet.SolrDispatchFilter.<init>(SolrDispatchFilter.java:91)
> > > >     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> > > > Method)
> > > >     at
> > > >
> > > >
> > >
> >
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> > > >     at
> > > >
> > > >
> > >
> >
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> > > >     at
> java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> > > >     at java.lang.Class.newInstance0(Class.java:355)
> > > >     at java.lang.Class.newInstance(Class.java:308)
> > > >     at
> > > >
> > > >
> > >
> >
> org.eclipse.jetty.servlet.ServletContextHandler$Context.createFilter(ServletContextHandler.java:951)
> > > > ...
> > > > Caused by: java.lang.ClassCastException: class
> > > > org.apache.lucene.codecs.mockintblock.MockFixedIntBlockPostingsFormat
> > > >     at java.lang.Class.asSubclass(Class.java:3018)
> > > >     at
> > > >
> org.apache.lucene.util.SPIClassIterator.next(SPIClassIterator.java:126)
> > > >     at
> > > org.apache.lucene.util.NamedSPILoader.reload(NamedSPILoader.java:60)
> > > >     at
> > > org.apache.lucene.util.NamedSPILoader.<init>(NamedSPILoader.java:42)
> > > >     at
> > > org.apache.lucene.util.NamedSPILoader.<init>(NamedSPILoader.java:37)
> > > >     at
> > > >
> > org.apache.lucene.codecs.PostingsFormat.<clinit>(PostingsFormat.java:44)
> > > >     ... 56 more
> > > >
> > > > Later I see:
> > > > WARNING: FAILED
> > > >
> > > >
> > >
> >
> o.e.j.w.WebAppContext{/solr,file:.../},target/classes/jettyhome/webapps/solr.war:
> > > > java.lang.ExceptionInInitializerError
> > > > java.lang.ExceptionInInitializerError
> > > >     at
> > > >
> > > >
> > >
> >
> org.apache.solr.core.SolrResourceLoader.reloadLuceneSPI(SolrResourceLoader.java:179)
> > > >     at
> > > >
> > >
> >
> org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:113)
> > > >     at
> > > >
> > >
> >
> org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:228)
> > > >     at org.apache.solr.core.Config.<init>(Config.java:94)
> > > >     at org.apache.solr.core.Config.<init>(Config.java:73)
> > > >     at
> > > >
> > > >
> > >
> >
> org.apache.solr.servlet.SolrDispatchFilter.<init>(SolrDispatchFilter.java:91)
> > > >     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> > > > Method)
> > > >     at
> > > >
> > > >
> > >
> >
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> > > >     at
> > > >
> > > >
> > >
> >
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> > > >     at
> java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> > > >     at java.lang.Class.newInstance0(Class.java:355)
> > > >     at java.lang.Class.newInstance(Class.java:308)
> > > >     at
> > > >
> > > >
> > >
> >
> org.eclipse.jetty.servlet.ServletContextHandler$Context.createFilter(ServletContextHandler.java:951)
> > > >
> > > >
> > > > --
> > > > Mark Bennett / New Idea Engineering, Inc. / [hidden email]
> > > > Direct: 408-733-0387 / Main: 866-IDEA-ENG / Cell: 408-829-6513
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Odd casting error in embedded Jetty container

Alexandre Rafalovitch
In reply to this post by mbennett
Are you sure that NamedSPILoader respects -verbose flag? I would still
check the filesystem access using something that does not lie (see my old
email).

Regards,
   Alex.

Personal blog: http://blog.outerthoughts.com/
LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch
- Time is the quality of nature that keeps events from happening all at
once. Lately, it doesn't seem to be working.  (Anonymous  - via GTD book)


On Tue, Nov 27, 2012 at 4:49 PM, Mark Bennett <[hidden email]> wrote:

> Hi Alex and Erick,
>
> I added -verbose which shows every class load.
>
> From the 12,000+ lines of output, I only see 4.0.0 jars, wrt lucene and
> solr.
>
> lucene-analyzers-common-4.0.0.jar from 2 places:
>
> /Users/username/.m2/repository/org/apache/lucene/lucene-analyzers-common/4.0.0
>
> /Users/username/project/branch/workspace/Project/solr-webapp/webapp/WEB-INF/lib/
>
> lucene-core-4.0.0.jar from 2 places: .m2 and WEB-INF/lib
>
> SolrJ is a bit interesting:
>
> file:/Users/username/.m2/repository/org/apache/solr/solr-solrj/4.0.0/solr-solrj-4.0.0.jar
>
> file:/Users/username/project/workspace/Project/solr-webapp/webapp/WEB-INF/lib/
> *apache*-solr-solrj-4.0.0.jar
> Notice the different spelling, the "apache-" prefix on the latter.
>
> apache-solr-core-4.0.0.jar just from WEB-INF/lib
>
> lucene-analyzers-kuromoji-4.0.0.jar and lucene-analyzers-smartcn-4.0.0.jar
> only from .m2
>
> lucene-test-framework-4.0.0.jar only from .m2
>
>
>
>
> On Tue, Nov 27, 2012 at 6:04 AM, Alexandre Rafalovitch
> <[hidden email]>wrote:
>
> > I find it is best to troubleshoot path problems backwards. Run something
> > that logs every file access (SysInternal's Process Monitor on Windows,
> > truss/struss on *nix/Mac systems) and then grep for jars. You will see
> > exactly which jars are loaded from where and also which other jars the
> same
> > process looked for just before/after. That often can give you a hint of
> > where the requests are coming from. This method has a bit of a learning
> > curve the first time, but the time investment pays off really fast.
> >
> > Shameless plus for - an old but still valid - presentation of mine on
> this:
> > http://www.infoq.com/presentations/maintaining-production-java-apps
> >
> > Regards,
> >    Alex.
> >
> > Personal blog: http://blog.outerthoughts.com/
> > LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch
> > - Time is the quality of nature that keeps events from happening all at
> > once. Lately, it doesn't seem to be working.  (Anonymous  - via GTD book)
> >
> >
> > On Tue, Nov 27, 2012 at 7:42 AM, Erick Erickson <[hidden email]
> > >wrote:
> >
> > > Sure looks like you're mixing up jars from old and new Solrs somehow.
> > > You've
> > > stripped down the classpath, but what about the solr libraries? All the
> > > things that
> > > can be defined in <lib> directives in solrconfig.xml?
> > >
> > > Not much help I know, but the best I can think of.
> > > Erick
> > >
> > >
> > > On Mon, Nov 26, 2012 at 7:38 PM, Mark Bennett <[hidden email]>
> > > wrote:
> > >
> > > > I'm sure this is some config error, but I've checked a lot of things
> > and
> > > > not finding much on Google.  Not sure if it's a jvm, maven, jetty or
> > solr
> > > > config issue.
> > > >
> > > > I'm running with a custom Solr 4.0.0 app under Jetty 8.1.2, with a
> > clone
> > > of
> > > > the example directory tree.
> > > >
> > > > The main error seems to be:
> > > >     java.lang.ClassCastException: class
> > > >
> org.apache.lucene.codecs.mockintblock.*MockFixedIntBlockPostingsFormat*
> > > >         ...
> > > >     at org.apache.lucene.util.NamedSPILoader.<init>(*NamedSPILoader*
> > > > .java:37)
> > > >     at
> > org.apache.lucene.codecs.PostingsFormat.<clinit>(*PostingsFormat*
> > > > .java:44)
> > > >
> > > > I've added jars to the class path, and iteratively stripped down my
> > > configs
> > > > to the bare essentials.
> > > >
> > > > It's odd that it talks about a Mock class as I'd normally associate
> > that
> > > > with unit tests; presumably that's part of the Service Loader
> > mechanism.
> > > >
> > > > Error logs:
> > > > WARNING: FAILED SolrRequestFilter:
> > java.lang.ExceptionInInitializerError
> > > > java.lang.ExceptionInInitializerError
> > > >     at
> > > >
> > > >
> > >
> >
> org.apache.solr.core.SolrResourceLoader.reloadLuceneSPI(SolrResourceLoader.java:179)
> > > >     at
> > > >
> > >
> >
> org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:113)
> > > >     at
> > > >
> > >
> >
> org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:228)
> > > >     at org.apache.solr.core.Config.<init>(Config.java:94)
> > > >     at org.apache.solr.core.Config.<init>(Config.java:73)
> > > >     at
> > > >
> > > >
> > >
> >
> org.apache.solr.servlet.SolrDispatchFilter.<init>(SolrDispatchFilter.java:91)
> > > >     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> > > > Method)
> > > >     at
> > > >
> > > >
> > >
> >
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> > > >     at
> > > >
> > > >
> > >
> >
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> > > >     at
> java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> > > >     at java.lang.Class.newInstance0(Class.java:355)
> > > >     at java.lang.Class.newInstance(Class.java:308)
> > > >     at
> > > >
> > > >
> > >
> >
> org.eclipse.jetty.servlet.ServletContextHandler$Context.createFilter(ServletContextHandler.java:951)
> > > > ...
> > > > Caused by: java.lang.ClassCastException: class
> > > > org.apache.lucene.codecs.mockintblock.MockFixedIntBlockPostingsFormat
> > > >     at java.lang.Class.asSubclass(Class.java:3018)
> > > >     at
> > > >
> org.apache.lucene.util.SPIClassIterator.next(SPIClassIterator.java:126)
> > > >     at
> > > org.apache.lucene.util.NamedSPILoader.reload(NamedSPILoader.java:60)
> > > >     at
> > > org.apache.lucene.util.NamedSPILoader.<init>(NamedSPILoader.java:42)
> > > >     at
> > > org.apache.lucene.util.NamedSPILoader.<init>(NamedSPILoader.java:37)
> > > >     at
> > > >
> > org.apache.lucene.codecs.PostingsFormat.<clinit>(PostingsFormat.java:44)
> > > >     ... 56 more
> > > >
> > > > Later I see:
> > > > WARNING: FAILED
> > > >
> > > >
> > >
> >
> o.e.j.w.WebAppContext{/solr,file:.../},target/classes/jettyhome/webapps/solr.war:
> > > > java.lang.ExceptionInInitializerError
> > > > java.lang.ExceptionInInitializerError
> > > >     at
> > > >
> > > >
> > >
> >
> org.apache.solr.core.SolrResourceLoader.reloadLuceneSPI(SolrResourceLoader.java:179)
> > > >     at
> > > >
> > >
> >
> org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:113)
> > > >     at
> > > >
> > >
> >
> org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:228)
> > > >     at org.apache.solr.core.Config.<init>(Config.java:94)
> > > >     at org.apache.solr.core.Config.<init>(Config.java:73)
> > > >     at
> > > >
> > > >
> > >
> >
> org.apache.solr.servlet.SolrDispatchFilter.<init>(SolrDispatchFilter.java:91)
> > > >     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> > > > Method)
> > > >     at
> > > >
> > > >
> > >
> >
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> > > >     at
> > > >
> > > >
> > >
> >
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> > > >     at
> java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> > > >     at java.lang.Class.newInstance0(Class.java:355)
> > > >     at java.lang.Class.newInstance(Class.java:308)
> > > >     at
> > > >
> > > >
> > >
> >
> org.eclipse.jetty.servlet.ServletContextHandler$Context.createFilter(ServletContextHandler.java:951)
> > > >
> > > >
> > > > --
> > > > Mark Bennett / New Idea Engineering, Inc. / [hidden email]
> > > > Direct: 408-733-0387 / Main: 866-IDEA-ENG / Cell: 408-829-6513
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Odd casting error in embedded Jetty container

Chris Hostetter-3

: > lucene-analyzers-common-4.0.0.jar from 2 places:
: >
: > /Users/username/.m2/repository/org/apache/lucene/lucene-analyzers-common/4.0.0
: >
: > /Users/username/project/branch/workspace/Project/solr-webapp/webapp/WEB-INF/lib/

Why are identical jars getting loaded from two differnet places?  what in
your config is loading jars from your .m2 cache?!?!?!

Having two versions of the same class show up in your classpath is exactly
the sort of thing that will cause a ClassCastException.   Two classes with
the same name and the same byte code loaded by two different class
loaders are not the same class as far as the JVM is concerned, and any
subsequent attempts to use one in place of the other will throw
ClassCastException...

http://onjava.com/pub/a/onjava/2003/11/12/classloader.html
(skip down to "Class Definition" if impatient)

: > lucene-test-framework-4.0.0.jar only from .m2

...that jar is the reason why you are seeing attempts to load the
MockFixedIntBlockPostingsFormat at all.  I re-iterate my earlier question:
what in your setup is attempting to load jars from your .m2 cache --
because that really makes no sense to me at all.

: > > > > It's odd that it talks about a Mock class as I'd normally associate
: > > that
: > > > > with unit tests; presumably that's part of the Service Loader
: > > mechanism.


-Hoss
Reply | Threaded
Open this post in threaded view
|

Re: Odd casting error in embedded Jetty container

mbennett
In reply to this post by Alexandre Rafalovitch
OK Alex.

BTW, I did go through your presentation, and even emailed it to some
cohorts of mine.


On Tue, Nov 27, 2012 at 5:58 PM, Alexandre Rafalovitch
<[hidden email]>wrote:

> Are you sure that NamedSPILoader respects -verbose flag? I would still
> check the filesystem access using something that does not lie (see my old
> email).
>
> Regards,
>    Alex.
>
> Personal blog: http://blog.outerthoughts.com/
> LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch
> - Time is the quality of nature that keeps events from happening all at
> once. Lately, it doesn't seem to be working.  (Anonymous  - via GTD book)
>
>
> On Tue, Nov 27, 2012 at 4:49 PM, Mark Bennett <[hidden email]>
> wrote:
>
> > Hi Alex and Erick,
> >
> > I added -verbose which shows every class load.
> >
> > From the 12,000+ lines of output, I only see 4.0.0 jars, wrt lucene and
> > solr.
> >
> > lucene-analyzers-common-4.0.0.jar from 2 places:
> >
> >
> /Users/username/.m2/repository/org/apache/lucene/lucene-analyzers-common/4.0.0
> >
> >
> /Users/username/project/branch/workspace/Project/solr-webapp/webapp/WEB-INF/lib/
> >
> > lucene-core-4.0.0.jar from 2 places: .m2 and WEB-INF/lib
> >
> > SolrJ is a bit interesting:
> >
> >
> file:/Users/username/.m2/repository/org/apache/solr/solr-solrj/4.0.0/solr-solrj-4.0.0.jar
> >
> >
> file:/Users/username/project/workspace/Project/solr-webapp/webapp/WEB-INF/lib/
> > *apache*-solr-solrj-4.0.0.jar
> > Notice the different spelling, the "apache-" prefix on the latter.
> >
> > apache-solr-core-4.0.0.jar just from WEB-INF/lib
> >
> > lucene-analyzers-kuromoji-4.0.0.jar and
> lucene-analyzers-smartcn-4.0.0.jar
> > only from .m2
> >
> > lucene-test-framework-4.0.0.jar only from .m2
> >
> >
> >
> >
> > On Tue, Nov 27, 2012 at 6:04 AM, Alexandre Rafalovitch
> > <[hidden email]>wrote:
> >
> > > I find it is best to troubleshoot path problems backwards. Run
> something
> > > that logs every file access (SysInternal's Process Monitor on Windows,
> > > truss/struss on *nix/Mac systems) and then grep for jars. You will see
> > > exactly which jars are loaded from where and also which other jars the
> > same
> > > process looked for just before/after. That often can give you a hint of
> > > where the requests are coming from. This method has a bit of a learning
> > > curve the first time, but the time investment pays off really fast.
> > >
> > > Shameless plus for - an old but still valid - presentation of mine on
> > this:
> > > http://www.infoq.com/presentations/maintaining-production-java-apps
> > >
> > > Regards,
> > >    Alex.
> > >
> > > Personal blog: http://blog.outerthoughts.com/
> > > LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch
> > > - Time is the quality of nature that keeps events from happening all at
> > > once. Lately, it doesn't seem to be working.  (Anonymous  - via GTD
> book)
> > >
> > >
> > > On Tue, Nov 27, 2012 at 7:42 AM, Erick Erickson <
> [hidden email]
> > > >wrote:
> > >
> > > > Sure looks like you're mixing up jars from old and new Solrs somehow.
> > > > You've
> > > > stripped down the classpath, but what about the solr libraries? All
> the
> > > > things that
> > > > can be defined in <lib> directives in solrconfig.xml?
> > > >
> > > > Not much help I know, but the best I can think of.
> > > > Erick
> > > >
> > > >
> > > > On Mon, Nov 26, 2012 at 7:38 PM, Mark Bennett <[hidden email]>
> > > > wrote:
> > > >
> > > > > I'm sure this is some config error, but I've checked a lot of
> things
> > > and
> > > > > not finding much on Google.  Not sure if it's a jvm, maven, jetty
> or
> > > solr
> > > > > config issue.
> > > > >
> > > > > I'm running with a custom Solr 4.0.0 app under Jetty 8.1.2, with a
> > > clone
> > > > of
> > > > > the example directory tree.
> > > > >
> > > > > The main error seems to be:
> > > > >     java.lang.ClassCastException: class
> > > > >
> > org.apache.lucene.codecs.mockintblock.*MockFixedIntBlockPostingsFormat*
> > > > >         ...
> > > > >     at
> org.apache.lucene.util.NamedSPILoader.<init>(*NamedSPILoader*
> > > > > .java:37)
> > > > >     at
> > > org.apache.lucene.codecs.PostingsFormat.<clinit>(*PostingsFormat*
> > > > > .java:44)
> > > > >
> > > > > I've added jars to the class path, and iteratively stripped down my
> > > > configs
> > > > > to the bare essentials.
> > > > >
> > > > > It's odd that it talks about a Mock class as I'd normally associate
> > > that
> > > > > with unit tests; presumably that's part of the Service Loader
> > > mechanism.
> > > > >
> > > > > Error logs:
> > > > > WARNING: FAILED SolrRequestFilter:
> > > java.lang.ExceptionInInitializerError
> > > > > java.lang.ExceptionInInitializerError
> > > > >     at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.solr.core.SolrResourceLoader.reloadLuceneSPI(SolrResourceLoader.java:179)
> > > > >     at
> > > > >
> > > >
> > >
> >
> org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:113)
> > > > >     at
> > > > >
> > > >
> > >
> >
> org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:228)
> > > > >     at org.apache.solr.core.Config.<init>(Config.java:94)
> > > > >     at org.apache.solr.core.Config.<init>(Config.java:73)
> > > > >     at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.solr.servlet.SolrDispatchFilter.<init>(SolrDispatchFilter.java:91)
> > > > >     at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> > > > > Method)
> > > > >     at
> > > > >
> > > > >
> > > >
> > >
> >
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> > > > >     at
> > > > >
> > > > >
> > > >
> > >
> >
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> > > > >     at
> > java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> > > > >     at java.lang.Class.newInstance0(Class.java:355)
> > > > >     at java.lang.Class.newInstance(Class.java:308)
> > > > >     at
> > > > >
> > > > >
> > > >
> > >
> >
> org.eclipse.jetty.servlet.ServletContextHandler$Context.createFilter(ServletContextHandler.java:951)
> > > > > ...
> > > > > Caused by: java.lang.ClassCastException: class
> > > > >
> org.apache.lucene.codecs.mockintblock.MockFixedIntBlockPostingsFormat
> > > > >     at java.lang.Class.asSubclass(Class.java:3018)
> > > > >     at
> > > > >
> > org.apache.lucene.util.SPIClassIterator.next(SPIClassIterator.java:126)
> > > > >     at
> > > > org.apache.lucene.util.NamedSPILoader.reload(NamedSPILoader.java:60)
> > > > >     at
> > > > org.apache.lucene.util.NamedSPILoader.<init>(NamedSPILoader.java:42)
> > > > >     at
> > > > org.apache.lucene.util.NamedSPILoader.<init>(NamedSPILoader.java:37)
> > > > >     at
> > > > >
> > >
> org.apache.lucene.codecs.PostingsFormat.<clinit>(PostingsFormat.java:44)
> > > > >     ... 56 more
> > > > >
> > > > > Later I see:
> > > > > WARNING: FAILED
> > > > >
> > > > >
> > > >
> > >
> >
> o.e.j.w.WebAppContext{/solr,file:.../},target/classes/jettyhome/webapps/solr.war:
> > > > > java.lang.ExceptionInInitializerError
> > > > > java.lang.ExceptionInInitializerError
> > > > >     at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.solr.core.SolrResourceLoader.reloadLuceneSPI(SolrResourceLoader.java:179)
> > > > >     at
> > > > >
> > > >
> > >
> >
> org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:113)
> > > > >     at
> > > > >
> > > >
> > >
> >
> org.apache.solr.core.SolrResourceLoader.<init>(SolrResourceLoader.java:228)
> > > > >     at org.apache.solr.core.Config.<init>(Config.java:94)
> > > > >     at org.apache.solr.core.Config.<init>(Config.java:73)
> > > > >     at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.solr.servlet.SolrDispatchFilter.<init>(SolrDispatchFilter.java:91)
> > > > >     at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> > > > > Method)
> > > > >     at
> > > > >
> > > > >
> > > >
> > >
> >
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> > > > >     at
> > > > >
> > > > >
> > > >
> > >
> >
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> > > > >     at
> > java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> > > > >     at java.lang.Class.newInstance0(Class.java:355)
> > > > >     at java.lang.Class.newInstance(Class.java:308)
> > > > >     at
> > > > >
> > > > >
> > > >
> > >
> >
> org.eclipse.jetty.servlet.ServletContextHandler$Context.createFilter(ServletContextHandler.java:951)
> > > > >
> > > > >
> > > > > --
> > > > > Mark Bennett / New Idea Engineering, Inc. / [hidden email]
> > > > > Direct: 408-733-0387 / Main: 866-IDEA-ENG / Cell: 408-829-6513
> > > > >
> > > >
> > >
> >
>