Java | 寺田　佳央 - Yoshio Terada

Posts filed under ‘Java’

Java EE 7 メンテナンス・レビュー・ドラフトの変更リスト一覧

自分用メモ

Java EE 7 Maintenance Review: Proposed Changes
————-
Section EE.5.2.2. [Clarify rules for default namespace.]

Replace the first sentence of the sixth paragraph on p. 69, section
5.2.2, with the following:

The default JNDI namespace for resource references and resource
definitions must always be “java:comp/env”. Note that this applies to
both the case where no name has been supplied so the rules for
choosing a default name are used, and the case where a name has been
supplied explicitly but the name does not specify a java: namespace.
Since the java:comp namespace is not available in some contexts, use
of that namespace in such a context should result in a deployment
error. Likewise, the java:module namespace is not valid in some
contexts; use of that namespace in such contexts should result in a
deployment error.

———-

Section 5.3.3. [Clarify the requirements for the specification of
the lookup and lookup-name elements.]

Add the following to the end of the second paragraph of section
EE.5.3.3, p. 77:

Deployment should fail if the lookup element of an annotation or the
lookup-name element in a deployment descriptor entry does not specify
a name with an explicit java: namespace.

——————-

Section EE.5.18.6.1 [Correct editorial error in the second paragraph]

Change the following text on page 140:
If a mail session resource has been previously provisioned for the
application (e.g., by administrative action), it is the
responsibility of the Application Component Provider to specify
the mail server host name.
to:
If a mail server resource has been previously provisioned for the
application (e.g., by administrative action), it is the
responsibility of the Application Component Provider to specify
the mail server host name.

——

Sections EE.5.19, EE5.20, EE5.21. [Correct editorial error in third
paragraph of each of these sections to correctly reflect Application
Assembler role.]

In EE.5.19, change:
The Application Component Provider or Deployer may explicitly bind
a DataSource resource reference to the default data source using
the lookup element of the Resource annotation or the lookup-name
element of the resource-ref deployment descriptor element.
to:
The Application Component Provider or Application Assembler may
explicitly bind a DataSource resource reference to the default data
source using the lookup element of the Resource annotation or the
lookup-name element of the resource-ref deployment descriptor
element.

In EE.5.20, change:
The Application Component Provider or Deployer may explicitly bind
a JMS ConnectionFactory resource reference to the default
connection factory using the lookup element of the Resource
annotation or the lookup-name element of the resource-ref
deployment descriptor element.
to:
The Application Component Provider or Application Assembler may
explicitly bind a JMS ConnectionFactory resource reference to the
default connection factory using the lookup element of the Resource
annotation or the lookup-name element of the resource-ref
deployment descriptor element.

In EE.5.21, change:
The Application Component Provider or Deployer may explicitly bind
a resource reference to a default Concurrency Utilities object
using the lookup element of the Resource annotation or the
lookup-name element of the resource-ref deployment descriptor
element.
to:
The Application Component Provider or Application Assembler may
explicitly bind a resource reference to a default Concurrency
Utilities object using the lookup element of the Resource
annotation or the lookup-name element of the resource-ref
deployment descriptor element.

——

Sections EE.5.19.1, EE.5.20.1, EE.5.21.1 [Correct editorial error in
second paragraph of each of these sections to reflect role of
Application Assembler.]

In EE.5.19.1, change:
If a DataSource resource reference is not mapped to a specific data
source by the Application Component Provider or Deployer, it must be
mapped by the Java EE Product Provider to a preconfigured data
source for the Java EE Product Provider’s default database.
to:
If a DataSource resource reference is not mapped to a specific data
source by the Application Component Provider, Application Assembler,
or Deployer, it must be mapped by the Java EE Product Provider to a
preconfigured data source for the Java EE Product Provider’s default
database.

In EE.5.20.1, change:
If a JMS ConnectionFactory resource reference is not mapped to a
specific JMS connection factory by the Application Component
Provider or Deployer, it must be mapped by the Java EE Product
Provider to a preconfigured JMS connection factory for the Java EE
Product Provider’s default JMS provider.
to:
If a JMS ConnectionFactory resource reference is not mapped to a
specific JMS connection factory by the Application Component
Provider, Application Assembler, or Deployer, it must be mapped by
the Java EE Product Provider to a preconfigured JMS connection
factory for the Java EE Product Provider’s default JMS provider.

In EE.5.21.1, change:
If a Concurrency Utilities object resource environment reference is
not mapped to a specific configured object by the Application
Component Provider or Deployer, it must be mapped by the Java EE
Product Provider to a preconfigured Concurrency Utilities object for
the Java EE Product Provider.
to:
If a Concurrency Utilities object resource environment reference is
not mapped to a specific configured object by the Application
Component Provider, Application Assembler, or Deployer, it must be
mapped by the Java EE Product Provider to a preconfigured
Concurrency Utilities object for the Java EE Product Provider.

——
Sections EE.8.1.3., EE.5.19, EE.5.20, EE.5.21, EE.5.3.3.
[Clarify the rules for the binding of unmapped resources.]

In EE.8.1.3, add the following new paragraphs:

Every resource reference should be bound to a resource of the
required type.

Some resources have default mapping rules specified; see sections
EE.5.19, EE.5.20, and EE.5.21. By default, a product must map
otherwise unmapped resources using these default rules. A product
may include an option to disable or override these default mapping
rules.

Once a resource reference is bound to a resource in the target
operational environment, and deployment succeeds, that binding is
not expected to change. A product may provide administrative
operations that change the resource bindings that are used by
applications. A product may notify applications of changes to
their resource bindings using JNDI events, but this is not
required.

If deployment succeeds, in addition to binding resource references
as specified above, every resource definition (see Section EE.5.18)
specified by the application or specified or overridden by
the deployer must be present in the target operational environment.

In EE.5.19, change the following text:
In the absence of such a binding, the mapping of the
reference will default to the product’s default data source.
to:
In the absence of such a binding, or an equivalent
product-specific binding, the mapping of the reference will
default to the product’s default data source.

In EE.5.20, change the following text:
In the absence of such a binding, the mapping of the
reference will default to a JMS connection factory for the
product’s JMS provider.
to:
In the absence of such a binding, or an equivalent
product-specific binding, the mapping of the reference will
default to a JMS connection factory for the product’s JMS
provider.

In EE.5.21, change the following text:
In the absence of such a binding, the mapping of the
reference will default to the product’s default managed
executor service.
to:
In the absence of such a binding, or an equivalent
product-specific binding, the mapping of the reference will
default to the product’s default managed executor service.

In section EE.5.3.3, add the following to the end of the second paragraph:
The Deployer may also use product-specific resource mapping
tools, deployment descriptors, rules, or capabilities to
bind resource reference entries to resources in the target
operational environment.

——

Section EE.6.2.2.6 [Clarify requirements for support of custom
permissions]:

Add the following to the end of paragraph 3:
The Java EE product is not required to support permissions.xml
files that specify permission classes that are packaged in the
application.

——

Section EE.6.7. [In the list in paragraph 3, correct the interface
shown for the third and fourth items. This should be
javax.jms.JMSConsumer, not javax.jms.JMSContext].

Replace:
javax.jms.JMSContext method getMessageListener
with
javax.jms.JMSConsumer method getMessageListener

Replace:
javax.jms.JMSContext method setMessageListener
with
javax.jms.JMSConsumer method setMessageListener

——

Section EE.6.7. [In the list in paragraph 3, add missing methods for
consistency with JMS spec.]

Add:
javax.jms.JMSProducer setAsync
javax.jms.MessageProducer send(Message message, CompletionListener completionListener)
javax.jms.MessageProducer send(Message message, int deliveryMode, int priority, long timeToLive,
CompletionListener completionListener)
javax.jms.MessageProducer send(Destination destination, Message message,
CompletionListener completionListener)
javax.jms.MessageProducer send(Destination destination, Message message, int deliveryMode, int priority, long timeToLive, CompletionListener completionListener)

——
Section EE.8.5. [Clarify the rules regarding whether an application
is attempted to be started during deployment].

Replace the first full paragraph on p. 215 with the following:

Deployment may provide an option that controls whether or not an
application is attempted to be started during deployment. If no such
option is provided or if the option to start the application is
specified, and if deployment is successful, the application modules
must be initialized as specified in section EE.8.5.4 and the
application must be started.

If the application is attempted to be started during deployment, the
Servlet and EJB containers must be initialized during deployment.
Such initialization must include CDI initialization. If
initialization fails, deployment must fail.

If the application is not attempted to be started during deployment,
these containers must not be initialized during deployment.

In all cases, the deployment and initialization of a Java EE
application must be complete before the container delivers client
requests to any of the application’s components. The container must
first initialize all startup-time singleton session bean components
before delivering any requests to enterprise bean
components. Containers must deliver requests to web components and
resource adapters only after initialization of the component has
completed.

——
Section EE.8.5. [Clarify the requirements for annotation scanning and
processing.]

Replace the *first* paragraph of section EE.8.5 on p. 216 with the
following pragraphs (i.e., break it up as follows and include
the new text):

Some deployment descriptors are optional. The required deployment
information is determined by using default rules or by annotations
present on application class files. Some deployment descriptors that
are included in an application may exist in either complete or
incomplete form. A complete deployment descriptor provides a complete
description of the deployment information; a deployment tool must not
examine class files for this deployment information. An incomplete
deployment descriptor provides only a subset of the required
deployment information; a deployment tool must examine the application
class files for annotations that specify deployment information.

If annotations are being processed (as required by table EE.10-1,
Servlet table 8-1, and EJB tables 16 and 17), *at least* all of the
classes specified in table EE-5.1 must be scanned for annotations that
specify deployment information. As specified in section EE.8.5.2, all
classes that can be used by the application may optionally be scanned
for these annotations. (These are the annotations that specify
information equivalent to what can be specified in a deployment
descriptor. This requirement says nothing about the processing of
annotations that were defined for other purposes.) These annotations
may appear on classes, methods, and fields. All resources specified
by resource definition annotations must be created. All resource
reference annotations must result in JNDI entries in the corresponding
namespace. If the corresponding namespace is not available to the
class declaring or inheriting the reference, the resulting behavior is
undefined. Future versions of this specification may alter this
behavior.

Any deployment information specified in a deployment descriptor
overrides any deployment information specified in an application’s
class files. The Java EE component specifications, including this
specification, describe when deployment descriptors are optional and
which deployment descriptors may exist in either complete or
incomplete form. The attribute metadata-complete is used in the
deployment descriptor to specify whether the descriptor is complete.
The metadata-complete attribute in the standard deployment descriptors
effects *only* the scanning of annotations that specify deployment
information, including web services deployment information. It has no
impact on the scanning of other annotations.

——

Section EE.8.5.2. [Clarify the intended semantics by correcting the
ambiguity resulting from the use of “JAR” to refer to both modules and
.jar files referenced from modules.]

Change EE.8.5.2 item 1.d on page 218) from:

d.For all files in the application package with a filename extension
of .jar, but not contained in the lib directory, do the following:

i. If the JAR file contains a META-INF/MANIFEST.MF file with a
Main-Class attribute, or contains a META-INF/application-client.xml
file, consider the JAR file to be an application client module.

ii. If the JAR file contains a META-INF/ejb-jar.xml file, or
contains any class with an EJB component-defining annotation
(Stateless, etc.), consider the JAR file to be an EJB module.

iii. All other JAR files are ignored unless referenced by a JAR
file discovered above using one of the JAR file reference
mechanisms such as the Class-Path header in a manifest file.

to:

d.For all files in the application package with a filename extension
of .jar, but not contained in the lib directory, do the following:

i. If the .jar file contains a META-INF/MANIFEST.MF file with a
Main-Class attribute, or contains a META-INF/application-client.xml
file, consider the .jar file to be an application client module.

ii. If the .jar file contains a META-INF/ejb-jar.xml file, or
contains any class with an EJB component-defining annotation
(Stateless, etc.), consider the .jar file to be an EJB module.

iii. All other .jar files are ignored unless referenced by a JAR
file discovered above using one of the JAR file reference
mechanisms such as the Class-Path header in a manifest file.

——

Section EE.10.6 [Correct table to include missing entries for
application-client_6 and application-client_7. These should
be the same as for application-client_5.]

Add the following entries to Table EE.10-1:
application-client_6 Yes No
application-client_7 Yes No

Add the following to the paragraph above this table:
Whether or not to process annotations depends on the
presence and version of the deployment descriptor and
the setting of the metadata-complete attribute.

——-

Figures EE.8-3, EE.10-1 [Corrected inconsistencies with the XML
schemas.]
Replace “connector-resource*” with “connection-factory*” in
Figures EE.8-3 and EE.10-1.
Add “administered-object*” to Figure EE.10-1.

2015年5月9日 at 2:55 午前

Java EE 8 の新機能概要のご紹介

この記事は、「Java EE Advent Calendar 2014」の19日目の記事となります。
昨日は、@nagaseyasuhitoさんの「JPAでマスター/スレーブ構成のMySQLを使うぞ」でした。明日は、@kokuzawa さんのご担当となります。

本エントリでは、今年の JavaOne で発表された、Java EE 8 (JSR-366) の今後の動向についてまとめたいと思います。

本エントリの内容は、JJUG CCC 2014 Fall で発表した内容に追加情報を加えた内容になっています。SlideShare で資料をご覧頂きたい方、もしくは PDF ファイルを入手されたい方は上記スライドをご参照ください。

本エントリの記載内容は、2014年12月時点での内容ですので、下記に記載する内容は今後大幅に変更する可能性もあることをどうぞご理解の上でご覧下さい。

まず、Java EE 8 のリリースに伴い、Java EE のスペックリードは本当に必要とされる技術が何なのかを改めて考えてみました。その際、業界のトレンドを観察し必要な技術は何なのかを検討したり、また Java の技術者の皆様にアンケートをとり、実際に技術者の皆様から求められている機能はどのような内容なのかも確認しました。アンケートの結果、JSON Binding, Security, JCache, Action ベース MVC 等が上位に占められていました。

こうして検討を重ねた結果、次の Java EE 8 のテーマを決めました。Java EE 8 では３つのテーマを元に機能提供を検討しています。

●　HTML5
　＋　JSON Binding : JSR-367
　＋　JSON-P : JSR-374
　＋　Server-Sent Events : JSR は未定(JAX-RS,Servlet, WebSocket の何れか)
　＋　Action Base MVC : JSR-371
　＋　HTTP/2 のサポート(Servlet 4.0) : JSR-369
　＋　WebSocket の改善

●　かんたん開発
　＋　CDI の適用範囲の拡大 : JSR-365
　＋　セキュリティ・インターセプタ
　＋　仕様の削減

●　クラウド環境への対応
　＋　Java EE Management 2.0 : JSR-373
　＋　Java™ EE Security API 1.0 : JSR-375

最新の Web 系の技術トレンドに対応するために、HTTP/2 への対応を Servlet 4.0 内で行うほか、Server-Sent Events の標準化、新しい Action ベースの MVC 等の導入も検討しています。また Java EE 5 以降、6,7 と継続してかんたん開発のテーマに取り組んでいますが、これは Java EE 8 でも継続します。例えば CDI の適用範囲をひろげ Java SE 環境でも CDI を利用できるようにします。さらにクラウド対応という点では、今まで　Java EE アプリケーションを監視する際に使用していた、管理・監視用の JMX を改め、JAX-RS による監視を可能にする他、今までアプリケーション・サーバ毎に個別設定していた認証・認可の設定・実装（レルム）を標準化し、より簡単にユーザ管理のアプリケーションを実装できるようにします。これらの各種技術概要を見るだけでも Java EE 8 が待ち遠しくなりますが、それぞれの検討内容を下記にまとめて紹介します。

HTML 5 への対応として、ここに列挙する内容が検討されています。これらを順に説明します。

JSON Binding : JSR-367
JSON Binding は JSON と Java オブジェクトをマッピングし相互変換を簡単に実現するための機能です。

今までも、XML を利用する場合には、JAX-B を利用したり、データベースのテーブルと Java オブジェクトをマッピングするために、JPA を利用してきましたが、JSON-B はこれらと類似の方法で JSON と Java オブジェクトをマッピングできるようになります。またこれを実装する事によって JPA の Entity を使用したデータベース・テーブルから JSONへの相互変換や、JAXB を使用した XML と JSON への相互変換も容易になります。
JSON-B は JSON の Java へのマッピングにおいてできるだけ実装コードを少なくするため、Configuration by Exception のルールに乗っ取り標準でデフォルトのマッピング・ルールが提供されます。またクラスの継承も可能です。このデフォルトのルールに従う場合は、Java を簡単に JSON に変換できます。そしてもちろん、デフォルトのルールをカスタマイズしたい場合には、専用のアノテーションを付加する事でデフォルト・ルールを上書きする事もできます。
また、Java EE 7 で導入された JSON-Processing との連携も容易にできます。

JSON-B の参照実装は、Eclipse link MOXy で開発が進められています。

それでは、実際に Java と JSON のバインディングについて見ていきましょう。ここでは、Employee というクラスに、インスタンス変数、id, firstName, lastName, email が定義されており、Employee クラスのインスタンス (e) を生成した後、それぞれに値を代入しています。この Java オブジェクトを JSON で扱う場合、デフォルトのルールに従うとインスタンス変数名が、JSON の KEY になり、変数に代入された値が JSON の value として代入されます。

また、JAX-B をご利用した事のある方であれば、用語の説明は不要かと想定しますが、Java から JSON への変換を Marshal (マーシャル) といい、逆に JSON から Java への復元の事を Unmarshal (アンマーシャル) といいます。

Marshal (JavaからJSONへの変換), Unmarshal (JSONからJavaへの変換) を行うために、まず JsonContext オブジェクトのインスタンスを生成します。JsonContext のインスタンスを生成するためには、デフォルトで用意されているファクトリ・メソッド JsonContext#newInstance() を利用する事ができます。また下記のように JsonContextBuilder を通じてインスタンスを生成する事もできます。

JsonContext context = new JsonContextBuilder()
　　　　　　　　　　　　　　　　　　.setScope (MyClass.class, ...)
　　　　　　　　　　　　　　　　　　.excludeField(“field”, MyClass.class)
　　　　　　　　　　　　　　　　　　.addFilter(myContextFilterImplementation)
　　　　　　　　　　　　　　　　　　.build();

生成した JsonContext のインスタンスから、それぞれ createMarshaller() で Marshaller オブジェクトを、createUnmarshaller() で Unmarshaller のオブジェクトを生成します。

一旦、Marshaller オブジェクトを生成すると、変換したいオブジェクトを marshall() メソッドの引数に渡す事で簡単に JSON を含む String オブジェクトを取得したり、Writer として取り出す事もできます。

同様に、unmarshaller() メソッドの引数に JSON を含む String 、もしくは Reader から Java オブジェクトを渡す事で簡単に Java オブジェクトに復元する事もできます。

今まで JsonContext から Marshaller や Unmarshaller を生成し各処理を行う方法を紹介しましたが、よりかんたんに直接相互変換を行うためのユーティリティ・クラス Jsonb の作成も検討中です。Jsonb のメソッドを利用すると直接、marshal, unmarshal を実行する事もできるようになります。

JSON-B ではプリミティブ型や、参照型に対するデフォルトのマッピングルールを提供します。しかし、デフォルトのルールに従わず独自にカスタマイズしたい場合には、下記のようなアノテーションを付加しカスタマイズする事もできます。

例えば、デフォルトのルールに従うと、Java クラス中のインスタンス変数名は、JSON のキーに同一の名でマッピングされます。しかし、Java クラス中のインスタンス変数名と、キー名を変更したい場合は、@JsonPropertyアノテーションを付加して変更する事ができます。

また、Java のクラス中に含まれる特定のインスタンス変数を JSON にマッピングさせたくない場合、@JsonTransient アノテーションを付加し無効化する事ができます。

さらに、JSON ドキュメント中のキーの記載順に意味があるような場合、デフォルトでは Java クラスのインスタンス変数の記載順にマッピングされますが、その順番を変更するために、@JsonPropertyOrder アノテーションを付加し引数内に順番を指定する事ができます。

JSON-B では継承やポリモーフィズムにも対応予定で、また Marshal の前後、もしくは Unmarshal の前後に処理をインターセプトして何らかの処理を付け加えて実行したい場合に、それらを実現するための API (JsonPre***, JsonPost***) も用意しています。

JSON-Processing は Java EE 7 に JSR-353 として導入されました。JSON-P は Stream を利用して JSON の解析、生成を行うための低レベル API を提供し、XML における StAX や DOM のような機能を提供しています。
Java EE 8 では Java EE 7 で提供されている機能に加え、JSON の標準仕様に準拠した最新機能 (JSON ポインタや JSON パッチ) にも対応します。

まず、JSON ポインタについてご紹介します。

JSON ポインタは IETF RFC 6901 : JavaScript Object Notation (JSON) Pointer で定義される仕様で、JSON ドキュメント内に存在する特定の値を参照するための構文です。

たとえば、この例をご覧ください。この例では JSON 配列の中に、２つの JSON オブジェクト(名前が Duke と Jane)があります。そして人に関する情報（名前、性別、電話番号）が JSON オブジェクトとして記載されています。それではこの中から携帯電話の電話番号 (650-234-5678) を取得するにはどうすればよいでしょうか。JSON ポインタを利用すると、”/何番目/phones/mobile” といった形式で一意に値を取得する事ができるようになります。例では “0/phones/mobile” と 0 番目を指定する事で値を取得しています。

それでは、Java で JSON ポインタを扱うためにはどのようにすれば宜しいでしょうか。まず、先ほどの JSON ドキュメント(名前が Duke と Jane)が　JsonArray のインスタンス contacts として表されている事とします。この時、Json クラスのクラスメソッド createPointer() の引数に、参照したい JSON 値への参照パス(“/0/phones/mobile”)を渡し、JsonPointer のインスタンスを生成します。ポインタの getValue() を実行する事で JsonValue を取得する事ができます。またポインタに対して、replace を実行する事で、指定した参照の値を変更した結果の JsonArray を取得する事ができます（※ オリジナルを直接書き換えるわけではない）。

JsonPointer クラスには、ここで示すように様々なメソッドが用意されています。しかし、ここで１点注意をしなければならない事があります、add, replace, remove 等のメソッドは直接オリジナルの JSON ドキュメントに対する変更を行うわけではないという点です。JsonObject や JsonArray はイミュータブル（不変）のデータなので、直接それを変更するわけではなく、変更した後に新しい JsonArray や JsonObject を生成するという点に気を付けてください。オリジナルの JSON ドキュメントを編集したい場合は、JsonPointer ではなく、次に紹介する JsonPatch を利用します。

