初めてのherokuでJavaデプロイ

herokuを触ってみようとおもって、herokuでjavaを動かそうとトライした時のメモ。

基本はこちらの２つを参考にさせて頂きました。ありがとうございます。

酒浸りの日々
daicham blog

参考にさせて頂いたブログを見ればherokuのへのpushまでは行けます。

で、自分のアプリにアクセスしたところエラー発生。ブラウザの画面には以下のメッセージが。
Application Error
An error occurred in the application and your page could not be served. Please try again in a few moments.
If you are the application owner, check your logs for details.
 おやぁ？
ログを見てみようか…。

$heroku logs
 (中略)
2012-02-21T14:46:17+00:00 heroku[slugc]: Slug compilation finished
2012-02-21T14:46:19+00:00 heroku[web.1]: Starting process with command `sh target/bin/webapp`
2012-02-21T14:46:20+00:00 app[web.1]: Exception in thread "main" java.lang.NoClassDefFoundError: HelloWorld
2012-02-21T14:46:20+00:00 app[web.1]: Caused by: java.lang.ClassNotFoundException: HelloWorld
2012-02-21T14:46:20+00:00 app[web.1]:  at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
2012-02-21T14:46:20+00:00 app[web.1]:  at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
2012-02-21T14:46:20+00:00 app[web.1]:  at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
2012-02-21T14:46:20+00:00 app[web.1]:  at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
2012-02-21T14:46:20+00:00 app[web.1]:  at java.security.AccessController.doPrivileged(Native Method)
2012-02-21T14:46:20+00:00 app[web.1]:  at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
2012-02-21T14:46:20+00:00 app[web.1]: Could not find the main class: HelloWorld. Program will exit.
2012-02-21T14:46:21+00:00 heroku[web.1]: Process exited with status 1
2012-02-21T14:46:21+00:00 heroku[web.1]: State changed from starting to crashed

 NoClassDefFoundErrorでてまんがな。
ググるとherokuのDevCenterが引っかかった。
http://devcenter.heroku.com/articles/release-note-java-2011-09-29
内容は…一応訳してみた。
Changes to Java Build Pack, Sep 29 2011
Javaビルドパックへの変更、2011/9/29

What Changed何が変わった？

On Sep 29, Heroku was updated with some changes to how Java applications are built. These changes only affect applications created after Sep 29th. Applications created before this date will continue to behave as they did. This change only impacts how applications are built and deployed. It does not affect running applications in any way.
9/29、herokuはjavaアプリケーションを構築するための変更でアップデートされました。これらの変更は9/29以降に作成されたアプリケーションにのみ影響します。この日付以前に作成されたアプリケーションはそれまでと同様の振る舞いを続けます。この変更はどのようにアプリケーションが構築／デプロイされるかにのみ、影響します。実行中のアプリケーションには決して影響しません。

If you are creating a new application on Heroku and you are using an old guide or an old sample, or if you are destroying and recreating a Java application, these changes may affect you.
もし、あなたが新しいアプリケーションをHerokuで作成し、古いガイド／サンプルを使っている場合、あるいは、javaアプリケーションを破棄して再作成している場合、これらの変更が影響するかもしれません。

If you are experiencing java.lang.ClassNotFoundException or java.lang.NoClassDefFoundError errors or get the error message “sh: mvn: not found” or similar, read on.
もし、あなたが、 java.lang.ClassNotFoundException、java.lang.NoClassDefFoundErrorのエラー、あるいは“sh: mvn: not found”や似たようなエラーメッセージに直面しているのであれば、以下を読んでください。

Before Sep 29th, Heroku included the .m2 Maven cache and the Maven distribution itself (residing in .maven) in your compiled slug. This allowed you to reference jar modules residing in the Maven cache without having to copy them to a target directory or including them in a WAR file. It also allowed you to execute mvn during runtime.
9/29以前、Herokuは、あたなのコンパイルしたslugに.m2 MavenキャッシュとMavenディストリビューション自身（.mavenに備わっている）を含んでいました。これは、Mavenキャッシュに備わっているjarモジュールをtargetディレクトリにコピーする、あるいは、WARファイルにそれらを含める、という必要なく、参照することができるようにしていました。また実行中にmvnを実行することもできるようにしていました。

Applications created after Sep 29th 2011 will no longer include the .m2 cache or Maven itself. It is your responsibility to copy dependencies into a directory such as target during the build process. This is a standard best practice and should not cause any issues to new developers. For example, if you are building a WAR based application and deploying it with Jetty runner using an approach like the one shown in the Spring MVC guide, you will not have any issue.
2011/9/29以降に作成されたアプリケーションにはもう.m2キャッシュやMaven自身は含まれません。依存関係をディレクトリ（targetなど）をビルドプロセス中にコピーすることは、あなたの責務となります。これは普通のベストプラクティスで、新規の開発者にとっては全く問題にならないはずです。例えば、もしあなたがWARベースのアプリケーションを構築していて、Spring MVCガイドに掲載されていた１つのような手法としてJetty runnerを使ってデプロイをしている場合、何も問題はないでしょう。

