[
http://jira.codehaus.org/browse/QDOX-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte resolved QDOX-148.
---------------------------------
Resolution: Fixed
Fix Version/s: (was: 1.9.1)
1.10
r600 | rfscholte | 2009-05-21 13:13:00 CEST
I've introduced a JavaClassContext, to split the responsibilities of classes.
You don't access the classLibrary or cache directly, but through the context.
just ask the context for a JavaClass and it will look in it's cache. If it's
not there, it'll use the classLibrary to get the definition of the class and
with the javadocbuilder an new JavaClass will be generated and put into the
cache.
Important to know: JavaDocBuilder doesn't implement javaCache any longer.
It's not anymore required to create a classLibrary with a cache, so everybody
can have full control over the classloader.
> 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.10
>
> 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
