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 179473 - Ability to run NB platform in pure OSGi container
Summary: Ability to run NB platform in pure OSGi container
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Module System (show other bugs)
Version: 6.x
Hardware: All All
: P1 normal (vote)
Assignee: Jesse Glick
URL: http://wiki.netbeans.org/NetBeansInOSGi
Keywords:
Depends on: 180201 182507 184434 184436 200528 200529
Blocks: 162911
  Show dependency tree
 
Reported: 2010-01-13 15:17 UTC by Jesse Glick
Modified: 2011-07-29 18:29 UTC (History)
4 users (show)

See Also:
Issue Type: TASK
Exception Reporter:


Attachments
Current patch (55.26 KB, patch)
2010-01-28 16:07 UTC, Jesse Glick
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2010-01-13 15:17:19 UTC
Explore the possibility of loading NB modules, including at least the contents of the platform cluster as well as user-developed modules/bundles, in an OSGi container such as Felix. The container would handle all class loading and lifecycle management rather than the NB module system.
Comment 1 Jesse Glick 2010-01-14 17:54:31 UTC
Development: https://hg.netbeans.org/prototypes/rev/nb-in-osgi-179473
Comment 2 Jesse Glick 2010-01-28 16:04:54 UTC
I plan to merge what I have so far into the trunk tomorrow so there will be something in M1 that people can play with and give feedback on. See the wiki page for details. I will try to keep the last section updated as I fix open issues, and at some point these ought to be turned into blocking issues in BZ.
Comment 3 Jesse Glick 2010-01-28 16:07:34 UTC
Created attachment 93638 [details]
Current patch
Comment 4 Jesse Glick 2010-01-30 07:54:13 UTC
Initial implementation in trunk: core-main #2e8d6798bfc3
Comment 5 Jaroslav Tulach 2010-02-03 03:08:32 UTC
I can see there is just one general BundleActivator in core.netigso. This is good for future performance improvements and makes me happy.
Comment 6 Jesse Glick 2010-02-03 08:05:10 UTC
(In reply to comment #5)
> This is good for future performance improvements

It may be. For now it is barely more efficient than an activator per module. I will however investigate whether the framework listener can be used to _reliably_ activate all modules in one step, even if all NB-related bundles are installed after the initial startup set.

Using a single activator unfortunately introduced a problem (listed in the issues section) that if you accidentally neglect to include core.netigso in the module set, nothing happens. I need to figure out how to cause all modules (at least all with layers and/or installers and/or URL handlers) to require core.netigso to be loaded, without using Import-Package. Perhaps Require-Bundle can work even with no exported packages, I will check.
Comment 7 Jaroslav Tulach 2010-02-03 10:32:40 UTC
Re. improvements. At least there is a way to turn on all normal module and only later start core.netigso. Then the core.netigso can verify its caches and use them. Thus one can configure its container to start effectively.

But if you change the dependencies, so every bundle depends on core.netigso, the above will be impossible again... I don't know what to do about that.
Comment 8 Jesse Glick 2010-02-03 12:42:23 UTC
(In reply to comment #7)
> there is a way to turn on all normal module and only
> later start core.netigso.

Sure, if I can depend on bundles being activated at certain times then optimization is easy. For example, when running java felix.Main -b <bundledir>, I know what the sequence of events will be and could consolidate startup.

The problem is rather to ensure correct behavior for an arbitrary policy: bundles being activated in an unspecified order (as is permitted in the absence of a management agent using the Start Level service), during or after "framework start", some possibly much later than the rest. The intent is to support any deployment workflow without configuration.
Comment 9 Quality Engineering 2010-02-03 21:58:09 UTC
Integrated into 'main-golden', will be available in build *201002040200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/2e8d6798bfc3
User: Jesse Glick <jglick@netbeans.org>
Log: Issue #179473: ability to run NB modules in an OSGi container.
Comment 10 Jaroslav Tulach 2010-02-04 02:23:52 UTC
(In reply to comment #8)
a. Any order of activation steps needs to result in correct behavior.
b. There needs to be at least one order of activation steps that will result in fast and effective behavior.