2010-06-10

grails run-appでGoogle App Engineを起動してみる

前回、永続化APIとしてJPA(Java Persistence API)を選択しました。

で、さっそくgrails run-appです。
app-engineプラグインをインストールすると、フツウにコマンドラインで
grails run-app
を実行しただけで、grailsがのっかった状態で、Google App Engine(以下、GAE)の開発サーバが起動するようになります。
らくちんですね。

ということで、さくっとやってみました。

えー、結論からいうと...ダメでした。
もちろん、イキナリまともに動くとは思ってませんでしたが。
あわよくば、エラーとして「次になにをすべきか」を、イイカンジに喋りはじめてくれるかな...とだけ、期待してました。
まぁ、そういう意味では、たしかに期待通りでした。
で、記念すべき第一声...つまり最初のエラーは、これでした。
C:\Program Files\appengine-java-sdk-1.3.4\config\user\ant-macros.xml:95: java.io.IOException: Cannot run program "C:\Program Files\Java\jdk1.6.0_13\jre\bin\java.exe": CreateProcess error=87, ?????????

はぁ?
GAE SDKに含まれるantマクロが、コマンド実行でおもむろにコケたとおっしゃってます。
たしかに何をすべきか喋ってはくれましたが、まさかしょっぱなからGAE SDK内部をいじれと言われるとは、ちょっと予想外でした。
調べてみると、これはGoogle App EngineのIssueTrackerをはじめ、いろんなところで取り上げられている問題のようです。
エラーに出てるantマクロが、DataNucleusのエンハンサーを起動するときに、エンハンス対象のクラス数(classファイル数)が多くなると、コマンドライン最大長を超えてしまう場合があるということらしいです。
ということは、
  • Groovyは、コンパイルすると、クロージャ1つ1つについて、それぞれclassファイルを生成するので、ただでさえclassファイル数は多くなる
  • Grailsは、ビルド時にdomainクラスとcontrollerクラスを同じフォルダに出力する
ということが相まって、Grailsではこの現象がとくに出やすくなっちゃうのかなと、漠然と考えてみたり。
この現象を回避する、最も手っ取り早い方法は、永続化クラスのクラス名に、適当なサフィックスかなんかを付けるということです。
そしたら、問題のantマクロの、エラーメッセージに出てる行付近にある、fileset要素のinclude属性を変更して、そのサフィックスで対象クラスを絞ることができますね。
これで、コマンドラインに出るクラスの数を制限するわけです。
ちゃんちゃん。
といったかんじでこの問題は解決しましたので、次回、GAEの起動に再挑戦です。

0 件のコメント:

コメントを投稿

Related Posts Plugin for WordPress, Blogger...