Develop Reference

eclipse: external CDI in EJB module: NoClassDefFoundError

My current project consisting of a war and ejb module, is using a jar (incorperated via maven). This jar contains a CDI component which, when I inject this in the war module it works as expected, but when I inject this in my ejb module I get a NoClassDefFoundError during startup from my WAS 8.5 in eclipse (full profile).
When I start the server first, add the inject later and republish it seems to work. Also when I use Liberty profile it works. Also on Z/os and IPAS it works as expected.
I think it might has something todo with classloading, but have no idea how to solve this properly.
Using Eclipse Neon, WAS 8.5.5.11 full profile , jee6
Project is using java 8 while the component is using java 6
This is the first part of the stacktrace:
[13-9-17 14:54:26:589 CEST] 0000003e InjectionProc W CWNEN0047W: Resource annotations on the fields of the BestelFacade class will be ignored. The annotations could not be obtained because of the exc
eption : Logger
at java.lang.Class.getDeclaredFieldsImpl(Native Method)
Thanks

I found a way to get the job done, but I'm not sure if this is a proper solution or just a workaround while masking the real problem.
When I take a look at the ear module assembly I see in the source column c:/ws/.../jar and in the deploy path lib/jar
when I change the source into /..ear/target/../jar it works

Try setting the <bundleDir>/</bundleDir>
This will place the external jar/ejb not in lib, but in the root.
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ear-plugin</artifactId>
<configuration>
...........
<defaultLibBundleDir>lib</defaultLibBundleDir>
<modules>
<jarModule>
<groupId>groupId</groupId>
<artifactId>artifactId</artifactId>
<bundleDir>/</bundleDir>
</jarModule>
</modules>
</configuration>
</plugin>

Eclipse Plug-in Test execution for JUnit4

I have a JUnit4 test suite and I want to execute it under the JUnit Plug-in Test run configuration.
It passes successfully when running through the JUnit Test configuration, but for plug-in conf it fails in different ways.
For example if I use JUnit4TestAdapter it fails with ClassCastException, and if I trying to run it only through the #RunWith annotation it wrotes "No methods found" error. For both implementations I use JUnit4 Test Runner setting inside run configuration.
I use
Eclipse Neon.1a Release (4.6.1)
Jdk 1.8
linking JUnit 4.1 lib to the plugin.
For first case it seems that Eclipse proceed to use the JUnit3 version when executing the suite.
Here it is:
#RunWith(Suite.class)
#SuiteClasses({ DndTest.class })
public class JSTestSuite {
public static Test suite() {
return new JUnit4TestAdapter(JSTestSuite.class);
}
}
And exception is:
java.lang.ClassCastException: junit.framework.JUnit4TestAdapter cannot be cast to junit.framework.Test
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.getTest(RemoteTestRunner.java:403)
While starting the test I have a strange log message in console:
!ENTRY org.eclipse.update.configurator 2017-05-04 17:58:57.279
!MESSAGE Could not install bundle ../../platform/eclipse/plugins/org.eclipse.jdt.junit4.runtime_1.1.600.v20160505-0715.jar No match is available for the required execution environment: J2SE-1.5
I see this lib is on the place, but I can't understand why it failing to be loaded. For JUnit3 Test Runner setting junit3 lib is loaded ok.
There are some bugs related to such issues (like this) but it is really hard to understand what can I do in this case.
For second case I just try to execute simple JUnit4 case without using the JUnit4TestAdapter, but it can't find any methods.
Reloading of eclipse and renaming of the methods didn't help.
What can I do in this case?

