I downloaded a couple of webapps and placed them in my /webapps folder.
Some of them I could open by going to http://localhost:8080/app1 and it would open.
However, some others I would do the exact same thing and go to http://localhost:8080/app2 and it will display "HTTP Status 404 - /app2/", even though I am sure it is there. I've checked that it contains a WEB-INF folder just like app1, and I've even restarted Tomcat to be sure.
My question is: is there anything (perhaps in the web.xml file) that specifies what the URL has to be to start the webapp? Or is it simply just http://localhost:8080/<folder name> ?
P.S. If you want to know exactly what app1 and app2 I am refering to:
app1 (works) = http://assets.devx.com/sourcecode/11237.zip
app2 (doesn't work) = http://www.laliluna.de/download/eclipse-spring-jdbc-tutorial.zip
I've tried a few others as well, some work, some don't. I'm just wondering if I'm missing something.
I usually debug this by going the the manager page and making sure that all of the contexts are deployed (http://localhost:8080/manager/html).
It sounds like app2 has not been deployed properly or is not starting up because of some other error.
I would look at the logs. There may be a bunch of information in there but usually it explains what is broken.
The second app (the directory named WebRoot) can also be deployed correctly but you get a 404 by going to it because there is not an "index.jsp" or "index.html" file in the root directory.
Try putting a file there with any of those names, and the 404 is gone.
A servlet mapping in the web.xml is not strictly necessary for this to work.
The first zip file you mention has a .war file as part of the zip. The second one is just the source code and it needs to be built into a .war file.
It looks like it is setup to have that done in Eclipse. Try the File>>Export option and select War file as the export type.
The second requires the spring framework. The only runnable things I could find were a client in eclipse-spring-jdbc-tutorial.zip\SpringJdbc\src\test\de\laliluna\library\TestClient.java and one in eclipse-spring-jdbc-tutorial.zip\SpringJdbc\src\de\laliluna\library\sample\MyApplication.java. If you open it in eclipse (it is an eclipse project), and compile, provided the Spring framework is installed, you should be able to run both.
Are you familiar with log4j? Spring puts a lot of often-useful information into the logs created via log4j. When I have a SpringMVC application that won't startup correctly or otherwise isn't running I check my log4j and potentially turn up the Spring log level to INFO or even DEBUG.
If "/" is not accessible it means that there is no "index.html", "index.jsp" or whatever is defined in the welcome-files list of the web.xml
Also no Servlet-Mapping for the context ROOT directory is present.
Check the web.xml for Servlet-Mappings or try to figure out the name of the jsp/html /... file being in the context root
Related
I know many similar questions have already been asked (ex. this, this, etc.), but none of them could help me, so I decided to bring it up again - been struggling for hours and I've really run out of ideas.
I have a Java EE project, whith simple servlet that accepts data from HTML form, performs a few queries in external services (with REST and JAX-RS) and returns results. My goal now is to deploy it on standalone Tomcat server. The way I'm trying to achieve it is by exporting WAR artifact and copying it to Tomcat's webapps directory.
It works up to the moment of sending REST request with JAX-RS - then I always get the error:
WELD-ENV-000016: Missing beans.xml file in META-INF
I'm not using this file at all, but as I read, it must be there, even if empty... so I've tried to put it at any location I could think of/read about, including:
/web/META-INF
/web/WEB-INF
/src/main/webapp/META-INF
/src/main/webapp/WEB-INF
/src/main/resources/META-INF
/src/main/resources/WEB-INF
When I check the output .war file or directories created by Tomcat after deployment, beans.xml is present in both META-INF and WEB-INF directories.
Initializing Weld and performing those queries works well in unit tests inside Intellij IDE - the only requirement here was to mark directory containing WEB-INF and META-INF as "Resources Root".
In my facet configuration, I mark directory containing WEB-INF and META-INF as "Web Resource Directory", and *'Web' facet resources' is included in my artifact.
Any ideas? Am I fundamentally misunderstanding something, does this inner Weld here require different, separate META-INF or something?
As nobody answered, I'll at least share my conclusion - the simplest way is to switch to TomEE (if that is acceptable).
I have a simple hello world java application I deployed, and in the new code I changed the output of the servlet to print some statements in a loop.
It works fine locally.
I uploaded the new .war file, stopped tomcat, deleted the old .war file in /webapps and the exploded folder.
Then I copied the new .war file, and then restarted tomcat.
It exploded the folder, but somehow the code is old.
Could it be caching the .war file somehow?
I did change server.xml and set autodeploy=false but not sure if that is relevant?
delete the work directory and restart tomcat.
Bit too terse sorry.
Tomcat will turn jsp into servlet source before compiling, some caching takes place in the work directory this may be what is causing it to happen.
It has been some time since I used Tomcat but I am fairly sure the structure was something like work/host/engine/context so you will probably find your stuff under work/localhost/Catalina/--web context--
I did change server.xml and set autodeploy=false but not sure if that
is relevant?
oO.
From the docs
This flag value indicates if new web applications, dropped in to the
appBase directory while Tomcat is running, should be automatically
deployed. The flag's value defaults to true. See Automatic Application
Deployment for more information.
I'd start there.
I am using weblogic 10.3.4, I am trying to write log with log4j. but at runtime my application is not getting any log4j.properties. even this is not generating any warning as "initialization of log4j has error".
I have tried my properties file to put in src folder, classes folder and then I created one jar and put it in domain lib. still its not picking. even when I am writing log with same jar in standalone application, its working fine.
please help me with valuable suggestions.
I tried the solution proposed at Oracle forums.
Excerpt from that link at Oracle forums:
I've only modified the scritp startWebLogic.cmd:
set LOG4J_CONFIG_FILE=log4j.xml
set SAVE_JAVA_OPTIONS=%JAVA_OPTIONS% -Dlog4j.configuration=%LOG4J_CONFIG_FILE%
#REM set SAVE_CLASSPATH=%CLASSPATH%
set SAVE_CLASSPATH=%CLASSPATH%;C:\Oracle\Middleware\user_projects\domains\domain\config
In this way I've put all the config folder inside the classpath, and I can use it in future to hold other libraries configuration files (for example oracle coherence config).
I tried this approach on a different properties file as well and that worked well!
You need to either specify where the application should find its log4j.properties, or put it onto the classpath of the application. Where the classpath is varies, but in general WEB-INF/classes should work. Other options depend upon how you're deploying the application.
A better long term strategy is to configure your system so that you can change the log4j.properties depending upon the environment. When you're in production, you won't want all of the debug information to appear. Look at the answer to this question or this question for more ideas. One strategy is to define a variable on the command line which gets picked up and defines a directory which contains your configuration files. This works for Tomcat, but there may be other, better, strategies for Weblogic.
It is not a good idea to change the configuration of your server, in particular, don't replace the log4j.jar or log4j.properties in your server directories. The server will depend upon the version that it was designed to use, which may or may not be the same as your version. You can do everything you need to do by changing the war that you're deploying.
I have used this code:
ClassLoader cl = this.getClass().getClassLoader();
URL log4jCfg = cl.getResource(configFile);
if (log4jCfg != null) {
DOMConfigurator.configure(log4jCfg);
}
log.info("log4j is now working on Web App.");
In my case, we used XML configuration:
log4jCfg = "mylog4j.xml";
In WebLogic, we were able to place such file (mylog4j.xml), equivalent to your log4j.properties file, at WebLogic's domain path (specific to the domain were we deploy). This means that domain folder belongs to your application's path. I just tested it with Web applications, I'm not sure if with SOA or EJB projects it works the same way.
When you deploy any application on any server that application should use servers log4j jar.
So if you have added any log4j jar in your application jar/tar/ear, remove it and copy log4j.properties file in the conf folder of the server from where server is picking its configuration files. Or just copy your log4j property content in servers log4j property file.
i use tomcat 6 for production. i have a web app deployed on this server called: app.war
it has a url : test.org.
every time when i undeploy app.war and redeploy it this path won't work any more
http://test.org/home
but this url always work: http://test.org/app/home.
to make the first url work, i need to restart the tomcat server.
i wonder why when i redeploy the app.war the url http://test.org/home does not work.
if there a way to make it always work without restarting the server?
i don't want the application name to be included in the url
Thanks
This has no simple answer, as there are many components involved. You should isolate the problem. For instance, you could start removing test.org domain mapping, ensuring that there's no component possibly caching the output and so on.
And then after you had isolated Tomcat from anything else, if the problem persist, you could state that this is a Tomcat problem.
So please (pleeeeeeease) refine your question when you have done a couple of these steps so the SO community can help you.
Sorry for the long response.
Check out your app.xml in ${TOMCAT_HOME}/conf/Catalina/localhost . Whe you try to redeploy this file might get deleted and gets recreated causing you the problem.
In your war file try creating a folder META-INF at the top level (in the same directory as WEB-INF) and creating a file context.xml in the META-INF folder. In context.xml put this:
<Context path="" reloadable="true">
</Context>
See if that works for you.
When I put a new war file in the webapps directory and restart tomcat, my war file is exploded but the servlets are not available and their respective log files are not created in the logs directory. When I bounce tomcat again, then the servlets are available and the log files are created. I'm assuming I have setting(s) not correct within tomcat, but I'm not sure where to start.
Does anyone know the cause of my current situation? Or even what parameters to review?
New Additional/Comments: Our setup allows us to have our app 'myApp' be the default application that is seen at root of our URL. On the first starting of tomcat, I can get to myApp by going to /myApp/index.html - whereas on the second start of tomcat I can then just goto and myApp/index.html is displayed.
My welcome file list is the 'myApp/index.html'
I had a similar problem with Tomcat 6.0.26. I worked around it by deleting the exploded webapps before copying the new war file to the webapps directory. Maybe a little kludgy, but it solved my problem.
http://tomcat.apache.org/tomcat-6.0-doc/config/context.html
antiJARLocking
If true, the Tomcat classloader will take extra measures to avoid JAR file locking when resources are accessed inside JARs through URLs. This will impact startup time of applications, but could prove to be useful on platforms or configurations where file locking can occur. If not specified, the default value is false.
have you set unpackWars and autoDeploy params to true in your server.xml file?
Try to do unpackwars=false and always make sure tomat is not running when you do deployment try to avoid hot deployment...