Tomcat Context Root - Tiles Exception when deploy a Spring app to Tomcat - spring

I have a Spring MVC 4 application deployed in tomcat. It works fine. I have to clone this app to have several applications with same behaviour but different configurations: database instance and folders for file management. Each for different customers. When I deploy de original application to Linux Tomcat it works fine (https://hostname:8443/app1).
Then I change the db connection settings (database name, username, and folders to manage some generated files) and change the name of the artefact to customername. But when I get into the application, it shows the login page right, but when login into the app, I'm getting the following error:
Status HTTP 500 - Request processing failed; nested exception is org.apache.tiles.request.render.CannotRenderException: java.io.IOException: JSPException including path '/WEB-INF/layout/header.jsp'
javax.servlet.ServletException: File [/WEB-INF/layout/header.jsp] not found
when accessing to https://hostname:8443/customername, which it's part of tiles template. Files exist in the deployed application, It's able to reach the login page, so it seems to be resolved the tiles config, but I don't know why is not able to reach the jsp files. It's working fine in local windows without secure Tomcat (port 8080).
EDITED
If I change the name of customername.war to app1.war it's working fine. Anybody knows where the war file keep a reference to the base application app1? It seems that there a reference to app1 in somewhere that makes that If I change the application name (artifact id) it does not reference to customername path.
Seems that it's a context root issue. I have changed it in STS (Project > Properties > Web Project Settings > Context root), deployed on Tomcat but still not working. It's supposed that only with changing the war file name, the context root of the application should be updated, but it's not working.

Upgrading Tomcat from 8.0 to 8.5.5 solves the issue. I don't know why, but there's an issue in 8.0 because no way to force context root for an application, not context.xml application file neither other configuration.
Just upgrade to 8.5.5 and deploy applications without context issue.
BR

Related

Multiple web applications in one tomcat instance start with a properties file from another applications

We have multiple web applications in one tomcat instance on 1 server, all running a spring-boot application inside.
Whenever we start tomcat and it starts to boot up all the spring-boot applications we mostly see that each application might use property files/settings from another application.
What especially happens is that we see it sometimes use the database information from other applications being used, resulting in a database which holds tables from other applications. This is scary since we might start a database migration or something.
We also see that the logs are written to the wrong project log file.
We define these settings using a application.properties like (or sometimes application-test.properties or application-secret.properties):
spring.datasource.username
spring.datasource.password
logging.file.name
Anyone have an idea why this is happening?
We found 2 possible causes for this behavior:
if Tomcat is started in a directory where application property files are present, or where application property files are placed in a /config subdirectory, like a WEB-INF/classes directory, these application property files are used by every Spring Boot application deployed in the tomcat instance. To fix this, make sure the Tomcat start script changes the working directory to a directory not containing application property files.
if the 'startStopThreads' attribute of the Tomcat Engine element in server.xml is set to values higher than 1, Spring Boot applications seem to occasionally and randomly use application property files of other Spring Boot applications deployed in the Tomcat instance. When 'startStopThreads' is set to 1, we don't see this behavior.

Can't access static file from Spring Boot application running in Tomcat servlet

All I want to do is access a specific file in a Java class. I am using Spring Boot 2.0.0.M7. When I run from my development machine using mvn spring-boot:run then everything works well. In that case I am using:
File jFile = new File("src/main/resources/static/folder/fileName.txt");
When I deploy this to a Tomcat server (8.5) as a war, the file is put into:
WEB-INF/classes/static/folder/fileName.txt
I've tried everything I could find or think of, but always get an error of some sort, usually a file not found exception.
My most recent attempt was:
URL url = this.getClass().getClassLoader().getResource("fileName.txt");
File jFile = new File(url.getPath());
That produces a null pointer exception with url.getPath().
I have read about needing to access the servlet config, but couldn't ever understand that well enough to get it to work. Does anyone have a clear example so that I can access the file both from the development context and the production context? Thanks!

How to run JAX-RS in Maven project of JAVA EE?

This is what I did on NetBeans.
New Project -> Maven -> Web Application
and gave my project name
And, created new RESTFUL Web services from patterns
selected Simple Root Resource
Assigned path "foo"
and hit finish
And now, I tried to access it from browser as
localhost:8084/context/webresources/foo
And, it shows 404 resources not found error.
I checked if it works with non-maven based projects, and it does. Accessing the resource was possible on those but, not on maven based.
I must have missed something.
I also tried to see if it is accessible from netbeans by doing right-click on the RESTful Web Services and clicking TestResource Uri,
It shows error
Unable to open resource url.
the uri of the rest location
Make sure project has been deployed successfully and the server is running.
While both have been done!!

WAS Liberty not serving images, css, js

I have an application which is working fine on Websphere server (as war and Eclipse Project).
Direct deploy on Liberty through WAR is also working fine.
I was trying to deploy it on WAS Liberty through Eclipse project. There are no console errors but once the application loads, none of the following files are getting loaded in the web page: js, gif, css
Because of this the page is looking distorted and most of the functionality is lost.
Surprisingly there are some JSPs in the js folder and these are getting loaded, so looks like the folders are published properly. But for all the mentioned files (js etc), I get following error in the browser console: 500 (Internal Server Error) .
There are no errors and the server log is also clean.
My setup: WAS Liberty 8.5, RHEL 6.5. Eclipse Luna, WDT 8.5.5.2. Project having Eclipse structure, not maven.
I have tried both loose config and 'from workspace' settings
Edit1: I noticed that Spring beans are not getting initialized properly. Getting null pointer on applicationContext.getBean.
OK, found the problem.
As I guessed this was related to spring initialization, though the problem was more code related.
Due to wrong implementation of REST implementation, where the base path was set as root application path (“/”), rest API classes were getting instantiated on application load and were then making calls to code which was instantiating few Spring beans.
But at this point the Spring listeners had not fired, hence the appcontext was empty. Some of the base application object were getting initialized with empty beans and hence spring security context and related classes were failing to serve the application content properly. (Problem is spring related code is created by another team and we just get the jar, hence I am not even able to debug it properly, so I don't know where it was failing exactly)
The thing that makes it Liberty specific is: The same problematic code is working fine on Websphere full profile and Weblogic and even on Liberty if we deploy as WAR. Not sure what classloading difference is causing difference in behaviour.
Thanks to all who took time and efforts for replying.
I am facing the same issue using open liberty and Eclipse Krazo when the base path is
application path (“/”)
so i have changed the path as shown below
package io.openliberty.sample;
import javax.ws.rs.ApplicationPath;
import javax.ws.rs.core.Application;
#ApplicationPath("")
public class ConfigApplication extends Application {
}
Now the CSS and imgs are loading with no issues.

Why do I get "HTTP Status 503 - This application is not currently available" in tomcat 6?

I have an application written with Struts2 and Spring for DI and I'm using Tomcat 6 as container. Assuming I have packaged the application as my-application.war after deployment on Tomcat I can access it through http://my-host/my-application.
When I delete the .war file, Tomcat's supposed to undeploy the application and according to here When I try the http://my-host/my-application I should get:
HTTP Status 404
but instead I get:
HTTP Status 503 - This application is not currently available
When I redeploy the application to same context path I get a weird exception:
Unable to instantiate Action, [ActionClass], defined for '' in
namespace '/' Failed to convert value of type [MyClass] to required type
[MyClass] for property 'myClass': no matching editors or conversion strategy
found
in which ActionClass has a property myClass of type MyClass which is injected by Spring and by default is a singleton. It's weird because type of both objects is the same. I suspect the application don't get undeployed completely in the first place cause when I restart Tomcat the scenario will be repeated. I would appreciate any help on finding the possible cause of this.
Well I think I found the answer. As I guessed the problem was with the improper undeployment.
It seems that deploying and undeploying an application without restarting the tomcat is a tricky business. When you deploy your application Tomcat classloader loads the classes in of the application and once they're loaded it seems they won't be unloaded with undeployment. And constantly deploying and undeploying an application will cause a serious memory leak. This case is specially true with singletons since the remained version of object in JVM doesn't match the newly deployed class. Hence the error I got above.
The safe path seems to be restarting Tomcat each time you redeploy any application.
Sources helped me find these information:
What makes hot deployment a "hard problem"?
Tomcat: hot deploying new jars
This post on CodeRanch
And some more sources found on Google

Resources