I found that there are couple of issues. First I consider one by one to solve the issue.
Issue#1: No match is available for the required execution environment: J2SE-1.5
Issue#2: java.lang.ClassCastException: junit.framework.JUnit4TestAdapter cannot be cast to
junit.framework.Test
Solution for Issue#1:
First solution:
Right-click on your project
Click Properties
Click the "Java Compiler" option on the left menu
Under JDK compliance section on the right, change it to "1.8"
Second solution:
If you use maven in your project, then you can change pom.xml file as below:
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
Resource Link: Maven "build path specifies execution environment J2SE-1.5", even though I changed it to 1.7
Solution for Issue#2:
JUnit runner has a dependency on JUnit 3.8. It won't be used but without it, the whole platform can't be initialized.
So you need 2 versions like the following
Check you have below plugins
org.eclipse.xtext.xbase.junit
org.junit (3.8.2)
org.junit (4.8.2)
How to check for JUnit?
In eclipse, please check in 2 sections.
Check your Project Properties->Java Build Path->Libraries (tab)
Check you Project's Run Configurations->JUnit->Classpath (tab)
How to fix?
To fix the error make sure you have org.junit 3.8 in the target platform!
All credit goes to A Paul.
Resource Link:
https://stackoverflow.com/a/21334162/2293534
Aaron Digulla has commented like below:
Despite the fact that org.eclipse.xtext.junit4 imports org.junit
4.5.0, org.eclipse.xtext.junit (note the missing "4" at the end) seems to have a dependency to JUnit 3.8. After adding the old, outdated
JUnit bundle, the plugin tests started.

Upgrading gwt from 2.1.1 to 2.8.0: ServiceConfigurationError: org.apache.juli.logging.Log: Provider org.eclipse.jetty.apache.jsp.JuliLog not a subtype

After upgrading gwt from version 2.1.1 to 2.8.0, I got the error message
2017-04-20 12:59:19.551:WARN:oejuc.AbstractLifeCycle:main: FAILED c.g.g.d.s.j.WebAppContextWithReload#341fbaf1{/,file:/C:/Users/xxx/.IntelliJIdea2017.1/system/gwt/xxx.97baa614/xxx.fdf824a8/run/www/,STARTING}{C:\Users\xxx\.IntelliJIdea2017.1\system\gwt\xxx.97baa614\xx.fdf824a8\run\www}: java.util.ServiceConfigurationError: org.apache.juli.logging.Log: Provider org.eclipse.jetty.apache.jsp.JuliLog not a subtype
java.util.ServiceConfigurationError: org.apache.juli.logging.Log: Provider org.eclipse.jetty.apache.jsp.JuliLog not a subtype
I found some other posts with similar messages, like this or this, but the situation seems to be different:
I do not use Maven or Ant, just pure IntelliJ, I have no reference to any Tomcat library, and I am not aware of any JSP in our application.
I found through debugging that first the class loader com.google.gwt.dev.shell.jetty.Jettylauncher$WebAppContextWithReload$WebAppClassLoaderExtension loads class org.eclipse.jetty.apache.jsp.JuliLog including interface org.apache.juli.logging.Log.
Then, later interface org.apache.juli.logging.Log is loaded by sun.misc.Launcher$AppClassLoader triggered indirectly by
org.eclipse.jetty.webapp.WebAppContext.startContext()
which calls method initialize of an
org.eclipse.jetty.jsp.JettyJspServlet
instance.
I have no idea why a JspServlet needs to be initialized at all, as no JSPs are used in the application, as far as I see, just a few Servlets. And it seems all the classes involved in this conflict are contained in the single jar gwt-dev.jar, so I see no possibility to influence any class loading behavior via class path settings.
Any idea how I could resolve this?

I also got this error upgrading from gwt from version 2.4 to 2.8.2.
Jake W's answer helped me.
To solve this, I ran a maven dependency tree on my project to figure out what was referencing jetty's apache-jsp.
To run the dependency tree, in Eclipse I created a new run configuration -> maven build -> with the goals "dependency:tree -Doutput=/dependency/file.txt". Once it's run, the console output will show where it saves the output. It should be the same location that you referenced with the -Doutput option.
Look for something like this in the output file:
- org.eclipse.jetty:apache-jsp:jar:9.2.14.v20151106:compile
And then look up in the tree to see where it's being pulled in from. In my case it came from this:
+- com.google.gwt:gwt-dev:jar:2.8.2:compile
+- net.sourceforge.htmlunit:htmlunit:jar:2.19:compile
\- org.eclipse.jetty:apache-jsp:jar:9.2.14.v20151106:compile
Once you know where it's coming from, (assuming you're using maven) you can add an exclusion in your pom.xml file for it:
</dependencies>
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-dev</artifactId>
<version>${gwt.version}</version>
<exclusions>
<exclusion>
<groupId>org.eclipse.jetty</groupId>
<artifactId>apache-jsp</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
This worked for me. Thanks :)

