[
https://issues.apache.org/jira/browse/XBEAN-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14003419#comment-14003419
]
Matt Benson edited comment on XBEAN-265 at 5/20/14 3:22 PM:
------------------------------------------------------------
{quote}
async or not the finder behavior should be the same.
{quote}
What about "Calling {{#link()}} before or after making other calls against the
{{AnnotationFinder}} instance the behavior should be the same?"
I'm only talking about finding classes that are *entries* in the {{Archive}},
but it seems to me pretty useless, not to mention impossible, if the classes
found can only reference other classes that are also *entries* in the
{{Archive}}. Every (normal) class extends {{java.lang.Object}} and very few
actual archives contain this class. In any case, the error only happens when,
at runtime, the decision is made to use class-based, rather than name-based,
functionality.
{quote}
For your particular issue, would adding a CompositeURLsArchive(URLs) work?
{quote}
I still don't see how it would. My test cases demonstrate what I want: to
search a specific location (jar, directory, whatever) for classes X that extend
or implement some class or interface Y where Y may not be in the archive
itself. If I included Y's archive K in the search, taking the suggested
composite approach, I would also potentially find classes in K that extend or
implement Y, which is not what I want.
If the problem is that this call caused a {{ConcurrentModificationException}}
or similar in the {{AsynchronousInheritanceAnnotationFinder}} then let's
improve its design to be more tolerant of such... this is par for the course
when designing something that is expected to run in a threaded manner. To that
end, it'd be quite nice to have some Javadoc explaining the _intent_ of that
class.
EDIT: I confess that on reviewing the synchronization code in
{{AsynchronousInheritanceAnnotationFinder}} I fail to see what could go wrong
by simply restoring this method. And that's why we need a test.
was (Author: mbenson):
{quote}
async or not the finder behavior should be the same.
{quote}
What about "Calling {{#link()}} before or after making other calls against the
{{AnnotationFinder}} instance the behavior should be the same?"
I'm only talking about finding classes that are *entries* in the {{Archive}},
but it seems to me pretty useless, not to mention impossible, if the classes
found can only reference other classes that are also *entries* in the
{{Archive}}. Every (normal) class extends {{java.lang.Object}} and very few
actual archives contain this class. In any case, the error only happens when,
at runtime, the decision is made to use class-based, rather than name-based,
functionality.
{quote}
For your particular issue, would adding a CompositeURLsArchive(URLs) work?
{quote}
I still don't see how it would. My test cases demonstrate what I want: to
search a specific location (jar, directory, whatever) for classes X that extend
or implement some class or interface Y where Y may not be in the archive
itself. If I included Y's archive K in the search, taking the suggested
composite approach, I would also potentially find classes in K that extend or
implement Y, which is not what I want.
If the problem is that this call caused a {{ConcurrentModificationException}}
or similar in the {{AsynchronousInheritanceAnnotationFinder}} then let's
improve its design to be more tolerant of such... this is par for the course
when designing something that is expected to run in a threaded manner. To that
end, it'd be quite nice to have some Javadoc explaining the _intent_ of that
class.
> Regression: cannot find subclasses/implementations of "external" classes
> after forcing ClassInfo.get()
> ------------------------------------------------------------------------------------------------------
>
> Key: XBEAN-265
> URL: https://issues.apache.org/jira/browse/XBEAN-265
> Project: XBean
> Issue Type: Bug
> Components: finder
> Affects Versions: 3.15, 3.16, 3.17
> Reporter: Matt Benson
> Labels: patch, test
>
> By "external" I mean available in the archive's classloader but not its
> iterated entries. In general it is rather difficult to test the class-based
> portion of {{AnnotationFinder}}'s implementation, but it can be done by
> calling {{#findAnnotatedClasses()}} before {{#link()}}. Then it is possible
> to demonstrate the problem.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
