Is it possible (and if: how?) to set up JBoss AS7 to use his own modules dir and an additional custom modules.custom at the same time? If so, I would not have to mix my custom entries with the default entries.
you can do that by setting JBOSS_MODULEPATH env variable to include more than just your folder.
For instance configuration like this
set JBOSS_MODULEPATH=%JBOSS_HOME%/modules;/path/to/my/modules
it would add /path/to/my/modules to path of modules. But just make sure you still keep default folder in your module path.
for more you can take a look at standalone.sh/bat and look how this variable is used.
(if you are on mac or unix, use export and colons)
export JBOSS_MODULPATH=$JBOSS_HOME/modules:/path/to/my/modules
Related
In order to run the application in my local, i need to provide some VM arguments(basically file path, where it is located). In similar way in PCF also I have to provide those arguments.
currently I am keeping in application.yml file like below.
jaas:
conf: /home/vcap/app/BOOT-INF/classes/nonprod_jaas.conf
krb5:
conf: /home/vcap/app/BOOT-INF/classes/krb5.conf
trustore:
conf: /home/vcap/app/BOOT-INF/classes/kafka_client_truststore.jks
When I deploy the application in PCF, will these files will be read from that location.
Basically I want to know this is correct way or not to provide the arguments in PCF.
how to check whether the file is present in that location, /home/vcap/app/BOOT-INF/classes/
You need to ssh into the container to check the location of the file.
cf ssh appname
In spring, #Value enables the use of the classpath: prefix to resolve the classpath (see this link) https://www.baeldung.com/spring-classpath-file-accessclasspath: It means you need to set this programmatically not via the variables in yml. Then you don't need to provide the path the way you are doing.
Also classpath: is a Spring specific convention, the JVM doesn't understand it which means you cannot use it directly in application.yml file. If you need to set in yml or as environment variable - you need to give it a full or relative path. On PCF, you can use /app or /home/vcap/app (the former is a symlink to the latter) as the path to the root of your application.
I've been searching for a solution but I can't find one.
I have a global configuration directory in my IntelliJ workspace. I also have several dozen modules. I would like each module to automatically include the global config directory in its path when I run or test a class.
Is there anyway to do this within IntelliJ? I don't think I should need to edit the configuration for each "Run/Debug" config to include the directory.
You'll want to set it in the Defaults for the type of Run or Debug Configuration that you are using.
For example, if I always want a Java Application to have the VM Option -XPutYourThingyHere, then I could go to Edit Configurations, Defaults, Application, and put -XPutYourThingyHere in the VM Options box. Then all new Applications that I run will have that option.
In all configuration below, a prefix of "solr." for class names
is an alias that causes solr to search appropriate packages,
including org.apache.solr.(search|update|request|core|analysis)
You may also specify a fully qualified Java classname if you
have your own custom plugins.
This is what I found while going through the solrconfig.xml file. But it seems this is defined to point to the respective classes in solr. I know somehow SOLR_HOME is used for solr.data.dir. I have used solr using "start.jar" and also using "solr-**-*.war" on Tomcat. It just works !!! :)
So where does solr.data.dir points to ?
Where exactly is SOLR_HOME is defined ?
So where does solr.data.dir points to?
The dataDir parameter is used to specify the directory for storing all index data. If this directory is not absolute, then it is relative to the directory where you started Solr. If the folder is empty, the new index would be re-created automatically when starting Solr.
Where exactly is SOLR_HOME is defined?
It really depends on operating system and web server used. And it defines the home directory of your Solr.
The most commonly it could be defined either:
in startup files,
using system environment variables, e.g.:
export JAVA_OPTS="$JAVA_OPTS -Dsolr.solr.home=/opt/solr/example"
during runtime as part of JAVA_OPTS (on Debian, in /etc/default/tomcat7 for instance, format: -Dmy.prop=value),
using System property substitution file (core.properties/solrcore.properties),
using Tomcat Context Configuration (e.g. in conf/Catalina/localhost by solr/home),
per Solr instance in solr.xml (instanceDir).
Best is to specify it explicitly.
You can modify tomcat/bin/catalina.sh to add following JVM option:
-Dsolr.solr.home=/home/mdhussain/solr-test/deployment/solr1
Data directory is relative to solr home, you can override this in solrconfig.xml.
If you are running on a MAC it's default installation directory (including data)
- if installed via maven dependency at least - is in the /var/XXX directory.
cd /var
grep --color -iHrn solr .
Example on my machine for the index data location:
/var/folders/1j/z7f1373977s_qlfvv9t71kmh0000gq/T/solr-7.3.1/solr-7.3.1/server/solr/cores/catalog_reindex/data
I need to put some production specific behavior in mule-config.xml. Is there a way to get environment info in mule?
You can access all system properties via MEL. But I would rather suggest you modularize your configuration in several files (say: common-config.xml, test-config.xml, prod-config.xml) and load the right files at Mule startup based on the environment.
And also you can create properties file for each environment and access it inside mule config file.
You can create xml file with all the configurations and import/load the file into mule project
In your Mule configuration file (src/main/app/app-config-file.xml), you can add the following line:
<context:property-placeholder location="${environment.name}.properties" />
${environment.name} must be a system environment variable. You need to make sure the system where you are deploying your app contains that variable. I think you can also specify it in the Maven build, if you are using Maven (clean install -Denvironment.name=test). You can try.
To test locally, right click on your project, select run as, select run configurations, click on Environment tab, add your variable "environment.name" and the value "local" (without quotation marks) and make sure your local.properties file exists in a location added to the build path. It can be src/main/app for example or in the resources folder.
MEL has some context objects like server, mule ,application using these you can get the envinformation from #[server.env] for more info refer
https://docs.mulesoft.com/mule-user-guide/v/3.6/mule-expression-language-basic-syntax
You can use different mule properties file like Mule-dev.properties , mule-test.properties.
In global elements add a property placeholder :
In mule-app.properties define env= test or dev depending on the env value which you want to use.
Clean the project and deploy. Sometimes it is not able to read the env specific properties. Cleaning the project solves this issue.
You can add a properties file in you project and refer it from property place holder. it is better to add environment value in mule-app.properties file ehich is in /src/main/app
you can have one variable like mule.env in this mule-app.properties and send value to this Property as DEV,QA,UAT,PROD from cloudhub properties and create different properties file in mule/src/app main resources then use Properties placeholder to configure this property file and send the value of mule-env dynamically from cloudhub
Typically the way this is done is to delcare a property bean in which you set the environment specific value like PROD,QA,DEV or local. This environment specific value is set in mule-app.properties like mule.env=local, This needs to be set to the environment we are trying to deploy it and the API picks up the right properties file.
We're having problems when trying to deploy a number of projects which use zc.buildout - specifically we're finding that they want to put their PYTHON_EGG_CACHE directories all over the show. We'd like to somehow set this directory to one at the same level as the built-out project, where eggs can be found.
There is some mention online that this can be done for Plone projects, but is it possible to do this without Plone?
Are there some recipes that can set up an environment variable so we can set the PYTHON_EGG_CACHE executable files in ./bin?
The PYTHON_EGG_CACHE is only used for zipped eggs, your best bet is to have zc.buildout install all required eggs unzipped:
[buildout]
...
unzip = true
If your system python has zipped eggs installed that still require unzipping for resource access, and setting the PYTHON_EGG_CACHE in your scripts is your only option (as opposed to setting the environment variable for your user), you could try to use the initialization option of zc.recipe.egg to add arbitrary Python code to your scripts:
[a-part]
recipe = zc.recipe.egg
...
initialization =
import os
os.environ['PYTHON_EGG_CACHE'] = '/tmp/python_eggs'
I'm not sure what you mean. Three options that you normally have:
Buildout, by default, stores the eggs in a directory called eggs/ inside your buildout directory.
You can set the eggs-dir variable inside your buildout.cfg's [buildout] section to some directory. Just tell it where to place them.
You can also set that very same option in .buildout/defaults.cfg inside your home directory. That way you can set a default for all your projects. Handy for storing all your eggs in one place: that can save a lot of download time, for instance.
Does one of those (especially the last one) accomplish what you want?
And: don't muck around with eggs in the generated bin/* files. Let buldout pick the eggs, that's its purpose.