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 102516 - Exception at IDE startup when installing JavaIDE+AppServer
Summary: Exception at IDE startup when installing JavaIDE+AppServer
Alias: None
Product: editor
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 6.x
Hardware: Sun All
: P3 blocker (vote)
Assignee: issues@editor
: 102642 105063 (view as bug list)
Depends on: 26338
  Show dependency tree
Reported: 2007-04-25 16:43 UTC by Mikhail Kondratyev
Modified: 2010-02-18 07:58 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Stack trace. (12.56 KB, text/plain)
2007-04-27 21:50 UTC, Jan Lahoda

Note You need to log in before you can comment on or make changes to this bug.
Description Mikhail Kondratyev 2007-04-25 16:43:39 UTC
Used build from 2007.04.25 for testing
Steps to reproduce:
 - download full install bundle
 - select only Base IDE + Java IDE + App Server to be installed
 - install selected components
 - run IDE
Exception will be thrown at IDE startup:
org.netbeans.modules.retouche.hints.GsfHintsProvider from
	at org.netbeans.ProxyClassLoader.loadClass(
	at java.lang.ClassLoader.loadClass(
	at org.openide.loaders.InstanceSupport.findClass(
	at org.openide.loaders.InstanceSupport.instanceClass(
Comment 1 ehucka 2007-04-26 12:43:44 UTC
Reassigned to java, I am not sure if it is the right module.

mikk, was the ide started after the exception? Why do you think it is P1?
Comment 2 Jiri Prox 2007-04-26 15:34:08 UTC
It looks like you have installed Ruby support in previous NB installation, but
it is not in the current installation now. Did you clear your userdir after
Comment 3 Mikhail Kondratyev 2007-04-27 20:47:48 UTC
Answering the questions:
 - Yes, the IDE was started after exception. I agree the selected components are
may be not very typical combination but cases when user experience with the IDE
starts from exception should not be allowed.

 - Regarding Ruby: You are probably right, I could leave the old user dir.

In case the old user dir is the reason for this exception I think we should
downgrade the priority for this bug
Comment 4 Mikhail Kondratyev 2007-04-27 20:49:33 UTC
Please evaluate and downgrade the priority if needed
Comment 5 Jan Lahoda 2007-04-27 21:49:05 UTC
P3 seems more appropriate for me. The problem is probably caused by reuse of the
userdir (org.netbeans.modules.gsf.LanguageRegistry creates an .instance file on
the system filesystem programatically, so it is created in the userdir, and if
the same userdir is used on a build without gsf, this problem occurs - I am able
to reproduce this problem this way). I am attaching full stack trace of the
exception. I think that the MimeLookup should not show this exception to the
user - it should either ignore the exception completely (ignore .instance files
which cannot he instantiated), or only log it. Please check for Lookups.forPath
Comment 6 Jan Lahoda 2007-04-27 21:50:56 UTC
Created attachment 41890 [details]
Stack trace.
Comment 7 Vitezslav Stejskal 2007-04-30 04:28:52 UTC
Well, we can (1) workaround this particular case in MimeLookup, but I think it's
a general problem. We should discourage people from using the same userdir for
different 'distributions' of Netbeans. Or (2) better we should organize our
settings in the way that uninstalling a pack (or cluster or whatever granularity
we want to use) would automatically disable all 'user customized' settings
related to that pack. Also (3) we should change the way how languages framework
'instanializes' a language (.nbs), so that it would not write files to a userdir
when in fact those files are not user customizations of any settings.

While the ideal solution would be (2) and (3), the practical one is (1) and at
least (3), if not (2). I think issue #26338 provides a suitable way for
implementing (3).

Comment 8 Jesse Glick 2007-04-30 20:34:08 UTC

#1 (the workaround part) should be unnecessary.

#1 (asking people to use different user dirs) is wrong.

#2 is wrong. Installer components are just a user convenience with no deep
meaning. People can always enable/disable/install/uninstall arbitrary individual

Sounds like someone is writing a .instance file to the userdir for no reason.
This is wrong - #3. Issue #26338 could perhaps help, but that is just a
workaround for lack of a proper SPI for registering languages.

BTW in the case of *.settings, we have a facility for automatically disabling
settings when the owning module is not enabled. See definition of <module> in
the DTD. This does not apply to *.instance or *.ser files.
Comment 9 Vitezslav Stejskal 2007-05-02 02:06:21 UTC
> Sounds like someone is writing a .instance file to the userdir for no reason.
> This is wrong - #3. 

The Schliemann framwork does I think, when they expand .nbs file. Normally
modules providing support for editing a type of files install various things in
the Editors/ folder and they do it by supplying XML layer, which gets
installed/uninstalled with the module. With Schliemann the modules only supply
.nbs file and the framework sort of dynamically does the other registration for
them. The way how this is done currently is by writing files to the Editors/
folder hierarchy (including .instance files of course).

I am not sure how this should be fixed. I understand your comments about my
points #1 (userdir) and #2 and I agree. I am not sure what the 'proper SPI for
registering languages' should be, but we are open to ideas.

I think I'll still do the fix/workaround in MimeLookup at least until we have a
better solution.
Comment 10 Vitezslav Stejskal 2007-05-02 02:07:14 UTC
*** Issue 102642 has been marked as a duplicate of this issue. ***
Comment 11 Torbjorn Norbye 2007-05-02 02:17:05 UTC
I'm doing it in the Ruby area too.

In my first implementation, I was relying on a patch supplied by Jarda which let me plug into the system 
file system dynamically. I registered some code which let me dynamically populate mime folders and 
such at startup, by inspecting other areas of the filesystem. (For example, the Ruby plugin could 
register its parser and scanner implementation under lets say "gsf", and then my code would go and 
populate all the various associated editor services (code completion, hyperlink handlers etc.) in other 
parts of the filesystem. 

However, this was a bit buggy (occasionally, the IDE would come up and none of my services would be 
registered - I'd need to restart). And more importantly, this wasn't in "stock NetBeans", so my plugins 
would only work with a hacked version of Netbeans.

When I discovered what Jan had done in Schliemann, I changed my code to do it his way, since it 
worked with stock NetBeans and seems to work reliably. However, it does have the unfortunate aspect 
that things which are really "var/cache"-oriented are stuck into "config/" settings.

Anyway -- I believe Yarda's patch has been modernized and integrated into NetBeans 6. I'm cc'ed on 
one of the issues, but I can't find it at the moment. So, there may be a better way for us to do this stuff 
now. I'm adding Yarda to this issue in case he wants to chime in.
Comment 12 Jesse Glick 2007-05-02 02:20:33 UTC
Issue #26338 is what you are thinking of.
Comment 13 Jan Jancura 2007-05-02 09:39:15 UTC
I think that this issue is not Schliemann (or Ruby impl.) specific. I saw it
even without Schliemann. If you customize something in NB (action?) and than
uninstall module...
Comment 14 Jesse Glick 2007-05-02 09:58:56 UTC
Yes, you can get CNFEs by customizing actions and then disabling the owning
module. However that seems a much less likely scenario than in this bug.
Comment 15 Jiri Prox 2007-05-30 09:53:27 UTC
*** Issue 105063 has been marked as a duplicate of this issue. ***
Comment 16 Jiri Prox 2008-04-11 00:43:19 UTC
moving opened issues from TM <= 6.1 to TM=Dev
Comment 17 Max Sauer 2008-11-13 13:03:29 UTC
Lets re-evaluate this issue after parsing api/gsf will be rewritten and used in trunk. 
Comment 18 Vitezslav Stejskal 2010-02-18 07:58:09 UTC
This should no longer be a problem. All CSL related registrations are now (6.9) automatically created in compile time by a special annotation processor. Prior that (6.7, 6.8) there was a special CslJar task, which used to do the same.