Develop Reference

I'm using JakartaEE and making a "hello world" kind of restfulAPI, can't get a return string by visiting URL

Providing every step I took with this short video:
https://youtu.be/hbSr8sRYuOk
Project code here: https://github.com/LJonn/restapiHelloWorld
Running everything on a local server on tomcat.
I'm having this issue for quite some time and ran out of ideas where the problem might be...
I tried URL's such as these: "http://localhost:8080/api/hello" and "http://localhost:8080/helloworld/api/hello" and expected one of these to work.
Running http://localhost:8080/manager/text/list shows that helloworld.war is deployed fine and working:
OK - Listed applications for virtual host [localhost]
/:running:0:ROOT
/helloworld:running:0:helloworld
/examples:running:0:examples
/host-manager:running:0:host-manager
/manager:running:0:manager
/docs:running:0:docs
So why I still get a HTTP Status 404 page? What could I try to do to find the issue?
These are my project's Maven dependencies:
<dependencies>
<dependency>
<groupId>jakarta.platform</groupId>
<artifactId>jakarta.jakartaee-web-api</artifactId>
<version>9.1.0</version>
<scope>provided</scope>
</dependency>
</dependencies>
Thanks to Nikos Paraskevopoulos comment it looks like changing from Tomcat to TomEE might fix the issue, but now I'm running into a problem where the .war file can't be deployed/started, probably some sort of versions compatibility issue, tomcat manager GUI gives this error when trying to start the .war file:
FAIL - Application at context path [/helloworld] could not be started
FAIL - Encountered exception [org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/helloworld]]]
Looking to manager logs It looks like it has something to do with annotations and Java 16 maybe?:
...
Caused by: java.lang.IllegalArgumentException: Unsupported class file major version 60
at org.apache.xbean.asm7.ClassReader.<init>(ClassReader.java:195)
at org.apache.xbean.asm7.ClassReader.<init>(ClassReader.java:176)
at org.apache.xbean.asm7.ClassReader.<init>(ClassReader.java:162)
at org.apache.xbean.asm7.ClassReader.<init>(ClassReader.java:283)
at org.apache.xbean.finder.AnnotationFinder.readClassDef(AnnotationFinder.java:1176)
... 52 more
01-Sep-2021 15:25:02.185 INFO [http-nio-8080-exec-3] org.apache.catalina.core.ApplicationContext.log HTMLManager: list: Listing contexts for virtual host 'localhost'
I've tried to check JRE version on Eclipse and it's 16.0.2 and it looks to me that the same version is running on tomcat.

Tomcat 10.0 and 10.1 are not full Jakarta EE 9.1 application servers: you shouldn't use the jakarta.jakartaee-web-api artifact, which would imply that the runtime supports all Jakarta EE 9.1 Web Profile technologies.
Tomcat does not implement all the specs required in Web Profile. At least four other products do. See this list for Jakarta Web Profile 9.1:
Apache TomEE
Eclipse Glassfish
IBM Open Liberty
Red Hat WildFly
You can find the list of supported technologies on Tomcat's web site and for Tomcat 10 they translate to this list shown as a Maven POM snippet.
<dependency>
<groupId>jakarta.servlet</groupId>
<artifactId>jakarta.servlet-api</artifactId>
<version>5.0.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>jakarta.servlet.jsp</groupId>
<artifactId>jakarta.servlet.jsp-api</artifactId>
<version>3.0.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>jakarta.el</groupId>
<artifactId>jakarta.el-api</artifactId>
<version>4.0.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>jakarta.websocket</groupId>
<artifactId>jakarta.websocket-api</artifactId>
<version>2.0.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>jakarta.security.auth.message</groupId>
<artifactId>jakarta.security.auth.message-api</artifactId>
<version>2.0.0-RC1</version>
<scope>provided</scope>
</dependency>
Since Servlet 3.0, additional Jakarta EE specifications can be added using the servlet pluggability mechanism. To use JAX-RS you need to add:
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>3.0.2</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.inject</groupId>
<artifactId>jersey-hk2</artifactId>
<version>3.0.2</version>
</dependency>
or an equivalent configuration using other JAX-RS implementations.

