Creating template

.gitignore

@@ -0,0 +1 @@
+target

.openshift/action_hooks/build

@@ -0,0 +1,5 @@
+#!/bin/bash
+# This is a simple build script and will be executed on your CI system if 
+# available.  Otherwise it will execute while your application is stopped
+# before the deploy step.  This script gets executed directly, so it
+# could be python, php, ruby, etc.

.openshift/action_hooks/deploy

@@ -0,0 +1,5 @@
+#!/bin/bash
+# This deploy hook gets executed after dependencies are resolved and the
+# build hook has been run but before the application has been started back
+# up again.  This script gets executed directly, so it could be python, php,
+# ruby, etc.

.openshift/action_hooks/post_deploy

@@ -0,0 +1,4 @@
+#!/bin/bash
+# This is a simple post deploy hook executed after your application 
+# is deployed and started.  This script gets executed directly, so 
+# it could be python, php, ruby, etc.

.openshift/action_hooks/pre_build

@@ -0,0 +1,5 @@
+#!/bin/bash
+# This is a simple script and will be executed on your CI system if 
+# available.  Otherwise it will execute while your application is stopped
+# before the build step.  This script gets executed directly, so it
+# could be python, php, ruby, etc.

.openshift/config/modules/README

@@ -0,0 +1,3 @@
+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.

.openshift/cron/README.cron

@@ -0,0 +1,22 @@
+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.
+

.openshift/cron/weekly/README

@@ -0,0 +1,16 @@
+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.
+

.openshift/cron/weekly/chrono.dat

@@ -0,0 +1 @@
+Time And Relative D...n In Execution (Open)Shift!

.openshift/cron/weekly/chronograph

@@ -0,0 +1,3 @@
+#!/bin/bash
+
+echo "`date`: `cat $(dirname \"$0\")/chrono.dat`"

.openshift/cron/weekly/jobs.allow

@@ -0,0 +1,12 @@
+#
+#  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
+

.openshift/cron/weekly/jobs.deny

@@ -0,0 +1,7 @@
+#
+#  Any script or job files listed in here (one entry per line) will NOT be
+#  executed (read as ignored by run-parts).
+#
+
+README
+

.openshift/markers/README

@@ -0,0 +1,15 @@
+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.

README

@@ -0,0 +1,146 @@
+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:
+
+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/ [email protected]:~/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 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.

pom.xml

@@ -0,0 +1,45 @@
+<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
+  <modelVersion>4.0.0</modelVersion>
+  <groupId>ceylon010</groupId>
+  <artifactId>ceylon010</artifactId>
+  <packaging>war</packaging>
+  <version>1.0</version>
+  <name>ceylon010</name>
+  <properties>
+    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
+    <maven.compiler.source>1.6</maven.compiler.source>
+    <maven.compiler.target>1.6</maven.compiler.target>
+  </properties>
+  <dependencies>
+    <dependency>
+      <groupId>org.jboss.spec</groupId>
+      <artifactId>jboss-javaee-6.0</artifactId>
+      <version>1.0.0.Final</version>
+      <type>pom</type>
+      <scope>provided</scope>
+    </dependency>
+  </dependencies>
+  <profiles>
+    <profile>
+     <!-- When built in OpenShift the 'openshift' profile will be used when invoking mvn. -->
+     <!-- Use this profile for any OpenShift specific customization your app will need. -->
+     <!-- By default that is to put the resulting archive into the 'deployments' folder. -->
+     <!-- http://maven.apache.org/guides/mini/guide-building-for-different-environments.html -->
+     <id>openshift</id>
+     <build>
+        <finalName>ceylon010</finalName>
+        <plugins>
+          <plugin>
+            <artifactId>maven-war-plugin</artifactId>
+            <version>2.1.1</version>
+            <configuration>
+              <outputDirectory>deployments</outputDirectory>
+              <warName>ROOT</warName>
+            </configuration>
+          </plugin>
+        </plugins>
+      </build>
+    </profile>
+  </profiles>
+</project>

src/main/webapp/WEB-INF/web.xml

@@ -0,0 +1,19 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<web-app version="3.0"
+         xmlns="http://java.sun.com/xml/ns/javaee"
+         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
+         metadata-complete="false">
+
+         <servlet>
+                  <servlet-name>health</servlet-name>
+                  <jsp-file>/health.jsp</jsp-file>
+         </servlet>
+         <servlet-mapping>
+                  <servlet-name>health</servlet-name>
+                  <url-pattern>/health</url-pattern>
+         </servlet-mapping>
+
+</web-app>
+

src/main/webapp/health.jsp

@@ -0,0 +1 @@
+1