How can we make a compromise between Tomcat and Websphere? - java

Our team is facing a difficuties while developing/modifying a servlet.
The servlet is having some unknown problem and we think I may due to too many request.
We would like to find a way so that the request could be queue up.
But what matter most is that we are developing the servlet using tomcat as the servlet container, when we put it in the production server, our company use websphere to hold it.
I don't know about websphere, but I am sure it have some way to control the requests. But we are only allowed to use tomcat to develop. Thus we do not know what would happen in the production server, this make us very sad. Of course, our company cannot afford to make another websphere for development usage.
What can I do?

If you can't find the information you're looking for in the Infocenter, you should probably test/debug on WAS. There is a free developer license for Windows and Linux (you must install it on your development machine - see the FAQ for restrictions).
While there's some merit in targeting Tomcat in development, a complete ban on the target application server is counterproductive. Production is not the place you want to find incompatibilities.

Tomcat and Websphere has different architecture and servlet engines and i think you cannot get guarantee that application that perfectly runs on Tomcat will be as well on Websphere.

Try to use JBoss free version for tests. It much more similar to Websphere than a Tomcat.
We use it for this purpose on one of the project - and it cover 99% of our problems with deploys.
Also if i remember it right exist development license version of websphere and it kind of free(but with mad license restrictions)

Related

Which one is the better configuration: Tomcat only OR Apache Server + Tomcat?

