Permalink
Browse files

Merge branch 'master' of git://github.com/projectodd/polyglot-openshi…

…ft-example
  • Loading branch information...
2 parents aaf7707 + 83f5914 commit 32e77f985c2b6bafdeb5feeb30864a38f2ca087e @jcrossley3 jcrossley3 committed Mar 28, 2012
@@ -1,3 +0,0 @@
-Place your jboss-as7 modules in this directory. This directory is added to the
-module path of the jboss-as7 server associated with your application. It has the
-same structure as the jboss-as7/modules directory.
@@ -1,22 +0,0 @@
-Run scripts or jobs on a periodic basis
-=======================================
-Any scripts or jobs added to the minutely, hourly, daily, weekly or monthly
-directories will be run on a scheduled basis (frequency is as indicated by the
-name of the directory) using run-parts.
-
-run-parts ignores any files that are hidden or dotfiles (.*) or backup
-files (*~ or *,) or named *.{rpmsave,rpmorig,rpmnew,swp,cfsaved}
-
-The presence of two specially named files jobs.deny and jobs.allow controls
-how run-parts executes your scripts/jobs.
- jobs.deny ===> Prevents specific scripts or jobs from being executed.
- jobs.allow ===> Only execute the named scripts or jobs (all other/non-named
- scripts that exist in this directory are ignored).
-
-The principles of jobs.deny and jobs.allow are the same as those of cron.deny
-and cron.allow and are described in detail at:
- http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/ch-Automating_System_Tasks.html#s2-autotasks-cron-access
-
-See: man crontab or above link for more details and see the the weekly/
- directory for an example.
-
No changes.
No changes.
No changes.
No changes.
@@ -1,16 +0,0 @@
-Run scripts or jobs on a weekly basis
-=====================================
-Any scripts or jobs added to this directory will be run on a scheduled basis
-(weekly) using run-parts.
-
-run-parts ignores any files that are hidden or dotfiles (.*) or backup
-files (*~ or *,) or named *.{rpmsave,rpmorig,rpmnew,swp,cfsaved} and handles
-the files named jobs.deny and jobs.allow specially.
-
-In this specific example, the chronograph script is the only script or job file
-executed on a weekly basis (due to white-listing it in jobs.allow). And the
-README and chrono.dat file are ignored either as a result of being black-listed
-in jobs.deny or because they are NOT white-listed in the jobs.allow file.
-
-For more details, please see ../README.cron file.
-
@@ -1 +0,0 @@
-Time And Relative D...n In Execution (Open)Shift!
@@ -1,3 +0,0 @@
-#!/bin/bash
-
-echo "`date`: `cat $(dirname \"$0\")/chrono.dat`"
@@ -1,12 +0,0 @@
-#
-# Script or job files listed in here (one entry per line) will be
-# executed on a weekly-basis.
-#
-# Example: The chronograph script will be executed weekly but the README
-# and chrono.dat files in this directory will be ignored.
-#
-# The README file is actually ignored due to the entry in the
-# jobs.deny which is checked before jobs.allow (this file).
-#
-chronograph
-
@@ -1,7 +0,0 @@
-#
-# Any script or job files listed in here (one entry per line) will NOT be
-# executed (read as ignored by run-parts).
-#
-
-README
-
View
@@ -1,15 +0,0 @@
-Markers
-===========
-
-Adding marker files to this directory will have the following effects:
-
-enable_jpda - Will enable the JPDA socket based transport on the java virtual
- machine running the JBoss AS 7 application server. This enables
- you to remotely debug code running inside the JBoss AS 7
- application server.
-
-skip_maven_build - Maven build step will be skipped
-
-force_clean_build - Will start the build process by removing all non
-essential Maven dependencies. Any current dependencies specified in
-your pom.xml file will then be re-downloaded.
View
146 README
@@ -1,146 +0,0 @@
-Repo layout
-===========
-deployments/ - location for built wars (Details below)
-src/ - Maven src structure
-pom.xml - Maven build file
-.openshift/ - location for openshift specific files
-.openshift/config/ - location for configuration files such as standalone.xml (used to modify jboss config such as datasources)
-../data - For persistent data (also in env var OPENSHIFT_DATA_DIR)
-.openshift/action_hooks/pre_build - Script that gets run every git push before the build (on the CI system if available)
-.openshift/action_hooks/build - Script that gets run every git push as part of the build process (on the CI system if available)
-.openshift/action_hooks/deploy - Script that gets run every git push after build but before the app is restarted
-.openshift/action_hooks/post_deploy - Script that gets run every git push after the app is restarted
-
-
-Details about layout and deployment options
-==================
-There are two options for deploying content to the JBoss Application Server within OpenShift Express:
-
-1) (Preferred) You can upload your content in a Maven src structure as is this sample project and on
-git push have the application built and deployed. For this to work you'll need your pom.xml at the
-root of your repository and a maven-war-plugin like in this sample to move the output from the build
-to the deployments directory. By default the warName is ROOT within pom.xml. This will cause the
-webapp contents to be rendered at http://app_name-namespace.rhcloud.com/. If you change the warName in
-pom.xml to app_name, your base url would then become http://app_name-namespace.rhcloud.com/app_name.
-
-Note: If you are building locally you'll also want to add any output wars/ears under deployments
-from the build to your .gitignore file.
-
-or
-
-2) You can git push prebuilt wars (with the corresponding .dodeploy file for exploded wars) into deployments/. To do this
-with the default repo you'll want to first run 'git rm -r src/ pom.xml' from the root of your repo.
-
-Basic workflows for deploying prebuilt content (each operation will require associated git add/commit/push operations to take effect):
-
-A) Add new zipped content and deploy it:
-
-1. cp target/example.war deployments/
-
-B) Add new unzipped content and deploy it:
-
-1. cp -r target/example.war/ deployments/
-2. touch deployments/example.war.dodeploy
-
-C) Undeploy currently deployed content:
-
-1. git rm deployments/example.war.dodeploy deployments/example.war
-
-D) Replace currently deployed zipped content with a new version and deploy it:
-
-1. cp target/example.war deployments/
-
-E) Replace currently deployed unzipped content with a new version and deploy it:
-
-1. git rm -rf deployments/example.war/
-2. cp -r target/example.war/ deployments/
-3. touch deployments/example.war.dodeploy
-
-WARNING: If you go with option 2) there are a couple issues to keep in mind with both prebuilt and exploded
-wars. With exploded wars the main issue is with committing binaries (class and jar files) can make merge
-conflicts tedious. With prebuilt wars the main issue is each time you modify the war and git push, it
-takes up the size of the war file away from your OpenShift file system quota. One alternative to this
-(other then using Maven from option 1) is to use rsync to push your war into the deployments folder. You
-would have to do this after each git push followed by 'rhc app restart -a appname'. Example:
-
-rsync -avz localdir/deployments/ app_uuid@appname-namespace.rhcloud.com:~/appname/repo/deployments/
-
-Note: You can get the information in the uri above from running 'rhc domain show'
-
-If you have already committed large files to your git repo, you rewrite or reset the history of those files in git
-to an earlier point in time and then 'git push --force' to apply those changes on the remote OpenShift server. A
-git gc on the remote OpenShift repo can be forced with (Note: tidy also does other cleanup including clearing log
-files and tmp dirs):
-
-rhc app tidy -a appname
-
-
-Whether you choose option 1) or 2) the end result will be the application
-deployed into the deployments directory. The deployments directory in the
-JBoss Application Server distribution is the location end users can place
-their deployment content (e.g. war, ear, jar, sar files) to have it
-automatically deployed into the server runtime.
-
-The filesystem deployment scanner in AS 7 and later works differently from
-previous JBoss AS releases. The scanner will no longer attempt to directly
-monitor the deployment content and decide if or when the end user wishes
-the content to be deployed. Instead, the scanner relies on a system of marker
-files, with the user's addition or removal of a marker file serving as a sort
-of command telling the scanner to deploy, undeploy or redeploy content.
-
-The marker files always have the same name as the deployment content to which
-they relate, but with an additional file suffix appended. For example, the
-marker file to indicate the example.war should be deployed is named
-example.war.dodeploy. Different marker file suffixes have different meanings.
-
-The relevant marker file types are:
-
-.dodeploy -- Placed by the user to indicate that the given content should
- be deployed into the runtime (or redeployed if already
- deployed in the runtime.)
-
-.deploying -- Placed by the deployment scanner service to indicate that it
- has noticed a .dodeploy file and is in the process of
- deploying the content. This marker file will be deleted when
- the deployment process completes.
-
-.deployed -- Placed by the deployment scanner service to indicate that the
- given content has been deployed into the runtime. If an end
- user deletes this file, the content will be undeployed.
-
-.faileddeploy -- Placed by the deployment scanner service to indicate that the
- given content failed to deploy into the runtime. The content
- of the file will include some information about the cause of
- the failure.
-
-.undeploying -- Placed by the deployment scanner service to indicate that it
- has noticed a .deployed file has been deleted and the
- content is being undeployed. This marker file will be deleted
- when the undeployment process completes.
-
-.undeployed -- Placed by the deployment scanner service to indicate that the
- given content has been undeployed from the runtime. If an end
- user deletes this file, it has no impact.
-
-
-Environment Variables
-=====================
-
-OpenShift Express provides several environment variables to reference for ease
-of use. The following list are some common variables but far from exhaustive:
-
- System.getenv("OPENSHIFT_GEAR_NAME") - Application name
- System.getenv("OPENSHIFT_GEAR_DIR") - Application dir
- System.getenv("OPENSHIFT_DATA_DIR") - For persistent storage (between pushes)
- System.getenv("OPENSHIFT_TMP_DIR") - Temp storage (unmodified files deleted after 10 days)
-
-When embedding a database using 'rhc app cartridge add', you can reference environment
-variables for username, host and password:
-
- System.getenv("OPENSHIFT_DB_HOST") - DB host
- System.getenv("OPENSHIFT_DB_PORT") - DB Port
- System.getenv("OPENSHIFT_DB_USERNAME") - DB Username
- System.getenv("OPENSHIFT_DB_PASSWORD") - DB Password
-
-To get a full list of environment variables, simply add a line in your
-.openshift/action_hooks/build script that says "export" and push.

0 comments on commit 32e77f9

Please sign in to comment.