2013年2月4日月曜日

Tomahawkの<t:jscookMenu>をJSF-RIで動作させる

JSF-RIでTomahawkのjscookmenuを使用した結果、何も反応無く動作しなかったので調べた結果…
どうやら数年前から抱えているバグだった。

で、その回避策が書かれていたので記録しておく。

参考ページ
action not working in t:navigationMenuItem
http://mail-archives.apache.org/mod_mbox/myfaces-users/200704.mbox/%3C9833177.post@talk.nabble.com%3E

Finally I got it working. I had to add this line in my JSP page.

<input type="hidden" name="jscook_action" />

But I have no idea why the above line is required !!

どうやらTomahawkが吐き出すスクリプトがバグってるようで、未だにそれが直ってない様子。
よって、フォームの中に<input type="hidden" name="jscook_action" />を入れて動いた。
その結果がこんな感じ。

<h:form>
<input type="hidden" name="jscook_action" />
<t:jscookMenu layout="hbr" theme="ThemeOffice">
<t:navigationMenuItem itemLabel="メニュー1" action="menu1" />
<t:navigationMenuItem itemLabel="メニュー2" action="menu2" />
</t:jscookMenu>
</h:form>

2013年2月3日日曜日

Tobagoのレイアウト設定

Tobagoのグリッドレイアウトを説明したドキュメント。
http://myfaces.apache.org/tobago/guide.html#Layout

Layout
レイアウト
Tobago organizes the placement of components with the help of layout managers.
Tobagoは、レイアウトマネージャの助けを借りて、コンポーネントの配置を整理します。
The main layout manager is called grid layout.
メインレイアウトマネージャは、グリッドレイアウトと呼ばれます。
It divides the available rectangular space into grid cells.
これは、グリッドのセルに使用可能な矩形領域を分割する。
The grid is spawned by the column and row values of the tag. 
グリッドは、タグの列と行の値によって生成されます。
The syntax of these values is based on the multi-length notation known from HTML.
これらの値の構文は、HTMLから知られているマルチレングス表記に基づいています。
To add a layout manager to a container like box, panel or page you have to add a layout facet (i.e. a facet with the name 'layout') to the respective container tag.
box, panelやpageのようなコンテナにレイアウトを追加するには、それぞれのコンテナにレイアウトファセットを追加する必要があります。
A code fragment from the address book example:
アドレスブックの例のコード·フラグメント:
<tc:panel>
  <f:facet name="layout">
    <tc:gridlayout columns="*" rows="fixed;fixed;*" />
  </f:facet>
  <tx:in label="First Name" />
  <tx:in label="Last Name" />
  <tc:cell />
</tc:panel>

In this example we place to two input controls with labels into two consecutive rows.
この例では、2つの連続した行にラベルを使用して2つの入力コントロールを配置します。
Below the two input fields we add a spacer element.
2つの入力フィールドの下にスペーサ要素を追加します。
The layout token 'fixed' advises the layout manager to give the input control the height, which this kind of control normally possesses in the selected theme.
レイアウト・トークン'fixed'は、レイアウトマネージャにインプット・コントロールの高さを与えるアドバイスを行い、この種のコントロールは通常選択されたテーマ中で処理されます。
The values of the column and row attributes of the tag can contain a semicolon separated list of layout tokens. 
タグのcolumnとrow属性の値は、セミコロン区切りでレイアウト・トークンのリストを含めることができます。
A layout token can be an exact length in pixels like 200px, a percentage length like 25%, a relative length like 2*, or a specific length called fixed, which's exact length is determined by the theme and make sure the control is usable -- a single-line input control for example needs to be so high that characters from the assigned font can be read inside the control.
レイアウト・トークンは「200px」のような ピクセルの正確な長さ、「25%」のようなパーセンテージ 、 「2*」のような相対的な 長さ、あるいは、「fixed」と呼ばれる特定の長さが可能です--たとえば、1行の入力コントロールは、割り当てられたフォント からのキャラクターがコントロール中に読まれることができるように高い必要があります。
Relative lengths are determined last by the layout manager.
相対的な長さは、レイアウトマネージャによって最後に決定されます。
The available remaining space is distributed among the existing relative lengths.
利用できる残りのスペースは、既存の相対的な長さに分配されます。
Each length receives space proportional to the integer before the '*'.
各々の長さは、「*」前の整数に比例したスペースを受けます。
A single '*' is a shorthand for '1*'.
一つの「*」は、「1*」の短縮形です。
The layout manager handles the rendered attribute of controls, too.
レイアウトマネージャは、コントロールのrendered属性も取り扱います。
If the rendered attribute is dynamically defined by a value binding, the page can contain fewer controls in some cases than in others.
rendered属性は動的にバリュー・バインディングによって定義されている場合、ページが他に比べていくつかのケースでは少ないコントロールを含めることができます。
The layout manager can then distribute the newly available space between the remaining relative and percentage lengths.
レイアウトマネージャは、その後、残りの相対的な割合と長との間に新たに利用可能なスペースを分配することができます。

