#21 NullPointerException on BEA Weblogic

[Rene Zanner]

The following exception is thrown when a WidgetServer application is deployed on a Weblogic BEA (9.2):

[29.01.08 16:59][[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'][ug2t][MESSAGE][registry startup]@[static->static]

--------------------------------------------------
WidgetServer Framework, commercial release
(C) 2005-2007, Dirk von der Weiden
--------------------------------------------------

[29.01.08 16:59][[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'][ug2t][MESSAGE][webContext rootDir: nullstart]@[class de.ug2t.unifiedGui.service.UnBasicServlet->HASH:32681570]
[29.01.08 16:59][[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'][ug2t][MESSAGE][no special encoding found, use ISO-8859-1]@[static->static]
[29.01.08 16:59][[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'][ug2t][MESSAGE][webContext tmpDir not set use default: C:\bea\user_projects\domains\WiSer\nullstart\tmp]@[class de.ug2t.unifiedGui.service.UnBasicServlet->HASH:32681570]
[29.01.08 16:59][[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'][ug2t][MESSAGE][producer cache has been disabled]@[class de.ug2t.unifiedGui.service.UnBasicServlet->HASH:32681570]
[29.01.08 16:59][[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'][ug2t][FATAL][java.lang.NullPointerException
at de.ug2t.connector.CoXmlParameterGetter.pcmf_getParameter(Unknown Source)
at de.ug2t.unifiedGui.UnComponentFactory.pcmf_construct(Unknown Source)
at de.ug2t.unifiedGui.UnComponentFactory.<init>(Unknown Source)
at de.ug2t.unifiedGui.service.UnBasicServlet.init(Unknown Source)
at weblogic.servlet.internal.StubSecurityHelper$ServletInitAction.run(StubSecurityHelper.java:274)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.servlet.internal.StubSecurityHelper.createServlet(StubSecurityHelper.java:64)
at weblogic.servlet.internal.StubLifecycleHelper.createOneInstance(StubLifecycleHelper.java:58)
at weblogic.servlet.internal.StubLifecycleHelper.<init>(StubLifecycleHelper.java:48)
at weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl.java:504)
at weblogic.servlet.internal.WebAppServletContext.preloadServlet(WebAppServletContext.java:1716)
at weblogic.servlet.internal.WebAppServletContext.loadServletsOnStartup(WebAppServletContext.java:1693)
at weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1613)
at weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:2764)
at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:889)
at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:333)
at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:204)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26)
at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:60)
at weblogic.application.internal.flow.ScopedModuleDriver.start(ScopedModuleDriver.java:200)
at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:117)
at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:204)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26)
at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:60)
at weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:26)
at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:635)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26)
at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:212)
at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:154)
at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:80)
at weblogic.deploy.internal.targetserver.BasicDeployment.activate(BasicDeployment.java:181)
at weblogic.deploy.internal.targetserver.BasicDeployment.activateFromServerLifecycle(BasicDeployment.java:358)
at weblogic.management.deploy.internal.DeploymentAdapter$1.doActivate(DeploymentAdapter.java:52)
at weblogic.management.deploy.internal.DeploymentAdapter.activate(DeploymentAdapter.java:186)
at weblogic.management.deploy.internal.AppTransition$2.transitionApp(AppTransition.java:30)
at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps(ConfiguredDeployments.java:233)
at weblogic.management.deploy.internal.ConfiguredDeployments.activate(ConfiguredDeployments.java:169)
at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(ConfiguredDeployments.java:123)
at weblogic.management.deploy.internal.DeploymentServerService.resume(DeploymentServerService.java:173)
at weblogic.management.deploy.internal.DeploymentServerService.start(DeploymentServerService.java:89)
at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)

[Rene Zanner]

Logged In: YES
user_id=551991
Originator: YES

It seems that the rootDir of the KeEnvironment is not set correctly and so the XML configuration files cannot be found:

[webContext rootDir: nullstart]

Digging the sources I found that almost every file access relies on directly accessing the file system below the application's root real path fetched by ServletContext.getRealPath("/").

Caution: this is not guaranteed to work on all web containers - the Servlet specification does permit this method to return "null" when the web application is deployed as a WAR file, for instance (http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/ServletContext.html#getRealPath(java.lang.String)).

Obviously Weblogic is not as generous as Tomcat to return the real path of the expanded WAR file, since the output above tells us that the "rootDir" is "nullstart" when it should be "[absolute path of the web application root in the file system]/start" .

So, the whole file processing in WidgetServer must be reworked NOT to use ServletContext.getRealPath() in order to work on other web containers than Tomcat or Jetty!

One solution is to use ServletContext.getResourceAsStream(String path). This is _specified_ to work no matter how the web application is actually deployed - as WAR or in exploded format.
Since most of the file processing in WidgetServer creates an XML InputSource from the java.io.File object anyway, the effort for the change should not be too much - an InputSource may be created from an InputStream (or an InputStreamReader, to be more encoding-aware), too.

The result is worth the effort: being able to deploy a WidgetServer web application on commercial web containers!

[Rene Zanner]

Logged In: YES
user_id=551991
Originator: YES

Special care has to be taken, of course, for the other channels. So the best may be to work everywhere with streams or URLs (ServletContext.getResource() returns a URL for the given resource path) and introduce a special handling for writing files.