| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 |
久しぶりにJBoss Application Server(以下JBoss)のセットアップをしようと
最新版のJBossを取得(DL)するためJBossサイトを訪れましたが
RedHat的有料化への地ならしが随所に見えました
JBoss有料化が既定路線化の記事を幾度か見ましたが…
時代の流れとはいえとうとう来たか（？）といった感じがします。
私が見た【地ならし】ポイント
・JBossをDLできるサイトが jboss.com ⇒ jboss.org へ
―jboss.comはサポート(ライセンス)を受けている顧客のプロダクトDLのみ
http://www.jboss.com/downloads/index
http://labs.jboss.com/projects/download/
・jboss.org がコミュニティーの名前を冠する
―コミュニティーエディション、プロダクトバージョン分離の複線か？？
| 固定リンク | コメント (0) | トラックバック (0)
JSPでリダイレクトをかける前に大きなデータを出力していたところ以下のようなエラーが発生した。
（割と初歩的なエラーのレポートです。）
java.lang.IllegalStateException
at org.apache.catalina.connector.ResponseFacade.sendRedirect(ResponseFacade.java:432)
at org.apache.jsp.tools.melo_jsp._jspService(melo_jsp.java:868)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.valves.FastCommonAccessLogValve.invoke(FastCommonAccessLogValve.java:495)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:199)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:282)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:754)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:684)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:876)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
このエラーが発生したJSPでは以下のような感じで長々と処理前にHTMLのヘッド部分
(JavaScriptでかなり膨大な量)を返していた。
<%@ page contentType="text/html; charset=Shift_JIS" %>
<%@ page import="java.sql.*"%>
<%@ page import="javax.sql.*"%>
<%@ page import="javax.naming.*"%>
<html>
<HEAD>
<BASE target="body">
<META http-equiv="Content-Type" content="text/html; charset=Shift_JIS">
<META name="GENERATOR" content="IBM WebSphere Studio Homepage Builder Version 8.0.0.0 for Windows">
<META http-equiv="Content-Style-Type" content="text/css">
<TITLE></TITLE>
<LINK rel="stylesheet" href="melo-cahx.css" type="text/css">
<script language="JavaScript">
<!--
（中略とても長いJavaScript）
-->
原因はまさにこれ、JSPではある程度の出力がoutに溜まると
responseを自動的に返してしまう。
responseはHTTPのヘッダーとコンテンツ内容になる。
リダイレクトはHTTPのヘッダーで処理を行うからresponseを返し始めた
ＪＳＰでリダイレクトをすることはできない。それでこんなエラーが出てしまう。
今回対策としてはJavaScriotを外部化しリダイレクト指示までに出力する
データ量を抑えることで対処した。
| 固定リンク | コメント (0) | トラックバック (0)
cgiを処理するservletがtomcatシリーズにはおまけでついてきている
（tomcatを内包しているJBossも）
これを利用しようとして http://hogehoge/tomcat/cgi/test.cgi
といったURLでWEBアプリケーションのCGIを設置し
Apache-mod_jk-JBoss(Tomcat)連携で
JkMount /tomcat/cgi/* work
と設定して http://hogehoge/tomcat/cgi/test.cgi にアクセスすると400エラーになる。
mod_jkの設定が無視されてApacheのパス内にファイルがみあたらないから400(not found)というわけだ。
Apacheがmod_jkの設定を無視するのは
AddHandler cgi-script .cgi
↑この設定がmod_jkを打ち消しているから、cgi拡張子をcgi(コモンゲートウェイ…)として扱おうとする。
このぎょうをコメントアウトするなり、Tomcat WEBアプリケーション側のcgi実行の
拡張子を変更するなりしてこの衝突は回避することができる。
| 固定リンク | コメント (0) | トラックバック (0)
雑記メモです以下のようなことがありました。
JBossのHibernateアーカイブ(har)を使用するとデータベースコネクションが
JBoss管理のTransactionに入ります。
同コネクションを使用してINSERTやUTDATEのSQLを直に実行しようとすると
Transactionがでしゃばってきてエラーを返します。そこでHot deployを利用してHibernateアーカイブを削除してみました。
ところがデータベースコネクションはJBoss管理下のTransactionから抜けることがなく
SQLの更新命令はエラーのままです。JBossを再起動すると(当然ですが)データベースコネクションはTransactionから抜けて
SQLは受け入れられるようになりました。
総括ではないですが、あるデータベースに対してJDBC(SQL)直制御＋Hibernate制御
を行う場合JBossのHibernateアーカイブは不適当なようです。
(SQLでリードのみを行う場合干渉は無い、Write系で問題発生)
ちなみにアーカイブにせずにwarアーカイブ内にHibernateの制御ファイルを
埋め込むパターンではこのような干渉行為は起きませんでした。
＊注 この記事の内容は各バージョンでの動作の違いなど細かい検証をしていません。
ご自分の環境で試すことを推奨します。
| 固定リンク | コメント (0) | トラックバック (0)
ひょっとしたらHibernateネタではなくてSQLネタかもしれない。
*注:例は仮想のテーブルhttpのアクセスログを想定しています。
select ip_address,count(*) as access_count from accress_log group by ip_address order by access_count;
上記のようなSQLを想定して
select log.ipAddress,count(log) as accessCount from AccessLog log group by log.ipAddress order by accessCount;
このようなHQLを書いてもHibernateの処理が通らなかった
どうやら別名でのorder by 句が通らないらしい。
自分はこのパターンしか知らなかったがSQLの辞書にて以下の構文を発見。
select ip_address,count(*) as access_count from accress_log group by ip_address order by 2;
要素を列挙する時の出現順番でorder byを指定することができる。
早速HQLに直してみたところ以下のような文で見事パスした。
select log.ipAddress,count(log) as accessCount from AccessLog log group by log.ipAddress order by 2;
赤字HQL 青字SQL
| 固定リンク | コメント (0) | トラックバック (0)
Aug 9 13:46:20 sv named[29336]: dumping master file: /var/named/tmp-XXXXS58pu2: open: permission denied
Aug 9 13:46:20 sv named[29336]: transfer of 'hogehoge.com/IN' from 123.456.789.123#53: failed while receiving responses: permission denied
BINDでスレーブサーバーを設定し更新をかけたら上記のようなエラーが出た
ちなみに環境は
OS : RHEL 3.0 ES
BIND : 9.2.4 (RHELデフォルトインストール)
管理ツール: Webmin
でWebmin経由で普通に設定した場合にこのエラーが出た。
原因はスレーブのデータを保存するディレクトリの書き込み権限が
ユーザーnamedに無いこと。
上記の環境では /var/named に保存しようとする。
解決方法①
/var/named の所有者を root ⇒namedに変更
手っ取り早いけど正攻法ではない。
解決方法②
スレーブのBIND設定が保存されるディレクトリを正しくwebminに設定する
/var/named ⇒ /var/named/slaves 等(フォルダの所有者をnamedにする)
以上
| 固定リンク | コメント (0) | トラックバック (0)
某携帯キャリアから使用するIPアドレスの変更(追加)通知が来た
IPアドレスでアクセスを切り分けたりセキュリティをかけている場合は
これを更新して欲しいというないようだ。
『○○様向け Proxyサーバ 増設のお知らせ』
○○様向けとなっているので一般と内容が違うかもしれない。
影響がある個所の確認をかねて念のため
一般向け技術仕様の公開サイトをチェックしてみた。
『ゲートウェイサーバ IPアドレス一覧』
…
……
………ん！？
『ゲートウェイサーバ』？『Proxyサーバ』とちゃうの？？
こういう似通った技術用語で意図的に言い分ける場合
意味や比較的重要な用途が異なり明確に区別する必要がある事が多い
知らずにバクが発生している可能性もあるのでProxyサーバとゲートウェイサーバーを
どう定義しているのか携帯キャリアのページを詳しく調べることになった。
数時間のリサーチの結果、意味は変らないと分かったりしたわけだが
改めて携帯キャリアS社のクオリティーの低さを感じ愕然とするばかりだorz
| 固定リンク | コメント (0) | トラックバック (0)
最近のコメント