I have this issue which I am unable to fix. I have an ext-plugin which overrides my portal-ext.rpoperties file (and I don't want this overriding) with another blank portal-ext file. There is no portal-ext.properties file in my ext-plugin but still every time when I deploy, this happens.
Any kind of help would be appreciated.
Thanks.
This is the response which i got from Liferay support department and it solves my problem. I am sharing here so it could be helpful to any other.
"Where is the portal-ext.properties file located in your system?
In WEB-INF/classes or in ${liferay.home}/portal-ext.properties?"
If it's in WEB-INF/classes, simply move your portal-ext.properties into ${liferay.home}/portal-ext.properties location. If it's the same, you can place your portal-ext.properties into your EXT plugin, so the original will be copied into the system instead of the empty one.
You can also add include-and-override lines in the empty portal-ext.properties and rename your original file to be loaded after portal-ext.properties, or you can use different properties file and specify it to the JVM to load. See the relevant part from portal.properties file:
Properties Override
#
# Specify where to get the overridden properties. Updates should not be made
# on portal.properties or on portal-bundle.properties, but in
# portal-ext.properties.
#
# The default read order is: portal.properties, portal-bundle.properties,
# portal-ext.properties, and then portal-setup-wizard.properties.
#
include-and-override=portal-bundle.properties
include-and-override=${liferay.home}/portal-bundle.properties
include-and-override=portal-ext.properties
include-and-override=${liferay.home}/portal-ext.properties
include-and-override=portal-setup-wizard.properties
include-and-override=${liferay.home}/portal-setup-wizard.properties
#
# Each portal instance can have its own overriden property file following
# the convention portal-companyWebId.properties. To enable this feature, set
# the "company-id-properties" system property to true.
#
# To enable:
#
# java ... -Dcompany-id-properties=true
#
# The read order will now be: portal.properties, then portal-ext.properties,
# and then portal-liferay.com.properties.
#
# Note that not all properties can have different values per company. This
# functionality is only available for legacy reasons. The preferred way to
# configure a portal instance is through the Control Panel.
#
include-and-override=portal-${easyconf:companyId}.properties
include-and-override=${liferay.home}/portal-${easyconf:companyId}.properties
#
# Additional property files can be used by setting the "external-properties"
# system property.
#
# A common use case is to keep legacy property values when upgrading to
# newer versions of Liferay. To enable:
#
# java ... -Dexternal-properties=portal-legacy-5.1.properties
#
# The read order will now be: portal.properties, then portal-ext.properties,
# and then portal-legacy-5.1.properties.
#
include-and-override=${external-properties}
include-and-override=${liferay.home}/${external-properties}
Related
Zookeeper is creating the logs with a name zookeeper-root-hostname.out but this is my log4j.properties:
zookeeper.root.logger=INFO, CONSOLE
zookeeper.console.threshold=INFO
zookeeper.log.dir=.
zookeeper.log.file=zookeeper.log
zookeeper.log.threshold=INFO
zookeeper.log.maxfilesize=256MB
zookeeper.log.maxbackupindex=20
zookeeper.tracelog.dir=${zookeeper.log.dir}
zookeeper.tracelog.file=zookeeper_trace.log
log4j.rootLogger=${zookeeper.root.logger}
#
# console
# Add "console" to rootlogger above if you want to use this
#
log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.Threshold=${zookeeper.console.threshold}
log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %-5p [%t:%C{1}#%L] - %m%n
#
# Add ROLLINGFILE to rootLogger to get log file output
#
log4j.appender.ROLLINGFILE=org.apache.log4j.RollingFileAppender
log4j.appender.ROLLINGFILE.Threshold=${zookeeper.log.threshold}
log4j.appender.ROLLINGFILE.File=${zookeeper.log.dir}/${zookeeper.log.file}
log4j.appender.ROLLINGFILE.MaxFileSize=${zookeeper.log.maxfilesize}
log4j.appender.ROLLINGFILE.MaxBackupIndex=${zookeeper.log.maxbackupindex}
log4j.appender.ROLLINGFILE.layout=org.apache.log4j.PatternLayout
log4j.appender.ROLLINGFILE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %-5p [%t:%C{1}#%L] - %m%n
If a change the property zookeeper.log.file=zookeeper.log the file is created with the same name, How can I change the filename of the log?
Update
I found that the file zkServer.sh set the variable ZOO_LOG_FILE and overrides the value that is define in the log4j.properties:
ZOO_LOG_FILE=zookeeper-$USER-server-$HOSTNAME.log
I can modify this file but Is it ok to change that manually?
In typical Java application fashion the logging situation with Zookeeper is incredibly complicated, custom, and poorly documented. The official Administrators manual logging section is a tiny paragraph with about zero information, but suggests you can rely on your existing knowledge of the third party library log4j configured to proxy through the other third party library SLF4J. This actually wouldn't be too bad since that complicated arrangement is common as many popular open source projects ignore the built-in logging framework that ships will Java, but later you'll discover using the log4j.properties file in the conf directory actually doesn't work as expected because custom properties are used in the provided start up script (zkServer.sh) that override many things.
In order to set the file name note the file conf/log4j.properties contains the following variable assignment that is overridden by the start up script (zkServer.sh):
zookeeper.log.file=zookeeper.log
Either set the environment variables externally, modify the start up script or update the log4j.properties to not use the variable:
#log4j.appender.ROLLINGFILE.File=${zookeeper.log.dir}/${zookeeper.log.file}
log4j.appender.ROLLINGFILE.File=/the/actual/path/goes/here.log
You may also want to enable the ROLLINGFILE like so:
#log4j.rootLogger=${zookeeper.root.logger}
log4j.rootLogger=INFO,ROLLINGFILE
After searching I found this link but I didn't found how to change the variable for the log, I noticed that inside the file zkServer.sh is defined the name of the file, so I needed to change this variable:
_ZOO_DAEMON_OUT="$ZOO_LOG_DIR/zookeeper-$USER-server-$HOSTNAME.out"
I don't know if it's ok to change that variable but now is working as expected.
In a sublimetext3 project, is there a way to modify or extend, not replace, default settings?
To be specific, in a project I specify the paths of the folders to include in the project. Each folder has files and directories unique to that folder that I want to exclude using either folder_exclude_patterns or file_exclude_patterns; see documentation for Projects.
But as I understand this, these project settings replace not extend the default settings. What I would like, however, is to have a project setting that appends to the default pattern rather than replacing it. Is this possible?
Pseudo code that expresses what I would like to do:
"folders":
[
{
"path": "c:\\dir1",
"folder_exclude_patterns": default_folder_exclude_patterns + ["junk"]
},
{
"path": "C:\\dir2"
"folder_exclude_patterns": default_folder_exclude_patterns + ["old"]
},
]
If this is not possible, then I believe the only thing I can easily do is copy the default settings and replicate them for each folder item. Since I have multiple projects/folders and need to do this for file exclude, folder exclude and binary file settings, this will get tedious and be hard to maintain. Of course, this seems like it is ripe for a plugin, but that is not in the scope of what I am looking to do. (Of course if someone else has a plugin that does something like this, I would be happy to try it out! :-))
Unfortunately, due to the way Sublime is set up, higher-precedence settings replace lower-precedence ones, not supplement them. This is a good thing because many settings are either/or - what would you do if your user settings had "highlight_line": false while a project had "highlight_line": true, for example?
A plugin should be able to do the trick. sublime.Window contains the project_data() and set_project_data() methods, which allow you to retrieve and write project settings, respectively. You could add a "more_folder_exclude_patterns" key to each folder in your project with the additional patterns you would like to add to the defaults set in your Preferences.sublime-settings file. The plugin could then check if the "more" key exists, read both arrays, concatenate them, and write the result back to the .sublime-project file, erasing the "more" key at the same time. Finally, you could set up an event listener to run the plugin whenever you wanted - on save, upon loading a new file, etc.
EDIT
Here's a working example:
import sublime
import sublime_plugin
from copy import deepcopy
class ModifyExcludedFoldersCommand(sublime_plugin.WindowCommand):
def run(self):
proj_data = self.window.project_data() # dict
orig_proj_data = deepcopy(proj_data) # for comparison later
settings = sublime.load_settings("Preferences.sublime-settings")
fep = settings.get("folder_exclude_patterns") # list
for folder in proj_data["folders"]:
try:
if folder["folder_exclude_patterns"]:
break # if f_e_p is already present, our work is done
except KeyError:
pass # if it doesn't exist, move on to mfep
try:
mfep = folder["more_folder_exclude_patterns"]
new_fep = sorted(list(set(fep + mfep))) # combine f_e_p from
# Preferences and project,
# excluding duplicates using
# a set.
folder["folder_exclude_patterns"] = new_fep
del folder["more_folder_exclude_patterns"]
except KeyError:
pass # if mfep doesn't exist, just move on to the next folder
if proj_data != orig_proj_data:
self.window.set_project_data(proj_data)
class UpdateProjectData(sublime_plugin.EventListener):
def on_activated(self, view):
window = view.window()
window.run_command("modify_excluded_folders")
Save the file as Packages/User/modify_excluded_folders.py (where Packages is the folder opened when selecting Preferences -> Browse Packages...) and it should go into effect immediately. It will run each time a view is activated. It checks for the presence of a "folder_exclude_patterns" array in each folder defined in the current .sublime-project file, and if found it assumes everything is OK and passes on to the next folder. If that array is not found, it then checks for the presence of a "more_folder_exclude_patterns" array. If found, it does its magic and merges the contents with the existing "folder_exclude_patterns" array from your preferences (Default or User). It then writes a new "folder_exclude_patterns" array into the folder and deletes the "more_folder_exclude_patterns" array. Finally, it checks to see if any changes were made, and if so it writes the new data back to the .sublime-project file.
Is it possible to get a value from the environment variables defined at local.properties configuration file and access it via the impex file?
Ex.
$someMacro=<some variable from config>
Thank you!
You can add this to your impex:
# Import config properties into impex macros
UPDATE GenericItem[processor=de.hybris.platform.commerceservices.impex.impl.ConfigPropertyImportProcessor];pk[unique=true]
All your configurations from local.properties, etc. are now loaded and can be used via $config- prefix, say for example:
local.properties
your.config.property=322
So your impex would look something like:
# Import config properties into impex macros
UPDATE GenericItem[processor=de.hybris.platform.commerceservices.impex.impl.ConfigPropertyImportProcessor];pk[unique=true]
$variable=$config-your.config.property
INSERT_UPDATE SampleItem;code[unique=true];name
;sample1;$variable
# OR you can just directly use the config macro
INSERT_UPDATE SampleItem;code[unique=true];name
;sample1;$config-your.config.property
Hope this works for you.
EDIT: Please also note that if there was no such property found, the value stored on the sample above shall be exactly: $config-your.config.property.
To complete #Atsusa Kai answer, the line with a header alone can be avoided.
It's quite ugly to have this line just to load the properties... but that's actually what is mentionned in the ConfigPropertyImportProcessor class comment :
/**
* Impex ImportProcessor that injects all config properties as impex definitions.
* All defined configuration properties are added as impex macro definitions with
* the prefix of "config-". For example the config key <tt>mail.smtp.server</tt>
* can be accessed via the macro <tt>$config-mail.smtp.server</tt>.
* In order to use this import processor and to load the configuration properties
* the following must be added to the top of the impex file:
*
* <tt>UPDATE GenericItem[processor=de.hybris.platform.commerceservices.impex.impl.ConfigPropertyImportProcessor];pk[unique=true]</tt>
*/
The alternative is to used a beanshell command that are tailored for this kind of action.
You can replace the UPDATE GenericItem line by
#%new de.hybris.platform.commerceservices.impex.impl.ConfigPropertyImportProcessor().init(impex)
but you need to enable code execution.
How can I change the .eclipse folder in Linux? I tried adding this line:
-Dosgi.configuration.area=/directory/directory1/eclipse/.eclipse
at the top of eclipse.ini but it doesn't work. I've also tried adding it to various other places in the eclipse.ini but still no luck.
Edit
I have added this line:
-Dosgi.configuration.area=file:/directory/directory1/eclipse/.eclipse
immediately below -vmargs. When Eclipse starts, it now reads from the correct .eclipse location and if .eclipse does not exist there, it creates it. Unfortunately, after Eclipse has loaded, another .eclipse folder is created in my home folder and Eclipse then continues to read from that folder. I suspect that my eclipse.ini file is now correct but there is another file I need to change.
The simplest thing to do is probably pass java a different user.home so that all the other myriad of places that derive a location base it off of user.home. So instead of what you have, use this in .ini file:
-Duser.home=/directory/other/here
In addition to .eclipse, you will probably find other directories created in your overridden user.home, such as .p2, .oracle_jre_usage, etc.
Other notes:
-Dosgi.configuration.area is the changes the configuration area for Eclipse, it does not effect user area. You also probably don't want to change that setting away from the default unless you really want multiple configurations (read more below).
Additionally, the normal thing to do would be to use -configuration as an argument to eclipse{.exe} and let eclipse convert it to the appropriate VM argument.
You probably want -user though to override the user area. Have a look at locations in the Eclipse help for more info (quoted below).
However, there are still things that have individual control over their location, such as secure storage, which is controlled by the -eclipse.keyring command line argument.
Locations
The Eclipse runtime defines a number of locations which give
plug-in developers context for reading/storing data and Eclipse users
a control over the scope of data sharing and visibility. Eclipse
defines the following notions of location:
User (-user) {osgi.user.area} [#none, #noDefault, #user.home,
#user.dir, filepath, url]
User locations are specific to, go figure,
users. Typically the user location is based on the value of the Java
user.home system property but this can be overridden. Information such
as user scoped preferences and login information may be found in the
user location.
Install (-install) {osgi.install.area} [#user.home,
#user.dir, filepath, url]
An install location is where Eclipse itself
is installed. In practice this location is the directory (typically
"eclipse") which is the parent of the eclipse.exe being run or the
plugins directory containing the org.eclipse.equinox.launcher bundle.
This location should be considered read-only to normal users as an
install may be shared by many users. It is possible to set the install
location and decouple eclipse.exe from the rest of Eclipse.
Configuration (-configuration) {osgi.configuration.area} [#none,
#noDefault, #user.home, #user.dir, filepath, url]
Configuration
locations contain files which identify and manage the (sub)set of an
install to run. As such, there may be many configurations per install.
Installs may come with a default configuration area but typical
startup scenarios involve the runtime attempting to find a more
writable configuration location.
Instance (-data) {osgi.instance.area}
[#none, #noDefault, #user.home, #user.dir, filepath, url]
Instance
locations contain user-defined data artifacts. For example, the
Resources plug-in uses the instance area as the workspace location and
thus the default home for projects. Other plugins are free to write
whatever files they like in this location.
While users can set any of
these locations, Eclipse will compute reasonable defaults if values
are not given. The most common usecase for setting location is the
instance area or, in the IDE context, the workspace. To run the
default Eclipse configuration on a specific data set you can specify:
eclipse -data c:\mydata
You must put property definitions like this at the end of the eclipse.ini after the -vmargs line. If there is no -vmargs line you must add one.
So:
.... other lines ....
-vmargs
... other arguments
-Dosgi.configuration.area=/directory/directory1/eclipse.eclipse
I need to take different actions based on what config file is passed at the time the server is started.
I have three config files -- prod.ini, dev.ini and test.ini.
When I do
pserve test.ini
I want to be able to know, within code, that test.ini has been passed. Is there any way to do it?
I checked config.registry.settings -- but it does not have anything.
The only other option I have is to specify an env directive within the INI files and then access it -- which is easy. But I didn't want to do the extra work and have to remember to do it for every new INI file I create.
WSGI entry point should look like:
def main(global_config, **settings):
""" This function returns a Pyramid WSGI application.
If my memory doesn't server me incorrectly, there should be global_config["__file__"] which is the configuration INI filename.
However what I usually do is that inside the INI file itself you specify a variable mode = production or mode = test, etc.