Plug-in "org.springframework.ide.eclipse.boot.wizard" was unable to instantiate class "org.springframework.ide.eclipse.boot.wizard.guides.GSImportWizard". java.lang.reflect.InvocationTargetException

[indrajeet4192]

Hi ,
I am not able to import spring Getting Started Project in STS4. I am getting following exception while importing .

The selected wizard could not be started. Plug-in "org.springframework.ide.eclipse.boot.wizard" was unable to instantiate class "org.springframework.ide.eclipse.boot.wizard.guides.GSImportWizard". java.lang.reflect.InvocationTargetException

Note :- I am facing above exception only after installing Jboss Server plugin. Otherwise it is working fine for me .

[martinlippert]

Which version of STS4 do you use? And where do you install the JBoss Tools from? Would like to reproduce the issue locally... :-)

[indrajeet4192]

Hi @martinlippert ,

• See below details for STS4 version .

Spring Tool Suite 4

Version: 4.1.1.RELEASE
Build Id: 201901241133

Copyright (c) 2007 - 2019 Pivotal, Inc.
All rights reserved. Visit http://spring.io/tools4

• To install the JBoss Server Tool,
  1. Go to Preference , search for Server.
  2. Click on Runtime Environments , available in drop-down of Server.
  3. Click on 'Add' button on right side and select Red Hat Jboss Middleware.
  4. Select JBoss AS, WildFly EAP and Server Tools.

It will install server tool for Jboss and WildFly.

[martinlippert]

Great, thanks for the details, I can reproduce the issue. Will investigate... :-)

[martinlippert]

Ok, so the reason for this is:

The import wizard bundle tries to create a client for javax.ws.rs via ClientBuilder.create(). This results in the javax.ws.rs ClientBuilder implementation to lookup the configured client builder and load that class via Class.forName....

This triggers the TCCL (Thread Context Class Loader) to load that class, which is the Jersey Glassfish implementation in our case. So far, so good.

BUT: Once you installed the JBoss Tools, the TCCL finds that class in a bundle called oracle.eclipse.tools.rest.lib and loads it from there. This results in an underlying LinkageError, because the ClientBuilder type is also contained in that oracle.eclipse.tools.rest.lib bundle. That means that the loaded Jersey implementation is bound to the ClientBuilder from the oracle.eclipse.tools.rest.lib bundle, not from the javax.ws.rs bundle.

I will try to implement a workaround for this by setting the TCCL to a specific one when we create the ClientBuilder.

[martinlippert]

Looks like my idea for the workaround doesn't solve the issue yet. The fundamental problem here, from my perspective, is that the oracle bundle exports various packages (among them javax.ws.rs.client as well as the jersey bundles), but does not define package-use restrictions among them. That causes our bundle, for example, to get wired to the javax.ws.rs bundle for the javax.ws.rs.client package, but to the oracle bundle for the Jersey bundles, which causes the LinkageError down the road.

I am not completely sure how to solve this, since the oracle bundle also seems to fully replace the individual jersey bundles that we usually use and package with STS. Will try a few other things, lets see if we can workaround this somehow.

[martinlippert]

I think I found a solution via setting a version constraint on the jersey package import (in addition to the TCCL setting). Need to verify that this works in the setting of
spring-attic/spring-ide#211.

If you want to give it a try, it would be great, too. Please feel free to grab the latest CI build from here: https://dist.springsource.com/snapshot/STS4/nightly-distributions.html and give it a try.