[Mondrian] Exception in MondrianServerRegistry

[Julian Hyde]

Any solution would have to correctly deal with the case where there is more than one mondrian.jar on the classpath. (Yes, it happens.)

I am beginning to think that using a text file was a mistake. I still think that we should put a VERSION.txt into mondrian.jar, but it should be for human eyes only.

Mondrian should get its version information either from the manifest of the jar file (presumably better supported by the ClassLoader mechanism, but still potentially presents problems when we are reading classes from a directory, not from a jar file) or in a generated class (which by its nature cannot become separated from the classpath and ClassLoader mechanism).

Julian


On Aug 19, 2013, at 10:17 AM, Jeff Rosen <jeffrey.leigh.rosen at gmail.com<mailto:jeffrey.leigh.rosen at gmail.com>> wrote:

Luc,

I have debugged the issue and you're close - in this case it is finding a VERSION.txt, but the wrong one.  What is happening on glassfish is that VERSION.txt is getting picked up from the JSP classpath.  I don't understand why VERSION.txt is showing up there - intuitively, one would only expect that classpath entry to contain generated JSP classes.  Whatever the reason, it is there and the difference is that on Windows that location contains the VERSION.txt from mondrian.jar, but on centos it contains the one from olap4j.jar which has a different format, i.e. a single line: "olap4j 1.0.1.539".  I guess there is a race condition that makes which specific file end up there indeterminate.

After understanding the problem, the code that had seemed a little "odd" in MondrianServerRegistry.loadVersionFile that looks for DefaultRules.xml and then changes the filename to VERSION.txt suddenly made sense - it is there to ensure that VERSION.txt is picked up from the correct jar when multiple jars have VERSION.txt in the root.  Unfortunately, this trick breaks down in the glassfish case because DefaultRules.xml also appears in the generated jsp classpath location.

I propose that a better solution to ensure that the proper VERSION.txt is always located is to store it in the mondrian.server package and then use Class.getResource() to locate it rather than ClassLoader.getResource().  I have made local modifications to do just that and tested it on Windows and Centos with Glassfish and it works.  I just copy VERSION.txt to the root and mondrian.server during the build and then modified the loadFileVersion to match.  I'm happy to submit the change if you think it would be useful.

--Jeff


On Mon, Aug 19, 2013 at 8:30 AM, Luc Boudreau <lucboudreau at gmail.com<mailto:lucboudreau at gmail.com>> wrote:
Hi Jeff,

This exception usually happens when the version file cannot be found in the classpath. Let's do a quick sanity check. What are the files at the root of that Mondrian JAR?


On Fri, Aug 16, 2013 at 8:05 PM, Jeff Rosen <jeffrey.leigh.rosen at gmail.com<mailto:jeffrey.leigh.rosen at gmail.com>> wrote:

I have a very strange problem that I've been battling and I can't seem to
figure out.  Any help would be greatly appreciated.

I am trying to deploy Mondrian 3.5 in glassfish 3.1 on a hosted server running
centos 6.  I have successfully deployed the same mondrian.war in the same
version of glassfish running on a Windows workstation.  It seems that whenever
mondrian attempts to initialize on centos, I get an NPE at line 85 of
MondrianServerRegistry.

I have created a simple test that simply calls
MondrianServerRegistry.INSTANCE.getOrLoadVersion();  It executes successfully
on the centos environment and returns the following information from
MondrianVersion:

VersionString: 3.50
Product: mondrian
MajorVersion: 3
MinorVersion: 0

I have looked at the code for MondrianServerRegistry and it would seem that
"versionString" is null.  Looking at loadVersionFile(), I don't see how that is
possible. I guess I can setup to try and remotely debug (over the internet,
yuk!), but while I'm doing that, has anyone seen anything like this or have
any idea what might cause something like this?

java.lang.NullPointerException
at mondrian.server.MondrianServerRegistry.getOrLoadVersion(MondrianServerRegistry.java:85)
at mondrian.olap.MondrianServer.getVersion(MondrianServer.java:107)
at mondrian.rolap.RolapSchema.checkSchemaVersion(RolapSchema.java:448)
at mondrian.rolap.RolapSchema.load(RolapSchema.java:408)
at mondrian.rolap.RolapSchema.(RolapSchema.java:216)
at mondrian.rolap.RolapSchemaPool.get(RolapSchemaPool.java:214)
at mondrian.rolap.RolapSchemaPool.get(RolapSchemaPool.java:66)
at mondrian.rolap.RolapConnection.(RolapConnection.java:160)
at mondrian.rolap.RolapConnection.(RolapConnection.java:90)
at mondrian.olap.DriverManager.getConnection(DriverManager.java:112)
at com.tonbeller.jpivot.mondrian.MondrianModel.initialize(MondrianModel.java:518)
at com.tonbeller.jpivot.olap.model.OlapModelDecorator.initialize(OlapModelDecorator.java:132)
at com.tonbeller.jpivot.tags.OlapModelProxy$MyState.initialize(OlapModelProxy.java:77)
at com.tonbeller.jpivot.tags.StackStateManager.initializeAndShow(StackStateManager.java:76)
at com.tonbeller.jpivot.tags.OlapModelProxy.initializeAndShow(OlapModelProxy.java:160)
at com.tonbeller.jpivot.tags.OlapModelTag.doEndTag(OlapModelTag.java:81)
at org.apache.jsp.WEB_002dINF.queries.mondrian_jsp._jspx_meth_jp_mondrianQuery_0(mondrian_jsp.java from :114)
at org.apache.jsp.WEB_002dINF.queries.mondrian_jsp._jspService(mondrian_jsp.java from :62)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:411)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:377)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1550)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:809)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:671)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:626)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:556)
at com.tonbeller.wcf.utils.IncludeTag.doStartTag(IncludeTag.java:59)
at org.apache.jsp.testpage_jsp._jspx_meth_wcf_include_0(testpage_jsp.java from :263)
at org.apache.jsp.testpage_jsp._jspService(testpage_jsp.java from :123)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:411)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:377)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1550)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at com.tonbeller.wcf.controller.RequestFilter$MyHandler.normalRequest(RequestFilter.java:139)
at com.tonbeller.wcf.controller.RequestFilter.doFilter(RequestFilter.java:264)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

Thanks!

--Jeff


_______________________________________________
Mondrian mailing list
Mondrian at pentaho.org<mailto:Mondrian at pentaho.org>
http://lists.pentaho.org/mailman/listinfo/mondrian



_______________________________________________
Mondrian mailing list
Mondrian at pentaho.org<mailto:Mondrian at pentaho.org>
http://lists.pentaho.org/mailman/listinfo/mondrian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20130819/fe8a65da/attachment.html