Ear Approach
You can just drop it into the Tomcat webapps/ directory and it will be picked up.
Example ear (valid):
myapplication.ear
lib/
lib/libraryOne.jar
lib/libraryTwo.jar
redEjbs.jar
blueEjbs.jar
Common mistake (invalid):
myapplication.ear
libraryOne.jar (err. not a javaee module)
libraryTwo.jar (err. not a javaee module)
redEjbs.jar
blueEjbs.jar
Only Java EE modules are allowed at the root. These are EJB jars, .war files, Connector .rar files and Application Client jars. Prior to Java EE 5, libraries had to be explicitly listed in an application.xml file. Java EE 5 and forward they can be added to a lib/ directory and be understood to be just plain jars as opposed to a Java EE module.
Collapsed EAR approach
In OpenEJB/Tomcat you can put all your libraries into the war file and be free of the ear concept. This is now part of Java EE 6.
mywebapp.war
WEB-INF/lib/libraryOne.jar
WEB-INF/lib/libraryTwo.jar
WEB-INF/lib/redEjbs.jar
WEB-INF/lib/blueEjbs.jar
Common mistake, including specs:
mywebapp.war
WEB-INF/lib/javax.ejb.jar (err. clashes with the related system library)
WEB-INF/lib/libraryOne.jar
WEB-INF/lib/libraryTwo.jar
WEB-INF/lib/redEjbs.jar
WEB-INF/lib/blueEjbs.jar
Doesn't sound like that is the issue, but adding for completeness.
Common mistake, broken dependencies:
tomcat/lib/libraryTwo.jar
mywebapp.war
WEB-INF/lib/libraryOne.jar
WEB-INF/lib/redEjbs.jar
WEB-INF/lib/blueEjbs.jar
The above is not invalid from a spec perspective and is impossible for the server to detect, but still can lead to apps not loading correctly. If libraryTwo.jar needs classes in libraryOne.jar then this app will never work as the Tomcat "lib" classloader cannot see classes from the "webapp" classloader, so classes from libraryTwo.jar will never successfully load. Unfortunately, the vm will almost never say the actual class that was missing and instead will report the first class in the chain of events that lead to needing a class that was missing. This is almost always a bean or servlet class.