My project works in several tomcat servers. Project Structure is same, when I updated and deployed. I don't want to change database, and baseUrl settings manually.
I'm using Spring MVC. I want to write settings/configurations into server and get from server.
You can use environment variables in different servers (pre-prod, prod etc) to accomplish something like this.
There are multiple ways to use environment ways in properties for spring framework.
Here is a good post Different property variable for Local and prod Environment (Spring)
You can append the server settings in your tomcat server and the base URL in your project properties file.
Related
Background:
I have an ASP.NET web app configured for federation with AD FS. I'm using VS 2012, and have TFS for source control, builds and deployments.
We're currently deploying by copying the built files from the build server (TFS) to the alpha environment. From there we would copy from alpha to beta, then from beta to production. So there is not a unique build for each environment. The way we're handling environment-specific settings right now is there is one config file that has all the settings for each environment Let's call this EnvironmentSpecificSettings.config (I'll refer to it below). There is a static file on each server that indicates which environment the server should be in, and so when that config file is read in, the matching settings can be applied.
The problem:
The ADFS configuration is handled in the web.config. There are a few things that are specific to the environment. How might I handle this within my current deployment paradigm? I had a couple of ideas:
include a file reference in the web.config that reads in a static environment-specific file that would not be part of the deployment.
Try to pull something off in Application_Start that would read in settings from EnvironmentSpecificSettings.config (mentioned above) and alter the web.config.
Try to tweak the configuration of the WSFederationAuthenticationModule at runtime
the first idea (#1) is less than optimal because it requires files hanging around outside of source control and outside of deployments, however it should work easily enough. Next, #2 I kinda think isn't possible. I'm not sure you can change your web.config like I am hoping, but maybe? Finally, #3 Is only reasonable because I'm in a special situation where I'm not doing regular passive authentication, instead I'm manually redirecting to adfs, so I have a chance to change settings, such as injecting the whr parameter to avoid HRD. So, it might be possible, however, I'm not sure how or if you can change some of these values on the fly such as thumbprint, or wsFederation issuer or realm.
Does anyone have any better ideas or experience in handling environment-specific settings without doing the visual studio web deploys with transforms?
Is there some sort of configuration settings in FlashBuilder 4.5 where you can easily switch between webservice urls? Right now I have to delete and recreate the web service every time I switch from local to production and vice versa.
The need/requirement is this – Since I work in a startup, we keep changing servers, and their IP addresses. And being a service oriented application – I need to be able to edit the webservice endpoints in my Flex application in a easy manner every time this happens.
My Solution for this -
Assumption is that my webservice endpoint looks like this -
http:////ListAllServices/
1) Create a file config.xml in a folder named “settings” that sits in the root folder of your Flex application – outside the “src” folder. And the config.xml will be a simple xml file of the following format -
localhostTestFlexApp
At the end of this exercise the directory structure of your flex source code will look like this -
flex_src(root of the source code)
-com(some source folder)
–testapp
—view
—
-images
-settings
–config.xml
-appName.mxml
2) Now in your application code, setup a HTTPService object either in mxml or action script. Set the url of that object to this value- “settings/config.xml” – And the above xml fiel containing the current settings will be loaded into memory .
Now you can store these values in a singleton object and construct your Webservice call at runtime.
And whenever you want to move this to a new server in production, edit the tag of your config.xml and you should be good to go.
And this can be automated as well via the EnvGen ant task.
This is not the best way but yes it is very helpful while switching among servers.
Alrighty... The way I was doing it before in fact worked. The problem was browser caching.
For the benefit of others I modified the subsclass for the generated service and replace the wsdl variable with whatever endpoint I need.
We have a series of web services that live in different environments (dev/qa/staging/production) that are accessed from a web application, a web site, and other services. There are a few different service areas as well. So for production, we have services on four different boxes.
We conquered the db connection string issue by checking the hostname in global.asax and setting some application wide settings based on that hostname. There is a config.xml that is in source control that list the various hostnames and what settings they should get.
However, we haven't found an elegant solution for web services. What we have done so far is add references to all the environments to the projects and add several using statements to the files that use the services. When we checkout the project, we uncomment the appropriate using statement for the environment we're in.
It looks something like this:
// Development
// using com.tracking-services.dev
// using com.upload-services.dev
// QA
// using com.tracking-services.qa
// using com.upload-services.qa
// Production
// using com.tracking-services.www
// using com.upload-services.www
Obviously as we use web services more and more this technique will get more and more burdensome.
I have considered putting the namespaces into web.config.dev, web.config.qa, etc and swapping them out on application start in global.asax. I don't think that will work because by the time global.asax is run the compilation is already done and the web.config changes won't have much effect.
Since the "best practices" include using web services for data access, I'm hoping this is not a unique problem and someone has already come up with a solution.
Or are we going about this whole thing wrong?
Edit:
These are asmx web services. There is no url referenced in the web.config that I can find.
Make one reference and use configuration to switch the target urls as appropriate. No reason to have separate proxies at all.
Is it possible to configure an IIS site to read ASP.Net settings from a site OTHER than web.config?
We'd like to have three config files in our codebase -- web-dev.config, web-test.config, and web-prod.config. Each IIS instance would be configured to read from their specific file. This way we have version control them all next to each other (and one-click deploy the entire site) but know that each IIS instance will read the settings specific to itself.
I've found in IIS where it shows where the web.config is, but I can't see how to change the location.
I use the configSource property to specify an external config file for sections that need different values for dev and production.
<connectionStrings configSource="Config\ConnDev.config"/>
Then you only have to change one setting (manually or with a tool) to switch from Dev to Production configs.
The best solution right now is to use different configs for development and production. This however will change with .net 4 and VS 2010 which they have added Web.Debug.config, Web.Release.config, Web.Staging.config and Web.Testing.config which will then publish the config you need in relation to the environment.
At my company we just have our deployment tool set to copy the appropriate file to web.config depending on what kind of deployment we're doing.
I believe it has to be named web.config.
You are facing a common problem.
One solution that I have used that worked really well in a large organization was to set environment variables on the web servers. Such as DEV, QA, UAT, PROD. Then, in code, you can query the environment variable to see which machine you are on, and then choose the values of appSettings accordingly. For example, you could have a database connection string named DEVconnection, and another named UATconnection. If your code determines from the environment variable that you are on UAT, then it would use UATconnection.
This does assume that you have the ability to set environment variables on the web server. In this instance, the admins running the servers were the ones who suggested this solution.
What was sweet about this was that there was ever only one version of web.config.
I do not think we can make web.config declaratively so that we can specify different config file. One thing you can do you can split your configuration file and set for different environments.
Please go through this article
http://jetmathew.wordpress.com/2011/02/07/split-web-config-for-different-environment/
cheers
I'm developing a web application (ASP.NET 3.5) that will consume a number of web services. I have created a separate dll-project for each web service: these projects contains the service reference and client code.
However, the calling website MUST have the <system.serviceModel> information (the <bindings> and <client> nodes) in it's web.config, even though this information is also in the dll's app.config file! I have tried copying the serviceclass.dll.config over to the bin directory of the website, but this didn't help.
Is there any way to centralize the configuration of a WCF client?
I've only limited WCF experience, all with BasicHTTP bindings. But I'm allergic to WCF's xml files and have managed to avoid them thus far. I don't recomend this generally but I put the configuration details in my apps existing configuration store and then apply them programatically. E.g. With a Web service proxy I use the constructor for the Client that takes 'bindings'and 'endpoint' and programatically apply the settings to the bindings & endpoint.
A more elegent solution appears to be descibed here: Reading WCF Configuration from a Custom Location, but I haven't tried it yet.
From my experience, library projects never read app.config.
So you can really delete the file because it is not used. The library's host configuration is read instead, so that is the only place the endpoint and binding configuration should be.
It's possible to forgo xml config and build up the Binding and Endpoint classes associated with the service in the constructor or a custom "Service Factory". iDesign has some good information on this:
http://www.idesign.net/idesign/DesktopDefault.aspx?tabindex=5&tabid=11
(See In Proc Factory)
In their approach, you set attributes on your services to specify at a high level how they should work (ie [Internet], [Intranet], [BusinessToBusiness]), and the service factory configures the service according to best practices for each scenario. Their book describes building this sort of service:
http://www.amazon.com/Programming-WCF-Services-Juval-Lowy/dp/0596526997
If you just want to share configuration XML config, maybe use the configSource attribute to specify a path for configuration: http://weblogs.asp.net/cibrax/archive/2007/07/24/configsource-attribute-on-system-servicemodel-section.aspx
Remember that a configuration file is is read by an executable that has an entry point. A library dll does not have an entry point so it is not the assembly that will read it. The executing assembly must have a configuration file to read.
If you would like to centralize your web configs then I would suggest you look into nesting them in IIS with virtual directories. This will allow you to use the configuration inheritance to centralize whatever you need.
There are 2 options.
Option 1. Working with channels.
If you are working with channels directly, .NET 4.0 and .NET 4.5 has the ConfigurationChannelFactory. The example on MSDN looks like this:
ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap();
fileMap.ExeConfigFilename = "Test.config";
Configuration newConfiguration = ConfigurationManager.OpenMappedExeConfiguration(
fileMap,
ConfigurationUserLevel.None);
ConfigurationChannelFactory<ICalculatorChannel> factory1 =
new ConfigurationChannelFactory<ICalculatorChannel>(
"endpoint1",
newConfiguration,
new EndpointAddress("http://localhost:8000/servicemodelsamples/service"));
ICalculatorChannel client1 = factory1.CreateChannel();
As pointed out by Langdon, you can use the endpoint address from the configuration file by simply passing in null, like this:
var factory1 = new ConfigurationChannelFactory<ICalculatorChannel>(
"endpoint1",
newConfiguration,
null);
ICalculatorChannel client1 = factory1.CreateChannel();
This is discussed in the MSDN documentation.
Option 2. Working with proxies.
If you're working with code-generated proxies, you can read the config file and load a ServiceModelSectionGroup. There is a bit more work involved than simply using the ConfigurationChannelFactory but at least you can continue using the generated proxy (that under the hood uses a ChannelFactory and manages the IChannelFactory for you.
Pablo Cibraro shows a nice example of this here: Getting WCF Bindings and Behaviors from any config source
First of all class libraries (DLLs) do not have their own configuration, however they can read the configuration of their host (Web/Executable etc.). That being said, I still maintain an app.config file on the library projects as a template and easy reference.
As far as the service configuration itself is concerned, WCF configuration can make somebody easily pull their hair out. It is an over-engineered over-complicated piece. The goal of your applications should be to depend least on the configuration, while maintaining flexibility of deployment scenarios your product is going to come across.