Jboss 管理パスワードなど (復刻ページ)

Serendiptyブログで比較的アクセス数の多いエントリを復刻しています。
このエントリは2012/08/10のものです。

触っていると色々ハックが必要。 Jbossを立ち上げると管理画面にアクセスするためのパスワードなどの設定が必要になる。

このあたりの設定は

jboss-as\server\default\conf の login-config.xml でアプリケーションごとの設定を行う。

 

サンプルの設定が上記のようになっている。 ここでjmx-consoleに関してpropsディレクトリにusers,rolesのプロパティファイルを置くように指定される。

propsは jboss-as\server\default\props ディレクトリを指しているようで、このディレクトリに既に jmx-console-users.properties jmx-console-roles.properties が存在している。 ファイルの内容はそれぞれ、こんな感じ

jmx-console-roles.properties
# A sample roles.properties file for use with the UsersRolesLoginModule admin=JBossAdmin,HttpInvoker

jmx-console-users.properties
# A sample users.properties file for use with the UsersRolesLoginModule admin=admin

私としてはjmx-consoleに対するパスワードのみを設定したつもりでしたが、Jbossの 管理画面の  Admin Console  JMX Console   JBoss WS Console   Tomcat status がアクセス可能になりました。 共通のログイン設定を使っているのかなにか共通の仕組みを使っているのが現時点では理解できて いません。 JBoss Web Consoleについては同じパスワードが効かないので、別の設定をする必要があるようです。

追記: JBoss Web Consoleに関してはまず、本体側のディレクトリがmanagementの下にありました。

jboss-as\server\default\deploy\management\console-mgr.sar\web-console.war

さらにuserやroleのプロパティファイルはこちらでした。

jboss-as\server\default\deploy\management\console-mgr.sar\web-console.war\WEB-INF\classes

web-console-users.properties web-console-roles.properties

他のアプリケーションもこの仕組みでラップすればログイン管理ができるのかも…. このあたりがJbossがTomcatよりも有利な点の一つかな….

Log4jを試してみる (復刻ページ)

Serendipityブログでアクセスの比較的多いページをこちらに移植しています。
このエントリは2012/11/10のものです。

たいしたアプリはつくっていないので今まで使っていませんでしたが、ロギングはプログラミングの基本ですね。自分用の小さなアプリではファイルアクセスと書き込みをまとめて小さなクラスを作ったりしていましたが、javaを使う限りはLog4jを使うべきでしょう。 

ネットを参考に遊んでみました。サンプルとしてはServletのConstractor部分でInitializeを実施してGetの処理の部分でさらにログを出力。基本的にはデフォルト設定でどのように動作するかを確認してみました。

ServletのConstractor部分への追加

logger=Logger.getLogger(“test”);
BasicConfigurator.configure();
logger.setLevel(Level.WARN);

logger.info(“This is info.”);
logger.warn(“This is warn.”);
logger.error(“This is major.”);

ServletのGet処理部分への追加
logger.warn(“Get is called”);
このサーブレットをTomcatに追加してみました。
まず、Tomcat上でLog4jが動作するために、/usr/share/java/tomcat7にlog4j-1.2.15.jarを配置します。これでログはTomcatのログ/var/log/tomcat7/catalina.outに出力されました。

学習になったのは、サーブレットのConstractorが動作するのがTomcatへのDeployのタイミングではなく、最初にGetを実施したタイミングということ。Tomcatの場合、ServletのConstractor部分でUnixのDaemonのような動作の起動を考えていたのですが、何か工夫が必要のようです。

不思議なのは、このURLにアクセスするとログが2行、あるいは3行出力されること…..一つのリクエストに複数のスレッドが反応しているのでしょうか?何かおかしいですよね。

追記:
問題はTomcatのキャッシュのようです。WARファイルを更新してwebappsのディレクトリに入れると自動的に古いアプリケーションがDestroyされて新しいアプリケーションがDeployされる…..ように見えますが、実際には古いアプリはメモリ上で動作しているみたいですね。だから複数のインスタンスが同時進行となってしまい、ログのメッセージも複数表示されるようです。
Tomcatの再起動を実施して問題は解消しました。

JBoss and Tomcat (復刻ページ)

