What are these warnings in catalina.out? [duplicate]

In a nutshell, some ThreadLocals have not been cleaned properly. Most (if not all) J2EE-servers / Application Containers use thread pools for incoming requests and other tasks, to prevent the overhead of starting new threads all the time. The problem is that some libraries (and you yourself, if you don't know better) don't clean up their ThreadLocals after the execution of the task/request ends.

Normally, as the thread dies on end of execution, the objects stored in ThreadLocals are no longer referenced and the garbage collector takes care of removing such objects:

Each thread holds an implicit reference to its copy of a thread-local variable as long as the thread is alive and the ThreadLocal instance is accessible; after a thread goes away, all of its copies of thread-local instances are subject to garbage collection (unless other references to these copies exist).

But when the thread has been fetched from a thread pool, it does not die, but instead is returned to the pool. Since the thread is still alive, so are the referenced ThreadLocals. This manifests both as memory leaks and "leaking" of values from one request to another when the same ThreadLocal is used and the thread handling the request/task was used before.

You have one or more memory leaks in your application. For a full explanation of why these occur, which ones are your fault and what you can do to fix them see this presentation:http://people.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf

At least one of the JAXB messages appears to relate to a known bug:

org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks SEVERE: The web application [/MyApplication] created a ThreadLocal with key of type [com.sun.xml.bind.v2.ClassFactory$1] (value [com.sun.xml.bind.v2.ClassFactory$1@25442544]) and a value of type [java.util.WeakHashMap]

See JAXB-563 and JAXB-831 (NB - These are on java.net and require a login to even view). The first bug was supposedly fixed but as others have commented this is not fully fixed. The second bug has a suggested workaround which is to force a gc() before letting the context shutdown which does mitigate the problem (though not eliminate it entirely) - you can use a custom ServletContextListener and simply call System.gc() in the contextDestroyed() method.

As for the other errors you need to follow the other answers advice and do some serious debugging.