JBoss7のデータソース設定

JBoss7でのデータソース設定方法を説明したページがあったので書いておく。
コレもボチボチと訳してこかな。
[AS71:DataSource configuration]
https://docs.jboss.org/author/display/AS71/DataSource+configuration

ついでにJBoss7.1のドキュメントも
https://docs.jboss.org/author/display/AS71/Documentation

ちなみにコッチの方が1ページになってて見易い
Data Source Configuration in AS 7
https://community.jboss.org/wiki/DataSourceConfigurationInAS7#Installing_a_JDBC_driver_as_a_module


Data Source Configuration in AS 7

Datasources are configured through the datasource subsystem.

Datasourcesは、datasourceサブシステムを通して構成されます。

Declaring a new datasource consists of two separate steps:

新しいdatasourceを宣言することは、2つの別々のステップから成ります：

You would need to provide a JDBC driver and define a datasource that references the driver you installed.

あなたはJDBCドライバーを提供する必要があって、設置したドライバーを参照文に引用するdatasourceを定めるでしょう。

JDBC Driver Installation

JDBCドライバー・インストール

The recommended way to install a JDBC driver into the application server is to simply deploy it as a regular JAR deployment.

アプリケーション・サーバにJDBCドライバーを設置する推薦された方法は、単に普通にJARをデプロイしてそれを配備することです。

The reason for this is that when you run your application server in domain mode, deployments are automatically propagated to all servers to which the deployment applies;

これの理由は、あなたがドメインモードでアプリケーション・サーバを動かすとき、配備機構が配備があてはまるすべてのサーバーに自動的に伝播されるということです;

thus distribution of the driver JAR is one less thing for you to worry about!

このように、ドライバーJARの配布は、あなたが心配する1つのより少ないものです！

Any JDBC 4-compliant driver will automatically be recognized and installed into the system by name and version.

どんなJDBC 4対応ドライバーでも、名前とバージョンによってシステムに自動的に認識されて、設置されます。

A JDBC JAR is identified using the Java service provider mechanism.

JDBC JARは、Javaサービスプロバイダ・メカニズムを使って確認されます。

Such JARs will contain a text a file named META-INF/services/java.sql.Driver, which contains the name of the class(es) of the Drivers which exist in that JAR.

ファイルがMETA-INF/services/java.sql.Driverという名前をつけたテキストを、そのようなJARsは含みます。そして、それはそのJARの中に存在するドライバーの種類の名前を含みます。

If your JDBC driver JAR is not JDBC 4-compliant, it can be made deployable in one of a few ways.

あなたのJDBCドライバーJARがJDBC 4-対応でないならば、それは2、3の方向の1つで展開できるようになることができます。

Modify the JAR

JARを修正する

The most straightforward solution is to simply modify the JAR and add the missing file.

最も直接の解決は単にJARを修正することで、失っているファイルを加えることです。

You can do this from your command shell by:

あなたは、コマンドシェルから以下によってこうすることができます：

1.Change to, or create, an empty temporary directory.

1.空の一時的なディレクトリに移動、あるいは、作成してください。

2.Create a META-INF subdirectory.

2.META-INFサブディレクトリを作成してください。

3.Create a META-INF/services subdirectory.

3.META-INF/servicesサブディレクトリを作成してください。

4.Create a META-INF/services/java.sql.Driver file which contains one line - the fully-qualified class name of the JDBC driver.

4.META-INF/services/java.sql.Driverファイルを作成し、そのファイルにこの1行含めます-JDBCドライバのフルクラス名

5.Use the jar command-line tool to update the JAR like this:

5.jarコマンドラインツールを使い、このようにJARをアップデートします:

jar \-uf jdbc-driver.jar META-INF/services/java.sql.Driver

For a detailed explanation how to deploy JDBC 4 compliant driver jar, please refer to the chapter "Application Deployment".

JDBC 4対応ドライバー・ジャーを展開するために詳細な説明方法については、章「アプリケーションDeployment」を参照してください。

Datasource Definitions

データソース定義

The datasource itself is defined within the subsystem datasources:

datasource自体は、サブシステムdatasourcesの中で定義されます：

<subsystem xmlns="urn:jboss:domain:datasources:1.0">
    <datasources>
        <datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS">
            <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url>
            <driver>h2</driver>
            <pool>
                <min-pool-size>10</min-pool-size>
                <max-pool-size>20</max-pool-size>
                <prefill>true</prefill>
            </pool>
            <security>
                <user-name>sa</user-name>
                <password>sa</password>
            </security>
        </datasource>
        <xa-datasource jndi-name="java:jboss/datasources/ExampleXADS" pool-name="ExampleXADS">
           <driver>h2</driver>
           <xa-datasource-property name="URL">jdbc:h2:mem:test</xa-datasource-property>
           <xa-pool>
                <min-pool-size>10</min-pool-size>
                <max-pool-size>20</max-pool-size>
                <prefill>true</prefill>
           </xa-pool>
           <security>
                <user-name>sa</user-name>
                <password>sa</password>
           </security>
        </xa-datasource>
        <drivers>
            <driver name="h2" module="com.h2database.h2">
                <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
            </driver>
        </drivers>
  </datasources>

</subsystem>
(See standalone/configuration/standalone.xml)

(standalone/configuration/standalone.xml参照)

As you can see the datasource references a driver by it's logical name.

datasourceがそばにドライバーを参照文に引用するのをあなたが見ることができるように、それは論理的な名前です。

You can easily query the same information through the CLI:

あなたは、CLIによって同じ情報を簡単に問い合わせることができます：

[standalone@localhost:9999 /] /subsystem=datasources:read-resource(recursive=true)
{
    "outcome" => "success",
    "result" => {
        "data-source" => {"java:/H2DS" => {
            "connection-url" => "jdbc:h2:mem:test;DB_CLOSE_DELAY=-1",
            "jndi-name" => "java:/H2DS",
            "driver-name" => "h2",
            "pool-name" => "H2DS",
            "use-java-context" => true,
            "enabled" => true,
            "jta" => true,
            "pool-prefill" => true,
            "pool-use-strict-min" => false,
            "user-name" => "sa",
            "password" => "sa",
            "flush-strategy" => "FailingConnectionOnly",
            "background-validation" => false,
            "use-fast-fail" => false,
            "validate-on-match" => false,
            "use-ccm" => true
        }},
        "xa-data-source" => undefined,
        "jdbc-driver" => {"h2" => {
            "driver-name" => "h2",
            "driver-module-name" => "com.h2database.h2",
            "driver-xa-datasource-class-name" => "org.h2.jdbcx.JdbcDataSource"
        }}
    }
}

[standalone@localhost:9999 /] /subsystem=datasources:installed-drivers-list
{
    "outcome" => "success",
    "result" => [{
        "driver-name" => "h2",
        "deployment-name" => undefined,
        "driver-module-name" => "com.h2database.h2",
        "module-slot" => "main",
        "driver-xa-datasource-class-name" => "org.h2.jdbcx.JdbcDataSource",
        "driver-class-name" => "org.h2.Driver",
        "driver-major-version" => 1,
        "driver-minor-version" => 2,
        "jdbc-compliant" => true
    }]
}
Using the web console or the CLI greatly simplifies the deployment of JDBC drivers and the creation of datasources.

