We have an java enterprise application that is supposed to run on cluster of servers. The application consists of different WARs hosted by some web containers running on these servers.
Now we have a lot of different configurations for this application, to name a few:
Relational DB host/port, credentials and so forth
Non Relational DB configurations - stuff like mongo, redis and so forth
Internal lookup configurations (how to obtain a web service in SOA architecture, stuff like that).
Logging related configuration, log4j.xml
Connection pooling configurations
Maybe in future some internal settings for smart load balancing, maybe Multi Tenancy support
Add to this multiple environments, test/staging/production/development and what not, having different hosts/ports for all aforementioned examples and we and up with a dozen of configuration files.
As I see it, all these things are not something related directly to the business layer of the application, but rather can be considered "generic" for all applications, at least in the java enterprise world.
So I'm wondering whether exists some solution for dealing with configuration management of this kind???
Basically I'm looking for the following abilities:
Start my war on any of my servers in cluster with a host/port of this configuration server.
The war will "register" itself and "download" all the needed configurations. Of course it will have adapters to apply this configuration.
This way, all my N wars in different JVMs in cluster start (they're all share-nothing architecture, so I consider them as independent pieces of deployment)
Now, if I want to change some setting, like, setting the log level of some logger to DEBUG, I go to the management console UI of this configuration server and apply the change.
Since this management center knows about all the wars (as they were registered), it should notify them about the setting change. I want to be able to change settings for one specific WAR or cluster wide. If one of the web servers that hosts the application gets restarted it will again ask for configuration and will get the configuration including the DEBUG level of that logger.
I'm not looking for solution based on deployment systems like puppet, chef and so forth since I want to change my settings during the runtime as well.
So far I couldn't find any descent ready solution for this. Of course I can craft something like that by myself, but I don't want to reinvent the wheel, So I'm asking for advice here, any help will be appreciated.
Thanks in advance
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'm working on an application which is comprised of many web containers with WAR-s installed on these containers.
Currently I have a farm of ~ 10 servers like this.
I'm about to start the integration of jolokia/hawtio to track the JMX mbeans exposed on each of these servers.
For this purpose (I think) I'll install a jolokia agent on each of these servers (just put the war into the deployment library.
Now I think to put hawtio on a dedicated node and connect to the remote agents deployed on the rest of my 10 servers.
My question is whether its possible to somehow give a list of predefined agents (host/port/credentials)?
I have a lot of farms to manage like this, I would prefer to use a predefined list generated per farm, rather than dealing with auto-discovery
Thanks in advance
No currently this is not supported, but a good idea. You are welcome to log a ticket about this.
https://github.com/hawtio/hawtio/issues
And also how would you like that list to be configured? Should you need to edit the web.xml and repackage the WAR, or how should that configuration be made easy? That is for something to think about.
I'm creating an application that relies heavily on dynamic creation/management of various resources like jms queues, webservice endpoints, jdbc connections... I have a background in java EE and am currently working on a jboss 7 server however I'm finding it increasingly difficult to control these things programmatically. The hardest thing to control seem to be the webservices. I need to be able to generate WSDLs (and XSDs) on the fly, manage the endpoints, soap handlers etc and the system simply does not seem to be set up to do that.
Other application servers don't seem to really offer any groundbreaking solutions so I'm wondering whether perhaps java EE is not the best solution to this particular problem?
Is there an application server that allows you to do just that? Is there another technology that does? Should I just roll a custom solution that integrates all the separate modules (e.g. a jms server, a web server etc...)?
UPDATE
To clarify, most java EE stuff is accomplished through a mixture of annotations and XML configuration. This however assumes that you have a POJO and/or a jar/war/... per resource.
Suppose I have a #WebServiceProvider bean which can be reused for multiple input/output combinations (for example because it dynamically redirects the content). I need to be able to deploy a new "instance" of the provider on the fly. This means I do not want to duplicate the code and redeploy it, I just want to take that one existing bean on the classpath and deploy it multiple times with different configuration settings. This also means I need to manage the WSDL dynamically. The end result should be a webservice that works pretty much like a standard webservice on the application server with the necessary integrated security, soap handlers,...
I imagine that at some point in the application server code, there must be a class "WebserviceManager" which has a method like "createWebservice(...)" that is actually used by the deployment module whenever it discovers a webservice annotation. I want access to that method and similar methods for creating jdbc connections, jms queues,...
You can use OSGi for these kind of scenarios. It is perfect for hot deployment of varios modules.
We have several Spring MVC and Metro based applications which communicates with each other. Their settings are currently stored in multiple property files, that are made available to apps via PropertyPlaceholderConfigurer. This is not convenient because configuration is scattered and some parts of it is duplicated among servers. Currently we are going to create another webapp which is known to every other app and which keeps this whole configuration and provides an interface that allows to request these properties as key-values pairs. Is there any out-of-the box solution of this kind? Or, probably, is there a better way for solving this problem?
Do you need hot configuration, or just on startup?
If its just on startup, I would do it by some kind of version control system like svn.
So when app starts, it makes a call to svn to get the latest config.
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).