Wicket 1.3 から 1.4 へマイグレートしてみた

数年前から Wicket 1.3 (1.3.7) で開発していたプロジェクトを Wicket 1.4 (1.4.7) へマイグレートした体験談です。
長文の上、ほぼ公式Wikiのマイグレート手順通りなのですが、何かの参考になりましたら。

作業をした当時は1.4.7が最新版だったので。この記事も1.4.7として書いていますが、1.4.8 以降に大きな変更が無いかぎり、同手順でいけるはずです。また、作業はEclipse Galileoで行いました。

続きを読む

AjaxLazyLoadPanelのトラブル対応

Wicket-1.4.7のAjaxLazyLoadPanelでちょっとトラブったのでメモ。

getLazyLoadComponent(String)メソッド内の処理が、HTTPリクエストのTimeout時間内に終了しなかったとき。
特にエラー画面も出ず、ずっと処理中のぐるぐるアニメーションが続くだけになってしまいました。

そもそもタイムアウトするような処理が走るのはどうなんだ、というツッコミもありますが、ひとまずサーバ側のTimeout時間を最適な時間に調整することで解決しました。

Logback-0.9.19 以降の設定記法がちょっと変わっていた

Logbackのライブラリを最新版にUpdateすると、アプリケーションの起動時にエラーが発生するようになりました。

ERROR in ch.qos.logback.core.joran.spi.Interpreter@11:13 - no applicable action for [encoding], current pattern is [[configuration][appender][encoding]]

以下、直したのでメモ。

調べてみると、Logback-0.9.19から、xmlの設定記法がちょっと変わっていました。

いままでのlayoutタグなどはencoderタグとして結果的に簡略化、そしてencodingタグはcharsetタグに変更になった模様。

というわけで、以前書いたlogback.xml を編集しなおし、
コンソールの出力には、

<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
	<Target>System.out</Target>
	<encoder>
		<Pattern>[%-5level][%d{yyyy-MM-dd HH:mm:ss.SSS}] %class - %msg%n</Pattern>
	</encoder>
</appender>

外部ファイルに出力したいときは、

<appender name="FILE"
	class="ch.qos.logback.core.rolling.RollingFileAppender">
		<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
			<FileNamePattern>logs/logFile.%d{yyyy-MM}.log</FileNamePattern>
			<MaxHistory>7</MaxHistory>
		</rollingPolicy>
		<encoder>
			<charset>UTF-8</charset>
			<Pattern>[%-5level][%d{yyyy-MM-dd HH:mm:ss.SSS}] %class - %msg%n</Pattern>
		</encoder>
</appender>

とすることで、エラーを抑えることができました。

実行環境は

です。

任意実行のJavaプログラムでLogbackのログファイルをRollingさせる設定メモ

cronによるバッチ処理の様な任意実行のJavaプログラムでlogbackを使うときに、ログのrolling設定でハマったのでメモ。

logbackのTimeBasedRollingPolicyを使って、過去一週間の日ごとのログに分けたかったので、公式のドキュメントのExample 4.6を参考にして下記のように設定しました。

<appender name="FILE"
	class="ch.qos.logback.core.rolling.RollingFileAppender">
	<Encoding>UTF-8</Encoding>
	<File>logs/logFile.log</File>
	<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
		<FileNamePattern>logs/logFile.%d{yyyy-MM-dd}.log</FileNamePattern>
		<MaxHistory>7</MaxHistory>
	</rollingPolicy>
	<layout class="ch.qos.logback.classic.PatternLayout">
		<Pattern>[%-5level][%d{yyyy-MM-dd HH:mm:ss}] %class - %msg%n</Pattern>
	</layout>
</appender>

ところが実際に動かしてみると、実行日が変わっても全てlogs/logFile.logにログが書き込まれてしまい、日ごとのログファイルも作成されません。
結果的にFileタグを除去して、

