name patterns doesn't really solve it.
And since JDT it self can compile thousands of files based on jars within seconds/few
minute(s) it can't be true we get *that* overloaded for the very few things we need to
lookup can it ?
/max
On 26 Jul 2012, at 22:05, Xavier Coulon <xcoulon(a)redhat.com> wrote:
Slava,
Thanks for the feedback. I'm trying to see if I can even totally skip the jar
scanning: since some elements are part of the specification, their model representation
could simply be hard-coded instead of looking them up in the jars of the classpath. But
yes, skipping the jars from the jvm is a good idea.
Best regards,
/Xavier
On Jul 26, 2012, at 8:17 PM, Viacheslav Kabanovich wrote:
> In JSF/Seam/CDI we have marker files, so that we do not scan all jars.
>
> If JAX-RS has not a marker, may it be reasonable to use a preference listing some jar
names/patterns to be excluded from scanning? For example, huge rt.jar may be the first
item in that list, followed by most jars from JRE and JBoss Runtime.
>
> Slava
>
>
> On 07/26/2012 08:25 AM, Max Rydahl Andersen wrote:
>> Alexey, didn't you guys face the same issue with JSF/Seam/CDI class lookups
in the "old" days that using the eclipse search is much slower than other
lower-level mechanisms ?
>>
>> /max
>>
>> On 24 Jul 2012, at 12:19, Xavier Coulon wrote:
>>
>>> Hello,
>>>
>>> Pete Muir opened an issue a few weeks ago
(
https://issues.jboss.org/browse/JBIDE-12224) because he found that the JAX-RS tooling was
sometimes taking too much time to build. He also attached a video to show what's
happening on his machine:
http://screencast.com/t/pHBqxVas4
>>>
>>> Now, at the tooling level, here's what's happening: a set of jars are
added to the classpath, and as part of the project build, the JAX-RS builder searches for
some JAX-RS annotated types or methods in those new jars, using the Search API. Hélas,
Eclipse needs to index those jars, which sometimes takes a few seconds.
>>> Now, as opposed to the CDI specification where the jars should have a marker
file (META-INF/beans.xml), JAX-RS does not mandate anything similar, which means that the
search includes all the jars..
>>>
>>> Here's an example of the code that deals with annotated types search (in
ws/plugins/org.jboss.tools.ws.jaxrs.core/src/org/jboss/tools/ws/jaxrs/core/jdt/JaxrsAnnotationsScanner.java)
:
>>>
>>> private static List<IType> searchForAnnotatedTypes(final
Class<?> annotation, final IJavaSearchScope searchScope,
>>> final IProgressMonitor progressMonitor) throws CoreException {
>>> JavaMemberSearchResultCollector collector = new
JavaMemberSearchResultCollector(IJavaElement.TYPE, searchScope);
>>> SearchPattern pattern = SearchPattern.createPattern(annotation.getName(),
IJavaSearchConstants.ANNOTATION_TYPE,
>>> IJavaSearchConstants.ANNOTATION_TYPE_REFERENCE |
IJavaSearchConstants.TYPE, SearchPattern.R_EXACT_MATCH
>>> | SearchPattern.R_CASE_SENSITIVE);
>>> // perform search, results are added/filtered by the custom
>>> // searchRequestor defined above
>>> new SearchEngine().search(pattern, new SearchParticipant[] {
SearchEngine.getDefaultSearchParticipant() },
>>> searchScope, collector, progressMonitor);
>>> return collector.getResult(IType.class);
>>> }
>>>
>>>
>>> Do you know any way to reduce the latency at this level ? Is there any trick
to improve the speed ?
>>>
>>> Thanks in advance
>>> Best regards,
>>> /Xavier
>>>
>>>
>>>
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>