|
[jira] Created: (QDOX-148) Allow to disable usage of "default" class loaders
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
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
|
|
RE: [jira] Created: (QDOX-148) Allow to disable usage of "default" class loaders
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Is there maybe another option: rearranging the order of classloaders. I guess the required classloader is somewhere available, isn't it?
Robert > Date: Tue, 17 Feb 2009 10:32:21 -0600 > From: jira@...> To: dev@...> Subject: [qdox-dev] [jira] Created: (QDOX-148) Allow to disable usage of "default" class loaders > > 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 > > > 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 > >
Express yourself instantly with MSN Messenger! MSN Messenger
|
|
[jira] Updated: (QDOX-148) Allow to disable usage of "default" class loaders
[ http://jira.codehaus.org/browse/QDOX-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Bentmann updated QDOX-148:
-----------------------------------
Attachment: qdox-148.patch
A not so beauty unit test for this.
> 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
>
>
> 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
|
|
[jira] Updated: (QDOX-148) Allow to disable usage of "default" class loaders
[ 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
|
|
[jira] Commented: (QDOX-148) Allow to disable usage of "default" class loaders
[ http://jira.codehaus.org/browse/QDOX-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=166618#action_166618 ]
Benjamin Bentmann commented on QDOX-148:
----------------------------------------
While the try/catch is surely an improvement, I still believe the option to exclude the default class loaders is worth to consider. I mean if tool A uses QDox to scan the sources of project B, what's the rationale for QDox trying to load classes from A's class path when A and B are totally different/independent projects? A and B might have some dependencies in common but in the general case that's rather by incident than by design, isn't it? If A wants to fully traverse the class hierarchy of B, the only proper way is for A to register a custom class loader with QDox that resembles B's class path.
> 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
|
|
[jira] Commented: (QDOX-148) Allow to disable usage of "default" class loaders
[ http://jira.codehaus.org/browse/QDOX-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=166628#action_166628 ]
Robert Scholte commented on QDOX-148:
-------------------------------------
I agree we need to have control over the classloaders. I'm thinking of introducing an new constructor to the JavaDocBuilder with a ClassLibrary as argument. This way you can add your own classloaders.
And after a second look, the exception should be pulled up to the createBinaryClass. If a CDNF-Exception occurs it should return null.
> 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
|
|
[jira] Updated: (QDOX-148) Allow to disable usage of "default" class loaders
[ http://jira.codehaus.org/browse/QDOX-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Scholte updated QDOX-148:
--------------------------------
Attachment: qdox-148.1.patch
patch created as mentioned. JavaDocBuilder has new constructors with ClassLibrary support and there's a big try/catch inside createBinaryClass. Don't think it's usefull to catch every small step while builder a JavaClass, one mistake makes this JavaClass broken, so it's better to return null asap.
> 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.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
|
|
[jira] Commented: (QDOX-148) Allow to disable usage of "default" class loaders
[ http://jira.codehaus.org/browse/QDOX-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=166913#action_166913 ]
Benjamin Bentmann commented on QDOX-148:
----------------------------------------
Looks good to me :-)
> 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.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
|
|
RE: [jira] Commented: (QDOX-148) Allow to disable usage of "default" class loaders
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Hi all,
I'm thinking of committing this patch.
There's a test which kind of covers this issue. Not completly but enough I guess.
It's a complicated issue, so the test is complicated as well :)
There are two ways to prepare this test, it's just a matter of taste.
1: Let Ant compile 2 files and delete the one which is an dependency for the other.
[+] You still have the sourcecode available
[-] You have call ant on resources:testResources. There will be some magic in the target/test-classes, since the inputfile was a build.xml, output only 1 source.class
2: Commit the generated class in the test-resouces folder
[+] No magic going on, straightforward
[-] Loss of sourcecode
another option is of course to skip the test.
Any thoughts?
Robert
> Date: Tue, 24 Feb 2009 14:14:19 -0600 > From: jira@...> To: dev@...> Subject: [qdox-dev] [jira] Commented: (QDOX-148) Allow to disable usage of "default" class loaders > > > [ http://jira.codehaus.org/browse/QDOX-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=166913#action_166913 ] > > Benjamin Bentmann commented on QDOX-148: > ---------------------------------------- > > Looks good to me :-) > > > 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.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 > >
Express yourself instantly with MSN Messenger! MSN Messenger
|
|
[jira] Closed: (QDOX-148) Allow to disable usage of "default" class loaders
[ http://jira.codehaus.org/browse/QDOX-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Scholte closed QDOX-148.
-------------------------------
Assignee: Robert Scholte
Resolution: Fixed
Fix Version/s: 1.10
r573 | rfscholte | 2009-03-02 19:26:08 CET
patch applied for qdox-148
----------------------------------------------------------------------------
> 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
|
|
[jira] Reopened: (QDOX-148) Allow to disable usage of "default" class loaders
[ http://jira.codehaus.org/browse/QDOX-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Hammant reopened QDOX-148:
-------------------------------
> 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
|
|
[jira] Resolved: (QDOX-148) Allow to disable usage of "default" class loaders
[ http://jira.codehaus.org/browse/QDOX-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Hammant resolved QDOX-148.
-------------------------------
Resolution: Fixed
Fix Version/s: (was: 1.10)
1.9.1
> 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
|
|
[jira] Reopened: (QDOX-148) Allow to disable usage of "default" class loaders
[ 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
|
|
[jira] Commented: (QDOX-148) Allow to disable usage of "default" class loaders
[ http://jira.codehaus.org/browse/QDOX-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175649#action_175649 ]
Paul Hammant commented on QDOX-148:
-----------------------------------
Benjamin, make a version for yourselves that works best (and field test), then get us the patch (or tell is what it was). It could be a bit trial and error if we try it any other way :)
> 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
|
|
[jira] Commented: (QDOX-148) Allow to disable usage of "default" class loaders
[ 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
|
|
[jira] Resolved: (QDOX-148) Allow to disable usage of "default" class loaders
[ 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
|
|
[jira] Updated: (QDOX-148) Allow to disable usage of "default" class loaders
[ http://jira.codehaus.org/browse/QDOX-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Hammant updated QDOX-148:
------------------------------
Affects Version/s: (was: 1.6.1)
1.9.2
> 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.2
> Reporter: Benjamin Bentmann
> Assignee: Robert Scholte
> Fix For: 1.9.2
>
> 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
|
|
[jira] Updated: (QDOX-148) Allow to disable usage of "default" class loaders
[ http://jira.codehaus.org/browse/QDOX-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Hammant updated QDOX-148:
------------------------------
Affects Version/s: (was: 1.9.2)
1.6.2
Fix Version/s: (was: 1.10)
1.9.2
> 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.2
> Reporter: Benjamin Bentmann
> Assignee: Robert Scholte
> Fix For: 1.9.2
>
> 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
|
