SEVERE exception in XmlConfigParser when launced in remot tomcat

[GoogleCodeExporter]

Any ideas? Any ways to make more robust the code there? 

I suspect it may just be some library missing but it doesnt make sense as in a 
local tomcat (same version) all works well. 

SEVERE: Allocate exception for servlet greetServlet
java.lang.NullPointerException
    at de.uds.MonitorInterventionMetafora.server.xml.XmlConfigParser.toActiveConfiguration(XmlConfigParser.java:59)
    at de.uds.MonitorInterventionMetafora.server.MainServer.readConfiguration(MainServer.java:66)
    at de.uds.MonitorInterventionMetafora.server.MainServer.<init>(MainServer.java:49)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:532)
    at java.lang.Class.newInstance0(Class.java:372)
    at java.lang.Class.newInstance(Class.java:325)
    at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1149)
    at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:827)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:129)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
    at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
    at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)
    at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:776)
    at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:705)
    at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:898)
    at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
    at java.lang.Thread.run(Thread.java:636)

Original issue reported on code.google.com by mavrikis@gmail.com on 11 May 2013 at 1:44

[GoogleCodeExporter]

Looking at the code, it seems this would happen only if it was not finding the 
configuration file. We could certainly add a null check to this, but I guess we 
have to hink about what we want to happen if it can't find the config file, 
because that probably means it can't find any config files (like xmpp config) 
and therefore can't really run.

The file path comes from the XmlConfigParser constructor, called in MainServer, 
line 60. It is gotten using that getRealPath() method that I believe you wrote 
specifically to handle this issue of having different path in local vs. tomcat 
versions.

I also know from prior experience, that tomcat can get a different relative 
path depending on the current path in your shell when calling the tomcat 
startup script.  For example, I used to have a problem when I ran the tomcat 
startup script from a script file inside the LASAD directory, because it would 
then look for files in that LASAD directory instead of in the webapps folder. 
Again though, I thought we had resolved these issues with the getRealPath() 
call, so I'm not sure exactly how to proceed on this other than to test where 
it is looking for the files.

Original comment by tdragon1...@gmail.com on 11 May 2013 at 2:02

[GoogleCodeExporter]

Good points. Had forgotten some of them... maybe it is because this time tomcat 
started relatively from somewhere else. Will have a look and also put some 
debug statement to check where it is looking.  

Original comment by mavrikis@gmail.com on 11 May 2013 at 2:14

[GoogleCodeExporter]

Sorry mantesat I should have taken the issue somehow ended with you.

This was an issue probably to do with the location where tmcat is launched from 
... there is conflicting evidence as there were also a couple of webapps 
running somehow accidentally and leaks floating about until I restarted 
everything. Anyway closing this issue.    

Original comment by mavrikis@gmail.com on 11 May 2013 at 3:51

• Changed state: Invalid