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 205019 - AssertionFailedException: The application has not been initialized - need for default startlevel
Summary: AssertionFailedException: The application has not been initialized - need for...
Status: VERIFIED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Netigso (show other bugs)
Version: 7.1
Hardware: All All
: P1 normal (vote)
Assignee: Jaroslav Tulach
URL:
Keywords: API_REVIEW_FAST
: 205747 205916 206192 206211 255691 (view as bug list)
Depends on: 205653
Blocks: 206347
  Show dependency tree
 
Reported: 2011-11-11 22:07 UTC by javydreamercsw
Modified: 2015-10-30 14:24 UTC (History)
10 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 182835


Attachments
stacktrace (2.69 KB, text/plain)
2011-11-11 22:07 UTC, javydreamercsw
Details
Hotfix, but the value "4" should be pluggable somehow (833 bytes, patch)
2011-11-23 07:43 UTC, Jaroslav Tulach
Details | Diff
Branding token to specify default bundle start level (12.04 KB, patch)
2011-11-23 08:49 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description javydreamercsw 2011-11-11 22:07:10 UTC
Build: NetBeans IDE Dev (Build 201111110600)
VM: Java HotSpot(TM) Client VM, 21.1-b02, Java(TM) SE Runtime Environment, 1.7.0_01-b08
OS: Windows 7

User Comments:
javydreamercsw: During start up (restarting after plugin installation)




Stacktrace: 
org.eclipse.core.runtime.AssertionFailedException: assertion failed: The application has not been initialized.
   at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110)
   at org.eclipse.core.internal.runtime.InternalPlatform.assertInitialized(InternalPlatform.java:138)
   at org.eclipse.core.internal.runtime.InternalPlatform.getStateLocation(InternalPlatform.java:605)
   at org.eclipse.core.runtime.Plugin.getStateLocation(Plugin.java:312)
   at com.atlassian.connector.eclipse.internal.jira.core.JiraCorePlugin.start(JiraCorePlugin.java:72)
   at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:783)