続いて、JSON パッチについて紹介します。
JSON パッチは、IETF RFC 6902 : JavaScript Object Notation (JSON) Patchで定義される仕様で、特定の JSON ドキュメントに対して行う操作(追加、変更、削除等)内容が記載された JSON のドキュメントのフォーマットです。JSON パッチのドキュメントは、op (add,replace,remove 等) と path (JSON ポインタ)が必須で、それ以外は必要に応じて追加できます。また、MIME タイプ “appliaction/json-patch+json” を指定し、HTTP の PATCH メソッドを利用できます。

※ JsonArray や JsonOBject はイミュータブル(不変)なオブジェクトなので、直接変更を加える事ができません。そこでオリジナルの JSON ドキュメントに対して、変更（追加、変更、削除など）を加えたい場合、新たに処理内容を記載した JSON ドキュメントを作成し、指定したドキュメントに対して操作を行う事ができるようになります。

下記に HTTP の PATCH メソッドの利用例をご紹介します。

PATCH /my/data HTTP/1.1
Host: example.org
Content-Length: 326
Content-Type: application/json-patch+json
If-Match: “abc123”

[
    { “op”: “test”, “path”: “/a/b/c”, “value”: “foo” },
    { “op”: “remove”, “path”: “/a/b/c” },
    { “op”: “add”, “path”: “/a/b/c”, “value”: [ “foo”, “bar” ] },
    { “op”: “replace”, “path”: “/a/b/c”, “value”: 42 },
    { “op”: “move”, “from”: “/a/b/c”, “path”: “/a/b/d” },
    { “op”: “copy”, “from”: “/a/b/d”, “path”: “/a/b/e” }
]

それでは、実際に JSON パッチのドキュメント記載方法と利用方法について説明します。まず、左側に示す、”mobile”:”650-234-5678″ の電話番号を (“650-111-2222”) に変更する場合を考えてみましょう。変更するために処理内容を記載した、JSON パッチのドキュメントを生成しますが、先ほど説明したように、op と path は必須です。ここでは既存の値を変更したいので、op には “replace” を指定します。また変更対象の値は、JSON ポインタで “/0/phones/mobile” と表す事ができますので、path にこの値を記載します。最後に value に変更後の値を指定する事で、電話番号を変更するための JSON パッチのドキュメントができあがりました。

また次に既存の JSON ドキュメントから要素を削除する例を確認してみましょう。この例では、0 番目を全部削除する場合を考えます。削除するために、JSON パッチのドキュメントを生成しますが、先ほどと同様 op と path は必須で、それぞれ remove と JSON ポインタで対象を指定します。

さて、基本的な JSON パッチの概念が理解できましたので、Java でどのようにしてパッチを扱うかについてご紹介します。オリジナルの JSON のドキュメントが JsonArray の target に代入されている事とします。また JSON パッチの記載内容が JsonArray の patch に代入されている事とします。Json クラスのクラス・メソッド createPatch(patch) を実行し、JsonPatch のオブジェクトを取得します。そして JsonPatch の apply メソッドをターゲットに対して実行します。このようにとても簡単にパッチを適用できます。

最後に、JSON クエリに対する Lambda & Stream API の適用についてご紹介します。JSON-P で提供される API の javax.json.JsonObject, javax.json.JsonArray はそれぞれ、java.util.Map, java.util.List インタフェースを実装したクラスです。そして、Map や List は Java SE 8 で導入された Lambda 式や Stream API を利用してバルク（一括）操作を行う事ができるようになります。具体的には、JSON ドキュメント中のデータのフィルタリングや変更（マッピング）などのバルク（一括）処理ができるようになります。下記に Java SE 8 の Lambda 式や Stream API を使用して JSON データに含まれるデータの抽出を行う例を紹介します。

Stream を取得するために、JsonObject, JsonArray で getValuesAs(JsonObject.class).stream() を実行します。一旦 Stream のインスタンスを取得した後は、java.util.stream.Stream で提供される filter や map といった中間操作用のメソッド、collect といった終端操作用のメソッドを、通常の Stream API と同様実行する事ができます。この例では、filter メソッド内で、性別が女性の方をフィルタリングし、 JsonObject として抽出しています、次に map メソッドで、抽出した JsonObject 中から、女性の名前を getString(“name”) で取得し、結果として String のストリームを返しています。最後に collect メソッド内で、結果を List として返しています。つまり List<String> femaleNames には女性の名前の一覧が代入されてます。

Lambda 式と Stream API を利用して JSON ドキュメントのデータの抽出等がかんたんにできる事が分かりました。しかし、Stream API の終端操作 Collectors で標準に提供する機能では、配列やリストなどへの変換しかできません。Stream API を利用して任意の中間操作を行った後、最終的に終端操作で直接、JsonObject や JsonArray のオブジェクトを取得できるとさらに有用です。そこで、Java EE 8 では java.util.stream.Collectors クラスを拡張した JsonCollectors を新たに提供する予定です。JsonCollectors では最終的に JsonObject や JsonArray を取得するためのメソッドを追加したり、groupingBy メソッドで結果のグルーピングをおこなうためのメソッドも提供する予定です。

具体的に JsonCollectors の利用例を紹介します。先ほどの例では collect で List を返していましたが、その代わりに collect で JsonCorrectors.toJsonArray() を指定する事で、結果 JsonArray オブジェクトとして結果を取得する事ができます。

最後に、今までご紹介してきた、JSON ポインタ、JSON パッチ、Lambda 式 & Stream API を使用して、オリジナルの JSON ドキュメントに対して一気に変更を加える例を紹介します。ここでは、電話番号のエリアコード（地域識別番号）で 415 を含むデータのみを抽出し、そのエリアコードを 415 から 650 に一括変更するための処理を記載します。まず、Stream を取得した後、filter メソッドで電話番号のエリアコードが 415 を含む JSONObject の Stream を取得します。次に、map メソッドでエリアコードの部分を 415 から 650 に変換するための JSON パッチを動的に生成し、生成した JsonObject の Stream を返します。最後に collect メソッドで、条件に一致する全ての変更用のパッチを含む JsonArray を生成し返します。パッチ用の JSON ドキュメント生成後、オリジナルの JSON ドキュメント(contacts) に対して、Json.createPatch(patch).apply(contacts) でパッチを適用する事で結果を取得しています。
このように、Lambda 式 & Stream API を利用する事で、より簡単にパッチの適用ができるようになります。

JSON-B に関する詳細は下記 JavaOne の発表資料「Java API for JSON Binding
Introduction and update」もご参照ください。

ここでご紹介した API に関して、ご意見、ご要望がある場合は、メーリングリスト、JIRA などでお問い合わせください。
https://java.net/projects/jsonb-spec/
https://java.net/jira/browse/JSONB_SPEC/

続いて、Server-Sent Events (以降 SSE) について説明します。

歴史を少し振り返ると、サーバ側で発生するイベントをリアルタイムに通知するための仕組みは、今まで Ajax を使った Polling, Comet(Long Polling,Streaming), WebSocket が利用できました。Polling や Comet は、パフォーマンスが非常に悪く、大量のリクエストを捌くサービスを提供する事が困難でした。WebSocket はハイ・スケーラブルで双方向通信を実現できますが、専用のプロトコルを利用するため、これをサポートするクライアント、サーバ、さらに HTTP プロキシ等が必要でした。一方で SSE は純粋な HTTP を使用し、サーバ側からクライアントに対する一方向へのメッセージ通知としては利用できます。双方向通信ではなく、サーバからの一方向通信でよい場合、SSE は有用です。

SSE は、現在 W3C で仕様がドラフトとしてまとめられています。
http://www.w3.org/TR/eventsource/

SSE は、クライアントからサーバに接続しコネクションが確立した後は、サーバからクライアントに対して一方向でデータを送信します。この際、サーバ側で発生するイベントに応じて、何度も同一コネクションを利用してデータ転送する事ができます。MIME タイプとして専用のメディア・タイプ “text/event-stream” を利用します。SSE はクライアントがサーバに対してサブスクライブ(購読)要求をだして、サーバがサブスクライブしているクライアントに対してパブリッシュ(配信)するという点で JMS のパブリッシュ・サブスクライブのモデルに似ています。

現在、Java EE 上で SSE の実装を検討中ですが、どのレイヤーで実装するかを今まさに議論中です。具体的には Servlet 上、WebSocket 上、JAX-RS 上、もしくは独自のコンテナ上で実装する案があがっており、これらを検討中です。

検討案の説明資料：

クリックしてSSE-in-EE8.pdfにアクセス

上記をエキスパート・グループメンバーに問い合わせ中ですが、現在、スペックリードとしては JAX-RS が一番適切ではないかと考えています。なぜならば、JAX-RS で既に HTTP のリソースに対するストリーミングをサポートしており小さな変更ですむためです。

● 小さな変更で実現
　　例えば、JAX-RS でサーバ、クライアントにそれぞれ下記の API を追加します
　　サーバの API として : EventOutput に対し新しいメディアタイプを追加
　　クライアントの API として：Server側のイベントに対する新しいハンドラを追加
● 他のHTTPの操作と組み合わせる際に便利：新しいメディアタイプ
● Jersey(JAX-RS RI)は既に SSE をサポート済み
Jersey を利用した実装例はコチラ

JavaOne で発表された、次の JAX-RS で組み込む機能紹介の概要は下記よりご参照ください。
Let’s Talk JAX-RS.next! JSR-370 – What to expect in JAX-RS in Java EE 8

また、JAX-RS の参照実装 Jersey で既に実現している SSE の実装方法については下記をご参照ください。
Chapter 14. Server-Sent Events (SSE) Support

オリジナルの資料では Java EE 7 から導入された Concurrency Utilities for EE を使って説明されていなかったため、Concurrency Utilities for EE を使って書き直したコードを下記に記載します。ここでは、ManagedExecutorService を @Resource アノテーションでインジェクトした後、別スレッドで SSE のイベント通知を行っています。別スレッドの処理内容の例は、StockThread に記載しています。実際に SSE でメッセージ通知は EventOutput#send()メソッドで行っています。

また、SSE ではクライアント用の API も用意しています。これにより、JavaFX 等のスタンドアローン・アプリケーションでも SSE クライアントを実装し、SSE のサーバ・サイドからの通知を受信して何らかの別処理を行う事ができます。

次に、Action ベースの新しい MVC フレームワークについて紹介します。
Java EE 7 まで Web アプリケーションの開発を行う際、JavaServer Faces(以降 JSF), もしくは JAX-RS を利用できました。この中で JSF はコンポーネント・ベースの MVC フレームワークとして Java EE 5 以降標準の Web 開発フレームワークとして導入されています。一方、アクション・ベースの MVC フレームワークも世の中には多く存在します。例えば Struts や SpringMVC 等がこれに当てはまります。

Java EE の開発者にアンケートを実施した所「アクション・ベースの MVC は改めて必要でしょうか？」という質問に対し、約 6 割の方々がハイと答えました。またその際、アクション・ベースのMVC を実装するために、「参考にすべき技術（デファクト・スタンダードな技術）はありますか？」と質問した所、75% の開発者は分からない、もしくは存在しないと答えました。

当初、JAX-RS のエキスパート・グループ・メンバーを中心に新しいアクション・ベースの MVC について議論を行いましたが、様々な議論を行った結果、JAX-RS とは別途、検討・実装した方がよいという結論になり、グループを再編し、スタンドアローンのAPI として、新しく JSR 371: Model-View-Controller (MVC 1.0) Specification として仕様策定を進めています。

※ 現在まさに仕様を検討中ですので、下記に紹介する内容は今後大きく変更する可能性があります。その点をどうぞご注意ください。

まず、MVC の各構成にどのような技術を適用するかを紹介します。アンケートの結果、参考にすべきアクション・ベース MVC が無い、もしくは分からないというご意見が多数あったため、既存の資産を有効活用するため Java EE で現在提供されている機能を組み合わせて、それらをつなぎ合わせて実装できるような MVC フレームワークを検討中です。Movel には CDI, Bean Validation, JPA 等を View は Facelets, JSP, 任意のテンプレート・エンジン（プラグイン可能なテンプレートエンジンが入れられると望ましい）等が予定されています。

一方で、現時点でまだ Controller 部分の実装が決まっていません。スペックリードが現在(10/29 から)この新しい MVC フレームワークのコントローラ部分をどのような環境で提供すべきかアンケートも実施しています。
https://java.net/projects/mvc-spec/lists/users/archive/2014-10/message/68

(A) Layer MVC on top of the Servlet API: define new set of annotations, new URI mapping algorithm and new data binding layer for controllers. This option implies no MVC + REST controllers, at least not in a elegant manner (see example on e-mail thread).

(B) Layer MVC on top of the JAX-RS API: reuse existing set of JAX-RS annotations, URI mapping algorithm and data binding layer for controllers. This option implies that MVC + REST controllers will be possible, but also that our runtime will depend on the JAX-RS runtime.

メーリングリストでの回答の多くは、(A) の Servlet API 上に Controller 実装を希望している方が多く見られるようです。一方、Oracle (Santiago) としては (B) に投票予定のようです。

(3) Oracle’s Vote: We have been busy writing some prototypes and evaluating
MVC frameworks for the last few weeks. We are not taking this decision
lightly as it obviously has a great impact on future work. Our main concern
has always been familiarity of existing APIs and duplication of work,
especially around matching (routing) and binding. These are the list of
annotations that JAX-RS defines for this:

* Matching: ApplicationPath, Consumes, Produces, GET, PUT, POST, DELETE,
HEAD, OPTIONS, Path, HttpMethod

* Binding: BeanParam, CookieParam, DefaultValue, Encoded, FormParam,
HeaderParam, MatrixParam, PathParam, QueryParam, Cookie, Form

And this is just annotations, no matching and binding semantics, etc.
This fact, together with the existence of several MVC frameworks built on top
of JAX-RS, has led us to the conclusion that JAX-RS is right technology for
MVC to be layered on. Thus, Oracle votes for option (B).

下記に JavaOne 発表時のサンプル・コードを示しますが、上記の投票結果や今後の進捗によって今後大きく変更される可能性があります。

上記では、JSP や Facelets で <form action=”/rough-example/form1a.jsp”> を記載し、ページ内に EL 式を用いてデータ・バインディングができるようになっています。またサーバ側では、クライアントのリクエストに対応する処理を @Path を付加したメソッド内で記述し、メソッドの戻り値として画面遷移先を返しています。

Java EE におけるアクション・ベースの MVC フレームワークのプロジェクトはまだ始まったばかりです。ご興味のある方は是非、java.net に存在するプロジェクトやメーリング・リストにご参加ください。

JSR 371: Model-View-Controller (MVC 1.0) Specification
The MVC specification project : java.net

HTML 5 関連で最後に、HTTP/2 対応についてご紹介します。
HTTP/2 は Internet Engineering Task Force(IETF)の Hypertext Transfer Protocol Bis (HTTPbis)のワーキング・グループで標準化が進められている、次バージョンの HTTP プロトコルです(現在はまだドラフト)。HTTP/2 の特徴として下記のような物があげられます。

＊レイテンシを軽減
＊ Head of Line Blocking 問題の対応
＊並列処理のサポート(複数コネクションは不要)
＊ HTTP 1.1 の意味は保持
＊ HTTP 1.x との連携を定義

Java EE で HTTP/2 に対応するために、JSR 369: Java™ Servlet 4.0 Specification で対応を行います。Servlet API は、HTTP/1.x に対応していたため、単一リクエストに対し単一レスポンスを返すアーキテクチャになってました。この問題点として、例えば、同一クライアントからサーバに対して大量の HTTP リクエストを行うような場合、特定のリクエストで処理時間を多く要した場合、後続の処理が待ち状態になり全体としてパフォーマンスが低下する場合がありました。しかし HTTP/2 ではよりデータ転送の効率化をはかるために、単一コネクションで、リクエストとレスポンスを多重化できるようになります。これにより、例え一つのリクエスト処理に時間を要しても後続の処理に影響が発生しにくくなるため、より効率的なデータ転送を行う事ができるようになります。

Servlet 4.0 における変更点の詳細は下記に記載していますので、下記をご覧ください。

また、JSF 2.3 における変更点は下記ごご覧ください。

続いて、「かんたん開発」の分野における Java EE 8 の拡張ポイントについて説明します。まず、CDI の適用範囲が大幅に広がります。

CDI は Java EE 6 で導入され、Java EE 7 まで、Java EE のコンテナ、つまりアプリケーション・サーバ上で利用されてきました。実際、CDI の仕様である JSR 299 は Contexts and Dependency Injection for the Java™ EE platform として記載されていました。しかし Java EE 8 からは、JSR 365 として Contexts and Dependency Injection for Java™ 2.0 に名前を変え、CDI の適用範囲を Java EE 外にもひろげ、Java SE 環境でも利用できるようにします。これにより、EJB の組み込み可能コンテナと同様に、JUnit のテストコード等でも CDI を利用できるようになります。

Java EE 8 に含まれる CDI 2.0 では、大きな機能拡張としてここにあげる３つの機能があります。

また、上記以外にも下記のような機能拡張も予定されています。

● イベント処理の拡張
● インターセプター・デコレータの仕様への対応
● SPI の拡張
● コンテキストの拡張
● Java 8 機能への対応(タイプ・アノテーション、アノテーションのくり返し、Lambda, Stream, デフォルト・メソッド、型推論)

詳しくはWorking method for CDI 2.0をご参照ください。

まず、Java SE 環境で利用可能にするために、CDI を Java SE 環境で起動するための Bootstrap 用 API が提供されます。

CDI 2.0 first Face to face meeting feedback によると、下記のようなクラスの提供を検討しているようです（まだ議論中との事）。上記会議での議論の内容は CDI 2.0 の新機能を理解する上で重要ですのでご興味のある方はどうぞご覧ください。

public class ContainerBoot {

    /**
     * Simple boot
     */
    static BeanManager initialize() {
      ...
    }

    /**
     * Boot with parameters
     */
    static BeanManager intialize(Map&lt;?,?&gt;) {
      ...
    }
    void shutdown() {}
}

つづいて、モジュール化について説明します。CDI は Java EE 6 における標準化以降、Java EE において非常に重要な機能になっています。そして、EJB 等で培ってきた経験を元に、EJB が持つ機能も多く CDI に取り込まれて利用できるようになってきており、この方向性は今後も引き続き継続されそうです。この中で CDI が機能を持てば持つ程、CDI 自身が大きく、重量になる事も懸念されてます。そこで、CDI 自身を引き続き継続して軽量に扱う事ができるように、CDI 自身のモジュール化を検討しています。

上記では①、②、③と示しましたが、実際にはより細かく検討されています。

A. 単純な DI の機能
B. Observer パターンを利用した CDI によるイベント管理機能
C. 対象型の発見方法の拡張
デプロイしたアプリケーションの起動時に型検査を行う
D. (A+B+C+AOP:インターセプタ、デコレータ)
E. D+コンテキスト管理

詳細は CDI 2.0 modularity proposal をご覧ください

また、EJB の MDB に変わり、CDI でも非同期メッセージを受信するための新しい API も検討中です。現在の MDB の実装は、たくさんの設定が必要で MessageListener を implements したクラスの実装も必要でした。
今回、JMS をさらに簡単に利用でき、任意の CDI に対して利用ができるようにします。また、MessageListener を implements したクラスの実装も不要で、直接メソッドに @JMSListener のアノテーションを付加し、監視する Queue を destinationLookup で指定し実装できるようになります。

また、Java EE 7 までの MDB と同等の振る舞いを実装するためには、該当の CDI に対して @Singleton アノテーションを付加する事で MDB と同等の振る舞いを実現できます、また @Transactional アノテーションを付加する事でコンテナ管理のトランザクションも正しく動作します。ここに記載したコード例のように既存の MDB の実装に比べより簡単に実装できるようになります。

Java EE 7 まで提供されてきた認可(Authorization)用のアノテーションとして、@RolesAllowed や @RunAs といったアノテーションが存在しました。これらのアノテーションは多くの利用場面に有用でした。しかしより複雑な認可処理が必要な場合、別途、認可用のプログラミングを実装するか、もしくは新しく CDI のインターセプタを実装する必要がありました。また認可用のアノテーションを実装する際に、EL 式が評価できるようになる事でより多くのユースケースにかんたんに対応できるようになります。

今回、ロールに基づく認可の他、Java EE のコンテキスト情報にもアクセスし、コンテキスト情報から認可情報(プリンシパル名、ロールチェック、認可チェック)を取得する事も可能な新しいアノテーションを、CDI のインターセプタとして実装する予定です。

詳細は、JIRA に登録されている JAVAEE_SPEC-29 : EL-Enabled Authorization Annotation をご覧ください。

また、上記以外にも、CDI との連携をより強化するために、様々な場所でクリーン・アップを行います。例えば、WebSocket の実装においても CDI のスコープを利用できるようにしていますが、このように CDI が他の仕様でも幅広く利用されている事がわかります。

WebSocket の拡張に関しては下記の Slide もご参照ください。

また、Java EE 8 では Pruning (剪定：仕様の削減) 候補として EJB 2.x のリモート、およびローカルのクライアント・ビュー(EJBObject, EJBLocalObject, EJBHome, EJBLocalHome インタフェース)があげられています。さらに CORBA : (Prune CORBA interoperability) もあげられています。理由として昨今 SOAP や REST で通信を行う事が多く CORBA の利用場面が大幅に減ってきているためです。現在これらを用いて実装している場合は、アップデートをご検討ください。

最後に、Java EE プラットフォームの近代化（クラウド環境への対応）を行うための機能を紹介します。

まず、Java EE Management & Deployment API について説明します。
JSR 77: J2EE™ Management という JSR において、Java EE のプラットフォームで提供される管理オブジェクトを定義していました。これらの管理オブジェクトの各インスタンスは、構造化された OBJECT_ID で識別され、管理オブジェクトは追加機能を提供するために、コンテナ側で下記インタフェースを実装する事もできました。そして、これらの管理オブジェクトは、JConsole 等のツールを利用して管理、監視を行ったり、独自に管理・監視機能実装してアプリケーション全体の運用管理を行う事ができました。

● EventProvider : 設定イベントの通知 : GlassFish 実装
● StatisticsProvider：統計情報採取 : GlassFish 実装
● StateManageable：状態管理（基本的なライフサイクル） : GlassFish 実装

