DSpaceを設定あるいはカスタマイズする方法はたくさんあります。
/dspace/configの設定ファイルを変更する。これらの方法のうち、最後の方法だけは問題を引き起こすかもしれません。DSpaceのソースコードを直接変更すると、将来のバージョンアップが難しくなるでしょう。 しかしながら、DSpaceはオープンソースですので、他の機関や組織にとっても有益であると思える変更をした際には、もちろん遠慮なくMITのDSpace開発チームに送付してください。
dspace.cfgDSpaceを設定する第1の方法は、dspace.cfgを変更することです。
DSpaceを正しく動かすためには、これは絶対に必要です。
dspace.cfg には、システムのパス情報やネットワークホスト情報、サイト名などDSpaceのインストールについての基本的な情報が含まれています。
デフォルトのdspace.cfgにはすべてのプロパティに説明が付いており、良い情報源となっています。
このファイルは基本的なJavaプロパティファイルであり、各行は、'#'で始まるコメント行、空行、次の形のプロパティと値の組のいずれかです。
プロパティ名 = プロパティ値
時間の制約でこの説明書ではプロパティを網羅的に取り上げることはしません。プロパティはdspace.cfgにすべてリストアップされています。以下では使用にあたって注意の必要なプロパティに限って説明します。
| プロパティ | 値の例 | 説明 |
|---|---|---|
dspace.dir |
/dspace |
DSpaceをインストールしたルートディレクトリ。最後の'/'は除く。
これを変更した場合は、assetstore.dirプロパティなど、他のいくつかのプロパティ値もこれに合わせて変更する必要があることに注意。 |
dspace.url |
http://dspace.myu.eduhttp://dspacetest.myu.edu:8080 |
DSpaceのウェブユーザインターフェースアプリケーションを配備するURL。80以外の場合はポート番号を付ける。ただし、最後の'/'は付けない。 |
dspace.hostname |
dspace.myu.edu |
完全修飾ホスト名。ポート番号は付けない。 |
dspace.name |
DSpace at My University |
簡潔なサイト名称。ウェブユーザインターフェースや電子メール、その他（OAIプロトコルなど）いろいろな場面で使用される。 |
config.template.foo |
/opt/othertool/cfg/foo |
install-configsを実行すると、/dspace/config/templates/foo ファイルにdspace.cfgで設定した値が埋め込まれて、このプロパティの値が示すファイル、この例では、/opt/othertool/cfg/fooにコピーされる。詳細はここを参照のこと。 |
webui.site.authenticator |
edu.myu.MyAuthenticator |
org.dspace.app.webui.SiteAuthenticatorインターフェースを実装したクラスのJavaクラス名。 |
handle.prefix |
1721.1234 |
運営サイトのハンドルプレフィックス。ハンドルサーバの設定の節を参照のこと。 |
assetstore.dir |
/bigdisk/store |
情報資産（ビットストリーム）格納番号0のファイルシステム上の配置場所。 DSpace専用のディレクトリであることが望ましい。 |
assetstore.dir.n |
/anotherdisk/store1 |
情報資産（ビットストリーム）格納番号nのファイルシステム上の配置場所。
格納場所を増やす際は、1（assetstore.dir.1）から始めてカウントアップする。
ただし、情報資産格納番号0は、つねにそのまま（assetstore.dir）にしておく。
詳細については、ビットストリームの保存の節を参照のこと。 |
assetstore.incoming |
1 |
新規のビットストームを格納する情報資産格納番号。
たとえば、assetstore.dir.1 が /anotherdisk/store1で、assetstore.incoming が 1 の場合、新規のビットストリームは /anotherdisk/store1 に格納される。
値が 0 の場合は、assetstore.dir のディレクトリに格納される。詳細については、ビットストリームの保存の節を参照のこと。 |
dspace.cfgを変更したら、必ず、/dspace/bin/install-configs を実行します。
そうしないと、変更した内容が、他のアプリケーション（たとえばApache）用の設定ファイルに反映しません。
変更の内容によっては、対象となるアプリケーションの再立ち上げが必要な場合もあります。
DSpaceはユーザに自動的に電子メール通知を送る場合があります。たとえば、新規ワークフロータスクの通知や新規アイテム通知サービスなどです。
電子メールの通知文の内容は、/dspace/config/emailsにある該当するファイルを編集することで変更することができます。
各ファイルの説明はファイル中に書かれています。「プレースホルダ」の番号（たとえば、{2}）を間違えないよう気をつけてください。
/dspace/config/registriesディレクトリには2つのXMLファイルがあります。
これらは、ダブリンコアタイプ・レジストリとビットストリームフォーマット・レジストリの初期値をロードするために使用されます。
いったん初期値がロードされる（ant fresh_installコマンドで実行されます）と、レジストリはデータベースに保管されます。以後、XMLファイルは更新されません。
現在のところ、システムはすべてのアイテムがダブリンコアレコードを持つことを必須としています。使用するダブリンコアの要素と限定子は、ダブリンコア・レジストリを編集することで設定できます。
その方法は2通りあります。1つは、インストール時に、/dspace/config/registries/dublin-core-types.xmlを編集する方法で、もう1つは実行時に管理用画面を使って変更する方法です。
ただし、DSpaceの機能を正しく動かすために、いくつかの要素と限定子は必ず持たなければならないことに注意してください。これらはプログラム上でさまざまな目的で使用されているからです。
詳細については、該当する.xmlファイルを参照してください。
システムが認識するビットストリームフォーマットとそのサポートレベルがビットストリームフォーマット・レジスタに格納されます。
これも、インストール時に/dspace/config/registries/bitstream-formats.xmlを編集するか、管理用画面で設定することができます。
ビットストリームフォーマット・レジストリの内容はまったく自由ですが、少なくとも次の2つのファーマットを持つことがシステム上必要です。
UnknownLicenseDSpaceと連動して稼働させるアプリケーション（たとえば、Apache）の設定ファイルの管理を容易にするために、DSpaceシステムでは、DSpace設定ファイルを変更した際に、これらの設定ファイルを自動的に更新することができます。 DSpaceのこの機能の使用はまったく任意ですが、便利だと思います。
これは次のように行ないます。まず、アプリケーション用の設定ファイルを/dspace/config/templatesに置きます。ファイルには特別な値を埋めこみ、適当なDSpace設定プロパティ値で置き換えられるようにします。
次に、dspace.cfgに適当なプロパティを追加して、変換後の正式な設定ファイルを置く場所をDSpaceに知らせます。そして、/dspace/bin/install-configs を実行します。
例として、apache13.confファイルを取りあげます。
このファイルには多くのApache独自の設定が書かれていますが、DSpaceやその他のアプリケーションと連動した値を持つ必要がある部分には、「プレースホルダ」が使われています。たとえば、ホスト名は次のようになっています。
ServerName @@dspace.hostname@@
@@dspace.hostname@@には、 dspace.cfgのdspace.hostname プロパティの値が埋め込まれます。次に、ライブバージョン、すなわち、Apacheの立ち上げ時に実際に読みこまれるファイルを置く場所を決めます。
このファイルを /opt/apache/conf/dspace-httpd.confに置きたいとします。そのためには、以下のプロパティを dspace.cfg に追加します。これでDSpaceはファイルを置く場所を知ることができます。
config.template.apache13.conf = /opt/apache/conf/dspace-httpd.conf
次に、/dspace/bin/install-configsを実行します。
このプログラムは、/dspace/config/templates/apache13.confを読み込み、プレースホルダに値を埋めこんで、/opt/apache/conf/dspace-httpd.conf にコピーします。
/opt/apache/conf/dspace-httpd.confには、次のような行が含まれています。
ServerName dspace.myu.edu
この方法の利点は、ホスト名のようなプロパティが変更された場合、dspace.cfgを変更してinstall-configsを実行するだけで、必要な設定ファイルをすべて変更できる点にあります。
ただし、/dspace/config/templatesにあるファイルの変更にはくれぐれも注意してください。
各ファイルの先頭に大きな注意文を置くことはいい考えです。後で上書きされてしまうライブバージョンの設定ファイルを誰かがうっかりと修正しないようにするためです。
ウェブユーザインターフェースはビジネスロジックを処理するJavaサーブレットとエンドユーザに送るHTMLページを作成するJavaServer Pages（JSP）を使って実装されています。 JSPはJavaプログラムよりはるかにHTMLに似ていますので、DSpaceのルックアンドフィールを変更することは比較的容易です。
ことを簡単にするために、DSpaceではソースディストリビューションにあるJSPを、変更して別の場所に保存したファイルで「置き換える」ことができます。 これにより、DSpaceを新規リリース版にバージョンアップしても、ローカルで変更したファイルが上書きされることはありません。
JSPは /dspace/jsp にあります。変更したJSPは /dspace/jsp/local ディレクトリ配下にオリジナルと同じパスを作成して保存してください。
/dspace/jsp/local配下にJSPファイルがあると、/dspace/jspにあるオリジナル版の代わりに使用されます。
たとえば、以下のように修正版を配置します。
| DSpaceのオリジナル版 | ローカル修正版 |
|---|---|
/dspace/jsp/community-list.jsp |
/dspace/jsp/local/community-list.jsp |
/dspace/jsp/mydspace/main.jsp |
/dspace/jsp/local/mydspace/main.jsp |
/dspace/jsp/styles.css.jspにあるスタイルシートが多くのファイルで使用されています。
このファイルを修正した場合は、/dspace/jsp/local/styles.css.jspに保存してください。上で述べたように、システムはオリジナルの代わりに自動的にこのファイルを使用します。
なお、ループしないように修正版のスタイルシートでは、localVersionに関する部分を忘れずに削除してください。
フォントと色はスタイルシートを使って簡単に変更することができます。 スタイルシートはJSPで書かれていますので、ユーザのブラウザのバージョンを知ることができ、これに合わせてスタイルを調整することができます。
各ページの「レイアウト」、すなわち、ヘッダ、フッタとナビゲーションバーは、/dspace/jsp/layout/header-*.jsp と /dspace/jsp/layout/footer-*.jspで作成しています。
これを変更する（/dspace/jsp/local/layoutディレクトリに置きます）こともできますし、さらに別のスタイルを作成してdspace:layoutタグの"style"属性に指定してページに適用することもできます。
多くの機関や組織は独自のユーザ認証システムを持っていますので、DSpaceはこれらを容易に統合できるように設計されています。
これを実現するには、Javaインターフェース org.dspace.app.webui.SiteAuthenticator を実装するカスタムクラスを用意します。
このインターフェースで定義されているメソッドは、ウェブユーザインターフェースにおいてユーザ認証関係のイベントが生ずるたびに呼び出されます。
DSpaceのウェブユーザインターフェースにおける基本的なユーザ認証手順は以下のとおりです。
SiteAuthenticator実装クラスのstartAuthentication メソッドが呼び出される。startAuthenticationが何らかの形ですぐにユーザを認証するか、何らかのログインページにリクエストを転送する。
オリジナルリクエストのパラメタは安全に保存されており、ログインプロセスの終了後に取り出すことが可能である。各メソッドについては、SiteAuthenticator.java のソースファイルを参照してください。
デフォルトの実装である org.dspace.app.webui.SimpleAuthenticator は以下のポリシーを実装する簡単な実装プログラムです。
電子メールアドレスとパスワードを使ったログインを使用する。これは、権限を必要とするアクションを求めるリクエストをパスワードログインサーブレット /password-login に転送することで実現している。
パスワードログインサーブレット（org.dspace.app.webui.servlet.PasswordServlet）は、上で述べたステップ3の方法でユーザ認証を行い、成功した場合にオリジナルリクエストを再開するプログラムを含んでいる。
ユーザは自分で登録する（すなわち、管理者による承諾なしに自身をe-パーソンとして追加する）ことができ、同時にパスワードも設定することができる。
ユーザはどの（動的な）スペシャルグループのメンパーでもない。
ソースツリーには、私たちがMITで使用しているSiteAuthenticatorの実装である edu.mit.dspace.MITAuthenticator が含まれています。これは次のように、若干複雑なユーザ認証メカニズムを実装しています。
認証されるユーザがMITのユーザの場合、ユーザはX509ウェブ証明書を使ってログインしなければならない。
password-loginサーブレット同様、certificate-login サーブレットがこの証明書を使ってユーザを認証し、成功するとパスワードログインサーブレットがしたように、オリジナルリクエストを再開する。
また、MITユーザは自動的に（システムに存在するに違いない）「MITユーザ」という（動的な）スペシャルグループに追加される。 これにより、MITユーザに関する権限ポリシーが作成され、MITユーザグループを手作業で管理する必要がない。
誰でも自分を登録することができるが、MITユーザはパスワードを設定することができない。MITユーザはログインにはX509ウェブ証明書を使用しなければならないからである。
X509証明書ログインサーブレットは、webui.cert.autoregister プロパティがtrue の場合にユーザをシステムに自動的に登録するという、特別な機能を持っています。
同様な処理をするようにパスワードログインサーブレットを変更できるでしょう。
たとえば、Windows NTのドメイン認証を使用しているとしたら、Windows NT認証を実行して、新規ユーザとしてe-パーソンを自動的に追加する PasswordServlet.java を実装すればよいでしょう。
この場合、オリジナルのPasswordServletを直接変更せずに、新しいサーブレットを作成することを強く勧めます。そうすれば、将来DSpaceがバージョンアップしてもプログラムが上書きされることがないからです。
なお、同時に、startAuthenticationメソッドが新しいサーブレットにリクエストを転送するようにSiteAuthenticatorを実装する必要もあります。