I’m having trouble with my Tomcat6 setup and need some help. When I place my JAR file in the standard location at C:\Program Files\Atlassian\JIRA\webapps\MYAPP\WEB-INF\lib\customlibrary.jar, the server throws a ClassNotFoundException.
noclassdeffounderror - class initialization failed
However, when I move the same JAR to C:\Program Files\Atlassian\JIRA\lib\customlibrary.jar, everything works perfectly.
I’m running JIRA 4.4 on Windows using the JIRA.exe launcher. My WAR file is properly deployed in the webapps directory.
Is there something wrong with my classpath configuration? Where should I look for the classpath settings in this setup? I expected the WEB-INF/lib folder to work since that’s the standard location for web application libraries.
yeah, it kinda seems like ur right about the classloading. maybe there’s somethin in the main lib that’s messin with it. double-check versioning to be sure, but that could def be the cause of the issue.
This actually makes sense once you know how JIRA’s deployment works. JIRA runs as an embedded app where the main classloader beats webapp-specific ones. The C:\Program Files\Atlassian\JIRA\lib\ directory loads at server level, but WEB-INF/lib stays isolated in webapp context. I’ve seen this in JIRA deployments - custom libraries usually need server-level placement to work properly with JIRA’s plugin system and dependency injection. That ClassNotFoundException happens because core JIRA components try accessing your library before the webapp classloader even starts up. Super common when your JAR has classes JIRA’s startup needs. For production, putting the JAR in the main lib directory is actually what Atlassian recommends for JIRA customizations.
This issue seems related to the JIRA classloader behavior. When you place the JAR in the main ‘lib’ directory, it is accessed by the parent classloader, which handles JIRA’s core dependencies. In contrast, the WEB-INF/lib directory may not be properly scanned due to JIRA’s unique application structure. I’ve experienced similar issues with plugins before, as JIRA’s classloading differs from standard Tomcat setups. It’s essential to verify if any conflicting dependencies exist within JIRA’s core that might interfere with your JAR. Observing the catalina.out log could provide more insight into any startup error messages. Additionally, ensure your library isn’t attempting to utilize classes that are restricted to the parent classloader.