今回提案する仕様では、現在の実装方法に代わり、REST インタフェースで管理可能な、管理オブジェクトを定義する事を目的としています。これにより、既存の HTTP のツールやライブラリを用いてかんたんに Java EE アプリケーションの管理ができるようになります。またこれにあわせ、エキスパート・グループ・メンバーは、既存の Management EJB の API や JMX API をオプションにするべきかどうかも検討中です。これは仕様をかんたんにするためという理由だけではなく、今回提案する REST インタフェースをより積極的に採用していただくためです。

新しい REST インタフェースは、既存で提供している OBJECT_NAME を URL に変換し、また個々の管理オブジェクトに対する CRUD 操作も可能です。EventProvider のイベント通知に Server-Sent Events もサポートする予定で(WebSocket も検討中だが、対応ツール(HTTPのアップグレードは不要)リアルタイムで監視する事ができるようになります。

また、JSR 88: Java™ EE Application Deployment という JSR において、デプロイ・ツール用のインタフェースが定義されていました。そしてこれに準拠したデプロイ・ツールから、個々のアプリケーション・サーバに対して直接アプリケーションをインストールする事ができました。JSR 88 のサポートは Java EE 7 からオプション化されています。

デプロイ用の API も上記、REST インタフェース内に取り込む予定です。このインタフェースを利用する事で、アプリケーション・サーバのインスタンスに対して、REST インタフェースを通じて直接アプリケーションをインストールする事ができるようになります。その際、依存するリソース定義や管理も REST インタフェースを通じてできるようになります。

次にセキュリティについて説明します。現在、セキュリティの設定・実装に関する多くがアプリケーション・サーバ固有設定になっており、これにより移植性が大きく損なわれていました。今回、これらサーバ独自の設定を排除し標準化する事で、クラウド環境でより柔軟に移植性の高いアプリケーションの構築が可能になります。
これらは、JSR 375: Java™ EE Security API で検討中です。

まず、パスワード・エイリアスを導入します。これまで、アプリケーション・サーバからデータベースや、LDAP 等の外部リソースへの接続するためには、サーバ側の設定でユーザ名、パスワードを設定していました。所がこのユーザ名、パスワード管理はアプリケーション・サーバ固有で、一部のアプリケーション・サーバでは生のパスワードを記載しなければならない場合もありました。データベースや LDAP への接続用のユーザ名やパスワードを生の形で見えるようにしておくのは非常に危険です。そこで、生パスワードを記入しなくてもよい標準の方法を提供します。

@DataSourceDefinition{
  name=“java:app/MyDataSource”,
  className=“com.example.MyDataSource”,
  …
  user=“duke”,
  password=“${ALIAS=dukePassword}”)

上記の構文は、現在 Java EE の参照実装 GlassFish で採用されているパスワード・エイリアスの指定方法で、標準化にあたりこれをベースにしていますが、パスワードの値には、実パスワードを参照するためのエイリアス（仮の名前）が設定されており、実行環境が必要に応じてエイリアスから元の実パスワードを参照するようになっています。

ご参照：Password Aliasing for EE 7

続いてユーザ管理について説明します。Java EE 7 までユーザ管理（認証・認可）を扱うアプリケーションの実装は、各アプリケーション・サーバ・ベンダーに依存していました。つまり統一的なユーザ管理用の API も用意されていなかったため、概念は共有できても実装コードは個別に行う必要がありました。以前、GlassFish v4 で始める Java EE JDBC レルムハンズオン・ラボとして GlassFish 上で Java EE6/7 利用者向けのハンズオン・ラボを公開しましたが、ここで記載した内容は他のコンテナではそのままでは利用できません。そこで、このようなユーザ管理を行うアプリケーションを作成する際の、標準化を行い移植性の高いアプリケーションを構築するため、ユーザ管理機能の標準化が行われます。
この仕様もまた、JSR 375: Java™ EE Security API 内で行われています。また、JIRA に登録されている JAVAEE_SPEC-9 : Simplify and standardize authentication & role mapping もご参照ください。

ユーザ管理を行うために、３つのコア・クラスを提供します。これらを順に紹介します。

● UserSourceDefinition：データ・ソース（DB, LDAP, ファイルなど）を定義
● UserService：ユーザの管理（追加、変更、削除など）機能を定義
● UserInfo：ユーザ情報の定義（ユーザ名、パスワード、有効期限など）

UserSource(DB, LDAP, ファイル、その他)のリソース中に含まれるユーザ、グループを UserService で処理し、個々のユーザは UserInfo として管理され、ユーザ名、パスワードだけでなく、有効期限や、アカウントのロック状態なども管理ができるようになります。

具体的に、LDAP からユーザ、パスワードを参照するアプリケーションを作成する例をここで紹介します。@LdapUserSourceDefinition というアノテーションを付加し、ユーザ情報が含まれる LDAP ディレクトリをしていします。またこれを利用する為には、@Resource アノテーションを付加し UserService をインジェクトしています。UserService のインスタンスを取得した後は、下記に示すメソッド（現時点での仮案）を利用してユーザ管理、グループ管理を行う事ができるようになります。

+ UserInfo:loadUserByUsername(username)
+ changePassword
+ createUser
+ deleteUser
+ updateUser
+ userExists
+ createGroup
+ addUserToGroup
+ removeUserFromGroup
+ isUserInGroup

また、UserInfo のインスタンスは下記のフィールドを持ち、ユーザ自身の管理も標準で用意にできるようになります。

+ Username
+ Password
+ AccountExpired
+ AccountLocked
+ PasswordExpired
+ Enabled
+ Attributes

続いて、ロール・マッピングについて説明します。ロール・マッピングもユーザ管理同様、アプリケーション・サーバ固有に設定・実装が必要でした。ロールマッピングの実装もまた標準化を行います。

ロール管理を行うために、２つのコア・クラスを提供します。これらを順に紹介します。

● RoleMapper：ロール情報が保存されるデータ・ソース（DB, LDAP, ファイルなど）を定義
● RoleService：ロールの管理（権限の付加、排除、権限の有無チェックなど）機能を定義

RoleMapper(DB, LDAP, ファイル、その他)のリソース中に含まれるロール情報を RoleService で処理します。

ここでは、メモリに存在するロール情報を元に、ロール管理を行うアプリケーションを作成例を紹介します。ここでは、@MemoryRoleMapperDefinition アノテーションを付加し、その中でロール情報を定義しています。ここで定義されたロール情報を元に @Resource アノテーションで RoleService をインジェクトしインスタンスを生成しています。getRolesメソッドの引数で与えられたユーザが持つ全てのロール一覧を取得するために、getRolesForUser(username) を実行しています。RoleService が提供するメソッドの一覧（現時点での仮案）は下記の通りです。

+ grantRoleToUser(username, role)
+ revokeRoleFromUser(username, role)
+ hasRoleForUser(username, role, includeGroups)
+ getRolesForUser(username, includeGroups)
+ getUsersWithRole(role, includeGroups)
+ grantRoleToGroup(group, role)
+ revokeRoleFromGroup(group, role)
+ hasRoleForGroup(group, role)
+ getRolesForGroup(group)
+ getGroupsWithRole(role)

このように、ユーザ管理用の API やロール管理用の API が標準化される事で、よりかんたんにユーザ管理アプリケーションが実装できるようになるだけでなく、移植性の高い認証・認可のアプリケーションを構築できるようになります。

Java EE 8 は 2016 年の秋頃を目処に仕様を FIX し提供する予定です。

また、これに向け Java EE 8 は JSR 366 として登録され投票の結果、満場一致で承認されました。

詳細なロードマップは上記ですが、Java EE 8 の正式リリース時には、今までと同様 GlassFish が参照実装として提供される予定です。

現時点で登録済みの Java EE 8 関連の JSR 一覧を下記に示します。下記 JSR もどうぞご参照ください。

●　JSR 366: Java Platform, Enterprise Edition 8 (Java EE 8) Specification
●　JSR 107: JCACHE – Java Temporary Caching API
●　JSR 365: Contexts and Dependency Injection for Java™ 2.0
●　JSR 367: Java™ API for JSON Binding (JSON-B)
●　JSR 368: Java™ Message Service 2.1
●　JSR 369: Java™ Servlet 4.0 Specification
●　JSR 370: Java™ API for RESTful Web Services (JAX-RS 2.1) Specification
●　JSR 371: Model-View-Controller (MVC 1.0) Specification
●　JSR 372: JavaServer Faces (JSF 2.3) Specification
●　JSR 373: Java™ EE Management API 2.0
●　JSR 374: Java™ API for JSON Processing 1.1
●　JSR 375: Java™ EE Security API

その他、メンテナンス・リリースとしてここに示す各既存 API の改善も検討されています。

Java EE 8 の今後にご興味のある方は Java EE プロジェクトにご参加頂き、メーリング・リスト等でフィードバックをください。

Adopt-A JSR プロジェクトを通じて、日本 Java ユーザ・グループの一員としてフィードバック等をおこなってください。

最後に、Java EE 7 が日本で本格的に導入されるのは 2015 年からですが、Java EE 7 のプロジェクトを開始するにあたり、その先の Java EE 8 の変更点等を理解し意識した上でプロジェクトを進めていく事は、将来の移行、更新において非常に有用です。例えば、Pruning 予定の EJB 2.x の機能を使っているかた、Java で CORBA の利用をご検討中の方は時代の流れをいち早くつかみ、そうしたコードを排除する事がより安全に長く使っていただくための秘訣です。また認証・認可の実装コードも将来標準化される予定のクラスやメソッド・シグネチャを理解しておく事で、移行も用意になるかと想定します。Java EE 8 が市場で投入されるようになるのは、2017 年後半〜2018年辺りになる事が予想されるので随分先の内容ですが、将来の動向もみながらどうぞ今のプロジェクトをお勧めください。2016 年にリリース予定の Java EE 8 をどうぞ楽しみにしてください。

2014年12月19日 at 10:00 午前 1件のコメント

leJOS + NetBeans 8.0 (Maven) + Java SE Embedded (7 or 8) で LEGO Mindstorms EV3のアプリケーション開発

今日は Java の開発者の皆様に、LEGO Mindstorms EV3 の制御を Java で行うために、環境構築から NetBeans を使用した Java のアプリケーションの開発方法までをご紹介します。LEGO 社は、幅広い年代の子供達に向けて LEGO ブロックを提供しています。最近では私の２歳になる子供も LEGO duplo という幼児向けのレゴで遊んでいます。

今日、ご紹介する「教育版レゴマインドストームEV3」は、LEGO Mindstorms を教育目的で使うために開発された製品で、これを使用するとブロックでロボットを作成した後、Java でそのロボットを制御する事もできるようになります。今回、Java でロボット制御を試すために、「教育版レゴマインドストームEV3 / LEGO Mindstorms Eduation EV3 」の日本の正規代理店である（株）アフレル様のご協力を得て、LEGO Mindstorm を1台お借りし、実際に教育版レゴマインドストームEV3 用の Java アプリケーションを書いてみました。

● アプリケーションの動作イメージ：

今回、作成した LEGO Mindstorms EV3 のサンプル・アプリケーションのソースコードは GitHub にアップしていますので、ご興味のある方はどうぞご覧ください。
https://github.com/yoshioterada/Java-Sample-app-for-LEGO-Mindstorms

本エントリでは、上記のサンプル・アプリケーションの実装に対する詳細の説明ではなく、Java でプログラムを書く事ができるように環境構築から最初のプログラム作成の部分までをご紹介します。

事前準備：

(1) レゴマインドストーム EV3 の入手

LEGO Mindstorms は教育版と玩具版があり含まれる内容が異なります。
参考：教育版と玩具版の比較 (アフレル)

教育版
「教育版レゴマインドストームEV3」の入手（本エントリではこちらを使用）
販売先情報：アフレル（株）

玩具版: Amazon 等から
レゴマインドストーム EV3 31313(￥51,000)
レゴマインドストーム EV3 31313 LEGO Mindstorms EV3 並行輸入品(￥ 44,320)
LEGO Mindstorms EV3 31313($349.95)

玩具版のレゴも Amazon で $350 〜￥51,000と少々高価な商品ですが、対象年齢は 10 歳以上のれっきとした LEGO です。機能的にこれは本当に子供向けなのか？！と思う程、自分でロボットを組み立てたり、そのロボットを制御するプログラムを書けたりと、子供よりも大人が熱中しそうな商品です。今回のエントリは玩具版でもご参考いただけるかと思います。

(2) USB WiFi アダプタの入手

USB の WiFi アダプタは EV3 に標準で付属していませんがあった方がとても便利です。開発時、開発環境から EV3 へネットワークを通じてアプリケーションをデプロイしたり、リモートから EV3 を制御したい場合、WiFi アダプタが必要です。今回、（株）アフレル様のご好意で「Roland Wireless USB Adapter WNA1100-RL」も借りる事ができたため、私はこの WiFi アダプタを使用します。Amazon から WNA1100-RL を購入していただく事も可能です。

その他、EV3 では下記の WiFi の USB アダプタが動作確認されています。特に EDIMAX EW-7811Un は EV3 からあまり突出しないのでオススメです。
動作確認済みの WiFi アダプタ

(3) leJOS 0.8.1 beta の入手

leJOS は LEGO Mindstorms EV3 のファームウェアを変更した OS で、この環境上で Java SE 7 Embedded 7 が稼働し、Java のアプリケーションを動かす事ができるようになります。
leJOS EV3 0.8.1 beta release より leJOS_EV3_0.8.1-beta.tar.gz を入手してください。

(4) Oracle Java SE Embedded の入手

Java for LEGO® Mindstorms® EV3 のサイト(オリジナルJRE入手先)から、Oracle Java SE Embedded を入手してください。
Java SE Embedded 7 の場合：
●　ejre-7u55-fcs-b13-linux-arm-sflt-headless-17_mar_2014.tar.gz

Java SE Embedded 8 のインストール方法は、本エントリの最後に記載しています。

(5) 開発環境用 (Mac/Linux/Windows環境) に統合開発環境、Java SE をインストール

デスクトップの開発環境に NetBeans 8 と Java SE 7 をインストールしてください。（今回は各インストール方法の詳細は割愛）

● NetBeans の入手はこちらから
● Java SE 7 の入手はこちらから

leJOS 環境構築から開発までの手順

LEGO Mindstorms EV3 で Java アプリケーションを動作させるためには、下記の手順に従って行います。

ブート可能なマイクロ SD カードへ leJOS のインストール
ブート可能なマイクロ SD カードから起動
leJOS で WiFi 設定
ローカル Maven レポジトリに必要ライブラリをインストール
Maven プロジェクトの作成
アプリケーションの開発
アプリケーションのビルド/デプロイ
アプリケーションの実行

(0)ブート可能なマイクロ SD カードを作成

ブート可能で FAT 32 でフォーマットしたマイクロ SD カードを作成してください。Mac OS/X の場合、「アプリケーション」→「ユーティリティ」→「ディスクユーティリティ」を実行して作成できます。「パーティションのレイアウト」から「１パーティション」を選択し、「パーティション情報」に「名前」を記入してください。

次に「オプション…」ボタンを押下してください、すると下記のウィンドウが表示されます。ここで、「マスター・ブート・レコード」にチェックされている事を確認し「OK」ボタンを押下してください。

最後に「適用」ボタンを押下してください、押下すると下記の画面が表示されます。ここで「パーティション」ボタンを押下してください。

(1) SD カードへファイルのコピーと展開 (Mac/Linux/Windows 環境で実施)

事前準備の (3) でダウンロードした leJOS_EV3_0.8.1-beta.tar.gz を展開してください。

> tar xvf leJOS_EV3_0.8.1-beta.tar.gz
> ls
COPYING README.md bin lejosimage.zip lib samples.zip sd500.zip

展開すると lejosimage.zip が存在しますので、このファイルと JRE7 を SD にコピーしてください。ファイルをコピーした後、SD カード内で lejosimage.zip を展開してください (※　JRE の展開は不要です)。

> cp ejre-7u55-fcs-b13-linux-arm-sflt-headless-17_mar_2014.tar.gz lejosimage.zip /Volumes/LEGO-PART/
> cd /Volumes/LEGO-PART/
> unzip lejosimage.zip
Archive: lejosimage.zip
creating: lejos/
creating: lejos/bin/
inflating: lejos/bin/partition.sh
inflating: lejos/bin/partfuncs.sh
inflating: lejos/bin/install.sh
inflating: lejos/bin/funcs.sh
inflating: lejos/bin/spinner.sh
inflating: lejos/bin/check.sh
creating: lejos/images/
inflating: lejos/images/lejoslogo.ev3i
inflating: lejosimage.bz2
inflating: uImage
inflating: uImageStandard
extracting: version

# 展開した後の SD カードのディレクトリ構成
# ls -F
ejre-7u55-fcs-b13-linux-arm-sflt-headless-17_mar_2014.tar.gz*
lejos/
lejosimage.bz2*
lejosimage.zip*
uImage*
uImageStandard*
version*

以上で準備は完了です。マイクロ SD カードをアンマウントして、システムから取り出してください。

取り出した後、EV3 にマイクロ SD カードを挿入してください。またその際、WiFi の USB アダプタも USB ポートに挿入してください。

(2)ブート可能なマイクロ SD カードから起動（EV3 で実施）

LEGO MindStorm に SD カードが挿入されている事を確認し、EV3 のボタンを押して起動してください。すると自動的に Linux 環境の構築(ファイルシステム構築等も含む)やJava 環境の構築を実施します。 (作業終了まで：約 8 分)

内部的には下記の処理等が行われています。
1. Resize FAT32 fs
2. Resize Complete
3. Create Linux fs
4. Expand Image
5. Prepare Install
6. Deleting old files
7. Expand Image
8. Start Install
9. Installing rootfs
10. Installing modules
11. Installing leJOS
12. Configure network
13. Install links
14. Install lib jna
15. Copy config files
16. Install jre
17. Extracting jre
18. Optimize java
19. Remove temp files
20. Installing kernel
21. Sync disks
22. Unmount disks
23. Rebooting

EV 3 はインストールや設定が完了すると自動的に再起動します。正常に起動が完了すると大きなブザー音が鳴った後、leJOS のメニュー画面が表示されます。

(3) leJOS で WiFi 設定（EV3 で実施）

WiFi の設定は、WiFi の設定マークを選択して行います。選択すると接続可能なアクセス・ポイントの一覧が表示されます。

自身の適切なアクセス・ポイントを選択してください。選択すると下記の画面が出てきます。

ここで、アクセス・ポイントに接続するため WEP のパスワードを入力します。基本的にはキーボード配列と同様にローマ字が並んでいますので、適切なパスワード文字を入力してください。ここで画面の一番最下行に特別な命令用の文字 (U,l,x,D) が記載されています、それぞれの意味は下記の通りです。大文字のローマ字を入力したい場合は、U を押す等してパスワードを正しく入力してください。

U : 大文字に変換 (Upper)
l : 小文字に変換 (lower)
x : 1文字消去
D : 設定終了 (Done)

パスワードを正しく入力した後、D を押下すると WiFi での接続ができるようになります。EV3 のメニュー画面で、IP アドレス: 10.0.1.1 と記載された行の下側に、割り当てられた IP アドレス(ここでは 192.168.1.100)が記載されていますので、この IP アドレスで EV 3 に接続できるようになります。EV3 に接続できるようになっているかどうかを確認するために、TELNET でログインをして確認してください。

> telnet 192.168.1.100
Trying 192.168.1.100…
Connected to 192.168.1.100.
Escape character is ‘^]’.

_____ _ _ ___
| _ |_ _ _| |___| | __|
| _| | | . | . | | _|
|__|__|___|___|___|_|_|

Rudolf 2011.01 EV3

正常に、WiFi の設定ができている場合、上記のようなログイン・プロンプトが表示されます。ここで login: 名に root を、パスワードは未入力（ノンパスワード）でエンター・キーを押下してください。すると EV3 にログインができるようになります。

(4) ローカル Maven レポジトリに必要ライブラリをインストール (Mac/Linux/Windows 環境で実施)

今回、統合開発環境には NetBeans を使用し、Maven プロジェクトとしてアプリケーション開発を行います。EV3 を制御する Java アプリケーション開発を行うためには、ev3classes.jar と dbusjava.jar が必要ですが、現在 leJOS 用の Maven レポジトリが存在していないようです。そこで、これら２つのファイルをローカルの Maven レポジトリにインストールしてください。２つのファイルは leJOS_EV3_0.8.1-beta.tar.gz を展開したディレクトリ内に含まれています。

> cd leJOS_EV3_0.8.1-beta/lib/ev3
> ls
dbusjava-src.zip dbusjava.jar ev3classes-src.zip ev3classes.jar

次に、２つのファイルを mvn コマンドでローカル・レポジトリにインストールします。下記の 2 つのコマンドを実行してください。仮に mvn コマンドが自身の実行パス内に見つからない場合は、NetBeans 付属のmvn コマンドをご利用ください。

例：Mac OS/X (Linux) の場合 mvn はデフォルトで下記に存在します。
“/Applications/NetBeans/NetBeans 8.0.app/Contents/Resources/NetBeans/java/maven/bin/mvn”

> mvn install:install-file -Dfile=ev3classes.jar -DgroupId=ev3.classes -DartifactId=ev3classes -Dversion=0.8.1 -Dpackaging=jar
[INFO] Scanning for projects…
[INFO]
[INFO] ————————————————————————
[INFO] Building Maven Stub Project (No POM) 1
[INFO] ————————————————————————
[INFO]
[INFO] — maven-install-plugin:2.3.1:install-file (default-cli) @ standalone-pom —
[INFO] Installing /Users/USER_NAME/Downloads/leJOS_EV3_0.8.1-beta/lib/ev3/ev3classes.jar to /Users/USER_NAME/.m2/repository/ev3/classes/ev3classes/0.8.1/ev3classes-0.8.1.jar
[INFO] Installing /var/folders/5x/qqvk50_50xl7jvfhyf9_tdd40000gn/T/mvninstall6910985062740456417.pom to /Users/USER_NAME/.m2/repository/ev3/classes/ev3classes/0.8.1/ev3classes-0.8.1.pom
[INFO] ————————————————————————
[INFO] BUILD SUCCESS
[INFO] ————————————————————————
[INFO] Total time: 0.623s
[INFO] Finished at: Tue Apr 22 20:22:57 WIT 2014
[INFO] Final Memory: 5M/245M
[INFO] ————————————————————————

