[BarryMcM]

Hi,

We have been successfully using BIRT Runtime 2.3.1 in a WAS 61 environment for over 2 years now.

We have 1 report which renders a bunch of data in csv format and is triggered by a Workflow/MDB process.
The ReportEngine directory containing the runtime files is in a shared directory on the WAS 61 server.

Like I say, everything has been working fine for the past 2 years, until we had to update the report to version 2.6.1 and use the 2.6.2 runtimes.

We replaced the 2.3.2 runtimes with the 2.6.2 runtimes on the WAS sever (In the ReportEngine directory) and deployed the new version of the report (Updated automatically to 2.6.1 by Eclipse).

We got a 'cannot start the OSGI' exception the first time we tried running the deployed report, but sorted that by changing the permissions on the ReportEngine/configuration director to 777.

This setup works fine when I run the report locally in Eclipse with a simple Java calling class i.e. 2.6.1 report and 2.6.2 runtimes. I get back my csv rendered data as before.

However, when running remotely I am getting a java.lang.NullPointerException
at com.ibm.icu.util.Calendar.getCalendarType(Calendar.java:1717)
exception. I have tried specifically setting the locale on the task object in the calling code but to no avail.

I have listed the complete stack trace below in case anything jumps out at anyone here. I'm hitting a brick wall here with something that could turn out to be completely simple.

Any help would be greatly appreciated.

Thanks,

-Barry

[3/16/12 12:44:28:375 EDT] 0000003b ReportEngine E An error happened while running the report. Cause:
java.lang.NullPointerException
at com.ibm.icu.util.Calendar.getCalendarType(Calendar.java:1717)
at com.ibm.icu.util.Calendar.getInstance(Calendar.java:1665)
at com.ibm.icu.util.Calendar.getInstance(Calendar.java:1638)

