Community
Participate
Working Groups
Created attachment 286530 [details] Error log Hi, I'm trying to upgrade from 4.16 to 4.19 but my application does not start anymore with any 4.17+ version. My application is using 4.4 as target platform and I never had any problems up to 4.16. Attached error log. Please advise. Thank you
What version of org.eclipse.core.jobs is included in your target when launching? This seems like the root cause for the failure: Unresolved requirement: Require-Bundle: org.eclipse.core.jobs; bundle-version="[3.2.0,4.0.0)"; visibility:="reexport" That would indicate that the required version of org.eclipse.core.jobs is not available.
java.version=1.8.0_282 I suspect the issue is actually because you are not using Java 11. 4.17 requires Java 11. https://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_17.xml#target_environments
I'm launching 4.19 with Java 14. My application however runs with Java 8 and my application's target platform of the application is 4.4 (using eclipse-platform-SDK-4.4)
(In reply to Markus S from comment #3) > I'm launching 4.19 with Java 14. > > My application however runs with Java 8 and my application's target platform > of the application is 4.4 (using eclipse-platform-SDK-4.4) Need some clarification, you are launching your application (which is based on the 4.4 release). But you are launching that from a development environment which is 4.17+. If that is the case I think this bug likely belongs to PDE where the launchers are for launching an RCP application from the eclipse development envorionment/workspace.
> Need some clarification, you are launching your application (which is based on the 4.4 release). But you are launching that from a development environment which is 4.17+. yes, exactly. sorry for not being precise enough in my initial description.
Generally the issues as seen in error log happens when there is mismatch of plugins. ( some plugins belong to old version and some to new version.) Does it happen on a release build of eclipse. If yes which one and what are the steps?
I'm using the 4.19 release build from Eclipse download page. I also tried 4.17 and 4.18 and it's the exact same issue. We have a RCP application based on Eclipse 4.4, so in order to launch our application from Eclipse IDE, we define a target platform that contains the Eclipse 4.4 SDK and our corresponding plugins. The exact same configuration works with every Eclipse version up until 4.16. Starting with 4.17 we see that exact same error when trying to launch the application.
If there is anything helpful we can provide (logging, instrumentation, ...) please let me know, thank you.
(In reply to Markus S from comment #8) > If there is anything helpful we can provide (logging, instrumentation, ...) > please let me know, thank you. Can you provide steps with sample rcp application that fails.
To put things into perspective: our RCP application consists of over 750 bundles and our target platform defintion contains over 1300 plugins.
I have uploaded a sample RCP application which reprocues the error to my Google drive: https://drive.google.com/drive/folders/1VF5EsTkjv1LOXQ0dAA33Xv2n79RdPYwJ?usp=sharing Project structure: - application -- features_test (feature) -- launches_test (launch config) -- plugins_test (plugins) -- targets_test (target platform definition) - runtime -- target_test (target platform) Steps: - import all four projects from "application" folder - go to "Preferences -> Plug-in Development -> Target Platform" and change to "E4 development version. Win64 EN,DE" defintion - launch the "Server (Sql-Server, win64)" launch configuration Feel free to change the runtime JRE in the launch configuration (we use Azul JDK8) to any other Java 8 runtime. The target platform contains the Eclipse 4.4 SDK which is why the runtime.zip filesize is 264MB
Since you are stuck on 4.4, why don't you keep working with 4.16? I bet Vikas is right in comment #6. Export your run configuration and examine that.
I don't want to be stuck with the bugs and issues that 4.16 has. > Export your run configuration and examine that. Examine what exactly?
Is there any update?
Kindly asking for update.
Julian, do you have any idea on this one?
The launch configuration is based on the test.feature.server feature which seems to contain all required plugins. However the launch configuration is configured with "use features from workspace if available" = false. --> when launching, the feature will not be found in the target platform and skipped completely. Therefore only the application requirements of test.platform.server will be available (which would include the missing requirements). However the launch configuration is misconfigured again to use the test.configuration.server/conf/config.ini instead of letting PDE generate one. This config.ini already includes the following osgi.bundles entry: osgi.bundles=org.eclipse.equinox.util@:start, org.eclipse.equinox.ds@:start, org.eclipse.equinox.event@:start, org.eclipse.equinox.common@:start, org.eclipse.equinox.common@:start, org.eclipse.osgi.services@:start, org.eclipse.update.configurator@:start, org.eclipse.core.runtime@:start, org.eclipse.equinox.http.registry@:start, com.sun.jersey.jersey-server@:start, com.sun.jersey.jersey-core@:start (which is missing the listed plugins) Because that entry already exists, PDE will not generate one based on the application requirements and the application is launched with missing plugins. To summarize: the launch configuration did work in a previous eclipse version because it's based on org.eclipse.update.configurator for which the support was removed in Bug 527378. To make it work in the current eclipse version, the config.ini template needs to updated (or the launch configuration should select "generate a config.ini file with default content"). Closing as INVALID.
We can confirm that if we either remove the osgi.bundles parameter from the config.ini or we let PDE generate a config.ini with default content, the application tries to startup. However startup fails due to this error: > com.sun.jersey.api.container.ContainerException: No WebApplication provider is present > at com.sun.jersey.spi.container.WebApplicationFactory.createWebApplication(WebApplicationFactory.java:69) > at com.sun.jersey.spi.container.servlet.ServletContainer.create(ServletContainer.java:391) > at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.create(ServletContainer.java:306) > at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:599) > at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:208) > at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:373) > at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:556) > at javax.servlet.GenericServlet.init(GenericServlet.java:244) > at org.eclipse.equinox.http.servlet.internal.ServletRegistration.init(ServletRegistration.java:49) > at org.eclipse.equinox.http.servlet.internal.ProxyServlet.registerServlet(ProxyServlet.java:184) > at org.eclipse.equinox.http.servlet.internal.HttpServiceImpl.registerServlet(HttpServiceImpl.java:66) Which is why the osgi.bundles parameter was added to config.ini in the first place. What is the proper solution for this problem?
(In reply to Markus S from comment #18) > We can confirm that if we either remove the osgi.bundles parameter from the > config.ini or we let PDE generate a config.ini with default content, the > application tries to startup. > > However startup fails due to this error: > > com.sun.jersey.api.container.ContainerException: No WebApplication provider is present Did you try to ask google? It looks like a common issue.
Yes, Google says I need to start jersey plugins before our application plugins. Which is what we did by adding the osgi.bundles property to the config.ini But since guys changed that with 4.17, the answer from Google feels kind of outdated, what do you think?
>To make it work in the current eclipse version, the config.ini template needs to >updated (or the launch configuration should select "generate a config.ini file with >default content"). Does this work for you?
No, as written in my last comment the application fails to load with the generated config.ini
(In reply to Markus S from comment #20) > Yes, Google says I need to start jersey plugins before our application > plugins. Which is what we did by adding the osgi.bundles property to the > config.ini I guess that now you have to do that in your run configuration.
If you could please point me into the direction of where and how?
(In reply to Markus S from comment #24) > If you could please point me into the direction of where and how? https://www.vogella.com/tutorials/EclipsePlugin/article.html
I'm sorry, this is not helpful at all. We also have to consider the deployed appliaction which does not have a run configuration
(In reply to Markus S from comment #26) > I'm sorry, this is not helpful at all. We also have to consider the deployed > appliaction which does not have a run configuration Please check the documentation [1] and/or other tutorials, this is a bugtracker not a help desk. I suggest you define a proper product and create a launch configuration from there rather than patching config files. [1] https://help.eclipse.org/2021-06/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftask-using_batch_compiler.htm
> https://help.eclipse.org/2021-06/index.jsp?topic=%2Forg.eclipse.jdt.doc. > user%2Ftasks%2Ftask-using_batch_compiler.htm Wrong link, sorry: https://help.eclipse.org/2021-06/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Fguide%2Ftools%2Flaunchers%2Feclipse_application_launcher.htm&cp%3D4_3_3_0
I'm not asking for helpdesk, I'm asking how to resolve the issue you guys caused with the functionality you have broken without providing a replacement, which is exactly what the bugtracker is for. But apparently you have no idea yourselves...
(In reply to Markus S from comment #29) > I'm not asking for helpdesk, I'm asking how to resolve the issue you guys > caused with the functionality you have broken without providing a > replacement, which is exactly what the bugtracker is for. But apparently you > have no idea yourselves... Markus, Julian has identified the issue for you in comment 17. So really it was and is a problem in your configuration. The fact that your 4.4 configuration was still working in 4.16 is a coincidence. It was not something we "broke" and now have to fix. Julian suggests creating a proper .product file where you specify all the required features. Then you can create a launch configuration from there. Alternatively, you can start with the run configuration and then create a product from that. If you don't know what a product configuration is or how this relates to a run configuration then you either have to study by reading some of the many articles that have been written about this, or you have to hire a consultant. I understand your frustration but we cannot help every individual personally.
