I have previously asked the question here on stackoverflow on how to get web lookups to work in log4j2 (See log4j2 Web Lookup not working). Eventually, the question was answered and all was fine. Now, when I got it working, the web apps were all Spring 4 based apps using log4j 2.2 jars running on Tomcat 5.0.57 containers.
Now however, we have almost the same setup as before (i.e Spring 4 on Tomcat 5.0.57 containers) with the exception that, the log4j jars have now been updated to log4j v2.5 jars. With log4j v2.5 jars the web lookups are still working when deployed on Windows Tomcat 5.0.57 containers but, NO LONGER on linux Tomcat 5.0.57 containers.
On our linux Tomcat containers the log files are now being created as: ${web:contextPath}.log instead of actually replacing the lookup variable with the deployment's context path name.
What has changed since log4j v2.2 that may cause web lookups to stop working?
Related
My requirement is to dynamically update log levels of 3 different Java web applications deployed on the same wildfly JBoss server. We are using logback core & classic 1.2.3.
I was able to update log level of the current application but I am unable to update log levels of another application deployed on the same server.
Any help in this regard would be appreciated.
At the moment, I'm developing a java web application locally(localhost) on Windows, using Tomcat 8.5 .
Unofortunately, I have no developing enviroment, so I have to do everything locally and then deploy to production via .WAR .
The issue is that the production application server (Linux RedHat) is running on websphere, if I generate the .WAR on tomcat, Will I have any problems to run it on WebSphere? Should I change anything in my code or web xml?
My system does nothing fancy, no hibernate, no spring, just a very classic mvc web application.
Thanks in advance
In general you shouldn't have to make any changes, but there are some differences between the two environments that could cause issues.
IBM provides a tool that will analyze your application and suggest changes that may need to be made. You can find more information here: https://www.ibm.com/developerworks/library/mw-1701-was-migration/index.html
At first i want to say that i'm a beginner in java servers and never deploy an java .war app on server other than localhost in my intellij.
I have a simple only REST app Which work fine in localhost, i also created war file and deploy it by command "asadmin deploy --port 4849 war_name", but when i go into url http://stachurskipiotr4.usermd.net/cookbook-1.0-SNAPSHOT there is an server error.
I completely don't know what it is, i will be grateful for any help.
Access the domain port for that case. Default is 8080 if you haven't configured.
http://stachurskipiotr4.usermd.net:8080/cookbook-1.0-SNAPSHOT
Also, please use or log in your admin console to see the apps if it's deployed. You can also access it directly from there.
Glassfish already provides the Jackson libraries and the version conflicts with the one Spring depends on. Glassfish is an enterprise container, is there a specific need for the enterprise container? Try a regular servlet container like Tomcat instead. If you do want enterprise, maybe you shouldn't need using Spring
EDIT:
Removing jackson jars from your project won't help you; Spring code wants the version it wants. You can try to find out which version Glassfish provides and then see which version of Spring depends on that and use that version of Spring. This is a wrong thing to try as this will be just the tip of the iceberg. Do not try to deploy Spring code in an enterprise container, these are competing specs.
Your options are
1) figure out why is Tomcat not working. Tomcat is a battle-tested servlet container with thousands of production deployments.
2) Try a different servlet container such as Jetty.
3) Rewrite your code to the JEE specification and deploy to an enterprise container such as Glassfish or Wildfly (there are others).
4) Use Spring Boot to embed the container and package your app as an executable jar.
EDIT2:
If you chose Spring Boot, your artifact will be an executable jar, you do not deploy it into a container since the container is embedded. You start the jar via a java command. You remove the container from your deployment entirely. I don't know your deployment environment, but you do not use Glassfish at all at this point, you have to run the java command to start the server.
If Glassfish is a requirement, you have to rewrite your code
This might be duplicate of this and this question.
I have a java application in which i am using JAX-WS (WEB SERVICES). and many other features in it like apache-commons utils.
My application is swing application, that connects to my server code
and uploads and downloads, and sync files with the server. my
database is mysql.
I have compiled my server code and created a .WAR file. i deployed
that .WAR (containing all the required libraries for my server
side application) file on a JBoss server and its working fine.
Now my Management says me to why use JBoss instead of Tomcat, which
easy to manage and setup on a linux server. actualy they have a
linux server which supports tomcat, but not JBoss. so they said to
me to deploy on Tomcat on Linux Server. I installed and configured
tomcat on my windows and deployed a .WAR file. and also created
virtual directory for my resources its working fine[but not tested
completely]
My Application does not have EJB so I think that Tomcat is good enough.
Please suggest me is it fine to use Tomcat instead of JBoss server,
I am worried if it may get problems in the future, or it might not
support features of my application in future or after complete testing.
JBoss uses Tomcat under the hood to host war applications anyway.
Using Tomcat for you war application instead of JBoss should be perfectly fine.
Any commons-jars that you are using can be downloaded from http://commons.apache.org/. Put them in your lib directory and you should be good to go. Most apache commons libraries should allready be included with Tomcat though, you'll have to check.
PS:
JAX-WS is standard in the latest JDK6 updates. If your using a earlier version of the JDK then just download the JAX-WS jars. The standard reference implementation from Oracle/Sun can be downloaded from here http://jax-ws.java.net/
Do you have EJB? JBoss comes with its implementation of the EJB JSR specification.
For Tomcat, you require plugins like openEJB.
Many application servers use Tomcat internally as its Servlet container. But for compliance to JavaEE standards, most would choose a JBoss application server over Tomcat anyday.
Note that JBoss 7 Application Server Web Profile is certified.
Tomcat functions well as a plain vanilla Servlet container. Many enterprises when using Tomcat, couple it with Proxy and HTTPD servers for security and load balancing reasons.
We're experiencing slightly strange webapp deployment behaviour under Tomcat 5.5.27 on Linux (both on CentOS in production and Ubuntu 10.04 for development).
App A and app B are almost identical (exactly the same libraries, a copied Maven project), App B differs only in that its JPA entities are annotated to access a different table within the same schema (the JNDI database references are identical).
When the apps are deployed into either environment, app B will not start. However:
Manually starting the stalled app, from the Tomcat admin console, works fine (???).
After any attempt to restart Tomcat, the alphabetically later app fails to start. Point #1 still remains valid (???)
Logging is configured (log4j), however, we get nothing from [the yet-to-start] app B's logging, nor errors from Tomcat's 'catalina.out' log file (NB. logging is working once the apps are up and running).
I've done a reasonably thorough search for information (Apache/Tomcat bugzilla, Google) but I've found nothing of real use. Other posts have sighted the use of the antijarlocking and antiresourcelocking attributes on the server's 'context.xml' 'Context' node, but there is also a suggestion that this is unecessary/inaffective under Linux (hasn't appeared to work here, either).
Any ideas?
Cheers
Rich
P.S. Upgrading from Tomcat 5.5.x isn't an option, currently (IT support etc.).
There is a similar behavior to spring applications on tomcat. -- They require that the webAppRootKey is unique for each application. -- If not the applications behave like you described, so in case of Spring apps, make sure that App-A has an other webAppRootKey then App-B.
<context-param>
<param-name>webAppRootKey</param-name>
<param-value>myRootKey</param-value>
</context-param>
#See http://groups.google.com/group/riotfamily/browse_thread/thread/9a0edf69575d3ab6?pli=1