at org.eclipse.birt.core.script.function.bre.BirtDateTime.getCalendar(BirtDateTime.java:1276)
at org.eclipse.birt.core.script.function.bre.BirtDateTime.month(BirtDateTime.java:285)
at org.eclipse.birt.core.script.function.bre.BirtDateTime.access$3(BirtDateTime.java:280)
at org.eclipse.birt.core.script.function.bre.BirtDateTime$Function_Month.getValue(BirtDateTime.java:269)
at org.eclipse.birt.core.script.function.bre.Function_temp.execute(BreUtility.java:39)
at org.eclipse.birt.core.script.function.bre.BirtDateTime.execute(BirtDateTime.java:1330)
at org.eclipse.birt.core.script.functionservice.impl.ScriptFunction.execute(ScriptFunction.java:146)
at org.eclipse.birt.core.script.functionservice.impl.CategoryWrapper$1.call(CategoryWrapper.java:67)
at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:3330)
at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2487)
at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:164)
at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:398)
at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3065)
at org.mozilla.javascript.InterpretedFunction.exec(InterpretedFunction.java:175)
at org.eclipse.birt.data.engine.expression.BytecodeExpression.evaluate(BytecodeExpression.java:49)
at org.eclipse.birt.data.engine.expression.ExprEvaluateUtil.evaluateCompiledExpression(ExprEvaluateUtil.java:205)
at org.eclipse.birt.data.engine.expression.ExprEvaluateUtil.evaluateCompiledExpression(ExprEvaluateUtil.java:219)
at org.eclipse.birt.data.engine.expression.ExprEvaluateUtil.evaluateExpression(ExprEvaluateUtil.java:76)
at org.eclipse.birt.data.engine.impl.BindingColumnsEvalUtil.evaluateValue(BindingColumnsEvalUtil.java:208)
at org.eclipse.birt.data.engine.impl.BindingColumnsEvalUtil.getColumnsValue(BindingColumnsEvalUtil.java:168)
at org.eclipse.birt.data.engine.impl.ResultIterator.prepareCurrentRow(ResultIterator.java:742)
at org.eclipse.birt.data.engine.impl.ResultIterator.<init>(ResultIterator.java:167)
at org.eclipse.birt.data.engine.impl.QueryResults.getResultIterator(QueryResults.java:208)
at org.eclipse.birt.report.engine.data.dte.QueryResultSet.<init>(QueryResultSet.java:98)
at org.eclipse.birt.report.engine.data.dte.DteDataEngine.doExecuteQuery(DteDataEngine.java:168)
at org.eclipse.birt.report.engine.data.dte.AbstractDataEngine.execute(AbstractDataEngine.java:265)
at org.eclipse.birt.report.engine.executor.ExecutionContext.executeQuery(ExecutionContext.java:1890)
at org.eclipse.birt.report.engine.executor.QueryItemExecutor.executeQuery(QueryItemExecutor.java:80)
at org.eclipse.birt.report.engine.executor.TableItemExecutor.execute(TableItemExecutor.java:62)
at org.eclipse.birt.report.engine.internal.executor.dup.SuppressDuplicateItemExecutor.execute(SuppressDuplicateItemExecutor.java:43)
at org.eclipse.birt.report.engine.internal.executor.wrap.WrappedReportItemExecutor.execute(WrappedReportItemExecutor.java:46)
at org.eclipse.birt.report.engine.internal.executor.l18n.LocalizedReportItemExecutor.execute(LocalizedReportItemExecutor.java:34)
at org.eclipse.birt.report.engine.layout.html.HTMLBlockStackingLM.layoutNodes(HTMLBlockStackingLM.java:65)
at org.eclipse.birt.report.engine.layout.html.HTMLPageLM.layout(HTMLPageLM.java:90)
at org.eclipse.birt.report.engine.layout.html.HTMLReportLayoutEngine.layout(HTMLReportLayoutEngine.java:99)
at org.eclipse.birt.report.engine.api.impl.RunAndRenderTask.doRun(RunAndRenderTask.java:180)
at org.eclipse.birt.report.engine.api.impl.RunAndRenderTask.run(RunAndRenderTask.java:77)
at com.lmig.cmit.pas.plp.service.reporting.util.ReportGenerator.runAndRender(ReportGenerator.java:131)
at com.lmig.cmit.pas.plp.service.reporting.util.ReportGenerator.generateCSVReport(ReportGenerator.java:79)
at com.lmig.cmit.pas.plp.service.reporting.ReportGeneratorHelper.generatePADESExportCSV(ReportGeneratorHelper.java:70)
at com.lmig.cmit.pas.plp.service.pades.business.BOLM_PadesTaskProcessorImpl.doWritePadesRecord(BOLM_PadesTaskProcessorImpl.java:268)
at com.lmig.cmit.pas.plp.service.pades.business.BOLM_PadesTaskProcessorImpl.processExportRequest(BOLM_PadesTaskProcessorImpl.java:152)
at com.lmig.cmit.pas.plp.service.pades.facade.LM_PadesTaskProcessorBean.processExportRequest(LM_PadesTaskProcessorBean.java:113)
at com.lmig.cmit.pas.plp.service.pades.facade.EJSRemoteStatelessPadesTaskProcessor_2302370e.processExportRequest(Unknown Source)
at com.lmig.cmit.pas.plp.service.pades.facade._LM_PadesTaskProcessorFacade_Stub.processExportRequest(_LM_PadesTaskProcessorFacade_Stub.java:86)
at com.lmig.cmit.pas.plp.service.pades.delegate.LM_PadesDelegate.processExportRequest(LM_PadesDelegate.java:58)
at com.lmig.cmit.pas.ironbridge.service.workflowintegration.helper.IssuanceTaskProcessorHelper.handleResponse(IssuanceTaskProcessorHelper.java:32)
at com.lmig.cmit.pas.plp.service.pades.messaging.LM_PadesMDBBean.onMessage(LM_PadesMDBBean.java:91)
at com.ibm.ejs.jms.listener.MDBWrapper$PriviledgedOnMessage.run(MDBWrapper.java:302)
at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:63)
at com.ibm.ejs.jms.listener.MDBWrapper.callOnMessage(MDBWrapper.java:271)
at com.ibm.ejs.jms.listener.MDBWrapper.onMessage(MDBWrapper.java:240)
at com.ibm.mq.jms.MQSession$FacadeMessageListener.onMessage(MQSession.java:147)
at com.ibm.msg.client.jms.internal.JmsSessionImpl.run(JmsSessionImpl.java:2639)
at com.ibm.mq.jms.MQSession.run(MQSession.java:862)
at com.ibm.ejs.jms.JMSSessionHandle.run(JMSSessionHandle.java:975)
at com.ibm.ejs.jms.listener.ServerSession.connectionConsumerOnMessage(ServerSession.java:957)
at com.ibm.ejs.jms.listener.ServerSession.onMessage(ServerSession.java:667)
at com.ibm.ejs.jms.listener.ServerSession.dispatch(ServerSession.java:634)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:618)
at com.ibm.ejs.jms.listener.ServerSessionDispatcher.dispatch(ServerSessionDispatcher.java:37)
at com.ibm.ejs.container.MDBWrapper.onMessage(MDBWrapper.java:96)
at com.ibm.ejs.container.MDBWrapper.onMessage(MDBWrapper.java:132)
at com.ibm.ejs.jms.listener.ServerSession.run(ServerSession.java:492)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1473)

[JasonW]

When you upgraded did you clear the configuration directory of everything but the config.ini? How are you setting the locale?

Jason

[BarryMcM]

JasonW, on 20 March 2012 - 08:04 AM, said:

When you upgraded did you clear the configuration directory of everything but the config.ini? How are you setting the locale?

Jason

Hi Jason,

Thanks for the quick response. Yes. I cleared all but the config.ini file in that directory, and BIRT has written files there when attempting to render the new report.

I set the locale in the ReportGenerator.runAndRender(ReportGenerator) method below thus:

task.setLocale(new Locale("en", "US"));

using java.util.Locale

One thing I've noticed is that in the 2.6.2 ReportEngine directory there is no 'workspace' directory. I assumed this directory would be automatically created but I'm seeing the following in the configuration logs:

