We have been using tomcat 7.0.19 successfully in embedded mode. However recently due to some fixes in our area of concern we decided to move to tomcat 7.0.32. Most things work as expected with same code and newer version, however the war deployment for some reason has'nt worked well. I have a couple of servlets registered with my tomcat. Facing below 2 issues,
Has something changed from 7.0.19 to 7.0.32 from embedded tomcat behavior. To detail this out let me explain the behavior difference, with 7.0.19, i could deploy my application and when i hit the "host:port/contextpath" it loaded the applications start page (i.e. welcome page, this page is UI centric and does not need a server intervention, so none of my servlets get called). However with 7.0.32 the same url results in my servlet being called.
So to debug the problem, i commented most of my code so that i have a vanilla tomcat implementation, just the very basic stuff, i.e. setting the engine name, default host, setting host properties, adding a connector (nio, with default properties) and deploying a war. No servlets and other things, just to check if the very basic stuff works. To my surprise when i ran this code it still failed with the same problem within my servlet, how did that happen, now that my code is commented it does not register any servlets, still where does it find it from? Does embedded tomcat store some old references, which are not getting cleaned on subsequent runs? I tried changing the port, but that too didn't help.
I am hitting the wall here, not able to understand this wierd behavior, if i figure out #2, only then can i make some progress on #1.
Thanks in advance,
Vikram
Figured out what the problems were.
In reverse order,
2 - This actually was a weird behavior with the vanilla embedded tomcat code too invoking the servlets which never were registered in the first place. The problem here was with eclipse, for some reason it picked up the old reference of my class. The moment i ran the same code from outside of eclipse i.e. via command prompt, things were back to normal.
1 - This problem was related to web deployment, in my code i was additionally setting my classloader into WebappLoader and eventually adding my application jars into it. This for whatever reasons worked fine with 7.0.19, however did not with 7.0.32, the moment i externalized all my jars to be loaded during application startup via classpath this problem too was resolved.
Thanks,
Vicky
Related
I'm hoping someone can help me figure this one out:
I have two projects on my Eclipse (Spring Tool Suite 3 to be exact) setup:
Our own project with our source code.
Another project from a provider, which our project references as a dependency.
We execute the application locally using a Tomcat v8.5 server.
It was all working fine until recently, when I performed a git pull to update my local code and messed up everything (I'm not sure if I changed something else).
Now, when I try to execute the application, I get the following error (everything compiles and builds correctly):
java.lang.IllegalArgumentException: The servlets named [A] and [A] are both mapped to the url-pattern [/XXXX] which is not permitted.
I didn't make a typo. The error message mentions the same servlet twice, treating it as if it was two different servlets that use the same url-pattern.
Searching for the servlet, I can only find it in a JAR that's downloaded into the local .m2 repository.
I mean, this isn't our servlet, it comes from the provider libraries.
I've seen the other answers to this problem, but those don't work here because:
1) I don't have two servlets steping on each other. There's only one.
2) I can't check if the servlet is defined on the web.xml and on an anotation because it's not ours, but it works for my colleagues so it should be correct.
3) As mentioned before, this servlet is loaded from a dependency, so I can't even try to change anything to try an understand what's happening.
Do you have any idea of what I may have wrong on my setup?
It works correctly for my colleagues, so it isn't a problem with the code.
I've deleted and setup everything from scratch (except deleting the Tomcat server); cleaned and updated the project several times, but I can't get rid of this.
My last attempt was purging and updating the local .m2 repository, but that didn't work either.
Any tips or ideas are much welcomed.
I think you are declaring the servlet mapping both in web.xml and in an annotation, if i remember correctly some tomcat versions allow that.
You said it works for your collegues, check if you all have the same tomcat version.
I am having trouble with an installation of Wildfly 9. Before now, everything has been fine and running smoothly. I've since made one small change to standalone.xml (turned up logging level to TRACE for one of the deployed packages, that's it).
Wildfly is running as a service.
Here's what's happening:
Made change to standalone.xml
Restarted the service
Noticed that none of my jars are deploying even though the deployment scanner is on
Create .dodeploy files to deploy the jars
Every single one fails
Change to standalone.xml is reverted, despite clearing the cache
So, I then try to deploy just ojdbc7.jar. This is the error message I am getting:
"{\"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available.\" => {
\"Services that were unable to start:\" => [\"jboss.deployment.unit.\\\"ojdbc7.jar\\\".PARSE\"],
\"Services that may be the cause:\" => [
\"jboss.jdbc-driver.ojdbc7_jar\",
\"jboss.remoting.remotingConnectorInfoService.http-remoting-connector\"
]}}"
At first, I thought I may have something else listening on port 8080. I checked, and I definitely don't. I don't really know what else this problem could be.
I am also at a complete loss to explain how my standalone.xml change is not being picked up. It seems like it's cached somewhere and I just don't know where. I have cleared the cache and it just keeps coming back.
Apologies if this seems a little vague - if anyone needs any clarification or more information I'll be happy to oblige.
I have several webapps deployed to production. I have used Tomcat as my servlet engine for ~10 years now. I'm considering moving to embedding Jetty model from the deploy-a-war-into-Tomcat model.
These webapps are deployed over several servers and some of the are horizontally scaled (using nginx IP hash based partitioning).
I see some advantages:
I can configure my servlet engine for a particular webapp (instead of having a generic configuration for Tomcat which is running several different webapps)
It's easier to horizontally scale my webapp by running multiple Jetty instances (configured to listen on different ports) on the same host. I could also do this with Tomcat (and I have run multiple tomcat instance on the same host in the past), but I've moved to using Debian packages (.deb archives) for deployment and it's not as easy to run multiple Tomcats using this method.
My deployment package (.deb) is more "complete" at build time i.e. I don't have to be sure the Tomcat instance is configured correctly.
And disadvantages:
More instances of a servlet engine running on a server means more resources being used
I've never used Jetty. I don't think I have any Tomcat-specific stuff going on in my webapps, but I'm not sure.
My main concern is the amount of resources that Jetty will use. If I had one Tomcat instance running 4 webapps, what will the difference in resources (memory/processor) be with four Jetty instances running?
This question is probably too open-ended, but I'm curious to know if I'm overlooking something or if anybody has any experience moving from Tomcat to (embedded) Jetty.
The web container I've found easiest to embed in a jar file (and it is still a valid WAR too) is Winstone (http://winstone.sourceforge.net/).
Jenkins - http://jenkins-ci.org/ - use this container so it has been pretty stress-tested. Note that it is Servlet 2.4 only.
Well I think there is no direct answer;
I might not fully understand the ".deb" part as I'm not a debian freak :)
I prefer having an instance of tomcat with a number of configurations aka CATALINA_HOME folders where you may specify apps and ports running, so you can always have all your configs separately and change the tomcat instance if needed.
Also, see related post:
Jetty: To embed or not to embed?
I also was used to Tomcat, so in my new project I tried using Jetty to learn about it.
In an enterprise environment (where you have production / testing / development servers) I would stick to Tomcat, mainly because it helps you in getting to separate code from configuration files (now I am working in setting the conf files in a separate jar, because that way when I move changes from testing to production they do not have to manually update the jars that I'll pass to sysadmin).
Other issue is that it looks like that Jetty has changed ownership not so long ago, and looking for info often got me to the old version.
Apart from that, using Jetty is not that different from Tomcat; had to run a little through docs for finding where everything is, but structure is (as last what I have seen, I have not tried anything too complicated) more or less like Tomcat.
Environment: WinXP.
RAD: Version: 7.5.3 (Eclipse 3.4.2)
Websphere 6.1
I have two web projects on my local RAD environment and 4 or 5 sub jar projects. When I change classes in debug and regular start mode, the files don't get copied to the server for runtime.
So, normally I have to restart the server completely or add/remove the project all together.
I may make a change to Servlet.java
When I do "publish", the ear/application seems to restart, but my changes are not there. So I normally restart the server. This is a productivity killer.
Additional settings:
* Publish automatically turned off.
* Minimize resources. Use workspace.
What can I do to make sure that the classes get copied over.
My theories:
I have parent_first/application for the class loader/war settings. Is that an issue?
Maybe I should remove the ear and add it back to websphere
I did a clean on the server?
Delete your application from the server.
Restart the server
Go to the admin console and ensure the application is not listed in the list of applications, if it is then delete it.
Restart the server
Deploy/publish again.
Unfortunatelly, RAD with WebSphere are very unstable environment.
From my experience, debug mode is causing a lot of problems. It's mainly what you describe, changes not being seen after republish, additionally very quick memory depletion. I'm using debug mode as last report.
In normal mode everything should (read: in most cases) work correctly. You add/change some classes and make 'republish'. Sometimes it's necessary to do clean on project before republishing it.
But when the Websphere is running longer together with RAD, I observe that often something get stuck. You have there clean option on the server, with is expected to clean the cache (which included also compiled classes). You should also observe memory usage. If it's nearing the limits of JVM (memory leaks are heavy) Websphere stops to function correctly, and you must restart it.
However, I sometimes get serious issues where the clean isn't helping, and then it's necessary to remove all applications, stop the websphere (close all projects and open then again) and then start Websphere and add all applications, restarting RAD in the meanwhile. But it's not everyday, maybe every month or so...
If you are really unlucky, RAD can break your workspace, which will force you to delete all project, delete project files (or do a fresh checkout) and import everything once again, or even start a new workspace (happens also with 'normal' Eclipse, ~1-2 years).
You are using the latest RAD so do I... here is my guide for solving this issue:
Enable the error log to see if you get intuitive info on internal RAD errors, in 7.5 it is available on "Show views"
If your changes are not deployed Clean project
If your changes are not deployed yet Rebuild project
If your changes are not deployed yet Redeploy project
If your changes are not deployed yet Clean server
If your changes are not deployed yet Restart server
Or:
- Use ant or maven to make deployments straighforward and ignore the pain due to websphere and eclipse having internal bugs (which you may see in the error log if it is fully enabled).
Regards.
Are your JSPs copied correctly? That is, when you make a change in one JSP, can you see change immediately upon browser refresh? If this works, then I see no reason why classes aren't also published. JSP auto refresh should work in normal and debug modes.
Now, is "build automatically" enabled? If no, your classes won't get compiled and transferred. Parent_first/application for class loading shouldn't be an issue.
Is the local app. server running in development mode? If not, it should be.
While developing, use debug mode. Hot deploy will assure changes to your methods are seen immediately. Changes in classes won't be seen (i.e. adding a method will require application restart).
Is your app. server using global security? I have it turned off and auto redeploy works without problems.
Class reloading has always been a problem while developing Java EE applications. Try do erase that ear file from your WAS and redeploy it again.
If all else fails, try JRebel.
This question already has an answer here:
Using special auto start servlet to initialize on startup and share application data
(1 answer)
Closed 7 years ago.
We have a few war files deployed inside an ear file. Some of the war files have a class that caches static data from our PLM system in singletons. Since some of the classes take several minutes to load we use the load-on-startup in the web.xml to load them ahead of time. This all works fine until we attempt to re-deploy the application on our production servers. (WebLogic 10.3) We get an exception from our PLM API about a dll already being loaded. Our PLM vendor has confirmed that this is a problem and stated that they don't support using the load-on-startup. This is also a huge problem on our development boxes where we have redeploy the app all the time. Most of us, when we're not working on one of the apps that uses a cache, have them commented out. Obviously we can't do that for the production servers. Right now we transfer the ear to the production server, deploy it in the console, wait for it to crash, shut the app server instance down and then start it up again.
We need to find a way around this...
One suggestion was to create a servlet that we can call after the server boots that will load the various caches. While this will work I'm looking for something a bit cleaner. Is there anyway to detect once the server started and then fire off the methods?
Thanks.
We had a similar problem with a third party JDBC driver that loaded a native DLL. When redeploying the app the driver would crash saying the DLL was already loaded. The solution (if one can call it that) was to move the driver from deploy into lib. This way the driver was global to the app server and didn't need to be reloaded when the app was redeployed.
What about using a servlet container lifecycle listener, such as ServletContextListener?
Example on how to use.
EDIT: Sorry, after re-reading your question I don't think this will work. You want something that will load only once per server life, not application life. The ServletContextListener's methods will be called each time the app is deployed, just like a load-on-startup servlet (which it seems you are using). My suggestion will do the exact same thing in a different way.
I would try Chris Nava's suggestion.
EDIT2: It looks like tomcat has some lifecycle listener(s) available to it also. It looks like documentation is sparse, but this potentially would allow you to do something on server startup specifically only once.
EDIT3: Yes, a tomcat lifecycle listener is the way to go. This link explains pretty well how to set one up. Should be fairly straight forward. If you ignore the part about adding the Transaction to tomcat, it goes over pretty thoroughly how to add a lifecycle listener.