Similarly, it is not a best practice to use Maven as part of your production configuration since it may introduce unpredictable behavior due to how Maven loads plugins dynamically.
同様に、Mavenが動的にプラグインをロードすることにより、予測できない振る舞いをもたらすかもしれないため、製品構成の一部としてMavenを使うことはベストプラクティスではありません。

Impact on Existing Apps
既存アプリへの影響

The behavior for applications created before Sep 29th have not changed. I.e. if you created your application before Sep 29th and you deploy a change to the application today, the application will get rebuilt with the Maven cache and the Maven executable included in the slug. Therefore, existing applications should continue to work as expected when you deploy changes.
9/29より前に作成されたアプリケーションの振る舞いは変更ありません。例えば、もしあなたがアプリケーションを9/29より以前に作成し、今日変更をデプロイした場合、アプリケーションは実行可能なslugに含まれていたMevenキャッシュとMavenによって再構築されるでしょう。従って、既存アプリケーションは、変更をデプロイした時でも想定通りの動きを継続するはずです。

Benefits
利益

With this change, your compiled slug size will generally be smaller. The more plugins and build time dependencies that you don’t need at runtime, the bigger a difference this will make.
この変更によって、あなたのコンパイルされたslugのサイズはたいてい小さくなります。あなたが実行時には必要としない多くのプラグインとビルド時間の依存関係、これが違いをより大きくします。

Maven App Assembler Plugin
Maven App Assembler プラグイン

The Maven appassembler plugin is a great way to set up an application execution wrapper for your Java application. It supports either referencing dependencies directly in the Maven cache and copying dependencies into a repo directory in target. Because .m2 is not included in the slug and therefore not available at runtime, you must configure the plugin to copy dependencies to your target directory. Fortunately this is the default behavior. But in case you are using sample code or a guide from before Sep 29, make sure you delete the following line in the plugin configuration:
false
Maven appassemblerプラグインはあなたのjavaアプリケーションにとってアプリケーション実行ラッパーをセットアップするためのすばらしい１つの方法です。Mevenキャッシュ内で依存関係を直接参照すること、依存関係をtarget内のrepoディレクトリにコピーすることのいずれの方法もサポートしています。.m2はslugに含まれず、その結果実行時には利用できないことから、あなたはtargetディレクトリに依存関係をコピーするようプラグインを設計しなければなりません。幸いにも、これはデフォルトの振る舞いです。しかし、9/29より前のサンプルコードやガイドを使っている場合、以下の行をプラグイン設定から削除するようにしてください。
false

