Web application specific form authenticator under Tomcat 6

Question

With your help I have successfully resolved a question that I have asked here. I have developed a custom Tomcat authenticator for the web application, and currently the authenticator and its configuration file are located in the %CATALINA_HOME%\lib\ directory. Unfortunately, the authenticator configuration file is almost a duplicate for the configuration file of the web application (located in %CATALINA_HOME%\webapps\myapp) the authenticator was developed for, and the configuration files both, obviously, share the same DB-connection settings. This is inconvenient because sharing the only configuration file would be the best.

I think there could be two ways to resolve the issue:

1. Find the webapps directory for myapp presence somehow at Tomcat startup, and then read the application configuration file (proceed from the current situation, and the myapp\WEB-INF\web.xml is configured properly). Sure, unfortunately this requires Tomcat restart.
2. There might be a way to put the form authenticator into the corresponding web application directory to be able to read the shared configuration file directly. Perhaps this might eliminate Tomcat restart and allow simple redeployment.

I would like to prefer the second solution if it's possible, but I'm not sure. Which way is better, if they both exist? Or is there any other and even better solution not putting the web application specific authenticator into %CATALINA_HOME\lib%?

Thanks in advance and sorry for my English.

Answer 1

Ah, it's all much easier! The main idea is just to get connection string through the (JDBCRealm) context.getRealm() object in the authenticate(...). That's enough to resolve my issue.

Answer 2

You have a case of code duplication.

I would suggest refactoring the code, so that Tomcat has all the necessary code to to its authentification, and then refactor your application to solely use the Tomcat authentification code.

If your application cannot use the Tomcat authentification you can at least move the common code, including its configuration files, up in Tomcat, and then use the common code.