Jboss 管理パスワードなど (復刻ページ)

Serendiptyブログで比較的アクセス数の多いエントリを復刻しています。
このエントリは2012/08/10のものです。

触っていると色々ハックが必要。 Jbossを立ち上げると管理画面にアクセスするためのパスワードなどの設定が必要になる。

このあたりの設定は

jboss-as\server\default\conf の login-config.xml でアプリケーションごとの設定を行う。

 

サンプルの設定が上記のようになっている。 ここでjmx-consoleに関してpropsディレクトリにusers,rolesのプロパティファイルを置くように指定される。

propsは jboss-as\server\default\props ディレクトリを指しているようで、このディレクトリに既に jmx-console-users.properties jmx-console-roles.properties が存在している。 ファイルの内容はそれぞれ、こんな感じ

jmx-console-roles.properties
# A sample roles.properties file for use with the UsersRolesLoginModule admin=JBossAdmin,HttpInvoker

jmx-console-users.properties
# A sample users.properties file for use with the UsersRolesLoginModule admin=admin

私としてはjmx-consoleに対するパスワードのみを設定したつもりでしたが、Jbossの 管理画面の  Admin Console  JMX Console   JBoss WS Console   Tomcat status がアクセス可能になりました。 共通のログイン設定を使っているのかなにか共通の仕組みを使っているのが現時点では理解できて いません。 JBoss Web Consoleについては同じパスワードが効かないので、別の設定をする必要があるようです。

追記: JBoss Web Consoleに関してはまず、本体側のディレクトリがmanagementの下にありました。

jboss-as\server\default\deploy\management\console-mgr.sar\web-console.war

さらにuserやroleのプロパティファイルはこちらでした。

jboss-as\server\default\deploy\management\console-mgr.sar\web-console.war\WEB-INF\classes

web-console-users.properties web-console-roles.properties

他のアプリケーションもこの仕組みでラップすればログイン管理ができるのかも…. このあたりがJbossがTomcatよりも有利な点の一つかな….

JBoss and Tomcat (復刻ページ)

Serendipityブログで比較的アクセスの多いものを移植しています。
このページは2012/11/06のもの。
さらにコードの部分が正しく表示されていませんでした。

AWSで久しぶりに動き…

といっても自分でWindowsのインスタンスを起動。Linuxと同じくMinimumのものであればAWS新規ユーザは1年間無料とのこと、早速動作させてJbossを動かすところまで行きましたが、Jboss重い重い。Windowsが重いのかも知れませんが、Jbossを動作させていると画面のレスポンスが遅い、遅い。1人でWebからアクセスする限りはその速さは特に問題ありませんが…

さらに気がついたのが、AWSのEC2の課金のIOの数値の上がり方が非常に大きいこと。Linux一台(Apache+Tomcat+Mysql)で一月の数値に今月の5日で到達してしまいました。もしかしたら、Windowsのベースが重いのかも知れませんが、とりあえずJbossは遊ばないときは止めておくことにしました。

Jbossを動かしながら少し学んだこと。JbossはTomcat上で動作していることは知っていましたが、実際どのようにうごいているのか分かりませんでした。ディレクトリの構造は必ずしもこうある必要はないと思いますが、Jbossのアプリケーションの一つとしてTomcatが動いているイメージでした。アプリケーションの階層とは逆のイメージですね。

Jbossのアプリケーションの配置場所は

C:\jboss-epp-5.2\jboss-as\server\default\deploy

という感じですが、この中のjbossweb.sarがwebサーバのアプリケーション、実態はTomcatのようです。jbossweb.sarディレクトリ内はこんなファイル群があります。

context.xml,jasper-jdt.jar,jbossweb.jar, jboss-web-service-jar, jstl.jar, server.xml

server.xmlの中をのぞくと

なんてのが見えます。Tomcatと同じですね。

 

Drop Box Windowによるファイル転送