I have a VPS where I want to install a web application for production.
Currently, it works on Tomcat 6 connected through Apache Server using AJP module.
Every thing works ok, but I want to know if it is a good idea to configure Tomcat as the main web server due we gonna run only JSP applications.
FYI: the server must handle https requests.
Thanks in advance.
Misinformation
Years ago there was much misinformation against using Tomcat directly as a web server, but in fact Tomcat works very well as such.
I've used nearly every version of Tomcat on various projects, though all were relatively low volume. Never let me down – well, the WebDAV module never worked right. But other than that Tomcat is fast and reliable both for static content as well as dynamic servlet work.
httpd
Apache HTTP Server ("httpd") is of course very advanced and full of features. If you need those features, then use httpd. If you have very high volume traffic, then use httpd. If you have huge amounts of static access and want to relieve Tomcat of that duty thereby letting Tomcat focus its performance on your servlets, then use httpd. If you want to keep a front-facing web site running while take Tomcat up and down, use httpd. But for most relatively simple web sites or simple web apps, Tomcat suffices.
I suggest you try Tomcat alone and see how it goes. Start with your development and testing systems. Review your config files for httpd to see if all its features can be reproduced using Tomcat features. If that all works, then do some load-testing. Either hack some load-tests of your own, or try any of the many load-test frameworks.
While you can hot-deploy webapps to Tomcat, that was not always recommended in production (I'm not sure about current versions). Plan how to handle taking down Tomcat to deploy updated apps and to perform maintenance chores.
Recent Tomcat
You say you are using Tomcat 6. You may want to consider moving to Tomcat 7 or 8, but review the release notes.
Jetty
Also consider Jetty, the most direct competitor/alternative to Tomcat. Jetty is much akin to Tomcat in its purpose, scope of features, and great reputation.
If you're using SSL you will get the following benefits by front-ending with Apache HTTPD:
Ability to specify cipher suites in order of preference, which is practically mandatory if you want case-hardened SSL, and impossible with Tomcat alone.
Ability to request or require client certificates on a per-location basis instead of globally, which is Tomcat's only mechanism.
There are many other benefits as well, such as:
the ability to load-balance between multiple Tomcat instances, which alone is probably enough of a reason to do it
more control over what's logged and where the log files go
more tools to defend against attacks of various kinds.
I used standalone Tomcats for years, but having made the switch I would never go back even for a clean-sheet project.
I don't think either is better, it depends on your requirements. In environments where you may have to address security or logging requirements horizontally across heterogeneous backends (IIS, Tomcat, etc), Apache is your friend (or an expensive load balancer).
Assuming you don't have these requirements, I don't know of any advantage in using Apache for Apache sake.
SSL is easily configured in Tomcat and performance these days is likely to be on par with Apache and can be improved with APR.

How can I simulate / test deployment on different Java Application Servers?

I am currently developing something in Java using Jetty as my web container. How can I test if my WAR/EAR/etc file can be deployed on other servers (including enterprise level servers)?
I want to try and sell my application to enterprises, but not sure how I can know whether or not the application will deploy? I've only ever used OS servers before
Also how do I spec my 'system requirements' if i don't have access to enterprise grade hardware?
edit: I mean, if I look at something like this: http://wiki.gxtechnical.com/commwiki/servlet/hwiki?Oracle+Application+Server+Deployment, it looks deceptively easy.. But going in blind is quite scary!
You need to download, configure, and install each server and try it out. Many have free or limited development versions.
Depending on the complexity of your application, you will very likely encounter issues with each container. I can't say if any of them will be in conflict (i.e. fix it to work with container X makes it break in container Y), but it is possible.

How can I get a WebSphere project to run under tc server?

Just wondering if anyone has ever converted a Websphere project to run under tc server? I run on a Mac and would love to be able to run my application locally without having to run Websphere in a VM.
I realize there are differences which would have to be accounted for, and that's really my question - what would I have to change? I also realize that even if this is possible, one couldn't depend on the tc server configuration before going to production - it would have to be tested in Websphere first.
As we know, application server provides lot more features than a tomcat. Hence first, you would have to check if your application is using any of those features. If so, then you would have to see if that missing functionality could be plugged-in somehow. To exemplify, you could be using the transactional capability of the application server. Tomcat doesn't come with transaction capability. You would need to plug-in a a third party component for that. For this to happen less intrusively, the code should be configurable so that based on the environment it would know whether to make use of the capabilities of the application server or use the capabilities of the plugged-in components in case of tomcat.
Advantage of this: It would certainly be boosting to the productivity if you use tomcat to develop rather than any application server, as the time it takes to start and stop tomcat if far less than the coffee time (To me ,one coffee time is the amount it takes for an application server to stop and start even when you have the minimal hardware requirements mentioned by it)
Warning:: Again this approach has a negative point that you would miss to see how your component interacts with the classes in the production environment, while you develop. Hence it becomes mandatory to have your QA environment and above to make use of the application server. This way you could avoid any surprises in production.

Choosing an application server for web application development

My manager has asked me to suggest an application server for web application development work.
What are the factors that needs to be considered before we select any application server for web application development in Java J2EE development?
If I select one now and IN future and I want to change to some other application server, is that minimum effort to change?
Apache Tomcat and Jetty are the two most popular web containers. Tomcat is the reference implementation of a Java servlet container, Jetty is a little bit faster and more lightweight. I personally favor Jetty, but you can't go wrong with either of them. A little comparison of the two can be found here.
Generally the migration of an application between web containers is fairly easy - only some configurations needs to be changed, but nothing in the source code(which is not always the case with full blown enterprise application servers).
The answer is that you can make it more or less difficult to change application containers based on your development practices. For example, the Liferay portal includes the custom XML configuration files for many application containers, allowing it to be used on many containers. So, it's certainly possible to switch flexibly, but you have to re-do all the server-specific configuration files and you can't rely on container-specific features.
In some cases, the containers themselves make it difficult. For example, the JBoss classloader has a history of scant support for the actual J2EE and Java EE standards. This makes it easy to rely on non-standard features, and in some cases nearly impossible to use standard ones.
Besides making sure that your application server enforces standards compliance, you do want to make sure you need a full application server, as opposed to just a servlet container as mentioned above. Does your application need EJBs, or just servlets? If you aren't doing EJB development, then an application server is over-kill.
If you are doing EJB development or otherwise using other EE features beyond what a servlet container supplies, consider ease of configuration and administration along side standards compliance, and I think you'll find a server that fits your needs.
A well written Java web application can be deployed on any web container, possibly with a bit of external configuration.
Hence you can choose the one that works the best for you during development, and then do testing on the target deployment server.
For netbeans, Tomcat is enclosed, and is fine. Eclipse does not have an enclosed web container yet, but Tomcat is supported.
In any case, use one that others use, then they can help you, and you them.
For pure development purposes, I would like a server with
Small footprint and very minimal start/stop time.
IDE plugins
So, my vote goes to Jetty for web app.
If you are on Netbeans, Glassfish is not a bad choice either as it shows superb performance via grizzly that uses NIO.

Lightweight portal server for WebSphere Portal development?

I'm doing some portlet development for IBM WebSphere Portal 6.1. However, the deployment process is painfully slow. As this is my first time doing portlet development, I'm not too familiar with the various portal servers out there. I'd like some recommendations for a lightweight portal server on which I can deploy quickly for development.
Pluto is the answer!
http://portals.apache.org/pluto/
I'm very happy now. :)
I believe Liferay has become Sun's adopted strategy, if that has any bearing.
If you are using Websphere Portal server, you can use the lazy load of portlet applications at server startup. This would help in less server startup times as it would not start many administrative applications.
For more information, follow this link
http://www-01.ibm.com/support/docview.wss?uid=swg27015437
Hope this help you :)
I'm not familiar with each of their deployment characteristics, but here is a list of open source portals in Java: http://java-source.net/open-source/portals
I was in a similar situation a year or two ago.
The server takes a long time to come up regardless, but it doesn't actually have to be restarted with any little change. You only have to restart the server with major changes, otherwise, restart or redeploy the project to the server.
Nevertheless, the system wasn't snappy until I had three gigs of ram. I'd recommend first upgrading your workstation to support the server. They're called workstation class systems for a reason :) Get yourself an 8gb machine and tell your boss you will be twice as productive :)
I typically use hotdeployment of changes Java classes and JSP pages. This is the fastest way. We shared 1 server with 5 developers using hotdeployment of classes to PortalServer/installedApps/.ear/yourportlet.war and this worked great. However, now and then we did have to restart the server. If you changed deployement descriptors you still need to re-deploy the portlet WAR. Make sure the reloadingEnabled flag is set to false for the wps.war app on your development machine (restart picks up the change).
You can use developer mode explained here:
http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1/index.jsp?topic=/com.ibm.wp.ent.doc_v615/install/chg_dev_mode.html

Categories

Resources