必要なもの ・JAF http://java.sun.com/products/javabeans/jaf/downloads/index.html ・JavaMail http://java.sun.com/products/javamail/index.jsp (最新版は1.4のようだけど、ここでは1.3.3.01) インストール DLしたファイルを解凍して、WEB-INF/lib の下に 次のファイルを追加します。 activation.jar imap4.jar mailapi.jar pop3.jar smtp.jar あとは、TomcatのWeb管理コンソールから Webアプリをリロードするだけで使えるようになった。 ※今回はまっってしまった点 ・以前 入れていた tomcat/common/lib に 古い mailapi.jar が混入していた。mailapi.jarが複数
[技術資料室] [SMTP] [Java] [J2EE] [java.dev.jp] [developer.jp] JavaMail のお部屋 Last update 2007.1.14 JavaMail(TM) API こんなんや。トップだけ日本語化されてた。めでたい。 雑誌で時々、簡単に触れられているけど、具体的なのがよく分からないので調べてみましたぞと。 何をするものか Javaでメールのクライアント(MUA)らしいことが出来る。SMTPで送信ができる。POP3、IMAPもつかえるらしい。 サーバ(MTA)機能は特に持っていない。 よって、メーリングリストなどをつくる場合は、受信部分についてはPOP等を使用するか、別途つくらなければいけないかもしれない。 インストール J2EEに含まれているものなのでJ2EEで利用する場合はこの設定は不要。Tomcatにも入っている? JavaBea
Jakarta Commons の HttpClient で日本語のフォームを渡す (2) Jakarta Commons の話。 post するときの文字コードの指定方法。 HTTP Request header で characterEncoding を指定するには、 次のような手順が必要らしい。 PostMethod method = new PostMethod(uri); method.getParams().setContentCharset(getContentCharset()); // これがないと characterEncoding がセットされない method.setRequestHeader("Content-Type", "text/html; charset=" + getContentCharset()); とりあえずうまく動作しているの
Tomcat 5.5 uses Commons Logging throughout its internal code allowing the developer to choose a logging configuration that suits their needs, e.g java.util.logging or Log4J. Commons Logging provides Tomcat the ability to log hierarchically across various log levels without needing to rely on a particular logging implementation. An important consequence for Tomcat 5.5 is that the <Logger> element f
無事JDK5.0もインストール出来たので、お次は一番の目的であるTomcatのインストールです! (`・ω・´) 長い道のりだった・・・ (ノ__・。) 何はともあれ、Javaの環境変数とか全く設定してなかったのでその設定から。 システム全体に設定を適用したいので # vi /etc/profile で以下の環境変数をexportします。 export JAVA_HOME="/usr/lib/jvm/java-1.5.0-sun" export CLASSPATH=".:$JAVA_HOME/lib/tools.jar:$JAVA_HOME/lib/dt.jar" export CATALINA_OPTS="-Djava.awt.headless=true -Xmx128m" (追記)この設定ならCATALINA_OPTSいらないかも。 そしたら /etc/profile の内容を反映して
現在(2005年10月)のバージョンのTomcatで使用されている"all-to-all"のセッションレプリケーションでは、クラスタグループ内にあるすべてのTomcatが同じセッション情報を共有します。"all-to-all"のセッションレプリケーションの方式はわかりやすい形ではありますが、クラスタグループ内のサーバの台数が多いとセッション間で情報のやり取りが多くなるため、ネットワークのトラフィックが増大してしまいます。 そのため、少ない台数のTomcatで同じセッション情報を共有する"primary-secondary"のセッションレプリケーションが望まれています。"primary-secondary"であれば、セッションレプリケーションされる情報は「プライマリサーバ」と「セカンダリサーバ」の2台の間でのみやり取りされるため、ネットワークにかかる負荷はそれほど大きくなりません(図2)。
Tomcat5のweb.xmlの構文を解析します。 web-app_2_4.xsd (J2EE 1.4) に対応しています。 web-app ルートとなる要素は常にweb-appとなります。 次の属性を持ちます。 version このアプリケーションがサポートするweb.xmlのバージョンを指定します。 web-appの子要素になる要素を以下に記述します。 icon アプリケーションに対応するアイコンを定義します。 これは各種GUIツールで利用されるらしいですが、Tomcatには標準でそういったツールは付いてない(と思う)ので未確認です。 2つの子要素を持ちます。 small-icon 小さいアイコン(16x16)を格納したパスを記述します。 large-icon 大きいアイコン(32x32)を格納したパスを記述します。 display-name アプリケーションの名前を記述します。 管理
Tomcatには、基本認証やダイジェスト認証などの、HTTPによるアクセス認証の機能が組み込まれています。Webアプリケーションに本格的な認証を付けたい場合には、Tomcatのフォーム認証や自前で用意した認証機構などを使う必要がありますが、簡易的にアクセス制限を施したい場合などは、これらのHTTPによる認証で事足りるでしょう。 そのうち基本認証は、簡単なのでよく利用されます。基本認証では、ユーザーが入力したパスワードは、BASE64という方法で符号化されてネットワーク上を流れます。このBASE64符号化は、そもそも暗号化のための方法ではなく、符号化のアルゴリズムを知っているものならば、誰でも簡単に解読できてしまうものです。そのため、認証時の通信を傍受されると、パスワードが簡単に取得されてしまい、基本的に安全ではありません。 通信経路の秘密性を保つには、SSL(Server Socket L
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く