ウェブ・コンソールまたはCLIを使用することは、JDBCドライバーの配備とdatasourcesの創造を大いに単純化します。

The CLI offers a set of commands to create and modify datasources:

CLIは、datasourcesをつくって、修正しなさいという一組の命令を提供します：

[standalone@localhost:9999 /] help
Supported commands:

[...]

data-source - allows to add new, modify and remove existing data sources
xa-data-source - allows add new, modify and remove existing XA data sources

For a more detailed description of a specific command, execute the command with '--help' as the argument.

特定の命令のより仔細な説明のために、引数として『--help』でコマンドを実行してください。

Using security domains

セキュリティ・ドメインの使用

Information can be found at https://community.jboss.org/wiki/JBossAS7SecurityDomainModel
Deployment of -ds.xml files

Starting with JBoss Application Server 7.1.0.Final you have the ability to deploy a -ds.xml file following the schema:

-ds.xmlファイルの配備の情報は、https://community.jboss.org/wiki/JBossAS7SecurityDomainModelで見つかります。

http://docs.jboss.org/ironjacamar/schema/datasources_1_1.xsd

It is mandatory to use a reference to an already deployed / defined entry.
すでに展開された/定義済みのエントリへの参照を使うことは、義務的です。

This feature is primarily intended for development, and thus has a few limitations to be aware of.
この特徴には主に発展を目的として、このように、気づいている2、3の限界があります。
It can not be altered in any of the management interfaces (consle, CLI, etc).
それは、管理インターフェース（コンソール、CLI、その他）の何でも変えられることができません。
Only limited runtime information is available.
限られた実行時情報だけが利用できます。
Also, password vaults and security domains are not deployable, so these can not be bundled with a datasource deployment.
また、パスワード金庫室とセキュリティ・ドメインは展開できないので、これらはdatasource配備とバンドルされることができません。

Component Reference
コンポーネント参照

The datasource subsystem is provided by the IronJacamar project.
datasourceサブシステムは、IronJacamarプロジェクトによって提供されます。
For a detailed description of the available configuration properties, please consult the project documentation.
利用できる構成特性の詳しい説明のために、プロジェクト・ドキュメンテーションを参照してください。

- IronJacamar homepage: http://www.jboss.org/ironjacamar
- Project Documentation: http://www.jboss.org/ironjacamar/docs
- Schema description: http://docs.jboss.org/ironjacamar/userguide/1.0/en-US/html/deployment.html#deployingds_descriptor

Springポートレットでパラメータ付リンクを使ったコントローラ分岐

SpringFrameworkポートレットで、
VIEWモードの中でコントローラ1から、コントローラ2へ画面を移動するのに、
リンクを使って移動する方法を書いておく。
(Spring3.1だからアノテーションでサクっと行くべきなんだろうけど、アノテーションだと、後から見たときに、設定ファイルだけじゃなく、ソースまで追いかけないと、概要が分からなくなるから、 ちょっと使いたくないのよね…)

まず、JSPページこんな風にした場合…

<portlet:renderURL var="vew1">
    <portlet:param name="action" value="view1" />
</portlet:renderURL>

<a href="${vew1}"> 次のページへ</a>

実際ポートレットに出力されるrenderURLは、
パラメータ付URLで、ネーム=action、値=view1になる。
ちなみに「ネーム=action」のactionはSpringのデフォルトに合わせた。

で、このジャンプ先をSpring設定ファイルで指定する。
が、この設定ファイル上で一癖あるので要注意。

まず、ポートレットモードハンドラ

<bean id="portletModeHandlerMapping" class="org.springframework.web.portlet.handler.PortletModeHandlerMapping">
 <property name="order" value="2" />
 <property name="portletModeMap">
  <map>
   <entry key="view" value-ref="viewController" />
   <entry key="edit" value-ref="editController" />
   <entry key="help" value-ref="helpController" />
  </map>
 </property>
</bean>

いつもは「property name="order" value="2"」の設定はしない。
各モードへ入ったあと、ドコに飛んでいくか、だけがあれば充分だから。

次に、パラメータハンドラ

<bean id="parameterHandlerMapping" class="org.springframework.web.portlet.handler.ParameterHandlerMapping">
 <property name="order" value="1" />
 <property name="parameterMap">
  <map>
   <entry key="view1" value-ref="view1Controller" />
  </map>
 </property>
 <property name="interceptors">
  <list>
  <ref bean="parameterMappingInterceptor" />
  </list>
 </property>
</bean>

今回、画面から受け取ったパラメータの値で、移動先コントローラを変えたいので、パラメータハンドラを使う。
これで、画面からリンクで受け取ったパラメータがview1の場合はview1Controllerへジャンプする。
で、要注意なのは「property name="order" value="1"」。
これでパラメータハンドラを、ポートレットモードハンドラより優先度を上にしてあげる。
そうしないと、リンクを押しても画面がジャンプしない。

で、それを踏まえつつ、今回の設定を書いておく。

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://www.springframework.org/schema/p"
    xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="
        http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
        http://www.springframework.org/schema/context
        http://www.springframework.org/schema/context/spring-context-3.0.xsd">

    <bean id="viewController" class="plutoportlet.ViewController">
        <property name="viewName" value="view" />
    </bean>

    <bean id="editController"
        class="org.springframework.web.portlet.mvc.ParameterizableViewController">
        <property name="viewName" value="edit" />
    </bean>

    <bean id="helpController"
        class="org.springframework.web.portlet.mvc.ParameterizableViewController">
        <property name="viewName" value="help" />
    </bean>

    <bean id="portletModeHandlerMapping"
        class="org.springframework.web.portlet.handler.PortletModeHandlerMapping">
        <property name="order" value="2" />
        <property name="portletModeMap">
            <map>
                <entry key="view" value-ref="viewController" />
                <entry key="edit" value-ref="editController" />
                <entry key="help" value-ref="helpController" />
            </map>
        </property>
    </bean>

    <bean id="viewResolver"
        class="org.springframework.web.servlet.view.InternalResourceViewResolver">
        <property name="viewClass"
            value="org.springframework.web.servlet.view.InternalResourceView" />
        <property name="prefix" value="/WEB-INF/jsp/" />
        <property name="suffix" value=".jsp" />
    </bean>

    <bean id="view1Controller" class="plutoportlet.View1Controller">
        <property name="viewName" value="view1" />
    </bean>

    <bean id="parameterMappingInterceptor"
        class="org.springframework.web.portlet.handler.ParameterMappingInterceptor" />

    <bean id="parameterHandlerMapping"
        class="org.springframework.web.portlet.handler.ParameterHandlerMapping">
        <property name="order" value="1" />
        <property name="parameterMap">
            <map>
                <entry key="view1" value-ref="view1Controller" />
            </map>
        </property>
        <property name="interceptors">
            <list>
                <ref bean="parameterMappingInterceptor" />
            </list>
        </property>
    </bean>

