I updated some properties files (some i18n messages) on a running keycloak. But nothing happens. Do I need to restart keycloak to see the changes? That would be odd, as I instantly see changes to (freemarker) template files.
You can disable theme caching by modifying standalone.xml as follows:
<theme>
<!-- Change the lines:
<staticMaxAge>2592000</staticMaxAge>
<cacheThemes>true</cacheThemes>
<cacheTemplates>true</cacheTemplates>
to: -->
<staticMaxAge>-1</staticMaxAge>
<cacheThemes>false</cacheThemes>
<cacheTemplates>false</cacheTemplates>
<dir>${jboss.home.dir}/themes</dir>
</theme>
Related
I have a Jboss 7.4.
I added into my war application a undertow-handlers.conf file in the WEB-INF folder.
Content is :
path(/)->samesite-cookie(mode=LAX, case-sensitive=false, enable-client-checker=false, add-secure-for-none=false)
But I can not see anything in the logs when Jboss is starting about that file. Except when the syntax of the file is not correct.
Is there a setting I can change to see if that handler is set and read/used?
Actually, setting LAX using this method for Samesite is not working at all and I wonder if this file is currently used/read at start.
Many thanks,
An architect is having issues bringing Liberty up. Currently, an individual is running a server on his local computer and they want to move it to a shared server. When he tries to deploy a simple “helloworld” it’s failing and he is receiving an error “Context Root Not Found”. He is not sure what to set in server.xml file to have wlp recognize the application. They have ODM 8.5 on the mainframe. He thinks it might help if he saw an example of an EAR or WAR file deployed. Any ideas or suggestions?
Either put your application in the dropins folder, it will be detected and started automatically, or put it in the apps folder and configure in server.xml like this:
<webApplication id="HelloApp" location="HelloApp.war" name="HelloApp"/>
by default context root is application file name without extension, but you can change it by adding contextRoot="mycontext" attribute.
In TYPO3 6.1.5 the install tool saves configuration values correctly into LocalConfiguration.php, but having a look at the Configuration Module in the BE, those values are ignored by TYPO3. When I open the install tool again, all values are replaced by default values.
Any ideas?
Could it be you have some values in ''AdditionalConfiguration.php''? Those constantly override the values of ''LocalConfiguration.php''.
If not - You should definately Check the umask settings in LocalConfiguration.php. There Could be file permission errors involved. This would expand to files generated in typo3temp.
Another option are opcaches like apc. Those may not reload the changed file. Restarting your webserver or fastcgi would be the solution then.
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.
While looking for a light-weight Scala development environment, I came upon an Scala edit mode for jEdit. I don't know how to put it to use, though. How does one put a new edit mode in jEdit?
All of this can be found inside jEdit's help, Using jEdit -> Writing Edit Modes -> Installing Edit Modes. But, if you are like me, and tried StackOverflow first, here's the short of it.
Place the mode file (in this case, scala.xml) inside the "modes" directory in jEdit home directory -- this can be found through the Utilities menu -- if you want it for all users, or the "modes" directory in user's jEdit's settings diretory -- which can also be found through the Utilities menu -- if the new mode is to be used by only one user.
After that, edit a file "catalog" inside that same directory. It contains a list of supported modes. If you are working on the settings directory, there won't be any examples to use as a reference, but the catalog inside the home directory has plenty.
A settings directory catalog would look like this, for the referenced mode:
<?xml version="1.0"?>
<!DOCTYPE MODES SYSTEM "catalog.dtd">
<MODES>
<!-- Add lines like the following, one for each edit mode you add: -->
<!-- <MODE NAME="foo" FILE="foo.xml" FILE_NAME_GLOB="*.foo" /> -->
<MODE NAME="scala" FILE="scala.xml"
FILE_NAME_GLOB="*.scala" />
</MODES>
May be this JEdit Setup with Scala can help you ?
It refers to a JEdit fully configured to run Scala projects.
http://liftweb.net/images/9/91/Screenshot-jedit.png
You can copy the scala.xml file to $JEDIT_HOME/modes