[
http://jira.codehaus.org/browse/QDOX-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated QDOX-148:
--------------------------------
Attachment: qdox-148.patch
I might have found a cleaner solution then trying to unload some classloaders.
When for some reason a binaryclass can't be resolved, an unknownClass will be
created which will be added to the classcache. This code was already there, but
it only checked if createBinaryClass(name) would result in null.
The proposal it to surround it with a try/catch for ClassDefNotFoundException
> Allow to disable usage of "default" class loaders
> -------------------------------------------------
>
> Key: QDOX-148
> URL: http://jira.codehaus.org/browse/QDOX-148
> Project: QDox
> Issue Type: New Feature
> Components: Parser
> Affects Versions: 1.6.1
> Reporter: Benjamin Bentmann
> Attachments: qdox-148.patch, qdox-148.patch
>
>
> Both available constructors of {{JavaDocBuilder}} will eventually call
> {code:java}
> classLibrary.addDefaultLoader();
> {code}
> As far as I see, there is currently no way to disable/remove these default
> loaders.
> This is problematic when the code using QDox and the code being analyzed
> depend on the same class file (but possibly a different version). Imagine a
> project with an annotated source file S that extends a class C from a
> third-party JAR. Further imagine a build tool that employs QDox to scan the
> previously mentioned source file S. When the scan walks up to the super class
> C of S, QDox ends up in {{ClassLibrary.getClass()}} and iterates over the
> class loaders to load the class C from its binary. Now imagine the build tool
> itself also depends on this binary class C and the build tool's class loader
> was used to create the {{JavaDocBuilder}} instance used for the scan. In this
> scenario, QDox will load C from the dependencies of the build tool instead of
> the dependencies of the project whose sources are actually scanned. In other
> words, the class path of the QDox client pollutes the analysis.
> Possible solutions could be a additional constructors for {{JavaDocBuilder}}
> to disable addition of the default class loaders or a new method
> {{clearClassLoaders()}} in {{ClassLibrary}}.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