> mvn install:install-file -Dfile=dbusjava.jar -DgroupId=ev3.dbus -DartifactId=dbusjava -Dversion=0.8.1 -Dpackaging=jar
[INFO] Scanning for projects…
[INFO]
[INFO] ————————————————————————
[INFO] Building Maven Stub Project (No POM) 1
[INFO] ————————————————————————
[INFO]
[INFO] — maven-install-plugin:2.3.1:install-file (default-cli) @ standalone-pom —
[INFO] Installing /Users/USER_NAME/Downloads/leJOS_EV3_0.8.1-beta/lib/ev3/dbusjava.jar to /Users/USER_NAME/.m2/repository/ev3/dbus/dbusjava/0.8.1/dbusjava-0.8.1.jar
[INFO] Installing /var/folders/5x/qqvk50_50xl7jvfhyf9_tdd40000gn/T/mvninstall6420442918254641308.pom to /Users/USER_NAME/.m2/repository/ev3/dbus/dbusjava/0.8.1/dbusjava-0.8.1.pom
[INFO] ————————————————————————
[INFO] BUILD SUCCESS
[INFO] ————————————————————————
[INFO] Total time: 0.597s
[INFO] Finished at: Tue Apr 22 20:25:04 WIT 2014
[INFO] Final Memory: 6M/310M
[INFO] ————————————————————————

例：Windows の場合 mvn はデフォルトで下記に存在します。
　C:\Program Files\NetBeans 8.0\java\maven\bin

Windows で mvn コマンドをターミナルから実行するために、下記２つの環境変数の設定を行ってください。
● JAVA_HOME を新規追加 : JDK をインストールした場所
● PATH へ追加 : maven　コマンドへのパスの追加

上記、環境変数の設定を行った後、lib\ev3 ディレクトリに移動し下記のコマンドを実行してください。※ 大文字、小文字の打ち間違いにご注意ください。

C:\Users\USER_NAME\Desktop\leJOS_EV3_0.8.1-beta_win32\lib\ev3 > mvn install:install-file -Dfile=dbusjava.jar -DgroupId=ev3.dbus -DartifactId=dbusjava -Dversion=0.8.1 -Dpackaging=jar
[INFO] Scanning for projects…
[INFO]
[INFO] ————————————————————————
[INFO] Building Maven Stub Project (No POM) 1
[INFO] ————————————————————————
[INFO]
[INFO] — maven-install-plugin:2.3.1:install-file (default-cli) @ standalone-po
m —
[INFO] Installing C:\Users\USER_NAME\Desktop\leJOS_EV3_0.8.1-beta_win32\lib\ev3\db
usjava.jar to C:\Users\USER_NAME\.m2\repository\ev3\dbus\dbusjava.8.1\dbusjava-0
.8.1.jar
[INFO] Installing C:\Users\USER_NAME\AppData\Local\Temp\mvninstall1908329777283214
622.pom to C:\Users\USER_NAME\.m2\repository\ev3\dbus\dbusjava.8.1\dbusjava-0.8.
1.pom
[INFO] ————————————————————————
[INFO] BUILD SUCCESS
[INFO] ————————————————————————
[INFO] Total time: 0.760s
[INFO] Finished at: Thu Apr 24 19:29:44 JST 2014
[INFO] Final Memory: 5M/155M
[INFO] ————————————————————————
C:\Users\USER_NAME\Desktop\leJOS_EV3_0.8.1-beta_win32\lib\ev3> mvn install:install-
file -Dfile=ev3classes.jar -DgroupId=ev3.classes -DartifactId=ev3classes -Dversion=0.8.1 -Dpackaging=jar
[INFO] Scanning for projects…
[INFO]
[INFO] ————————————————————————
[INFO] Building Maven Stub Project (No POM) 1
[INFO] ————————————————————————
[INFO]
[INFO] — maven-install-plugin:2.3.1:install-file (default-cli) @ standalone-po
m —
[INFO] Installing C:\Users\USER_NAME\Desktop\leJOS_EV3_0.8.1-beta_win32\lib\ev3\ev
3classes.jar to C:\Users\USER_NAME\.m2\repository\ev3\classes\ev3classes.8.1\ev3
classes-0.8.1.jar
[INFO] Installing C:\Users\USER_NAME\AppData\Local\Temp\mvninstall2687157046215461
183.pom to C:\Users\USER_NAME\.m2\repository\ev3\classes\ev3classes.8.1\ev3class
es-0.8.1.pom
[INFO] ————————————————————————
[INFO] BUILD SUCCESS
[INFO] ————————————————————————
[INFO] Total time: 0.712s
[INFO] Finished at: Thu Apr 24 19:31:49 JST 2014
[INFO] Final Memory: 5M/158M
[INFO] ————————————————————————

(5) Maven プロジェクトの作成 (Mac/Linux/Windows 環境で実施)

NetBeans のメニューからプロジェクトを作成してください。まず、「ファイル(F)」→「新規プロジェクト(W)…」を選択してください。

選択すると下記の「新規プロジェクト」作成用のウィンドウが表示されます。ここで、「カテゴリ (C) :」から「Maven」を選択し、「プロジェクト (P) :」から「Javaアプリケーション」を選択し「次へ」ボタンを押下してください。

ボタンを押下すると下記の「新規 Java アプリケーション」ウィンドウが表示されます。ここで「プロジェクト名 (N) :」、「プロジェクトの場所 (L) :」、「グループ ID (G) :」、「バージョン (V) :」、「パッケージ (P) :」に適切な値を入力した後、最後に「終了 (F)」ボタンを押下してください。

プロジェクトが正常に作成されるとプロジェクト・タブに下記のようなプロジェクトが作成されます。

プロジェクトを作成した後、pom.xml ファイルに下記を記載してください。

<?xml version="1.0" encoding="UTF-8"?>
<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/xsd/maven-4.0.0.xsd">
    
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.yoshio3</groupId>
    <artifactId>LEGOMind</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>jar</packaging>
    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <maven.compiler.source>1.7</maven.compiler.source>
        <maven.compiler.target>1.7</maven.compiler.target>
    </properties>

    <build>
        <extensions>
            <extension>
                <groupId>org.apache.maven.wagon</groupId>
                <artifactId>wagon-ssh</artifactId>
                <version>1.0</version>
            </extension>
        </extensions>
        <plugins>
            <!--- MANIFEST ファイルを作成するプラグイン -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-jar-plugin</artifactId>
                <version>2.4</version>
                <configuration>
                    <archive>
                        <manifest>
                            <mainClass>com.yoshio3.legomind.EV3AppMain</mainClass>
                        </manifest>
                        <manifestEntries>
                            <Class-Path>/home/root/lejos/lib/ev3classes.jar /home/root/lejos/libjna/usr/share/java/jna.jar</Class-Path>
                        </manifestEntries> 
                    </archive>
                </configuration>
            </plugin>
            <!--- デスクトップからネット経由で jar ファイルをコピーするためのプラグイン -->
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>wagon-maven-plugin</artifactId>
                <version>1.0-beta-5</version>
                <executions>
                    <execution>
                        <id>upload-jar</id>
                        <phase>package</phase>
                        <goals>
                            <goal>upload</goal>
                        </goals>
                        <configuration>
                            <!-- ~/.m2/settings.xml ファイルに記述したログインID、パスワードの参照 --> 
                            <serverId>ev3-root</serverId>
                            <!-- EV3 に割り当てられている IP アドレス --> 
                            <url>scp://192.168.1.100/</url>  
                            <fromDir>${project.basedir}/target</fromDir>  
                            <includes>*.jar</includes>  
                            <excludes>*-sources.jar</excludes>
                            <!-- EV3 のコピー先ディレクトリ --> 
                            <toDir>/home/lejos/programs</toDir>  
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>    

    <!-- ローカル・レポジトリにインストールしたファイルへの参照
    mvn install:install-file 
        -Dfile=ev3classes.jar 
        -DgroupId=ev3.classes 
        -DartifactId=ev3classes 
        -Dversion=0.8.1 -Dpackaging=jar
    -->
    <dependencies>
        <dependency>
            <groupId>ev3.classes</groupId>
            <artifactId>ev3classes</artifactId>
            <version>0.8.1</version>
        </dependency>
        
    <!-- ローカル・レポジトリにインストールしたファイルへの参照
    mvn install:install-file 
        -Dfile=dbusjava.jar 
        -DgroupId=ev3.dbus 
        -DartifactId=dbusjava 
        -Dversion=0.8.1
        -Dpackaging=jar
    -->
        <dependency>
            <groupId>ev3.dbus</groupId>
            <artifactId>dbusjava</artifactId>
            <version>0.8.1</version>
        </dependency>
    </dependencies>
</project>

また、Maven の設定ファイル ( ~/.m2/settings.xml (Windows では C:\Users\USER_NAME\.m2)) に下記を記載してください。

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
                     http://maven.apache.org/xsd/settings-1.0.0.xsd">
    <servers>
        <server>  
            <id>ev3-root</id>  
            <!---- EV3 の root ログイン ID -->
            <username>root</username>  
            <!---- EV3 の root ログイン パスワード -->
            <password>password</password>
        </server>
    </servers>
</settings>

※　ご注意
pom.xml ファイルを設定、保存後に wagon のライブラリが存在しないため、下記のようにプロジェクトが「ロード不可能」と表示されます。

この場合、プロジェクトを右クリックし、「プロジェクトの問題を解決…」を選択してください（Maven のセントラルレポジトリよりライブラリを入手）。

選択すると下記のウィンドウが表示されます。ここで「解決 (R) …」ボタンを押下してください。

(6) アプリケーションの開発(Mac/Linux/Windows 環境で実施)

Maven プロジェクトを作成したので実際にプログラムを初めてみましょう。今回は上記 pom.xml の MANIFEST ファイルの定義 <manifest> の <mainClass> タグ内でメイン・クラスとしてcom.yoshio3.legomind.EV3AppMain を定義しましたので、このクラスを作成します。また、初めての LEGO Mindstorms のアプリケーション開発ということで、やはり Hello World から初めてみましょう。プロジェクトの中に含まれる「com.yoshio3.legomind」パッケージを右クリックし「新規」→「Java クラス …」を選択してください。

選択すると下記のウィンドウが表示されます。ここで「クラス名 (N) :」に「EV3AppMain」と入力し「終了 (F)」ボタンを押下してください。

クラスを作成すると下記の画面が表示されます。

ここで、「EV3AppMain」クラスに対して、EV 3 のパネルに文字列を表示させ、3 秒程緑色の LED を点滅させるプログラムを下記のように記載します。

package com.yoshio3.legomind;

import lejos.hardware.Button;
import lejos.hardware.lcd.LCD;
import lejos.utility.Delay;

/**
 *
 * @author Yoshio Terada
 */
public class EV3AppMain {

    public static void main(String... argv) {
        //パネルに文字列を表示
        LCD.drawString("Hello World", 0, 0);
        //緑の点滅ボタンを３秒間光らせる(有効値: 0 - 9)
        Button.LEDPattern(4);
        Delay.msDelay(3000);
    }
}

(7) アプリケーションのビルド/デプロイ(Mac/Linux/Windows 環境で実施)

コードを実装した後、プロジェクトをビルドしてください。プロジェクト・タブから「LEGOMind-Sample」プロジェクトを右クリックし「ビルド」を選択してください。

ビルドを行うと下記のメッセージが表示され、org.codehaus.mojo の wagon-maven-plugin を通じて、WiFi のネットワーク経由で自動的に /home/lejos/programs ディレクトリ配下に　LEGOMind-1.0-SNAPSHOT.jar ファイルが配備されます。

cd /Users/USER_NAME/NetBeansProjects/LEGOMind; JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home "/Applications/NetBeans/NetBeans 8.0.app/Contents/Resources/NetBeans/java/maven/bin/mvn" install
Scanning for projects...
------------------------------------------------------------------------
Building LEGOMind 1.0-SNAPSHOT
------------------------------------------------------------------------
--- maven-resources-plugin:2.5:resources (default-resources) @ LEGOMind ---
[debug] execute contextualize
Using 'UTF-8' encoding to copy filtered resources.
skip non existing resourceDirectory /Users/USER_NAME/NetBeansProjects/LEGOMind/src/main/resources
--- maven-compiler-plugin:2.3.2:compile (default-compile) @ LEGOMind ---
Nothing to compile - all classes are up to date
--- maven-resources-plugin:2.5:testResources (default-testResources) @ LEGOMind ---
[debug] execute contextualize
Using 'UTF-8' encoding to copy filtered resources.
skip non existing resourceDirectory /Users/USER_NAME/NetBeansProjects/LEGOMind/src/test/resources
--- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @ LEGOMind ---
No sources to compile
--- maven-surefire-plugin:2.10:test (default-test) @ LEGOMind ---
Surefire report directory: /Users/USER_NAME/NetBeansProjects/LEGOMind/target/surefire-reports
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
--- maven-jar-plugin:2.4:jar (default-jar) @ LEGOMind ---
Building jar: /Users/USER_NAME/NetBeansProjects/LEGOMind/target/LEGOMind-1.0-SNAPSHOT.jar
--- wagon-maven-plugin:1.0-beta-5:upload (upload-jar) @ LEGOMind ---
Uploading /Users/USER_NAME/NetBeansProjects/LEGOMind/target/LEGOMind-1.0-SNAPSHOT.jar to scp://192.168.1.100///home/lejos/programs/LEGOMind-1.0-SNAPSHOT.jar ...
--- maven-install-plugin:2.3.1:install (default-install) @ LEGOMind ---
Installing /Users/USER_NAME/NetBeansProjects/LEGOMind/target/LEGOMind-1.0-SNAPSHOT.jar to /Users/USER_NAME/.m2/repository/com/yoshio3/LEGOMind/1.0-SNAPSHOT/LEGOMind-1.0-SNAPSHOT.jar
Installing /Users/USER_NAME/NetBeansProjects/LEGOMind/pom.xml to /Users/USER_NAME/.m2/repository/com/yoshio3/LEGOMind/1.0-SNAPSHOT/LEGOMind-1.0-SNAPSHOT.pom
------------------------------------------------------------------------
BUILD SUCCESS
------------------------------------------------------------------------
Total time: 4.837s
Finished at: Tue Apr 22 21:09:27 WIT 2014
Final Memory: 11M/312M
------------------------------------------------------------------------

8. アプリケーションの実行（EV3 で実施）

leJOS のメニュー画面より Programs (/home/lejos/programs ディレクトリ)を選択してください。

選択するとデプロイされているファイル一覧が表示されますので、LEGOMind-1.0-SNAPSHOT.jar を選択してください。

選択すると下記の画面が表示されます。そのままエンター・キー（真ん中のボタン）を押下してください。

押下すると下記の Duke が手を振っている画面 (しばらくお待ちください) が表示されます。アプリケーションをロードするまで数秒かかりますのでそのままお待ちください。

アプリケーションがロードされると下記のように実行され、メニューに「Hello World」が表示され、ボタンの LED が緑色に点滅する事を確認できます。

9. LEGO を組み立てて、超音波センサー、タッチ・センサー、モータ(車輪)を取り付けます。

上記で、Java を使って LEGO Mindstorms を制御できる事がわかりました。後は EV3 に LEGO のパーツを組み立てて、超音波センサーやタッチ・センサー、モータ(車輪)などを取り付けて自分オリジナルのロボットを組み立ててみてください。

その後で、下記 GitHub にアップロードしているコード例をご参照いただき実装すると、センサーから受け取った情報を元に EV3 を制御できるようになります。

GitHub にアップしたサンプルは、タッチセンサーに何かがぶつかると車輪が逆方向に回転し、超音波センサーに物を近づけると車輪の回転スピードが遅くなります。最後に EV3 の何らかのボタンを押すとアプリケーションを終了します。
https://github.com/yoshioterada/Java-Sample-app-for-LEGO-Mindstorms

今回私の上記実装では、車輪毎にリスナーを登録しセンサーからの情報に応じて車輪を制御する方法で実装しましたが、leJOS で提供されているサンプルを確認すると、様々な方法で実装ができるようです。是非色々お試しください。

また、調べていてちょっとおもしろかったのが、上記のようにデプロイしなくても、デスクトップの Java アプリケーションからWiFi 経由 (RMI) でリモートのEV3 を制御する事ができるので、これと JavaFX や WebSocket と組み合わせて応用すればスマートフォンや他のデバイスからリアルタイムに EV3 を制御できるようになるのではないかと想定します。

package com.yoshio3.legomind;

import java.net.MalformedURLException;
import java.rmi.NotBoundException;
import java.rmi.RemoteException;
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
import java.util.logging.Level;
import java.util.logging.Logger;
import lejos.remote.ev3.RMIRegulatedMotor;
import lejos.remote.ev3.RMISampleProvider;
import lejos.remote.ev3.RemoteEV3;
import lejos.robotics.RegulatedMotor;
import lejos.robotics.RegulatedMotorListener;

/**
 *
 * @author Yoshio Terada
 */
public class RemoteOperation {

    public static void main(String... argv) {
        RemoteEV3 ev3;
        try {
            ev3 = new RemoteEV3("192.168.1.100");
            RMISampleProvider sampleProv = ev3.createSampleProvider("S1", "lejos.hardware.sensor.EV3TouchSensor", "sensor");

            // 車輪の制御 
            RMIRegulatedMotor right = ev3.createRegulatedMotor("B", 'L');
            RMIRegulatedMotor left = ev3.createRegulatedMotor("C", 'L');
            right.resetTachoCount();
            left.resetTachoCount();

            ExecutorService execSvc = Executors.newFixedThreadPool(3);
            execSvc.submit(new RunMotor(right));
            execSvc.submit(new RunMotor(left));

            Future<Float> res = execSvc.submit(new MonitoringTouch(sampleProv));
            if (res.get() == 1.0f) {
                right.stop(true);
                left.stop(true);
            }
        } catch (RemoteException | MalformedURLException | NotBoundException | InterruptedException | ExecutionException ex) {
            Logger.getLogger(RemoteOperation.class.getName()).log(Level.SEVERE, null, ex);
        }
    }
}

class RunMotor implements Runnable {

    RMIRegulatedMotor motor;

    RunMotor(RMIRegulatedMotor motor) {
        this.motor = motor;
    }

    @Override
    public void run() {
        try {
            motor.setSpeed(400);
            motor.rotate(360 * 20);
            motor.close();
        } catch (RemoteException ex) {
            Logger.getLogger(RunMotor.class.getName()).log(Level.SEVERE, null, ex);
        }
    }
}
...

最後に

leJOS のオリジナルのサイトでは Eclipse でプラグインをインストールし ant を用いて開発する方法が紹介されていました。Eclipse ユーザの方はオリジナル・サイトをご参照いただければ幸いです。一応、私も Eclipse で試しましたが、上記オリジナルサイトの記載内容に従い設定を行う事で Eclipse で開発からデプロイまで行う事ができる所までは確認しました。

普段、私は NetBeans を使用しているため、今回 NetBeans で同様に開発ができないか？！と考え、上記環境設定を行いました。一旦、上記 1 〜 4 までの設定を行うと、以降の開発は 5 〜 8 までを繰り返し行うだけで NetBeans でも簡単に開発ができるようになります。また Eclipse と同様に、ビルドを行った時点で自動的に WiFi 経由でデプロイができるようになるためとても便利です。

どうぞ、Java で LEGO Mindstorms をお楽しみください。

PS.
Java SE 8 のローンチ・イベントで発表された Java SE Embedded で LEGO Mindstorms の説明資料も参考として紹介します。

また、Java Champion の Adam Bien もRun Java 7u40 Embedded on Lego Mindstormsのエントリで leJOS を使用した LEGO Mindstorms の制御のデモも公開していますので併せてご紹介します。

追記メモ２.
Java SE Embedded 8 を使う場合の手順。

1. Oracle Java SE Embedded version 8 の DownLoad

Oracle Java SE Embedded version 8のダウンロード

上記のページ内に下記の記述があります。
Java SE Embedded 8 enables developers to create customized JREs using the JRECreate tool. Starting with Java SE Embedded 8, individual JRE downloads for embedded platforms are no longer provided. To get started, download the bundle below and follow instructions to create a JRE that suits your application’s needs.

これは、Java SE Embedded 8 以降では、Java SE 7 のように個別の JRE を提供しないため、自分専用の JRE を、JRECreate ツールを使って作成する必要がある事が書かれています。

2. Create a Custom JRE with jrecreate

jrecreate コマンドを使用してカスタムの JRE を作成してください。

※ jrecreate コマンドの引数の詳細は下記をご参照ください。
jrecreate Options

上記、説明内容に従って、カスタムの JRE を作成してください。

> tar xvfz ejdk-8-fcs-b132-linux-arm-sflt-03_mar_2014.tar.gz
> cd ejdk1.8.0/
> ls
bin lib linux_arm_sflt
> cd bin
> ./jrecreate.sh -vm all -d /tmp/ejre1.8.0
Options {
ejdk-home: /Users/USER_NAME/Downloads/ejdk1.8.0
dest: /tmp/ejre1.8.0
target: linux_arm_sflt
vm: all
runtime: jre
debug: false
keep-debug-info: false
no-compression: false
dry-run: false
verbose: false
extension: []
}
を使用してJREを作成しています

