geronimo-web.xml

実装

流石に後発のサーバだけある。
と言うか、実は今までAPサーバ依存のDDは使おうと思った事が無かったなぁ…と。


まぁ、そうは言っても、xsdの中身は、たったこんだけ。

<xs:complexType name="web-appType">
    <xs:sequence>
        <xs:group ref="sys:classloader-infoGroup"/>

        <xs:element name="context-root" type="xs:string" minOccurs="0"/>
        <xs:element name="context-priority-classloader" type="xs:boolean" minOccurs="0"/>
        <xs:element name="container-config" type="web:container-configType" minOccurs="0"/>

        <xs:group ref="naming:jndiEnvironmentRefsGroup"/>
        <xs:element ref="naming:message-destination" minOccurs="0" maxOccurs="unbounded"/>

        <xs:sequence minOccurs="0">
            <xs:element name="security-realm-name" type="xs:string"/>
            <xs:element ref="security:security" minOccurs="0"/>
        </xs:sequence>

        <xs:element ref="sys:gbean" minOccurs="0" maxOccurs="unbounded"/>

    </xs:sequence>
    <xs:attribute name="configId" type="xs:string" use="required"/>
    <xs:attribute name="parentId" type="xs:string" use="optional"/>
</xs:complexType>

どこにでもありそうで、まぁ、一番良く使うんじゃないかな、と言うのがコレ。

  • context-root
    • デフォルトだと.warファイルの名前が使われるけど、まぁ、よく使うのは
      /(ルート)にする時かな。
  • context-priority-classloader
    • trueにすると、WEB-INF/libのクラスの方を先に見るようになる感じ。
      commons辺りをガリガリ使ってるとバージョン問題でドハマリは良くあるでなぁ。
      geronimoはApacheだけあってcommonsふんだんに使ってるし。
  • container-config
    • Geronimoは搭載するサーブレットコンテナをTomcatとJettyから選べるのに、
      それらに依存する設定はどうすんのかな？と思ったらコレ。
      この中に、サーブレットコンテナ依存の設定に絡むelementを記述するっぽい。
      とりあえず、geronimo-tomcat-config-1.0.xsdってのと、
      geronimo-jetty-config-1.0.xsdのが用意されてます。
      Resinは対応してくれんのかなぁ…。


naming:の二つは、まぁ、S2を使うなら関係無いかな。JNDI周りの設定だし。
イラナイよ、そんなん。面倒な上に使い勝手もあんま良く無いし。
コードの中に文字列リテラル書いてpullするのはイマイチだと思う今日この頃。


securityなんちゃらってのは、実は使った事がなかったり。
JAASとか、何かうまく使うとかっちょぇぇのかなぁ…と思う事もあるんだけど、
何だか良く分からなくて使ってないのです。


こんな所でGBeanを定義出来る理由が良く分からないけど、
GBean単独でデプロイせんとWebアプリとセットでデプロイする事も出来まっせ、
ってな所だろうか。
使い道は、何かそれなりにありそうなﾖｶｰﾝ。


んで、ここまで、わざと無視してきたコレ。

<xs:group ref="sys:classloader-infoGroup"/>

元の定義から引っ張ってくると、こんな感じ。

<xs:group name="classloader-infoGroup">
    <xs:sequence>
        <xs:element ref="sys:import" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="sys:dependency" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="sys:hidden-classes" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element ref="sys:non-overridable-classes" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
</xs:group>

GBeanが定義出来るから、importやdependencyがあるのかな。
importはちょっと面倒な感じなので、また今度。
dependencyは中々面白い事が書いてある。

"dependency" holds a URI, where the URI identifies an entry in the server's
Repository.  That repository entry will be added to the ClassPath of this module.
Essentially, this module's ClassPath points to that location in the server's
repository, so that entry must be in the repository at runtime for this to work.

This URI must always have a form acceptable to the Repository, which currently
takes Maven-style URIs (groupId/artifactId/version/type).  You can also use the
sub-elements (groupId, type, ...) instead of a full URI.

ここで指定したURIのリソースをクラスパスに追加してくれるんだそーな。
ポイントは、サーバが抱えてるリポジトリから取ってくる事。
多分、デフォルトだと%GERONIMO_HOME%/repositoryの事かな。
んで、MavenっぽくURIで書けるんだと。
つまり、これは両方とも合法って事。

<dependency>
  <groupId>log4j</groupId>
  <artifactId>log4j</artifactId>
  <version>1.2.8</version>
  <type>jar</type>
</dependency>
<dependency>
  <uri>log4j/log4j/1.2.8/jar</uri>
</dependency>

気持ち悪いのは、これの場合、実際のリソースはこんな感じで配置されてる事。

%GERONIMO_HOME%/repository/log4j/jar/log4j-1.2.8.jar

まぁ、Mavenを日常的に使ってりゃ、気にならないのかもしんないけど。
所で、ここで見にいくリポジトリのディレクトリって変えられるんかな…。
明日、調べてみよう。


更に続けて残り。まずは、hidden-classes。

A list of classes which will never be loaded from parent ClassLoaders of this
module.  For example, if Log4J was listed here, the module would never see
Geronimo's copy of Log4J.  If the module provided it's own Log4J JAR it would
use that, otherwise it would not be able to load Log4J at all.

The form of this is a comma-separated list of fully-qualified class names or
prefixes.  Essentially, any class that starts with one of the prefixes listed
here will be treated as hidden.  For example, if you set this value to
"java.util,java.lang" then you would really screw up your application.  :)

まぁ、context-priority-classloaderと機能的には被ってる感じがするんだけど、
こっちの方が、きめ細かく設定出来るって事。
特定のパッケージ名やら、特定のクラス名をカンマ区切りで指定すると、
そいつだけは、自分とこのmoduleに含まれてる.jarファイルから読んでくれるんだなぁ。
ここまで書いておいてアレだけど、使い道あんのか？微妙。
まぁ、何かの拍子に切羽詰まってイカサマが必要になった時に、思い出したら使うかもしれない。


使ってみるとこんな感じ？

<hidden-classes>
  <filter>org.apache.commons.logging.LogFactory</filter>
  <filter>org.apache.commons,org.apache.log4j</filter>
</hidden-classes>

んー、正規表現位使えたらえーんでないかなぁ…。
String[]をforループで回すのと、|で繋いで、
一発ドン！ってのと、どっちがエエかねぇ…って話か。
MultiParentClassLoader弄って投げてみるかなぁ。


ついでだから、non-overridable-classesも。

A list of classes which will only be loaded from parent ClassLodaers of this
module (never from the module's own ClassLoader).  For example, this is used
to prevent a web application from redefining "javax.servlet", so those
classes will *always* be loaded from the server instead of from the web
web application's own ClassPath.

The form of this is a comma-separated list of fully-qualified class names or
prefixes.  Essentially, any class that starts with one of the prefixes listed
here will be treated as hidden.  For example, setting this to
"javax.servlet,javax.ejb" would protect some of the core J2EE classes from
being overridden.

さっきのとは、全く逆。自分トコにあっても上から読む感じ。
気になるのは、context-priority-classloaderと、どっちが優先すんだ？って事だけ。


まぁ、順当に考えれば、context-priority-classloaderは、
自分とこでロードしてみた後に、上位に委譲するか否かを決めてるだけで、
hidden-classesとnon-overridable-classesは、
クラスをロードする際のフィルタ設定だから、後者の方がバッチリ効きまっせって感じかなぁ…。


Geronimoは、色んなライブラリをMavenリポジトリを中心にして統合するのを
前提に作られてるだけあって、ClassLoader周りは結構考えて作られてるなぁ…と言う感じ。