The default jsp dependencies changed from glasfish to apache in jetty version 9.2.
http://www.eclipse.org/jetty/documentation/current/configuring-jsp.html
I have tried to replace all jsp dependencies in a project to apache but I have not succeeded to replace javax.servlet.jsp to a working apache dependency:
groupId: org.glassfish.web
artifactId: javax.servlet.jsp
version: 2.3.2
So are there any alternative dependency which I should use instead or is org.glassfish.web:javax.servlet still the best dependency to use when packaging a runnable war?
The exception thrown when removing the javax.servlet.jsp dependency is:
java.lang.ClassNotFoundException: org.apache.jasper.servlet.JspServlet
You only need the api libraries on the build time classpath. These should be marked with scope 'provided' which indicates that they should not be bundled in any generated artifact (WAR) as they will be provided by the Servlet container at runtime.
Thus in your pom you should have the following:
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.0.1</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jsp-api</artifactId>
<version>2.0</version>
<scope>provided</scope>
</dependency>
In the absence of any other container specific behaviour, the above change makes your application portable across all containers compliant with the relevant version of the Servlet specification.
Related
I have a web application created using spring boot. I have added jasper report, iText and bouncycastle maven dependency. Jasper and iText both contain bouncycastle libraries and now because of this the web application is not working correctly.
Error is: java.security.NoSuchProviderException: JCE cannot authenticate the provider BC. Note that I already added this code: Security.addProvider(new BouncyCastleProvider());
This perfectly works using spring boot embedded tomcat but not when exporting to a war file running on a wildfly server.
Here is how I declare the pom.
<dependency>
<groupId>org.bouncycastle</groupId>
<artifactId>bcpkix-jdk15on</artifactId>
<version>1.58</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.itextpdf</groupId>
<artifactId>itextpdf</artifactId>
<version>5.5.13</version>
</dependency>
<dependency>
<groupId>net.sf.jasperreports</groupId>
<artifactId>jasperreports</artifactId>
<version>6.4.0</version>
<exclusions>
<exclusion>
<groupId>org.bouncycastle</groupId>
<artifactId>bcprov-jdk14</artifactId>
</exclusion>
<exclusion>
<groupId>org.bouncycastle</groupId>
<artifactId>bcmail-jdk14</artifactId>
</exclusion>
</exclusions>
</dependency>
Upon creating war file, this are the list of libraries included:
bcmail-jdk14-138
bcprov-jdk14-138
bcpkix-jdk15on is not being included even I specify it as provided
To quote directly from the Maven docs
provided
This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive.
To paraphrase, it uses the .jar marked as "provided" to compile (and test) your software, but when you package it up, it will not be included in the .war: you are expecting the runtime system to provide a (presumably different) version of those classes.
Try removing changing the scope of that dependency to "compile" to see if that resolves your problem.
I am getting below error -
servlet [jersey] in context with path [/GeneralService] threw exception
java.lang.AbstractMethodError: javax.ws.rs.core.UriBuilder.uri
I am getting this error after adding a new external dependency which has below dependencies in it's pom.xml file-
jersey-client - 2.25.1 which in turn depends on -
javax.ws.rs-api - 2.0.1
when I exclude javax.ws.rs-api - 2.0.1 from the dependency heirarchy, I don't get the above mentioned error but then this external dependency code doesn't work as it depending on this artifact.
My main application has below jersey related dependencies in the pom.xml
<dependency>
<groupId>com.sun.jersey.contribs</groupId>
<artifactId>jersey-multipart</artifactId>
<version>1.18</version>
</dependency>
<dependency>
<groupId>com.sun.jersey.contribs</groupId>
<artifactId>jersey-spring</artifactId>
<version>1.18</version>
<exclusions>...</exclusions>
</dependency>
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-bundle</artifactId>
<version>1.18</version>
</dependency>
So my main application depends on the jersey version 1.18 and external dependency depends on jersey version 2.0.1.
I am unable to figure out a way to resolve this so that it runs smoothly. Any help is appreciated!
You need to use a consistent version of jersey, preferably 2.x. So update all your dependencies to 2.x and then figure out step by step which changes you need to make in your own code to make that work.
There is no sensible way to use different versions of the same artifact simultaneously.
The jersey version 1.18 use java.ws.rs version 1.1.1 as compile dependency. See:
https://mvnrepository.com/artifact/com.sun.jersey/jersey-bundle/1.18
Since you're talking about using jersey 2.25.1, I suggest to upgrade your pom to glassfish jersey 2.25:
https://mvnrepository.com/artifact/org.glassfish.jersey.core/jersey-client/2.25.1
like this:
<dependency>
<groupId>org.glassfish.jersey.core</groupId>
<artifactId>jersey-client</artifactId>
<version>2.25.1</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.media</groupId>
<artifactId>jersey-media-multipart</artifactId>
<version>2.25.1</version>
</dependency>
Then the dependency to java.ws.rs will be 2.0.1.
As for jersey-spring artifact, it don't depends on java.ws.rs
I have a maven project with multiple submodules.
I have a root pom file in which I have the jackson dependency
<dependency>
<groupId>fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>${jackson.version}</version>
</dependency>
I have the jackson dependency in one module called 'api'.
<dependency>
<groupId>fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<scope>provided</scope>
</dependency>
I have a new module named 'client' in which I import the maven dependency of 'api'
<dependency>
<groupId>abc.com</group>
<artifactId>api</artifactId>
<version>0.1.0-SNAPSHOT</version>
<scope>provided</scope>
</dependency>
I am using the following command to compile.
mvn -Djackson.version=2.4.4 compile
I am getting a compile error if I try to import jackson libraries to the client module unless I add the jackson dependency explicitly again to the client module
Why is adding the api dependency not sufficient as it already contains the jackson dependency
You define the jackson dependency in api as provided, so it is not transitive:
provided
This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive.
- https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope (emphasis added)
I am using the Glassfish library like this in my webapp to be in sync with Glassfish embedded libs directory during development. How can I update it to be able to use javax.validation.api 1.1.0?
This is the glassfish dependency:
<dependency>
<groupId>org.glassfish.main.extras</groupId>
<artifactId>glassfish-embedded-all</artifactId>
<version>4.0-b72</version>
<scope>provided</scope>
</dependency>
Unfortunately this glassfish lib collection is still using an older javax.validation-api lib. But to use:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-validator</artifactId>
<version>5.1.0.Final</version>
</dependency>
I need a newer one. Is there any way to update the Glassfish libs if there isn't a new version for glassfish-embedded-all.
How do you solve such issues?
Thanks in advance.
Is there any way to update the Glassfish libs if there isn't a new
version for glassfish-embedded-all.
Yes, but there is also a new version which is the 4.0 final build of GlassFish.
<dependency>
<groupId>org.glassfish.main.extras</groupId>
<artifactId>glassfish-embedded-all</artifactId>
<version>4.0</version>
<scope>provided</scope>
</dependency>
This version includes Hibernate Validator 5.0.0 which already depends on Validation API 1.1.0.
If you need a newer version then Hibernate Validator 5.0.0 you have to extract the corresponding GlassFish module (in this case bean-validation.jar), change the pom.xml to depend on the desired version and rebuild it with mvn package.
See also:
Bean-Validation 1.1 in Glassfish 4.0 - CDI Injection not working as intended
Trouble starting Hibernate Validator due to Bean Validation API
How to upgrade the hibernate-validator 4.3.0.Final to the Glassfish 3.1.2?
How do I add the servlets API to my project's pom.xml
mvnrepository.com has lots of servlet api and similarly named projects, that I don't know which is the right one. Or are all of them ok?
I believe most web/app servers come bundled with a version of the servlet api, so you won't want to bundle the api in your .war file. You will need to find out which version is included with your server, then you can use
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>${servlet-api-version}</version>
<scope>provided</scope>
</dependency>
replacing servlet-api-version with your version. You will want to specify the "provided" scope so the api.jar isn't included in your war file.
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>provided</scope>
</dependency>
For servlet-api 3.1.0, here is the declaration :
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
</dependency>
We use
<dependency>
<groupId>javax</groupId>
<artifactId>j2ee</artifactId>
<version>1.4</version>
<scope>provided</scope>
</dependency>
but if you only need the servlet api you might want to use
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>?</version>
<scope>provided</scope>
</dependency>
It depends on which version of the servlet API you are using.
The javax.servlet artifact will provide jars for all of the servlet API versions.
Scope provided can be used when you dont want to put jar file inside the WEB-INF/lib folder instead you are supplying it at runtime either by container or JDK.
Jakarta EE
In recent years, Oracle transferred the Java EE technologies to the Eclipse Foundation. There the technologies have been renamed to Jakarta EE. So Java Servlet is now known as Jakarta Servlet.
This name change was done to respect Oracle’s trademarks. Do a Web search to find many articles and videos discussing this transition.
This name change includes changing the package naming of the classes from javax.* to jakarta.*. This is a breaking change, though updating your project may be as simple as merely changing your import statements. But check that any libraries you depend on have versions available using the new naming as well.
Servlet 5
This transition has brought new versions of the Servlet specification. Version 5 of the spec is the same as Servlet 4 but with the new naming.
For the current version, edit your POM file to use the following Maven dependency. Check for updates in a Maven repository of your choice in the version numbering.
You can deploy web apps built with Servlet 5 to web containers such as Tomcat 10.0.x, Jetty 11.0.x, Glassfish 6, and several more.
<dependency>
<groupId>jakarta.servlet</groupId>
<artifactId>jakarta.servlet-api</artifactId>
<version>5.0.0</version>
<scope>provided</scope>
</dependency>
Servlet 6
Jakarta Servlet 6 specification is currently in development, and will contain significant changes. The spec will be finalized later this year 2022.
See the overview page, the product page, project links page, and repository coordinates page.
<dependency>
<groupId>jakarta.servlet</groupId>
<artifactId>jakarta.servlet-api</artifactId>
<version>6.0.0</version>
<scope>provided</scope>
</dependency>