Serendipityブログで比較的アクセスの多いものを移植しています。
このページは2012/11/06のもの。
さらにコードの部分が正しく表示されていませんでした。

AWSで久しぶりに動き…

といっても自分でWindowsのインスタンスを起動。Linuxと同じくMinimumのものであればAWS新規ユーザは1年間無料とのこと、早速動作させてJbossを動かすところまで行きましたが、Jboss重い重い。Windowsが重いのかも知れませんが、Jbossを動作させていると画面のレスポンスが遅い、遅い。1人でWebからアクセスする限りはその速さは特に問題ありませんが…

さらに気がついたのが、AWSのEC2の課金のIOの数値の上がり方が非常に大きいこと。Linux一台(Apache+Tomcat+Mysql)で一月の数値に今月の5日で到達してしまいました。もしかしたら、Windowsのベースが重いのかも知れませんが、とりあえずJbossは遊ばないときは止めておくことにしました。

Jbossを動かしながら少し学んだこと。JbossはTomcat上で動作していることは知っていましたが、実際どのようにうごいているのか分かりませんでした。ディレクトリの構造は必ずしもこうある必要はないと思いますが、Jbossのアプリケーションの一つとしてTomcatが動いているイメージでした。アプリケーションの階層とは逆のイメージですね。

Jbossのアプリケーションの配置場所は

C:\jboss-epp-5.2\jboss-as\server\default\deploy

という感じですが、この中のjbossweb.sarがwebサーバのアプリケーション、実態はTomcatのようです。jbossweb.sarディレクトリ内はこんなファイル群があります。

context.xml,jasper-jdt.jar,jbossweb.jar, jboss-web-service-jar, jstl.jar, server.xml

server.xmlの中をのぞくと

なんてのが見えます。Tomcatと同じですね。

 

TomcatのJRE Versionと開発環境 (復刻ページ)

復刻ページ:Serendipity版のブログでアクセス頻度の高いページを移植しています。
これは2012/08/23の記事です。
本日のトラブルシュート
PC上の開発環境で作成したログイン画面のプロジェクトをサーバ上に移設したのですが、 動きません。 Apache側からのリンクはうまく動いているようなのですがindex.jspを含めwebapp上に 展開したリソースに全くアクセスできません。
殆どお手上げの時にTomcatのログレベルをDEBUGにして起動時のログを見てみました。 こんなエラーがありました。 

catalina.2012-08-23.log Caused by: java.lang.UnsupportedClassVersionError: test/nozomu/com/HelloWorld : Unsupported major.minor version 51.0 (unable to load class test.nozomu.com.HelloWorld)

結局、開発環境が1.7なのに対して、Tomcat側のJREの環境が1.6であるためのエラーのようです。 開発環境かサーバ側どちらかを修正しなければいけないのですが、開発環境の設定が良く分からなかったので Tomcat側でとりあえず修正

tomcat.conf:
#JAVA_HOME=”/usr/lib/jvm/jre”
JAVA_HOME=”/usr/java/jre1.7.0_05″

一応、サーバにも1.7のJREが入っていたのでこれでOKになりました。
今まで、Eclipse上でサーブレットの開発を行っていなかったのと、PC上で確かAWSのサンプルコードを コンパイルするときにPC側の環境を1.7にしたのが背景でしょう。
でも、開発側の環境設定も確認しておかないといけませんね。

mobiファイル自動転送プロジェクト

先日のmobiファイルをKindle端末へ直接メールする方法ですが、うまく動作するようになりました。入力画面もRadioボタンを使って、新規に作品が追加された場合も一行追加するだけで対応できるようにしました。
今回、Crayon Syntax HighlighterというWordpressのプラグインをインストールしたので、これを使って、コードも綺麗に表示したいと思います。(今まではCodeの表示に苦労していました….)
全体の流れは
htmlのformでGETの実行
JSPでGETの引数解析とJava Toolの起動
Java ToolによってNative Scriptの起動
Native Scriptによってmailxを起動してメール転送 となります。

htmlのフォームはこんな感じです。

ここではKindle上のアカウント名とKindleアカウントに登録しているメールアドレスを入力してもらいます。mobiファイルはRadioボタンによる選択、サブディレクトリはhiddenで指定します。

JSPでは引数のチェックを行って、正しく引数が設定されている場合のみサーブレットを起動します。

 

