Windows7でChromiumをビルドする

No Comments

Chromiumをビルドしてみた。
リビジョン番号は139214。
(ChromiumはGoogle ChromeのもとになっているオープンソースのWebブラウザ)

環境はWindows7 64bitで,Visual Studio 2010 Expressを用いる。
また,すでにgitがインストールされているとする。

基本的に下記のページに指示に従えば良かった。

Build Instructions (Windows)

ビルド前の準備

VS2010Expressの場合は下記をの2つを実施する。

  • Prerequisite software
    注意点は下記の通り。
    • Windows 7.1 SDK
      こいつをインストールした後にVS2010C++SP1をインストールするとコンパイラを上書きされるというバグあり。(手順の中に修正プログラムのインストールも含まれているので問題はない)
    • KB articles: KB957912, KB958842, KB960075, KB967631, KB971092, and KB2519277
      KB971092はVS2008用のためインストール出来ず。
    • Cygwin
      インストールしなかった。以下,コマンドはすべてコマンドプロンプトから実行した。
  • Setting up the environment for Visual Studio 2010
    途中で,”gclient runhooks”を実行する箇所があるけれど,depot_toolsが無いと実行できないので,取得後実行する。
    後は手順通りにやれば問題なく実施できる。

depot_toolsの取得

depot_toolsをインストールするディレクトリにて下記のコマンドを実行する。

次にWindowsの環境変数PATHにこのdepot_toolsまでのパスを通す。

ソースの取得

ソースを取得するディレクトリにて,下記のコマンドを実行する。

作成されたリポジトリの内容は下記で確認できる。

次に,ソースを実際に取得する

ソースが取得できたら次はビルド。

ビルド

取得したソースのsrc/chrome/chrome.slnをダブルクリックで実行する。
そしてこのソリューションをビルドする。
(動かすだけならchromeプロジェクトをビルドすればよいみたい。)

ビルドが完了するとsrc/build/Debug(またはRelease)にchromium.exeができるので,これを実行すればChromiumが起動する。

http://www1205uf.sakura.ne.jp/wp/world/wp-content/uploads/2012/05/chromium.png

ビルドの失敗の修正

手順通りにやってもいくつかビルドエラーが起こったので,その時に解決した方法をメモ。

ファイルのエンコードの間違い

下記のようなエラーが起こった。

エラー箇所は下記のようになっており,C++コンパイラがコードをUnicodeとして認識していないのが原因らしい。

そこで,解決方法はこのファイルを選択し,[ファイル]-[保存オプションの詳細設定]を選択する。

http://www1205uf.sakura.ne.jp/wp/world/wp-content/uploads/2012/05/change_encoding.png

次に,開くダイアログにてエンコードに”Unicode(UTF-8 シグネチャ付き)-コードページ65001″を選択し保存。

http://www1205uf.sakura.ne.jp/wp/world/wp-content/uploads/2012/05/change_encoding2.png

これで解決した。

ANSIコードページに表示できないUnicodeが含まれている

次に下記のようなエラーが出た。
警告をエラーとして扱ったため,オブジェクトファイルが生成されなかったとのこと。

ANSI コード ページに表示できない,Unicodeの文字を使っているのが原因とのこと。
とりあえず警告をエラーとして扱うのを無効化して回避。。。
問題が出ていたunit_testプロジェクトにて下記の赤枠のように設定する。
構成を”すべての構成”にしておかないと,Debug,Releaseの両方には適用されないので注意。

http://www1205uf.sakura.ne.jp/wp/world/wp-content/uploads/2012/05/warning_error_off.png

これで解決。

インストーラーの作成

chrome.slnをビルドしただけでは,インストーラー(mini_installer.exe)は作成されなかった。

そこで,src\chrome\installerの中のmini_installer.slnをダブルクリックで起動する。
ソリューションをビルドすればDebug(またはRelease)フォルダにmini_installer.exeが生成されているはず。

これをダブルクリックで実行すればPCにインストールされる。

Chromiumのリビジョン番号を知る

作成したインストーラーの名前にリビジョン番号を追加しておきたくなった。
これからソースを更新していってもリビジョン番号がわかるようにしたい。

そのためにはsrcディレクトリに入って,下記を実行する。

すると下記のように表示される。

ここのRevisionがリビジョン番号を示している。