ターゲットJREサイズは45,523 KBです(ディスクの使用量はこれより多いことがあります)。
埋込みJREが正常に作成されました
> cd /tmp/
> ls
ejre1.8.0
> tar cvf ejre1.8.0.tar ejre1.8.0
a ejre1.8.0
a ejre1.8.0/bin
a ejre1.8.0/bom
a ejre1.8.0/lib
a ejre1.8.0/release
a ejre1.8.0/lib/arm
a ejre1.8.0/lib/calendars.properties
a ejre1.8.0/lib/classlist
a ejre1.8.0/lib/content-types.properties
a ejre1.8.0/lib/currency.data
a ejre1.8.0/lib/ext
a ejre1.8.0/lib/hijrah-config-umalqura.properties
a ejre1.8.0/lib/jce.jar
a ejre1.8.0/lib/jsse.jar
a ejre1.8.0/lib/logging.properties
a ejre1.8.0/lib/meta-index
a ejre1.8.0/lib/net.properties
a ejre1.8.0/lib/resources.jar
a ejre1.8.0/lib/rt.jar
a ejre1.8.0/lib/security
a ejre1.8.0/lib/tzdb.dat
a ejre1.8.0/lib/security/blacklist
a ejre1.8.0/lib/security/cacerts
a ejre1.8.0/lib/security/java.policy
a ejre1.8.0/lib/security/java.security
a ejre1.8.0/lib/security/local_policy.jar
a ejre1.8.0/lib/security/trusted.libraries
a ejre1.8.0/lib/security/US_export_policy.jar
a ejre1.8.0/lib/ext/meta-index
a ejre1.8.0/lib/ext/sunjce_provider.jar
a ejre1.8.0/lib/arm/client
a ejre1.8.0/lib/arm/jli
a ejre1.8.0/lib/arm/jvm.cfg
a ejre1.8.0/lib/arm/libjava.so
a ejre1.8.0/lib/arm/libjsig.so
a ejre1.8.0/lib/arm/libnet.so
a ejre1.8.0/lib/arm/libnio.so
a ejre1.8.0/lib/arm/libverify.so
a ejre1.8.0/lib/arm/libzip.so
a ejre1.8.0/lib/arm/minimal
a ejre1.8.0/lib/arm/minimal/libjsig.so
a ejre1.8.0/lib/arm/minimal/libjvm.so
a ejre1.8.0/lib/arm/minimal/Xusage.txt
a ejre1.8.0/lib/arm/jli/libjli.so
a ejre1.8.0/lib/arm/client/libjsig.so
a ejre1.8.0/lib/arm/client/libjvm.so
a ejre1.8.0/lib/arm/client/Xusage.txt
a ejre1.8.0/bin/java
a ejre1.8.0/bin/keytool
a ejre1.8.0/bin/rmid
a ejre1.8.0/bin/rmiregistry
> gzip -c ejre1.8.0.tar > ejre1.8.0.tar.gz
> cp ejre1.8.0.tar.gz /Volumes/LEGO-PART/
> cp lejosimage.zip /Volumes/LEGO-PART/
> cd /Volumes/LEGO-PART/
> unzip lejosimage.zip
Archive: lejosimage.zip
creating: lejos/
creating: lejos/bin/
inflating: lejos/bin/partition.sh
inflating: lejos/bin/partfuncs.sh
inflating: lejos/bin/install.sh
inflating: lejos/bin/funcs.sh
inflating: lejos/bin/spinner.sh
inflating: lejos/bin/check.sh
creating: lejos/images/
inflating: lejos/images/lejoslogo.ev3i
inflating: lejosimage.bz2
inflating: uImage
inflating: uImageStandard
extracting: version

SD カードにファイルをコピーして展開した後、SD ディスクをアンマウントしてください。後は、上記 (2)ブート可能なマイクロ SD カードから起動（EV3 で実施）と同様に、作成した SD から EV3 を起動して(2)以降の処理を行ってください。
上記で、Java SE Embedded 8 で制御できるようになります。

Java SE 8 Embedded のコードを実装するためには、Maven の pom.xml の下記の行 (コンパイラのソース、ターゲット) をそれぞれ 1.7 → 1.8 に修正して実装してください。

  
    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <maven.compiler.source>1.8</maven.compiler.source>
        <maven.compiler.target>1.8</maven.compiler.target>
    </properties>

備考：本来であれば、LEGO Mindstorms は Java SE Embedded 8 の “Compact Profile 2” で動作するようなのですが、現在 Compact Profile 2 で JRE を作成した場合は現時点で動作しません。本件は、leJOS のチームと Oracle の Embedded チームが現在調査中です。
上記は現時点(2014年4月28日時点)でのワークアラウンドとしてご利用ください。

2014年4月23日 at 6:05 午後 13件のコメント

jBatch(JSR-352) on Java SE 環境

先日のデブサミの発表後、jBatch (JSR-352) についてご質問を頂き、また別件でも同じ質問を頂きましたので、その内容を共有致します。

jBatch を cron 等で実行したいのだが、jBatch は Java EE 環境でしか実行できないのか？とのご質問を頂きました。
答えは、jBatch の仕様上、Java SE 環境上でも動作するように実装されております。

ただし、Java EE 環境上で実装する方がとても簡単に実装・運用ができますので個人的にはJava EE 環境上での動作をお薦めします。仮に Java SE 環境上で jBatch (jBatch の RI)を実行したい場合は下記をご参照ください。

1. 準備

Java SE 環境上で jBatch を稼働させるためには、JavaDB(Derby) が必要です。
また、jBatch の RI を使って Java SE 環境上で動作させるためには、
jBatch RI の実行に必要なライブラリ一式を下記より入手します。

https://java.net/projects/jbatch/downloads/download/jsr352-SE-RI-1.0.zip

zip を展開すると下記のファイルが含まれています。下記全ファイルを lib 配下にコピーしてください。

derby.jar
javax.inject.jar
jsr352-SE-RI-javadoc.jar
javax.batch.api.jar
jsr352-RI-spi.jar
jsr352-SE-RI-runtime.jar

2. Batch コンテナを実行するための設定

次に Batch コンテナを稼働させるためのプロパティの設定を行います。
META-INF ディレクトリ配下に services ディレクトリを作成して
それぞれ下記のファイルを作成してください。

src/META-INF/services/batch-config.properties

JDBC_DRIVER=org.apache.derby.jdbc.EmbeddedDriver
# JDBC_URL=jdbc:derby://localhost:1527/batchdb;create=true
JDBC_URL=jdbc:derby://localhost:1527/batchdb

src/META-INF/services/batch-services.properties

J2SE_MODE=true

以上で基本的には Java SE 環境上で動作させるために必要な設定は完了です。

3. 動作確認

それでは、バッチであるファイルの内容を別のファイルに書き出すサンプルを作成します。(※ 以降は Java EE 環境での実装と同じです。)
下記に、本 jBatch プロジェクトのディレクトリ構成を下記に示します。

まず、メイン・メソッドから Batch の JOB: “my-batch-job” を起動します。

package com.yoshio3.main;

import java.util.Properties;
import javax.batch.operations.JobOperator;
import javax.batch.runtime.BatchRuntime;

/**
 *
 * @author Yoshio Terada
 */
public class StandAloneBatchMain {

    public static void main(String... args) {
        JobOperator job = BatchRuntime.getJobOperator();
        long id = job.start("my-batch-job", new Properties());
    }    
}

この、”my-batch-job” の処理内容は、META-INF/batch-jobs ディレクトリ配下に、”my-batch-job.xml” として定義します。

“my-batch-job” の内容を下記に示します。プロパティを２つ input_file,output_file 定義し、それぞれ /tmp/input.txt, /tmp/output.txt を示します。また、JOB の step としてチャンク形式の step を１つ定義し、データの読み込み用(reader)、処理用(processor)、書き込み(writer)用の処理を、それぞれ、MyItemReader, MyItemProcessor, MyItemWriter に実装します。

<job id="my-batch-job"
     xmlns="http://xmlns.jcp.org/xml/ns/javaee" version="1.0">
    <properties>
        <property name="input_file" value="/tmp/input.txt"/>
        <property name="output_file" value="/tmp/output.txt"/>
    </properties>

    <step id="first-step">
        <chunk item-count="5">
            <reader    ref="com.yoshio3.chunks.MyItemReader"/>
            <processor ref="com.yoshio3.chunks.MyItemProcessor"/>
            <writer    ref="com.yoshio3.chunks.MyItemWriter"/>
        </chunk>
    </step>
</job>

読み込み用の処理は、ItemReader を実装したクラスを作成します。ここでは、input_file で指定されたプロパティのファイル(/tmp/input.txt)ファイルを読み込み、１行読み込んでその値を返します。

package com.yoshio3.chunks;

import java.io.BufferedReader;
import java.io.Serializable;
import java.nio.charset.Charset;
import java.nio.file.Files;
import java.nio.file.Paths;
import javax.batch.api.chunk.ItemReader;
import javax.batch.runtime.context.JobContext;
import javax.inject.Inject;

public class MyItemReader implements ItemReader {

    @Inject
    JobContext jobCtx;

    BufferedReader bufReader;

    @Override
    public void open(Serializable checkpoint) throws Exception {        
        String fileName = jobCtx.getProperties()
                .getProperty("input_file");
        bufReader = Files.newBufferedReader(Paths.get(fileName),Charset.forName("UTF-8"));
    }

    @Override
    public void close() throws Exception {
        bufReader.close();
    }

    @Override
    public Object readItem() throws Exception {
        String data = bufReader.readLine();
        System.out.println("Reader readItem : " + data);
        return data;
    }

    @Override
    public Serializable checkpointInfo() throws Exception {
        return null;
    }
}

次に、読み込んだデータの加工処理部分は、ItemProsessor を実装したクラスに記述します。ここでは、読み込んだデータ(文字列)に対して、文字列を付加して返しています。

package com.yoshio3.chunks;

import javax.batch.api.chunk.ItemProcessor;

/**
 *
 * @author Yoshio Terada
 */
public class MyItemProcessor implements ItemProcessor {

    @Override
    public Object processItem(Object item) throws Exception {
        String line = (String)item ;
        StringBuilder sBuilder = new StringBuilder();
        sBuilder.append("Processor processItem : ");
        sBuilder.append(line);
        String returnValue = sBuilder.toString();
        System.out.println(returnValue);
        return returnValue;
    }    
}

最後に書き出し部分を ItemWriter を実装したクラスに記述します。ここでは、oputput_file のプロパティを取得して書き出すファイル名を取得しています。次にファイルに対して取得したデータを書き出しています。

package com.yoshio3.chunks;

import java.io.BufferedWriter;
import java.io.Serializable;
import java.nio.charset.Charset;
import java.nio.file.Files;
import java.nio.file.Paths;
import java.util.List;
import javax.batch.api.chunk.ItemWriter;
import javax.batch.runtime.context.JobContext;
import javax.inject.Inject;

/**
 *
 * @author Yoshio Terada
 */
public class MyItemWriter implements ItemWriter {

    @Inject
    JobContext jobCtx;

    String fileName;

    BufferedWriter bufWriter;

    @Override
    public void open(Serializable checkpoint) throws Exception {
        fileName = jobCtx.getProperties()
                .getProperty("output_file");
        bufWriter = Files.newBufferedWriter(Paths.get(fileName), Charset.forName("UTF-8"));
    }

    @Override
    public void close() throws Exception {
        bufWriter.close();
    }

    @Override
    public void writeItems(List<Object> items) throws Exception {
        for (Object obj : items) {
            String data = (String) obj;
            System.out.println("Writer writeItems : " + data);

            bufWriter.write(data);
            bufWriter.newLine();
        }
    }

    @Override
    public Serializable checkpointInfo() throws Exception {
        return null;
    }
}

上記を実装した後、コンパイルをしてください。

# java -classpath
　　lib/jsr352-ri-1.0/javax.inject.jar:
　　lib/jsr352-ri-1.0/derby.jar:
　　lib/jsr352-ri-1.0/jsr352-RI-spi.jar:
　　lib/jsr352-ri-1.0/javax.batch.api.jar:
　　lib/jsr352-ri-1.0/jsr352-SE-RI-javadoc.jar:
　　lib/jsr352-ri-1.0/jsr352-SE-RI-runtime.jar:
　　build/classes com.yoshio3.main.StandAloneBatchMain

実行すると下記のようなログを確認できます。chunk 形式ではデフォルトで 10 件まとめて読み込み＆処理を実施し、
まとめて 10 件書き込むという動作を下記からも確認できるかと思います。

2 18, 2014 12:10:50 午後 com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl createSchema
情報: JBATCH schema does not exists. Trying to create it.
2 18, 2014 12:10:50 午後 com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl createIfNotExists
情報: CHECKPOINTDATA table does not exists. Trying to create it.
2 18, 2014 12:10:50 午後 com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl createIfNotExists
情報: JOBINSTANCEDATA table does not exists. Trying to create it.
2 18, 2014 12:10:50 午後 com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl createIfNotExists
情報: EXECUTIONINSTANCEDATA table does not exists. Trying to create it.
2 18, 2014 12:10:50 午後 com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl createIfNotExists
情報: STEPEXECUTIONINSTANCEDATA table does not exists. Trying to create it.
2 18, 2014 12:10:50 午後 com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl createIfNotExists
情報: JOBSTATUS table does not exists. Trying to create it.
2 18, 2014 12:10:50 午後 com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl createIfNotExists
情報: STEPSTATUS table does not exists. Trying to create it.
Reader readItem : hogehoge1
Processor processItem : hogehoge1
Reader readItem : hogehoge2
Processor processItem : hogehoge2
Reader readItem : hogehoge3
Processor processItem : hogehoge3
Reader readItem : hogehoge4
Processor processItem : hogehoge4
Reader readItem : hogehoge5
Processor processItem : hogehoge5
Reader readItem : hogehoge6
Processor processItem : hogehoge6
Reader readItem : hogehoge7
Processor processItem : hogehoge7
Reader readItem : hogehoge8
Processor processItem : hogehoge8
Reader readItem : hogehoge9
Processor processItem : hogehoge9
Reader readItem : hogehoge10
Processor processItem : hogehoge10
Writer writeItems : Processor processItem : hogehoge1
Writer writeItems : Processor processItem : hogehoge2
Writer writeItems : Processor processItem : hogehoge3
Writer writeItems : Processor processItem : hogehoge4
Writer writeItems : Processor processItem : hogehoge5
Writer writeItems : Processor processItem : hogehoge6
Writer writeItems : Processor processItem : hogehoge7
Writer writeItems : Processor processItem : hogehoge8
Writer writeItems : Processor processItem : hogehoge9
Writer writeItems : Processor processItem : hogehoge10
Reader readItem : hogehoge11
Processor processItem : hogehoge11
Reader readItem : hogehoge12
Processor processItem : hogehoge12
Reader readItem : hogehoge13
Processor processItem : hogehoge13
Reader readItem : hogehoge14
Processor processItem : hogehoge14
Reader readItem : hogehoge15
Processor processItem : hogehoge15
Reader readItem : hogehoge16
Processor processItem : hogehoge16
Reader readItem : hogehoge17
Processor processItem : hogehoge17
Reader readItem : hogehoge18
Processor processItem : hogehoge18
Reader readItem : hogehoge19
Processor processItem : hogehoge19
Reader readItem : hogehoge20
Processor processItem : hogehoge20
Writer writeItems : Processor processItem : hogehoge11
Writer writeItems : Processor processItem : hogehoge12
Writer writeItems : Processor processItem : hogehoge13
Writer writeItems : Processor processItem : hogehoge14
Writer writeItems : Processor processItem : hogehoge15
Writer writeItems : Processor processItem : hogehoge16
Writer writeItems : Processor processItem : hogehoge17
Writer writeItems : Processor processItem : hogehoge18
Writer writeItems : Processor processItem : hogehoge19
Writer writeItems : Processor processItem : hogehoge20
Reader readItem : null

書き込む間隔を変更したい場合は、Job XML の設定を変更し<chunk item-count=”5″>を設定します。

<job id="my-batch-job"
     xmlns="http://xmlns.jcp.org/xml/ns/javaee" version="1.0">
    <properties>
        <property name="input_file" value="/tmp/input.txt"/>
        <property name="output_file" value="/tmp/output.txt"/>
    </properties>

    <step id="first-step">
        <chunk item-count="5">
            <reader    ref="com.yoshio3.chunks.MyItemReader"/>
            <processor ref="com.yoshio3.chunks.MyItemProcessor"/>
            <writer    ref="com.yoshio3.chunks.MyItemWriter"/>
        </chunk>
    </step>
</job>

<chunk item-count=”5″>を設定した後、実行すると下記のような結果が得られます。

run:
Reader readItem : hogehoge1
Processor processItem : hogehoge1
Reader readItem : hogehoge2
Processor processItem : hogehoge2
Reader readItem : hogehoge3
Processor processItem : hogehoge3
Reader readItem : hogehoge4
Processor processItem : hogehoge4
Reader readItem : hogehoge5
Processor processItem : hogehoge5
Writer writeItems : Processor processItem : hogehoge1
Writer writeItems : Processor processItem : hogehoge2
Writer writeItems : Processor processItem : hogehoge3
Writer writeItems : Processor processItem : hogehoge4
Writer writeItems : Processor processItem : hogehoge5
Reader readItem : hogehoge6
Processor processItem : hogehoge6
Reader readItem : hogehoge7
Processor processItem : hogehoge7
Reader readItem : hogehoge8
Processor processItem : hogehoge8
Reader readItem : hogehoge9
Processor processItem : hogehoge9
Reader readItem : hogehoge10
Processor processItem : hogehoge10
Writer writeItems : Processor processItem : hogehoge6
Writer writeItems : Processor processItem : hogehoge7
Writer writeItems : Processor processItem : hogehoge8
Writer writeItems : Processor processItem : hogehoge9
Writer writeItems : Processor processItem : hogehoge10
Reader readItem : hogehoge11
Processor processItem : hogehoge11
Reader readItem : hogehoge12
Processor processItem : hogehoge12
Reader readItem : hogehoge13
Processor processItem : hogehoge13
Reader readItem : hogehoge14
Processor processItem : hogehoge14
Reader readItem : hogehoge15
Processor processItem : hogehoge15
Writer writeItems : Processor processItem : hogehoge11
Writer writeItems : Processor processItem : hogehoge12
Writer writeItems : Processor processItem : hogehoge13
Writer writeItems : Processor processItem : hogehoge14
Writer writeItems : Processor processItem : hogehoge15
Reader readItem : hogehoge16
Processor processItem : hogehoge16
Reader readItem : hogehoge17
Processor processItem : hogehoge17
Reader readItem : hogehoge18
Processor processItem : hogehoge18
Reader readItem : hogehoge19
Processor processItem : hogehoge19
Reader readItem : hogehoge20
Processor processItem : hogehoge20
Writer writeItems : Processor processItem : hogehoge16
Writer writeItems : Processor processItem : hogehoge17
Writer writeItems : Processor processItem : hogehoge18
Writer writeItems : Processor processItem : hogehoge19
Writer writeItems : Processor processItem : hogehoge20
Reader readItem : null

以上のように、Java SE の環境でも jBatch (JSR-352) を実行する事ができます。今回は参考のため jBatch の RI を使用しましたが、各 Java EE 7 準拠のアプリケーション・サーバで必要なライブラリはそれぞれ異なるかと想定します。必要なライブラリは各アプリケーション・サーバでお調べください。

2014年2月18日 at 12:51 午後 2件のコメント

Java EE 7 の新機能紹介と Java のイベントのご紹介

2014年2月13日（木）・14日（金）に目黒雅叙園でDevelopers Summit 2014 が開催されました。

今日は関東はあいにくの天気（大雪）で、とても足元が悪い中多くの方にイベントやセッションに参加して頂きまして誠にありがとうございました。また、Developers Summit 2014の事務局の皆様に置かれましても、同様に(Javaの)大規模イベントの企画を行っている者として、数多くの難作業があった事が用意に想像ができるため、イベントの主催者の皆様全員にあつく御礼を申し上げます。

私自身は、本日 14日(金)に【14-D-6】45 new features of Java EE 7 in 45 minutes というセッションを持たせて頂き発表を行いました。私のセッションにも非常に多くの開発者の皆様にご参加いただき良いフィードバックや、難しすぎたといったフィードバックなども頂きそうしたご意見を次回につなげていきたいと思います。本日発表に使用した資料を下記に公開します。実際にプレゼン時にはアニメーション等も使用しているため、下記の静的なコンテンツと内容は若干変わりますがご参考頂ければ誠に幸いです。

今回の個人的な所管として、45 分で 45 個 (総ページ数 P 90) の Java EE 7 の新機能をご紹介する事は初めてのチャレンジだったため、時間内に終わるか発表前から心配しておりましたが、結果、なんとかそして大幅な時間超過なく終える事ができました (最後はかなり足早になってしまい申し訳ありません)。本日、ご紹介した内容を本来であれば１件づつブログなどの記事にまとめられれば良いのですが、私自身次のステップに足を向けなればならないため、直近でブログに書く事は困難かもしれません。（もちろん時間ができれば書きますが。）どうぞご理解頂ければ幸いです。

さて、その次のステップでございますが、今日のセッションの最後に申し上げましたが、5 月に今年最大の Java のお祭りイベントを企画しております。そしてこれからその準備に多くの時間を割くようになります。現時点で詳細を申し上げる事はできませんが、5月18日〜5月24日まで、Java の開発者の皆様は極力日程を空けておいていただけないでしょうか。正式な情報が決まり次第、JJUG / 日本オラクルから正式アナウンスがあるかと想定します。

2/17 追記：JJUG のイベントとオラクルのイベントは、別イベントとして、別日程で開催されます。また、JJUG のイベント JJUG CCC につきましては、Call for Papers の募集も既に開始しておりますので日程等の詳細は JJUG のサイトをご覧ください。

日本オラクルからの正式なアナウンスまでは是非お待ちいただきたいのですが、今から 5 月の出張申請、もしくは上長への申請を上げておいていただければ誠に幸いです。

今年のイベントは、Java SE 8 の正式リリース後という事もあり、昨年以上の盛り上がりをご期待頂けるかと思いますので、どうぞお楽しみにしてください。

「５月末 Java のお祭りをするどぉーーーー！！！」

2014年2月14日 at 11:36 午後

JSF + WebSocket で実装した IMAP Web メール・クライアント

このエントリは Java EE Advent Calendar 2013 の 11 日目のエントリです。昨日はsk44_ さんの「JSF で日本語ファイル名のファイルダウンロード？」のご紹介でした。
明日は @nagaseyasuhito さんです。

エントリを始める前に、昨日 12/10 は Java EE 6/GlassFish v3 が正式リリースされて丁度 4 年目にあたる日でした。2009 年のブログを確認すると昨日の日本時間の夜 11 時頃からダウンロードできていたようです。
Happy Birth Day 4th Anniversary of Java EE 6 & GlassFish v3 !!

今回私は、JavaServer Faces (JSF) + WebSocket + Java Mail API を使用して、IMAP のメールクライアントを作成しました。本アプリケーションは、Ajax を使用していますが、Ajax 部分では一切 JavaScript を使用していません。JSF のデフォルトで用意されている Ajax ライブラリを使用し動的な画面更新を実現しています。また、今回実装したコードはコード量も比較的少なくある程度かんたんに動かす所までの実装で 3-4 日程度で実装できています。是非ご覧ください。

このアプリケーションのデモ動画はコチラ

今回作成した JSF のアプリケーションは並列処理 (Concurrency Utilities for Java EE)も利用しています。例えば長時間処理が必要な処理を実行しなければならない場合、バックエンドの処理をシーケンシャルに処理していては大量の時間を要してしまいます。これを並列処理 (Concurrency Utilities) を利用する事で描画までの時間を短縮する事もできます。

ここでご紹介する JSF(PrimeFaces) で実装したサンプル・アプリケーションを通じて Java EE 7 のテクノロジーを使ってどのような事ができるのか、どのようにして実装できるのかをご理解いただければ幸いです。
特に JSF (PrimeFaces)でツリーやテーブルを扱う部分、さらには Ajax を実現する部分はご注目ください。

※ このアプリケーションの実装では INBOX を監視し新規メッセージを受信した際、WebSocket で通知を行なう部分も実装しています。しかし WebSocket の実装部分は次回エントリで記載する予定です。