Comment 1 javydreamercsw 2011-11-11 22:07:12 UTC
Created attachment 113137 [details]
stacktrace
Comment 2 Tomas Stupka 2011-11-14 10:00:47 UTC
was able to reproduce with NetBeans IDE Dev (Build 20111114-95ee7eead146) (#95ee7eead146)
- just download the jira plugin from UC and since that moment the exception is thrown on each nb start
- the plugin itself seems to work fine

jarda - any chance this has something to do with the fix in issue #203790
Comment 3 Tomas Danek 2011-11-21 10:06:24 UTC
p2 -> really visible. If this is not pointing to serious problem, I guess this gets "fixed" at least by turning off AE in FCS, right?
Comment 4 Jaroslav Tulach 2011-11-21 11:42:23 UTC
Yes, it is very likely related to bug 204513. Since then all OSGi bundles in NetBeans have a startup level (by default 4). The level is specified inside of config/Modules/*.xml file. Probably the JIRA plugin has not been rebuild since then and has no startlevel specification (defaults to 1). If so, then the JIRA bundle gets activated sooner than rest of Eclipse runtime.

Just rebuild JIRA, verify startlevel is there and if so, increase the spec version.

Btw. for a rant about OSGi startlevels see: http://wiki.apidesign.org/wiki/OSGi
Comment 5 Tomas Stupka 2011-11-21 13:05:34 UTC
> Just rebuild JIRA, verify startlevel is there and if so, increase the spec
> version.
osgi bundles are on the UC like jar files. autoupdate has to take care of that
Comment 6 Antonin Nebuzelsky 2011-11-22 12:11:53 UTC
Is it clear who will be fixing this?
Comment 7 Jiri Rechtacek 2011-11-22 12:16:22 UTC
(In reply to comment #6)
> Is it clear who will be fixing this?

Jardo, Tomas told me you have promised to fix it. Is it true?
Comment 8 Jaroslav Tulach 2011-11-23 06:24:49 UTC
I need to find out the code that generates config/Modules/*.xml file for downloaded bundles and modify it to include 

<startlevel>4</startlevel>

to be aligned with changes made while fixing bug 203790.
Comment 9 Jaroslav Tulach 2011-11-23 07:43:35 UTC
Created attachment 113444 [details]
Hotfix, but the value "4" should be pluggable somehow
Comment 10 Jaroslav Tulach 2011-11-23 08:45:32 UTC
On a second thought, it may be better to fix this directly in module system.
Comment 11 Jaroslav Tulach 2011-11-23 08:49:11 UTC
Created attachment 113447 [details]
Branding token to specify default bundle start level

After this change we need to override the startlevel in projectized.xml no longer. Default level of "4" will be read during runtime from the branded bundle.

I'd like to integrate tomorrow.
Comment 12 Jesse Glick 2011-11-23 14:00:29 UTC
(In reply to comment #3)
> I guess this gets "fixed" at least by turning off AE in FCS, right?

I doubt it - the stack trace in comment #0 does not look like a regular Java assertion, so it may not be affected by -ea/-da.

(In reply to comment #4)
> for a rant about OSGi startlevels see: http://wiki.apidesign.org/wiki/OSGi

I think this is a bit off the mark. Seems like Eclipse is not really using OSGi as designed. Proper OSGi bundles are (acc. to spec) supposed to work regardless of what other bundles have or have not been started; that is why dynamic services exist, and why bundles are not started in topological order. In other words, we are working around misdesign in Eclipse, not OSGi per se. The problem presumably does not affect Eclipse and its RCP apps because they are not attempting to load code from an arbitrary compliant OSGi container, and so can make assumptions about runtime behavior not guaranteed by the spec.

As for the diff in comment #11, it seems fine to me; basically the same as JG02 in bug #203790 comment #10.
Comment 13 Jaroslav Tulach 2011-11-23 19:18:41 UTC
Given there is overall agreement I've integrated the change as ergonomics#dac9621ee0fb
Comment 14 Tomas Danek 2011-11-24 10:35:13 UTC
verified. IDE is started after installing JIRA without exception.
Comment 15 Jaroslav Tulach 2011-11-24 16:23:42 UTC
The fix has not yet propagated from ergonomics to main-silver. Delaying integration.
Comment 16 Jaroslav Tulach 2011-11-28 13:59:13 UTC
changeset:   634e004b4241                                                                                                                                                                 
branch:      release71                                                                                                                                                                           
tag:         tip                                                                                                                                                                                 
parent:      20f16ed85a54                                                                                                                                                                 
parent:      fa77bc381037                                                                                                                                                                 
user:        Jaroslav Tulach <jtulach@netbeans.org>                                                                                                                                              
date:        Mon Nov 28 14:58:16 2011 +0100                                                                                                                                                      
summary:     Merge of #205019 to release71 branch
Comment 17 Quality Engineering 2011-11-28 20:12:25 UTC
Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/dac9621ee0fb
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #205019: Default bundle level can be assigned during runtime
Comment 18 Quality Engineering 2011-11-29 08:45:55 UTC
Integrated into 'releases'
Changeset: http://hg.netbeans.org/releases/rev/dac9621ee0fb
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #205019: Default bundle level can be assigned during runtime
Comment 19 Tomas Stupka 2011-12-01 13:56:28 UTC
*** Bug 205747 has been marked as a duplicate of this bug. ***
Comment 20 Tomas Danek 2011-12-01 15:48:50 UTC
verified in rc2
Comment 21 Tomas Stupka 2011-12-05 09:19:57 UTC
*** Bug 205916 has been marked as a duplicate of this bug. ***
Comment 22 Tomas Stupka 2011-12-09 13:39:35 UTC
*** Bug 206192 has been marked as a duplicate of this bug. ***
Comment 23 Tomas Danek 2011-12-12 15:17:43 UTC
*** Bug 206211 has been marked as a duplicate of this bug. ***
Comment 24 Tomas Hurka 2015-10-30 14:24:53 UTC
*** Bug 255691 has been marked as a duplicate of this bug. ***