</beans>

OpenShiftのLinuxで使えるコマンド

ココに、OpenShiftにSSHログインした後で使用可能なコマンドリストがあったので書いておく。
Remotely Accessing your App with SSH
https://openshift.redhat.com/community/developers/remote-access
ほとんどがLinuxを使ったことがあれば誰でも知ってるコマンドだけどね。

Common Commands

help
Displays a list of common commands to use

ctl_app
control your application

ctl_app start
ctl_app stop
ctl_app restart
ctl_app status

ctl_all
Similar to ctl_app but controlls application and deps like mysql in one command

ctl_all start
ctl_all stop
ctl_all restart
ctl_all status

export
Prints out all available environment variables and their current values which you may use in your application

rm
Removes a file or directory

Use this with care

Remove a file:

rm file

Remove a directory and all files and directories under it

rm -rf

tail_all
Displays the last entries in your log files as they are written to

You can hit ctrl-c to exit this command

ls
List files and directories

ps
List running applications

kill
Kill running applications using the process id found by calling ps

Be careful when using this command as it should only be used to kill runaway processes, otherwise it is preferable to stop them using the appropriate command such as ctl_app stop

mysql
Opens an interactive MySQL shell

mongo
Opens an interactive MongoDB shell

quota
Lists your application's current disk usage

Pluto2.0の日本語文字化け対策

ApachePluto2.0をデフォルトのまま使うと、こんな文字化けが発生する。

1. JSPやポートレットの日本語が文字化けする。
2. 画面からPostした日本語が文字化けする。

で、その対策を書いておく。

対策としては、普通のWEBアプリ同様エンコードをUTF-8に統一すればOK。
今回、その対象となるのが、Plutoのフロントエンドとなるplutoアプリ。
この、plutoアプリのweb.xmlを修正する。
つまり、pluto-2.0.3/webapps/pluto/WEB-INF/web.xmlを修正する。

修正したのが下記XML。
修正内容としては、変更や削除は何もなく、サーブレットパラメータとエンコーディングフィルタの追加のみ。

1. 青文字が、JSPやポートレットの文字化け対策。
   plutoPortalDriverサーブレットのcharsetパラメータにUTF-8を指定する。
   参考情報
   Pluto - Frequently Asked Questions
   http://portals.apache.org/pluto/faq.html
   How can I change the default encoding of the Pluto Portal
   
2. 赤文字が、Postした日本語の文字化け対策。
   Tomcatが持ってるエンコーディングフィルタを使って、ブラウザと送受信するデータをUTF-8と指定する。
   昔はサンプルだったのに、いつのまにやら本体に入ってたのね。

エンコーディングフィルタはともかく、サーブレットパラメータはデフォルトをUTF-8にしてくれればいいのにね。