Root exception:
java.lang.IllegalStateException: The platform metadata area could not be written: /was61_sharedLib/ReportEngine/workspace/.metadata. By default the platform writes its content
under the current working directory when the platform is launched. Use the -data parameter to
specify a different content area for the platform.
at org.eclipse.core.internal.runtime.DataArea.assertLocationInitialized(DataArea.java:61)
at org.eclipse.core.internal.runtime.DataArea.getStateLocation(DataArea.java:120)
at org.eclipse.core.internal.runtime.InternalPlatform.getStateLocation(InternalPlatform.java:606)
at org.eclipse.core.runtime.Plugin.getStateLocation(Plugin.java:312)
at org.eclipse.birt.chart.plugin.ChartEnginePlugin.start(ChartEnginePlugin.java:34)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:783)
at java.security.AccessController.doPrivileged(AccessController.java:241)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:774)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:755)
at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:370)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:284)
.....


The timing of this exception coincides with that of the Calendar Nullpointer exception in our application log listed in my previous post.

Is the locale info stored temporarily in the workspace directory but in this case cannot be read as the directory doesn't exist?

In our old archived 2.3.2 ReportEngine directory, the workspace directory exists.


Thanks,

-Barry

[JasonW]

This does sound like a permission issue. Can you try to either create the directory or change the permissions on the above directory. Is this where you set your birt home:
/was61_sharedLib/ReportEngine/

Jason

[BarryMcM]

Hi Jason,

Yes, it's looking very like that, though I'm wondering why we're getting this with 2.6.2 when the file permissions *should* be the same as before, with 2.3.1.

I tried locally, making the workspace directory unwriteable and was able to emulate the metadata exception okay, but the report still rendered and didn't throw the Calendar NullPointer exception. Is there another working directory in the structure used by the timezone or locale functionality?

Thanks,

-Barry

[BarryMcM]

Well, I figured out what's causing the NullPointerException:

[3/16/12 12:44:28:375 EDT] 0000003b ReportEngine E An error happened while running the report. Cause:
java.lang.NullPointerException
at com.ibm.icu.util.Calendar.getCalendarType(Calendar.java:1717)
at com.ibm.icu.util.Calendar.getInstance(Calendar.java:1665)
at com.ibm.icu.util.Calendar.getInstance(Calendar.java:1638)

I was able to create the issue locally.

It appears the birt jars are referencing the Calendar class in the file 'com.ibm.ws.runtime_6.1.0.jar' on the app's classpath rather than 'com.icu_4.2.1.v20100412.jar' in the Runtimes directory.

The application's classpath contains 2.6.2 versions of engineapi, coreapi, etc which seem to be incompatible with the was runtime jar.

Project restrictions mean I can't remove or change anything from the application classpath, but is there a way that I can force my BIRT report to ignore the application classpath and use the jars in ReportEngine/lib instead?

This could be a particularly dumb question, but I've been thrown into the deep end to fix something that no one has looked at in over 2 years, the problem originally being caused by us having to recently update the birt jars in the classpath from 2.3.2 to 2.6.2 versions, to fix a different issue.


Thanks,

-Barry

[JasonW]

If you were using 3.7 you could just remove the birt version of icu. Can you set the parent last for the app similar to the method shown for 3.7 here:
http://wiki.eclipse....here_Deployment


If that does not work you could do the ugly fwk setting in the osgi configuration file for the birt runtime.

Jason

[JasonW]

BTW I am curious how you determined which jar it was using? I am currently debugging a WASCE instance with 2.6.2.

Jason

[BarryMcM]

Hi Jason,

Sorry for taking so long to respond.

I determined what jar was causing the issue through a laborious painstaking task of setting up our deployed environment locally, with all the jars from our app classpath, running the report within a java wrapper, pointing to a directory with the 2.6.2 runtime. This replicated the execption. I then kept removing jars a handful at a time from the classpath and re-running the report until the exception disappeared. That's how I narrowed it down to the com.ibm.ws.runtime_6.1.0.jar. I opened this jar in a java decompiler and found the calendar class which was actually being called. The line numbers from the stack trace all added up.

Not very technical, or intuitive, but it got me the offending jar.

Anway, since I could not remove the jar from tha classpath I decided what parts of the report actually needed the calendar class. As it turned out, in 6 parts of the report the birtdatetime.month, .day and .year functions were called. I eliminated these from the report, and updated the query SQL to send the month, year and date parts instead.
I only got around to deploying this fix today in our Dev environment and hey presto - the report ran with no more exceptions.

Not the ideal solution, but we're upgrading from WAS 6.1 to WAS 8 in the autumn so I can revisit the report then, or suggest we upgrade to BIRT 3.7.


Anyway, thought I'd write this up in case it's of use to anyone else out there.

Thanks, Jason, for the responses and helpful advice.


-Barry

[JasonW]

Barry,

Thanks for updating and your tenacity! When you get around to upgrading please let me know.

Jason