RemoteFileTransferに関してサーバ側のWebServiceはなんとか満足できる動作をしていますが、Client側はjavaのコマンドラインアプリケーションで実行しています。これをAmazon Cloudのようなウィンドウズアプリケーションにしてファイルのドラッグ&ドロップで作業できないかトライしてみました。
ネットをいろいろ調べてみるとSwingにはTransferHandlerという仕組みがあるようで、それを自分の実行したい実装をつけてextendsして、それをSwingのオブジェクトにくっつければ何とか動作しました。

まだ、ウィンドウ上のステータス表示やリモート側のリスト表示がありませんが、とりあえず、一区切りとして..

サンプルコード

PCの引っ越しとEclipseの移設

先日のウィルス騒ぎを契機に私のPCのOSをWindows XPからWindows 7にアップグレードすることになりました。ITから代替機が支給され、まず、Win7の代替機にデータを移行して、その後、アップグレードされた旧PCに再度環境を構築することになります。
現時点では代替機のWin7環境で作業しています。
最終的には、再度PCの移行がありますので、あまり、真剣に作業を行っていませんが、今後同様な環境の再構築はあるはずなのでメモしておくのは意味がありそうです。
まず、Eclipse本体自体はディレクトリごと、PCを超えて移動すれば基本的にOKでした。また、各プロジェクトに関してはも、XPでは\Document and Users…というようなディレクトリが\Users…というディレクトリに変わったことくらいで、こちらもWorkspaceのディレクトリごとコピーすることで問題ありませんでした。
比較的戸惑ったのが、Javaのruntime environmentの設定とTomcatなどのサーバ設定。TomcatはEclipse内部のpluginで動作するようですが、JbossとかGlassFishは別途インストールしたアプリケーションをEclipse内部の設定で起動する必要があります。
事前に以前のPC上のJREのインストールが以前のPCと同様に設定できていれば、このあたりもスムーズに移行できるのだと思いますが、私の場合はそのあたりが不完全でしたので、ちょっと手間取りました。
むしろ、Eclipse上のServer設定を一旦削除して、JREの設定を修正しながら、Serverも再作成する方がスムーズな気がしました。また、JREを一旦削除するとTomcatなどのサーバ再度の開発環境からServer用のライブラリがBuild Pathから消えてしまいますので再度設定する必要があります。
このあたりのポイントを若干メモしておくと、
Serverについて
Windows –> Show View —> Others —> Servers    サーバタブが表示される。
Server tabで右クリック–> New –> Server でTomcat, GlassFish, Jbossなどを作成する。
Java Run Time Environemtについて
Windows –> Preference –> Java (Expandして)–>Install JREs
ここでAddやEditでJREの設定を実行します。私の今の環境例です。

さらにServerごとのRuntime Enviromentは
同じく
Windows –> Preference –> Server (Expandして)–>Runtime Environment
ここでそれぞれのサーバに関してはRuntime Environment などの設定をします。
Tomcatの場合には必要であればサーバ自体をEclipse内部にダウンロード、インストールできますし、JbossやGlassFishの場合にはインストールしたディレクトリへのパスを指定します。

Tomcatの例:

Jbossの例:

MySQLの移行ができていないのでDBアクセスあたりはまだ動きません。
MySQLのVersionが開発環境のPCと商用環境のLinuxで異なるのでたぶん、ファイルベースでの移行はできませんので、テーブル形式をコピーしてそのうえでデータを移行するような流れになるとは考えています。

Jboss Hibernate上でのKeep Alive

先日の、Jboss上のHibernateがMySQLにアクセスできなくなるという話。
Jboss上のDBにアクセスできない
一つの解決方法として、Keep Aliveを組み込んでみました。
Jboss上にServletを作成し、起動時での自動起動及び、Threadの無限ループで30分ごとにサーチを掛けるだけの物です。このKeep Aliveを導入するまでは毎日朝、サーバにアクセスしようとするとHibernateがMySQLにアクセスできない現象が発生していましたが、このKeep Aliveを組み込んでからはその現象は解消しました。サーブレット内のコードはこんな感じです。

public class KeepAlive extends HttpServlet {
 private static final long serialVersionUID = 1L;
 static KeepAliveMain t = null;

    public KeepAlive() {
        super();
    }

  public void init(ServletConfig config) throws ServletException {
  t = new KeepAliveMain();
  t.start();
 }

 }