Javaのツールのコードです。単純にNativeコマンドの実行を行っています。Windowsで動作しているTomcatでは使えませんが、Linux(Unix)上で動作している場合、Unixのツールを簡単に使えるので個人的には重宝しています。
Linuxを単にTomcatを動作させるプラットフォームと考えるよりも、Unixの遺産を使いこなす環境と考えることも個人的には意味があるのではと思います。

Javaのツールのコード

使うスクリプトが増えてきて、引数の多いものを逐次追加しているのはご愛嬌というところで…..

最後にKshで作ったスクリプトになります。

jspのレベルではURLを直接タイプすれば誰でもメールできますが、結局はkindle.comにしかメールできませんし、添付ファイルも指定ディレクトリのものしか添付できませんので、不正に使用されることは無いと考えています。

試験した感想としては自分の通常使うメールクライアントに添付してkindle.comにメールするほうが端末にファイルが転送される時間が短いです。
おそらく、AWSで絞っているのか、sendmailの設定なのかはわかりませんが、私のサーバからAWS内のメールサーバへのメール転送に時間がかかり、さらにその先の転送スピードも遅いように見えます。AWS内でのデータ転送がトラフィックの関係で遅いのか、あるいは、契約上スループットが抑えられているのかは興味深いところです。添付ファイルのサイズが小さいと転送も速いように感じられます。

青空文庫 吉川英治作品公開予定

鳴門秘帖の公開完結後、青空文庫の吉川英治作品の公開が止まっていましたが、本日青空文庫を確認すると6月、7月の公開予定が更新されていました。
以下、私が青空文庫の内容を転記しただけですが今後の公開予定となります。

くせ        6月1日
競馬       6月1日
紅梅の客    6月6日
俗即菩提    6月6日
天皇と競馬   6月11日
河豚       6月11日
舌のすさび   6月16日
押入れ随筆   6月16日
辞典のすすめ  6月21日
親鸞の水脈    6月21日
雪村筆「茄子図」 6月26日
文化の日     6月26日

紋付を着るの記   7月1日
落日の荘厳に似る  7月1日
美しい日本の歴史  7月6日
梅ちらほら       7月6日
黒田如水       7月11日
小説のタネ      7月16日
正倉院展を観る   7月16日
随筆 新平家     7月21日
親鸞聖人について  7月26日

三国志はあと、数ヶ月は待つ必要がありそうです。

Kindleドキュメントをサーバから直接Kindle端末にメールする方法

最近、私生活ネタばかりになってしまいましたが、私のサイトの新しいアイディアをひとつ。
青空文庫の吉川英治の作品をmobiファイル化してサイトにアップしていますが、このmobiファイルはユーザの方がPCなりにダウンロードして、その後、メールやUSB接続でさ最終的にKindleに転送しなければいけません。(注:タブレッドなどでダウンロードした端末でmobiファイルをそのまま読んでいるのであればこの必要はありませんね。)
そこで、サーバからKindle端末にmobiファイルの添付されたメールを直接送れば手間が省けます。
最初はBase64のuuencode…..などを考えたのですが、実は私のAmazon Linuxにはmailxというアプリケーションが動作していました。(mailとタイプすると実はこのアプリが動作している。)このmailxには”-a”オプションでファイルを自動的に添付してくれますので、自分でuuencodeなどを使用する必要はありませんでした。
自分のKindle端末にメールを送る場合には実は事前に登録したメールアドレスから到着したメールのみが自分のアカウントに受信され、その後、Kindle端末に転送されます。ですから、自分のアカウントにmobi添付メールを送る場合には自分の登録アドレスがわかりますが、任意の人に使用してもらうには、そのあたりを考慮しなくてはいけません。ちなみにmailxでは”-r”オプションで送信元(返信先)アドレスが指定できます。
おそらく、このようなサービスを行う場合のスクリプトはこんな感じになると思います。

#!/bin/ksh
rm test$$
touch test$$
mail -a musahi01.mobi -s “Musahi01″ -r $2 $1@kindle.com <test$$
rm test$$

引数1としてKindleユーザのアカウント名、引数2としてKindleユーザの登録メールアドレス。Web画面からこのスクリプトを実行するにはjspなりサーブレットを使うのかなと考えています。