[Mondrian] Exception in MondrianServerRegistry

Luc Boudreau lucboudreau at gmail.com
Mon Aug 19 13:27:17 EDT 2013


Jeff,

Thanks for looking into this issue. All the help we receive on Mondrian is
greatly appreciated, especially when it comes to supporting different
environments.

Your understanding of the DefaultRules->Version scheme is right.

Your fix would definitely be useful. We can't merge this fix directly as we
are nearly done with our next release, but we'd gladly accept a pull
request on GitHub. Could you also create a Jira case in our bug tracker to
track this? By referring to your pull request, the team will be able to
quickly review and integrate your change.

Before we accept it though, let's make sure that this is the right way to
access resources. This might break other things in other environments. I'm
thinking in places where people create plugin frameworks and override the
default behavior of their class loader(s). The JVM docs state that:

This method delegates the call to its class loader, after making these
changes to the resource name: if the resource name starts with "/", it is
unchanged; otherwise, the package name is prepended to the resource name
after converting "." to "/". If this object was loaded by the bootstrap
loader, the call is delegated to ClassLoader.getSystemResource.

How exactly is this helping in the case before us? If Glassfish merges all
the paths, wouldn't we be at square one? Why does it fix the problem for
you then? Food for thought... I just want to make sure that we understand
this change before making it.

Thanks a bunch

Luc


On Mon, Aug 19, 2013 at 1:17 PM, Jeff Rosen
<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>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> 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
>>> http://lists.pentaho.org/mailman/listinfo/mondrian
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20130819/f317931a/attachment-0001.html 


More information about the Mondrian mailing list