It is 6:43 AM on 3/19/2011 and its a Saturday.
Lets get cracking :)
Google search for "tomcat scan detect common jars" yielded some reading material for starters - jar-scanner and loader - but both these seemed to be get kicked-off per web-application whereas something more global is required to move jars around and thin the pack before web applications are considered at all.
Let us break-down the process:
- Tomcat starts
- Hook-in at the point where we have a list of the docBase attribute for all the web applications that will be hosted by this tomcat instance. And none of the web application specific handling has begun yet.
- Loop over each ${docBase}/WEB-INF/lib folder and make a list of common jars.
- Try to decide "commonality" based on a combination of the following factors:
- start by doing a fuzzy match on the file name
- then try to match the jar version in the names or if you can find it by introspecting the jar's manifest
- and at the end confirm by doing an exact match on the file size
- Thought: generating and comparing md5 hashes on files might yield the same results quicker?
- Even after the jar dependencies have been moved to common/lib folder, one might not want to expose any of the other common jars in the shared folder to their webapp. For this case, the wiki about embedding JBoss into Tomcat gives us an idea about the possibility of only having each web application refer strictly to the jars it really needs via the help of a resource scanner listener.
- There may not be a hook in the tomcat code where we have a consolidated list of the docBase attribute for all the web applications!
- Even if such a hook exists, it may be happening at three different places:
- when the application contexts defined via server.xml are processed,
- when the war files directly under the webapps/ folderare processed,
- and when the context-fragment files under conf/Catalina/localhost/ folder are processed!
- The user starting tomcat may not have the permissions required to move the files around.
- Piggyback off a resource scanner listener per application and create a list/report as each individual app comes up.
- Then Tomcat can be shutdown and the list/report can be acted upon by a script that runs under an admin/root account to achieve the same results as before.
- Starting back the tomcat server afterwards should be fine.
Sent an email to the tomcat users list to find out if a hook into the process exists.
Started the process of getting and building the source-code for Tomcat.
0 comments:
Post a Comment