I saw this error when I recently upgraded to GWT 2.8.0. Please try to exclude jetty-apache-Jsp related dependencies from your project.
You may see other jetty related issues as well, so please also make sure you are using exactly the same jetty version as GWT 2.8.0 is using.
I'm on mobile at the moment, unable to add more details, but I hope that can be a useful direction to go. Please add your comments if you still see issues, I will then have a look and update the answer when I'm on my laptop.

I have just ran into this exception after adding gwt-test-utils:0.53 dependency (with GWT 2.8.1)

I am using ant and all information found regarding this error indicated there was 2 versions of Juli Logging in the classpath, but every search came up with only gwt-dev.jar. Production builds worked fine, but dev mode did not which needs gwt-dev.jar.
Part of the build process has the jars copied from a local lib directory to war/WEB-INF/lib to pack into the war. The ant script points to the local lib directory for debugging, not the ones meant for the war file. Despite the war location not being listed in the ant file as a class path, it was still loading it.
Ultimately, gwt-dev.jar was conflicting with the copied version of itself.

ClassNotFoundException: how to find dependency conflict in Java

In a test WebSocket application using Atmosphere servlet I'm getting the following exception:
SEVERE: Servlet.service() for servlet AtmosphereServlet threw exception
java.lang.ClassNotFoundException: javax.servlet.AsyncContext
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1645)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1491)
at org.atmosphere.cpr.AtmosphereServlet.doPost(AtmosphereServlet.java:191)
at org.atmosphere.cpr.AtmosphereServlet.doGet(AtmosphereServlet.java:177)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
From the below posts I understand that this might be caused by a Servlet container version older than Servlet 3.0:
ClassNotFoundException: javax.servlet.AsyncContext in Jetty hello world
ClassNotFoundException: javax.servlet.AsyncContext in Jetty hello world in eclipse
Grails project - Servlet call - ClassNotFoundException: javax.servlet.AsyncContext
However the application is running on Tomcat7, and the following dependency is added in pom.xml:
<!-- https://mvnrepository.com/artifact/javax.servlet/javax.servlet-api -->
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
</dependency>
I've checked all other dependensies in the project and was not able to find anything else related to Servlet. Still I'm getting the exception.
Questions: How to find a jar file which is actually used by the application? How to find the dependency which is causing the usage of an old version?

I was finally able to solve the dependency conflict by doing the following.
To find the jar file which is used by application I used the below simple code:
public void listJarFilesAndClassVersions() {
Class classToCheck = javax.servlet.ServletRequestWrapper.class;
URL location = classToCheck.getResource('/'
+ classToCheck.getName().replace('.', '/') + ".class");
System.out.println(location.toString());
for(Package p : Package.getPackages()) {
if (p.getName().startsWith("javax.servlet")) {
System.out.println("Class: " + p.getName()
+ ", version: " + p.getSpecificationVersion());
}
}
}
The class javax.servlet.ServletRequestWrapper was chosen because it does exist in the old Servlet 2.5.
The execution of the above script gives me the following:
jar:file:/C:/Users/[username]/.m2/repository/org/apache/tomcat/servlet-api/6.0.29/servlet-api-6.0.29.jar!/javax/servlet/ServletRequestWrapper.class
Class: javax.servlet.jsp, version: 2.1
Class: javax.servlet, version: 2.5
Class: javax.servlet.http, version: null
So, first, it confirms that the Servlet of version 2.5 is used, and second, the "bad" jar is located in the maven repository under the tomcat directory.
After a short reasearch I was finally able to find the root cause of that: when deploying and running the maven application I need to specify the concrete version of tomcat, otherwise maven uses the libraries from tomcat of version 6. So the fix for me was to change
mvn -Dmaven.tomcat.port=8080 tomcat:run-war
to
mvn -Dmaven.tomcat.port=8080 tomcat7:run-war
Now if I execute the above script it gives the following result:
jar:file:/C:/Users/[username]/.m2/repository/org/apache/tomcat/embed/tomcat-embed-core/7.0.47/tomcat-embed-core-7.0.47.jar!/javax/servlet/ServletRequestWrapper.class
Class: javax.servlet.jsp, version: 2.2
Class: javax.servlet, version: 7.0
Class: javax.servlet.http, version: 7.0
Class: javax.servlet.annotation, version: 7.0
Class: javax.servlet.descriptor, version: 7.0
Hope it helps others who is running into the same issue.