今回作成したアプリの全ソースコードは下記の URL にアップしました。
https://github.com/yoshioterada/JSF-WebSocket-Mailer

本アプリケーションで使用する、Java EE 7 の技術を紹介します。

　●　JavaServer Faces 2.2 (PrimeFaces 4.0)
　●　Java Mail 1.5
　●　Contexts and Dependency Injection 1.1
　●　Concurrency Utilities 1.0

まず、本アプリケーションの完成予想イメージを示します。

本アプリケーションは、ログイン画面の「IMAP Server 名」で指定した IMAP サーバに対して、「ログイン名」、「パスワード」を入力しIMAPサーバとの認証を行い、認証に成功した場合、下記の画面が表示されます。

上記の画面は、主に３つのコンポーネントから構成されています。
　●　フォルダ一覧表示部（画面左部）
　●　フォルダ内のサブジェクト一覧表示部（画面右上部）
　●　メッセージ表示部（画面右下部）

フォルダ一覧表示部（画面左部）

画面左側に IMAP サーバ上で作成されているフォルダの一覧を表示しています。

フォルダに子のフォルダが存在する場合、「▶」のマークが表示され、展開する事によって子のフォルダ一覧を取得できます。「▶」を押下すると Ajax でサーバに問い合わせを行い、子のフォルダを一覧を取得します。１度子フォルダを取得した後は「▶」を押下しても Ajax 通信を行なわず、開いたり閉じたりできるようになります。
特定のフォルダを選択すると、選択したフォルダ内に存在するメッセージを Ajax で行い、取得後「フォルダ内のサブジェクト一覧表示部」と「メッセージ表示部」を更新します。
また、「受信数：」のフィールドにデフォルトで「10」と表示されています。ここで扱う数字は、画面右部の「フォルダ内のサブジェクト一覧表示部」で扱うメッセージの件数を変更できます。デフォルトでは、テーブル内で表示されているメッセージは５件です。テーブル下部に存在するボタン「2」を押下する事で次の５件を表示できるようになります。
本エントリでは詳細は説明しませんが、「リアルタイム・チェック開始」、「リアルタイム・チェック中止」ボタンを押下する事で、それぞれ WebSocket 通信の開始、中止を行なうことが、INBOX (受信箱)にメッセージが届くと WebSocket でリアルタイムに通知を受け取ることができるようになります。

フォルダ内のサブジェクト一覧表示部（画面右上部）

画面右上部では、アプリケーション起動直後はデフォルトで INBOX(受信箱)に存在するメッセージの内、最新５件のメッセージの「サブジェクト」、「送信者アドレス」、「送信日付」、「サイズ」を取得し表示しています。

また、デフォルトでフォルダに存在する最新のメッセージが選択された状態になります。また、「サブジェクト」、「日付」、メッセージの「サイズ」に応じてソートができるようになっていますので、各項目でソートをしたい場合、各項目の上下の ↑↓ 部分を押下することでソートができます。

また、サーバ側ではデフォルトで受信数 10 件を管理していますが、1 画面中では、5 件のメッセージを表示できます。テーブル下部に存在する「2」のボタンを押下する事で次の５件を取得できます。このデフォルトの受信数を変更したい場合は、「フォルダ一覧表示部（画面左部）」の下に存在する「受信数」のフィールドの数字を変更し「適用」ボタンを押下する事で受信数を変更でき、参照可能な件数が代わります。例えば、「受信数」を 20 に変更した場合、テーブル下部に「1」、「2」、「3」、「4」のボタンが追加されます。また、テーブル内に存在する、メッセージ（サブジェクト等が表示されている）を選択すると対応するメッセージを Ajax で取得し「メッセージ表示部」に対象のメッセージを表示します。

メッセージ表示部

最後に、右画面の下部を下記に示します。デフォルトで INBOX(受信箱)に存在する最新のメッセージを表示していますが、「フォルダ内のサブジェクト一覧表示部（画面右上部）」で特定のメッセージをマウスでクリックし選択すると、対応するメッセージがここで表示されます。

本アプリケーションの実装方法の詳細

この JSF アプリケーションの主要な機能は View の実装として、JSF のFacelets を使用し「folders-show.xhtml」ファイルに画面デザインを実装しています。また、この画面のバックエンドの処理を行なったり、画面上に存在する各種コンポーネントとのバインディングを行なうために、JSF 管理対象 Bean を「MessageReceiveMgdBean.java」として実装しています。つまりこの２つのファイルを確認する事で、本アプリケーションの詳細な振る舞いを把握する事ができます。

メッセージを表示するために実装した Facelets の全ソースコードを下記に示します。ある程度、複雑な画面構成になっているにも関わらず、記載しているコード量が 88行程度と、とても少ない事をご確認いただけるのではないかと思います。

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
   xmlns:h="http://xmlns.jcp.org/jsf/html"
   xmlns:p="http://primefaces.org/ui"  
   xmlns:f="http://xmlns.jcp.org/jsf/core"
   xmlns:ui="http://xmlns.jcp.org/jsf/facelets">
 <h:head>
  <title>JSF-WebSocket WebMail</title>
  <f:event type="preRenderView" listener="#{messageReceiveMgdBean.onPageLoad}"/>
  <h:outputScript library="javascripts" name="ws-client-endpoint.js"/>
 </h:head>

 <h:body>
  <h:form id="form">
   <p:notificationBar position="top" effect="slide" widgetVar="bar" styleClass="top" style="background-color : #F8F8FF ; width: fit-content;">  
    <h:panelGrid columns="2" columnClasses="column" cellpadding="0">  
     <h:outputText value="新着メッセージ ：" style="color: red;font-size:12px;" /> <p:commandButton value="閉じる" onclick="PF('bar').hide()" type="button" style="font-size:10px;"/>  
     <h:outputText value="Subject ：" style="font-size:10px;" /><h:outputText id="wssubject" value="" style="font-size:10px;" />
     <h:outputText value="From ：" style="font-size:10px;" /><h:outputText id="wsfrom" value="" style="font-size:10px;" />
     <h:outputText value="メッセージ・サマリー ：" style="font-size:10px;" /><h:outputText id="wssummary" value="" style="font-size:10px;" />
    </h:panelGrid>
   </p:notificationBar>

   <p:layout fullPage="true"> 
    <p:layoutUnit position="west" size="200" header="フォルダ一覧" resizable="true" closable="true" collapsible="true" style="font-size:14px;">  
     <p:tree id="docTree" value="#{messageReceiveMgdBean.root}" var="doc" selectionMode="single" dynamic="true" selection="#{messageReceiveMgdBean.selectedNode}">  
      <p:ajax event="select" listener="#{messageReceiveMgdBean.onNodeSelect}" update=":form:mailheader :form:specifiedMsg"/>
      <p:treeNode>  
       <h:outputText value="#{doc.name}" style="font-size:14px;"/>  
      </p:treeNode>
     </p:tree>  
     <p:outputLabel value="受信数:" style="font-size:10px;"/> 
     <p:inputText autocomplete="false" id="numberOfMsg" value="#{messageReceiveMgdBean.numberOfMessages}" style="font-size:10px;">
     </p:inputText>
     <h:commandButton id="upBtn" value="適用" style="font-size:10px;">
      <f:ajax event="click" render="mailheader" execute="numberOfMsg" listener="#{messageReceiveMgdBean.updateMessageCount}"/>
     </h:commandButton>
     <input id="connect" type="button" value="リアルタイムチェック開始" style="font-size:10px;" onClick="connectServerEndpoint();"/>
     <input id="close" type="button" value="リアルタイムチェック中止" style="font-size:10px;" onClick="closeServerEndpoint();"/>
    </p:layoutUnit>  

    <p:layoutUnit position="center">  
     <p:dataTable id="mailheader" var="mheader" 
         paginator="true"
         paginatorPosition="bottom"
         value="#{messageReceiveMgdBean.mailHeaderModel}" 
         rows="5" rowKey=" #{mheader.messageCount}" 
         selection="#{messageReceiveMgdBean.selectedMailHeader}"
         selectionMode="single" style="width:800px;font-size:10px;" >  
      <p:ajax event="rowSelect" listener="#{messageReceiveMgdBean.onMessageSelect}" update=":form:specifiedMsg" global="false"/>  

      <p:column id="msubject" headerText="サブジェクト" style="font-size:10px;" sortBy="subject" width="50%">  
       #{mheader.subject}  
      </p:column>  

      <p:column id="maddress" headerText="アドレス" style="font-size:10px;" width="30%">  
       <ui:repeat value="#{mheader.fromAddress}" var="fromEmail">
          #{fromEmail.toUnicodeString()}
       </ui:repeat>
      </p:column>  

      <p:column id="mdate" headerText="日付" style="font-size:10px;" sortBy="sendDate" width="10%">  
       <h:outputLabel value="#{mheader.sendDate}">           
        <f:convertDateTime pattern="yyyy年MM月dd日 HH:mm:ss"/>
       </h:outputLabel>
      </p:column>  

      <p:column id="msize" headerText="サイズ" style="font-size:10px;" sortBy="size" width="10%">  
       #{mheader.size}  
      </p:column>  
     </p:dataTable>

     <p:scrollPanel style="width:800px;height:400px" mode="native">  
      <h:outputText id="specifiedMsg" value="#{messageReceiveMgdBean.specifiedMessage}" escape="false"/>
     </p:scrollPanel> 

    </p:layoutUnit> 
   </p:layout>  
  </h:form>

  <p:ajaxStatus  onstart="PF('statusDialog').show();" onsuccess="PF('statusDialog').hide();"/>  
  <p:dialog  modal="true" widgetVar="statusDialog" header="処理中"   
       draggable="false" closable="false">  
   <p:graphicImage value="/resources/imgs/ajaxloadingbar.gif" />  
  </p:dialog>
 </h:body>
</html>

次に上記 Facelets のバックエンド処理を実装する、MessageReceiveMgdBean クラスを下記に示します。

package jp.co.oracle.samples.mgdBean;

import java.io.Serializable;
import java.util.List;
import java.util.Properties;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.Future;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.annotation.Resource;
import javax.enterprise.concurrent.ManagedExecutorService;
import javax.inject.Named;
import javax.faces.view.ViewScoped;
import javax.inject.Inject;
import javax.mail.MessagingException;
import javax.mail.Session;
import javax.mail.Store;
import jp.co.oracle.samples.tasks.AllFolderHandlerTask;
import jp.co.oracle.samples.beans.FolderName;
import jp.co.oracle.samples.beans.MailHeader;
import jp.co.oracle.samples.beans.MailHeaderModel;
import jp.co.oracle.samples.tasks.SpecifiedMessageHandlerTask;
import jp.co.oracle.samples.tasks.SpecifiedNodeMailHeaderHandleTask;
import org.primefaces.event.NodeSelectEvent;
import org.primefaces.event.SelectEvent;
import org.primefaces.model.TreeNode;

/**
 *
 * @author Yoshio Terada
 */
@Named(value = "messageReceiveMgdBean")
@ViewScoped
public class MessageReceiveMgdBean implements Serializable {

    private Store store;
    private TreeNode root;
    private TreeNode selectedNode;
    private MailHeader selectedMailHeader;
    private MailHeaderModel mailHeaderModel;
    private String folderFullName;
    private String specifiedMessage;
    private int numberOfMessages = DEFAULT_NUMBER_OF_MESSAGE;
    private final static int DEFAULT_NUMBER_OF_MESSAGE = 10;

    private static final Logger logger = Logger.getLogger(MessageReceiveMgdBean.class.getPackage().getName());

    @Inject
    IndexLoginMgdBean login;

    @Resource
    ManagedExecutorService execService;

    /**
     *  コンストラクタ 
     */
    public MessageReceiveMgdBean() {

    }

    /** 
     * ページのロード時の処理を実装
     * 並列で各タスクを実行し結果表示速度を少し改善
    */
    public void onPageLoad() {
        String imapServer = login.getImapServer();
        String username = login.getUsername();
        String password = login.getPassword();
        initStore(imapServer, username, password);

        if (getRoot() == null) {
            //全フォルダリストの取得
            Future<TreeNode> folderHandlesubmit = execService.submit(new AllFolderHandlerTask(store));
            int num = getNumberOfMessages();
            if (num == 0) {
                num = DEFAULT_NUMBER_OF_MESSAGE;
            }
            // デフォルトで INBOX のメッセージの取得
            folderFullName = "INBOX";
            Future<MailHeaderModel> headerHandlerSubmit = execService.submit(new SpecifiedNodeMailHeaderHandleTask(store, folderFullName, num));
            Future<String> messageHandlerSubmit = null;
            try {
                // デフォルトで INBOX の最新のメッセージ取得
                messageHandlerSubmit = execService.submit(new SpecifiedMessageHandlerTask(store, folderFullName, store.getFolder(folderFullName).getMessageCount()));
            } catch (MessagingException ex) {
                logger.log(Level.SEVERE, null, ex);
            }

            try {
                //左ペインのツリーの一覧を設定
                root = folderHandlesubmit.get();
                //右ペインのテーブルの設定
                MailHeaderModel mailmodel = headerHandlerSubmit.get();
                setMailHeaderModel(mailmodel);
                List<MailHeader> headers = mailmodel.getAllHeader();
                //デフォルトで最新のメッセージを選択された状態に設定

                if (headers != null && !headers.isEmpty()) {
                    MailHeader latestMailHeader = headers.get(0);
                    selectedMailHeader = latestMailHeader;
                }

                if (messageHandlerSubmit != null) {
                    specifiedMessage = messageHandlerSubmit.get();
                }
            } catch (InterruptedException | ExecutionException ex) {
                logger.log(Level.SEVERE, null, ex);
            }
        }
    }

    // ツリーが選択された際に呼び出されるイベント
    public void onNodeSelect(NodeSelectEvent event) {
        folderFullName = ((FolderName) selectedNode.getData()).getFullName();
        int num = getNumberOfMessages();
        if (num == 0) {
            num = DEFAULT_NUMBER_OF_MESSAGE;
        }
        // 選択したフォルダのメールヘッダを更新
        Future<MailHeaderModel> headerHandlerSubmit = execService.submit(new SpecifiedNodeMailHeaderHandleTask(store, folderFullName, num));

        // 選択したフォルダの最新メッセージを取得
        try {
            MailHeaderModel mailmodel = headerHandlerSubmit.get();
            //メールヘッダの更新
            setMailHeaderModel(mailmodel);
            // 最新のメッセージ取得
            Future<String> messageHandlerSubmit = execService.submit(new SpecifiedMessageHandlerTask(store, folderFullName, store.getFolder(folderFullName).getMessageCount()));
            specifiedMessage = messageHandlerSubmit.get();

            List<MailHeader> headers = mailmodel.getAllHeader();
            //デフォルトで最新のメッセージを選択された状態に設定

            if (headers != null && !headers.isEmpty()) {
                MailHeader latestMailHeader = headers.get(0);
                selectedMailHeader = latestMailHeader;
            }
        } catch (MessagingException | InterruptedException | ExecutionException ex) {
            logger.log(Level.SEVERE, null, ex);
        }
    }

    // メッセージが選択された際に呼び出されるイベント
    public void onMessageSelect(SelectEvent event) {

        int msgCount = ((MailHeader) event.getObject()).getMessageCount();
        try {
            Future<String> messageHandlerSubmit = execService.submit(new SpecifiedMessageHandlerTask(store, folderFullName, msgCount));
            specifiedMessage = messageHandlerSubmit.get();
        } catch (InterruptedException | ExecutionException ex) {
            logger.log(Level.SEVERE, null, ex);
        }
    }

    // メッセージのカウンタが更新された際の処理
    // 10 よりしたの値が入力された場合、何もしない。
    public void updateMessageCount() {
        String folderName = folderFullName;
        if (folderName.isEmpty()) {
            folderName = "INBOX";
        }
        int num = getNumberOfMessages();
        if (num > 10) {
            Future<MailHeaderModel> headerHandlerSubmit = execService.submit(new SpecifiedNodeMailHeaderHandleTask(store, folderName, num));
            try {
                setMailHeaderModel(headerHandlerSubmit.get());
            } catch (InterruptedException | ExecutionException ex) {
                logger.log(Level.SEVERE, null, ex);
            }
        }
    }

    // Store の初期化（ページのロード時）
    private void initStore(String imapServer, String username, String password) {
        Properties props = System.getProperties();
        props.setProperty("mail.store.protocol", "imaps");
        javax.mail.Store initStore;
        try {
            Session session = Session.getDefaultInstance(props, null);
            initStore = session.getStore("imaps");
            initStore.connect(imapServer, username, password);
            this.store = initStore;
        } catch (MessagingException ex) {
            logger.log(Level.SEVERE, null, ex);
        }
    }

    /**
     * @return the selectedNode
     */
    public TreeNode getSelectedNode() {
        return selectedNode;
    }

    /**
     * @param selectedNode the selectedNode to set
     */
    public void setSelectedNode(TreeNode selectedNode) {
        this.selectedNode = selectedNode;
    }

    /**
     * @return the selectedMailHeader
     */
    public MailHeader getSelectedMailHeader() {
        return selectedMailHeader;
    }

    /**
     * @param selectedMailHeader the selectedMailHeader to set
     */
    public void setSelectedMailHeader(MailHeader selectedMailHeader) {
        this.selectedMailHeader = selectedMailHeader;
    }

    /**
     * @return the mailHeaderModel
     */
    public MailHeaderModel getMailHeaderModel() {
        return mailHeaderModel;
    }

    /**
     * @param mailHeaderModel the mailHeaderModel to set
     */
    public void setMailHeaderModel(MailHeaderModel mailHeaderModel) {
        this.mailHeaderModel = mailHeaderModel;
    }

    /**
     * @return the specifiedMessage
     */
    public String getSpecifiedMessage() {
        return specifiedMessage;
    }

    /**
     * @param specifiedMessage the specifiedMessage to set
     */
    public void setSpecifiedMessage(String specifiedMessage) {
        this.specifiedMessage = specifiedMessage;
    }

    /**
     * @return the numberOfMessages
     */
    public int getNumberOfMessages() {
        return numberOfMessages;
    }

    /**
     * @param numberOfMessages the numberOfMessages to set
     */
    public void setNumberOfMessages(int numberOfMessages) {
        this.numberOfMessages = numberOfMessages;
    }

    /**
     * @return the root
     */
    public TreeNode getRoot() {
        return root;
    }
}

本アプリケーションの実装において、特筆すべき点として JSF を利用する事で Ajax がとても簡単に実装できる点です。実際、今回のアプリケーションでは WebSocket の実装部以外で一切 JavaScript を記述しておらず、JSF の標準に含まれる <f:ajax> タグを拡張した PrimeFaces の <p:ajax> タグを使用して Ajax 通信を実現しています。

それでは、上記のコードを分割して、各コンポーネントの実装について詳しくご紹介していきます。

画面描画前に実行するコードの実装

この IMAP のメッセージを表示する画面は、画面にリクエストが発生した際に、各種画面のコンポーネントを初期化し、デフォルトで表示する全データを取得した後、描画を行ないます。これを実現するために、JSF では画面の描画前に処理を実行するために <f:event> タグを利用できます。

 <h:head>
  <title>JSF-WebSocket WebMail</title>
  <f:event type="preRenderView" 
        listener="#{messageReceiveMgdBean.onPageLoad}"/>
 </h:head>

ここで type=”preRenderView” 属性を追加しレンダリングされる前にイベントを発生する事を指定し、実行したい処理は listener で指定します。ここでは listener で「#{messageReceiveMgdBean.onPageLoad}”」を定義し、CDI (JSF の管理対象 Bean) として実装した MessageReceiveMgdBean クラスの onPageLoad() メソッドを呼び出しています。onPageLoad()メソッドでは最初のアクセスの際にデフォルトで描画する全コンポーネント（ツリーの構築部や、テーブルの構築部、メッセージの表示部）のデータを取得し組み立てます。

この際、「ツリーの構築部」、「テーブルの構築部」、「メッセージの表示部」を構成するための処理を、それぞれ並列処理タスクとして実装しました。 仮に並列処理で実装しない場合、画面を構築するためにかかる所要時間は、「フォルダ一覧表示部（画面左部）」＋「フォルダ内のサブジェクト一覧表示部」＋「メッセージ表示部」の合計時間になります。この時間を少しでも軽減するために、上記をそれぞれ別のタスクとして実装して並列に取得できるように実装します。

フォルダ一覧表示部（画面左部）の実装

下記に、画面左部の実装を説明します。

画面左部の「フォルダ一覧表示部」の部分のコードは下記です。下記は、大きく３つのコンポーネントから構成されています。

●　フォルダの一覧を表示するツリー
●　受信数を変更するテキスト・フィールド
●　WebSocket によるリアルタイム監視機能の開始/中止ボタン

    <p:layoutUnit position="west" size="200" header="フォルダ一覧" resizable="true" closable="true" collapsible="true" style="font-size:14px;">  

     <p:tree id="docTree" value="#{messageReceiveMgdBean.root}" var="doc" selectionMode="single" dynamic="true" selection="#{messageReceiveMgdBean.selectedNode}">  
      <p:ajax event="select" listener="#{messageReceiveMgdBean.onNodeSelect}" update=":form:mailheader :form:specifiedMsg"/>
      <p:treeNode>  
       <h:outputText value="#{doc.name}" style="font-size:14px;"/>  
      </p:treeNode>
     </p:tree>  

     <p:outputLabel value="受信数:" style="font-size:10px;"/> 
     <p:inputText autocomplete="false" id="numberOfMsg" value="#{messageReceiveMgdBean.numberOfMessages}" style="font-size:10px;">
     </p:inputText>
     <h:commandButton id="upBtn" value="適用" style="font-size:10px;">
      <f:ajax event="click" render="mailheader" execute="numberOfMsg" listener="#{messageReceiveMgdBean.updateMessageCount}"/>
     </h:commandButton>
     <input id="connect" type="button" value="リアルタイムチェック開始" style="font-size:10px;" onClick="connectServerEndpoint();"/>
     <input id="close" type="button" value="リアルタイムチェック中止" style="font-size:10px;" onClick="closeServerEndpoint();"/>
    </p:layoutUnit>

ここで、特に「フォルダ一覧表示部」のツリーは下記のコードで実現しています。

     … 前略
     <p:tree id="docTree" value="#{messageReceiveMgdBean.root}" var="doc" selectionMode="single" dynamic="true" selection="#{messageReceiveMgdBean.selectedNode}">  
      <p:ajax event="select" listener="#{messageReceiveMgdBean.onNodeSelect}" update=":form:mailheader :form:specifiedMsg"/>
      <p:treeNode>  
       <h:outputText value="#{doc.name}" style="font-size:14px;"/>  
      </p:treeNode>
     </p:tree>  
     … 後略

