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.
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 am trying to develop a java software based on OSGi (Apache Felix), which different module (which may contain more than one jar file) could be developed by different developers from different companies.
the question is: i am wondering how should i provide database connection to these modules. if i share the same user credential between modules, they may accidentally or intentionally use each other tables or data which should be avoid because of information privacy. or if i force each module to have its own connection with its own user credential then there will be many connections.
note: i am using mariadb as backend.
i know this problem is not a OSGi specific problem. i am wondering if anyone has faced such problem and has proven solution for this scenario (i only describe my development environment).
any idea,
thanks
First of all, your issue of multi-tenancy isn't something any system (beeing it OSGi or not) is made for. Therefore you need to take care of this yourself. Most OSGi applications still use datasources if you want to connect to a db, via JPA for example. Usually those datasources are registered as OSGi services.
Coming back to your multi-tenancy issue, you should make sure for each you have another datasource and just use that datasource in your application. For example make sure each tenant has it's own configuration and therefore receives his own Datasource as configured in your configuration. This way you can make sure each tenant is separate to each other.
OSGi cannot achieve the level of security you need for this scenario. An OSGi Framework is intended to represent a single logical application. If bundles exist in the same JVM and OSGi Framework, then it is very hard to prevent data leaks, especially against determined attacker.
You need to isolate processes at the very least, and run those processes as separate user IDs.
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
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'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).