gclientのツールでもわかるのかと,helpを見て調べたがよくわからなかった(汗)


Hibernate3を使った永続オブジェクトの作成・検索・削除

No Comments

前回でHibernateをMavenで用いるための下準備を行った。

Hibernate3とMavenを使って,マッピング用のクラスやテーブルスキーマを自動生成する

そこで今回は実際に永続オブジェクトの作成・検索・削除を行なってみる。

一時的に作成したオブジェクトを永続オブジェクトに登録することによって,JVMが終了しても存在し続けるようにすることができる。

今回も勉強に用いたのは下記の書籍である。

http://www.amazon.co.jp/Hibernate-%E9%96%8B%E7%99%BA%E8%80%85%E3%83%8E%E3%83%BC%E3%83%88%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA-James-Elliott/dp/487311215X

使用したMavenは3.0.4である。

プロジェクトの構成

プロジェクトの構成は前回に引き続き下記のようにする。
今回作成するjavaファイルは正しいパッケージのパスに保存する。

永続オブジェクトの作成

下記のようなCreateTest.javaファイルを作成する。
Sessionクラスのsaveメソッドに渡すことでオブジェクトは永続化される。

MavenでこちらのMainメソッドを実行するには,下記のプラグインをpom.xmlに追加する。

そのあと,下記のコマンドで実行できる。

コンパイルから行う場合は下記のようにする。

永続オブジェクトの検索

下記のようなQueryTest.javaを作成する。

クエリは前回,マッピング文書(Tag.hbm.xml)に記述したのであった。
下記のqueryタグがそれに該当する。

実行方法については”作成”のときと同様である。

永続オブジェクトの削除

savaメソッドのように,Sessionクラスのdeleteメソッドの引数として設定すれば,永続オブジェクトは一時オブジェクトに戻る。
そしてスコープ外や参照が無くなった時削除される。


Hibernate3とMavenを使って,マッピング用のクラスやテーブルスキーマを自動生成する

1 Comment

Hibernateの勉強として。
HibernateはJavaのORMとして有名なライブラリである。

今回やりたいことは下記の項目でHibernateを用いるための下準備となっている。

  1. マッピング用のアクセッサクラスを自動生成
  2. MySQLのテーブルのスキーマを自動生成

前提条件は下記のとおりである。

  • Maven2をインストール済みである
  • jdk7をインストール済みである
  • MySQL Serverをインストール済みである

下記の書籍を参考に用いた。
http://www.amazon.co.jp/Hibernate-%E9%96%8B%E7%99%BA%E8%80%85%E3%83%8E%E3%83%BC%E3%83%88%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA-James-Elliott/dp/487311215X

使用したMavenは3.0.4である。

プロジェクトのファイル構成

まず,mavenプロジェクトの雛形を自動生成する。

ここで,プロジェクトの構成は下記のようにする。

pom.xmlについて

pomについては下記のように記述した。

Hibernateのコンフィグファイルを作成する

ファイル名はhibernate.cfg.xmlというものがよく使われているみたい。
今回はMySQLを用いるので,その設定を行なっている。
また,mappingタグにはマッピング文書へのパスを書く。
これをsrc/main/resourcesの中に保存する。

log4j.propertiesの設置

hibernateは内部でlog4jを用いているらしい。
src/main/resource内に保存する。

マッピング文書の作成

マッピング文書には自動生成されるクラスの情報やクエリを記述する。

アクセッサクラスの自動生成

以上を行った上で,下記のコマンドを実行すると,アクセッサクラスが自動生成される。

すると,pom.xmlで指定したsrc/main/java/jp.ne.sakura.www1205ufというディレクトリにTag.javaというファイルが自動生成される。
Tag.javaは下記のようになっている。

MySQLの下準備

スキームを自動生成するために,下記の操作を行いDBとそれにアクセスするユーザーを追加しておく。

このときのユーザーはhibernate.cfg.xmlに記述したものを用いる。

スキーマの自動生成

下記のコマンドを実行する。

すると,作成済みのDBにテーブルが自動的に作成される。

作成されたことは下記のコマンドで確認できる。

なお,以上のすべてを実行しコンパイルを行う場合は,下記のようにすればよい。

これで永続化オブジェクトを作成しDBにデータを格納したり,それを検索したりといった操作が可能になる。

それについては次回。