HTML の中でツリーを実現するために、PrimeFaces の <p:tree> タグを使用します。また、<p:tree> には下記の属性を指定しています。
　● id= コンポーネントの識別子
　● value=ツリーを描画するための TreeNode オブジェクト
　● var= TreeNode 内に含まれる各ノード・オブジェクト (FolderName) に対する変数
　● selectionMode=選択モード
　● dynamic=動的モード
　● selection=選択されたノードを表すオブジェクト

次に、上記のツリーを描画するために必要な実装コード (MessageReceiveMgdBean クラス) を下記に抜粋します。

@Named(value = "messageReceiveMgdBean")
@ViewScoped
public class MessageReceiveMgdBean implements Serializable {

 private TreeNode root;
 private TreeNode selectedNode;

 @Resource
 ManagedExecutorService execService;

 public void onPageLoad() {
  // ログイン画面で入力されたデータの取得
  String imapServer = login.getImapServer();
  String username = login.getUsername();
  String password = login.getPassword();
  initStore(imapServer, username, password);
  
  if (getRoot() == null) {
   //全フォルダリストの取得
   Future<TreeNode> folderHandlesubmit = execService.submit(new AllFolderHandlerTask(store));
   try {
    root = folderHandlesubmit.get();
   } catch (InterruptedException | ExecutionException ex) {
    logger.log(Level.SEVERE, null, ex);
   }
 }

 // Store の初期化（ページのロード時）
 private void initStore(String imapServer, String username, String password) {
  Properties props = System.getProperties();
  props.setProperty("mail.store.protocol", "imaps");
  javax.mail.Store initStore;
  try {
   Session session = Session.getDefaultInstance(props, null);
   initStore = session.getStore("imaps");
   initStore.connect(imapServer, username, password);
   this.store = initStore;
  } catch (MessagingException ex) {
   logger.log(Level.SEVERE, null, ex);
  }
 }
}

まず、initStore() メソッドを実行し IMAP サーバに接続します。接続に問題がない場合、18 行目〜26行目で並列タスクを実行し、実行結果よりツリーを取得しています。
ここで、ツリーを構成するための並列処理タスクは下記「AllFolderHandlerTask」クラスです。Callable インタフェースを実装したこのタスクは Runnable インタフェースを実装したタスクと違い、返り値 (TreeNode) を取得することができます。
タスクが ManagedExecutorService のインスタンス execService#submit() によって実行されると、AllFolderHandlerTask クラスの call() メソッドが呼び出されます。このメソッドは IMAP サーバに存在する全フォルダ一覧を再帰的に取得し、TreeNode を構築していきます。
より詳しく説明すると、TreeNode rootのインスタンスを生成し、IMAP サーバに存在するデフォルトのフォルダの一覧を取得します。そしてフォルダの一覧を root に付け加えていきます。次に取得したフォルダの中で子のフォルダを持つフォルダの場合、再帰的に子のフォルダ一覧を取得しツリーのノードに付け加えていきます。全てのフォルダ一覧を取得した後、全フォルダ一覧を含む TreeNode のオブジェクトを返します。　
　＃getAllIMAPFolders()の再帰の実装正直いけてないですが、
　＃TreeNode に追加する方法上こう実装しました。

AllFolderHandlerTask#call() メソッドの処理が完了後、onPageLoad() メソッドに処理が戻り、root = folderHandlesubmit.get() で返り値を取得できます。そして取得した結果を root に代入しています。

public class AllFolderHandlerTask implements Callable<TreeNode> {

 private final Store store;
 private static final Logger logger = Logger.getLogger(AllFolderHandlerTask.class.getPackage().getName());
 
 public AllFolderHandlerTask(Store store) {
  this.store = store;
 }

 @Override
 public TreeNode call() throws Exception {
  TreeNode root = new DefaultTreeNode("root", null);
  Folder[] folders;
  if (store == null) {
   return null;
  }
  try {
   folders = store.getDefaultFolder().list();
   getAllIMAPFolders(root, folders);
  } catch (MessagingException ex) {
   logger.log(Level.SEVERE, null, ex);
  }
  return root;
 }
 
 private TreeNode getAllIMAPFolders(TreeNode root, Folder[] folders) {
  TreeNode child = null;
  try {
   for (Folder folder : folders) {
    String folName = folder.getName();
    String folFullName = folder.getFullName();
    if (hasChildFolder(folder) == true) {
     child = new DefaultTreeNode(new FolderName(folName, folFullName), root);
     getAllIMAPFolders(child, folder.list());
    } else {
     child = new DefaultTreeNode(new FolderName(folName, folFullName), root);
    }
   }
  } catch (MessagingException ex) {
   logger.log(Level.SEVERE, null, ex);
  }
  return child;
 }

 //フォルダに子のフォルダがあるか否か
 private boolean hasChildFolder(Folder folder) throws MessagingException {
  boolean hasFolder = false;
  if (folder.list().length > 0) {
   hasFolder = true;
  }
  return hasFolder;
 }
}

onPageLoad() メソッドに処理が戻った後、root に代入する事で、View からフォルダ一覧がツリーとして参照できるようになります。具体的には、Facelets の <p:tree> タグに記述している value=”#{messageReceiveMgdBean.root}” で参照できるようになります。
また、<p:tree> タグに追加した属性 var=”doc” によって、ツリー中に含まれる各フォルダは、変数 doc として EL 式中で扱う事ができるようになります。具体的に doc は FolderName クラスのインスタンスを表します。例えば、#{doc.name} は FolderName インスタンスの getName() メソッドを呼び出し、フォルダ名を取得することができます。

<p:treeNode>タグ中に <h:outputText> タグを記載しています。このタグはテキストを表示するためのコンポーネントですが、属性 value=”#{doc.name}” で各フォルダの名前を出力しています。

     <p:tree id="docTree" value="#{messageReceiveMgdBean.root}" var="doc" selectionMode="single" dynamic="true" selection="#{messageReceiveMgdBean.selectedNode}">  
       <p:ajax event="select" listener="#
　　　{messageReceiveMgdBean.onNodeSelect}" 
　　　update=":form:mailheader :form:specifiedMsg"/>
      <p:treeNode>  
       <h:outputText value="#{doc.name}" style="font-size:14px;"/>  
      </p:treeNode>
     </p:tree>

次に、ツリー中のフォルダが選択された際の処理を説明します。ツリー中のフォルダを選択した際、選択されたツリーのノードは、<p:tree> タグで指定した属性、selection （<p:tree selection=”#{messageReceiveMgdBean.selectedNode}”>）によって MessageReceiveMgdBeanクラスの selectedNode に代入されます。

ここで、<p:tree> タグの直下に、<p:ajax>タグを記載していますが、この<p:ajax>タグは、ツリー内で特定のフォルダが選択されると、同タグ中の listener=”#{messageReceiveMgdBean.onNodeSelect}”
を呼び出します。これは、内部的に MessageReceiveMgdBean クラスの onNodeSelect(NodeSelectEvent event)を呼び出します。
onNodeSelect()のメソッドでは、選択されたフォルダに存在する「フォルダ内のサブジェクト一覧表示部」と「メッセージ表示部」を取得する処理が行なわれます。
呼び出した結果、<p:ajax> タグの update 属性の設定に従い、 <p:ajax update=”:form:mailheader :form:specifiedMsg”/>「:form:mailheader」と「:form:specifiedMsg」で指定するコンポーネント、つまり「フォルダ内のサブジェクト一覧表示部」と「メッセージ表示部」を更新します。

「フォルダ内のサブジェクト一覧表示部（画面右上部）の実装

つづいて、「フォルダ内のサブジェクト一覧表示部」の実装を説明します。

テーブルを実現している Facelets の実装コードは下記です。

  <p:dataTable id="mailheader" var="mheader" 
     paginator="true"
     paginatorPosition="bottom"
     value="#{messageReceiveMgdBean.mailHeaderModel}" 
     rows="5" rowKey=" #{mheader.messageCount}" 
     selection="#{messageReceiveMgdBean.selectedMailHeader}"
     selectionMode="single" style="width:800px;font-size:10px;" >  

   <p:ajax event="rowSelect" listener="#{messageReceiveMgdBean.onMessageSelect}" update=":form:specifiedMsg" global="false"/>  

   <p:column id="msubject" headerText="サブジェクト" style="font-size:10px;" sortBy="subject" width="50%">  
    #{mheader.subject}  
   </p:column>  

   <p:column id="maddress" headerText="アドレス" style="font-size:10px;" width="30%">  
    <ui:repeat value="#{mheader.fromAddress}" var="fromEmail">
     <h:outputLabel value="#{fromEmail.toUnicodeString()}"/>
    </ui:repeat>
   </p:column>  

   <p:column id="mdate" headerText="日付" style="font-size:10px;" sortBy="sendDate" width="10%">  
    <h:outputLabel value="#{mheader.sendDate}">     
  <f:convertDateTime pattern="yyyy年MM月dd日 HH:mm:ss"/>
    </h:outputLabel>
   </p:column>  

   <p:column id="msize" headerText="サイズ" style="font-size:10px;" sortBy="size" width="10%">  
    #{mheader.size}  
   </p:column>  
  </p:dataTable>

ちょっと補足：
web.xml の最後に下記の <context-param>を追加してください。
上記 JSF の Facelets でメッセージ送信日付を、f:convertDateTime で変換し描画しています。この変換の際デフォルトのタイムゾーンをシステムのタイムゾーンに変更します。

<web-app version="3.1" xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd">
  … 前略
    <context-param>
        <param-name>javax.faces.DATETIMECONVERTER_DEFAULT_TIMEZONE_IS_SYSTEM_TIMEZONE</param-name>
        <param-value>true</param-value>
    </context-param>
</web-app>

画面が描画前に呼び出される処理は onPageLoad() メソッドに実装されている事は上記ですでに紹介しました。onPageLoad() メソッドの中、つまり最初のアクセスの際に、テーブルは「INBOX(受信箱)」に存在するメッセージを並列タスクとして取得し描画します。

HTML のテーブルを扱うために PrimeFaces の <p:dataTable>を使用します。
<p:dataTable id=”mailheader” var=”mheader”
　　　paginator=”true”
　　　paginatorPosition=”bottom”
　　　value=”#{messageReceiveMgdBean.mailHeaderModel}”
　　　rows=”5″ rowKey=” #{mheader.messageCount}”
　　　selection=”#{messageReceiveMgdBean.selectedMailHeader}”
　　　selectionMode=”single” style=”width:800px;font-size:10px;” >

<p:dataTable> タグでは下記の属性を指定しています。

　● paginator : テーブル内にボタンを表示しページ移動を可能にする属性
　● paginatorPosition : ページ移動用のボタンの配置場所を指定
　● value: テーブル内で扱うデータ・モデル
　● rows: テーブルで描画する行数
　● rowKey: 行を選択した際、他の行と区別するためのキー
　● selection: 選択された行のデータ
　● selectionMode: 選択モード

この中で、特に重要なのが value で指定するデータ・モデルです。今回、このテーブルを扱うためのモデルとして、MailHeaderModel クラスを実装し、value にはこのクラスのインスタンスを代入します。MailHeaderModel クラスは MailHeader オブジェクト(行を表すオブジェクト)を List で管理しています。これらのクラスのインスタンスは並列処理タスク SpecifiedNodeMailHeaderHandleTask の中で生成されます。下記に MailHeaderModel、MailHeader クラスの実装をそれぞれ示します。

まず、テーブル内に表示するデータを保持する MailHeader クラスを作成します。今回テーブルには「サブジェクト」、「From:」、「送信日」、「メッセージのサイズ」の４項目を表示させますので、４つのフィールド（subject, fromAddress, sendDate, size）を定義しています。
またmessageCount はフォルダ内に存在するメッセージの内、特定のメッセージを識別するためのキーをメッセージのカウントIDとして指定します。実際には、SpecifiedNodeMailHeaderHandleTask の中でMailHeaderのインスタンスを生成する際、Java Mail API の Message#getMessageNumber() をここに代入します。

@ViewScoped
public class MailHeader {

 private String subject;
 private Address[] fromAddress;
 private Date sendDate;
 private int size;
 private Integer messageCount;

 public MailHeader(String subject, Address[] fromAddress, Date sendDate, int size, Integer messageCount) {
  this.subject = subject;
  this.fromAddress = fromAddress;
  this.sendDate = sendDate;
  this.size = size ;
  this.messageCount = messageCount;
 } 

 別途、Setter, Getter メソッドを実装してください。
}

次に、上記 MailHeader クラスを管理するクラスを MailHeaderModel に実装します。このクラスはインスタンスが生成された際に、コンストラクタ内で MailHeader の List を最新日付順（最新のメッセージのカウント ID 順）でソートします。そして各行を識別するためのキーとして、メッセージのカウントID を使用します。

@ViewScoped
public class MailHeaderModel extends ListDataModel<MailHeader> implements SelectableDataModel<MailHeader> {

    public MailHeaderModel() {
    }

    public MailHeaderModel(List<MailHeader> header) {
        super(header);
        Collections.sort(header, new Comparator<MailHeader>() {
            @Override
            public int compare(MailHeader m1, MailHeader m2) {
                return m2.getMessageCount() - m1.getMessageCount();
            }
        });
    }

    @Override
    public Object getRowKey(MailHeader header) {
        return header.getMessageCount();
    }

    @Override
    public MailHeader getRowData(String rowKey) {
        List<MailHeader> headers = (List<MailHeader>) getWrappedData();

        for (MailHeader header : headers) {
            if (header.getMessageCount().toString().equals(rowKey)) {
                return header;
            }
        }
        return null;
    }
}

ここで、画面ロード時に呼び出される MessageReceiveMgdBean#onPageLoad() メソッドの中から、テーブルを初期化する部分のコードを下記に抜粋し示します。画面ロード時にはデフォルトで INBOX のメッセージを取得します。INBOX のフォルダを SpecifiedNodeMailHeaderHandleTask に指定し並列タスクとして実行します。

 public void onPageLoad() {
   // デフォルトで INBOX のメッセージの取得
   folderFullName = "INBOX";
   Future<MailHeaderModel> headerHandlerSubmit = 
         execService.submit(
              new SpecifiedNodeMailHeaderHandleTask(store, 
                                                                                   folderFullName, 
                                                                                   num));
   try {
        MailHeaderModel mailmodel = headerHandlerSubmit.get();
        setMailHeaderModel(mailmodel);
        // テーブル中の最新のメッセージ(MailHeader)をデフォルトで
        // 選択 (マウスがクリックされた) 状態にする。
        List<MailHeader> headers = mailmodel.getAllHeader();
        if (headers != null && !headers.isEmpty()) {
            MailHeader latestMailHeader = headers.get(0);
            selectedMailHeader = latestMailHeader;
        }
   } catch (InterruptedException | ExecutionException ex) {
    logger.log(Level.SEVERE, null, ex);
   }
 }

execService#submit によりSpecifiedNodeMailHeaderHandleTask(store, folderFullName, num) の並列タスクを実行します。このタスクは、指定された IMAP のフォルダの中から、num で指定した数だけ最新メッセージを取得し、取得したメッセージ(MailHeader) を含む MailHeaderModel のインスタンスを返します。
並列処理タスクの処理が完了すると、onPageLoad() に処理が戻り、headerHandlerSubmit.get() でMailHeaderModel を取得できますので、取得した MailHeaderModel を setMailHeaderModel() で置き換えて更新します。更新した後、最新のメッセージを選択状態にするため、最新のメッセージを取得し、selectedMailHeader に代入しています。

public class SpecifiedNodeMailHeaderHandleTask implements Callable<MailHeaderModel> {

    private final Store store;
    private final String folderFullName;
    private final int numberOfMessage;

    private static final Logger logger = Logger.getLogger(SpecifiedNodeMailHeaderHandleTask.class.getPackage().getName());
    
    public SpecifiedNodeMailHeaderHandleTask(Store store,String folderFullName,int numberOfMessage){
        this.store = store;
        this.folderFullName = folderFullName;
        this.numberOfMessage = numberOfMessage;
    }    
    
    @Override
    public MailHeaderModel call() throws Exception {
        MailHeaderModel model = null;
        if (store != null) {
            try {
                Folder folder = store.getFolder(folderFullName);
                if (!folder.isOpen()) {
                    folder.open(javax.mail.Folder.READ_WRITE);
                }

                int endMsgs = folder.getMessageCount();
                int startMsgs = endMsgs - (numberOfMessage - 1);

                Message[] msgs = folder.getMessages(startMsgs, endMsgs);
                List<MailHeader> data = new ArrayList<>();
                for (Message msg : msgs) {
                    MailHeader msgModel = new MailHeader(msg.getSubject(), msg.getFrom(), msg.getSentDate(), msg.getSize(), msg.getMessageNumber());
                    data.add(msgModel);
                }
                model = new MailHeaderModel(data);
            } catch (MessagingException ex) {
                logger.log(Level.SEVERE, null, ex);
            }
        }
        return model;
    }
}

次に、テーブル内で行が選択された場合の実装、振る舞いを紹介します。テーブル内で行を選択すると、選択した行を表す MailHeader オブジェクトが、<p:dataTable> タグの selection 属性で指定した、
<p:dataTable selection=”#{messageReceiveMgdBean.selectedMailHeader}” >
に代入されます。また、行を選択した際のキーは MailHeaderModel クラス内の getRowKey() メソッドの返り値、つまり MailHeader の getMessageCount() をキーとなります。

また、<p:dataTable> タグの直後に<p:ajax>タグを記述しています。これにより、実際に行が選択されると <p:ajax> の属性 listener で示すメソッド onMessageSelect() メソッドが呼び出されます。

 // メッセージが選択された際に呼び出されるイベント
 public void onMessageSelect(SelectEvent event) {
  int msgCount = ((MailHeader) event.getObject()).getMessageCount();
  try {
   Future<String> messageHandlerSubmit = execService.submit(new SpecifiedMessageHandlerTask(store, folderFullName, msgCount));
   specifiedMessage = messageHandlerSubmit.get();
  } catch (InterruptedException | ExecutionException ex) {
   logger.log(Level.SEVERE, null, ex);
  }
 }

onMessageSelect() メソッドは選択された該当のメッセージを、SpecifiedMessageHandlerTask で実装された並列タスクで取得し、取得したメッセージの文字列を specifiedMessage に代入します。
この Ajax リクエストは処理が完了後、メッセージを<p:ajax> タグで設定されている update 属性の内容に従い、”:form:specifiedMsg” つまり「メッセージの表示部」に更新します。

メッセージ表示部（画面右下部）の実装
最後にメッセージ表示部の実装部分について説明します。

specifiedMessage は View(Facelets) の中で下記のコードで参照・表示されます。

  <p:scrollPanel style="width:800px;height:400px" mode="native">  
   <h:outputText id="specifiedMsg" value="#{messageReceiveMgdBean.specifiedMessage}" escape="false"/>
  </p:scrollPanel>

<p:scrollPalnel> タグは、スクロールが可能なパネルで長文のメッセージを表示する際に、スクロールしながら参照が可能なパネルです。このスクロール可能なパネルの中で、IMAP の特定メッセージを <h:outputText> タグ内で表示します。ここで、<h:outputText> タグ内で excape=”false” と指定していますが、これは HTML メールを参照する場合、JSF では
デフォルトで < や > 等をエスケープ＆lt；、＆gt；しますので、HTMLメールをそのまま表示させるために、この部分だけエスケープしないように設定しています。

実際に、指定されたメッセージのカウントID を持つメッセージを取得するための並列タスク SpecifiedMessageHandlerTask クラスを下記に示します。

public class SpecifiedMessageHandlerTask implements Callable<String> {

 private final Store store;
 private final String folderFullName;
 private final int msgCount;
 private static final Logger logger = Logger.getLogger(SpecifiedMessageHandlerTask.class.getPackage().getName());
 
 public SpecifiedMessageHandlerTask(Store store, String folderFullName, int msgCount) {
  this.store = store;
  this.folderFullName = folderFullName;
  this.msgCount = msgCount;
 }

 @Override
 public String call() throws Exception {
  String returnMsg ="";
  if (store != null) {
   Folder folder;
   try {
    folder = store.getFolder(folderFullName);
    if (!folder.isOpen()) {
     folder.open(javax.mail.Folder.READ_WRITE);
    }
    Message msg = folder.getMessage(msgCount);
    MessageDumpUtil dumpUtil = new MessageDumpUtil();
    returnMsg = dumpUtil.getText(msg);
   } catch (MessagingException | IOException e) {
    logger.log(Level.SEVERE, null, e);
   }
  }
  return returnMsg;
 }
}

Message を取得するためには、Java Mail の API を使用して folder.getMessage(msgCount) で取得します。ただし Message は単純なプレイン・テキストだけではなく、マルチパート、html 形式様々な形の
メッセージが存在します。そこで、メッセージのタイプに応じて表示用の文字列を取得する必要があります。

今回の実装では、Base 64 への未対応や、マルチパートファイルのダウンロードなどは実装しておらず、テキストと HTML 表示のみ対応しています。HTML ならばその文字列をそのまま返し、プレイン・テキストの場合、&lt:PRE>を付加してメッセージの形式をそのままの形で表示して返しています。Message の解析を行ない表示用の文字列を取得するためのユーティリティ・クラスを MessageDumpUtil として実装しました。MessageDumpUtil クラスを下記に示します。

public class MessageDumpUtil {

    private boolean textIsHtml = false;

    public String getText(Part p) throws
            MessagingException, IOException {
        if (p.isMimeType("text/*")) {
            textIsHtml = p.isMimeType("text/html");
            if (true == textIsHtml) {
                return (String) p.getContent();
            } else {
                return getPreString((String) p.getContent());
            }
        }

        if (p.isMimeType("multipart/alternative")) {
            // prefer html text over plain text
            Multipart mp = (Multipart) p.getContent();
            String text = null;
            for (int i = 0; i < mp.getCount(); i++) {
                Part bp = mp.getBodyPart(i);
                if (bp.getContent() instanceof BASE64DecoderStream) {
                    return "現在 Base 64 のコンテンツには現在未対応です。";
                } else if (bp.isMimeType("text/plain")) {
                    if (text == null) {
                        text = getPreString(getText(bp));
                    }
                } else if (bp.isMimeType("text/html")) {
                    String s = getText(bp);
                    if (s != null) {
                        return s;
                    }
                } else {
                    return getPreString(getText(bp));
                }
            }
            return text;
        } else if (p.isMimeType("multipart/*")) {
            Multipart mp = (Multipart) p.getContent();
            for (int i = 0; i < mp.getCount(); i++) {
                String s = getText(mp.getBodyPart(i));
                if (s != null) {
                    return s;
                }
            }
        }

        return null;
    }