2012年12月28日金曜日

OpenShiftのTomcat添付README(作成中)

OpenShiftのTomcatに付いていたREADME。
徐々に翻訳予定。


Repo layout
レポレイアウト
===========
webapps/ - location for built wars (Details below)
webapps/ - 構築されたWARファイルの配置場所(以下詳細)
src/ - Maven src structure
src/ - Mavenのソース構造
pom.xml - Maven build file
pom.xml - Mavenのビルドファイル
.openshift/ - location for openshift specific files
.openshift/ - openshiftの詳細ファイル配置場所
.openshift/config/ - location for configuration files such as standalone.xml (used to modify jboss config such as datasources)
.openshift/config/ - standalone.xmlなど設定ファイル配置場所 (データソースなどJBoss設定に使用)
ん?standalone.xmlなんか無いぞ?server.xmlなどtomcatの設定ファイルだぞ?
.openshift/action_hooks/pre_build - Script that gets run every git push before the build (on the CI system if available)
.openshift/action_hooks/pre_build - 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)
.openshift/action_hooks/build - git pushビルドプロセスの一部として実行されるスクリプト(もし有効であればCIシステム上で)
.openshift/action_hooks/deploy - Script that gets run every git push after build but before the app is restarted
.openshift/action_hooks/deploy - git pushビルド後毎に実行されるアプリが再起動される前に実行されるスクリプト
.openshift/action_hooks/post_deploy - Script that gets run every git push after the app is restarted
.openshift/action_hooks/post_deploy - アプリが再起動された後、git push毎に実行されるスクリプト
.openshift/action_hooks/pre_start_jbossews-1.0 - Script that gets run prior to starting EWS1.0
.openshift/action_hooks/pre_start_jbossews-1.0 - EWS1.0を開始する前に実行されるスクリプト
.openshift/action_hooks/post_start_jbossews-1.0 - Script that gets run after EWS1.0 is started
.openshift/action_hooks/post_start_jbossews-1.0 - EWS1.0開始後に実行されるスクリプト
.openshift/action_hooks/pre_stop_jbossews-1.0 - Script that gets run prior to stopping EWS1.0
.openshift/action_hooks/pre_stop_jbossews-1.0 - EWS1.0を停止する前に実行されるスクリプト
.openshift/action_hooks/post_stop_jbossews-1.0 - Script that gets run after EWS1.0 is stopped
.openshift/action_hooks/post_stop_jbossews-1.0 - EWS1.0停止後に実行されるスクリプト


Notes about layout
レイアウトについての注意事項
==================
Note: Every time you push, everything in your remote repo dir gets recreated
      please store long term items (like an sqlite database) in the OpenShift
      data directory, which will persist between pushes of your repo.
注意:あなたがpushをかける度に、あなたのリモート・レポ・ディレクトリ内全ては再作成を受けるので、OpenShiftデータ・ディレクトリには長期アイテム(sqliteデータベースのような)をストアしてください。そこはプッシュの間も持続されます。
      The OpenShift data directory is accessible relative to the remote repo
      directory (../data) or via an environment variable OPENSHIFT_DATA_DIR.
OpenShiftのdataディレクトリは、相対的なリモートレポ(../data)経由、又はOPENSHIFT_DATA_DIR環境変数を経由してアクセス可能です。


Details about layout and deployment options
レイアウトとデプロイメント・オプションの詳細
==================
There are two options for deploying content to the Tomcat Server within OpenShift.
OpenShiftのTomcatサーバーにコンテンツをデプロイするのに2つのオプションがある。 
Both options can be used together (i.e. build one archive from source and others pre-built)
どちらのオプションも一緒に使用される(すなわち、ソースと他のプレ・ビルドから一つのアーカイブがビルドされる)。

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.
1) (好ましい方法)サンプルプロジェクトのようにMavenソース構造のコンテンツをアップロード可能であり、そして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 webapps directory.
これが正常に機能するために、レポジトリルートにpom.xmlが必要で、サンプルのようなmaven-war-pluginがbuildからwebappsディレクトリへ出力するのに必要だろう。
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-amespace.rhcloud.com/.
これはwebappコンテンツがhttp://app_name-amespace.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に変えたなら、ベースURLはhttp://app_name-namespace.rhcloud.com/app_nameとなる。
Note: If you are building locally you'll also want to add any output wars under webapps
from the build to your .gitignore file.
注意:もしローカルでビルドしているのなら、幾つかwebapps下に出力したwarファイルを、ビルドから.gitignoreファイルまで追加を望むでしょう。
Note: If you are running scaled EWS1.0 then you need an application deployed to the root context (i.e. http://app_name-namespace.rhcloud.com/) for the HAProxy load-balancer to recognize that the EWS1.0 instance is active.
注意:もし貴方がスケールされたEWS1.0を実行しているなら、EWS1.0インスタンスがアクティブであることを認識する為に、HAProxyロードバランサーの為に、ルートコンテキストへのアプリケーション配備が必要です。
or
もしくは
2) You can git push pre-built wars into webapps/.
2) webappsフォルダにプレビルドのwarを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 pre-built 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:
A)新規ZIPコンテンツを追加し、それをデプロイする:

