error: `Could not initialize class org.opensolaris.opengrok.search.SearchEngine`

[cnst]

I've upgraded my OpenGrok dev installation from about master around 2013-04-14 to master around 2013-11-21, re-ran the indexer, but the web-interface doesn't appear to want to work, giving out the following error. Is this expected?

There was an error!

Could not initialize class org.opensolaris.opengrok.search.SearchEngine

java.lang.NoClassDefFoundError: Could not initialize class org.opensolaris.opengrok.search.SearchEngine
    at org.opensolaris.opengrok.search.CustomQueryParser.(CustomQueryParser.java:43)
    at org.opensolaris.opengrok.search.QueryBuilder.buildQuery(QueryBuilder.java:313)
    at org.opensolaris.opengrok.search.QueryBuilder.build(QueryBuilder.java:220)
    at org.opensolaris.opengrok.web.SearchHelper.prepareExec(SearchHelper.java:250)
    at org.apache.jsp.search_jsp._jspService(search_jsp.java:165)
    at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
    at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
    at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
    at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
    at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
    at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1001)
    at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)
    at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
    at java.lang.Thread.run(Thread.java:722)

[tarzanek]

was the source.war updated? lucene updates happened in between, so you need FULL reinstall/reindex

[cnst]

Yes, I've upgraded source.war. I've also deleted the old data directory, ran the new opengrok to index, but I'm still getting the same error.

[cnst]

I ran ant clean, and then re-build, copied the new source.war, and now the issue is gone.

There must be some kind of bug in the build system that is not rebuilding stuff that should be re-built.

[cnst]

It doesn't look like the old index requires to be cleared, BTW; looks like the build process is the cause of the upgrade culprit.

[tarzanek]

well, that's the problem ... there is no upgrade process and upgrades are not really supported let's change this bug into investigation of cleaning (but fwiw I had no problems as developer switching the binaries ... and release HAS to use ant clean and uses a clean repo so this cannot be an issue there - see docs)

[cnst]

I've updated from master that had 4.5.1 in it, to the one that has 4.6 in it, and I seem to be getting the very same error again. The first run, the error displayed is something like "LUCENE_4_x" (where x is a number), and then, upon reload, the same error and stack as in the original report. So, there seems to be something wrong indeed in the build process.

[tarzanek]

build like I said - use JDK 1.7 (_45), use tomcat7 and REFRESH index from SCRATCH between 4.5.1 and 4.6 this is a MUST, since format changed

[tarzanek]

if you use the same index created with old trunk, then you will get this error - no update supported I think we have some bugs to allow better versioning of index (lucene is versioned+has update code, so not a prob there, but historycache/xrefs aren't and no one maintains update code for them anyways) so if you go with trunk, you need to reindex everytime index changes (either in analyzers or in lucene engine)

[tarzanek]

I guess those update bugs are low hanging in a sense, but also low priority, since with the rate of releases refresh from scratch shouldn't be an issue and gives you an option to update your refresh process as well (I saw people who flip datasets to get parallel update/searching without having a gap between code and index) ...

[cnst]

I'm not sure why you insist that the index must be redone. I have no problems using the old index (of course, with a 0.11 index, searching by type with 0.12 won't work, but that's a feature). All that's needed is a ant clean, before running ant -lib lib/JFlex.jar, and then the error doesn't appear.

As I said, this seems to be related to the build process itself; as mentioned in the prior comment, using a new index doesn't fix it at all. I'll take that it's a low priority, and seems to only affect people building from source without doing an ant clean from building with a past version of Lucene. But I don't see any proof of this being related to the index itself.

Also, since this hasn't been the case with prior lucene upgrades (although I haven't sure how many I've sustained with a single tree), I think this may be a regression.

[tarzanek]

ok, so to say it short and sweet the stack you complain about is: java.lang.NoClassDefFoundError: Could not initialize class org.opensolaris.opengrok.search.SearchEngine

which translated to human talk means: your distro doesn't contain proper class which I need yes, you are correct on index, if you don't refresh it, you will get an error when searching that index is old or such thing

back to original stack: so if this is build prob, let's check the sanity(how I redeploy dev builds - I guess this is a good doc candidate): 1) from Netbeans(suggested way): I have clean+build from main project, using my console I run OpenGrok from dev workspace to create clean index, then I do clean+build on the web project, then I do a RUN / DEBUG from web project which will redeploy the webapp (note - in case of standalone webapp server - you need to CLEANLY redeploy web application - means NEW source.war, properly clean old one - depends on webapp server, some of them are not able to properly refresh just by inplace source.war replacement) 2) manual - build using proper ant+proper jdk(oracles 1.7_45) - use OpenGrok from dev workspace (clean index), replace source.war in webapp **

* - for tomcat: cd tomcat/ ; rm -rf webapps/source\ ; cp devws/dist/source.war webapp/ this might vary for other webapp containers, but the deal is - it MUST be clean - if there are leftovers/classes from other/older source.wars then you get above error

hope this explains

[tulinkry]

No reaction for years. A candidate for closing.