I am facing a rather strange problem with an installation of JBoss 5.0.1 I have to deploy a webapp on.
In my webapp I try:
System.getProperty("jboss.server.config.url")
to get at the "conf"-dir. (And subsquently read a few files) On my development-machine this worked just fine, but in the deployment environment the aforementioned property appears to be the empty String ("").
Does anyone know why that could be and how to change it?
Thank you
I don't know why it does not work properly at yours, but you can change any JBoss property, just open run.conf file, and add line like at the end (at least JAVA_OPTS should be defined before):
JAVA_OPTS="$JAVA_OPTS -Djboss.server.config.url=new_path"
for Windows should work (in run.conf.bat):
set JAVA_OPTS = %JAVA_OPTS% -Djboss.server.config.url=new_path
this way you can change any property. Like Kevin D. already wrote, take a look at JBoss Properties, jboss.server.config.url is just $jboss.server.home.url/conf, so maybe something wrong with jboss.server.home.url variable, you can specify its value.. In its turn its value is $jboss.server.base.url/$jboss.server.name, check them etc. So you could find real cause of it... Hope it helps
It may rely on your JBOSS_Home being set in your environment variables.
This...article/list seems to indicate that all the JBOSS properties are built up from this http://community.jboss.org/wiki/JBossProperties
Related
I am to switch between DB localhost or a dev server DB depending on the system I am running the code.
in the build.gradle
System.getenv()
System.getProperty("test.property")
but this one comes as null.
2 possible solutions,
1) set the System varibale
2) Try some other way to get the domain
Appreciate your answers
Expecting a way to get the domain so that i can decide which DB and other scripts to be used.
To read an env var in gradle,
var myvar = "$System.env.myvar"
System.getenv("myvar")
Also, try to avoid special characters such as . in env prop names.
If you really want to get the domain name, consider executing a windows command and store the output in a string.
How to use exec() output in gradle
Other options could be...
Creating .local file with no content, adding it to .gitignore, and then checking its existence. It could be created in the local dev machines, but be missing from other places.
Adding something to the ~/.gradle/gradle.properties file. Because this is picked up on the local machine, you can test for it. But, in other places where it is not set, you wouldn't see it.
I have been trying to setup a proof of concept elasticsearch/kibana/logstash environment, but it is not working at the moment.
The LOGSTASH_HOME is:
c:\_work\issues\log4j_socketappender\logstash-5.0.1\
In the console log of logstash I found the following line:
Could not find log4j2 configuration at path /_work/issues/log4j_socketappender/logstash-5.0.1/config/log4j2.properties. Using default config which logs to console
You can see logstash is trying to look for log4j2.properties in the right location but it does not contain the "c:" part
I tried adding the path to the config\jvm.options
-Dlog4j.configurationFile=c:\_work\issues\log4j_socketappender\logstash-5.0.1\log4j2.properties
but it did not work.
Eventually I fixed it by adding the following line into bin\setup.bat
42. SET JAVA_OPTS=%JAVA_OPTS% -Dlog4j.configurationFile=%LS_HOME%\config\log4j2.properties
Two things come to mind:
Try specifying the full path with -Dlog4j.configurationFile=c:\_work\issues\log4j_socketappender\logstash-5.0.1\log4j2.properties
Also, is the properties file using the new Log4j2 properties syntax? An old log4j 1.2-style properties file will not work. (Although I would expect a different error message in that case.)
as you can see here
create an Environment Variable in Windows LS_SETTINGS_DIR and set it to:
/c:/logstash-5.0.1/config
(notice - leading forward slash and all slashes are unix style not Windows style backslashes)
or to invoke logstash with
--path.settings=/c:/logstash-5.0.1/config/
(again note position and direction of slashes)
I hope that this helps someone avoid the Googling and testing I have just done!
I need to be able to read in a property file, that lives outside of my war. My problem is that a need a solution that will allow me to tell my war file where my property file is located. Can this be done through bashrc variables and windows env variables?
I need to do this because I need to be able to drop the property file in different locations that could be away from the war file.
I am struggling to come up with a solution.
This will very much depends what the property file is for. Some libraries will have have the possibility of setting it on the command-line and others will allow you to explicitly load them in code.
In case of the latter, System.getProperties() can prove helpful, since it allows you to read properties passed to the JVM using the '-D' flag. For example
java -jar -Dfilelocation="yourfilelocation" yourapp.jar
would populate the system property 'filelocation' with the string 'yourfilelocation'. This could then be used in your code to load the property file (or whatever you want to do with it).
Since you are running inside some sort of application server, there are different ways you can accomblish this. For jetty you can put them in start.ini (or simply pass them on the command-line when you start jetty)
where tomcat uses an enviroment variable called JAVA_OPTS, so
JAVA_OPTS='-Dfilelocation=yourfilelocation' start.sh
would set the system property when you start tomcat.
one way is to provide specific location by passing java argument or setting up environment varialble and read it from app to determine the location
and as a fallback (default) app should be announcing to look at
${user.home}/appname/some.peroperties
You could defines a list of possible directories ... and try to read each one ...
I have a solution that read a property file in the file system using a default directory structure.
Eg: c:\properties\code-suit\prd\application.properties
Where:
code-suit is a variable defined by application name;
prd is a environment that I will use
Good luck
This one is driving me nuts - almost :-) I got a Java properties file, looking something like that:
url=${ip}:${port}
In my pom.xml, I enabled filtering for all property files in src/main/resources and ip and port are defined in my pom.xml.
Now, when I run maven's process resources, only the first placeholder is replaced. In the case above ip. So the resulting properties file looks something like that:
url=127.0.0.1:${port}
First, I though I might have mistyped port or forgotten to define it. So I tested what happens with:
test=${port}
Guess what, during filtering, it gets filtered correctly.
test=8080
What could that be? Why does maven (3.0.4) ignore the second property on the line? Any ideas where to look for that?
I have created an example which also has two properties in a single line, but i don't have any problems with that. But it would be helpful to see your pom.xml.
I have installed a java batch process using the version of procrun that ships with tomcat 5.5.33:
Commons Daemon Service Runner version 1.0.5.0/Win32 (Jan 5 2011)
Copyright (c) 2000-2011 The Apache Software Foundation.
In the installation, I specify (among other JVM options):
--JvmOptions="-Duser.dir=C:\LOCAL\serverapps"
My log4j.properties configuration includes:
log4j.appender.InfoLogFile.File=../logs/info.log
However, the info.log file is being written to:
C:\WINDOWS\logs
I've checked the value of user.dir at many different points and it's always C:\LOCAL\serverapps.
But, log4j is behaving as if user.dir=C:\Windows\System32 (or some other subir of C:\Windows).
From what I can tell from the log4j source (1.2.16), the FileAppender deals only with the java.io.FileOutputStream and File classes which claim to make paths relative from the user.dir location.
I've worked around the issue, but I am curious: has anyone else has encountered this type of behaviour? If so, what's really going on?
FileAppender, when given a relative path, creates a file withing the current working directory - not the user home directory.
You need to pass the ${user.dir} within the filename.
SRC:
http://svn.apache.org/viewvc/logging/log4j/trunk/src/main/java/org/apache/log4j/FileAppender.java?view=markup
EDIT: see comment below for correction - user.dir != user.home
http://bugs.sun.com/view_bug.do?bug_id=4117557
I have used ${user.dir} in the lo4j.properties and it has worked. Have you tried?
log4j.appender.InfoLogFile.File=${user.dir}/logs/info.log
PhilW's comment points to the correct answer to the original question. That is, Oracle/Sun declares an issue http://bugs.sun.com/view_bug.do?bug_id=4117557 when user.dir is set via the command line. That is the reason why the relative path is not properly understood when logging files are written out.
By using a an absolute path (even prefixing with ${user.dir} -- which can be trusted at that point - even if the JVM gets the value wrong internally) as Phil, Amir and I all suggest, you avoid the issue altogether.