java.util.loggingの闇 - nekop's blog
Javaの1.4からjava.util.logging(以下JULと表記)というロギングパッケージが標準で使えるようになって、ログ出力のためにlog4jなどのサードパーティライブラリをいちいち導入したりする必要がなくなりみんな幸せになりました。 と言いたいところですこいつが超不便なAPIをしていてとてもとてもとっっっても使い辛い。ふざけんな。 まずさらっと使ってみましょう。Java 7です。 Logger.getGlobal().info("log") Logger.getLogger("foo").info("log") 出力はこうなります。 Jan 15, 2015 5:11:41 PM JUL main INFO: log Jan 15, 2015 5:11:41 PM JUL main INFO: log はい、キモイですね。軽くつっこむと なんで2行なんだよ 日時AM/PM表記か
Java 7 CMS GCの基本的な情報の整理 - nekop's blog
バッチ処理などスループット重視のアプリケーションはデフォルトのパラレルGCで良いが、Java EEアプリケーションサーバなどレスポンスタイム重視のものやHadoopなどのクラスタ系ソフトウェアで死活監視に引っ掛る系などのstop the worldをなるべく避けたいいわゆるサーバ系ソフトウェアを運用する場合には、UseConcMarkSweepGCを付与して停止時間の短いCMS GCを使う。その場合にCMSのチューニングに踏み込もうとするとなんだか難しい記述がいっぱいで若干困るので、簡単なガイドをメモとして書いておく。 対象バージョンは以下。 $ java -version java version "1.7.0_51" OpenJDK Runtime Environment (fedora-2.4.5.1.fc20-x86_64 u51-b31) OpenJDK 64-Bit Serve
EJBとは - nekop's blog
世に出ているEJBの説明はクソみたいなものが多く、簡潔に機能や特徴を記述しているものが見当たらないので書きました。Java EE 6, 7を対象として書いています。 EJBというのはJava EEアプリケーションサーバ上で利用できるJavaのコンポーネントです。トランザクション制御などの煩雑な部分をEJBが自動的に面倒を見てくれるので、開発者はEJBの基本的なルールを抑えたあとはビジネスロジックの記述に集中することができる、というものです。EJBには4種類あります。 基本となるステートレスセッションビーン (Stateless Session Bean, SLSB) 状態を保持できるステートフルセッションビーン (Stateful Session Bean, SFSB) 単一インスタンスのシングルトンセッションビーン (Singleton Session Bean, SSB) メッセージ(
独自機能とポータビリティのジレンマ - nekop's blog
JBoss / WildFly (全部俺) Advent Calendar 2013の18日目です。 Tomcat, Jetty, WildFly, GlassFish, Resin, WebSphere, WebLogic, Cosminexus, Interstage, WebOTXなどいろいろなJavaアプリケーションサーバがありますが、仕様に準拠するための機能の他に、それぞれ独自の機能を持っていたりします。JBossでも昨日紹介したsarのような独自の機能があります。 独自の機能を考えたときに、常につきまとうのがポータビリティの問題です。不用意な独自機能はポータビリティを阻害しますし、JBossはオープンソースでありポータビリティマターな信条の人が多いので当然これを嫌います。 他のアプリケーションサーバの独自機能の流量制御に依存している、デプロイメント機能にロックインされていて移行
テクニカルサポートというお仕事 - nekop's blog
tstalk Vol.1というテクニカルサポートのトークイベントに行ってきていろいろお話したり聞いたり考える機会になったので書き出しておくよ。いろいろなテクニカルサポートな人が集まっておもしろかった。ソフトウェア製品サポート、ハードウェア製品やそのファームのサポート、非サポート(興味がある、昔やっていた、サポートを利用するお客様の立場だけど、というような方々)、その他、みたいなごちゃまぜ編成。 ランダム箇条書きな感じで。 テクニカルサポートは楽しい テクニカルサポートはケーキバイキングみたいなお仕事 基本的に扱う内容はエンジニアであるお客様がつまずいた「技術的に難しいところだけ」おいしいとこどり食べ放題 「サポート」を「エンジニアリング」する、多くの改善余地のある創造的な作業が多め 例えばプログラマ関連だと、WebとDBとの橋渡しをするだけのコード書きや(デザインなどの創造的な作業ではない
BoxGrinderで遊ぶ - nekop's blog
新しいバーチャルマシンをGUIベースでセットアップする刺身たんぽぽ作業がいい加減飽きてきたのと、Amazon EC2なんかも使うことがあるのでその辺の手間を自動化したいですよね。 ということでBoxGrinder使います。Fedora 15ではyumで一発インストール。 sudo yum install rubygems-boxgrinder-build -y ふつうにgem install boxgrinder-buildでもインストールできますが、その場合gemの範囲外の依存などは自分でインストールしなければならないので、ドキュメントなど参照してがんばることになります。yumでのインストールのほうが楽です。 実行するときは適当なディレクトリ掘ってrootで。 mkdir -p ~/boxgrinder cd ~/boxgrinder vi empty-f15.appl sudo box
Fedora 14でOpenJDKをビルドする - nekop's blog
さて、第1回JVMソースコードリーディングの会(OpenJDK6)もあることですし、OpenJDKのソースに手を入れたりコンパイルオプションとか変えてビルドしたいなぁ、とか思いますよね。というわけで一つOpenJDKビルド用サンドボックスとなるFedora 14環境を用意してOpenJDK 6をビルドしてみましょう。 Fedora 14が無い人はFedoraのサイトからLive isoイメージダウンロードして(torrentが利用できる人はtorrent使った方がダウンロード早いです)、仮想環境とか一個作って入れれば良いです。仮想環境では1.2GBほどのメモリと20GBほどのディスクを用意してください。インストールしたらsu -してvisudoで自分のユーザからsudoを発行できるようにしましょう。サンドボックス環境なのでNOPASSWD指定で良いと思います。 Fedora 14がインスト
コミュニティ版JBoss ASとエンタープライズ版JBoss EAPの違い - nekop's blog
何が違うのー？って良く聞かれるので少しだけ書いておきます。宣伝っぽくなるのは意図するところではないのでなるべく簡潔に。 簡単に言ってしまえばエンタープライズ版のリリースバイナリはコミュニティ版にさらなるテストを行って修正を積み重ね、より高パフォーマンス＆安定化させたものです。 まず目的ですが、コミュニティ版のJBoss ASは、機能開発がメインです。機能開発の途中に取り込まれたバグ修正などはリリースバージョンに含まれていきますが、バグ修正のみを目的としたメンテナンスアップデートや、セキュリティアップデートのようなリリースは基本的には行われていません。つまり、メジャーバージョンアップリリースのみであり、メンテナンスリリースが行われるかどうかは不定です。よって、コミュニティ版を利用し、かつバグ修正が必要な場合は、自分で修正のバックポートやビルドをすることが前提となります。 エンタープライズ版は
Javaプロジェクトのパッケージ名をざっくり変えたい - nekop's blog
自分のローカルにあるjp.programmersパッケージになっているサンプルコードとかのプロジェクトをcom.redhat.jbossパッケージとかにリネームしてお客様に渡したいなー、というケースがあったのでシェルスクリプト書いた。 #!/bin/sh # Usage: ./repackage.sh org.example com.example.foo FROM_PACKAGE=$1 TO_PACKAGE=$2 find . -type f -not -name '.*' | xargs perl -i~ -pe "s/\Q$1/$2/g" FROM_PACKAGE_DIR=`echo $FROM_PACKAGE | tr . /` TO_PACKAGE_DIR=`echo $TO_PACKAGE | tr . /` mkdir -p src/main/java/$TO_PACKAGE
シェルスクリプトでJBossの起動を待つ - nekop's blog
2パターン書いてみた。 まずは簡易版。ログをチラ見する適当な起動判定。マッチする文字列はJBossのバージョンによって変わるかもしれない。ログしか見てないし判定もすごくゆるいので場合によっては誤動作する可能性があるけど、9割動作すればいいよ的な場合はこっちでも問題ないと思う。 while ! tail -20 $JBOSS_SERVER_LOG | grep ServerImpl | grep 'Started in' > /dev/null; do sleep 1; doneちゃんとJBossのランタイムに問い合わせる版。ループでTwiddle(Javaプロセス)起動してJMX問い合わせするのでちょっともっさりする。 while ! sh twiddle.sh -u username -p password get jboss.system:type=Server Started | g
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GCログを上書きしないためのTips - nekop's blog