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.

Bug 200050 - Web related classes loaded on startup with JavaSE project
Summary: Web related classes loaded on startup with JavaSE project
Status: RESOLVED WONTFIX
Alias: None
Product: webservices
Classification: Unclassified
Component: JAX-WS (show other bugs)
Version: 7.0
Hardware: Other Linux
: P3 normal (vote)
Assignee: Milan Kuchtiak
URL:
Keywords: PERFORMANCE
Depends on: 204817 205151
Blocks:
  Show dependency tree
 
Reported: 2011-07-11 14:33 UTC by Jaroslav Tulach
Modified: 2016-05-25 06:17 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
@BinaryIndexer.Registration and its usage (15.35 KB, patch)
2011-07-22 08:40 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2011-07-11 14:33:40 UTC
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
Comment 1 David Konecny 2011-07-11 22:01:45 UTC
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!
Comment 2 Quality Engineering 2011-07-12 14:17:16 UTC
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
Comment 3 Petr Jiricka 2011-07-13 11:42:39 UTC
Not a stopper for 7.0.1 -> TM=7.1.
Comment 4 Martin Fousek 2011-07-15 15:04:01 UTC
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.
Comment 5 Denis Anisimov 2011-07-18 07:18:06 UTC
>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.
Comment 6 Marek Fukala 2011-07-18 09:02:40 UTC
> 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.
Comment 7 Petr Jiricka 2011-07-18 09:55:08 UTC
Thanks everyone for the comments - so is there any action that needs to be done?
Comment 8 Jaroslav Tulach 2011-07-18 14:01:13 UTC
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)?
Comment 9 Denis Anisimov 2011-07-18 14:13:59 UTC
(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.
Comment 10 Tomas Zezula 2011-07-18 14:23:56 UTC
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)
Comment 11 Martin Fousek 2011-07-18 18:12:37 UTC
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.
Comment 12 Jaroslav Tulach 2011-07-20 07:30:06 UTC
"Profiling" snapshot showing who loads what violator:
http://netbeans.org/bugzilla/attachment.cgi?id=109525
Comment 13 Jaroslav Tulach 2011-07-22 07:21:29 UTC
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.
Comment 14 Tomas Zezula 2011-07-22 07:30:54 UTC
Yes, it should be something like this. The AP will encode the resources and mimeTypes into FO attributes.
Comment 15 Jaroslav Tulach 2011-07-22 08:40:33 UTC
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.
Comment 16 Marek Fukala 2011-10-11 15:24:15 UTC
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.
Comment 17 Tomas Zezula 2011-10-11 16:08:36 UTC
I will take a care of it.
Comment 18 Tomas Zezula 2011-11-04 11:45:21 UTC
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.
Comment 19 Tomas Zezula 2011-11-10 11:14:57 UTC
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.
Comment 20 Marek Fukala 2011-11-14 12:10:31 UTC
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.
Comment 21 Denis Anisimov 2011-11-15 08:00:43 UTC
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.
Comment 22 Tomas Zezula 2011-11-15 08:36:19 UTC
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.
Comment 23 Petr Jiricka 2011-11-16 10:10:16 UTC
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.
Comment 24 Denis Anisimov 2011-11-16 10:56:13 UTC
(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.
Comment 25 Denis Anisimov 2011-11-16 11:41:41 UTC
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.
Comment 26 Petr Jiricka 2013-07-24 08:34:15 UTC
Is this issue still valid? If so, can we make any further improvements in this area? Or is this issue WONTFIX?
Comment 27 Martin Janicek 2014-01-23 13:06:10 UTC
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.