With the recent announcement of support for Servlet 3.1, I cannot figure out how to modify the App Engine Standard environment to use 3.1 instead of 2.5 in a non-Maven build.
It seems there is no way to upgrade to 3.1?
https://cloudplatform.googleblog.com/2017/06/Google-App-Engine-standard-now-supports-Java-8.html
Here is a full example given here: https://github.com/GoogleCloudPlatform/getting-started-java/tree/master/appengine-standard-java8/helloworld
Running procedure is also attached.
For Gradle Users:
For non-maven users, you can use gradle.
In gradle build file, line number 39 denotes: https://github.com/GoogleCloudPlatform/getting-started-java/blob/master/appengine-standard-java8/helloworld/build.gradle#L39
providedCompile 'javax.servlet:javax.servlet-api:3.1.0'
Running locally:
gradle appengineRun
If you do not have gradle installed, you can run using ./gradlew appengineRun.
To use visit: http://localhost:8080/
For Maven Users
In pom.xml, line number 62 to 70 denotes that it is using servlet version 3.1.0: https://github.com/GoogleCloudPlatform/getting-started-java/blob/master/appengine-standard-java8/helloworld/pom.xml#L66
<!-- [START servlet] -->
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
<type>jar</type>
<scope>provided</scope>
</dependency>
<!-- [END servlet] -->
Hope it will clarify you.
These are the steps that should work no matter what technique is used, as long as it produces a valid war that includes javax.servlet-api:3.1.0:
1) As documented, make sure you've added <runtime>java8</runtime> to your appengine-web.xml file
2) uncompress the war into its own separate directory
3) deploy using the appcfg.sh script found on App Engine SDK for Java bin directory. It will look something like:
/<some-path>/appengine-java-sdk-1.9.54/bin/appcfg.sh update /<some-path>/exploded-war/
Note: To verify ServletContext's version from within a servlet I've used:
ServletContext sc = req.getSession().getServletContext();
resp.getWriter().println("Servlet version = " + sc.getMajorVersion() + "." + sc.getMinorVersion());
Related
I was upgrading to new library of geojson from version 14.2 to 20.2. And I was keep of getting below maven build error which is failing at the bundle processing with the message "the-default-package . -is-not-permitted-by-the-import-package-syntax".
I expect the maven build with bundle processing to be successful but the actual output is "the-default-package-is-not-permitted-by-the-import-package-syntax" error.
While upgrading the geotools library from old version 14.2 to new version 20.2, there were lot of changes has been made.
GeoTools Upgrade
This was one of the link that would help everyone to do it very easily. But with the upgradation of geotools, we also update the gt-geojson library too. This library contains the class "Skunkwork" without any package name which result in above error during bundle processing of maven build. To avoid this error,i have to remove this class. And it works fine.
Before Fix
POM Configuration:
<dependency>
<groupId>org.geotools</groupId>
<artifactId>gt-geojson</artifactId>
<version>20.2</version>
</dependency>
After Fix
POM Configuration:
<dependency>
<groupId>org.geotools</groupId>
<artifactId>gt-geojson</artifactId>
<version>20.2-fixed</version>
</dependency>
Note: This jar needs to be manually installed to your local repository. And as well as you need to install the fixed jar to remote artifactory if used by your code base such as Nexus, JFrog etc.
We created client for web-service with security policy to call the other web-service by passing the required information like username,password and other information..Jdeveloper had given the support for security policy and their packages but to create the war and building the application we are using maven.
when we compile through maven it is giving the compilation errors.
Can any one suggest is there any plug in to add in the maven to compile the code..
Please click below link to see the image of compilation error :
Compilation errors in console when we run Maven
The Package weblogic.wsee.jws.jaxws.owsm is part of weblogic middleware and is installed on the modules folder.
You can add it to your maven repository for example Nexus as:
<dependency>
<groupId>com.oracle.weblogic</groupId>
<artifactId>ws.api</artifactId>
<version>1.1.0.0</version>
</dependency>
The file is %MW_HOME%\modules\ws.api_1.1.0.0.jar
or, of course, if you don't want the hassle of going through adding artifacts to the repository:
<dependency>
<groupId>com.oracle.weblogic</groupId>
<artifactId>ws.api</artifactId>
<version>1.1.0.0</version>
<scope>system</scope>
<systemPath>${mw.home}/modules/ws.api_1.1.0.0.jar</systemPath>
</dependency>
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.
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
I have a Maven Java project that uses Mashape Unirest for sending HTTP requests to other URLs. I am currently writing an integration test (using TestNG) that sends a normal HTTP request using Unirest. When I run the integration test through Maven (via the Failsafe plugin), the request is sent out successfully. However, when I try to run the integration test via Eclipse, I keep on getting the following error:
FAILED: getCurrentTimeTest
java.lang.NoSuchFieldError: INSTANCE
at org.apache.http.impl.io.DefaultHttpRequestWriterFactory.<init>(DefaultHttpRequestWriterFactory.java:52)
at org.apache.http.impl.io.DefaultHttpRequestWriterFactory.<init>(DefaultHttpRequestWriterFactory.java:56)
at org.apache.http.impl.io.DefaultHttpRequestWriterFactory.<clinit>(DefaultHttpRequestWriterFactory.java:46)
at org.apache.http.impl.conn.ManagedHttpClientConnectionFactory.<init>(ManagedHttpClientConnectionFactory.java:72)
at org.apache.http.impl.conn.ManagedHttpClientConnectionFactory.<init>(ManagedHttpClientConnectionFactory.java:84)
at org.apache.http.impl.conn.ManagedHttpClientConnectionFactory.<clinit>(ManagedHttpClientConnectionFactory.java:59)
at org.apache.http.impl.conn.PoolingHttpClientConnectionManager$InternalConnectionFactory.<init>(PoolingHttpClientConnectionManager.java:487)
at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>(PoolingHttpClientConnectionManager.java:147)
at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>(PoolingHttpClientConnectionManager.java:136)
at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>(PoolingHttpClientConnectionManager.java:112)
at org.apache.http.impl.client.HttpClientBuilder.build(HttpClientBuilder.java:726)
at com.mashape.unirest.http.options.Options.refresh(Options.java:41)
at com.mashape.unirest.http.options.Options.<clinit>(Options.java:27)
at com.mashape.unirest.http.HttpClientHelper.prepareRequest(HttpClientHelper.java:141)
at com.mashape.unirest.http.HttpClientHelper.requestAsync(HttpClientHelper.java:80)
at com.mashape.unirest.request.BaseRequest.asStringAsync(BaseRequest.java:56)
at ...
I am also able to reproduce this error using a basic Java application script.
I have made sure that the dependencies I am using in my pom.xml file are the latest and greatest, as seen below:
<dependency>
<groupId>com.mashape.unirest</groupId>
<artifactId>unirest-java</artifactId>
<version>1.3.5</version>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.3.2</version>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpasyncclient</artifactId>
<version>4.0</version>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpmime</artifactId>
<version>4.3.2</version>
</dependency>
<dependency>
<groupId>org.json</groupId>
<artifactId>json</artifactId>
<version>20140107</version>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpcore</artifactId>
<version>4.3.2</version>
</dependency>
I have also checked out the source code of BasicLineFormatter.java, both from the source file downloaded to Eclipse and from Apache's Httpcore Github repo. In the Github repo, notice how the INSTANCE field is defined for the 4.3.x branch and the trunk branch, but not in older branches like 4.2.x. However, I am indeed using version 4.3.2 in my project, so I should be using a JAR file for Httpcore that has the latest version of BasicLineFormatter. I know that, based on the Maven Dependencies JAR files that are in my project, that I am indeed using the latest versions of these Apache dependencies, not the older versions specified as downstream dependencies of my project.
I have checked other various SOF and blog posts about this issue, such as Mashape Unirest Java : java.lang.NoClassDefFoundError and this blog post too, but they all seem to be talking about solving the NoSuchFieldError problem for Android. However, I'm dealing with a standalone Java application, not an Android application.
I am at a loss in determining how to troubleshoot this issue. Anyone have any idea what I need to do?
UPDATE
Instead of showing my test case, I will reduce the illustration of a reproduction of this problem to just a simple one-liner Java application, because the problem exists with any Java application or test case run through Eclipse, not just one particular test:
System.out.println(Unirest.get("http://www.google.com").asStringAsync().get().getBody());
Normally, this should print the HTML of the Google home page, but I instead get the NoSuchFieldError stack trace.
FIXED!
The problem was that the AWS SDK (it's on my classpath because I'm developing for Elastic Beanstalk) had a conflicting JAR file. Using Oleg's solution (thanks BTW), I printed the following output in a unit test:
jar:file:/some/path/aws-java-sdk/1.7.1/third-party/httpcomponents-client-4.2.3/httpcore-4.2.jar!/org/apache/http/message/BasicLineFormatter.class
I'll have to rearrange my classpath so that AWS SDK is no longer conflicting.
The only plausible explanation to this problem is there is an older version of HttpCore on the classpath (unless you also want to consider a possibility of green men from Mars messing with your computer remotely from a flying saucer).
You can add this snippet to your code to find out what jar the class gets picked up from. This might help find out why that jar is on your classpath in the first place.
ClassLoader classLoader = MyClass.class.getClassLoader();
URL resource = classLoader.getResource("org/apache/http/message/BasicLineFormatter.class");
System.out.println(resource);
This basically tells me that in my case the jar resides in the local maven repository and likely to have been added to the classpath by Maven
jar:file:/home/oleg/.m2/repository/org/apache/httpcomponents/httpcore/4.3.1/httpcore-4.3.1.jar!/org/apache/http/message/BasicLineFormatter.class
As already mentioned by previous comments, It's mainly because of the conflicting versions of httpcore jar, the static field INSTANCE is been added to BasicLineFormatter class in versions > 4.3.1, Though you might have added the latest version of the httpcore jar in your dependencies, but its highly possible that other (lower) version of jar is getting picked up.
So, first to confirm that, wrong jar is getting picked up, Use the following line of code -
ClassLoader classLoader = <Your Class>.class.getClassLoader();
URL resource = classLoader.getResource("org/apache/http/message/BasicLineFormatter.class");
System.out.println(resource);
If this prints, the lower version of the jar, then it's confirmed that it's picking the lower version of the httpcore jar (May be from other dependencies of your project),
Solution -
Add following maven/gradle dependencies at the top of dependency list (Or above the other project dependency which caused the conflict) -
<dependency>
<groupId>com.mashape.unirest</groupId>
<artifactId>unirest-java</artifactId>
<version>1.4.5</version>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpcore</artifactId>
<version>4.4.1</version>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.4.1</version>
</dependency>
I faced the same exception using unirest:
java.lang.NoSuchFieldError: INSTANCE
at org.apache.http.impl.io.DefaultHttpRequestWriterFactory.<init>(DefaultHttpRequestWriterFactory.java:52)
at com.mashape.unirest.http.options.Options.refresh(Options.java:55)
at com.mashape.unirest.http.options.Options.<clinit>(Options.java:36)
And found it was due to DefaultConnectionKeepAliveStrategy.INSTANCE; and the conflicting jar was apache-httpcomponents-httpclient.jar in my classpath. Adding this post to help anyone who faces similar exception
I got this Exception: Caused by: java.lang.NoSuchFieldError: INSTANCE
Solution:
This happens if you have two different version classes in your classpath…. […], So I first find that class (one version of class), click that class, select build path, then I click remove from build path.
if you are using aws sdk this error occurs because of dependency mismatch.
To avoid this error do the following:
1.Put the dependecies in the required order aws sdk and the end preferably
2.Add shade plugin to the project
This solved my problem
you can refer to my answer in
HTTPClient Example - Exception in thread "main" java.lang.NoSuchFieldError: INSTANCE
my case is i have httpclient-4.4.1.jar, and httpcore-4.4.1.jar in my class path, but JVM loaded BasicLineFormatter from httpcore-4.0.jar