I developed one web applications using struts. Now when i tried to run in another machine I am getting the following error. Following is taken from glassfish server log
SEVERE: INFO [http-thread-pool-8080-(1)] (CommonsLogger.java:31) - Parsing configuration file [struts-default.xml]
SEVERE: INFO [http-thread-pool-8080-(1)] (CommonsLogger.java:31) - Unable to locate configuration files of the name struts-plugin.xml, skipping
SEVERE: INFO [http-thread-pool-8080-(1)] (CommonsLogger.java:31) - Parsing configuration file [struts-plugin.xml]
SEVERE: INFO [http-thread-pool-8080-(1)] (CommonsLogger.java:31) - Parsing configuration file [struts.xml]
SEVERE: INFO [http-thread-pool-8080-(1)] (CommonsLogger.java:31) - Loading global messages from ApplicationResources
Also in the browser I am getting java.lang.reflect.InvocationTargetExceptionthis message. Please tell me where the problem lies.
This seems to be a similar problem to what is described in this article:
http://www.java.net/node/705006
It appears to be a GlassFish bug to incorrectly put "SEVERE:" before the log message that actually starts with "INFO".
FYI I came across this with SL4J and Glassfish 3.1. The exact same code logging via the JUL logger works perfectly, and then you get the "SEVERE:" when you swap it out with a proper logger.
Sadly I have not been able to find a resolution, and will post it when I find it. It is equally possible that they re-fix the bug in the next version of GlassFish.
Related
Trying to deploy Midpoint OpenSource IDM software on Windows server
Runing JAVA 9.0.1 and Tomcat Apache 8.5
Deployment of the WAR file seems to succeed but application does not start
On Tomcat Web Application Manager I get the error:
FAIL - Application at context path [/midpoint] could not be started
In the Catalina logs all I can see is:
SEVERE [http-nio-8080-exec-38] org.apache.catalina.core.StandardContext.startInternal One or more listeners failed to start. Full details will be found in the appropriate container log file
SEVERE [http-nio-8080-exec-38] org.apache.catalina.core.StandardContext.startInternal Context [/midpoint] startup failed due to previous errors
I am trying to migrate from Tomcat 8.0.37 to 8.5.6
In this new version, the err console is flooded constantly with these warnings:
oct. 27, 2016 3:16:40 PM org.apache.catalina.webresources.Cache getResource
WARNING: Unable to add the resource at [/WEB-INF/lib/something.jar]
to the cache because there was insufficient free space available after evicting expired cache entries -
consider increasing the maximum size of the cache
I want to configure the servlet (web.xml or Spring) to ignore caching for some file types (*.jar)
I've read about configuring the context.xml file but it feels like a workaround the real issue.
how can I tell Tomcat to log everything to slf4j?
I added this to the manifest but it doesn't work :
Dependencies: org.slf4j
The cache warnings are caused by a known bug in 8.5.6 that will be fixed in 8.5.7. The new version should be available in a week or so.
If you want to use slf4j then following the slf4j instructions for redirecting java.util.logging output.
My application context is defined as an XML file located in my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml.
<Context docBase='/my/path/to/myApp/myAppWarFile.war'>
<Environment name='my_config_dir' value='/my/path/to/myApp' type='java.lang.String'/>
</Context>
/my/path/to/myApp contains the WAR file myAppWarFile.war and a number of externalized properties that are read by Spring.
Tomcat is configured with autoDeploy turned off. When I start Tomcat, it creates my/path/to/Tomcat/conf/webapps/my-app/ and the WAR file gets unpacked into this location as expected, and the application of course can run as expected.
When I want to deploy a new version without restarting Tomcat, I run the undeploy command as follows:
curl http://localhost:8080/manager/text/undeploy?path=/my-app --user my-username:my-password
... and that works. But when I instruct Tomcat to deploy with the following curl statement, I get a failure.
curl http://localhost:8080/manager/text/deploy?config=file:/my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml --user my-username:my-password
# Tomcat response
FAIL - Invalid context path null was specified
Adding the path does not help much, I still get a failure.
curl http://localhost:8080/manager/text/deploy?config=file:/my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml\&path=/my-app --user my-username:my-password
# Tomcat response
FAIL - Failed to deploy application at context path /my-app
The worst part is that tailing catalina.out does not yield any insight. And on top of that, Tomcat deletes the application context XML file my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml!
Naturally I have reviewed Tomcat documentation (https://tomcat.apache.org/tomcat-8.0-doc/manager-howto.html#Deploy_using_a_Context_configuration_%22.xml%22_file) and I have googled all day to figure this out, but I have not found anything that can help me with this particular configuration.
It feels as though the choice is:
Tomcat with autoDeploy on (not recommended for production) in which case simply dropping the new WAR to /my/path/to/myApp/ will cause Tomcat to hot deploy the app.
Tomcat with autoDeploy off, but re-deploying requires a Tomcat restart because the deploy API does not seem to be working as advertised.
Has anybody made this work with this configuration?
EDIT:
I turned up the logging on Catalina. When I run the first deploy command without the path, I get this set of log entries:
FINE: Start processing with input [config=file:/my/apth/to/tomcat/conf/Catalina/localhost/my-app.xml]
Oct 13, 2015 10:04:53 AM org.apache.coyote.AbstractProtocol$AbstractConnectionHandler process
FINE: Socket: [org.apache.tomcat.util.net.SocketWrapper#189651c1:Socket[addr=/0:0:0:0:0:0:0:1,port=45415,localport=8080]], Status in: [OPEN_READ], State out: [OPEN]
Oct 13, 2015 10:04:53 AM org.apache.coyote.http11.AbstractHttp11Processor process
FINE: Error parsing HTTP request header
java.io.EOFException: Unexpected EOF read on the socket
at org.apache.coyote.http11.Http11Processor.setRequestLineReadTimeout(Http11Processor.java:168)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:982)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:744)
Oct 13, 2015 10:04:53 AM org.apache.coyote.AbstractProtocol$AbstractConnectionHandler process
FINE: Socket: [org.apache.tomcat.util.net.SocketWrapper#189651c1:Socket[addr=/0:0:0:0:0:0:0:1,port=45415,localport=8080]], Status in: [OPEN_READ], State out: [CLOSED]
Oct 13, 2015 10:04:53 AM org.apache.tomcat.util.threads.LimitLatch countDown
FINE: Counting down[http-bio-8080-exec-16] latch=1
Have you tried:
curl --upload-file /my/path/to/my-app.war http://localhost:8080/manager/text/deploy?path=/my-app --user my-username:my-password
I was trying to deploy a war file via tomcat manager 6. Once deployed get always the same
error :
FAIL - Application at context path /App could not be started
The war file is under apache-tomcat-6.0.0/webapps folder.
I was googling and tried different options like :
removing apache-tomcat-6.0.0/work/Catalina/localhost folder and also apache-tomcat-6.0.0/webapps/App
restarting the server and redeploying again.
As I could see in the catalinalog file :
INFO: Deploying web application archive App.war
3:32:47 PM org.apache.catalina.core.StandardContext start
SEVERE: Error listenerStart
2012 3:32:47 PM org.apache.catalina.core.StandardContext start
SEVERE: Context [/App] startup failed due to previous errors
2012 3:32:50 PM org.apache.catalina.core.StandardContext start
SEVERE: Error listenerStart
2012 3:32:50 PM org.apache.catalina.core.StandardContext start
SEVERE: Context [/App] startup failed due to previous errors
Any ideas ?
Add a “log4j.properties” file under ‘/WEB-INF/classes’ directory inside your WAR to help debug which one of the listeners is throwing this error.
This holds true for Tomcat versions < 6.0
In Tomcat 6 or above, the default logger is the”java.util.logging” logger and not Log4J. So if you are trying to add a “log4j.properties” file – this will NOT work. The Java utils logger looks for a file called “logging.properties” as stated here:
http://tomcat.apache.org/tomcat-6.0-doc/logging.html
So to get to the debugging details create a “logging.properties” file under your”/WEB-INF/classes” folder of your WAR and you’re all set.
And now when you restart your Tomcat, you will see all of your debugging in it’s full glory!!!
Sample logging.properties file:
org.apache.catalina.core.ContainerBase.[Catalina].level = INFO
org.apache.catalina.core.ContainerBase.[Catalina].handlers = java.util.logging.ConsoleHandler
and you will most likely see a “ClassNotFound” exception.
Consider the following output from a Tomcat server under Eclipse:
INFO: Initializing Coyote HTTP/1.1 on http-8080
INFO: Initialization processed in 634 ms
INFO: Starting service Catalina
INFO: Starting Servlet Engine: Apache Tomcat/6.0.20
SEVERE: Error listenerStart
SEVERE: Context [/MyServlet] startup failed due to previous errors
I would like to figure out what exception caused "Error listenerStart", but Spring seems to be preventing me from finding the error via Eclipse. I'd love to start Catalina manually, but that doesn't seem to do anything.
What's the best way to find the hidden exception? I'm not afraid to use torture methods.
In my case, the answer was:
Debug java.util.logging.SimpleLogger to find out what exceptions were being hidden.
Figure out that my logging.properties file, cut-and-pasted from the Tomcat docs, was bunk. Several exceptions were going into black holes in log files (maybe they weren't flushed)? Switching everything to a single ConsoleLogger enabled me to see all exceptions.
Make sure that -Djava.util.logging.config.file="/<path>/logging.properties" was present in my Run Configuration.
Try to configure logger (Log4j for example) and log errors to console.
Check tomcat's logs directory, see if it logged to an alternate log file.