InterceptorでSessionを利用

SAStrutsでAOPを使ってセッションタイムアウトの処理を実装しようとしていた時のこと。

HttpSession session = SingletonS2Container.getComponent( HttpSession.class );

LoginUser loginUser = (LoginUser) session.getAttribute("loginUser");

こんな感じのコードでClassCastExceptionが投げられた。

ちなみにLoginUserクラスは訳あって、

@Component(instance = InstanceType.SESSION)

を使わずに、HttpSession.setAttribute()で直に管理しています。

Sessionの取り方を以下のように変えても駄目でした。

HttpSession session =　 (HttpSession) SingletonS2ContainerFactory.getContainer().getExternalContext().getSession();

以下でも駄目。

Map<String, Object> sessionScope = SingletonS2Container.getComponent("sessionScope");

どうして駄目なんだろうと思って調べてみると、以下の記事が見当たりました。

http://d.hatena.ne.jp/learn/20090318

なるほど。

同一クラスでもクラスローダーが異なれば、違うクラスとして扱われる。

SMART deploy対象外のクラスからSMART deploy対象のクラスを参照していたわけね。

とりあえず理由はわかったので、一時的措置として以下のように対処しておいた。

if (sessionScope.get("loginUser") == null) {

　//セッションタイムアウト時の処理

}

やはり、SMART deploy対象外クラスとして切り分けたほうがいいのかな。

子画面をsubmitして、親画面をリロード

前回、親画面から子画面を出してsubmitする場合を書いたが、

子画面をsubmitして親画面をリロードする場合は、これでOK、か？

JavaScriptね。

function func() {

  var childForm = window.document.forms['formName'];　
  childForm.submit();

  opener.open("parentURL", "_self");

  close();
}

親画面、値を渡さずにリロードするだけなら、これでOK、よね？

submitした結果を子画面に出す

親画面をsubmitして、その結果を子画面に出力するのって、こんなんでよいのだろうか。

JavaScriptね。

以下にかなり簡単に書いてみた。

普段、業務ではコンポーネント化されているものを使うから、自分で書くことがないんだが。

function func(arg1) {

  //画面から取ってきた値をフォームにセットしたり、しなかったり
  //document.forms['formName'].elements['elementName'].value = arg1;

  var form = document.forms['formName'];
  var target = form.target;

  open("../wait.html", target,
      "toolbar = no, location = no, directories = no, status = yes, menubar = no, " +　
      "scrollbars = yes, resizable = yes, width = 500, height = 400");
  
  form.submit();
}

あとは、どこにfocusを持ってくるのかとか、

細かい処理があるかもしれないが、

とりあえずこれでいいのかな。

一応、これに近い感じのコードで動いた。