    private String getPreString(String data) {
        StringBuilder sb = new StringBuilder();
        sb.append("<PRE style=\"font-size:12px;\">");
        sb.append(data);
        sb.append("</PRE>");
        String s = sb.toString();
        return s;
    }
}

このユーティリティ・クラスでは getText(Part p) メソッドが実際の解析を行なっています。解析を行なった後、HTML は HTML として、テキストはテキストとして文字列を取りだし、最後に表示用の文字列を String で返しています。ユーティリティ・クラスから文字列が返ってくると、その値をそのまま並列タスクの戻り値として返します。
並列タスクの処理が完了すると <h:outputText value=”#{messageReceiveMgdBean.specifiedMessage}” > でその文字列を描画するために、戻り値を specifiedMessage に代入します。

以上により、大まかな実装の概要説明は終了です。

Ajax 通信の際のダイアログ表示方法
最後に、長時間の Ajax 通信時にステータス・ウィンドウを表示させる方法を紹介します。

Ajax リクエストを行なう際に、上記のステータスを表示するダイアログを表示させています。これは Ajax で長時間処理を要するような処理を行なう際にとても有用です。特に今回は IMAP サーバに直接接続を行いフォルダ一覧を取得したりメッセージを取得しているため、通常の DB アクセスよりもさらに時間を要すような処理を Ajax として実装しました。仮に上記のようなダイアログを使用しない場合、本当に Ajax のリクエストが実行されているのか否かわからなくなります。そこで、このような長時間処理用に、今回 PrimeFaces の下記のタグを使用して実装しました。

        <p:ajaxStatus  onstart="PF('statusDialog').show();" onsuccess="PF('statusDialog').hide();"/>  
        <p:dialog  modal="true" widgetVar="statusDialog" header="処理中"   
                   draggable="false" closable="false">  
            <p:graphicImage value="/resources/imgs/ajaxloadingbar.gif" />  
        </p:dialog>

基本的には、上記のコードを記述する事で全ての Ajax 通信時にステータス・ウィンドウが表示されるようになります。しかし、全ての処理で上記ダイアログを表示させたくない場合もあります。そのような場合、<p:ajax> タグの属性 global を false に設定する事で、その Ajax リクエストではダイアログを非表示にする事もできます。実際、私の場合は、テーブル中で特定のメッセージを選択した際、その対象メッセージをスクロール・パネルに表示させますが、その Ajax リクエストではダイアログを非表示にしています。

     <p:dataTable id="mailheader" var="mheader" 
         paginator="true"
         paginatorPosition="bottom"
         value="#{messageReceiveMgdBean.mailHeaderModel}" 
         rows="5" rowKey=" #{mheader.messageCount}" 
         selection="#{messageReceiveMgdBean.selectedMailHeader}"
         selectionMode="single" style="width:800px;font-size:10px;" >  
      <p:ajax event="rowSelect" listener="#{messageReceiveMgdBean.onMessageSelect}" update=":form:specifiedMsg" global="false"/>

※ご注意：全てのコンポーネントで global=false が利用できるわけではないようです。

このようにして、PrimeFaces のようなリッチな JSF コンポーネントを使用する事で、標準の JSF でもある程度簡単に、シングル・ページ・アプリケーションを構築する事ができます。如何でしょうか？是非この開発生産性の高い技術をお試しください。

最後に、
本アプリケーションは短時間で実装し、あくまでも JSF, WebSocket, JavaMail のサンプル・アプリケーションとして作成しました。そのため、実務レベルで使用するためには細かい部分で実装が足りていません。

例えばログイン時に毎回 IMAP サーバに接続し全情報を取得しますので、アプリケーションの動作としてとても遅いと感じるかもしれません。それはJSF ではなく、毎回 IMAP サーバに接続しに行っているため遅くなっています。また、一般的な IMAP のメールクライアントが実装しているような、ローカル・キャッシュを実装していません。毎回直接 IMAP サーバに参照に行っています。起動時に全画面の描画を高速にするためには、ローカル・キャッシュのデータを参照するなどが必要です。また各処理を並列処理で行なっていますが、タイミングに応じて異なるメッセージが選択される可能性もあります（注意点は GitHub のソースに記述しています）。また、セッション・タイムアウトに対する実装も今回は実装していません。ログイン認証も簡易実装しています。Java EE におけるログイン認証は「たかがレルムされどレルム GlassFish で始める詳細 JDBC レルム」のエントリをご参照ください。

ここで、ご紹介した内容の内、ご参考になる部分があれば幸いです。

2013年12月11日 at 2:55 午前 2件のコメント

はじめての Project Avatar

https://avatar.java.net/

JavaOne 2013 San Francisco で Project Avatar のオープン・ソース化が発表されました。そこで、本エントリでは Avatar にご興味を持って頂いた方が、どこから Avatar に触ればよいのかを分かりやすくするために、Avatar プログラムの実行方法、Avatar プログラムの作成方法をご紹介します。

※ 昨年、Project Avatar について、下記のプレゼンでアーキテクチャ等をご紹介していますが基本的なコンセプトは変わっていません。しかしこの１年で実装方法が大きく修正されています。昨年の時点では、View の実装部分で Avatar 専用のタグライブラリを使用しなければなりませんでしたが、今回 OSS 化された Avatar の実装を確認すると、標準の HTML 5 + JavaScript + EL 構文で実装できるようになっています。昨年の JavaOne 2012 の BoF で開発者から頂いたフィードバックを受けて、今回の実装方法に修正された事と想定します。

それでは、実際に OSS 化された Avatar の実行方法、プログラムの作成方法を下記にご紹介します。

1. まずはじめに、JDK 8 をダウンロードしてインストールしてください。
　（※Avatar の動作のためには、JDK 8 の build 103 以降が必要です。）
　　 Open JDK 8 Early Access のダウンロード

2. 次に Avatar の実行環境をバンドルした GlassFish v4 を入手してインストールしてください。
　　入手はこちらから

3. 次に AVATAR_HOME (GlassFish のインストールした場所) の環境変数と GlassFish の bin へのパスを設定してください。

　　csh 系の場合：
　　setenv AVATAR_HOME /Applications/NetBeans/avatar-gf-1.0-ea
　　set path=($path;/Applications/NetBeans/avatar-gf-1.0-ea/glassfish4/bin)

4. Avatar プロジェクトの作成
　　3. でパスを通しておくと、avatar コマンドが実行できるようになってます。
　　avatar コマンドで Avatar プロジェクトを作成してください。
　　Avatar プロジェクトを作成するとデフォルトで下記のディレクトリが作成
　　されます。
　　# avatar new [project-name]
　　# ls -F project-name/　

　　WEB-INF ディレクトリ配下には readme.txt が作成されています。
　　view ディレクトリ配下に src ディレクトリが存在し、hello.html ファイルが
　　作成されます。

hello.html ファイルの内容

<!DOCTYPE html>
<html>
    <head>
        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
        <title>Hello</title>
    </head>
    <body>
        Hello
    </body>
</html>

5. GlassFish v4 の起動
　　GlassFish を起動します。
　　 # asadmin start-domain

6. Avatar プロジェクトのデプロイ
　　GlassFish に Avatar プロジェクトをデプロイします。
　　 # asadmin deploy project-name

7. デプロイした Avatar プロジェクトの動作確認
　　ブラウザで http://localhost:8080/project-name へアクセスしてください。
　　Hello のみがブラウザ上に表示されます。

8. Avatar アプリケーションの作成の準備
　　まず、Avatar の基本概念を簡単にご紹介すると、Avatar は View
　　(クライアント側の実装) と Service(サーバ側の実装)をそれぞれ実装します。
　　また、Avatar はクライアントとサーバの通信に、RESTful, Server-Sent
　　Event, WebSocket を利用可能です。

　　今回は、まず最も簡単なアプリケーションを作成するために、
　　RESTful 対応のアプリケーションを作成します。
　　4. で Avatar プロジェクトを下記のコマンドを実行し作成しましたが、
　　 # avatar new project-name

　　上記コマンドを実行した際には、下記のように view のディレクトリしか
　　作成されていません。
　　 # ls -F project-name/

　　サーバ側の実装も行うためには、service ディレクトリとそのディレクトリ
　　配下にsrc ディレクトリを作成する必要があります。下記のコマンドを
　　実行して service ディレクトリを作成してください。

　　# mkdir service
　　# mkdir service/src
　　# ls -F

　　# ls -F service
　　　src/

　　今回作成する RESTful 対応のサンプル・アプリケーションは、ブラウザ
　　からボタンを押下すると GET リクエストを送信し、サーバ側の時間を
　　取得してクライアントに表示させるアプリケーションを作成します。

9. Avatar RESTful 対応のサーバ側 (Service) の実装
　　まず、サーバ側の実装を行うために、service ディレクトリの下の
　　src ディレクトリに移動し、main.js ファイルを作成します。
　　ここでは、下記のコードを実装してください。

　　# cd service/src
　　# vi main.js

var avatar = require("org/glassfish/avatar");

var getTime = function(){
    var current = new Date();
    return{
        h: current.getHours(),
        m: current.getMinutes(),
        s: current.getSeconds()
    };
};

avatar.registerRestService({ url:"data/message"},
    function(){
        this.$onGet = function(request, response){
            response.$send(getTime());
        };
    }    
);

　　備考：
　　Service 側の API は下記 URL に記載されておりますが、REST, Server-Sent
　　Event(SSE), WebScoket それぞれの実装ができるようになっています。
　　https://avatar.java.net/jsdoc/service/avatar.html

　　例：
　　RESTful : registerRestService(metadata, restService)
　　SSE : registerPushService(metadata, pushService)
　　WebSocket : registerSocketService(metadata, socketService)

10. Avatar RESTful 対応のクライアント側(View)の実装
　　View は下記の内容を実装してください。

<!DOCTYPE html>
<html>
    <head>
        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
        <title>Hello</title>
    </head>
    <body>
        <script data-model="rest">
            var Message = function(){
                this.msg = this.h = this.m = this.s ='';
            };
        </script>
        <script data-type="Message" data-instance="message" data-url="data/message"></script>
        <output class="time">#{message.h}:#{message.m}:#{message.s}</output>
        

        <button onclick="#{message.$get()}">Update</button>
    </body>
</html>

　　今回、REST のモデルを使用しますので、<script data-model=”rest”>を
　　定義しています。
　　REST モデルで利用可能な API は下記の通りです。
　　https://avatar.java.net/jsdoc/view/module-RestModelBase.html

　　今回はボタンを押下した際に GET リクエストでサーバにリクエストを
　　送信し、サーバ側の時間を表示しますが、Avatar ではモデル・データの
　　バインディングに Java EE に含まれる Expression Language(EL) 構文
　　を使用します。
　　具体的には、#{message.h} , #{message.m} , #{message.s} と記載している
　　部分が EL 式になります。

11. Avatar プロジェクトのコンパイル
　　View と Service をそれぞれ実装完了した後、プロジェクトをコンパイル
　　してください。
　　# avatar compile project-name

　　コンパイル後、このアプリケーションを動作させるために必要なファイルが
　　自動的に追加されます。

12. Avatar プロジェクトを GlassFish にデプロイ
　　コンパイルが完了すると、アプリケーション・サーバにデプロイします。
　　# asadmin deploy project-name

13. RESTful アプリケーションの動作確認
　　ブラウザより http://localhost:8080/project-name にアクセスしてください。
　　ボタンを押下するとサーバ側の時刻が表示され、ボタンを押す事に
　　サーバの時刻が更新されるようになります。

14. RESTful アプリケーションから SSE アプリケーションへ移行
　　RESTful の場合、ボタンを押下しなければサーバ側のデータが取得
　　できません。
　　そこで、RESTful から SSE にアプリケーションを変更し、サーバ側から
　　自動的に時刻を通知するように変更します。
　　それぞれ、View と Service の実装を下記のように修正してください。

　　View 側の修正

<!DOCTYPE html>
<html>
    <head>
        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
        <title>Hello</title>
    </head>
    <body>
        <script data-model="push">
            var Time = function(){
                this.msg = this.h = this.m = this.s ='';
            };
        </script>
        <script data-type="Time" data-instance="time" data-url="data/time"></script>
        <output class="time">#{time.msg}#{time.h}:#{time.m}:#{time.s}</output>

</body>
</html>

　　Service 側の修正

var avatar = require("org/glassfish/avatar");

var message = 'The Server Time is ';

var getTime = function(){
    var current = new Date();
    return{
        msg: message,
        h: current.getHours(),
        m: current.getMinutes(),
        s: current.getSeconds()
    };
};

avatar.registerPushService({ url:"data/time"},
    function(){
        this.$onOpen = this.$onTimeout = function(context){
            context.$setTimeout(1000);
            return context.$sendMessage(getTime());
        };
    }    
);

15. SSE アプリケーションのコンパイル
　　ソースコードを修正したら、再度コンパイルします。
　　 # avatar compile project-name

16. SSE アプリケーションの動作確認
　　ブラウザより、http://localhost:8080/project-name にアクセスしてください。
　　ブラウザでアクセスすると自動的にサーバの時刻が表示されるように
　　なります。

最後に
　　今回は、Avatar で簡単な RESTful, SSE のアプリケーションを作成
　　しましたが、WebSocket なども扱う事ができます。
　　色々と試してみたい場合、バンドルされている、exapmples をご参考頂く
　　ことがとても有用です。
　　example をデプロイして色々なサンプルコードをご覧いただき試して
　　頂ければ幸いです。また試していただいた後、Avatar プロジェクトでは
　　フィードバックを求めています。是非、色々なフィードバックを頂ければ
　　誠に幸いです。

Avatar サンプル・アプリケーションのデプロイ方法
　　インストールした GlassFish v4 のインストール・ディレクトリ
　　直下にサンプル・アプリケーションが用意されています。
　　サンプル・アプリケーションをデプロイして確認してください。
　　# asadmin deploy avatar-gf-1.0-ea/examples/examples.ear

サンプル・アプリケーションの動作確認
　　ブラウザより http://localhost:8080/examples にアクセスしてください。
　　豊富なサンプルが用意されていますので、こちらをご参照頂き
　　Avatar でどのような事ができるかをご覧ください。

2013年10月10日 at 9:20 午後

You are the “Make the future Java”

本日、GlassFish ユーザ・グループ・ジャパンによる Java EE 7 リリース記念のナイトセミナーが開催されました。本日ご登壇いただいた、上妻さん、久保田さん、槇さん、蓮沼さんには大変感謝すると共に、ご参加頂いた皆様にも大変感謝いたしております。（下記の写真の通り会場は満員で、ご登録者数は 140 名、実際にご参加頂いた方も 88 名でした。）
Java EE 7 そして GlassFish の最新情報をコミュニティ・ドリブンでお届け頂ける、このような機会はとても貴重だと感じております。GlassFish ユーザ・グループ・ジャパン副会長のの蓮沼さん、そして参加者の皆様ありがとうございます。

GlassFish は元々、日本では元 Sun の３人のメンバーが日本での啓蒙活動を開始しましたが、今や GlassFish はこの３人の手を離れ、Java EE の参照実装として、コミュニティ・ドリブンで情報提供がなされ、さらには多くのユーザが GlassFish の良さに気付きご賛同頂きはじめた事を、日本で活動を始めた３人の内の１人として大変嬉しく思っております。

Java EE 7 は、WebSocket, JOSN, jBatch, Concurrency Utilities for EE といった新機能が含まれ、特に WebSocket, JSON あたりの技術は特に開発者が注目する技術だと思います。また本日、上妻さんに発表して頂いた、jBatch に関しても非常に詳しい内容をご紹介頂いたため、今後多くの開発者にとってとても有用な情報だったのではないかと思います。

その一方でツイート上を除くと「Java EE 7 が流行ればいいな」といった、（言葉が若干悪いかもしれませんがお許しください）他人まかせなご意見も見受けられました。これに対して私が皆様にご期待する内容として、本ブログのタイトルにもございますように、「将来の Java を創っていくのは皆様です！！」

もし、Java EE 7 もしくは GlassFish に関して、ご興味を頂いた方、もしくは試して見ようと思われ方がいらっしゃったら、どんな些細な事でも結構です。実際に試して頂いた内容を、体裁問わず、ブログや Wiki、その他何でも結構です、試された内容を是非公に公開してください。それらの情報が他の開発者にとっても有用な情報になり、それが流行（トレンド）になっていく物と心より信じております。

例えば、今このエントリで Java EE 7 のどの技術にご興味があるかアンケートを実施しています。結果をみると、圧倒的に Java EE 7 のご興味のある技術は WebSocket になっていますが、全ての開発者が WebSocket に興味を持っているわけではなく、JAX-RS 2.0, JSF 2.2, JSON, Concurrency , CDI 等の技術にご興味を持って頂いている方も多く見受けられます。実際、jBatch に関しては現在７番目の人気となっておりますが、本日、上妻さんにご登壇頂いた内容は多くの開発者にとってとても有用だったと思います。

ここで申し上げたい事は、皆様、それぞれ異なる興味分野を持っていらっしゃると思います。１人が全てを一度に試す（把握する）事は困難ですが、自分の興味分野、試した内容を公開する事でかならず、他の Java 開発者の為にもなります。

もちろん、私も今後も継続して情報発信してまいりますが、１人でできる事はとても限られています。スケールも致しません。それを支えていただけるのは皆様です。仮に、試してダメだと思った所は、正直この機能のここがダメだとフィードバックをください。それが将来の Java を創っていく事だと思います。
「将来の Java を創っていくのは皆様」なのです。

是非、お試しいただいた内容を、どのような形でも結構です。是非情報をご共有頂ければ大変嬉しく思います。
最後にくどいようですが、繰り返します「将来の Java を創っていくのは皆様です！！」

2013年6月15日 at 2:14 午前

Java EE 7 トレーニング・コースについて

Oracle University では、現在 Java EE 7 のトレーニング・コース(Java EE 7: New Features Coming Soon (￥145,530) )を全世界への提供に向けて準備しています。

これは、Java EE 7 に含まれる新機能を２日間で紹介し、加えてラボで実際に手を動かしながら演習を行うこともできるトレーニング・コースになっています。これによりいち早く Java EE 7 の全体像とプログラミング方法を習得できます(このトレーニング・コースに関してはレビューの要望が私の元にも入ってきたため、一部私もレビューをし改善を加えた部分もあります）。

本トレーニング・コースでは Batch, JSON, WebSocket, JAX-RS, EL 3.0, JMS 2.0 , EJB, JPA, CDI, Bean Validation 等 Java EE 7 に含まれるの技術をとりあげ、既存のアプリケーションを Java EE 7 に対応させるために必要な情報も提供してくれます。

本トレーニング・コースについて日本の担当者と話をした所、本コースは世界で正式公開された後も、現時点では英語でのみ提供予定のようです。ただし、日本の Oracle University に対して、日本語での開催リクエストを行い、かつご希望者が多い場合、日本人講師による日本語でのサービス提供も可能との事でした。

Java EE 7 のトレーニング・コースを日本語で受講されたい方は、今から本トレーニング・コースに対する日本語開催リクエストを出されてみては如何でしょうか。

トレーニングの紹介ページにアクセスした後、「コース開催日のリクエスト」を押下するとリクエストを行う事ができます。途中の質問で「集合研修（Clasroom Training）」にチェックしてください。

どうぞ宜しくお願いします。

2013年6月14日 at 5:29 午後

Virtual Developer Day-Java 開催 (6/19 or 6/25)

Oracle Technology Network (通称：OTN) 主催で Virtual Developer Day : Java が開催されます。下記のスケジュールに詳細を記述していますが、Java SE/FX/Embedded/EE の各テクノロジーに関して、無償で、オンラインでご覧頂く事ができます。Java SE 8 に含まれる 52 の新機能、Lambda 式、JavaFX、Java EE 7、Raspberry Pi など各テクノロジーの最新情報をご確認いただけます。またライブ・チャットもご用意しておりますので、エキスパートに対して直接質問を投げかける事もできます。本イベントにご興味のある方はご登録の上受講してください。
（※ 日本の開発者の皆様は恐らく 6 月 25 日開催のヨーロッパ向けの方が受講しやすい時間帯かと思います。）

アメリカ：6 月 19 日（日本時間夜中の１時〜５時）
ヨーロッパ：6 月 25 日（日本時間夕方５時〜９時）

詳しくは、コチラをご参照ください。

2013年6月14日 at 3:28 午後

Older Posts Newer Posts

2026年1月
月	火	水	木	金	土	日
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31

Posts filed under ‘Java’

事前準備：

(1) レゴマインドストーム EV3 の入手

(2) USB WiFi アダプタの入手

(3) leJOS 0.8.1 beta の入手

(4) Oracle Java SE Embedded の入手

(5) 開発環境用 (Mac/Linux/Windows環境) に統合開発環境、Java SE をインストール

leJOS 環境構築から開発までの手順

(0)ブート可能なマイクロ SD カードを作成

(1) SD カードへファイルのコピーと展開 (Mac/Linux/Windows 環境で実施)

(2)ブート可能なマイクロ SD カードから起動（EV3 で実施）

(3) leJOS で WiFi 設定（EV3 で実施）

(4) ローカル Maven レポジトリに必要ライブラリをインストール (Mac/Linux/Windows 環境で実施)

(5) Maven プロジェクトの作成 (Mac/Linux/Windows 環境で実施)

(6) アプリケーションの開発(Mac/Linux/Windows 環境で実施)

(7) アプリケーションのビルド/デプロイ(Mac/Linux/Windows 環境で実施)

8. アプリケーションの実行（EV3 で実施）

9. LEGO を組み立てて、超音波センサー、タッチ・センサー、モータ(車輪)を取り付けます。

最後に

追記メモ２. Java SE Embedded 8 を使う場合の手順。

1. Oracle Java SE Embedded version 8 の DownLoad

2. Create a Custom JRE with jrecreate

1. 準備

2. Batch コンテナを実行するための設定

3. 動作確認

本アプリケーションの実装方法の詳細

Java Champion & Evangelist

Translate

ご注意

カレンダー

カテゴリー

タグクラウド

過去の人気記事

clustermap

ブログ統計情報

Feeds

アーカイブ

ブログ管理

追記メモ２.
Java SE Embedded 8 を使う場合の手順。