If you’re in doubt exactly how to configure Maven or you are having trouble getting things to work, you can start over with the simple Getting Started example (with sample code in github and check how it might differ from your own app.
もし、どのようにMavenを設定するかが正直言って疑わしい、あるいは、何かを稼働させるようとしてトラブルに陥っている場合、simple Getting Started exampleでやり直してください。（githubのサンプルコードと、自身のアプリがどのように異なるかをチェックしてください）
うむ、じゃあ.gitignoreを削除して、targetディレクトリ丸ごとgitの管理対象にして、pom.xmlにあるgenerateRepositoryの行を削除してみて、※追記参照もう一回gitにcommitして、herokuにpushしたら…。

動いた！

動いたは良いけど…、herokuのslugってなんだ！？と思った今日この頃でした。
追記
こちらのheroku本家に載っていたやり方だと、.gitignoreは必要、pom.xmlの内容が以前と違う、という２点があるので、本家を参考にした方がいいかも…。
http://devcenter.heroku.com/articles/java

コメント

コメントを投稿

このブログの人気の投稿

ユースケースポイント法（UCP法）

見積もりにおける手法の１つ。 有名なFP法はデータ項目数（DBのテーブルやファイルの項目数）と入出力の数を手がかりにシステムの規模を見積もるが、UCPはUMLでいうクラス図を元に規模を見積もる方法。 分析クラス図までを作れれば、UCP法で見積もりしやすいだろう。 分析クラス図をベースにしたポイントを「未補正UCP」とし、さらに技術的な複雑度、環境的な複雑度をもとにした係数をかけることで「補正後UCP」ができあがる。 あとはFP法と同じように「１ポイントは何時間（または人月）かければ消化できるか」＝生産性係数をかけることで工数の見積もりにすることができる。 UMLを主に開発するプロジェクトでは非常に重宝されそうなこの手法だが、問題点を感じないわけではない。 この手法で感じる問題点は、FPと同じように「生産性係数をいくつにするんじゃい？」という点なのだが、UCP法を考えたGeri Schneiderさんによると普通のプロジェクトならば生産性係数は２０時間らしい。 （つまり１UCPの機能あるいはシステムであれば２０時間で作れるであろう、と。） しかしながらこのUCP法はまだ日が浅いためか、Geriさんの考えるプロジェクトが私の周りと一致しずらいのか、２０時間で本当に大丈夫か？という不安がいつもある・・・。 （事実、２０時間で工数に変換すると「大丈夫かなぁ・・・」という工数が出てくる） また、技術要因はさることながら、環境要因が曲者と思う。 なぜならば、環境要因は「採用するプロセスの習熟度」「モチベーションの有無」「プログラミング言語の難しさ」などなど、非機能要件的な要素を先に係数として含めてしまう仕組みになっており、これをどう扱うかが実際に使おうとすると非常に悩ましい。 とはいえ、個人的に分析クラス図は頭のなかで思い浮かびやすいUMLであり、これからもお世話になるはずなので、まずはUCP法の生産性係数はいくつが望ましいのか、周りからデータ収集を地道にがんばるしかないか。 ■参考 ■オブジェクト倶楽部 http://www.objectclub.jp/ ■ITpro http://itpro.nikkeibp.co.jp/article/COLUMN/20060811/245759/
続きを読む

COCOMO（工数と工期）

COCOMO自体はプログラムステップから工数を出す見積もり手法だが、COCOMOには工数から工期を算出する計算式があるので、そいつについて。 式は 工期（月）＝α×（工数（人月）の３乗根） だそうな。 なお、このの工数と工期はプロジェクト全体（要件定義からシステムテストまで）が入るので注意。 この式のαについては「日本情報システムユーザ協会（JUAS）」が収集・計測したところ、「2.7」が妥当らしい。 本来、αの部分は「プロジェクトのメンバの能力による適当な係数」と「正規分布を想定した時間経過ごとの要員割り当て」をもとに割り出という手順になっている。 （要員割り当てはαだけではなく式全体に影響がある、と思う） とはいえ、JUASでは実際のプロジェクトをいくつも収集したというのだから、「2.7」は日本のプロジェクトには使ってもよいと思う。 αを2.7としたときの各人月に対する工期は以下のとおり。 1人月　2.7ヶ月 2人月　約3.4ヵ月 5人月　約4.6ヶ月 10人月　約5.8ヶ月 20人月　約7.3ヶ月 50人月　約9.9ヶ月 100人月　約12.5ヶ月 うーむ、工程が要件定義からシステムテストまで入ってると・・・。 10人月以下あたりはちょっと長い印象。 20人月以上になるとこれくらいで適当かなぁという印象。 思うに10人月以下の場合は一人が担当する範囲が広い（プログラム設計者が実装もして、単体テストもして、結合テストもしてetc）な場合が多い、というか実際自分のところではそうなので、感覚と違うのだと思われる。 要員が少なければ各工程ごとの要員割り当てが正規分布どころか、一直線になるんだからこの式に当てはめるて違和感がでるのは、納得感あり。 うーん、大きな工数になることがない限り使う機会が少ない、かな？ ■参考 ThinkIT 日本情報システムユーザ協会
続きを読む

seleniumをmacで使いたいメモ１

macを手に入れたのでそのメモ。 １）firefoxでのIDE動作確認 試そうとした目的のサイトでcaptureEntirePageScreenshotをすると上手くキャプチャがとれない。 CSSの関係だと思われるがサイトの上部しかキャプチャされずに、メイン部分となる中央、下部がキャプチャされない。 WindowsXPのfirefoxでも同様の事象は確認しており、JavaScriptのuser-extentions.jsを用意して、もとのcaptureEntirePageScreenshotを改造したコマンドを作ったのであとで試してみよう。 ２）pngデータの出力パス設定 captureEntirePageScreenshotの第２引数はフルパスで書く。一応備忘のため記載。 ３）safariでの画面ハードコピー保管 safariでの画面ハードコピー保管ができる方法は無いのだろうか…？ captureEntirePageScreenshotはfurefixのchromeモードとIEのHTAモードでしか動作しないとIDEでのコマンドリファレンスには記載がある。 とはいえ、画面HCが無いと認めてくれない世界もあるわけで。 たしかevalとかいう関数でselenium実行中にすきなJavaScriptを呼び出せるとか書いてあったような気がするので調べみるか…。 ここが一番のKOファクターになりそうだ…。 ４）seleniumIDEでテストケース作成→safariでの実行 safariはデフォルトでポップアップウィンドウが開かない設定になっているので、それをOFFにする。 ウィンドウは開くようになったが、実行すると java.lang.NullPointerException: sessionId should not be null; has this session been started yet? at org.openqa.selenium.server.FrameGroupCommandQueueSet.getQueueSet(FrameGroupCommandQueueSet.java:216) at org.openqa.selenium.server.SeleniumDriverResourceHandler.handleBrowserResponse(
続きを読む