We Keep Coding

Change CodeStar Spring MVC project to Spring Boot

I have a Spring Boot project that works perfectly when run in IDE. I would like to run this via AWS CodeStar. Unfortunately, the default Spring template created by CodeStar uses Spring MVC.
I cannot just overwrite the default Spring MVC project with my Spring Boot project (it doesn't work). I can copy some of my resources to the MVC project, for example index.html and that works. But then features like Thymeleaf don't work. For this and other reasons, I would like to change the provided Spring MVC into the Spring Boot structure I already have.
I followed the instructions here: https://www.baeldung.com/spring-boot-migration
Unfortunately, this doesn't help. I can create Application Entry Point and add Spring Boot dependencies without the app breaking. But when I remove the default dependencies or the configuration associated with the MVC, the app breaks. When trying to reach the URL, I get a 404 error with description:
The origin server did not find a current representation for the target resource or is not willing to disclose that one exists.
Debugging this error message (e.g. https://www.codejava.net/java-ee/servlet/solved-tomcat-error-http-status-404-not-found) didn't help.
The message seems like it's connected to the web resource. I have my web resources in folder resources as well as webapp/resources. And Spring Boot doesn't need any location configuration, right? It uses this location by default.
Can somebody tell me what things to remove and what to add to be able to use my existing Spring Boot project?
EDIT:
This is a link to a default template for AWS CodeStar Spring web application: https://github.com/JanHorcicka/AWS-codestar-template
And this is my Spring Boot project structure:

I realize that you indicated that previously you tried to use your Spring Boot project with some modifications without success, but I think it could be actually a possibility to successfully deploy your application on AWS CodeStar, and it will be my advice.
I also realized that in your screenshot you included several of the required artifacts and classes, but please, double check that you followed these steps when you deployed your application to AWS CodeStar.
Let's start with a pristine version of your Spring Boot project running locally, without any modification, and then, perform the following changes.
First, as indicated in the GitHub link you shared, be sure that you include the following files in your project. They are required for the deployment infrastructure of AWS:
appspec.yml
buildspec.yml
template.yml
template-configuration.json
The whole scripts directory
Please, adapt any necessary configuration to your specific needs, especially, template-configuration.json.
Then, perform the following modifications in your pom.xml. Some of them are required for Spring Boot to work as a traditional deployment and others are required by the deployment in AWS CodeStar.
Be sure that you indicate packaging as war:
<packaging>war</packaging>
To ensure that the embedded servlet container does not interfere with the Tomcat to which the war file is deployed, either mark the Tomcat dependency as being provided as suggested in the above-mentioned documentation:
<dependencies>
<!-- … -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
<scope>provided</scope>
</dependency>
<!-- … -->
</dependencies>
Or exclude the Tomcat dependency in your pom.xml:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<exclusions>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
</exclusion>
</exclusions>
</dependency>
If necessary, apply this exclusion using some kind of profile that allows you to boot Spring Boot locally and in an external servlet container at the same time.
Next, parameterize the maven war plugin to conform to the AWS CodeStar deployment needs:
<build>
<pluginManagement>
<plugins>
<!-- ... -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>3.2.2</version>
<configuration>
<warSourceDirectory>src/main/webapp</warSourceDirectory>
<warName>ROOT</warName>
<failOnMissingWebXml>false</failOnMissingWebXml>
</configuration>
</plugin>
<!-- ... -->
<plugins>
</pluginManagement>
</build>
I do not consider it necessary, but just to avoid any kind of problem, adjust the name of your final build:
<finalName>ROOT</finalName>
Lastly, as also indicated in the Spring documentation, be sure that your MyProjectApplication - I assume this class is your main entry point subclass SpringBootServletInitializer and override the configure accordingly, something like:
#SpringBootApplication
public class MyProjectApplication extends SpringBootServletInitializer {
#Override
protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
return application.sources(MyProjectApplication.class);
}
public static void main(String[] args) {
SpringApplication.run(MyProjectApplication.class, args);
}
}
Please, feel free to adapt the class to your specific use case.
With this setup, try to deploy your application and see if it works: perhaps you can find some kind of library dependencies problem, but I think for the most part it should work fine.
At a first step, you can try to deploy locally the version of the application you will later deploy to AWS CodeStar following the instructions you provided in your project template, basically, once configured with the necessary changes described in the answer, by running:
mvn clean package
And deploying the generated war on your local tomcat environment. Please, be aware that probably the ROOT application already exists in a standard tomcat installation (you can verify it by inspecting the webapps folder): you can override that war file.
For local testing you can even choose a different application name (configuring build.finalName and the warName in your pom.xml file): the important thing is verify if locally the application runs successfully.
If you prefer to, you can choose to deploy the app directly to AWS CodeStar and inspect the logs later it necessary.
In any case, please, pay attention on two things: on one hand, if you have any absolute path configured in your application, it can be the cause of the 404 issue you mention in the comments. Be aware that your application will be deployed in Tomcat with context root '/'.
On the other hand, review how you configured your database access.
Probably you used application.properties and it is fine, but please, be aware that when employing the application the database must be reachable: perhaps Spring is unable to create the necessary datasources, and the persistence manager or related stuff associated with and, as a consequence, the application is not starting. Again, it may be the reason of the 404 error code.
To simplify database connectivity, for testing, at first glance, I recommend you to use simple properties for configuring your datasource, namely the driver class, connection string, username and password. If that setup works properly, you can later enable JNDI or what deemed necessary.
Remember that if you need to change your context name and/or define a datasource pool in Tomcat you can place a context.xml file under a META-INF directory in your web app root path.
This context.xml should look like something similar to:
<?xml version="1.0" encoding="UTF-8"?>
<Context path="/">
<Resource name="jdbc/myDS"
type="javax.sql.DataSource"
maxActive="100"
maxIdle="30"
maxWait="10000"
url="jdbc:mysql://localhost:3306/myds"
driverClassName="com.mysql.jdbc.Driver"
username="root"
password="secret"
/>
</Context>

How to test EJBs in Spring Boot - openejb cannot handle multi-release JARs because of module-info

I am currently upgrading one application from Spring Boot 1.X to 2.X. One of the tests in the application is testing Stateless remote EJB using OpenEJB under the #SpringBootTest. Since the support for SpringBeanAutowiringInterceptor has been dropped in Spring 5, I am now faced with a task to rewrite the logic and test it and here comes the problem:
We are running on JDK 1.8 and openejb (4.7.4, which is used in the test to initialize jndiContext) cannot handle multi-release JARs which comes as a dependencies from upgrade to Spring Boot 2.X (for example byte-buddy and others). OpenEJB tries to load META-INF/versions/9/module-info and fails on IllegalArgumentException.
I am also trying switch from OpenEJB to EJBcontainer along with glassfish as loader, but I am facing different issues (Stateless bean is not set in the jndContext - inspected in DEBUG), which I am currently trying to solve.
My question is: Is there any possibility to somehow force classloader or openejb to ignore module-info to be able to run it under JDK 1.8 with multi-release jars on classpath? Or is there a way to use EJBContainer with glassfish-embedded-all, which currently doesn't load the EJB but at least load the context without error? I need to avoid the error or use another way how to test Stateless Bean in SpringBootTest.
Note: I don't want to use Arquillian
Summary of versions:
JDK 1.8
spring-boot-starter-parent: 2.1.3.RELEASE
openejb-core: 4.7.4
glassfish-embedded-all: 5.1.0
Error using openEJB (module-info, multi-release JARs problem):
ERROR OpenEJB [] []- FATAL ERROR: Unknown error in Assembler. Please send the following stack trace and this message to users#tomee.apache.org :
java.lang.IllegalArgumentException
at org.apache.xbean.asm5.ClassReader.<init>(Unknown Source)
at org.apache.xbean.asm5.ClassReader.<init>(Unknown Source)
at org.apache.xbean.asm5.ClassReader.<init>(Unknown Source)
at org.apache.openejb.util.AnnotationFinder.readClassDef(AnnotationFinder.java:299)
at org.apache.openejb.util.AnnotationFinder.find(AnnotationFinder.java:164)
at org.apache.openejb.config.DeploymentLoader.checkAnnotations(DeploymentLoader.java:2008)
at org.apache.openejb.config.DeploymentLoader.discoverModuleType(DeploymentLoader.java:1891)
at org.apache.openejb.config.DeploymentsResolver.processUrls(DeploymentsResolver.java:389)
at org.apache.openejb.config.DeploymentsResolver.loadFromClasspath(DeploymentsResolver.java:302)
at org.apache.openejb.config.ConfigurationFactory.getModulesFromClassPath(ConfigurationFactory.java:664)
Error using glassfish (probably wrong MODULES specified?):
ERROR embedded [] []- EJB6005:No EJB modules found
Important part of test class:
#RunWith(SpringRunner.class)
#SpringBootTest(classes = {
CommonTestConfiguration.class,
DatabaseTestConfiguration.class,
PropositionServiceConfiguration.class,
BeanUtils.class,
PropositionRemoteServiceImpl.class,
PropositionRemoteService.class})
#DirtiesContext
public class PropositionRemoteServiceImplTest {
#Autowired
private AdminFacade adminFacade;
private PropositionRemoteService remoteService;
#Before
public void setUp() throws NamingException {
Properties props = new Properties();
props.put(Context.INITIAL_CONTEXT_FACTORY, "org.apache.openejb.client.LocalInitialContextFactory");
//props.put("openejb.deployments.classpath.exclude", ".*?module-info.*?");
Context jndiContext = new InitialContext(props);
remoteService = (PropositionRemoteService) jndiContext.lookup("PropositionRemoteServiceImplRemote");
// Map<String, Object> properties = new HashMap<>();
// properties.put(EJBContainer.MODULES, new File("target/classes"));
// EJBContainer ejbContainer = EJBContainer.createEJBContainer(properties);
// Context ctx = ejbContainer.getContext();
// remoteService = (PropositionRemoteService) ctx.lookup("PropositionRemoteServiceImplRemote");
}
Project structure (simplified - large project, cannot change):
ude> root node module - pom
adapter> - node-module
ejb-adapter> node module
ejb-adapter-impl> node module containing Stateless bean used in test
test> node module
test-unit> node module where the Test class is defined and run
UPDATE:
Currently trying apache-tomee (1.7.5) instead of openejb-core sbut it uses also asm5 and the same error occurs

Problem solved using newer version openEJB -> Apache Tomee, which uses asm6 and supports JDK 1.9, even if I am using JDK 1.8, but because of multi-release JARS as dependencies from Spring Boot 2, this support is needed.
Artifact used:
<dependency>
<groupId>org.apache.tomee</groupId>
<artifactId>apache-tomee</artifactId>
<version>8.0.0-M2</version>
<scope>test</scope>
</dependency>

RESTEasy annotation scan unable to find resources (under Tomcat)

I'm trying to update WAR with old RESTEasy 3.0.5 to something newer. 3.0.6 works fine, but after updating to 3.0.7 (or higher, like 3.0.24) all resources (#Path) are lost — 404 for any resource. WAR is run under Apache Tomcat server.
I believe the reason is linked to change of annotation scanner:
https://issues.jboss.org/browse/RESTEASY-1010
I've tried to create class which extends javax.ws.rs.core.Application instead of web.xml configuration. According to answer https://stackoverflow.com/a/29957040/2528366, empty set should trigger scan for #Path but no any resource is found. If I override getClasses() which returns non-empty set, that resources work as expected.
web.xml: https://pastebin.com/uRD2w6Z6
New Application inherited class:
#ApplicationPath("/rest")
public class WebApi extends Application
{
#Override
public Set<Class<?>> getClasses()
{
Set<Class<?>> s = new HashSet<>();
// if line below is uncommented SomeResource works fine
// s.add(SomeResourceImpl.class);
return s;
}
}
Resources are interfaces and implementation is in derived classes. Moving annotations to classes itself changes nothing.
What's wrong with annotations or configuration? Or is there something else needed to trigger scanning for annotations?

If you are using a Tomcat version that is compatible with the Servlet 3.0 specification, you need to add the resteasy-servlet-initializer dependency :
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-servlet-initializer</artifactId>
<version>${resteasy.version}</version>
</dependency>
As stated in the documentation :
Resteasy uses the ServletContainerInitializer integration interface in Servlet 3.0 containers to initialize an application, automatically scanning for resources and providers. To enable automatic scanning, you must also include the resteasy-servlet-initializer artifact in your WAR file as well

Jackson with JodaTime and Jax-rs

I have a REST web-service created in Java. I am using Joda-time for the date and Jackson for the JSON formatting. Everything is uploaded on a Glassfish 4.1 server
Versions
avax.ws.rs-api-2.0.1.jar
joda-time-2.7.jar
jackson-annotation-2.8.8.jar
jackson-core-2.8.8.jar
jackson-databind-2.8.8.jar
jackson.datatype-joda-2.8.8.jar
Mapper
#Provider
public class ObjectMapperContextResolver implements ContextResolver<ObjectMapper>{
final ObjectMapper mapper = new ObjectMapper();
public ObjectMapperContextResolver() {
mapper.registerModule(new JodaModule());
}
#Override
public ObjectMapper getContext(Class<?> type) {
return mapper;
}
}
Error when calling the service
java.lang.NoSuchFieldError: WRITE_DURATIONS_AS_TIMESTAMPS
What I found
I already found that it may have a mismatch between different versions. All the jars come from maven repository and I took each times the dependencies needed.
Question
What am I missing ? Is there a missing library ? Is there a wrong library's version ?
Note: I am not using Maven
Update
I tried to update the jackson-?.jars inside glassfish4.1/glassfish/modules but now I cant even start the server because of a requirement mismatch with jackson versions
Updates 2
Is there a way to use the jackson libraries that are inside my project instead of the one in Glassfish ? This seems to be the solution

Is there a way to use the Jackson libraries that are inside my project instead of the one in Glassfish? This seems to be the solution.
See the following quote from the chapter 2 of the GlassFish 4 Application Development Guide:
The Java Servlet specification recommends that a web module's class loader look in the local class loader before delegating to its parent. You can make this class loader follow the delegation inversion model in the Servlet specification by setting delegate="false" in the class-loader element of the glassfish-web.xml file. It is safe to do this only for a web module that does not interact with any other modules. [...]
The default value is delegate="true", which causes a web module's class loader to delegate in the same manner as the other class loaders. You must use delegate="true" for a web application that accesses EJB components or that acts as a web service client
or endpoint. [...]
For a number of packages, including java.* and javax.*, symbol resolution is always delegated to the parent class loader regardless of the delegate setting. This prevents applications from overriding core Java runtime classes or changing the API versions of specifications that are part of the Java EE platform.
In the section B of the GlassFish 4 Application Deployment Guide you'll find an example of the glassfish-web.xml deployment descriptor. Tailoring it to your issue, your glassfish-web.xml file would be like:
<!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>
Then place it under WEB-INF of your web module.

How to write Jersey Multipart webapp, Tomcat Server

I've been doing a lot of REST tutorials and enjoying them. Recently, I tried writing a jersey multipart webapp with Netbeans but I can't seem to because it seems something's missing my jersey library.
I downloaded the jersey-multipart.jar file, but still that didn't help:
#Path("/file")
public class UploadFileService {
#POST
#Path("/upload")
#Consumes(MediaType.MULTIPART_FORM_DATA)
public Response uploadFile(
#FormDataParam("file") InputStream uploadedInputStream,
#FormDataParam("file") FormDataContentDisposition fileDetail) {
This code is from blog. I'm trying to put it in my webapp, but the #FormDataParam tag and the FormDataContentDisposition class are not recognised. I downloaded the jersey-multipart.jar and that seemed to solve the #FormDataParam tag problem, but not the FormDataContentDisposition class.
I'm using Tomcat 7.0.
How do I go about successfully creating a jersey multipart webapp without any problems? And how come the jersey-multipart jar file isn't included in the jersey library in Netbeans?
Thanks.

Lutz Horn has a point, but for the sake of those using Netbeans 7.4 (Java EE 6) and are still struggling with this issue, here's a step by step on how to create your very own multipart rest web service and deploying on Tomcat, with Netbeans. (Note, deploying on Glassfish requires a slightly different configuration which isn't covered in this answer).
First off, my suggestion is to create a maven web application and not a normal web application. Reason is, the JAX-RS and Jersey libraries that come with Java EE 6 are not sufficient enough, and once you start fiddling around with external jars, things tend to get messy, especially with Jersey. (Hopefully, this has been corrected in Netbeans 8.0 (Java EE 7)).
(1) Create a maven web-app, choose Java EE 6 and Tomcat 7. Once you're done, you'll notice you don't have a web.xml. Most multipart tutorials will tell you to include certain configurations in your web.xml file. Don't bother with that. You don't need a web.xml file.
(2) Create a RESTfull web service by either writing it manually or using the wizard (right click on your maven web-app -- New -- Other -- Web Services -- [choose the RESTful web service you want])
(3) Open your pom.xml (you can find it under the Project Files folder in your maven web-app) and add these dependencies:
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>2.7</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.media</groupId>
<artifactId>jersey-media-multipart</artifactId>
<version>2.7</version>
</dependency>
If you're doing this for the first time, you need an active internet connection, as maven will download the dependencies from its central repository.
(4) Go to your ApplicationConfig class or whatever class that holds that contains your #ApplicationPath(). It should look like this:
#javax.ws.rs.ApplicationPath("webresources")
public class ApplicationConfig extends Application {
#Override
public Set<Class<?>> getClasses() {
Set<Class<?>> resources = new java.util.HashSet<Class<?>>();
resources.add(MultiPartFeature.class);
addRestResourceClasses(resources);
return resources;
}
/**
* Do not modify addRestResourceClasses() method.
* It is automatically populated with
* all resources defined in the project.
* If required, comment out calling this method in getClasses().
*/
private void addRestResourceClasses(Set<Class<?>> resources) {
resources.add(com.mycompany.mavenrestuploader.UploaderResource.class);
}
Note: resources.add(MultiPartFeature.class); That has to be included, otherwise Jersey multipart won't work.
The reason I put that line of code in the getClasses method and not the addRestResourceClasses method is because the addRestResourceClasses method gets modified whenever there's a change to your resource class, and if you include the MultiPartFeature code in there, it will get erased.
Once you've done all these things, you are good to go.
If you're just looking to create a RESTful web service without multipart, follow steps 1 to 3, but in step 3 do not include the jersey-media-multipart dependency.
I hope this helps you ;)

The imports for these two are
import org.glassfish.jersey.media.multipart.FormDataContentDisposition;
import org.glassfish.jersey.media.multipart.FormDataParam;
If you use Maven, add this dependencies:
<dependency>
<groupId>org.glassfish.jersey.media</groupId>
<artifactId>jersey-media-multipart</artifactId>
<version>2.0</version>
<type>jar</type>
</dependency>

Together with jersey-media-multipart dependency, instead of Application (see below) you can configure ResourceConfig:
#ApplicationPath("/")
public class AppConfig extends ResourceConfig {
public AppConfig() {
packages("packages.to.scan");
register(MultiPartFeature.class);
}
}
or Jersey REST configuration in web.xml:
<init-param>
<param-name>jersey.config.server.provider.classnames</param-name>
<param-value>org.glassfish.jersey.media.multipart.MultiPartFeature</param-value>
</init-param>