[Mondrian] Exception in MondrianServerRegistry

Jeff Rosen jeffrey.leigh.rosen at gmail.com
Mon Aug 19 13:46:01 EDT 2013 

Luc,

I'll create the JIRA ticket and we can move the discussion there.

Just quickly though, I think my solution helps because it moves the
location of the resource to the package level which should (especially in
the presence of OSGi) make it much more likely to locate the correct
VERSION.txt if it exists on the classpath.  Since VERSION.txt would not
appear in the package mondrian.server in any jar other than mondrian.jar
I'm guaranteed of finding the VERSION.txt I'm after.

Also, I think the quote from the javadoc of Class.getResource() that you
reference is simply saying that the package that the class resides in is
converted to a path when looking for the resource, i.e. if I use
mondrian.server.MondrianServerImpl.class.getResource("VERSION.txt") it will
search the classpath for the resource mondrian/server/VERSION.txt.  Since
we then get the InputSteam directly from the URL I believe this will work
in all environments, but I agree, it needs to be looked at. I don't want to
break other environments just to get mine working.

--Jeff


On Mon, Aug 19, 2013 at 11:27 AM, Luc Boudreau <lucboudreau at gmail.com>wrote:

> 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/fc0108c2/attachment-0001.html

More information about the Mondrian mailing list