JAX-RS(Jersey)とSpring3の連携

No Comments

WebアプリケーションフレームワークとしてSpringを使ってみる。

その勉強の手始めにこれまでの記事で作成したJAX-RS(Jersey)のMavenプロジェクトをSpringに対応させてみた。

Mavenを用いて,JAX-RS(Jersey)で作成したWeb APIをJettyのServletコンテナで動かす

参考にさせていただいたのは
ぺーぺーSEの日記 – Spring 3でHello World REST (Jersey)
である。

使用したMavenは3.0.4である。

Mavenプロジェクトの雛形を作る

すると,下記のような構成のプロジェクトが生成される。

pom.xmlの記述

Jettyのサーブレットコンテナを使えるように設定。

applicationContext.xmlの作成

このファイルも必要らしい。
下記のように記述する。
このファイルはresourceフォルダ内に設置する。

web.xmlの記述

下記のように記述する。

Spring + Jerseyのサービスの作成

下記のRestTest.javaをsrc/main/java/jp/ne/sakura/www1205ufディレクトリにおいた。

最終的な構成

これまでの手順を踏むと,最終的なファイル・ディレクトリ構成は下記のようになる。

ビルドとローカルリポジトリへのインストール

下記のコマンドを実行する。

実行

APIには下記のURIでアクセスできる。

http://localhost:9095/rest/hello

すると

と表示されるはずである。


WordPressでWPtouchプラグインを有効にするとリダイレクトループが発生する

No Comments

標記の通り。

WPtouchプラグインをインストールしているとする。

iPhoneからWordPressにアクセスすると
“ページを開けません 多くのリダイレクトが発生しています”
エラーメッセージが表示されアクセスできなくなることがあった。

この場合,”Permalink Fix & Disable Canonical Redirects Pack”というプラグインをインストールして有効化するとエラーが表示されなくなる。

問題と解決方法はイマイチ分かっていないけれど。。。


Mavenを用いて,JAX-RS(Jersey)で作成したWeb APIをJettyのServletコンテナで動かす

1 Comment

Mavenを用いると前頁の手順が非常に簡略化される。

JAX-RS(Jersey)で作成したWeb APIをJettyのServletコンテナで動かす

実行はWindows7上で行い,JAX-RSの実装は全ページ同様Jerseyを用いている。

Mavenのバージョンは3.0.4を用いた。(インストール方法については省略)

プロジェクトの構成

Mavenのデフォルトの構成を用いて下記のような構成にする。

web.xmlやソース(.java)には前頁で作成したものをそのまま入れる。

pom.xmlの記述

下記のように記述する。

ビルドとローカルリポジトリへのインストール

下記のコマンドを実行する。
するとローカルリポジトリ(デフォルトだと~/.m2)に.warのファイルがインストールされる。

実行

APIには下記のURIでアクセスできる。

http://localhost:9095/rest/hello

すると

と表示されるはずである。


JAX-RS(Jersey)で作成したWeb APIをJettyのServletコンテナで動かす

1 Comment

RESTの勉強にJAX-RSを触ってみた。
そこで,作成したコードをJettyのServletコンテナ上で動かしてみる。

Jettyをアプリに組み込んで,プログラム中から起動するケースの方が多いようだけれど,Jettyの勉強も兼ねて。

JAX-RSの実装に関してはJerseyを用いた。また,実行環境はUbuntu10.04である。

使用したMavenは3.0.4である。

Jettyのインストール

下記のEclipseのサイトからJettyをダウンロードする。

eclipse.org/jetty

2012/5/6現在での最新バージョンは8.1.3.v20120416であった。
ダウンロードして,インストールするディレクトリに解凍する。

JAX-RSサービスの作成

下記のようなサービスのクラスを作成する。
ファイル名はRestTest.javaとした。
このサービスはhttp://[ドメイン]:[ポート番号]/[アプリ名]/helloのURIに対し,”Hello World”のレスポンスボディを返す。

Jerseyのダウンロード

下記の公式ページからjarseyのzipをダウンロードする。
(For the convenience of non-maven developers the following are provided:の項目)

Jersey.java.net

2012/5/6現在でjersey-archive-1.12.zipというファイルをダウンロードできた。
これを任意のディレクトリに保存し解凍する。

web.xmlの作成