There're two ways in which I usually find a conflict.
If you are using Eclipse, open the pom.xml in IDE, and switch to "Dependency Hierarchy" tab. In the left panel is the dependency tree, and in the right panel are the dependencies actually getting used. Right after each dependency it's its scope (eg. compile / test / runtime / omitted for conflict)
In terminal run the command. mvn dependency:tree It will print out the dependency like in Eclipse.

Using google cloud endpoints on AppEngine

I normally use Google Cloud Endpoints on the AppEngine (Java) , as described in :
https://cloud.google.com/appengine/docs/java/endpoints/helloendpoints-java-maven
The dependency for the endpoints library I use is :
<plugin>
<groupId>com.google.appengine</groupId>
<artifactId>appengine-endpoints</artifactId>
<version>1.9.48</version>
</plugin>
Using this, I can start a local development server using the command:
mvn clean package appengine:devserver
However, there seems to be a new version of cloud endpoints.
https://cloud.google.com/endpoints/docs/frameworks/java/quickstart-frameworks-java .
The new framework is found here
<dependency>
<groupId>com.google.endpoints</groupId>
<artifactId>endpoints-framework</artifactId>
<version>${endpoints.framework.version}</version>
</dependency>
The same maven commands do not work here. I am unable to start a local dev server, open the API explorer or use a local datastore (all of which was possible earlier) . Could someone please guide me on how to work with the new framework.
Also, is the former framework likely to be deprecated ?

To answer my own question partially :
I could finally get the "Echo application" (mentioned in https://cloud.google.com/endpoints/docs/frameworks/java/quickstart-frameworks-java) to work
But I had to make 2 changes:
a) Comment out the block in appengine-web.xml . ie,
<!--
<basic-scaling>
<max-instances>2</max-instances>
</basic-scaling>
-->
After doing this, I got a different error, "failed endpoints-api-configuration: com.google.api.config.ServiceConfigException: Failed to fetch default config version for service"
To get around this :
b) Comment out the ServiceManagementConfigFilter from web.xml , ie,
<!--
<filter>
<filter-name>endpoints-api-configuration</filter-name>
<filter-class>com.google.api.control.ServiceManagementConfigFilter</filter-class>
</filter>
-->
<!--
<filter-mapping>
<filter-name>endpoints-api-configuration</filter-name>
<servlet-name>EndpointsServlet</servlet-name>
</filter-mapping>
-->
After this,
To build : mvn clean package
To run locally : appengine-java-sdk/1.9.44/appengine-java-sdk/appengine-java-sdk-1.9.44/bin/dev_appserver.sh /path/to/war/directory
It would be great if someone could shed more light on implication of these changes, and on how we could get it to work out of the box

There are a few problems you are running into and this stuff is overly sensitive to configuration issues:
To solve the problems follow the instructions in: https://cloud.google.com/endpoints/docs/frameworks/java/quickstart-frameworks-java
Use the correct Google project id when you replace the YOUR_PROJECT_ID in pom.xml. It needs to be a valid project id for all the steps to work.
Same when replacing the YOUR-PROJECT-ID in echo.java
If the project id is not valid (actually exists in AppEngine) the next steps won't work
execute: mvn exec:java -DGetSwaggerDoc
execute: gcloud service-management deploy openapi.json
execute: export ENDPOINTS_SERVICE_NAME=echo-api.endpoints.<your project id>.cloud.goog
The quickstart guide is not very helpful for step 5. Step 4 needs to end with a success message.
Finally the sample comes with a Maven plugin that does not seem to work with the new Endpoints.
Instead of using:
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>appengine-maven-plugin</artifactId>
<version>${appengine.maven.plugin.version}</version>
</plugin>
use:
<plugin>
<groupId>com.google.appengine</groupId>
<artifactId>appengine-maven-plugin</artifactId>
<version>1.9.44</version>
</plugin>
The answer to the question why mvn appengine:devserver doesn't work is that the devserver target doesn't exist in the new plugin.
The old Maven plugin allows you to execute: mvn appengine:devserver