南関東の「いろんなところから富士山が見える」状況に驚きつづけている 大阪から東京に引っ越して30年以上経つが、じわじわと蓄積されてきた驚きがついに閾値を超えたので筆を執った次第である。正確には「ポメラ DM250を起動してmenuキーを押して新規作成を選んだ」のだが、ポメラを持っていなかったら、さらに驚きが蓄積されていないと…
Seasar2.4.xのHOT deployでは、filterやutil、entityといったのようなSMART deploy対象外のクラスから、actionやservice、dao、dtoといったSMART deploy対象のクラスを参照すると、ClassCastExceptionが発生する。この対策を考えてみた。 ちなみに、COOL deployでは発生しない。 2009/4/14 追記 utilやentityがSMART deploy対象外クラスと書いたが、S2Containerにコンポーネントの自動登録がされない(おそらくS2Containerがインスタンスを管理する必要がないから)だけで、コードの変更はHotに反映されるし、クラスローダーもちゃんとHotdeployClassLoaderになる。なので、SMART deploy対象外というのは誤りと思いますので、訂正しました。 原
現時点(Seasar2.4.34まで)のHOT deployでは、HttpSessionを直接使用して、リクエストをまたいでHttpSessionに格納されたオブジェクトを取得してキャストすると、ClassCastExceptionが発生する。 例.XxxAction#indexでセッションにXxxDtoを格納して、XxxAction#index2でセッションから取得する。 public class XxxAction { @Resource protected XxxDto xxxDto; @Execute(validator = false) public String index() { HttpSession session = RequestUtil.getRequest().getSession(); session.setAttribute("xxxDto", xxxDto)
「Hot Deploy」「Hot Deploy」連呼によって、今までで一番長いタイトル。。 気を取り直して本題を。 SeasarのHot Deploy機能はアプリケーションサーバーの再起動不要で修正コードがすぐに反映されるという便利な反面、ちょっとフレームワークの拡張をした時に「Hot Deployでは動くのにCool Deployでは動かない」(またはその逆)といったことにハマることが多いように思います。 S2Container本体やHot Deploy機能の理解が浅いせいもあって、自分も何回泣かされたことか。。。 今回もSAStrutsを使っていて遭遇してしまいました。 Hot Deploy対象外クラス(RequestProcessorやtaglibなど)内で、HotDeploy対象のServiceクラスやDtoクラスをgetComponentするような以下のコードを書くとClassC
メンバーに「Hot Deploy は便利だよねー」と言ったら、「今までと変わらなくないですかぁ?」と返されて焦る。Hot Deploy のおかげで、かなり開発効率が上がっていると思っていただけに、ショック。 しかし、よくよく話を聞いて開発環境を触ってみると、ソース修正後に tomcat が再ロードされている。これ、Hot Deploy できてないから! tomcat の context 設定で、 reloadable="true" になってた。うわー、もったいない!(過ぎ去った時間が) reloadable="false" に書き換えてあげて、使ってもらったら、メンバーの目から鱗が落ちていた。「Hot Deploy は便利なんですね!」という言葉に続いて、今日はいつもよりソースのロールアウト量が増えている気がする。もう少しすれば、気のせいじゃないくらいの効率アップを、肌で感じられそうな気が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く