|Re: [virgo-dev] Rationale for the Virgo launcher|
As part of our attempts to address the P2 provisioning, Katya Todorova (our P2 expert) started a discussion on the Equinox/P2 mailing list .
Currently we have several ideas:
1) Custom (Virgo specific) bundles
2) Standard way to provision rfc152
3) Start with 1 and replace the implementation when 2 is finished
The discussion in P2 mailing list is targeted at approach #2.
The updated list with known issues/to-do items:
1. Merge branch bug324991-eclipse-structure with the latest changes in master
2. Major P2 issues
Â Offline/standalone provisioning of bundles in user region
o Idea 1: Bundles.info and P2 profile has to contain extended information
o Idea 2: Use different configuration files (and bundles) for the different regions
Â Online/runtime handling of bundles in user and kernel region
3. Minor P2 issues
Â P2 seems to always create configuration and plugins folders
Â file names are changed since the version is separated from the bundle name with "_", while original file names have "-"
Â adapt the build to handle different file names or use P2 to install and then ZIP the result
4. Run the existing Virgo tests
5. Check Spring update as usability test
6. Equinox logs are produced in config and not in work
7. NPEs for all services on shutdown:
8. Launcher is not used but still needed because of usage of ArgumentParser class
Â add util package for merging URIs
Â move ArgumentParser in util project
9. bin/shutdown.bat does not work
I hope we will have some idea how to resolve the major P2 issue until the end of the day so I can continue with the prototype work.
Yesterday I managed to move the repository to the same folder as the rest of the JARs and we can now go for P2 publishing and installation of Virgo. You can find the prototype here:
However I also found that the parameters are passed to the user region, but of course they are also passed to the kernel region since âD is used. In this way the osgi.console is picked by the kernel region as itâs the first one in the startup order J I guess we should think of a way to bring back the launcher functionality to pass parameters to the user region.
The known problems/limitations for this prototype:
1. Equinox extension hook is working but on every startup in the log there is:
at java.security.AccessController.doPrivileged(Native Method)
at java.lang.Class.forName0(Native Method)
2. NPEs for all services on shutdown:
3. Passing parameters (system propertiesâ.) to the user region
4. Launcher is not used but still needed because of usage of ArgumentParser class
Ok. I'm glad that works. Thanks.
On 4 Jan 2011, at 13:53, Iliev, Hristo wrote:
The parameters work ok. The command:
startup.bat â-Dosgi.console=2401â (â=â is separator in windows)
provides the same functionality as before. I had to refactor a bit the dmk.bat script to put the system properties before equinox launcherâs âjar, but now everything is ok. Thanks for the hint J
I think we have to merge our prototypes anyway and me and Borislav will use only one branch. Iâm currently working with head, but we should also check if there are problems to merge all changes since weâve made several small changes so far.
I missed the most important piece! I should have said "the launch sequence *under Eclipse* is quite delicate". You should try running those tests as JUnit tests *under Eclipse*. Sorry.
On 31 Dec 2010, at 10:54, Glyn Normington wrote:
One other thing to check is that integration tests still run as the launch sequence is quite delicate. Try StandardKernelIntegrationTest for starters and then something more ambitious like NestedPlanIntegrationTests.
On 31 Dec 2010, at 08:29, Glyn Normington wrote:
That approach seems good except for the change to replace -F with -D which impacts externally visible function. For instance, it is currently possible to run with the Equinox console without having to change the configuration by invoking:
Is there a way to preserve this function, e.g. by enhancing the Equinox launcher? If not, we'll have to document the incompatibility carefully in 2.1->3.0 migration notes.
Please note also that we need to manage potential conflicts carefully. I presume you and Borislav are working on a branch or branches. I am still in the process of doing radical restructuring in and around the org.eclipse.virgo.kernel.osgi.region package on the branch bug330776-framework-hooks branch which are likely to conflict with your changes, especially relating to the user region, so you should take care to do the appropriate merging before merging into master to ensure that all tests continue to pass on master. I can advise on that when you are closer to completion, depending on whether my branch has merged into master by then.
On 30 Dec 2010, at 21:22, Hristo Iliev wrote:
I was not able to run the existing tests, since I had problems with running them on Windows :), but it seems that Virgo is starting ok and the web console is working. What I've done so far was to:
I think that the first 3 point in the list above correspond almost 1:1 to the launcher's rationale you described:
While the first problem can be solved by simply refactoring the code to allow the use of the launcher as bundle, the second one is not that easy.
On 30 December 2010 11:56, Glyn Normington <gnormington@xxxxxxxxxx> wrote:
At the recent Virgo F2F we discussed the possibility of replacing the Virgo launcher with the standard Equinox launcher.