tags:

views:

answers:

I am facing this peculiar problem. My webapp, works fine on my localhost. Its a JSP/Struts-Tomcat-MySQL app. However, when I host it on hostjava.net (shared tomcat), it is unable to connect to the database.

"java.lang.NullPointerException
at com.DAO.UserDAO.userLogin(UserDAO.java:109)
at com.Actions.UserAction.execute(UserAction.java:66)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
"

This tells me that something is NOT being initialized properly. on what object are you invoking in line 109 of UserDAO.java ?

The peculiar thing is, that another part of the same application, accesses the database, with a hardcoded url (using DriverManager, and NOT datasource from the JNDI lookup), and that works just fine (check out the first two lines in the log, and the next couple of lines with cuisine names, which are read from the database). So, it is certain, that the database is also on the same server.

is the driver available? Try Class.forName("com.mysql.jdbc.Driver"); - and it can't be located in your webapps WEB-INF/lib because you are asking for the container (tomcat) to instantiate it for you: It needs to be in the servers classpath

Are you running Tomcat 5.5.x or 6.0.x? On 5.0.x the context.xml syntax, especially resource definition, has been different: Way more xml tags instead of the nicer and simpler attributes since 5.5.

http://tomcat.apache.org/tomcat-5.5-doc/config/context.htmlThe context path of this web application, which is matched against the beginning of each request URI to select the appropriate web application for processing. All of the context paths within a particular Host must be unique. If you specify a context path of an empty string (""), you are defining the default web application for this Host, which will process all requests not assigned to other Contexts.

I'm not an expert in Tomcat configuration. The point is: on shared hosting it may be prohibited to create your own data sources. For security reasons or resources reasons. Ask support to add one for you.

Per Vladimir's answer and comments, you may want to consider requesting the server context (server.xml, or the more globally scoped context.xml) be updated.

If nothing else, this is, in my opinion, a best practice. While Tomcat does allow you to define the context (including JNDI resources) from within the web application itself, the only place you should use this feature is in a developer's local test server. It makes your web application more portable, as it allows to change the configuration of your external resources (in this case, the database, but it could be a mail server, or content server, rules engine etc) independently of your application.

Another note:
Do you have access to any other log files besides the one you posted? If you have access to the server logs/catalina.out file, it may show you the exact problem Tomcat is having setting up the data source (this would be right when you start up Tomcat).

Sorry everyone. It was a problem of miscommunication between me and the Support team of the hosting facility. There was a clash of configs. They had set some old settings in server.xml. As that takes precedence over any other context information, I was facing those issues. Now it is taken care of.

But I still feel, that to allow people on a shared configuration, to have their context information in META-INF/context.xml file, is a better option. That way, they have more control over it.

But I Thank everyone, who took the time out, to respond. I learnt a lot from you. Thank you again.