class KeepAliveMain extends Thread{

 public KeepAliveMain() {
  // TODO Auto-generated constructor stub
  super();
 }
 public void run(){
  Logger logger = Logger.getLogger(“mylog”);
  Date d = new Date();
  logger.warn(“”+d+”: “+this.getClass().getName()+” KeepAliveMain(service) started”);
  for (int i=0;;i++){
   d = new Date();
   logger.warn(“”+d+”: KeepAliveMain(service):”+i);
         YearDao yearDao = new YearDao();;
      List<Year> yearList = null;
   yearList = yearDao.searchAll();
   yearList.isEmpty();
   try {
    Thread.sleep(30*60*1000);
   } catch (Exception e){
    e.printStackTrace();
   }
  }
 }
}

GetやPostは実装しないで、init()だけで、localのThreadクラスに起動をかけているだけです。

自分のHackとしてはこれでもいいのですが、平行してネットで現象を調べていくと要は、Hibernateにデフォルトで付属しているコネクションプールは試験的なのもで長時間未使用状態が続くとMySQL(DB)側でコネクションを切断してしまうのにたいして、Hibernate側ではまだコネクションが残っていると考えて問題が発生するようです。
また、Jbossのログにはこんなメッセージが出ています。

09:26:48,260 INFO  [DriverManagerConnectionProvider] Using Hibernate built-in co
nnection pool (not for production use!)

Hibernateを使うのであればコネクションプールはThirdPartyのものを使えということのようです。Hibernateのマニュアルにもそのあたりの記述がありました。
次はこのコネクションプールの設定方法が調査項目になります。

JBossでのパスワード設定

基本的にはTomcatと同じ仕組みのようですが触るファイルが異なるのでメモしておきます。
まずはJboss全体レベルとして触るのが以下のファイルです。ここで、このファイルにuserやroleを指定します。
….jboss-epp-5.2/jboss-as/server/default/conf/login-config.xml
私が追加した例はこんな感じ、
  <application-policy name=”MyJbossWebService”>
    <authentication>
      <login-module code=”org.jboss.security.auth.spi.UsersRolesLoginModule”
        flag=”required”>
        <module-option name=”usersProperties”>props/ws-users.properties</module-option>
        <module-option name=”rolesProperties”>props/ws-roles.properties</module-option>
      </login-module>
    </authentication>
  </application-policy>
ここで実際のuser名やrole名は実はprop配下の対応ファイルにこんな感じで設定

# cat ws-users.properties
# A sample users.properties file for use with the UsersRolesLoginModule
admin=testpassword
# cat ws-roles.properties
# A sample roles.properties file for use with the UsersRolesLoginModule
admin=client

次にそれぞれのアプリケーションに付属するファイルは以下の二つです。
WEB-INF/jboss-web.xml
WEB-INF/web.xml

jboss-web.xmlはTomcatにはありませんが、セキュリティ部分を宣言するだけのようです。

<?xml version=”1.0″ encoding=”ISO-8859-1″?>
<!DOCTYPE jboss-web
    PUBLIC “-//JBoss//DTD Web Application 2.3V2//EN”
    “http://www.jboss.org/j2ee/dtd/jboss-web_3_2.dtd“>
<jboss-web>
  <!– A security domain that restricts access –>
  <security-domain>java:/jaas/MyJbossWebServiceClient</security-domain>
</jboss-web>

web.xmlに関してはTomcatと同じような設定が必要です。

  <security-constraint>
    <web-resource-collection>
      <web-resource-name>
        MyJbossWebServcieClient
      </web-resource-name>
      <url-pattern>/RemoteHourly</url-pattern>
      <url-pattern>/RemoteTemp</url-pattern>
      <url-pattern>/RemoteYear</url-pattern>
    </web-resource-collection>
    <auth-constraint>
      <role-name>client</role-name>
    </auth-constraint>
  </security-constraint>
  <login-config>
    <auth-method>BASIC</auth-method>
    <realm-name>UserDatabaseRealm</realm-name>
  </login-config>
  <security-role>
   <role-name>client</role-name>
  </security-role>