[web.xml]

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC
        "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
        "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>

  <display-name>Apache Pluto Portal Driver</display-name>

    <filter>

        <filter-name>EncodeFilter</filter-name>

        <filter-class>org.apache.catalina.filters.SetCharacterEncodingFilter</filter-class>

        <init-param>

            <param-name>encoding</param-name>

            <param-value>UTF-8</param-value>

        </init-param>

    </filter>

    <filter-mapping>

        <filter-name>EncodeFilter</filter-name>

        <url-pattern>/*</url-pattern>

    </filter-mapping>

  <context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>/WEB-INF/pluto-portal-driver-services-config.xml</param-value>
  </context-param>

  <filter>
    <filter-name>plutoPortalDriver</filter-name>
    <filter-class>org.apache.pluto.driver.PortalDriverFilter</filter-class>
  </filter>

  <filter-mapping>
    <filter-name>plutoPortalDriver</filter-name>
    <url-pattern>/about.jsp</url-pattern>
  </filter-mapping>

  <filter-mapping>
    <filter-name>plutoPortalDriver</filter-name>
    <url-pattern>/about.jsp/*</url-pattern>
  </filter-mapping>

  <listener>
    <listener-class>org.apache.pluto.driver.PortalStartupListener</listener-class>
  </listener>

  <servlet>
    <servlet-name>plutoPortalDriver</servlet-name>
    <display-name>Pluto Portal Driver</display-name>
    <description>Pluto Portal Driver Controller</description>
    <servlet-class>org.apache.pluto.driver.PortalDriverServlet</servlet-class>

    <init-param>

      <param-name>charset</param-name>

      <param-value>UTF-8</param-value>

   </init-param>

  </servlet>

  <servlet>
    <servlet-name>plutoPortalDriverLogout</servlet-name>
    <display-name>Pluto Portal Driver</display-name>
    <description>Pluto Portal Driver Logout</description>
    <servlet-class>org.apache.pluto.driver.PortalDriverLogoutServlet</servlet-class>
  </servlet>

  <servlet>
    <servlet-name>portletApplicationPublisher</servlet-name>
    <display-name>Portlet Application Publisher</display-name>
    <description>Portlet Application Publisher Service</description>
    <servlet-class>org.apache.pluto.driver.PublishServlet</servlet-class>
  </servlet>

  <servlet>
    <servlet-name>tckDriver</servlet-name>
    <display-name>Pluto TCK Driver</display-name>
    <description>Pluto TCK Driver Controller</description>
    <servlet-class>org.apache.pluto.driver.TCKDriverServlet</servlet-class>
  </servlet>

  <servlet>
    <servlet-name>AboutPortlet</servlet-name>
    <servlet-class>org.apache.pluto.container.driver.PortletServlet</servlet-class>
    <init-param>
      <param-name>portlet-name</param-name>
      <param-value>AboutPortlet</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
  </servlet>

  <servlet>
    <servlet-name>AdminPortlet</servlet-name>
    <servlet-class>org.apache.pluto.container.driver.PortletServlet</servlet-class>
    <init-param>
      <param-name>portlet-name</param-name>
      <param-value>AdminPortlet</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
  </servlet>

  <servlet>
    <servlet-name>PlutoPageAdmin</servlet-name>
    <servlet-class>org.apache.pluto.container.driver.PortletServlet</servlet-class>
    <init-param>
      <param-name>portlet-name</param-name>
      <param-value>PlutoPageAdmin</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
  </servlet>

  <servlet-mapping>
    <servlet-name>plutoPortalDriver</servlet-name>
    <url-pattern>/portal/*</url-pattern>
  </servlet-mapping>

  <servlet-mapping>
    <servlet-name>plutoPortalDriverLogout</servlet-name>
    <url-pattern>/Logout</url-pattern>
  </servlet-mapping>

  <servlet-mapping>
    <servlet-name>portletApplicationPublisher</servlet-name>
    <url-pattern>/admin/Publish</url-pattern>
  </servlet-mapping>

  <servlet-mapping>
    <servlet-name>tckDriver</servlet-name>
    <url-pattern>/tck/*</url-pattern>
  </servlet-mapping>

  <servlet-mapping>
    <servlet-name>AboutPortlet</servlet-name>
    <url-pattern>/PlutoInvoker/AboutPortlet</url-pattern>
  </servlet-mapping>

  <servlet-mapping>
    <servlet-name>AdminPortlet</servlet-name>
    <url-pattern>/PlutoInvoker/AdminPortlet</url-pattern>
  </servlet-mapping>

  <servlet-mapping>
    <servlet-name>PlutoPageAdmin</servlet-name>
    <url-pattern>/PlutoInvoker/PlutoPageAdmin</url-pattern>
  </servlet-mapping>

  <taglib>
    <taglib-uri>http://portals.apache.org/pluto</taglib-uri>
    <taglib-location>/WEB-INF/tld/pluto.tld</taglib-location>
  </taglib>

  <security-constraint>
    <web-resource-collection>
      <web-resource-name>portal</web-resource-name>
      <url-pattern>/portal</url-pattern>
      <url-pattern>/portal/*</url-pattern>
      <http-method>GET</http-method>
      <http-method>POST</http-method>
      <http-method>PUT</http-method>
    </web-resource-collection>
    <auth-constraint>
      <role-name>pluto</role-name>
    </auth-constraint>
  </security-constraint>

  <login-config>
    <auth-method>FORM</auth-method>
    <form-login-config>
      <form-login-page>/login.jsp</form-login-page>
      <form-error-page>/login.jsp?error=1</form-error-page>
    </form-login-config>
  </login-config>

  <security-role>
    <role-name>pluto</role-name>
  </security-role>

</web-app>

OpenShiftDIYのTomcat7用server.xml

OpenShiftにDIYアプリケーションを作成し、その中にTomcat7を作ってみた。
その際に設定のキモだったのがTomcatのserver.xmlだったので、その中身を書いておく。

Liferayや他のアプリケーションサーバでもTomcat7なら、このserver.xmlでいけるかもしれない。
でもLiferayはデプロイ設定を変えないとNGだろうな…、OpenShiftはホームディレクトリに書き込み権限が無いからね。
っと思い、試しにOpenShiftDIYにLiferayをセットアップし、走らせた結果…
起動中に「Killed」が出てきてダウンした。
たぶんメモリ不足か何か使用可能リソース制限に触れたのだと思う。
ならばJetspeed2でどうよ、っと思いJetspeed2を試した結果…
Jetspeed2も起動中に「Killed」でダウン。
主要ポートレットコンテナ2つが使用不可なのが残念。
Pluto2.0は動作可能だから、とりあえずはPluto2.0でいいや。

ココの料金ページによると、無料で使えるFreeは、Gear SizesはSmallがデフォルト。
このSmallだとメモリ容量は512 MB RAMだそうな。Mediumだと1 GB RAMだそうな。
Pricing

ココのコミュニティフォーラム記事によると、デフォルトはスモールサイズらしい。
ミディアムサイズにしたければopenshift@redhat.comにメールを送れってことだった。
Cannot deploy Liferay because of PermGen

20120927 Liferayのクイックスタートがあるので、Liferayを作れるかもしれない
openshift / jbossas7-liferay-quickstart

で、本題に戻って…
DIYの中にTomcatを作る方法は、ココ。
Free Apache Tomcat Hosting in the Cloud for Java Applications? It's Called OpenShift!
https://openshift.redhat.com/community/blogs/free-apache-tomcat-hosting-in-the-cloud-for-java-applications-its-called-openshift

20120918 どうやらshutdown設定とajp設定にIPアドレスを入れないと動かないようになったみたいなので、設定追加

で、今回は各設定を下記のようにした前提。
URL = tomcat-yourdomain.rhcloud.com
OPENSHIFT_INTERNAL_IP = 127.6.99.1

[server.xml]

<?xml version='1.0' encoding='utf-8'?>
<!--
  Licensed to the Apache Software Foundation (ASF) under one or more
  contributor license agreements.  See the NOTICE file distributed with
  this work for additional information regarding copyright ownership.
  The ASF licenses this file to You under the Apache License, Version 2.0
  (the "License"); you may not use this file except in compliance with
  the License.  You may obtain a copy of the License at

      http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.
-->
<!-- Note:  A "Server" is not itself a "Container", so you may not
     define subcomponents such as "Valves" at this level.
     Documentation at /docs/config/server.html
 -->
<Server port="15005" shutdown="SHUTDOWN" address="127.6.99.1" >
  <!-- Security listener. Documentation at /docs/config/listeners.html
  <Listener className="org.apache.catalina.security.SecurityListener" />
  -->
  <!--APR library loader. Documentation at /docs/apr.html -->
  <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
  <!--Initialize Jasper prior to webapps are loaded. Documentation at /docs/jasper-howto.html -->
  <Listener className="org.apache.catalina.core.JasperListener" />
  <!-- Prevent memory leaks due to use of particular java/javax APIs-->
  <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
  <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
  <Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />

  <!-- Global JNDI resources
       Documentation at /docs/jndi-resources-howto.html
  -->
  <GlobalNamingResources>
    <!-- Editable user database that can also be used by
         UserDatabaseRealm to authenticate users
    -->
    <Resource name="UserDatabase" auth="Container"
              type="org.apache.catalina.UserDatabase"
              description="User database that can be updated and saved"
              factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
              pathname="conf/tomcat-users.xml" />
  </GlobalNamingResources>

  <!-- A "Service" is a collection of one or more "Connectors" that share
       a single "Container" Note:  A "Service" is not itself a "Container",
       so you may not define subcomponents such as "Valves" at this level.
       Documentation at /docs/config/service.html
   -->
  <Service name="Catalina">

    <!--The connectors can use a shared executor, you can define one or more named thread pools-->
    <!--
    <Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
        maxThreads="150" minSpareThreads="4"/>
    -->


    <!-- A "Connector" represents an endpoint by which requests are received
         and responses are returned. Documentation at :
         Java HTTP Connector: /docs/config/http.html (blocking & non-blocking)
         Java AJP  Connector: /docs/config/ajp.html
         APR (HTTP/AJP) Connector: /docs/apr.html
         Define a non-SSL HTTP/1.1 Connector on port 8080
    -->
    <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               address="127.6.99.1"
               redirectPort="15443" />
    <!-- A "Connector" using the shared thread pool-->
    <!--
    <Connector executor="tomcatThreadPool"
               port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" />
    -->
    <!-- Define a SSL HTTP/1.1 Connector on port 8443
         This connector uses the JSSE configuration, when using APR, the
         connector should be using the OpenSSL style configuration
         described in the APR documentation -->
    <!--
    <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
               maxThreads="150" scheme="https" secure="true"
               clientAuth="false" sslProtocol="TLS" />
    -->

    <!-- Define an AJP 1.3 Connector on port 8009 -->
    <Connector port="15009" protocol="AJP/1.3" redirectPort="8443" address="127.6.99.1" />


    <!-- An Engine represents the entry point (within Catalina) that processes
         every request.  The Engine implementation for Tomcat stand alone
         analyzes the HTTP headers included with the request, and passes them
         on to the appropriate Host (virtual host).
         Documentation at /docs/config/engine.html -->

    <!-- You should set jvmRoute to support load-balancing via AJP ie :
    <Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
    -->
    <Engine name="Catalina" defaultHost="127.6.99.1">

      <!--For clustering, please take a look at documentation at:
          /docs/cluster-howto.html  (simple how to)
          /docs/config/cluster.html (reference documentation) -->
      <!--
      <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
      -->

      <!-- Use the LockOutRealm to prevent attempts to guess user passwords
           via a brute-force attack -->
      <Realm className="org.apache.catalina.realm.LockOutRealm">
        <!-- This Realm uses the UserDatabase configured in the global JNDI
             resources under the key "UserDatabase".  Any edits
             that are performed against this UserDatabase are immediately
             available for use by the Realm.  -->
        <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
               resourceName="UserDatabase"/>
      </Realm>

      <Host name="tomcat-yourdomain.rhcloud.com"  appBase="webapps"
            unpackWARs="true" autoDeploy="true">

        <!-- SingleSignOn valve, share authentication between web applications
             Documentation at: /docs/config/valve.html -->
        <!--
        <Valve className="org.apache.catalina.authenticator.SingleSignOn" />
        -->

        <!-- Access log processes all example.
             Documentation at: /docs/config/valve.html
             Note: The pattern used is equivalent to using pattern="common" -->
        <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
               prefix="localhost_access_log." suffix=".txt"
               pattern="%h %l %u %t "%r" %s %b" />

      </Host>
    </Engine>
  </Service>
</Server>

Pluto2.0用ポートレット設定

Apache Pluto2.0用ポートレットに必要な設定を書いておく。

今回のポートレットはplutoPortletと名づけた。

1.まずportlet.xml。

<?xml version="1.0"?>
<portlet-app xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd"
version="2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd">
<portlet>
<description>plutoPortlet</description>

<portlet-name>plutoPortlet</portlet-name>

<display-name>plutoPortlet</display-name>
<portlet-class>plutoportlet.MyPortlet</portlet-class>
<supports>
<mime-type>text/html</mime-type>
<portlet-mode>view</portlet-mode>
</supports>
<portlet-info>
<title>plutoPortlet</title>
<short-title>plutoPortlet</short-title>
<keywords>plutoPortlet</keywords>
</portlet-info>
</portlet>
</portlet-app>

通常のポートレット用設定だが、 portlet-nameはPluto用にweb.xmlを設定する際、必要になるので注意しとく。

2.次にweb.xml

<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" 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">
    <servlet>
        <servlet-name>plutoPortlet</servlet-name>
        <servlet-class>org.apache.pluto.container.driver.PortletServlet</servlet-class>
        <init-param>
            <param-name>portlet-name</param-name>
            <param-value>plutoPortlet</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>plutoPortlet</servlet-name>
        <url-pattern>/PlutoInvoker/plutoPortlet</url-pattern>
    </servlet-mapping>
    <jsp-config>
        <taglib>
            <taglib-uri>http://java.sun.com/portlet_2_0</taglib-uri>
            <taglib-location>/WEB-INF/portlet_2_0.tld</taglib-location>
        </taglib>
    </jsp-config>
</web-app>

• 青文字にしたスキーマ設定は、これが無いと/PlutoInvoker/plutoPortletをコールする際にエラーになるので必要。
• 紫文字にしたクラスは、Pluto2.0でのサーブレット。
  このサーブレットにポートレットをコールしてもらう(らしい)。
• 赤文字にした設定は、plutoPortletをPlutoに自動認識してもらう為に必要(らしい)。
  ポートレットAP１つごとに、この設定を行う。
  つまり、ポートレットAP追加ごとに、サーブレットとサーブレットマッピングを追加する。

ここまで設定したらplutoPortlet.warファイルにして、pluto-2.0.3/webappsフォルダにデプロイする。
あとはPlutoが自動的に認識してくれる。

3.pluto-2.0.3/conf/Catalina/localhostに置く、plutoPortlet.xml

<Context path="/plutoPortlet" docBase="plutoPortlet"crossContext="true"/>

このファイルが無いと、VIEWモードしか表示しない。
HELPモードやEDITモードが表示できない。

まだ、日本語が文字化けするけど、エンコーディングフィルタを入れれば大丈夫だと思う。
ポートレット側にエンコーディングフィルタ入れてもダメだった。
対策としては、フロント側となるplutoアプリのweb.xmlを修正する必要がある。
内容を書くと長くなるので、別投稿にて詳細説明。

OpenShiftDIYの作り方

Started with DIY Applications on OpenShift
https://openshift.redhat.com/community/blogs/a-paas-that-runs-anything-http-getting-started-with-diy-applications-on-openshift
とりあえず機械翻訳そのまんま、徐々に直すかな。

In addition to supporting Perl, Ruby, PHP, Python, and Java EE6, the OpenShift environment supports the "Do it Yourself" or "DIY" application type.

PerlやRuby、PHP、Python、及びJava EE6のサポートに加え、OpenShift環境をサポートするのが、"DIY" または"Do it Yourself"アプリケーションタイプです。

Using this application type, you can run just about any program that speaks HTTP.

このアプリケーション·タイプを使用して、HTTPを話すすべてのプログラムについてだけ実行することができます。

How this works is remarkably straightforward.

これがどのように動作するかは、とても直接的です。

The OpenShift execution environment is a carefully secured Red Hat Enterprise Linux 6.2 on x64 systems.

OpenShift実行環境は、x64システム上で慎重に確保されたRed Hat Enterprise Linux6.2です。

Thus, OpenShift can run any binary that will run on RHEL 6.2 x64.

したがって、OpenShiftは、RHEL6.2 x64上で実行される任意のバイナリを実行することができます。

The way that OpenShift DIY interfaces your application to the outside world is that creates a HTTP proxy specified by the environment variables OPENSHIFT_INTERNAL_IP and OPENSHIFT_INTERNAL_PORT.

OpenShift DIY·インタフェース外の世界へは、アプリケーションが環境変数OPENSHIFT_INTERNAL_IPとOPENSHIFT_INTERNAL_PORTで指定されたHTTPプロキシを作成することであることをする方法。

All your application has to do is bind and listen on that address and port.

すべてのアプリケーションは、そのアドレスとポートをバインドしリッスンする必要があります。

HTTP requests will come into the OpenShift environment, which will proxy those requests to your application.

HTTPリクエストは、アプリケーションへのプロキシこれらの要求をれる、OpenShift環境に来る。

Your application will reply with HTTP responses, and the OpenShift environment will relay those responses back to your users.

アプリケーションは、HTTPレスポンスで応答し、OpenShift環境がユーザーに戻ってそれらの応答を中継します。

Your application will be executed by the .openshift/action_hooks/start script, and will be stopped by the .openshift/action_hooks/stop script.

アプリケーションが.openshift/ action_hooksによって実行/スクリプトを起動し、スクリプトを停止/.openshift/ action_hooksによって停止されますされます。

To learn more about how it works, follow along with as we construct a simple C application, and then run it as an OpenShift DIY.

それがどのように動作するかの詳細については、我々は単純なCアプリケーションを構築し、OpenShift DIYとしてそれを実行するようにと一緒に従ってください。

We will use the libmicrohttpd library so we dont have to write our own HTTP server.

我々は独自のHTTPサーバを書くために持っていけないので、我々はlibmicrohttpdライブラリを使用します。

Run the following commands at a shell prompt on your own Linux or MacOS machine.

独自のLinuxやMacOSのマシンのシェルプロンプトで次のコマンドを実行します。

svn checkout https: //gnunet.org/svn/libmicrohttpd/src-libmicrohttpd
cd src-libmicrohttpd
autoreconf -fi
mkdir ${HOME}/lib-libmicrohttpd
./configure --prefix=${HOME}/lib-libmicrohttpd make && make install
cd ${HOME}

Next, we download the binhello.c sample program.

次に、我々はbinhello.cサンプルプログラムをダウンロードしてください。

curl -NOL https ://raw.github.com/openshift/openshift-diy-binhello-demo/master/binhello.c

This was originally the "hellobrowser.c" from the libmicrohttpd examples, but has been modified to run in OpenShift, by looking for the OPENSHIFT_INTERNAL_IP and OPENSHIFT_INTERNAL_PORT environment variables, and then binding to and listening on that address and port.

これは、もともとlibmicrohttpdの例から "hellobrowser.c"でしたが、OPENSHIFT_INTERNAL_IPとOPENSHIFT_INTERNAL_PORT環境変数を探し、その後に結合し、そのアドレスとポートをリッスンすることによって、OpenShiftで実行するように変更されています。

Next, we compile the program. We will statically link the libmicrohttpd.a object instead of using the .so shared object libraries.

次に、我々はプログラムをコンパイルします。我々は静的ますので、共有オブジェクト·ライブラリを使用する代わりにlibmicrohttpd.aオブジェクトをリンクします。

We could instead include the shared object library files into our application, and then play with LD_PRELOAD, but that is more than we want to do for this demo.

我々は代わりに私たちのアプリケーションに共有オブジェクトライブラリファイルを含めることができますし、LD_PRELOADと遊ぶ、それは我々がこのデモのために何をしたい以上です。

gcc -o binhello binhello.c ${HOME}/lib-libmicrohttpd/lib/libmicrohttpd.a -L ${HOME}/lib-libmicrohttpd/include -pthread

If we want to skip that step, and avoid playing with the GCC compiler, we can instead download a precompiled binary:

私達はそのステップをスキップして、GCCコンパイラと一緒に遊んで回避したい場合は、代わりにコンパイル済みのバイナリをダウンロードすることができます。

curl -NOL https ://raw.github.com/openshift/openshift-diy-binhello-demo/master/binhello
chmod +x ./binhello

Next, we create the OpenShift application container.

次に、我々はOpenShiftアプリケーションコンテナを作成します。

We will name this application jamie, after one of the kings of Do It Yourself: Jamie Hyneman.

ジェイミーHyneman：我々はそれを自分の王の一人した後、このアプリケーションジェイミー名前を付けます。

rhc-create-app -a jamie -t diy-0.1

Next, we place our binary into the local git repo we just created.

次に、先ほど作成したローカルのgitリポジトリに我々のバイナリを配置します。

mkdir jamie/bin
mv binhello jamie/bin
cd jamie
git add bin/binhello

Next, we tell OpenShift how to run our program. We go into the .openshift/action-hooks directory

次に、我々はプログラムを実行する方法をOpenShift教えてください。我々は.openshift/アクションフックディレクトリに移動

cd .openshift/action_hooks

and replace the start script with the following text:

次のテキストで起動スクリプトを置き換えます。

#!/bin/bash
cd $OPENSHIFT_REPO_DIR/bin
nohup ./binhello >;${OPENSHIFT_LOG_DIR}/binhello.log 2>&1 &

We are redirecting the UNIX standard output and standard error to a file in the OpenShift logging directory, and using nohup to assure that the program properly runs in the background.

我々はディレクトリを記録しているOpenShiftでUNIX標準出力と標準エラーをファイルにリダイレクトしていて、プログラムがバックグラウンドできちんと動作することを保証するために、nohupを使っています。

Next, we replace the stop script with the following text:

次に、我々は停止スクリプトを以下のテキストと入れ替えます：

#!/bin/bash
kill `ps -ef | grep binhello | grep -v grep | awk '{ print $2 }'` >; /dev/null 2>&1
exit 0

We make sure those scripts are still executable.

我々は、それらのスクリプトがまだ実行可能なことを確認します。

chmod +x start stop

Now, we go back to the top directory of our application, commit it to git, and push it up to the OpenShift servers.

現在、我々はアプリケーションの一番上のディレクトリに戻って、それをクズに任せて、それをOpenShiftサーバーまで上げます。

cd ../..
git commit -a -m "install the binhello binary and start stop scripts"
git push

We can then browse to the application.

それから、我々はアプリケーションに閲覧することができます。

In my case, it will be http://jamie-matwood.rhcloud.com/.

私のケースでは、それはhttp://jamie-matwood.rhcloud.com/.です。

We should see a very simple Hello, World!

我々は、非常に単純なハローワールドを見なければなりません！

And that is all there is to it!

そして、つまり、そこのすべては、それにあります！

Using the DIY application type, you can do all sorts of crazy things.

ＤＩＹアプリケーション・タイプを使って、あなたはいろいろな狂ったことをすることができます。

Do you have a favorite scripting language that OpenShift does not yet support?

OpenShiftがまだサポートしない大好きなスクリプト言語が、あなたにはありますか？

Do you have a framework written in Smalltalk?

あなたは、フレームワークをSmalltalkで書いておきますか？

Do you have a HTTP server written in Fortran?

あなたは、HTTPサーバをFortranで記述しておきますか？

Do you have a control server for a model train?

あなたには、模型の電車のために制御サーバーがありますか？

With DIY, you can run it on OpenShift.

DIYで、あなたはOpenShiftの上でそれを走らせることができます。

We would like to extend a challenge:

挑戦を延長したいです：

If you do something useful, amazing, or crazy with the DIY application container, please contact us at openshift@redhat.com, or tell us on the OpenShift Forums or come to IRC at freenode.net #openshift. We want to hear from you!

あなたがＤＩＹアプリケーション容器で役に立つか、素晴らしいか、おかしく何かするならば、openshift@redhat.comで我々に連絡してください、さもなければ、OpenShift Forumsの上で我々に言うか、freenode.net #openshiftでIRCに来てください。 我々は、あなたから連絡をもらいたいです！

GateInのportlet_2_0.tldファイル

JBoss GateInで使うポートレットを作るので、
GateIn用のportlet_2_0.tldが必要になり、
GateInの中を探して見たけど見当たらない。
で、WEBで探したところJARファイルを解凍して取り出せとのこと。

pc-portlet-2.3.1-Beta02.jarを解凍して、
その中からportlet_2_0.tldを取り出す。

pc-portlet-2.3.1-Beta02.jarの在りかはココ。
GateIn-3.2.0.Final-jbossas7-preview/gatein/modules/org/gatein/pc/main

参考情報
https://community.jboss.org/thread/177043
If you´re running GateIn you can find the file portlet_2_0.tld packaged in the library pc-portlet-2.3.0-GA.jar

GithubにPUSHするREADMEで日本語を使う

Eclipseで作成したプロジェクトをGithubにPUSHした後、READMEを見たら、
日本語が全部文字化けしてたので、その対応策を書いておく。

原因)
Eclipseで作成したREADMEは、エンコードがMS932で保存されている為。

処置)
READMEのエンコードをUTF-8に変更する。
具体的にはREADMEを右クリックし、「プロパティ」を表示して変更する。

OpenShiftのREADME

とりあえず機械翻訳。
徐々に直そかな。

Repo layout
リポジトリレイアウト
===========
deployments/ - location for built wars (Details below)
ビルドしたwarファイル（下の詳細）の配置場所
src/ - Maven src structure

Mavenソース構造

pom.xml - Maven build file

Mavenビルドファイル

.openshift/ - location for openshift specific files

openshiftに特有のファイルの場所

.openshift/config/ - location for configuration files such as standalone.xml (used to modify jboss config such as datasources)

standalone.xmlのような構成ファイルの場所（datasourcesのようなjboss構成を修正するのに用いられる）

../data - For persistent data (also in env var OPENSHIFT_DATA_DIR)

持続的なデータのために（環境変数OPENSHIFT_DATA_DIR）

.openshift/action_hooks/pre_build - Script that gets run every git push before the build (on the CI system if available)

あらゆるgit pushでビルドの前に走らせるスクリプト（CIシステムが有効な場合）

.openshift/action_hooks/build - Script that gets run every git push as part of the build process (on the CI system if available)

あらゆるgit pushでビルドプロセスの一部として走らせるスクリプト（CIシステムが有効な場合）

.openshift/action_hooks/deploy - Script that gets run every git push after build but before the app is restarted
あらゆるgit pushでビルド後から、アプリ再開の前に実行されるスクリプト
.openshift/action_hooks/post_deploy - Script that gets run every git push after the app is restarted
あらゆるgit pushでアプリが再開されたあと、実行されるスクリプト

Details about layout and deployment options
レイアウトと配備オプションについての詳細
==================
There are two options for deploying content to the JBoss Application Server within OpenShift:

OpenShiftの中でJBossアプリケーション・サーバに内容を展開するために、2つのオプションがあります：

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.
（推奨） あなたは、このサンプル・プロジェクトであるMaven src構造で内容をアップロードすることができ、git pushでアプリケーションを構築し、配備することができます。
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.
これを実行するため、ビルドから配備ディレクトリまで出力させるために、あなたはリポジトリのルートとこのサンプルでのようなmaven-war-pluginでpom.xmlを必要とします。
By default the warName is ROOT within pom.xml.
デフォルトで、warの名称はpom.xmlの中のROOTです。
This will cause the webapp contents to be rendered at http://app_name-namespace.rhcloud.com/.
これで、webappの内容が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.

あなたがpom.xmlでwarNameをapp_nameに変えるならば、それから、あなたのベースＵＲＬは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.

注：ローカルでビルドしているならば、あなたはビルドから.gitignoreファイルまでdeploymentsの下にどんなwars/earsでも加えたくもあります。

or
もしくは

2) You can git push prebuilt wars (with the corresponding .dodeploy file for exploded wars) into deployments/.
あなたは、前もってビルドされたwars（展開されたwarsのための対応する.dodeployファイルで）をdeployments/にgit pushすることができます。
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.

デフォルトのリポジトリでこうするために、あなたはリポジトリのルートから最初に『git rm-r src/pom.xml』を走らせたいです。

Basic workflows for deploying prebuilt content (each operation will require associated git add/commit/push operations to take effect):
前もってビルドしておいたコンテンツを展開するための基本的なワークフロー（各々の活動は実施されることを合同git add/commit/push活動に要求します）：

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.

警告： あなたがオプション2)を伴うならば、前もってビルドしておかれて分解WARsで心を閉じ込めるために、2つの問題があります。

With exploded wars the main issue is with committing binaries (class and jar files) can make merge conflicts tedious.
主要な問題がバイナリ（クラスとJarファイル）を反することである分解WARsで、製造は退屈な紛争を合併することができます。
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.
あなたがWARとgit pushを修正するたびに、主要な問題がそうである前もって建設しておかれた戦争で、それはあなたのOpenShiftファイルシステム割当てから離れて戦争ファイルの寸法を取ります。
One alternative to this (other then using Maven from option 1) is to use rsync to push your war into the deployments folder.
これ（それからオプション1からMavenを利用している他）に1つの代わるものは、あなたのWARを配備フォルダに押し込むためにrsyncを使うことです。
You would have to do this after each git push followed by 'rhc app restart -a appname'.
『rhc app restart -a appname』が続く各々のgit pushの後、あなたはこうしなければならないでしょう。
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'
注： あなたは、『rhc domain show』を走らせることから、上のuriで、情報を得ることができます
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.
GIT REPOに大きなファイルをすでに委託したならば、あなたは初期の時までGITでそれらのファイルの歴史を書き直すか、リセットします、そして、それらを適用する『git push --force 』は遠隔OpenShiftサーバーで変わります。
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):

遠いOpenShift買い戻し特約に関するGCが強制されることができるクズ（注： 背おおいも、ログファイルと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.
あなたがオプション1)または2)を選ぶかどうかにかかわらず、結果は配備ディレクトリに配備されるアプリケーションです。
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.
JBoss Application Server配布の配備ディレクトリは、エンドユーザーが置くことができる場所です自動的にそれをサーバー実行時に配備しておくだけで満足している（例えばWAR、EAR、JAR、SARファイル）彼らの配備。

The filesystem deployment scanner in AS 7 and later works differently from previous JBoss AS releases.
AS 7とそれ以後のファイルシステム配備スキャナは、前のJBoss ASリリースと違って動きます。
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.
たとえば、example.warが配備されなければならないことを示すマーカーファイルは、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.
それが.dodeployファイルに注意して、内容を展開するところのことを示すために、配備スキャナ・サービスによって置かれます。 配備プロセスが完了するとき、このマーカーファイルは削除されます。
             
.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.
それが.deployedファイルが削除された、そして、内容が展開していないと気がついたことを示すために、配備スキャナ・サービスによって置かれます。 非配備プロセスが完了するとき、この目印ファイルは削除されます。
             
.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.
OpenShiftは、使いやすさのためにいくつか環境変数の参照を提供します。
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:
『rhc app cartridge add』を用いてデータベースを埋めるとき、あなたはユーザー名、ホストとパスワードのために環境変数にリファレンスをつけることができます：

    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.
環境変数の全リストを得るために、単に「輸出」を言うあなたの.openshift/action_hooks/造りスクリプトで線を加えて、押してください。

EclipseからGithubへHTTPSでPUSHする

Eclipseで作成したプロジェクトを、GithubへHTTPSでPUSHする手順を書いておく。
(SSH経由だと、何かしらエラーが発生して、PUSHできないので、当面はコレ)

1. プロジェクトを右クリックして、「チーム」⇒「Commit and Push」を選択する
   
2. コミットする
   
3. Githubへログインして、PUSH先リポジトリパスをコピーする
   
4. コピーしたリポジトリパスを、URIにペーストして続行する
   
5. 「ソース参照」でmasterを選択する
   
6. 「Add Spec」を押す
   (今回始めてGithubへPUSHするのなら、「Force Update All Specs」を押して、強制PUSHする)
   
7. 続行する
   
8. 「完了」を押して実行する
   
9. 実行中の状態
   
10. 終了
    

GithubへのPUSHでnon-fast-forwardエラーが出るとき

Eclipseで作成したプロジェクトを、
GithubへのPUSHしたとき、
non-fast-forwardエラーが出て、
PUSHを拒否されたときの対処方法を書いておく。

このエラーが出たら、強制PUSHを実行する。

具体的には、この画面で

 Force…を押して

 この状態で続行する

どうやら、
PULLやマージをしていない、Githubと整合とれてないプロジェクトだとダメらしい。
全くのローカルで作ったプロジェクトを、始めてGithubにPUSHするときには、この方法が必要らしい。

rhcコマンドのappサンプル

rhcコマンドを使ってアプリケーションを制御するサンプル。

phpmyadmin-3.4を追加した場合

アプリケーションに追加したphpmyadmin-3.4を開始する。
rhc app cartridge start -a APP_NAME -c phpmyadmin-3.4

アプリケーションに追加したphpmyadmin-3.4を停止する。
rhc app cartridge stop -a APP_NAME -c phpmyadmin-3.4

アプリケーションに追加したphpmyadmin-3.4を再起動する。
rhc app cartridge restart -a APP_NAME -c phpmyadmin-3.4

アプリケーションに追加したphpmyadmin-3.4をリロードする。
rhc app cartridge reload -a APP_NAME -c phpmyadmin-3.4

アプリケーションに追加したphpmyadmin-3.4の情報を表示する。
rhc app cartridge status -a APP_NAME -c phpmyadmin-3.4

アプリケーションに追加したphpmyadmin-3.4を削除する。
rhc app cartridge remove -a APP_NAME -c phpmyadmin-3.4

ちなみに、これはMongoDB 2.0の場合
rhc app cartridge status -a APP_NAME -c mongodb-2.0

これは、rockmongo-1.1の場合
rhc app cartridge status -a APP_NAME -c rockmongo-1.1

rhcコマンドリファレンスみたいな、コマンド一覧ページを探してるけど、見当たらない…。
どこにあるんだろう？
HELPから少しづつ調べていくしかないのかな…。

.openshift/config/modulesのREADME

Place your jboss-as7 modules in this directory.
このディレクトリにあなたのjboss-as7モジュールを置いてください。
This directory is added to the module path of the jboss-as7 server associated with your application.
このディレクトリは、あなたのアプリケーションと関連したjboss-as7サーバーのモジュールパスに加えられます。
It has the same structure as the jboss-as7/modules directory.
それには、jboss-as7/モジュール・ディレクトリと同じ構造があります。

OpenShiftのMySQLにUTF-8設定を追加する

OpenShiftのアプリケーションにMySQLカートリッジを追加し、
アプリケーションからMySQLに接続後、
日本語などマルチバイトコードの送受信をすると、
キャラクタが全部「？？？」になってしまう。

これはMySQL設定(my.cnf)に、UTF-8設定が無いので発生する。

以下に、この現象の対応方法を記録する。

1. SSHでアプリケーションサーバへログインする
2. my.cnfのディレクトリ(~/mysql-5.1/etc/)までcdする
3. my.cnfファイルをviで開く
4. 下記設定を追加する
   [mysqld]
   ..
   .....
   .....
   default-character-set=utf8
   character-set-server=utf8
   
5. MySQLをリスタートする(又はアプリケーションをリスタート)
   > cd mysql-5.1/
   > ./app_mysql_ctl.sh restart

参考情報
MySQLの文字コードをUTF8に設定したい

20130831 追記
OpenShiftバージョンアップの影響で、my.cnfの編集が不可能になった。
所有者がrootになり、我々一般ユーザには書き込み権限が無い。
#なんとも使い勝手の悪い、迷惑なバージョンアップだわ…。
#こんなに悪い仕様や使い勝手で有料化されても、絶対に買わないわな…。

で、
文字化け対策として別の方法を捜してみた結果、
「JDBCの接続文字列に付与する接続パラメータで解決する」
という方法が見つかったので記録しておく。

通常の接続文字列（jdbc:mysql://…の文字列）にパラメータを付与して下記のように指定する。
(旧)
jdbc:mysql://$OPENSHIFT_MYSQL_DB_HOST:$OPENSHIFT_MYSQL_DB_PORT/DB名
(新)
jdbc:mysql://$OPENSHIFT_MYSQL_DB_HOST:$OPENSHIFT_MYSQL_DB_PORT/DB名?useUnicode=true&characterEncoding=utf8

これで文字化けを回避する。

20131001 追記
Tomcat7のデータソースとして使う場合は、context.xmlの中で設定する。
その際、指定するURLは下記のようにする必要がある。
jdbc:mysql://$OPENSHIFT_MYSQL_DB_HOST:$OPENSHIFT_MYSQL_DB_PORT/DB名?useUnicode=true;characterEncoding=utf8;

OpenShiftでMAVENビルドをスキップする

OpenShiftでEARファイルや、WARファイルなどアプリケーションアーカイブだけをデプロイしたい場合、下記のように行う。

1. app/.openshift/markersディレクトリにskip_maven_buildファイルを作成する。(中身は空でOK)
2. 後は通常のgitを使ったアップロード

参考情報

• app/.openshift/markers/READMEより
  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.
  
• Deploying GateIn to OpenShiftより
  One final thing - we don’t care much about the template web application that ‘rhc app create’ prepared for us, so we tell the tooling to skip building, and deploying it:
  
  touch .openshift/markers/skip_maven_build
  

OpenShiftに複数WARファイルをデプロイする

OpenShiftにROOT.warに加え、他にデプロイするWARファイルがある場合、下記手順でデプロイする。
1.デプロイしたいWARファイルをapp/deploymentsディレクトリに入れる。
2.WARファイルのdodeployファイルを作成する。(中身は空でOK)
例えばwebapp.warをデプロイする場合、
app/deploymentsディレクトリにwebapp.warファイルを作成し、webapp.war.deployファイルを作成する。
(.deployは無くてもOKみたい)
後はコマンドプロンプトで、app(アプリケーション)ディレクトリにて、通常通りアップロードする。
git add .
git commit -m "webapp"
git push ssh://...

これで
https://app-domain.rhcloud.com/
ならROOT.war
https://app-domain.rhcloud.com/webapp/
ならwebapp.warを参照できる。

つまり、
OpenShiftでの1アプリケーション作成=ローカルでの1サーバ作成
他にもEARファイルやJARファイルも、上記dodeployファイルにてデプロイできる様子。