Does anyone know if it is possible to restart a J2EE application (from the application)? If so, how?
I would like to be able to do it in an app-server-agnostic way, if it is possible.
The application will be run on many different app servers-- basically whatever the client prefers.
If it isn't possible to do this in an app-server-agnostic manner, then it probably isn't really worth doing for my purposes. I can always just display a message informing the user that they will need to restart the app manually.
I would suggest that you're unlikely to find an appserver agnostic way. And while I don't pretend to know your requirements, I might question a design that requires the application to restart itself, other than an installer that is deploying a new version. Finally, I would suggest that for any nontrivial purpose "any" appserver will not work. You should have a list of supported app servers and versions, documented in your release notes, so you can test on all of those and dont have to worry about supporting clients on a non-conforming server/version. From experience, there are always subtle differences between, for example, Apache Tomcat and BEA WebLogic, and these differences are often undocument and hard to determine until you run into them.
Most application servers provide a JMX interface, so you could invoke that.
I'd suggest using servicewrapper to manage the application server, and then use its api methods for requesting a restart of the service. There would be some configuration involved and its hard to know if this would work in your particuar environment, but thats the only solution that I know of which is even reasonably cross-server compatible.
Related
I'm sure this is very obvious, but I'm new and just trying to wrap my head around this. And googling this question isn't helping, because I think the answer is just so obvious... but I'd really appreciate an answer.
First of all, there are many modules Spring provides for a variety of applications. For applications like job scheduling, console applications, batch or stream processing, serverless applications, etc. you don't require any kind of server or browser.
But, when it comes to a web or enterprise application, you definitely need a web container. Spring comes with a built-in server of its own, i.e Tomcat (though there is also an option for Jetty and UnderTow, etc.). This is basically a container that handles the dynamic requests coming from the clients. But, you can have your own configuration by modifying the default one to meet your custom requirements. Like say, for example, Usually, it runs on port no.-8080 you can change it to say, 8081 by simply mentioning 'server.port=8081' in the application property of your application.
Now, coming back to your question any Spring/Spring Boot application runs on servers as a whole and sole application.
In our system we have a legacy standalone java application which we are trying to made available for new webapps we are developing all together running in a server (f.e. Tomcat)
In order to made requests to this app lighter we thought about made them directly to the same vm using jndi instead of developing a webservice interface.
I would like to start this application environment in some webapp context and make some API available to other webapps and invoke interfaces' methods.
I've not been able to bind this objects by JNDI in the Tomcat's read-only Context without adding the app in the Common lib, when I get more problems due to incompatibilities between dependencies versions. Maybe the best solution is to deploy these interfaces as EJBs so I'd use a Java EE Server instead of a servlet container. Or maybe I'd use some other framework such as Camel or something.
Thanks in advance and any suggestion will be helpful.
I would suggest to wrap your legacy java interfaces in REST. When you expose them as REST APIs, they will become available for any client, not only java. Also you don't need any Application Servers for that, all you need is a jar file for your REST reference implementation.
From performance perspective, well, I know theoretically JNDI should be faster, but in the real world the difference in performance becomes significant ONLY for very very performance intensive applications.
However, if performance is your primary requirement then wrap your legacy interfaces in EJBs.
Manual JNDI/RMI lookups are going to be the fastest, BUT and this is a rather big but, unless you are well experienced in network programming and multi threading, I would advise you to steer clear of that, and use a container. There are a lot of nitty gritty details that the container takes care of and you can concentrate on implementing your business logic.
is it possible to install more than one java application server on one server or VPS ?
i want to install JBOSS , TOMCAT , WEBLOGIC and my be more.
how this is possible and what the benefits and disadvantages ?!
It is possible, if you want to try all of them. You just have to select different port for each services.
Is there a real use-case ? You could have an application bound to your application server, and you could want to run different applications.
Yes. The usual problem is that a given port can only be used by a single process.
Hence you cannot have both JBoss and Weblogic on port 8080. Also a lot of extra ports are needed for normal operation. This is at best tedious.
This is possible. You need to take care about port's these servers use.
Also you need to check what resources (cpu's/core/RAM) you have on your server. Your system should have ample resources to Run multiple servers.
I don't know whats use case, But if possible I would prefer having various webapps on single Java applicationserver.
As already mentioned above it is possible but it is a configuration management nightmare.
If it is for compatibility testing, I would look at EC2 or similar timebased hosting and , put an 1 app server in 1 image and spin up each image in turn and shut it down after the test is finished.
The money that costs is paid 10x by not having to edit all kind of configuration files and debugging weird conflicts.
Yes, it is possible.
Pros:
You don't need extra servers to run your appservers, so you save in physical/virtualmachines. This helps a lot when you're prototyping something, and also in functional testing, because you can share servers between applications.
Some applications may need incompatible appserver settings, so you must run them in different appservers, side by side.
Downtime of one appserver doesn't affect other appservers.
Cons:
You must make sure that every appserver gets enough share of CPU, memory, etc.
You must assign port numbers to each appserver
You are making each environment's performance dependent on each other's.
So, it is something that you do mainly to experiment/develop/test. In production environments you have to be much more careful when running appservers side by side..
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.
I'll need to develop a Java service that is simple because:
It only communicates via a TCP socket, no HTTP.
It runs on a dedicated server (there are no other services except the basic SSH and such)
Should I make this a standalone service (maybe in something like Java Service Wrapper) or make it run in a container like Tomcat? What are the benefits and detriments of both?
If you aren't working with HTTP, you will have to build your own connectors for Tomcat. When I've written these types of applications, I've just written them as standard Java applications. On Windows machines, I use a service wrapper that allows them to be part of the Windows startup process. On non-windows machines, you just need to add a start up script.
Using a container (regardless which) buys you that all the details about starting, stopping, scaling, logging etc, which you have to do yourself otherwise, and it is always harder than you think (at least when you reach production).
Especially the scalability is something you need to consider already now. Later it will be much harder to change your mind.
So, if somebody already wrote most of what you need, then use that.
Tomcat doesn't sound like a good choice for me in your situation. AFAIK it's primarily made for Servlets and JSPs, and you have neither. You also don't need to deploy multiple applications on your app. server etc. (so no benefit from ".war").
If you need dependency injection, connection pooling, logging, network programming framework etc., there are a lot of good solutions out there and they don't need tomcat.
For example, in my case I went for a standalone app. that used Spring, Hibernate, Netty, Apache Commons DBCP, Log4j etc. These can be easily setup, and this way you have a lot more freedom.
Should you need a HTTP server, maybe embedding Jetty is another option. With this option too, you have more control over the app. and this can potentially simplify your implementation compared to using a tomcat container.
Tomcat doesn't really buy you much if you don't use HTTP.
However, I was forced to move a non-HTTP server to Tomcat for following reasons,
We need some simple web pages to display the status/stats of the server so I need a web server. Java 6 comes with a simple HTTP server but Tomcat is more robust.
Our operation tools are geared to run Tomcat only and standalone app just falls off radar in their monitoring system.
We use DBCP for database pooling and everyone seems more comfortable to use it under Tomcat.
The memory foot-print of Tomcat (a few MBs) is not an issue for us so we haven't seen any performance change since moved to Tomcat.
A container can save you from reinventing the wheel in terms of startup, monitoring, logging, configuration, deployment, etc. Also it makes your service more understandable to non-developers.
I wouldn't necessarily go for tomcat, check out glassfish and germonimo as they are more modular, and you can have just the bits the need, and exclude the http server.
We faced a similar decision a while back, and some parts of the system ended up being jsw based, and the others as .war files. The .war option is simpler (well more standard for sure) to build and configure.