[
http://jira.codehaus.org/browse/QDOX-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann reopened QDOX-148:
------------------------------------
There's a problem we missed with the new constructors: How to create the
{{ClassLibrary}} to pass into the {{JavaDocBuilder}}? To create a
{{ClassLibrary}}, a {{JavaClassCache}} needs to be provided for its
constructor. However, the intention is to have the {{JavaDocBuilder}} as
{{JavaClassCache}} so we have a cycle: It requires an existing
{{JavaDocBuilder}} to create the {{ClassLibrary}} and it requires an existing
{{ClassLibrary}} to create the {{JavaDocBuilder}} without default class loaders.
Probably the easiest way out is to simply provide a constructor in
{{JavaDocBuilder}} that provides a boolean parameter to skip the call to
{{addDefaultLoader()}}.
FWIW, the improved try/catch logic for linkage errors already saved
source-scanning Maven plugins from troubles so the remaining issue is of less
concern.
> 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
> Assignee: Robert Scholte
> Fix For: 1.9.1
>
> Attachments: qdox-148.1.patch, 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