1. cp target/example.war webapps/

B) Undeploy currently deployed content:
B)現在デプロイされたコンテンツをアンデプロイする:

1. git rm webapps/example.war

C) Replace currently deployed zipped content with a new version and deploy it:
C)現在デプロイされたZIPコンテンツを新バージョンに置き換え、それをデプロイする:

1. cp target/example.war webapps/

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レポに、既にコミットされた大きなファイルを有しているのなら、あなたは上書き又はそれらのファイルの履歴を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上のgit gcは、強制させることもできる(注意:)
rhc app tidy -a appname


Whether you choose option 1) or 2) the end result will be the application
deployed into the webapps directory. The webapps directory in the
Tomcat 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.

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_APP_NAME")  - Application name
    System.getenv("OPENSHIFT_DATA_DIR")  - For persistent storage (between pushes)
    System.getenv("OPENSHIFT_TMP_DIR")   - Temp storage (unmodified files deleted after 10 days)
    System.getenv("OPENSHIFT_INTERNAL_IP")  - The IP address used to bind EWS1.0

When embedding a database using 'rhc app cartridge add', you can reference environment
variables for username, host and password. For example, when embedding MySQL 5.1, the
following variables will be available:

    System.getenv("OPENSHIFT_MYSQL_DB_HOST")      - DB host
    System.getenv("OPENSHIFT_MYSQL_DB_PORT")      - DB Port
    System.getenv("OPENSHIFT_MYSQL_DB_USERNAME")  - DB Username
    System.getenv("OPENSHIFT_MYSQL_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.

2012年7月8日日曜日

Displaytagポートレットで表のソート、ページング

Displaytagポートレットの作り方。
及び、このポートレットでソート、ページングができる表の作り方を書いておく。

参考情報:
External Paging and Sorting
Displaytag library in your portlet

通常、コノ手の表はJSFベースでナントカFaces使って片付けるんでしょうね。
でも、今回は個人的な方針の都合でSpringベースだから、Displaytagを使う。
  1. Displaytagポートレットを作る
    まず、通常のセットアップとして、Displaytagのライブラリを、アプリケーションのWEB-INF/libに入れる。
    参考情報:Installation Guide

    次に、クラスパスにdisplaytag.propertiesファイルを追加する。
    displaytag.propertiesファイルに、この一文を書き込む。
    factory.requestHelper=org.displaytag.portlet.PortletRequestHelperFactory
    参考情報:JSR-168 Portlet Support

    これで、ポートレットにDisplaytag表を追加して、ソートやページングさせる準備が整う。
    実は、このファイルが無くても、Displaytag表は表示できる。
    が、ソートやページングができない。

  2. ソート、ページングができる表を作る
    ソートやページングができる表を作るには、二つ方法があるらしい。
    Valuelistパターンを使う方法と使わない方法。
    今回はValuelistパターンを使う方法を採用した。

    この方法だとorg.displaytag.pagination.PaginatedListインタフェイスの実装が必要。
    で、探したところ幾つか見つけて、コレはその中の一つ。
    Displaytag library in your portlet

    具体的に、どう使うかって言うと…
    まず、Springのコントローラから渡すモデルMapに、このPaginatedList実装をプットする。
     Map model = new HashMap();
     // 表示するデータのリストを取得する
     List list = this.logpageDao.readLogmessages(filePath,log4jPattern);
     // displaytagでソート、ページングできるリストへ変換
     PaginatedListImpl list2 = new PaginatedListImpl(request);
     list2.setList(list);
     model.put("list", list);
    次に、JSP側で、Displaytag表で表示するデータに、このPaginatedList実装を指定する。
     <portlet:renderURL var="viewListURL" />
     <display:table name="list" sort="external" defaultsort="1" requestURI="${viewListURL}" pagesize="20" id="element" >
      <display:column property="lineNumber" title="LN" sortable="true" sortName="lineNumber" />
      <display:column property="data" title="DT" />
     </display:table>
    
    「pagesize="20"」で1ページに20レコードを指定。

2012年6月28日木曜日

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


2012年6月24日日曜日

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になる。
ちなみに「ネーム=actionactionは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>









2012年6月21日木曜日

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