Currently, we store datasource definitions in the Tomcat container inside server.xml and expose environment variables through context.xml.
Any time we change an environment variable or datasource, it requires a server restart for those changes to be live.
Is there a way that we could create a web application to manage these things? Instead of storing them in the server context.xml and server.xml files, we could store them in another file and have them be modifiable through the webapp. When an application wants a datasource, it could request it from the webapp (maybe through messaging). I had thought about modifying the jndi elements at runtime and saving the changes in a file, but found that Tomcat does not allow that.
If it's not obvious, I have only a little experience with the technologies involved, but would like a direction to head in. I don't want to do anything hackish and would like to follow standards.
Would it be correct to have a webapp that handles global datasource and global variable management, requiring you to request these objects through messaging? If not, what are some preferable alternatives?
Well, you could have used the Tomcat "admin" package, if it existed. But then, it was never ported from version 5 to 6 for various reasons. The post itself states the right way on how one must right the admin tool.
In the meantime, you could possibly use the MBeans exposed by Tomcat, although I can't vouch for anything useful being present.
Look at migrating to a different application server.
For instance Glassfish might suit your requirements.
http://blogs.oracle.com/alexismp/entry/glassfish_ose_3_0_1
http://glassfish.java.net/
Related
We maintain our server once a week.
Sometimes, the customer wishes that we change some settings which is already cached in server.
My colleague always write some JSP code to change these settings which are stored in the memory.
Is it a good method to use this kind of methodology?
If our project is not a Web container, which tools can help me?
Usually, in my experience, the server configuration is not stored only in memory of server:
What happens that after a configuration change, the server has been restarted / just went down for some system reason?
What happens if you have more than one instance of the same server to work on (a cluster of servers in other words)?
So, usually, people opt for various "externalized configuration" options that can range from "file-based" configuration + redeploy the whole cluster upon each configuration change, to configuration management servers (like Consul, etc.d, etc). There are also some solutions that came from (and used in) a java world: Apache Zookeeper, Spring cloud config server to name a few, there are others. In addition, sometimes, it's convenient to store the configurations in a database.
Now to your question: If your project is not a web container and you don't care that configuration will "disappear" after a server restart and you're not running a distributed cluster of servers, then, using JSP indeed doesn't seem appropriate in this case.
Maybe you should take a look at JMX - Java management extensions, that have a built-in solution so that you probably will be able to get rid of a web container (which seems to be not used by your team anyway other than for JSP modifications that you've described).
You basically need in memory cache, there are multiple solutions found in answers which include creating your own implementation or using existing java library. You can also get data from database and add cache over the database layer.
I have a requirement where I have to host two (different) webapps on the same machine accessible via HTTP but on different ports. I am wondering what is the better solution, or basically what is the difference between
Starting two separate Tomcat instances with specific catalina_home / catalina_base and of course two conf dirs with corresponding server.xml(s)
Having one Tomcat instance and configure multiple Services in a single server.xml. There is a default Catalina Service in the server.xml and adding an another with the specific ports and appbase
Could someone describe which way to choose and why? I am interested in the main differences between the two instances vs two services?
The main difference between both approach is:
Many Tomcat instance
You can start or stop tomcat without affect the other instances, this approach is very helpful when you need to give maintenance to one application but you don't want to affect the availability of the other instances. Each instance will use their own resources, that could be a problem when the machine couldn't guarantee the amount of memory or processor that is need by every tomcat instance, this approach will demand more resources than the other one, in terms of tomcat knowledge this approach is very easy to implement.
One Tomcat instance And Many services x webapp
This approach is helpful when you need to share the resources between the web applications, you can have one single point of configuration for all the web application, with this approach is more difficult to isolate problems between web apps because they coexist in the same tomcat instance, for example if you need to troubleshoot one application how do that if both of them are running in the same tomcat? how read the log files? are the log files of both application in one log file? or are properly separated? be careful here if no proper configuration is perform then it could be nightmare in production. This approach will need more effort and knowledge in the tomcat configuration in order to define a proper separation of services, it is more difficult to configure but in terms of efficiency is better.
How to decide
Well it depend on
a. the amount of the resources of the server.
b. the knowledge level of the IT team in terms of tomcat configuration
c. how critical are the web applications, for example if one application is very critical is better to keep it in a separated tomcat instance because it helps you to isolate in a simple form any problem that can occurs with that specific application.
And finally it will depends on the context where you need to implement your solution and your business needs.
I would like to edit Connectors on the fly on my web-app code. However, for achieving this, I need to access the server from the web-app. How can do this access? It was tried going up from the JMX but it did not work either.
At my case, using JMX was the solution. I looked at the MBeans and I found out Beans directly related to what I wanted, I iterated over the beans and performed my actions over the right ones. This way, I could start/stop them and get the effect I wanted to.
Please consider me as a novice and this is my first web app I am creating.
I am planning to develop a web application where the traffic I am expecting is around 50 users will access the application at a single time.
The webapp is developed with Vaadin (for UI) and respective business logic implemented with Java. DB used would be MySQL. The war will be deployed in Tomcat.
So, my question is do I need to modify anything in Tomcat properties or anywhere to make the web app as multi user application (i.e. each users need to access and use application as though they are only one using the application)?
I tried to access a prototype developed using Vaadin in both Chrome and Firefox and could see both sessions running without an impact on another.
But please let me know suggestions.
You must keep in mind that even if tomcat and vaadin manage multiple sessions, your server application will have only 1 instance. So if you use singletons, static methods or fields, use them with care: they should never hold session-dependant content. Try to favour stateless methods over statefull.
Apart from that, there shouldn't be any problem.
It should not have any code changes if you handle the session and your business logic with statefulness properly.
There might be some configuration changes, like increasing the database connection pool size, it depends on what kind of connection pooling you are using and what is the default size etc.
Apart from that it should work just fine.
Vaadin is built on top of Jakarta Servlet technology (formerly known as Java Servlet). See Wikipedia. Indeed, Vaadin is a servlet, a much bigger and more sophisticated servlet than most.
Within a Java Servlet container (engine) such as Apache Tomcat or Eclipse Jetty, any particular servlet has only a single instance running. If three requests from three users arrive at the same time, there are three threads running through that same single instance for that particular servlet. So a servlets are inherently a highly threaded environment.
If you share any variables or resources between those threads, you must be very careful. That means mandatory reading, rereading, and fierce study of the book Java Concurrency in Practice by Brian Goetz, et al.
While the Web and HTTP were designed to be stateless delivery of single documents, that original vision has been warped by the desire to make web apps. To maintain state, a servlet automatically maintains a session. Vaadin represents this session state in its VaadinSession object. All data in all the forms, along with business logic, running for each user is maintained as part of that session.
Depending on your particular Vaadin app, and when multiplied by the number of concurrent users, this may add to a large amount of memory. You should monitor your server to make sure you have enough available RAM on your server.
do I need to modify anything in Tomcat properties or anywhere to make the web app as multi user application (i.e. each users need to access and use application as though they are only one using the application)?
No, nothing for you to set or enable. Tracking the requests/responses and session for each user is the very purpose of a servlet container. From the moment it launches, every servlet container expects multiple users. As a Servlet, Vaadin is built to expect multiple users as well. The only trick is making your own code thread-safe, hence the book suggestion.
I tried to access a prototype developed using Vaadin in both Chrome and Firefox and could see both sessions running without an impact on another.
Concurrency problems can be very tricky to detect and debug. Often potential problems occur on the random chance of coincidental timing. You need to focus on properly designing your code in the first place, rather than relying on testing. Again, hence the book recommendation.
Of special note, since you mentioned using a database, is JDBC drivers. Deploying them in a Servlet environment can be tricky. Basically you need to not bundle them within your Vaadin web app WAR file. Instead, deploy the JDBC driver separately within a shared library folder within Tomcat. If using Maven to drive your project, direct Maven in the POM file to give the dependency for your JDBC driver a scope of provided. This has nothing to do with Vaadin specifically, it applies to all servlets. Search Stack Overflow as this issue has been extensively addressed.
We're looking at how to do distributed configuration within our primarily Java based deployment. We have a number of applications and it makes sense to centralise the configuration of the applications. JNDI appears to be the standard choice, probably backing off to something like ApacheDS (that way we can store non Java config in there as well). Here are some of the things that I've considered. Has anyone tried something similar? Any recommendations?:
Distributed
This would be for multiple applications on multiple machines, some of the applications would be clustered. The Directory Server should also ideally be clustered.
Lightweight
JNDI has a bit of a J2EE feel to it. Anyone use an alternative distributed configuration mechanism. The applications themselves tend to be relatively lightweight rather than full Java EE applications (ok controversial whether Java EE is still considered heavyweight and requirements are certainly heavyweight).
Supports fallbacks
Often the same configuration applies to multiple applications (e.g. multiple applications may connect to the same database). One the other hand, some applications may need specific configuration. Sometimes it is difficult to know in advance whether an application will use a 'global' configuration or something specific, so being able to first search for application / host specific configuration and then falling back would be good. I'm thinking of a structure something like this:
/global/host/application/instance or /global/application/host/instance:
so, start by checking to see if there is any configuration specific to this instance of the application on this host, then check if there is any configuration specific to this application for this host, then check to see if there is anything specific for this application, then try the global setting. Are there any best practices for this kind of thing?
Live configuration changes
Spring allows configuration with a jee:jndi-lookup and you can choose not to cache the value which means it is looked up each request. I'm not sure that makes sense for "String" type configuration values. It also doesn't appear to use the NamingListener way of detecting changes in the DS. It would be good to be able to update a value on the Directory Server and have that change broadcast to all of the applications that use it.
Other considerations
Managing different environments
Adding the configuration to source control so that it can have change management applied to it
Managing different versions
Rolling back
Have you considered using a database to store the application configuration?
Apache Commons has a DatabaseConfiguration class that exposes your table as a java.util.Properties instance (see http://commons.apache.org/configuration/apidocs/org/apache/commons/configuration/DatabaseConfiguration.html).