<appender name="FILE"
	class="ch.qos.logback.core.rolling.RollingFileAppender">
	<Encoding>UTF-8</Encoding>
	<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
		<FileNamePattern>logs/logFile.%d{yyyy-MM-dd}.log</FileNamePattern>
		<MaxHistory>7</MaxHistory>
	</rollingPolicy>
	<layout class="ch.qos.logback.classic.PatternLayout">
		<Pattern>[%-5level][%d{yyyy-MM-dd HH:mm:ss}] %class - %msg%n</Pattern>
	</layout>
</appender>

とすると、実施日ごとに直接ログファイル(例:logFile.2009-12-22.log)を作成してくれるようになりました。

未検証ですが、サーブレットコンテナで常時動くようなシステムであればFileタグを指定していても大丈夫なのかな。

上記の設定をTomcat上で動くアプリケーションに設定すると、$CATALINA_HOME/logs の中に保存されます。

2010年4月9日の記事に、新しい設定記法についてのせました。こちら。

そうそう、実行環境は

でした。

b-mobileのWebアクセラレータは本当にSSLに対応していないのか?

モバイル環境としてMacBookAirでb-mobile3G(MF626)を使ってます。
でもb-mobile接続でGmailを使おうとすると、ログイン処理から先に進まなかったり、運良くメールタイトル一覧が表示されても記事が開かない…などなど、まったく使えないことがほとんど。

静的なページはスムーズに表示されていて、これがまた混乱の元でしたが、mixiや職場のシステムなど、特にログイン時のHTTPSでの通信が必須なWebサービスで同様のタイムアウトが起こっていることに気がつきました。

一方、b-mobileでは、Webアクセラレータをproxyとして提供しています。
静的なHTTPのアクセスがOKなのにHTTPSのアクセスを挟むと駄目なのは、単純にHTTPSにアクセラレータのproxyが通っていないからじゃね?

というわけで、

試してみたこと。

  • 環境
    • MacBookAir2,1
    • b-mobile3G (MF626)
    • GmailSSL設定は「常に使用する」

b-mobileのドライバとb-Accessを通常通りインストールすると、「システム環境設定」>「ネットワーク」に「ZTEUSBModem」というインターフェースが追加されます。これの「詳細」>「プロキシ」を見ると、

mao.bmobile.ne.jp:32080

というアクセラレータのproxyが、「Webプロキシ(HTTP)」にだけ設定されています。

そこでこのproxy設定を「保護されたWebプロキシ(HTTPS)」にも入力して、再度Gmailを閲覧してみると、非常にスムーズに動作するようになりました。タイムアウトが頻発していたのが信じられないぐらい(定量的な評価じゃなくてごめんなさい)。

b-mobileサイトでの情報と、とりあえずの結論

けれども実は、b-mobileのアクセラレータのQ&AにはSSLには対応していないと明記されていて、利用ガイドにもWebプロキシだけにWebアクセラレータのproxyが設定されています。

netstatで見ている限りは、HTTPSへの設定後はHTTPS通信を行っても、直接相手サーバの443ポートへのアクセスは無く、アクセラレータのproxyがちゃんと経由してくれているように見えます。

ネットワーク屋さんではないのでこの程度のテストしかできないのですが、結論としては、

  • b-mobileGmailなどの調子が悪い人は、HTTPSにもアクセラレータのproxyを通すと改善する(場合がある)

といったところでしょうか。

これでFirefoxのUserAgentをiPhoneにして転送量を抑えて頑張るとか、涙ぐましい(無駄な)努力の日々ともオサラバです。

Restlet(1.2-m2)へ入門してみんとす

あるWebサービスから別個稼働しているWebサービスのデータを表示したくて、RESTで解決できないかなあということで、検証がてらRestletを勉強してみます。

(私の現状でのRESTへの知識:HTTPリクエストに対してxmlが帰ってくるから適当にパーサして使ってね!)

下準備

