We have a grails project in production. Grails version is 2.3.4. We are using MongoDB for persistence.
Earlier, we had all the config hardcoded inside DataSource.groovy. The client demanded that the config be outside the .war file. So we moved it to a .groovy file. Everything was working fine, including the repicaSet config.
Then the client came up with another requirement. Since a groovy file can be used to give any programmable instruction, it can be misused by a person whose job is just to update a property file. So they want all the config in a .properties file.
here is the contents of my .properties file
grails.mongo.host=10.3.253.201
grails.mongo.port=27017
grails.mongo.databaseName=testDb
grails.mongo.username=mongouser
grails.mongo.password=mongouser
Where can I give the details of replicaSet? Thanks in advance.
I would like to answer this question in case someone else is facing the same isssue.
grails.mongo.uri=mongodb://10.3.253.201,10.3.253.202,10.3.253.203/test
grails.mongo.host=10.3.253.201
grails.mongo.port=27017
grails.mongo.databaseName=test
grails.mongo.username=mongouser
grails.mongo.password=mongouser
This is the content of my config.properties file and it started working for me.
201 was the primary node and the other two were backup in my cluster.
Regards.
Related
I have a fully working JBoss 6.3.3.GA instance but one of my colleagues unwittingly connected to my Development server instead of his, and updated my Standalone.xml file.
He made a lot of changes and there's no way (at least I didn't find any one) to get my old file back.
Now I need to restart my server, and I'm afraid I'll loose my current configuration forever since his update will be taken into account.
My question is : Is there anyway I can find my current XML Standalone configuration in any temporary folder or something like that ?
Under your jboss directory go to : standalone/configuration/standalone_xml_history.
You should find different versions : standalone.boot.xml, standalone.initial.xml, standalone.last.xml ... etc
You will also find old configurations of your standalone stored in folders which names include the date when you made those configurations includig a folder containing your current configuration.
For my Play 2.2/Scala application (built with SBT), I would like to deploy different configuration files depending on the environment I'm deploying to (e.g. to couple a deployment with a particular database server). How does one create different variants of the application's configuration file (conf/application.conf) for different deployment targets? Hopefully variants can be generated from a base version?
What I'm used to from .NET is to have a base configuration file (Web.config), which undergoes a certain transformation depending on the profile one is deploying (e.g. Production). Does one use a similar technique in the Play/Scala world?
Alternative configuration files are covered in Play's documentation quite well in section Specifying alternative configuration file.
In short - in application.conf you place default configuration of your app, and additionally you need to create additional files for you environment(s) ie. life.conf, dev.conf etc. In these files you first need to include application.conf (which will read whole default configuration) and next just overwrite only parts which have to be changed - ie. DB credentials, it could be dev.conf:
include "application.conf"
db.default.driver=org.h2.Driver
db.default.url="jdbc:h2:mem:alternative-database-for-dev-testing"
db.default.user=developer
db.default.password="developerpass"
So finally you start your application (after dist) as
./start -Dconfig.resource=dev.conf
or with the Play console
play -Dconfig.resource=dev.conf run
Several tips:
It's good idea to do not place your 'life' DB credentials in default application.conf file, if some dev will forget to include his dev.conf he won't damage the production DB, instead you should put it in prod.conf.
Also these additional configs shouldn't be placed in any VCS (ie. git) repository - creating them directly on target machine (and ignoring in repository) give you sure, that people who shouldn't know the life database credentials won't see it.
It's also possible to use remote alternative config file, which can be useful ie. when you deploying several instances of the same app ie. on several hosts in the cloud.
Each dev can has own config file ie dev_aknuds1.conf, dev_biesior.conf etc, so you can ignore them with one pattern dev_*.conf in repo.
Finally you can just create a shell script (unix) or bat file (Windows) to start using choosen config file like start_dev.sh, run_dev.sh etc. so you won't need to write -Dconfig.resource=... each time
In TYPO3, Version 6.1.5, I'd like to split my configuration in typo3conf in three parts:
One part generated by the install-tool, under version control.
One manually managed part, under version control.
One manually managed part, containing server specific stuff, not under version control. Contains e.g. database credentials.
I've tried to do it like this:
is done using LocalConfiguration.php,
is done using AdditionalConfiguration.php
is done by and additional file, included by the AdditionalConfiguration.php.
This does not work, as it seams that the files are evaluated in this order:
LocalConfiguration.php
AddtitionalConfiguration.php
LocalConfiguration.php
So the changes from my server specific file (and AdditionalConfiguration.php) are simple overwritten by the stuff from LocalConfiguration.php.
Any idea how to get around something like this?
First: don't apply any manual changes in your: LocalConfiguration.php file as it will be removed after each operation in the Install Tool, Extension Manager etc.
For adding custom configuration, you should use AddtitionalConfiguration.php file which isn't changed (as probably you know while you are using it). In this additional conf you need to use 'old' syntax for overwriting values, ie:
<?php
$GLOBALS['TYPO3_CONF_VARS']['DB']['database']='some_db_loc';
$GLOBALS['TYPO3_CONF_VARS']['DB']['host']='localhost';
$GLOBALS['TYPO3_CONF_VARS']['DB']['username']='jost';
$GLOBALS['TYPO3_CONF_VARS']['DB']['password']='yourpass';
finally at the end of the additional conf use common include() for including next PHP file in which you can overwrite these values again:
#include('jost_localconf_dont_commit.php');
At least in TYPO3 ver. 6.1.1 this scenario works like a charm.
EDIT: also take a look at Viktor's answer according to accessing the properties in additional config.
BTW: I'm not really sure why you need to commit AdditionalConfiguration.php , IMHO it should be ignored in the git, and on every environment it should have this file filled with local data typical for this env. Main (production) instance should keep whole its config in LocalConfiguration.php
Just one things to add to biesior's answer:
For security reasons, it is even better not to have the DB credentials in AdditionalConfiguration.php. It's better to include a PHP file with the credentials from a path that is outside the document root of the host. Therefore if PHP doesn't work properly, the file cannot be downloaded and the DB credentials are not exposed.
I used Eclipse to deploy my Java web application on AWS Elastic Beanstalk which uses a UNIX 64-bit environment. And my application needs to read a file from the same project folder. However, after I run the project, the log in the Management Console shows that the directory cannot be found. I tried to resolve this by either using a relative path or a absolute path. But neither worked.
One weired thing is that I cannot find the Tomcat folder in the ec2 instance. Does anyone have an idea about how I can set up my file path in the application or where I should put my file to make it found?
Thank you!
I'm not certain what you're doing with your file, but I had the same problem finding a path to an image to use in a class. I hope this helps!
Preface: I'm deploying my .war to my elastic beanstalk instance via the AWS-Elastic Beanstalk console. I moved my image into the exact same package/folder as the class I'm referencing it in.
BufferedImage imBuff = ImageIO.read(MyAwesomeFooBarClass.class.getResourceAsStream("foobar.png"));
And that's it! I'm sure this isn't the most elegant solution, but it certainly works/I'm a bit crunched for time ;)
Is there a way to configure a container in multiple configuration files?
For instance, I want to register types for a container in a web.config file located at the root and also register types for the same container (and others containers) in the web.config file of sub-folders.
And also register other types for others containers in a company.config file in path C:\Company\Framework\Configs.
When I try to do this I get a ConfigurationError stating that the entry for the container has already been added.
EDIT: any suggestions here
http://unity.codeplex.com/Thread/View.aspx?ThreadId=23230
any more suggestions for sample code ?
I have a similar question posted here: WCF + Unity nested web.config problem
I have a web application with a subdirectory 'Services' which contains WCF services.
This services folder also has a web.config file containing my WCF configuration. That doesn't seem to be a problem for WCF.
The same web.config also has unity configuration for use inside my services. But i'm unable to load this configuration using 'GetSection'
If I move my unity configuration to the root web.config, everythings works fine.