This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Following classes seem to be loaded by http://deadlock.netbeans.org/hudson/job/ergonomics/2571/ for no apparent reason. Please eliminate or justify their necessity: org.netbeans.modules.spring.beans.index.SpringBinaryIndexer org.netbeans.modules.spring.beans.index.SpringBinaryIndexer$Factory org.netbeans.modules.web.beans.analysis.CdiEditorAnalysisFactory org.netbeans.modules.web.beans.analysis.WebBeansModelAnalysisFactory org.netbeans.modules.web.el.ELIndexer$Factory org.netbeans.modules.web.el.ELLanguage org.netbeans.modules.web.jsf.editor.facelets.FaceletsLibraryDescriptor org.netbeans.modules.web.jsf.editor.facelets.FaceletsLibraryDescriptor$1Handler org.netbeans.modules.web.jsf.editor.facelets.LibraryDescriptor org.netbeans.modules.web.jsf.editor.index.JsfCustomIndexer$Factory org.netbeans.modules.web.jsf.editor.index.JsfIndexSupport org.netbeans.modules.websvc.api.jaxws.project.JaxWsBuildScriptExtensionProvider org.netbeans.modules.websvc.jaxwsmodel.project.J2seBuildScriptExtensionProvider org.netbeans.modules.websvc.jaxwsmodel.project.J2seJaxWsOpenHook How to: http://wiki.netbeans.org/FitnessViaWhiteAndBlackList
Guys could you have a look at these please? Martin: org.netbeans.modules.spring.beans.index.SpringBinaryIndexer org.netbeans.modules.spring.beans.index.SpringBinaryIndexer$Factory Marek: org.netbeans.modules.web.el.ELIndexer$Factory org.netbeans.modules.web.el.ELLanguage org.netbeans.modules.web.jsf.editor.facelets.FaceletsLibraryDescriptor org.netbeans.modules.web.jsf.editor.facelets.FaceletsLibraryDescriptor$1Handler org.netbeans.modules.web.jsf.editor.facelets.LibraryDescriptor org.netbeans.modules.web.jsf.editor.index.JsfCustomIndexer$Factory org.netbeans.modules.web.jsf.editor.index.JsfIndexSupport Denis: org.netbeans.modules.web.beans.analysis.CdiEditorAnalysisFactory org.netbeans.modules.web.beans.analysis.WebBeansModelAnalysisFactory org.netbeans.modules.websvc.api.jaxws.project.JaxWsBuildScriptExtensionProvider org.netbeans.modules.websvc.jaxwsmodel.project.J2seBuildScriptExtensionProvider org.netbeans.modules.websvc.jaxwsmodel.project.J2seJaxWsOpenHook Thanks!
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/3c9e1583a035 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #200050: Temporarily allowing web related classes
Not a stopper for 7.0.1 -> TM=7.1.
org.netbeans.modules.spring.beans.index.SpringBinaryIndexer org.netbeans.modules.spring.beans.index.SpringBinaryIndexer$Factory Spring framework can be part of Java SE project as well. BTW, it seems that there is no way to postpone loading of Indexer classes for now - see #187271. Maybe it can be good topic for Performance meeting. But as I said SpringBinaryIndexer has to be loaded anyway if the project doesn't contain Spring and I'm not aware of another place where to do that. But I will not resist any good idea.
>org.netbeans.modules.web.beans.analysis.CdiEditorAnalysisFactory >org.netbeans.modules.web.beans.analysis.WebBeansModelAnalysisFactory This is CDI related analysis tasks for editor. Currently they are enabled only for Web project. BUT there is a request to enable them for J2SE project as well. It could be a library with CDI features enabled. So they are needed and cannot be excluded. org.netbeans.modules.websvc.api.jaxws.project.JaxWsBuildScriptExtensionProvider org.netbeans.modules.websvc.jaxwsmodel.project.J2seBuildScriptExtensionProvider org.netbeans.modules.websvc.jaxwsmodel.project.J2seJaxWsOpenHook J2SE project can contain WS references. The purpose of these classes is support of WS client in the J2SE project. So they are needed. Classes are really Web related but even Web related stuff could present in J2SE projects.
> org.netbeans.modules.web.jsf.editor.facelets.FaceletsLibraryDescriptor > org.netbeans.modules.web.jsf.editor.facelets.FaceletsLibraryDescriptor$1Handler > org.netbeans.modules.web.jsf.editor.facelets.LibraryDescriptor > org.netbeans.modules.web.jsf.editor.index.JsfCustomIndexer$Factory > org.netbeans.modules.web.jsf.editor.index.JsfIndexSupport Facelets are not limited only to the web project. Any library binary jar file or javase project can contain tag library components(pages/classes/resources)or library descriptors which needs to be indexed to make the support work. > org.netbeans.modules.web.el.ELIndexer$Factory > org.netbeans.modules.web.el.ELLanguage Similar reason as above - EL can be contained in almost any web related content which can be also stored in java library projects. Facelets is a good example.
Thanks everyone for the comments - so is there any action that needs to be done?
Looks like all these features are conditionally enabled by a presence of certain resource on in a source root or on classpath. The parsing API could be enhanced to check the condition for you and instantiate your classes only when it is known you will process something. Can you please go through your classes and find some simple condition that is necessary for your technology to be on (and that will not be true in case of our testing JavaSE project)?
(In reply to comment #8) > Looks like all these features are conditionally enabled by a presence of > certain resource on in a source root or on classpath. The parsing API could be > enhanced to check the condition for you and instantiate your classes only when > it is known you will process something. > > Can you please go through your classes and find some simple condition that is > necessary for your technology to be on (and that will not be true in case of > our testing JavaSE project)? I can quickly answer about classes : org.netbeans.modules.web.beans.analysis.CdiEditorAnalysisFactory org.netbeans.modules.web.beans.analysis.WebBeansModelAnalysisFactory which I have wrote. They should be loaded if some classes are present in the Project's classpath. I need to look deeply to other three classes : org.netbeans.modules.websvc.api.jaxws.project.JaxWsBuildScriptExtensionProvider org.netbeans.modules.websvc.jaxwsmodel.project.J2seBuildScriptExtensionProvider org.netbeans.modules.websvc.jaxwsmodel.project.J2seJaxWsOpenHook because I'm not an author of this functionality. But they are also project related. So it seems in my case there will be enough to provide some method API which passes Project as argument and proceed based on it's return value.
Several comments to Jarda's idea: If the indexer + factory is written defensively it has nearly no closure. Parsing API does not know anything about java classes. Adding an SPI is the same as having indexer factory (instead of loading IndexerFactory the implementation of the SPI will be loaded)
org.netbeans.modules.spring.beans.index.SpringBinaryIndexer org.netbeans.modules.spring.beans.index.SpringBinaryIndexer$Factory Some Spring class or Spring package (as is now) could be used as the condition. So it should be loaded when any project would depend on JAR which contains specific package/class.
"Profiling" snapshot showing who loads what violator: http://netbeans.org/bugzilla/attachment.cgi?id=109525
The first check I see in the SpringBinaryIndexer is if (root.getFileObject("org/springframework") == null) { //NOI18N return; } the next one is String fileName = file.getNameExt().toLowerCase(); if (fileName !=null && fileName.endsWith("xsd) && ... Thus, if we want to avoid loading useless indexers, we could conditionally register it for: a) specific file in the archive b) specific mime type as "xsd" could be easily matched as a mime type I'd recommend creating @interface BinaryIndexer.Registration { String[] requiredResource(); String[] acceptedMimeType(); } this annotation (better than current layer registration anyway) could generate a proxy implementation checking for the above conditions and only then instantiating the underlaying indexer.
Yes, it should be something like this. The AP will encode the resources and mimeTypes into FO attributes.
Created attachment 109565 [details] @BinaryIndexer.Registration and its usage I have a feeling I have once tried to write something like this, but I can't find the diff. Anyway here is new version. It misses tests and documentation, I might be improved to be more effective (by joining the scan through resources of the JAR to be done just once) and it is missing definition of the mimetype. Anyway I hope it gives the basic idea of what could be done.
Actually it is not clear to me who should own this issue. The Jarda's patch would have to be integrated to the parsing API so trying to assign to Tomas. Once the change is there the web-related binary indexers may be modified to use it as well.
I will take a care of it.
The proposed patch cannot be taken as it is as it's has negative impact on performance while scanning jars which match the criteria. So I am updating it to resolve this problem, but it will require that all the affected indexers (those which are using the introduced annotation) has to be rewritten.
The parsing.api part has been fixed and integrated, jet-main d054f910d8f6. I've also updated spring binary indexer, the others should be updated by owners. Basically the binary indexer needs to extends ConstrainedBinaryIndexer and has to be registered by the ConstrainedBinaryIndexer.Registration annotation. All the checks should be done in declarative way and removed from indexer. The indexer should not lookup the resources in jar but it should rather use the files where it has the files of the mime type it has specified as required. Assigning to Marek (sorry) I have no idea who owns the other indexers, please reassign. Thanks.
JsfBinaryIndexer is now ConstrainedBinaryIndexer so should not be loaded until some of the searched mimetypes are found the binary archives: web-main#5bbfc13db986 org.netbeans.modules.web.el.ELIndexer is en embedding indexer which indexes expression language expressions which are usually embedded in xhtml (facelets) files which may reside in a java library project. Since it is an embedding indexer it should be ok since *I assume the infrastructure triggers the indexer only if a file containing some EL appears in the classpath root*. JsfCustomIndexer is an instance of CustomIndexer which looks for .taglib.xml and .tld descriptors on source path. Tomasi, couldn't you create a similar support as for the binary indexers also for the CustomIndexer-s? Last part org.netbeans.modules.websvc.*: Reassigning the issue to Denis since his last comment "I need to look deeply to other three classes" implies he may did some other investigations.
ConstrainedBinaryIndexer as a fix in the parsing API has no direct (or any) relation to mentioned classes in my areas : org.netbeans.modules.web.beans.analysis.CdiEditorAnalysisFactory org.netbeans.modules.web.beans.analysis.WebBeansModelAnalysisFactory and org.netbeans.modules.websvc.api.jaxws.project.JaxWsBuildScriptExtensionProvider org.netbeans.modules.websvc.jaxwsmodel.project.J2seBuildScriptExtensionProvider org.netbeans.modules.websvc.jaxwsmodel.project.J2seJaxWsOpenHook The first two classes are EditorAwareJavaSourceTaskFactory instances ( JavaSourceTaskFactory services ) and mentioned fix doesn't help to avoid loading them for any project. To solve the problem something similar to proposed fix should be done for JavaSourceTaskFactory services. F.e. in this specific case loading indicator is presence some classes in the classpath of the project ( classpath is not static so infrastructure should somehow recheck the condition on some event. In the specific case : classpath modification ). The last three classes are WS specific ProjectServiceProvider classes. They has no relation to the parsing at all. I've already said that J2SE project could has WS references so this classes could be required. Again: they should be loaded on some condition : some files should present inside project directory ( in the specific case those files are build scripts in the nbproject directory ). So I can't do anything with mentioned classes respectively fix in the parsing api.
In reply to comment 21. None of these loaded classes has something in common with parsing api. The SourceFactories are java.source The J2seBuildScriptExtensionProvider and JaxWsBuildScriptExtensionProvider is websvc.jaxwsmodel and has to be fixed there. The @PSP guards you that the service is loaded when its needed (someone looks it up). The J2seJaxWsOpenHook if really needed os OK to load. As far as I understand it forces the IDE to load the J2seBuildScriptExtensionProvider and JaxWsBuildScriptExtensionProvider classes. SO it should be responsible for doing the check before loading them. Anyway none of these classes has static initializer so it's not a big problem to load them, it costs nearly nothing. But in any case parsing api cannot help you at all.
Denis, would you please look at J2seBuildScriptExtensionProvider and JaxWsBuildScriptExtensionProvider? Is it possible to not load them? > Anyway none of these classes has static initializer so it's not a big problem to load them, it costs nearly > nothing. I agree, it sounds like this is no longer a P2, changing priority to P3.
(In reply to comment #23) > Denis, would you please look at J2seBuildScriptExtensionProvider and > JaxWsBuildScriptExtensionProvider? Is it possible to not load them? > I did a search against all classes in the trunk and found JaxWsBuildScriptExtensionProvider interface is used only inside websvc.jaxwsmodel module. So there is no need to have it at all. Its implementation for each project type could be moved into ProjectOpenHook impl classes. As result there will be no need to load JaxWsBuildScriptExtensionProvider and its impl classes ( J2seBuildScriptExtensionProvider for j2se project ). Moreover those classes could be safely deleted at all.
Unfortunately JaxWsBuildScriptExtensionProvider is used also in the JaxWsModelImpl class. It is possible to put basic logic into the ProjectOpenHook impl class and extend it for JaxWsModel interface as a service. Such approach could allow to delete JaxWsBuildScriptExtensionProvider at all along with its impl classes. But there is an issue #205151 which doesn't allow to find service in the lookup if impl class is also ProjectOpenHook service. So I cannot remove JaxWsBuildScriptExtensionProvider with its impl classes for now.
Is this issue still valid? If so, can we make any further improvements in this area? Or is this issue WONTFIX?
Reassigning to JaxWS. As I understand the discussion only classes where we need to do something else are from web services area. On the other hand if I understand comment 22 well, it costs almost nothing to load them and maybe it would make more sense to just close the issue as all important parts were already fixed few years ago.