After reviewing the Resin documentation, it mostly just talks about using only one properties files.
I know resin.xml can reference multiple properties files like this:
< resin:properties path="${__DIR__}/custom.properties" optional="true"/>
Is there a way to replace the standard properties file (i.e.resin.properties) with multiple other properties files and most importantly place them somewhere else other than standard ${RESIN_HOME}/conf directory?
With what arguments can I run Resin so that it can locate those custom properties files?
Thank you in advance!
resin:properties#path can be a full path as so:
path="/etc/resin/resin.properties"
Alternatively, Resin can resolve -D arguments with ${} expression.
< resin:properties path="${location}/custom.properties" optional="true"/>
e.g.
bin/resin.sh -Dlocation=/custom/resin start
resin.xml:
< resin:properties path="${location}/custom.properties" optional="true"/>
< resin:properties path="${location}/custom2.properties" optional="true"/>
Related
I have a Powershell (v2.0) script that I am working on.
One of the first things it does is loads a Module (runMySQLQuery.psm1) which includes (amongst other bits) a function to connect to a MySQL Database.
Import-Module runMySQLQuery.psm1
However, this requires that an assembly MySQL.Data.DLL is loaded in order for this to work.
If I place the line:
[void][system.reflection.Assembly]::LoadFrom("C:\PowerShell\modules\runMySQLQuery\MySql.Data.dll")
at the top of my script (separate to the Import-Module entry), then the whole thing works fine.
But I want to be able to load this assembly at the same time as the module, so that I don't have to worry about forgetting to including the assembly each time I use this module.
I tried placing it at the top of the .psm1 file, but that didn't work.
I then added it to my manifest file as:
RequiredAssemblies = #("C:\PowerShell\modules\runMySQLQuery\MySql.Data.dll")
This also didn't work.
Am I missing something here, is there a proper way to include assemblies as part of a module?
n.b. the error I get when it hasn't loaded properly is:
You cannot call a method on a null-valued expression
Can you just try to assign a varialbe a the beginig of you module :
$dumy = [system.reflection.Assembly]::LoadFrom("C:\PowerShell\modules\runMySQLQuery\MySql.Data.dll")
I have the same question related to this:
aop.xml name and location?
In the answers, it says:
use the system property:
-D org.aspectj.weaver.loadtime.configuration=META-INF/myaop.xml
What does "use the system property" mean?
create a aop.properties file?
Or, write in the vm option?
AFAIK there is no such thing as aop.properties. Have you just made this up? The hint means you should specify the property as a JVM command line parameter like this, if the given path can be resolved as a Java resource path/URL:
java ... -Dorg.aspectj.weaver.loadtime.configuration=META-INF/myaop.xml ...
If you explicitly want to point to the file system, you have to precede the path by file:, e.g.
java ... -Dorg.aspectj.weaver.loadtime.configuration=file:META-INF/myaop.xml ...
or
java ... -Dorg.aspectj.weaver.loadtime.configuration=file:c:\my\path\META-INF\myaop.xml ...
Attention: no white space between -D and the property name!
Update:
What does "use the system property" mean?
Your favourite search engine will lead you to pages like:
Oracle Java tutorial
System Javadoc, specifically methods
getProperties(),
getProperty(String),
getProperty(String, String),
setProperties(Properties),
setProperty(String, String),
clearProperty()
I've already asked a similar question, here:
Linking to modules in external directory Compaq Visual Fortran command prompt
And I thought that the first answer was correct (that is, in the manual they say you can simply specify the path name before the module), but after deleting the temporary files in my library folder, this approach seemed to stop working. Trying with the /include[:path] approach, here is my .bat file:
df /include:..\FORTRAN_LIB\ __constants
myIO griddata_mod myfdgen myDiff magneticField /exe:magneticField
And an error is returned saying:
__constants
myIO
griddata_mod
myfdgen
myDiff
magneticField
f90: Severe: No such file or directory
... file is '__constants'
Again, I apologize that this question is VERY specific, but it seems like it should be simple and does not work at all.
p.s. Originally, I was using:
df ..\FORTRAN_LIB\__constants ..\FORTRAN_LIB\myIO
..\FORTRAN_LIB\griddata_mod ..\FORTRAN_LIB\myfdgen
..\FORTRAN_LIB\myDiff magneticField /exe:magneticField
But, as I've said, it stopped working after I deleted the temporary files in my FORTRAN_LIB folder. Also note, these .bat files used only one line, I've broken them into several lines just for readability. I would prefer using the /include[:path] option since that seems like a better solution.
Okay, so I think I figured out a workaround at the very least. I understood that the /include[:dir] specifies to search in "dir" for included files. But it seemed from documentation, that this also specifies to search for USEd modules but that doesn't seem to be the case.
My program now looks like this:
include '..\FORTRAN_LIB\__constants.f90'
include '..\FORTRAN_LIB\computeError.f90'
include '..\FORTRAN_LIB\griddata_mod.f90'
include '..\FORTRAN_LIB\myfdgen.f90'
include '..\FORTRAN_LIB\myDiff.f90'
include '..\FORTRAN_LIB\myIO.f90'
program magneticField
use constants
use computeError_mod
use griddata_mod
use myfdgen_mod
use myDiff_mod
use myIO_mod
implicit none
...
And my DF command like this:
df magneticField /exe:magneticField
And everything seems to work fine. It would be nicer to have the /include[:dir] option, but so long I'm able to reach in a separate directory, I'm satisfied. If anyone can find a better solution I'll switch the checkmark. I hope this helps with anyone else who was confused like me.
I would like to control 'global' config in Gradle build scripts using external property files on each build machine (dev, ci, uat,...) and specify the filename with a command line argument.
e.g. gradle -DbuildProperties=/example/config/build.properties
I specifically don't want to use gradle.properties as we have existing projects that already use this approach and (for example) we want to be able to amend database urls and jdbc drivers without having to change every project.
So far have tried:-
Properties props = new Properties()
props.load(new FileInputStream("$filename"))
project.setProperty('props', props)
which works but has a deprecated warning, but I can't figure out how to avoid this.
Have also tried using groovy style config files with ConfigSlurper:-
environments {
dev {
db.security {
driver=net.sourceforge.jtds.jdbc.Driver
url=jdbc:someserver://somehost:1234/some_db
username=userId
password=secret
}
}
}
but the colons and forward slashes are causing exceptions and we don't want to have to mess up config with escape characters.
There must be a non-deprecated way to do this - can anyone suggest the 'right' way to do it?
Thanks
You can get rid of the deprecated warning quite easily. The message you got probably looks something like this:
Creating properties on demand (a.k.a. dynamic properties) has been deprecated and is scheduled to be removed in Gradle 2.0. Please read http://gradle.org/docs/current/dsl/org.gradle.api.plugins.ExtraPropertiesExtension.html for information on the replacement for dynamic properties.
Deprecated dynamic property: "props" on "root project 'private'", value: "true".
It can be fixed by replacing:
project.setProperty('props', props)
with
project.ext.props = props
Just to supplement the response given by #Steinar:
it's still possible to use next syntax:
project.ext.set('prop_name', prop_value)
in case you have several properties from file:
props.each({ project.ext.set(it.key, it.value)} )
src
|--Manager.cpp
|--Specializations
| |--Manager.cpp
Building this Boost.Build tries to create
/bin/...
|--Manager.o
|--Manager.o
but fails. How to resolve this automatically? I read FAQ item, but I don't like the solution, as I have to fix things manually when I have a same class name, but different namespace. Would it be possible to make Boost.Build automatically prefix object file names with directory?
/bin/...
|--Manager.o
|--Specializations.Manager.o
Or duplicate the source directory tree?
/bin/...
|--Manager.o
|--Specializations
| |--Manager.o
This behavior has been changed a long time ago and should just work. Boost.Build now mimics the source structure, i.e. you should get both bin/Manager.o and bin/Specializations/Manager.o.