tomcat6 with spring throws org/springframework/core/NestedExceptionUtils

[Bruce Edge]

Binary package hint: tomcat6

Here's a stack trace when I try to load my app with the ubuntu packaged jaunty tomcat6:

May 10, 2009 11:11:28 AM org.apache.catalina.core.StandardContext listenerStart
SEVERE: Exception sending context initialized event to listener instance of class org.springframework.web.context.ContextLoaderListener
java.lang.NoClassDefFoundError: org/springframework/core/NestedExceptionUtils
        at org.springframework.core.NestedRuntimeException.getMessage(NestedRuntimeException.java:67)
        at java.lang.Throwable.getLocalizedMessage(Throwable.java:284)
        at java.lang.Throwable.toString(Throwable.java:360)
        at org.springframework.beans.factory.BeanCreationException.toString(BeanCreationException.java:150)
        at java.lang.String.valueOf(String.java:2838)
        at java.io.PrintWriter.println(PrintWriter.java:727)
        at java.lang.Throwable.printStackTrace(Throwable.java:526)
        at org.springframework.beans.factory.BeanCreationException.printStackTrace(BeanCreationException.java:176)
        at java.util.logging.SimpleFormatter.format(SimpleFormatter.java:94)
        at org.apache.juli.FileHandler.publish(FileHandler.java:129)
        at java.util.logging.Logger.log(Logger.java:476)
        at java.util.logging.Logger.doLog(Logger.java:498)
        at java.util.logging.Logger.logp(Logger.java:698)
        at org.apache.commons.logging.impl.Jdk14Logger.log(Jdk14Logger.java:101)
        at org.apache.commons.logging.impl.Jdk14Logger.error(Jdk14Logger.java:149)
        at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:215)
        at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:45)
        at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3843)
        at org.apache.catalina.core.StandardContext.start(StandardContext.java:4342)
        at org.apache.catalina.manager.ManagerServlet.start(ManagerServlet.java:1247)
        at org.apache.catalina.manager.HTMLManagerServlet.start(HTMLManagerServlet.java:604)
        at org.apache.catalina.manager.HTMLManagerServlet.doGet(HTMLManagerServlet.java:129)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:244)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.Subject.doAsPrivileged(Subject.java:537)
        at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:276)
        at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:162)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:283)
        at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:56)
        at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:185)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
        at java.lang.Thread.run(Thread.java:636)
Caused by: java.lang.ClassNotFoundException: org.springframework.core.NestedExceptionUtils
        at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1387)
        at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1233)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:336)
        ... 49 more

The same problem reported here:
http://<email address hidden>/msg57804.html

Where the result was "check with your packager".

My app also runs fine with the apache tgz tomcat6.

I'll attaching the war I'm deploying that is causing this.

#> dpkg -l | grep tomcat
ii libtomcat6-java 6.0.18-0ubuntu6 Servlet and JSP engine -- core libraries
ii tomcat6 6.0.18-0ubuntu6 Servlet and JSP engine
ii tomcat6-admin 6.0.18-0ubuntu6 Servlet and JSP engine -- admin web applications
ii tomcat6-common 6.0.18-0ubuntu6 Servlet and JSP engine -- common files
ii tomcat6-docs 6.0.18-0ubuntu6 Servlet and JSP engine -- example web applications
ii tomcat6-examples 6.0.18-0ubuntu6 Servlet and JSP engine -- example web applications
ii tomcat6-user 6.0.18-0ubuntu6 Servlet and JSP engine -- tools to create user instances

#> java -version
java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.4.1) (6b14-1.4.1-0ubuntu7)
OpenJDK 64-Bit Server VM (build 14.0-b08, mixed mode)

[Bruce Edge (bruce-edge)]

Forgot platform details:
This is an up to data jaunty 64 bit system.

It's running without an X server, if that matters. I know some java apps barf because of this.

 #> update-java-alternatives -l
java-6-openjdk 1061 /usr/lib/jvm/java-6-openjdk
java-gcj 1042 /usr/lib/jvm/java-gcj

It's set to java-6-openjdk

Other than adding a tomcat user I have zero changes to the tomcat6 config.

Let me know if you need _anything_ else.

I would very much like to use the prepackaged tomcat6 as opposed to the apache tgz for reasons of recreatibility, integration and simplicity.

-Bruce

[Bruce Edge (bruce-edge)]

Found a workaround, disabling TOMCAT_SECURITY in /etc/init.d/tomcat6 allows this app to run.

-Bruce

[Thierry Carrez (ttx)]

Yes, by default we run Tomcat with a security manager, which means you need to configure rights for your application in the policy files.

