Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [virgo-dev] Rationale for the Virgo launcher

Hi,

 

Please try http://hsiliev.dnsalias.com/virgo/dmk.sh

 

I adapted the script in the clean part and made some changes. It’s working on my Gentoo, but let’s see how it behaves on Mac J

 

Regards,

Hristo Iliev

 

From: virgo-dev-bounces@xxxxxxxxxxx [mailto:virgo-dev-bounces@xxxxxxxxxxx] On Behalf Of Glyn Normington
Sent: Wednesday, January 05, 2011 11:33 AM
To: Virgo Project
Subject: Re: [virgo-dev] Rationale for the Virgo launcher

 

I didn't have much luck on Mac OS X:

 

bin/startup.sh -clean

Usage: java [-options] class [args...]

           (to execute a class)

   or  java [-options] -jar jarfile [args...]

           (to execute a jar file)

 

where options include:

    -d32          use a 32-bit data model if available

    -d64          use a 64-bit data model if available (implies -server, only for x86_64)

    -client           to select the "client" VM

    -server          to select the "server" VM

    -jvm  is a synonym for the "client" VM  [deprecated]

    -hotspot        is a synonym for the "client" VM  [deprecated]

                  The default VM is client.

                  

    -cp <class search path of directories and zip/jar files>

    -classpath <class search path of directories and zip/jar files>

                  A : separated list of directories, JAR archives,

                  and ZIP archives to search for class files.

    -D<name>=<value>

                  set a system property

    -verbose[:class|gc|jni]

                  enable verbose output

    -version      print product version and exit

    -version:<value>

                  require the specified version to run

    -showversion  print product version and continue

    -jre-restrict-search | -jre-no-restrict-search

                  include/exclude user private JREs in the version search

    -? -help      print this help message

    -X            print help on non-standard options

    -ea[:<packagename>...|:<classname>]

    -enableassertions[:<packagename>...|:<classname>]

                  enable assertions

    -da[:<packagename>...|:<classname>]

    -disableassertions[:<packagename>...|:<classname>]

                  disable assertions

    -esa | -enablesystemassertions

                  enable system assertions

    -dsa | -disablesystemassertions

                  disable system assertions

    -agentlib:<libname>[=<options>]

                  load native agent library <libname>, e.g. -agentlib:hprof

                    see also, -agentlib:jdwp=help and -agentlib:hprof=help

    -agentpath:<pathname>[=<options>]

                  load native agent library by full pathname

    -javaagent:<jarpath>[=<options>]

                  load Java programming language agent, see java.lang.instrument

    -splash:<imagepath>

                  show splash screen with specified image

/Users/glynnormington/downloads/v/bin/dmk.sh: line 174: -Dosgi.framework.activeThreadType=normal: command not found

/Users/glynnormington/downloads/v/bin/dmk.sh: line 176: -Dorg.eclipse.virgo.kernel.config=/Users/glynnormington/downloads/v/config: No such file or directory

/Users/glynnormington/downloads/v/bin/dmk.sh: line 180: -jar: command not found

/Users/glynnormington/downloads/v/bin/dmk.sh: line 181: -install: command not found

/Users/glynnormington/downloads/v/bin/dmk.sh: line 182: -data: command not found

/Users/glynnormington/downloads/v/bin/dmk.sh: line 183: -configuration: command not found

/Users/glynnormington/downloads/v/bin/dmk.sh: line 184: -noExit: command not found

 

Regards,
Glyn

 

On 5 Jan 2011, at 09:00, Iliev, Hristo wrote:



Hi,

 

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:

java.lang.ClassNotFoundException: org.eclipse.virgo.osgi.extensions.equinox.hooks.ExtensionsHookConfigurator

                at java.net.URLClassLoader$1.run(URLClassLoader.java:202)

                at java.security.AccessController.doPrivileged(Native Method)

                at java.net.URLClassLoader.findClass(URLClassLoader.java:190)

                at java.lang.ClassLoader.loadClass(ClassLoader.java:307)

                at java.lang.ClassLoader.loadClass(ClassLoader.java:248)

                at java.lang.Class.forName0(Native Method)

                at java.lang.Class.forName(Class.java:169)

                at org.eclipse.osgi.baseadaptor.HookRegistry.loadConfigurators(HookRegistry.java:176)

2.       NPEs for all services on shutdown:

