Doug, The application directory under webapps is named "timesheet", therefore, the context fragment in conf/Catalina/localhost is "timesheet.xml" to match the context name. The beginning of the <Context> element in timesheet.xml is
<Context path="/timesheet" docBase="timesheet" . . . > to match the directory name under webapps. So, I think as far as Tomcat goes, I've got it consistently as "timesheet". The class name under webapps/timesheet/WEB_INF/classes is "Timesheet" to follow the Java capitalization conventions of class names. Therefore, "Timesheet" appears in my web.xml as the prefix to the various <servlet-class> names, but nowhere else. Now, as for the MySQL database, I named it "Timesheets" (note the capital and the plural). My logic being that the application was for doing a single timesheet at a time while the database was for recording all the timesheets at once. (Yes, I'm anal. I know. :-) ). The database name shows up in the url parameter: jdbc:mysql://localhost/Timesheets?... In that case the plural is critical, but the capitalization isn't (in my case) since a MySQL database name is merely a file name and file names in Windows are case insensitive. Nevertheless, I've got it matching. As far as I can tell, this URL is the only place in the Tomcat configuration files that the name of the MySQL database appears. Unless... Now we come to <Resource name="jdbc/TimesheetsDB" ... /> <ResourceParams name="jdbc/TimesheetsDB"> ... </ResourceParams> I was just reading up on the JNI naming conventions from a link someone gave me when I stopped to check my mail again. As nearly as I can tell, the "jdbc" part of the "jdbc/TimesheetsDB" is magic, and it must be that to work. However, the "TimesheetsDB" part can be anything you want as long as the name attributes in <Resource> and <ResourceParams> matches. Therefore, I used "Timesheets" to reflect the MySQL database name and "DB" just because the first example I saw used that suffix. I think I've got all that consistent, but if DataSource is supposed to be the way to go in the future for JDBC, it shouldn't be this hard. By the way, I do appreciate the time you're spending thinking about my problem. Merrill --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