See instructions at:
http://tomcat.apache.org/tomcat-6.0-doc/security-manager-howto.html

Given the complexity of getting security policy files right, depending on your environment it may make sense to run without the security manager (i.e. disabling TOMCAT_SECURITY). The security manager is just another layer for security in depth, restricting what the code run can ultimately do with your system.

By the way, this is not a specificity in our Tomcat packaging... It would also fail with a stock Tomcat 6 if you enabled the security manager without configuring policy files to give proper rights to your application.

Closing as invalid as this is not a bug.

[Calum (caluml)]

I'd just like to say that I'm getting this too, and the big problem here is that there is nothing in any logs I can see that actually says what the permission not being granted is.

Usually, the error includes something like...

java.security.AccessControlException: access denied (java.util.PropertyPermission webapp.root read)

which makes it very obvious what to put in the security manager policy files.

The errors generated by this don't have any of the exceptions above, which means I'm stuck as to what it is wanting.

[Calum (caluml)]

Also, I don't want to just disable the security manager which is mentioned as a workaround above.

[Calum (caluml)]

Can we have another look at this one, please?

[Thierry Carrez (ttx)]

This bug was closed because it's assumed to be a Spring / Tomcat6 SecurityManager incompatibility (then it's not a bug in our Tomcat6 packaging).

Do you manage to run it with a SecurityManager with the stock Tomcat6 from Apache, and the same JDK ? If yes, then it's a valid Ubuntu bug, and please attach the SecurityManager configuration you used. If not, then it's a bug in Tomcat6 or Spring.

[Thierry Carrez (ttx)]

We'd like to figure out what's causing this bug for you, but we haven't heard back from you in a while. Could you please provide the requested information? Thanks!

[Calum (caluml)]

I'm just at work now, so I'll have a look when I'm back at home.

On Wed, Oct 14, 2009 at 2:57 PM, Thierry Carrez
<email address hidden> wrote:
> We'd like to figure out what's causing this bug for you, but we haven't
> heard back from you in a while. Could you please provide the requested
> information? Thanks!

[Thierry Carrez (ttx)]

We'd like to figure out what's causing this bug for you, but we haven't heard back from you in a while. Could you please provide the requested information? Thanks!

[Chuck Short (zulcss)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

[Bob Kerns (rwk)]

Reopening, with added information and a better workaround...

The problem here is that insufficient privileges are given to tomcat-juli.jar in /etc/tomcat6/policy.d/03catalina.policy.

i haven't determined yet the specific missing permissions, but giving this jar file all permissions does resolve the issue.

You probably need some error in need of logging to reproduce it.

It would seem to me that it must be something needed by the classloader to produce this symptom. In particular, in trying to load one class form the spring-core.xxxx.jar file, it fails to find another class in the same jar file. This should always succeed!

In googling around, I find quite a number of people have run into this. The tomcat people blame it on the 3rd-party packagers (I believe that be you!). Everyone else ends up disabling security entirely as a "workaround".

This is a much better workaround:

// Workaround for missing permissions on tomcat-juiljar
grant codeBase "file:${catalina.home}/bin/tomcat-juli.jar" {
     permission java.security.AllPermission;
};

Also note that you can give AllPermission to the webapp itself,, and it does NOT solve the problem. This places the blame squarely on the distro's security configuration rather than on the application and Spring -- I think. (Between security and classloaders, there's plenty of room for confusion!)

BTW, kudos for at least trying to get it installed with a working security configuration, even if it isn't 100%. It is a real pain to work out the right security policy, and it is well worth getting the basics right and sharing the result. And configuring it by dropping in my webapp's policy is a breeze, even if I DID end up giving it AllPermission for now.

[Bob Kerns (rwk)]

BTW, this was originally reported in Jaunty -- I'm encountering it in Karmic Koala.

[Thierry Carrez (ttx)]

Yes, to match upstream behavior we disabled security by default in Lucid (10.04), which basically avoids the problem altogether. I still think we should strive for a better security configuration shipped in the package though (for those trying to enable it), so I will test and add your suggested snippet. Thanks !

[Bob Kerns (rwk)]

Great!

It would be even better if someone (you or I or an interested bystander) figured out just what permissions it really needs. I tried guessing, but that didn't work. Since (as is typical of classloader issues) it doesn't really tell you what went wrong, this probably needs either seriously systematic trial-and-error or setting up to attach a debugger.

BTW, enabling security by default led to a bug in Apache Tiles getting fixed, so some good came of the experiment!

(Every time I see 'Lucid' I think of the Lisp company of the same name from the '80's and early '90's.)