次に,下記のようなweb.xmlファイルを作成する。
このファイルは後ほどwarファイルにパッケージングすることになる。

warファイルを作成する

warファイルを作成するために,下記のような構成にする。
先程,ダウンロードしたJerseyのlibディレクトリ中のjarファイルをすべてコピーして配置する。

その後,warファイル作成用ディレクトリにて下記のコマンドを入力してwarファイルにパッケージング。

JettyのServletコンテナに配置

ServletアプリをJettyのServletコンテナに配置するための構成は下記のようになる。

実行

[jettyのインストールディレクトリ]に入って下記のコマンドを実行して起動する。

作成したRESTのAPIにアクセスする際は下記のようなURIを用いる。ブラウザのナビゲーションバーに貼り付けるなどして試す。

すると,下記のように表示されるはず。


Mavenを用いると上記の操作が非常に簡略化される。これについては次回。


オレオレ証明書に対してWindows7標準のWebDAVクライアントを使う

No Comments

Windows7でオレオレ証明書を用いたWebDAVサーバーに標準のクライアントからは接続できない。

これはWindows7では信頼されたサーバー証明書でないとアクセスできないという制限があるためである。

しかし,オレオレ証明書を信頼されたサーバー証明書としてインストールすると接続することができる。

それには下記の手順を踏む必要がある。
プロトコルはもちろんhttpsで,Basic認証ありとする。

  1. オレオレのサーバー証明書を信頼出来るルート証明書としてインストールする。インストールするにはIEを用いることができる。
  2. “コンピュータ”を右クリックして表示される”ネットワークドライブの割り当て”を用いて接続する。

上記はググればいくらでもでてきて,この方法で殆どの人が解決しているようだった。

しかし,なぜか失敗する。

“ネットワークドライブの割り当て”の接続中にBasic認証のダイアログが表示されるのだけれど,正しいものを入力してもエラーになってしまう。

なぜだろうと思って調べたら,オレオレ証明書の方に問題があった。

Common Name(略してCN)が設置先のサーバーのドメイン名(www.domain.co.jpみたいな)と異なっていたのである。

この場合,上記手順によってオレオレ証明書を信頼するように設定しても,アクセスしようとしているサイトと表示されるサイトが別物の可能性が生じ,危険なサイトと判断されてしまう。

これがダメだったらしい。

オレオレ証明書を作り直し,CNを正しいサーバーのドメイン名に変更すれば,問題なく接続できた。

めでたしめでたし(汗)


nginxをapacheのリバースプロキシとして設定する

No Comments

勉強のために今流行のnginxをapacheのリバースプロキシとして設定することを試みた。
nginxは”Webサーバー” + “リバースプロキシ”の機能を持っており,C10K問題に対応して設計されたサーバーとのこと。

参考にしたサイトはapache のかわりにnginxを使ってみる(10) nginx をリバースプロキシとして使ってみたのサイト。

以下,OSはUbuntu11.04とする。

インストール

最新の安定版 Nginx が LaunchPad 上の Nginx PPA から取得できる。
下記のように入力し,インストールする。

2012年5月現在で,バージョン1.2.0をインストールすることができた。

nginx.confを編集する

/etc/nginx/nginx.confはデフォルトのままとした。

nginxのリバースプロキシ設定

/etc/nginx/conf.d/proxy.confにリバースプロキシの設定を記述。
proxy_set_headerを指定して、バックエンドサーバに対してクライアントのIPアドレスを教える。

再起動(sodo /etc/init.d/nginx restart)時にキャッシュ用ディレクトリを作れなかったという類のエラーが出た場合は自分で作る。
その際は所有者とグループをnginxを実行しているユーザーに合わせる。

sites-available/defaultの設定

/etc/nginx/sites-available/defaultの編集を行う。
default以外に記述する場合は,sites-enabledにシンボリックリンクを貼るのを忘れないこと。
下記,ポート8080にてApacheがlistenしているとして記述。

$do_not_cacheの値が0以外の値だと,キャッシュを使わなくなる。
ここで,場合分けなどして設定する。

apacheの設定

リバースプロキシ用のモジュールをインストール。
ApacheのログにnginxのサーバーのIPではなく,クライアントのIPが表示されるようにするためのもの。

再起動

再起動して完了。

次はapache上のコンテンツをnginxのWebサーバーで表示させることを試みよう。