[
http://jira.codehaus.org/browse/QDOX-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175655#action_175655
]
Robert Scholte commented on QDOX-148:
-------------------------------------
During an IRC-session Benjamin and I have worked on this problem. Finally we
came with this constructor-solution which seems very elegant. By using your own
{{ClassLibrary}} you would have full control on the dependencies which may be
used by the {{JavaDocBuilder}}. But now it seems it's not (yet) possible to
create your own library because of the required {{JavaClassCache}}.
It has become more of an architectural problem.
Although the {{addClassLoader()}} is the most simple solution I don't really
like this option. Maybe it's just not so nice that {{JavaDocBuilder}}
implements {{JavaClassCache}}. It might be better to have the cache as a
variable. It's just a first thought, can't see which complication might occur
yet.
Meanwhile it's not a problem if classes are missing, because of the
try/catch-block, but it would be better if you can decide which classes are
available on the classpath. Like the type says: it's a new feature, not a bug.
> 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
