JBoss EAPがコミュニティダウンロードに追加されました - nekop's blog
JBoss EAPのバイナリはRed Hatカスタマーポータルで提供されてきましたが、JBoss EAP 6.1.0からはJBoss.orgのコミュニティページからもダウンロード可能になりました。 EAPバイナリのダウンロードは以前のカスタマーポータルでもユーザ登録さえすれば試用ダウンロードは自由に可能でした。今回のコミュニティダウンロードによって、このRed Hatサイトへのユーザ登録も必要なくなりました。 http://www.jboss.org/jbossas/downloads JBoss EAP 6.1.0の最初のバージョンであるJBoss EAP 6.1.0.Alpha1が公開されています。これはAS 7.2系の最新バイナリです。 より詳しい情報はFAQを参照してください。
JBoss AS7のロギング事情 - nekop's blog
JBoss Advent Calendar 2012の3日目のエントリです。 ログというのはディスクなどのハードウェアリソースを使うものなので、基本的にデータベースコネクションやスレッド数などと同じように、ミドルウェアリソースに位置づけられ、アプリケーションサーバで一括管理できるようになっています。 と言いたいところですが、現実的にはLog4j, commons-logging, JUL(java.util.logging), SLF4J, Logbackなどログライブラリは乱立しており、各アプリでは異なるログライブラリが利用され、ログ出力設定もバラバラになされていて実際には一元管理するのはすごく大変でカオスな状態です。 JBoss ASは6までLog4jをログ実装として利用していましたが、AS7ではJBoss LogManagerというJULをベースとした実装に変更されました。これに伴い
テクニカルサポートというお仕事 - nekop's blog
tstalk Vol.1というテクニカルサポートのトークイベントに行ってきていろいろお話したり聞いたり考える機会になったので書き出しておくよ。いろいろなテクニカルサポートな人が集まっておもしろかった。ソフトウェア製品サポート、ハードウェア製品やそのファームのサポート、非サポート(興味がある、昔やっていた、サポートを利用するお客様の立場だけど、というような方々)、その他、みたいなごちゃまぜ編成。 ランダム箇条書きな感じで。 テクニカルサポートは楽しい テクニカルサポートはケーキバイキングみたいなお仕事 基本的に扱う内容はエンジニアであるお客様がつまずいた「技術的に難しいところだけ」おいしいとこどり食べ放題 「サポート」を「エンジニアリング」する、多くの改善余地のある創造的な作業が多め 例えばプログラマ関連だと、WebとDBとの橋渡しをするだけのコード書きや(デザインなどの創造的な作業ではない
JBoss AS7 はじめの一歩 - nekop's blog
自分がやっているセットアップを淡々と記録していきます。webプロファイル版じゃなく全部入り版を使ってます。 まずは展開してデフォルト状態をバックアップ。バックアップにはgitとか使ってもいいかもしれないけど、とりあえずベタに行きます。 mkdir -p ~/usr/local cd ~/usr/local unzip ~/Downloads/jboss-as-7.0.0.Final.zip ln -s ~/usr/local/jboss-as-7.0.0.Final ~/jboss7 cd ~/jboss7 cp -a bin .bin cp -a standalone .standalone cp -a domain .domain 基本的に利用するものは"standalone"と付いているほうです。"domain"と名前が付いているモノは複数のJBoss ASサーバを扱う仕組みであり、
TomcatではなくJBossを選ぶ○○の理由 - nekop's blog
java-ja忘年会でharu860さんに聞かれたのでエントリを書くよ。と思ってざっくり書いて放置していましたすみません。この質問へのよくある回答として「EJBを使うとき」みたいなものがありますが、この回答は多くの場合何の役にも立ちませんね。このような回答をする人はJBossをあまり良く理解していない可能性があります。 というわけで、JBossを使っているユーザがどのようなモチベーションでTomcatではなくJBossを使うのか、もしくは完全にJBossに乗り換えているのか、実例ベースの理由をいくつか紹介しましょう。 機能 Tomcatで提供される機能は基本的にServlet, JSP, JDBC接続プールのみで、他のものは提供されていません。シンプルですが、他のものが必要になったときに、それらをインテグレーションするコストが発生するなど、少し面倒なことになります。 TomcatになくてJ
OutOfMemoryErrorが発生したときにきちんとJavaプロセスを殺す - nekop's blog
OutOfMemoryErrorが発生してもスレッドを異空間に葬るだけでJava VMはそのまま動き続ける場合があるけど、当然ながら状態に一貫性のない状態で動いている可能性があるわけで基本的にはとっとと死んで欲しいわけである。一般的に言うところの「不定」状態。OOMEはErrorであってふつうの例外ではなく、致命的なJava VMエラーを示すものである。OOME発生後にプロセス再起動しないでそのままどうこうしようというのは絶対に避けた方が良い。 例えばJDBCのコネクションオープンしてDBからデータを読み込んでるときにOOMEが起きた場合、JDBCコネクションは大抵オープンしっぱなしで回収はされなかったりする。OOMEではfinallyブロックが呼ばれる保証はない。JDBCコネクションリークくらいならまだ良い方だが、これは全てに当てはまる。A-B-Cといったセットになっている処理は例外など
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