How to use JIRA REST client library?

I need to use JIRA REST client version 5.2.0 or higher. Cloud JIRA does not work with an earlier version of the client.
In my pom.xml file I have the following dependencies:
<dependency>
<groupId>com.atlassian.jira</groupId>
<artifactId>jira-rest-java-client-core</artifactId>
<version>5.2.1</version>
</dependency>
<dependency>
<groupId>com.atlassian.jira</groupId>
<artifactId>jira-rest-java-client-app</artifactId>
<version>5.2.1</version>
</dependency>
When I building the project, I get an exception like this:
Failed to execute goal on project XXXXXXXXX: Could not resolve dependencies for project XXXXXXXXXX:jar:XXXX: Failed to collect dependencies at com.atlassian.jira:jira-rest-java-client-core:jar:5.2.1: Failed to read artifact descriptor for com.atlassian.jira:jira-rest-java-client-core:jar:5.2.1: Could not find artifact com.atlassian.platform:platform:pom:3.1.7 in MY_REPO (http://XXXXXXXXXX/repository/maven-public) -
com.atlassian.platform:platform:pom:3.1.7 is not listd at mvnrepository. There are versions 3.1.12 and 3.1.17, but not 3.1.7. Someone told me that version 3.1.7 might have had a security-related bug and was therefore removed by Atlassian.
Both jira-rest-java-client-app and jira-rest-java-client-core are children of jira-rest-java-client-parent, which uses version 3.1.7 of the platform:
<groupId>com.atlassian.jira</groupId>
<artifactId>jira-rest-java-client-parent</artifactId>
<version>5.2.1</version>
<packaging>pom</packaging>
[...]
<properties>
<platform.version>3.1.7</platform.version>
[...]
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.atlassian.platform</groupId>
<artifactId>platform</artifactId>
<version>${platform.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
5.2.1 seems to be the latest version of both jira-rest-java-client-core and jira-rest-java-client-app.
How can I use the JIRA REST client (for programmatically creating issues in Cloud JIRA) when it uses a version of the library that is not available any more?
I tried to exclude the platform in the dependencies and to specify another version in depencency management sections. This did not help.

The accepted answer is absolutely correct. A concrete example on how to be able to get the artifacts from https://packages.atlassian.com, for anyone coming here looking for answers, would be to include a repository element for it in your pom, like so:
<repositories>
<repository>
<id>atlassian-public</id>
<url>https://packages.atlassian.com/maven/repository/public</url>
</repository>
</repositories>
A WORD OF CAUTION, THOUGH: The jira-rest-java-client was created for use with Jira Server, not Jira Cloud
Some months ago, Atlassian made changes to Jira Cloud which made it impossible to use the jira-rest-java-client (JRJC) for things such as searches in Jira Cloud. As far as I can tell they don't intend to make the JRJC library compatible with Jira Cloud anymore. Atlassian has provided an article on how to generate a REST client for Jira Cloud, but as far as I know, they haven't created any Jira Cloud libraries similar to the JRJC.

If you have a look at the repository
https://packages.atlassian.com/mvn/maven-external
from atlassian, you find the desired artifact com.atlassian.platform:platform:pom:3.1.7there. Since this repository seems to be from atlassian, I see no reason to believe that they recommend not to use the version.
This is also discussed in https://community.atlassian.com/t5/Jira-questions/Jira-rest-java-client-core-5-1-and-fugue-2-7-0-breaks-build/qaq-p/1151091

What version of Jersey should I use with Glassfish 3.1 and Java 7?

After I added JAX-RS 2.1/Jersey 2.26+ libraries to my dynamic web project I got the next error:
Glassfish error after upload WAR file 1
The server is running Glassfish 3.1 with JDK 1.7.0_80
I tried to use Jersey 1.19.1 ZIP bundle but then Glassfish said:
Glassfish error after upload WAR file 2
The WAR file with the latest Jersey runs perfect with Tomcat 9 and Java 8 but I need this project to run with Glassfish 3.1 and Java 7.
If you can provide a link to the correct version of Jersey I would appreciate!
This is my very fisrt question so excuse any errors.

To run Jersey with Glassfish 3 you really need to exclude all Jersey.2 things from you war and either:
use the bundled Jersey.1 implementation of your Glassfish 3.1.2.2 installation (check the /lib or /modules folders you shall see it, or online documentation)
EDIT: Jersey version should be 1.11.1
<!-- Keep 1.11.1 for Jersey which is Fish's version -->
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-server</artifactId>
<version>1.11.1</version>
<!-- <scope>provided</scope> ... set Provided scope for GF3 deployment -->
</dependency>
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-servlet</artifactId>
<version>1.11.1</version>
<!-- <scope>provided</scope> ... set Provided scope for GF3 deployment -->
</dependency>
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-bundle</artifactId>
<version>1.11.1</version>
<!-- <scope>provided</scope> ... set Provided scope for GF3 deployment -->
</dependency>
<!-- Etc. - Organize your dependencies accordingly ... -->
replace the bundled Jersey.1 libraries of your Glassfish3 installation by another Jersey.1 implementation/libs(if you need a fresher version) - but never expect Jersey.2 to run with GF3.
Nonetheless you can actually write code that works with Jersey.1 and Jersey.2 but when you come to packaging and deployment you must build it with appropriate target JVM, dependencies and deployment descriptors - as soon as your modularization is "ok". I didn't read this post fully personnally but why not have a look here.

From Jersey latest (2.26) documentation
https://jersey.github.io/documentation/latest/modules-and-dependencies.html#d0e560
Since Jersey 2.26, all modules are build using Java SE 8 and there is no support for running it on older Java SE distributions.
So if you really want to use jersey 2.26 +, JDK should be 1.8+. No alternatives.

How to use javax.mail in Tomcat 7 inside openshift v3?

I use to have a site running in openshift v2, from where I could send a email using javax.mail.
But after migrating to openshift v3 the email function stopped working.
Now I just get a NoSuchProviderException. How ever I found this page: Might be a reson
I can compile the code with these dependencies:
<dependency>
<groupId>javax.mail</groupId>
<artifactId>javax.mail-api</artifactId>
<version>1.6.0</version>
</dependency>
<dependency>
<groupId>com.sun.mail</groupId>
<artifactId>mailapi</artifactId>
<version>1.6.0</version>
</dependency>
If I try with booth I get "NoSuchProviderException: smtp"
If I try only with com.sun.mail I get "NoSuchProviderException: smtp"
If I try only with javax.mail I get NoClassDefFoundError: com/sun/mail/util/MailLogger (this class is included in the other com.sun.mail-jar)
Is there any other libs that might already be shipped with tomcat 7 (that I assume is the webserver in openshift v3) that perhaps I should use instead of these two I have found?
Or do you guys see any other solution?
Best regards
Fredrik

hibernate-entitymanager NoSuchMethodError: org.jboss.logging.Logger.debugf(Ljava/lang/String;I)V

I'm deploying an EAR application built with Maven which has the following dependency in one of the modules:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-entitymanager</artifactId>
<version>5.1.0.Final</version>
</dependency>
When I try to deploy the application in a Glassfish Server 4.1 I get the following error:
Fatal: java.lang.NoSuchMethodError: org.jboss.logging.Logger.debugf(Ljava/lang/String;I)V
at org.hibernate.internal.NamedQueryRepository.checkNamedQueries(NamedQueryRepository.java:149)
I made some research to solve this problem and made the following attempts:
First Attempt
I found this question and used the script in this article to clean the Glassfish's osgi-cache, as suggested in the question and in this issue of the Glassfish/Payara Github repository. Restarted the server. Same error.
Second Attempt
I found this question and tried the suggestion of the first answer, like this: looking at the dependency tree, I see that hibernate-entitymanager has the following dependency:
<dependency>
<groupId>org.jboss.logging</groupId>
<artifactId>jboss-logging</artifactId>
<version>3.3.0.Final</version>
<scope>compile</scope>
</dependency>
So I searched at my Server installation and found the jboss-logging.jar. The installed version was 3.1.0-GA (I'm not sure right now, but surely it was a previous version of the dependency). I downloaded jboss-logging-3.3.0.Final.jar from the Maven Central Repository and replaced the one in my Server installation. Restarted the server. Same error.
Third Attempt
Some comments in the previous post (and others) suggested to add a property org.jboss.logging.provider=slf4j as I'm using these dependencies for logging:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.21</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.21</version>
<scope>test</scope>
</dependency>
I found some .properties files in the /glassfish/domains/domain1/config/ folder but none of them contains such a property and I don't know in which file to add that property. I also made some search in the Admin Console but I didn't found where to add properties. The only logging configuration I found was to configure logging levels.
After that I found where to put some JVM options for the Glassfish Server in the Admin Console and added -Dorg.jboss.logging.provider=slf4j as an option but did not work for me (even more, I had to reboot my computer to get Glassfish in ground zero)
Fourth Attempt
Before all this I had a problem and made another question in StackOverflow. Guided by this comment in that post I changed the project configuration but nothing happened (I solved that problem with a little change in my dependencies, answer still pending)
After all the attempts, I'm running out of ideas and the problem remains. I don't know what could be the problem. Any guide, help or answer will be really appreciated. If anybody needs more details about the situation just let me know.
Thanks in advance for your collaboration.
EDIT 1
I was searching and found this article which says something similar to what I did and adds a provided dependency for jboss-logging like this:
<dependency>
<groupId>org.jboss.logging</groupId>
<artifactId>jboss-logging</artifactId>
<version>3.3.0.Final</version>
<scope>provided</scope>
</dependency>
But the error remains. Apparently it's something with the Server but I can't figure out what. I'm using GlassFish Server Open Source Edition 4.1 (build 13)

I was using JBoss server 7.1 to deploy my project. In my case this error was due to the fact that the I was using jboss-logging-3.3.0.Final.jar in my project but the JBoss 7 had a jboss-logging-3.1.0.GA.jar (/opt/jboss-as-7.1.1.Final/modules/org/jboss/logging/main/) by default. So, may be this was due to the jar conflict or method was not present in the jboss-logging-3.1.0.GA.jar, I am not sure. But replacing the jboss-logging-3.1.0.GA.jar with jboss-logging-3.3.0.Final.jar and change mapping in module.xml (at the same above mentioned location) as follows
<module xmlns="urn:jboss:module:1.1" name="org.jboss.logging">
<resources>
<resource-root path="jboss-logging-3.3.0.Final.jar"/>
<!-- Insert resources here -->
</resources>
<dependencies>
<module name="org.jboss.logmanager"/>
</dependencies>
</module>
And the error was gone. Hope it helps.

This is because GlassFish ships with an earlier version of JBoss Logging and this is being picked up by your application hence the NoSuchMethod error. The version of JBoss Logging shipped with GlassFish 4.1 does not have the method defined. You can try and replace the version of jboss-logging in the modules directory of glassfish this may or may not work but it looks like you tried and failed with this approach.
Another option is to upgrade to the latest Payara 4.1.1.162 which ships with JBoss Logging 3.3.0.Final.

Block Glassfish for using its own lib when project lib is provided
Just create a glassfish-web.xml file in the WEB-INF directory. The contents of the file are shown below:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">
<glassfish-web-app>
 <class-loader delegate="false"/>
</glassfish-web-app>
This ensures that glassfish does not load it's internal libraries, but libraries from your project.