Where does the portal-ext.properties file go before the liferay war file is deployed?
It's typically the folder where your appserver resides. if I remember correctly, glassfish typically has two nested "glassfish" folder - there it'd be within the first.
The best way to explore that yourself (and to be sure) is to put your portal-ext.properties in every location you guess it might be, then startup the server and examine the log. There it mentions which file is being read.
Also, AFAIK portal-ext.properties will also be read from the user's home directory if found there - careful, when you run a server like glassfish, that might be a different user account than your own.
domains/domain1/applications/liferay-portal/WEB-INF/lib/portal-impl.jar >>> /content/
you will find all translation files there.
Related
I have the following directory structure
The circled directories are the paths of the liferay tomcat server and the sdk respectively.
and I have the file build.osama.properties with the following settings :
app.server.parent.dir=D:\sources\lr_bundles\liferay_tomcat\liferay-ce-portal-7.0-ga3
app.server.tomcat.dir=${app.server.parent.dir}/tomcat-8.0.32
and when I try to create a liferay plugin project it keeps saying :
I am using LR 7 ga3 with tomcat 8 and sdk 7 ga3
Try with the slash using the *NIX way, or at least, double the '\', as it may be understood as an escape character.
app.server.parent.dir=D:/sources/lr_bundles/liferay_tomcat/liferay-ce-portal-7.0-ga3
or
app.server.parent.dir=D:\\sources\\lr_bundles\\liferay_tomcat\\liferay-ce-portal-7.0-ga3
and see if it helps.
Regards
If I were you, I'd reinstall the Liferay one more time with brief step-by-step instruction.
In a few words, you should install:
Database (if you want to use custom one)
Liferay Portal
Liferay IDE
Plugins SDK.
In the plugins SDK folder you should copy build.properties file, and change the copied build.propertis file name to build.osama.properties. (check this step one more time, may be your profile is named as Osama instead of osama). Then you should open newly created build.osama.properties file and uncomment following lines:
app.server.type=tomcat
app.server.parent.dir=${sdk.dir}/../bundles
app.server.tomcat.dir=${app.server.parent.dir}/tomcat-7.0.42
app.server.tomcat.deploy.dir=${app.server.tomcat.dir}/webapps
app.server.tomcat.lib.global.dir=${app.server.tomcat.dir}/lib/ext
app.server.tomcat.portal.dir=${app.server.tomcat.dir}/webapps/ROOT
Make sure that app.server.type and app.server.dir properties should be correct.
In my case I had to combine previous answers ('/' instead of Windows' default '\') AND move liferay portal directory to C:/ (and point build.Username.Properties file to this directory).
I'm trying to remove sample data (Welcome screen and everything else) from my Liferay server.
I tried to:
remove all directories from the webapps directory except ROOT directory
create new (blank) portal-ext.properties in ROOT/WEB-inf/classes (there was no portal-ext.properties file)
search via Google :)
Nothing of the above helped. Thank you for your advices.
You might have configured a database, or are using the built-in demo hsql database. This holds all the regular data. If you've configured Liferay to access another database either remove the tables from that database or point to another one. There's also the document library that holds documents and images (the binary content). By default they all live in the data directory, on the same level as your tomcat directory (assuming you use a bundle)
A new blank portal-ext.properties will not help you, as it overrides all the standard values defined in Liferay. If there's no content, you're using all the default. And the file should rather be in ${liferay-home}, e.g. the directory that also has the tomcat directory in a bundle.
As you've removed all content and bundled webapplications anyway, you can also just install a new bundle in another directory and use it, pointing it to a new database.
Thank you everyone in advance... ^^;
My manager asked me to migrate the installed OpenAM (already used) to another machine (newly obtained).
I tried to migrate it by file level.
(.openamcfg folder, openam folder, tomcat whole folder, ...)
But, after file migration... first access to /openam, it showed initial page(wizard) again. (no using installed configurations)
So, I should do first step. (amadmin password setting, and so on...)
Hmm... Is there any solution for pre-installed OpenAm instance migration?
If No, I can tell her there's no migration way.
Migrating the files should be enough, however you must make sure that :
The .openamcfg folder is in Tomcat's home folder
The file inside the .openamcfg folder contains a valid path to the openam folder
The .openamcfg and openam folders can be read/write by the user who runs the Tomcat service
The webapp context (the part of the URL after the server's IP address, typically /openam) stays the same
Also, when you copy the files, you must first properly stop the Tomcat service, especially if you use OpenAM's embedded datastore.
I am looking at the cruisecontrol web dashboard. I can see one farm and one server. However, I don't see any way to add a project?
Is this something I can do with the UI or do I need to edit the config file by hand?
You'll need to edit the ccnet.config file by hand (located within the CruiseControl directory) to add projects. There are some graphical tools to help you do this however you do get used to doing it by hand fairly quickly - just have the documentation near by!
Update: An example of one such tool is http://www.codeplex.com/ccnetconfig
You can use CCNETConfig to edit the config file through an UI although it doesn't support higher version > CruiseControl.NET 1.4.
You have to basically edit the configuration file by hand, however I have it setup so that the raw config file is split into different include files, each of which is setup in my source control system. Then I created a project for the configuration, and then for the whole config. So when something changes in the config, CC.NET itself pulls out the changes, recreates it's config files and the refreshes the system configuration.
This means that anyone can edit the config (if they can access the files in sourcecontrol), and no-one has to go into the program files directory of the CC.NET machine itself.
Not sure whether this answers the question you asked, but this is how our setup works
What files should/should not be stored in the cgi-bin folder/directory on a web server?
Obviously, executable scripts/files that make up a web application, called from a web browser can be stored there.
But is there a common industry opinion about what else can be stored there?
Is there a very strong reason why nothing else apart than the scripts/executables is allowed there?
My preference is to store all files belonging to an application in the cgi-bin directory/folder, as a subfolder off it - for each application.
For example directory cgi-bin/myapplication would contain:
the cgi scripts/executables
datafiles
configuration files
This simplifies installation and also simplifies the steps to run different versions of a application in parallel, e.g. for trialling a new version.
Concerns about security access to non-script files can be addressed by using the correct user permissions and also Apache .htaccess to control access to the directory and files.
It would seem that popular free applications are in favour of this everything-under-one-directory approach: The versions of bugzilla, the free defect and feature tracking tool, e.g. 3.4.4 are offered in this structure, while earlier versions, e.g. 2.x installed bugzilla components to at least three folders.
Drupal, the powerful and popular free content management system also takes this approach of everything-under-one-directory, albeit doesn't use the cgi-bin folder but the approach is the same.
What are your thoughts?
There is nothing special about the cgi-bin folder. It is like any publicly-accessible web folder that has the "allow-script" flag set (or the equivalent for your web server) - something that has become almost meaningless in the world of PHP/JSP and the likes.
You should only store files that you wish to be public in any folder under your webroot. You probably don't want your data and configuration to be downloadable by any user on the internet, so don't keep them in /cgi-bin
Certain servers may try and execute any file in /cgi-bin if requested. This could cause problems, especially if text or data files are executed as shell script.
Applications like Drupal are intended to be easy for anyone to install, regardless of what permissions they may have on their web-host. This is the main reason it keeps everything together. If you have the ability to put files where you want, it is always a good practise to keep non-public files outside of the webroot. If you must keep them under the webroot, then ensure that you use your server's configuration to deny public access to the non-public files.