I have a doubt over this question
Question: What is the correct order of precedence to setup runmodes in aem? (From left to right, left beign the highest)?
A. System property, Sling properties file, jar file
B. jar file, sling properties file, system property
C. Sling properties file, jar file, system property
D. jar file, System property, Sling properties file
Answer : B
I had gone through various docs and had done multiple experiments over this.
Acc to Adobe documentation the order is - Sling.properties, System property, jar file
Similarly, this Adobe doc has a contradictory opinion - jar file, sling.properties, system property
Also, Apache Sling Doc says that any property to option D (-D) set in manner, n=v, overwrites same named properties in the sling.properties file. which means system property has higher precedence then sling.properties.
Now, these are all according to docs, what I had experimented is-
I made a path ${dir}/crx-quickstart/conf and created a file sling.properties and wrote sling.run.modes=publish. Then renamed the jar file as cq-author-7502.jar. Then run this jar with the command java -jar cq-author-7502.jar -Dsling.run.modes=prod
This is my observation:
1. When the jar runs, Setting 'sling.run.modes' to 'publish' from sling.properties. this message is shown in the terminal.
2. The instance up in author mode. And
3. When I checked the instance-mode in felix console, it was prod
I am totally confused about the order of precedence. As everything seems contradictory to me.
It would be grateful if anyone can put some light on it..
Thank you
I think it depends on when we are checking the run mode precedence, at the time of installation or later on a running instance and how we are starting our instance. There are 2 kinds of run modes. Installation time run mode, custom run modes.
Installation time run mode - As explained by official run modes documentation and setup instructions, this can be set only one time at the time of installation. This includes author,publish,nosamplecontent,samplecontent
Custom run mode - Own customized run modes e.g. dev, qa, prod etc
I did some tests (AEM 6.1), precedence is working in following way
Initial setup
Start jar (by double clicking) - In this you do not have option to set run mode in sling.properties, start script first time. JAR name takes precedence.
Unpack jar and specify run mode as system properties in start script - JAR name doesn't comes to picture here. In this you do not have option to set run mode in sling.properties. System properties takes precedence.
Running instance
Even if we change run mode in JAR name, it doesn't changes the installation time run mode. For custom run mode, JAR file name is not applicable. Order of precedence is sling.properties -> specifying -r option (command line jar option) -> system properties (start script)
As far as the question (seems to be AEM certification question), the context is not clear with respect to which they are asking. Helpx article is contributed by community, context might be different. Sling documentation link (it seems as per this link the launchpad version in AEM is old, not 2.4.0). Need to ask Adobe to confirm :).
There are two conflicting Adobe articles that say something quite different
Article 1: (Assumed more recent)
Starting CQ with a specific run mode If you have defined
configurations for multiple run modes then you need to define which is
to be used upon startup. There are several methods for specifying
which run mode to use; the order of resolution is:
sling.properties file
-r option
system properties (-D)
Filename detection
From this Reference: Configure Run Modes
- the answer is C
Article 2:
Behavior when run modes are specified more than one way The run mode
specified in the naming of the jar file takes precedence. If run modes
are not specified in the naming of the jar file, the values in the
sling.properties file are used. If run modes are not specified in
either the naming of the jar file or the sling.properties file, the
system property (or JVM argument) is used.
From this Reference: Configure Run Modes
- the answer is B
However based on my experience and based on process of elimination I'd go with answer B.
Related
Given a build.sbt which is committed to a code repository, what is a general pattern which allows users to override setting values defined in this script?
On the surface, this appears to have been answered in Where should local settings (per user, and not version-controlled) go in newer (0.10+) versions of SBT?. The answer there is to simply define two scripts in the same directory -- build.sbt and local.sbt, and rely on the fact that sbt will combine these scripts together. This may work for augmenting values (i.e., appending lists), but I don't see how it works for overriding the script value, since if a setting's value is set in both scripts, I don't know which of the two values will survive after sbt has combined the scripts.
It could be that I'm missing something very simple.
I'd recommend using ~/.sbt/0.13 global directory where your .sbt files are processed during project load and after the other files in the project itself.
I found ~/.sbt/0.13/global.sbt a good place for global settings - the name always hints me for its purpose.
I have different logs locations in development and in production, they also may be different platforms, so I want to configure the logs just one time using a environment variable.
Possible locations:
C:/logs/
T:/logs/
/var/logs/
In this question they need just that, but it is applied to Java and is using the Java system properties, obviously not available in C++.
So, is there a way to use a environment variable in the log4cxx config file?
It works just the same way as in Java.
For example, in an XML configuration read with log4cxx::xml::DOMConfigurator::configure, containing <param name="file" value="${LOG_DIR}/traces.log"/>, the environment variable LOG_DIR will be correctly substituted. Tested on Linux/Ubuntu 12.01 with log4cxx 0.9.7.
Also see my question and the answer here: https://mail-archives.apache.org/mod_mbox/logging-log4cxx-user/201403.mbox/%3C1378908733.20140324173531%40am-soft.de%3E
in my project, I want to refer to an other xcconfig file, located in InDesign SDK. As this SDK may be installed at different locations, depending upon the machine, I prefer to declare an environment variable for locating it.
Nest step is obviously to use variable (aptly named ID_CS5_SDK_DIR) in my xcconfig include directive.
Unfortunatly, when I try the simple
// InDesign sdk project build settings (based on common build settings)
#include "$(ID_CS5_SDK_ROOT)/build/mac/prj/_shared_build_settings/common.xcconfig"
XCode throws me a
[WARN]AutocatPlugin.xcconfig line 7: Unable to find included file "$(ID_CS5_SDK_ROOT)/build/mac/prj/_shared_build_settings/common.xcconfig"
How can I make it work ?
I've been trying to do this too and also came to the conclusion that it is not possible.
I once tried to achieve that and came to the conclusion that you can't. I would be happy if someone proves us it's possible though then delete my answer
It seems like .xcconfig files can only DEFINE and set value to environment variables (which prevail only throughout the build session) but not USE or evaluate environment variables.
Maybe it is because .xcconfig files serve as a base layer of build-settings, and are not parsed.
Unfortunately this is not possible, but instead of making one include the other, you can use two different xcconfig files per target. Just select one for the Project and one for the Target.
If you put the environment variable in /etc/config/launchd.conf and then reboot it will be accessible to the .xcconfig file.
Short Instructions for experienced users:
Edit the read-only file /etc/launchd.conf and add 'setenv VARIABLENAME /FOLDER/PATH' to the file, then reboot.
Steps For Inexperienced Users
Open Application/Utilities/Terminal, and entersudo nano /etc/launchd.conf
Create the Environment Variable by adding a line like setenv VARIABLENAME FOLDER/PATH and then pressing ENTER.
Save the file using Ctrl-O, Ctrl-M, (Possibly Ctrl-Y to overwrite), then Ctrl-X to exit the editor.
(Optional) type cat /etc/launchd.conf to see that your changes are present
Restart your computer. (Logoff doesn't work)
You can now access the variable in your .xcconfig file as$(VARIABLENAME)
Notes:
This creates a GLOBAL environment variable, accessible to all users. It probably doesn't make sense to set this to something in your home directory (e.g ~/MyFolder). If you do this, however, you need to use the full pathname, such as /Users/MyUserName/MyFolder).
References:
Stack Overflow - Setting Environment Variables in OSX
Stack Overflow - Are there any differences between /etc and /private /etc
I am fighting with Xcode 4 workspaces. Currently Xcode 4 wins. Thus, my situation:
I have the workspace with the iOS app project. There is also static library project iOS app depends on in the this workspace.
Solution #1
I try to configure like this:
the app project:
add to target's Build Phases > Link Binary With Library a product (libmystaticlib.a);
set USER_HEADER_SEARCH_PATHS to $(TARGET_BUILD_DIR)/usr/local/include $(DSTROOT)/usr/local/include;
the static library project:
add some header files to target's Build Phases > Copy Headers > Public;
set SKIP_INSTALL to YES.
And important thing: both projects must have configurations named the same. Otherwise, if I have, e.g., configuration named Distribution (Ad Hoc) for the app and Release for the static library, Xcode can't link the app with the library.
With this configuration archiving results to an archive with the application and public headers from static library projects. Of course, I am not able to share *.ipa in this case. :(
Solution #2
I have also tried another configuration:
Xcode preferences:
set source tree for the static library, e.g, ADDITIONS_PROJECT;
the app project:
add to target's Build Phases > Link Binary With Library a product (libmystaticlib.a);
set USER_HEADER_SEARCH_PATHS to $(ADDITIONS_PROJECT)/**;
the static library project:
don't add any header files to Public!;
set SKIP_INSTALL to YES.
I still need to care about configuration names for both projects. But in result I can build and archive successfully. In the result I get archive and I can share *.ipa.
I don't like the second solutions, because in this case I don't get any real advantage of the Xcode 4 workspace. The same effect I can add get, if I add the static lib project inside the app project. Therefore, I think something is wrong with my solution.
Any suggestion how better to link a static libraries?
I also found a solution that works with build and with archive.
In your static library set the Public Headers Folder Path to ../../Headers/YourLib
In your app config set the Header Search Paths to $(BUILT_PRODUCTS_DIR)/../../Headers
In your app you will be able to code #import <YourLib/YourFile.h>
Don't forget the Skip Install = YES option in your static lib.
We've found an answer, finally. Well, kind of. The problem occurred because Xcode 4 places public headers into InstallationBuildProductsLocation folder during build for archive. Apparently, when archiving it sees the headers and tries to put them into archive as well. Changing Public Headers Folder Path of the lib to somewhere outside of InstallationBuildProductsLocation, for example, to $(DSTROOT)/../public_folders and adding this path to Header Search Path solve the problem.
This solution doesn't look very elegant, but for us it seems to be the only option. May be you'll find this useful.
Here is a solution a get from Apple DTS. I don't like it, because it is suggests to use absolute path. But I still publish it here, maybe someone feels it is right for him.
How to set up the static library:
Add a build configuration named "Archive" by copying the Release Configuration.
Move your headers to the Project group of the Copy Headers build phase.
Set the Per-configuration Build Products Path of the "Archive" configuration to $(BUILD_DIR)/MyLibBuildDir. Xcode will create the MyLibBuildDir folder inside the BuildProductsPath, then add your static library into that folder. You can use "MyLibBuildDir" or provide another name for the above folder.
Set Skip Install to YES for all configurations.
Set Installation Directory of "Archive" to $(TARGET_TEMP_DIR)/UninstalledProducts.
Edit its scheme, set the Build Configuration of its Archive action to "Archive."
How to set up the project linking against the library:
Add a build configuration named "Archive" by copying the Release Configuration.
Set the Library Search Paths of "Archive" to $(BUILD_DIR)/MyLibBuildDir.
Set the User Header Search Paths to the recursive absolute path of your root of your workspace directory for all configurations.
Set Always Search User Paths of "Archive" to YES.
Set Skip_Install to NO for all configurations.
Edit its scheme, set the Build Configuration of its Archive action to "Archive."
I was not real happy with any of the other solutions that were provided, so I found another solution that I prefer. Rather than having to use relevant paths to put the /usr/local/include folder outside of the installation directory, I added a pre-action to the Archive step in my scheme. In the pre-action I provided a script that removed the usr directory prior to archiving.
rm -r "$OBJROOT/ArchiveIntermediates/MyAppName/InstallationBuildProductsLocation/usr"
This removes the usr directory before archiving so that it does not end up in the bundle and cause Xcode to think it has multiple modules.
so far I also struggled with the same problem, but did come to a solution with a minimal tradeoff:
This requires Dervied Data to be your Build Location.
I set the Public Headers Folder path to ../usr/local/include
This will ensure, that the headers will not be placed into the archive.
For the app, I set the Header Search Path to:
$(OBJROOT)/usr/local/include
$(SYMROOT)/usr/local/include
There are 2 entries necessary since the paths slightly change when building an archive and I haven't figured out how to describe it with only one variable.
The nice thing here is, that it doesn't break code sense. So except for having 2 entries rather than one, this works perfectly fine.
I'm struggling with the same problem at the moment. I didn't progress much farther than you. I can only add that in the second solution you can drag headers you need to use from the library to the app project, instead of setting ADDITIONS_PROJECT and USER_HEADER_SEARCH_PATH. This will make them visible in app project. Value of SKIP_INSTALL flag doesn't matter in this case.
Still, this solution isn't going to work for me, because I'm moving rather big project, with dozens of libraries, from Xcode 3 to Xcode 4, and it means really a lot of drag and drop to make my project build and archive correctly. Please let us know if you find any better way out of this situation.
I could use Core Plot as a static library and workspace sibling, with two build configurations:
Release:
in project, Header Search Path: "$(BUILT_PRODUCTS_DIR)"
in CorePlot-CocoaTouch, Public Headers Folder Path: /usr/local/include
AdHoc (build configuration for "Archive" step in Scheme, produces a shareable .ipa):
in project, Header Search Path: "$(BUILT_PRODUCTS_DIR)"/../../public_folders/**
in CorePlot-CocoaTouch, Public Headers Folder Path: ../../public_folders
Hope it will help someone to not waste a day on this.
How to monitor version in swf file when we compile a swf file in Adobe Flex file?
Assuming I understand your question correctly, you should check out this blog post of mine, titled "Saving and Accessing Version/Compilation Information with Flex Applications", which goes on to explain how you can use the conditional compilation feature in the mxmlc compiler to save variable values into the compiled binary and then print them to the log (or display in the user interface) within the app itself.
Here are the relevant snippets from that post:
# Compiling the binary with the conditional compilation parameter:
/path/to/mxmlc -define+=DEBUG::compiled,"Fri_Sep_12_17:26:13_on_Alis-MacBook.local" -strict=true /path/to/myApp.mxml
// Printing out the "compiled" value in the application code:
var DEBUG:Namespace = new Namespace("DEBUG");
var compiledStr:String = DEBUG::compiled;
trace("SWF was compiled: "+compiledStr);
As far as the actual "version number" goes, I just use three things:
the compilation date (see the example scripts in the post for info on how to automate this)
the hostname of the computer where it was compiled (also demonstrated in the post)
the SVN revision of the working copy (see my answer to this question for info on how to get the SVN revision number)