You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by "Juan Pablo Santos RodrÃguez (JIRA)" <ji...@apache.org> on 2014/01/20 21:37:19 UTC
[jira] [Commented] (JSPWIKI-812) startup fails when having plugin
jars in tomcat's lib dir
[ https://issues.apache.org/jira/browse/JSPWIKI-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13876840#comment-13876840 ]
Juan Pablo Santos RodrÃguez commented on JSPWIKI-812:
-----------------------------------------------------
Hi,
the stacktrace is produced by a classloading issue:
1) the VM/system classpath can see/use its own classes
2) the container can see/use its own classes + system's classpath classes
3) the webapp can see/use its own classes + container's classpath classes + system's classpath classes
the webapp can load the tomcat's lib plugin, as it _can see_ it, but the plugin in tomcat's lib only sees container's classpath, so it _can't see_ the WikiPlugin interface, which is on webapp's classpath, hence the exception.
We can turn this issue into an enhancement request though, by changing it into providing an external dir to be used as an "extension" point. The application should load on classpath all classes \[#1] & resources \[#2] found in that directory.
Another approach to war surgery could be war overlaying \[#3], but this means we won't use the vanilla war and stick to a custom war.
\[#1]: http://stackoverflow.com/a/15601071
\[#2]: http://stackoverflow.com/a/5957981
\[#3]: http://maven.apache.org/plugins/maven-war-plugin/overlays.html
> startup fails when having plugin jars in tomcat's lib dir
> ---------------------------------------------------------
>
> Key: JSPWIKI-812
> URL: https://issues.apache.org/jira/browse/JSPWIKI-812
> Project: JSPWiki
> Issue Type: Bug
> Components: Plugins
> Affects Versions: 2.9, 2.9.1, 2.10
> Environment: Ubuntu Linux Mint 14 Nadia
> Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
> JSPWiki 2.10.0
> Reporter: Harry Metske
>
> I stumbled upon this bug while testing a non-core plugin.
> To reproduce :
> * add the plugin jar tomcat's lib directory (not the WEB-INF/lib dir of jspwiki)
> * update the jspwiki.plugin.searchPath property to include the plugin's package name
> * create a page that references the page
> * restart your wiki
> It will not initialize and throw the following exception :
> {noformat}
> Jan 18, 2014 1:20:24 PM org.apache.catalina.core.StandardContext filterStart
> SEVERE: Exception starting filter WikiJSPFilter
> java.lang.NoClassDefFoundError: org/apache/wiki/api/plugin/WikiPlugin
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:792)
> at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:270)
> at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1700)
> at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1558)
> at org.apache.wiki.util.ClassUtil.findClass(ClassUtil.java:103)
> at org.apache.wiki.plugin.DefaultPluginManager.findPluginClass(DefaultPluginManager.java:256)
> at org.apache.wiki.plugin.DefaultPluginManager.newWikiPlugin(DefaultPluginManager.java:769)
> at org.apache.wiki.parser.PluginContent.executeParse(PluginContent.java:217)
> at org.apache.wiki.parser.JSPWikiMarkupParser.handleHyperlinks(JSPWikiMarkupParser.java:1467)
> at org.apache.wiki.parser.JSPWikiMarkupParser.handleOpenbracket(JSPWikiMarkupParser.java:2269)
> at org.apache.wiki.parser.JSPWikiMarkupParser.parseToken(JSPWikiMarkupParser.java:2844)
> at org.apache.wiki.parser.JSPWikiMarkupParser.fillBuffer(JSPWikiMarkupParser.java:2643)
> at org.apache.wiki.parser.JSPWikiMarkupParser.parse(JSPWikiMarkupParser.java:2916)
> at org.apache.wiki.providers.CachingProvider.refreshMetadata(CachingProvider.java:441)
> at org.apache.wiki.providers.CachingProvider.getPageInfo(CachingProvider.java:484)
> at org.apache.wiki.PageManager.getPageInfo(PageManager.java:420)
> at org.apache.wiki.WikiEngine.getPage(WikiEngine.java:1892)
> at org.apache.wiki.WikiEngine.getPage(WikiEngine.java:1872)
> at org.apache.wiki.ReferenceManager.initialize(ReferenceManager.java:267)
> at org.apache.wiki.WikiEngine.initReferenceManager(WikiEngine.java:728)
> at org.apache.wiki.WikiEngine.initialize(WikiEngine.java:623)
> at org.apache.wiki.WikiEngine.<init>(WikiEngine.java:430)
> at org.apache.wiki.WikiEngine.getInstance(WikiEngine.java:370)
> at org.apache.wiki.ui.WikiServletFilter.init(WikiServletFilter.java:82)
> at org.apache.wiki.ui.WikiJSPFilter.init(WikiJSPFilter.java:88)
> at org.apache.catalina.core.ApplicationFilterConfig.initFilter(ApplicationFilterConfig.java:281)
> at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:262)
> at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:107)
> at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4746)
> at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5399)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
> at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)
> at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1114)
> at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1673)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> Caused by: java.lang.ClassNotFoundException: org.apache.wiki.api.plugin.WikiPlugin
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 53 more
> {noformat}
> If you undo one of the three steps, problem is solved.
> Also, if you move (not copy) the plugin jar to jspwiki's WEB-INF/lib directory, the problem does not occur.
> We want to stay away from war surgery and therefore having plugin jars in tomcat's lib directory should be possible.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)