java.lang.NullPointerException

                at java.util.AbstractCollection.removeAll(AbstractCollection.java:336)

                at org.eclipse.virgo.kernel.shell.internal.CommandRegistry.serviceUnregistering(CommandRegistry.java:97)

                at org.eclipse.virgo.kernel.shell.internal.CommandRegistry.access$1(CommandRegistry.java:94)

                at org.eclipse.virgo.kernel.shell.internal.CommandRegistry$CommandRegistryServiceListener.serviceChanged(CommandRegistry.java:110)

                at org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:104)

3.       Passing parameters (system properties….) to the user region

4.       Launcher is not used but still needed because of usage of ArgumentParser class

 

Regards,

Hristo Iliev

 

From: virgo-dev-bounces@xxxxxxxxxxx [mailto:virgo-dev-bounces@xxxxxxxxxxx] On Behalf Of Glyn Normington
Sent: Tuesday, January 04, 2011 6:06 PM
To: Virgo Project
Subject: Re: [virgo-dev] Rationale for the Virgo launcher

 

Ok. I'm glad that works. Thanks.

 

Regards,
Glyn

 

On 4 Jan 2011, at 13:53, Iliev, Hristo wrote:




Hi,

 

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.

 

Regards,

Hristo Iliev

 

From: virgo-dev-bounces@xxxxxxxxxxx [mailto:virgo-dev-bounces@xxxxxxxxxxx] On Behalf Of Glyn Normington
Sent: Friday, December 31, 2010 1:10 PM
To: Virgo Project
Subject: Re: [virgo-dev] Rationale for the Virgo launcher

 

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.

 

Regards,
Glyn

 

On 31 Dec 2010, at 10:54, Glyn Normington wrote:





Hi Hristo

 

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.

 

Regards,
Glyn

 

On 31 Dec 2010, at 08:29, Glyn Normington wrote:





Hi Hristo

 

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:

 

bin/startup.sh -Fosgi.console=2401

 

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.

 

Regards,
Glyn

 

On 30 Dec 2010, at 21:22, Hristo Iliev wrote:





Hi Glyn,

We are indeed working on a prototype that replaces Virgo's launcher with the one from Equinox. The idea for having such prototype is to allow P2 to install Virgo, and to allow easy setup of target platforms containing Virgo.

This week I was able to create a version that has:

  • Equinox launcher
  • P2's SimpleConfigurator (lifecycle / bundle list)
  • merged lib + lib/kernel + repository into one folder

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:

  1. change the imports of the Virgo's framework hooks [1]
  2. change the dmk shell script (no classpath, replaced -F with -D)
  3. provide a way to configure the directory structure for the user region (property in the user region configuration + changes in launcher's parser)
  4. change the kernel.osgi bundle to use the launcher as a bundle
  5. adapt the build (added parametrized config.ini and bundles.info, new version variables)

I think that the first 3 point in the list above correspond almost 1:1 to the launcher's rationale you described:
     T1. The hooks now can be installed as a bundle
     T2. Only system properties are used currently (in dmk script) as far as I can tell
     T3. The directory structure can be configured

As you can see we are trying to keep the existing functionality and to change as little as possible. Perhaps T3 would not be a big problem, but that remains to be seen.

As additional problems I can point the following:

  • launcher and hooks are used directly (classpath) from the kernel bundles and not by importing the packages
  • bundles.info contains bundle list with paths that once populated is hard to be changed (connected with T3)

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. 

Btw Borislav is working in parallel on another prototype that will allow flexible startup order and I hope we'll be able to present both (or the merged result) in the middle of January. 

If you think that something can be done differently or is already done, please do not hesitate to write back. We'll be happy if you can save us some work :)

Regards,
Hristo Iliev

[1] bug 333159




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.

For the record, the original rationale for creating a Virgo launcher was threefold:

1. to install (just) the required framework hooks
2. to allow command line parameters to be passed in
3. to allow flexibility in the naming of certain directories

Some of these may now be addressed by the Equinox launcher since it has probably moved on, but they should be useful considerations. At the very least, we need to ensure that any replacement launcher passes these tests:

T1. The same set of framework hooks is installed as in Virgo 2.1.0.
T2. All the startup script options in Virgo 2.1.0 are supported.
T3. All the directories can be named as in Virgo 2.1.0.

Clearly these tests may be rendered invalid by new features (e.g. restructuring the directory layout may invalidate T3), but for now they should be useful.

Regards,
Glyn

_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev


_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev

 

_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev

 

_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev

 

_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev

 

_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev

 


Back to the top