I am picking up an old project which has a lot of old dependencies.
I am using "Eclipse IDE for Enterprise Java and Web Developers".
After importing the source to Eclipse, Eclipse is complaining all my jsp files that
The superclass "jakarta.servlet.http.HttpServlet" was not found on the Java Build Path
In pom.xml, I see there is this dependency:
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.0.1</version>
<scope>provided</scope>
</dependency>
I went to google about the error and read a bit of javax vs jakarta history.
The thing is, because this is an old project that is still running on the server... can I stick with javax and not jakarta?
In Eclipse, under Project Facets, I have "Dynamic Web Module" checked and it is using Apache Tomcat v9.0 locally.
Under Server settings, I have "Tomcat v9.0 Server" at localhost for running this project.
Another thing I don't know if it has anything to do with setup of my Tomcat or project settings, which is that on pom.xml, I get an error about missing a lot of artifacts, like "jini:jsk-lib:jar", "jini:reggie:jar", "jini:start:jar", etc...
just go to mavenrepository
and serach for java servlet api
then click on the version api
then scroll down copy the dependency which looks like below
<!-- https://mvnrepository.com/artifact/javax.servlet/javax.servlet-api -->
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>4.0.1</version>
<scope>provided</scope>
</dependency>
now past this in pom.xml in your project within dependency tag which is already present.
after this
right click on the project
and select maven
select update project
then check force update
then click ok
this will solve your error
can I stick with javax and not jakarta?
Yes, certainly you can stick with the javax. naming rather than migrating to the new jakarta. namespace. Eventually you’ll want to make the migration to benefit from new and improved technologies. But not necessary this year or next.
Read the Which version? documentation page. You will see that versions 9.0.x and 10.0.x are functionally equivalent, developed in parallel. The only significant difference is that namespace change discussed above. So use Tomcat 9 if you choose to stick with javax naming.
You’ll need to get your codebase in order, to use only the javax. naming. Apparently you have some code that refers to the new jakarta. naming. Fix that. Check your import statements. Check any use of fully-qualified class names. Use your IDE’s search tools.
By the way… If using Tomcat 9, you can change that dependency on the Servlet API from 3.0.1 to the version 4.0.3 of the Servlet specification. See that Which version? page linked above, as well as the https://Jakarta.EE site, to learn the appropriate versions of specs for JSPs, etc.
In order to run javax.servlet with JSP you need two dependencies.
First one is servlet api,
<!-- https://mvnrepository.com/artifact/javax.servlet/servlet-api -->
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
<scope>provided</scope>
</dependency>
Second one is JSP api,
<!-- https://mvnrepository.com/artifact/javax.servlet.jsp/javax.servlet.jsp-api -->
<dependency>
<groupId>javax.servlet.jsp</groupId>
<artifactId>javax.servlet.jsp-api</artifactId>
<version>2.3.3</version>
<scope>provided</scope>
</dependency>
Note: javax.servlet.jsp-api also include the dependency to javax.servlet-api, so you do not need it explicitly in your project.
This means that, javax.servlet-api is mendatory for JSP to work.
Related
I have a working project with Dropwizard and Vaadin7.
I need to use Vaadin8 with the existing environment without removing vaadin7 code.
Can I run my project by using Vaadin7 and Vaadin8 both version?
As I am new to the Vaadin can anybody help me with some direction about how to solve this issue?
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-themes</artifactId>
<version>7.5.10</version>
</dependency>
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-client-compiled</artifactId>
<version>7.5.10</version>
</dependency>
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-client</artifactId>
<version>7.5.10</version>
</dependency>
This is my current vaadin configuration
You can't use two versions of the same dependency in Maven, it will take the first one.
As far as you are not using COMMUNITY ADD-ONS in your code it won't be a problem to upgrade the version to 8.
I leave you a good guide to learn how to upgrade the versions:
Guide to upgrade vaadin
As already noted, you can't have two versions specified of the same dependency in maven, but in this particular case, did you consider to use compatibility packages with Vaadin 8 Migrating to Vaadin 8? Then you would be able to access the classes needed from the Vaadin 7 framework using *.v7.* imports. Like noted in the link above:
The only change to classes in the compatibility packages is the change in their classpath. All compatibility classes can be found under com.vaadin.v7.*. For example the compatibility TextField is available through the import import com.vaadin.v7.ui.TextField, given that the project dependencies have been set up to include the compatibility variants, as described in the previous section.
It's not the exact solution you are looking for, but hopefully helps ,at least, a bit.
P.S. the problem, which might occur with this path is the add-ons, if they haven't been ported to Vaadin8. Then you will need to update the dependencies of our own and replace incompatible ones.
I'm using JavaEE 7 but I want to use the CDI 2.0 API (with Weld and Tomcat, Jersey too). When I have the following Maven dependency, it uses the old CDI API for Event (so no fireAsync):
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>7.0</version>
</dependency>
Adding this below it does not fix the issue (since the first maven dependency overrides it):
<dependency>
<groupId>javax.enterprise</groupId>
<artifactId>cdi-api</artifactId>
<version>2.0</version>
</dependency>
How would I get all the things I need (Jersey/Jax-RS, Servlets, ServerEndpoint, CDI 2.0/Weld in Tomcat 8) via Maven?
As of now (May 2017), EE 8 still wasn't released. And any EE 7 API dependency will bring in CD 1.2. Therefore, you need to make use of Maven to resolve the conflicting dependency versions. I can think of two ways to this:
1) Define CDI dependency before you define EE 7 API
When declaring versions in your <dependencyManagement> section of your pom.xml, Maven resolves dependencies from top to bottom, e.g. first encountered defines version. This means if you first define javax.exterprise:cdi-api:2.0, then it will take 2.0 and once you reach EE API, CDI version will be ignored. Hacky as this sounds, this is quite common way of manipulating dep. management section.
When using classical <dependency> the algorithm of dep resolution differs and uses the principal of 'nearest definition'. Image the dependencies as a tree with your project being the root. The shortest path (lowest depth) in the tree from root to the version of given dependency is always taken. In case of equal depths, first encountered is taken (since Maven 2.0.9).
Therefore in this case, simply defining cdi-api dependency with version directly should do the trick (depth will be 1, while with EE API depth would be 2).
2) Use exclusion(s) from artifact
I haven't tried this myself but theoretically, it should be possible to exclude cdi-api from EE 7 API dependency. Something along these lines:
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>7.0</version>
<exclusions>
<exclusion>
<groupId>javax.exterprise</groupId>
<artifactId>cdi-api</artifactId>
</exclusion>
</exclusions>
</dependency>
If you put the cdi-api dependency before the javaee-api, it will solve your problem and maven will pick up the "good" cdi-api dependency.
For your second question, javaee-api in 7.0 version is enough to have all the Java EE 7 API. Note that CDI 2.0 is not part of the Java EE 7 specification, that's why you need to add it manually.
In NetBeans 8, in a Maven-based project, how does one use a jar while programming but omit from build?
I need to access some specific classes in a specific JDBC driver in my Vaadin web app. But in web apps, we normally do not bundle JDBC drivers within our build (the .war file). Instead, the JDBC drivers belong in a folder controlled by the Servlet container (the runtime environment).
So, I need the JDBC driver (a jar file) to be on the classpath while I am editing my code and compiling. But that jar file must be omitted from the build.
exclusions Tag
I tried adding the exclusions and exclusion tags to my dependency element. But this did not work – The postgresql-9.4-1201.jdbc41.jar appeared in WEB-INF/lib folder.
<dependency>
<groupId>org.postgresql</groupId>
<artifactId>postgresql</artifactId>
<version>9.4-1201-jdbc41</version>
<exclusions>
<exclusion>
<groupId>org.postgresql</groupId> Exclude from build
<artifactId>postgresql</artifactId>
</exclusion>
</exclusions>
</dependency>
New Profile?
This Answer by ZNK - M on the Question, Setting custom runtime classpath for a maven project in netbeans, may be what I need.
But creating a new project profile seems like overkill what seems like small little task to me. And, I always want to exclude this jar from my build output, not just when testing or in other limited scenarios.
You should add a new profile run-with-netbeans in your pom that declares the additional dependencies (use the provided scope to not include them in the release).
Then you'll have to add the new profile to your IDE to run the pom with the -P run-with-netbeans option in the command line.
But I am familiar only with the basics of editing a POM file. If that approach is the way to go, it would be helpful if someone could expand on the details and steps needed.
<scope>provided</scope>
Use <scope> tag in POM file, with a value of provided.
Excerpt from the Dependency Scope section of the page, Introduction to the Dependency Mechanism :
compileThis is the default scope, used if none is specified. Compile dependencies are available in all classpaths of a project. Furthermore, those dependencies are propagated to dependent projects.
providedThis 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.
runtime[…]
test[…]
system[…]
import[…]
Like this:
<dependency>
<groupId>org.postgresql</groupId>
<artifactId>postgresql</artifactId>
<version>9.4-1201-jdbc41</version>
<scope>provided</scope>
</dependency>
Use the provided scope instead of the default compile scope for this dependency. That's exactly what it's for.
<dependency>
<scope>provided</scope>
<groupId>...</groupId>
<artifactId>...</artifactId>
<version>...</version>
</dependency>
In my project, i am using :
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.2</version>
</dependency>
I can not remove it, because a lot of other dependencies use it.
App is working with LDAP,so ecently i have add:
<dependency>
<groupId>org.apache.directory.server</groupId>
<artifactId>apacheds-all</artifactId>
<version>1.5.5</version>
</dependency>
Which is depends from:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.5.2</version>
</dependency>
And now i have a lot of errors:
java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;[Ljava/lang/Object;Ljava/lang/Throwable;)V
at org.apache.commons.logging.impl.SLF4JLocationAwareLog.error(SLF4JLocationAwareLog.java:225)
Can you please help me?
Yep, I see this question
You could:
Update your version to 1.5.7 which is the latest 1.x version. It depends on slf4j-log4j12:1.5.10, so this unlikely will help.
Consider using apacheds-all:2.0.0-M15. It depends on slf4j-log4j12:1.7.5 so if this version suits you, it should resolve this problem.
UPDATE
Some other ideas:
Decouple ApacheDS from Spring
or Disable logging for the problematic packages which use the old 1.5.x bridge
or Remove this bridge (by excluding a dependency) and (optionally) add log4j configuration to see log4j logs (never tried having them both!).
Maven should be picking the latest version, but you could try adding a dependency management section, to explicitly specify which version of slf4j you want. Probably picking the most recent version out of all your various dependencies will be fine (1.7.2 in this case).
Alternatively, I've come across this issue when deploying an application into jboss, because it bundles an old version of slf4j, which takes precedence over the version in my application. You can check this by running your application (or jboss or whatever) with the -verbose:class jvm parameter, it will log out where each class is being loaded from. This would tell you if it's being loaded from the jar in your application, or something in your environment.
I'm using JBoss EAP 6.0.1 (NOT JBoss AS 7.1.1 or 7.1.3!) and I'm just starting with a Maven project.
In normal Eclipse projects I set the target runtime of my project to the JBoss EAP server runtime and then all its libraries are available to my project. Available here means I can use e.g. ctrl-t to find a class in any of those libraries, and when I attach the source I can step into them when debugging.
How would I do this using Maven (m2e)?
I've found the Maven repository for JBoss EAP 6.0.1 at http://maven.repository.redhat.com/techpreview/eap6/6.0.1/
Do I need to add some root dependency (representing JBoss EAP itself) to my project, and if so, what would this dependency be?
I found a very similar question here: Adding JBoss AS 7 modules on Eclipse using Maven or JBoss Tools
But the accepted answer only says: "Take a look at these links", which doesn't tell me how to exactly do this (and it's for AS 7.1.1 not for EAP 6.0.1).
UPDATE
I wasn't entirely clear about the question. I'm not looking for a mere reference to the Java EE APIs. I know how to do that, as it's simply:
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>1.6</version>
<scope>provided</scope>
</dependency>
I'm also NOT looking for any vendor versions of that spec jar. I'm absolutely NOT looking for the following one either:
<dependency>
<groupId>org.jboss.spec</groupId>
<artifactId>jboss-javaee-6.0</artifactId>
<version>1.0.0.Final</version>
<type>pom</type>
</dependency>
What I'm looking for is having all implementation libs available in the project. The JBoss AS 6 server runtime does this by default, and with the JBoss AS 7/EAP 6 server runtime you can do this by going to Server -> Runtime Environments -> Default Classpath (you can enter individual paths there, or just add the /modules rootpath to have everything at one)
I'm looking for the equivalent of this in a Maven project.
I'M NOT LOOKING FOR SPEC JARS!!!!
As I need to step through the ACTUAL IMPLEMENTATION jars of the target server, I REALLY need the ACTUAL IMPLEMENTATION jars. I KNOW I can't deploy these, and nor do I intend to deploy them. They need to be present in my IDE, so there's source code that matches what's in the target JVM and I can use CTRL-SHIFT-T to lookup IMPLEMENTATION classes and CTRL-CLICK to navigate into them, analyse call hierarchies, etc.
AGAIN: I'M NOT LOOKING FOR SPEC JARS!!!!
You can import the dependencies manually into your repository. I did it into ours (artifactory) and it's working.
See: https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Application_Platform/6/html/Development_Guide/Install_the_JBoss_Enterprise_Application_Platform_6_Maven_Repository_Locally.html
I found a surprisingly simple solution my self: even though libs are managed via Maven, and a target runtime is disabled by default, you can still explicitly select a target runtime.
The libraries this target runtime puts on the classpath will now also be put on the classpath for the Maven project, in addition to those Maven already puts there. You can (manually) attach the source code to those libraries.
Once you're doing with debugging and stepping through the internals of your AS, you can simply remove the target runtime again.
An answer that tells how to do this purely via Maven and for JBoss EAP 6.0.1 (not JBoss AS 7.1.1 or 7.1.3) would still be welcome, so I won't accept my own answer ;)
There is a nice explanation of the JBoss Maven repositories at: https://community.jboss.org/wiki/MavenRepository
I would guess the repository you need to use is: https://repository.jboss.org/nexus/content/groups/public-jboss/
it should contain all JBoss artifacts you're looking for.
Maybee the groupId/artifactId is not correct. There is a search feature for the repositories at: https://repository.jboss.org/nexus/index.html#welcome
I would recommend to not include the impl jars as you cannot deploy them anyway. So the spec jars should be ok:
<dependency>
<groupId>org.jboss.spec</groupId>
<artifactId>jboss-javaee-6.0</artifactId>
<version>1.0.0.Final</version>
<type>pom</type>
</dependency>
see: http://www.andygibson.net/blog/quickbyte/jboss-java-ee-6-spec-dependency-in-maven/
The gav for the JBoss server seem to change a lot. JBoss 7 can be found at:
<dependency>
<groupId>org.jboss.as</groupId>
<artifactId>jboss-as-ee</artifactId>
<version>7.1.3.Final</version>
</dependency>
Take a look here:
JBoss Enterprise Application Platform Component Details
And in my pom.xml I'm using this to get dependencies from Jboss EAP 6.0.1
<dependency>
<groupId>org.jboss.spec</groupId>
<artifactId>jboss-javaee-6.0</artifactId>
<type>pom</type>
<scope>provided</scope>
<version>3.0.2.Final</version>
</dependency>
You can use Nexus or Git or Overlord to manage project artifacts in order to create a proxy virtual dependency, if i am not mistaken.
Runtime artifacts can be used:
<!-- https://mvnrepository.com/artifact/org.jboss.bom/eap-runtime-artifacts -->
<dependency>
<groupId>org.jboss.bom</groupId>
<artifactId>eap-runtime-artifacts</artifactId>
<version>7.1.0.GA</version>
<type>pom</type>
<scope>import</scope>
</dependency>
See https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.1/html/development_guide/using_maven_with_eap#manage_project_dependencies