Community
Participate
Working Groups
I20080206-1800 1. Create a Hello World RCP with the plugin project wizard 2. Make sure that you use 1.5 execution environment for the RCP 3. create a product configuration for the RCP 4. Export the product to a directory 5. Either run the product on a platform with 1.4 vm as default vm or with the -vm parameter pointing to a 1.4 vm Is: java.lang.RuntimeException: No application id has been found. at org.eclipse.equinox.internal.app.EclipseAppContainer.startDefaultApp(EclipseAppContainer.java:234) at org.eclipse.equinox.internal.app.EclipseAppContainer.start(EclipseAppContainer.java:96) at org.eclipse.equinox.internal.app.Activator.addingService(Activator.java:127) at org.osgi.util.tracker.ServiceTracker$Tracked.trackAdding(ServiceTracker.java:1064) at org.osgi.util.tracker.ServiceTracker$Tracked.trackInitialServices(ServiceTracker.java:926) at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:330) at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:274) at org.eclipse.equinox.internal.app.Activator.start(Activator.java:56) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:265) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:419) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:193) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:354) at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass(SingleSourcePackage.java:33) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:427) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:383) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:371) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:87) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) at org.eclipse.core.internal.runtime.PlatformActivator.startAppContainer(PlatformActivator.java:47) at org.eclipse.core.internal.runtime.PlatformActivator.start(PlatformActivator.java:32) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:355) at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1073) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:632) at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:506) at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:280) at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:466) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:209) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:319) !ENTRY org.eclipse.osgi 2 0 2008-02-12 11:12:53.754 !MESSAGE The following is a complete list of bundles which are not resolved, see the prior log entry for the root cause if it exists: !SUBENTRY 1 org.eclipse.osgi 2 0 2008-02-12 11:12:53.770 !MESSAGE Bundle initial@reference:file:plugins/TestRCP_1.0.0.jar/ [3] was not resolved. !SUBENTRY 2 TestRCP 2 0 2008-02-12 11:12:53.770 !MESSAGE Missing Constraint: Bundle-RequiredExecutionEnvironment: J2SE-1.5 Should: At least throw a useful exception, such that one can understand that this is a problem with the vm and not with the product. Better: show a dialog to inform the user that she needs a more recent vm to run this product. Even Better: show a dialog to inform the user and to allow to browse to another vm if available. This is bad for everyone trying to deploy RCPs, how can a normal user ever understand this exception? Sorry, I'm not sure if Platform/Runtime is the correct component for this...
(In reply to comment #0) > !ENTRY org.eclipse.osgi 2 0 2008-02-12 11:12:53.754 > !MESSAGE The following is a complete list of bundles which are not resolved, > see the prior log entry for the root cause if it exists: > !SUBENTRY 1 org.eclipse.osgi 2 0 2008-02-12 11:12:53.770 > !MESSAGE Bundle initial@reference:file:plugins/TestRCP_1.0.0.jar/ [3] was not > resolved. > !SUBENTRY 2 TestRCP 2 0 2008-02-12 11:12:53.770 > !MESSAGE Missing Constraint: Bundle-RequiredExecutionEnvironment: J2SE-1.5 Well, this part offers some insight into the problems I suppose. I do agree that a user isn't necessarily going to know that TestRCP is the cause of why the application is failing to start.
Missing Constraint: Bundle-RequiredExecutionEnvironment: J2SE-1.5 That should mean something to you. Plus, your default VM was a J2SE-1.5 VM so you were targetting your application to run on 1.5. If this wasn't the case and you were developing against a 1.4 VM, you would see error messages telling you within the workbench that there's mismatches. I'm not sure what else the runtime could do for you here. Maybe Tom has thoughts...
(In reply to comment #2) > Missing Constraint: Bundle-RequiredExecutionEnvironment: J2SE-1.5 > > That should mean something to you. Plus, your default VM was a J2SE-1.5 VM so > you were targetting your application to run on 1.5. If this wasn't the case and > you were developing against a 1.4 VM, you would see error messages telling you > within the workbench that there's mismatches. I'm not the problem here, the problem is the user. Missing constraint for bundle does mean nothing to a 'normal' user. > I'm not sure what else the runtime could do for you here. Maybe Tom has > thoughts... see my comment#0
It is hard to throw any useful exception here. The container was told to run a particular application and was not able to find the id to run. The reason the application id was not found was because the application is contained in an unresolved bundle. But the application container does not know why the application was missing, it only know it is not able to find one. Perhaps the container could interrogate the framework and give some information on any unresolved bundles. But this would be a guess that will be wrong in cases where the application bundle simply is not installed at all. But then the argument can be made that if the container can not figure it out how is the common user!!! :(
(In reply to comment #4) > It is hard to throw any useful exception here. The container was told to run a > particular application and was not able to find the id to run. The reason the > application id was not found was because the application is contained in an > unresolved bundle. But the application container does not know why the > application was missing, it only know it is not able to find one. Yes, I understand that. But the information is there somewhere: 1. I specified a minimum execution env for the application bundle to be 1.5 2. I specified that the application is contained in that bundle Maybe the native launcher must check that the application bundle can be loaded? Then the launcher can abort right away with an error dialog. Much easier would be if I can specify the minimum execution environment in the product. Then the native launcher must just check that the default vm fulfills the minimum. If not then the launcher could even search for one that does. But I see that fixing this is not as trivial as I thought...
(In reply to comment #5) > Much easier would be if I can specify the minimum execution environment in the > product. Then the native launcher must just check that the default vm fulfills > the minimum. If not then the launcher could even search for one that does. If that is all you need then setting osgi.requiredJavaVersion=1.5 in the config.ini will do the trick. The check is done by the org.eclipse.equinox.launcher jar, not the native launcher, but the results should be the same.
(In reply to comment #6) > If that is all you need then setting osgi.requiredJavaVersion=1.5 in the > config.ini will do the trick. The check is done by the > org.eclipse.equinox.launcher jar, not the native launcher, but the results > should be the same. Oh, wow, you rock Tom! This will show a dialog if the product is run with a 1.4 vm saying: 'Version 1.4 of the JVM is not suitable for this produce. Version: 1.5 or greater is required', which is exactly what I was looking for. So I will move this to PDE/UI, all what's missing then is UI in the product editor. And the generated config.ini should contain this setting if I created a RCP with the plugin wizard and did select 1.5 EE. Thanks Tom
*** This bug has been marked as a duplicate of bug 138543 ***