ひとまず環境を作ります。

  • eclipsetomcatプロジェクトを作成
  • http://サーバ名:port/restlet-1.2/で上記のtomcatプロジェクトが動作するようにcontext.xmlを作成
  • Restletの公式サイトから、restlet-1.2m2.zipをダウンロード
  • 展開してできたlibディレクトリから、org.restlet.jar、org.restlet.ext.servlet.jarをtomcatプロジェクトの適当な場所へ複製(ひとまずReadme.txtを読む限り、この2つだけならTomcat以外の依存jarはないみたい)
  • tomcatプロジェクトのビルドパスに2つのjarを追加

FirstStepsをなぞってみる

公式サイトのFirstStepをなぞってみます。パッケージ名はrestlet.testingにしました。

HelloWorldResourceの作成
package restlet.testing;

import org.restlet.resource.Get;
import org.restlet.resource.ServerResource;

public class HelloWorldResource extends ServerResource {
	
	@Get
	public String represent() {
		return "Hello, world.";
	}

}
HelloWorldApplicationの作成(公式だとFirstStepsApplicationですね)
package restlet.testing;

import org.restlet.Application;
import org.restlet.Restlet;
import org.restlet.routing.Router;

public class HelloWorldApplication extends Application {
	
	@Override
	public Restlet createRoot() {
		Router router = new Router(getContext());
		router.attachDefault(HelloWorldResource.class);
		return router;
	}

}
web.xmlの作成
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4" 
	xmlns="http://java.sun.com/xml/ns/j2ee"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
		 http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">

	<display-name>Testing Rest Application</display-name>
	<description>
		This is only a test of the Restlet.
	</description>

	<context-param>
		<param-name>org.restlet.application</param-name>
		<param-value>restlet.testing.HelloWorldApplication</param-value>
	</context-param>
	
	<servlet>
		<servlet-name>RestletServlet</servlet-name>
		<servlet-class>org.restlet.ext.servlet.ServerServlet</servlet-class>
	</servlet>
	
	<servlet-mapping>
		<servlet-name>RestletServlet</servlet-name>
		<url-pattern>/*</url-pattern>
	</servlet-mapping>
	
</web-app> 
context.xmlの作成
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4" 
	xmlns="http://java.sun.com/xml/ns/j2ee"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
		 http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">

	<display-name>Testing Rest Application</display-name>
	<description>
		This is only a test of the Restlet.
	</description>

	<context-param>
		<param-name>org.restlet.application</param-name>
		<param-value>restlet.testing.HelloWorldApplication</param-value>
	</context-param>
	
	<servlet>
		<servlet-name>RestletServlet</servlet-name>
		<servlet-class>org.restlet.ext.servlet.ServerServlet</servlet-class>
	</servlet>
	
	<servlet-mapping>
		<servlet-name>RestletServlet</servlet-name>
		<url-pattern>/*</url-pattern>
	</servlet-mapping>
	
</web-app> 
動かしてみる

tomcatを起動して、http://サーバ名:port/restlet-1.2/へアクセスすると、Hello, world!と表示されました。

……このコード量だけでレスポンスがHello, world!xmlみたいに帰ってくるのかなあとワクワクしていましたが、人生そんなに甘くなく、文字列だけが帰ってきてる模様。その辺はやっぱり実装しなくちゃいけないのですね。

第2回 wicket勉強会に参加できませんでした……

 当日朝、ちょうど出発の準備をしていたら身内の訃報が入り、残念ながら参加できませんでした。訃報と参加できなかった事、両方の意味で無念です。
 参加された方の記事を地引き網方式で巡回しましたが、とても盛況したようですね。

 一緒に行く予定だった後輩達にも好評だったようで、次回こそ再び参加したいと思います。できれば学生を引き連れて。

 私も前回参加させていただいて肌で感じたことですが、kk_ataka(d:id:kk_ataka:20090305) の言うとおり、IT分野を目指している学生こそ、こういう勉強会に就職前に行っておくべきだと思うんですよね(勿論、懇親会も)。