目次へ

Sun ONEって何だ!

ある日Forteの新しいのをダウンロードしようとSunのサイトに行ったらForteが見つからない。と思ったらSun ONE Studioという名前になっていた。どうやらJ2EEもXMLも全部Sun ONEという新しい構想の下にまとめられたらしい。だがそれは一体何なのか?
思わず本屋で「Sun ONE完全解説((株)アスキー発行)」を買ってしまった。まだほとんど読んでないがそれはそれとして,Sun ONEナントカという名前で使えるアプリケーションやサービスを自分なりに使ってみることによりSun ONE構想というものを自分なりに理解しようと試みることにした。理解したらどうするのか,それはその〜。積み上げ方式です。

/天国か地獄か、パチロク版Sun ONE Studio5/今更のようにコンテキストルート/さらばSun ONE Studio CE。でも・・・/Sun ONE StudioだとWebServiceも簡単?/Sun ONEで初めてのCMP/EJBのコードも変わったのか?/ひとつ不思議な話:MySQLのアクセス問題/避けては通れない(んじゃないかな)DataSource問題/今度こそAppServer7と連携だ/怪我の功名?Java大工事/晴天の霹靂Studio_5SE!/Enterprise Editionでゴー!/AS:J2EEアプリのハンドデプロイメント!/Application Serverお詫びと訂正/さらに相対パス問題/よそ猫と比べて気がついたリンク問題/よその猫も飼えるんだ!/内部Tomcatを飼い慣らせるのか?/Sun ONE Application Serverの起動と操作/Sun ONE Application Server 7のインストール/WARファイルも作れるぞ!/JSPとServletの連携アプリの実行のさせ方/S1SからNetscape6を立ち上げる/落ち出すと止まらない!?/Pointbaseに接続/変わっただけじゃなくこれはすごすぎる/Forteも変わった!/J2SDK1.4 for Solarisが変わった!/Sun ONE構想に対する苦言/

天国か地獄か、パチロク版Sun ONE Studio5

わたしは最近、NetBeans3.5.1にSolaris-x86版があるのをいいことに、チョッパヤIntelマシンにSol9を載せこれにNetBeansを載せできる限りのカスタマイズを施し、使い倒すことに生き甲斐すら感じていた。そんなときふと、ていうかわたしのブラウザのホームページはサン・ドットコムだからかなり必然的なのだが、Sun ONE Studio5を見に行ったらなんとSolaris-x86版が出ていた!
たぶん血圧150くらいなっていたのではないだろうか。この前見に行ったときはなかった。インストールマニュアルが別に作られていた(Sparc, Win, Linux版用は一緒のpdfだ)ところを見ると、最近後発で出たに違いない。そしてダウンロードファイルは.jar形式だ!もちろんセットアップにはjava -jar コマンドを使う。ピュアJavaかヨ?カッチョ良すぎるぜパチロク版!Bladeでは起動までに腹筋運動とかやってシェイプアップになったSE5だが、2.7Gマシンだったらきっと夢のように速いに違いない。
「か・・・・・・」
禁断の言葉がアタマをよぎる。例の200ダラーディスカウントもまだ有効のようだ。トライアル版のダウンロードに結構時間がかかったのだが、おりしも水曜の夜で今非常に好きなテレビドラマ「相棒」をやっているところだったので気がまぎれた。でなければ待つ間に495ダラーをクリックかサブミットかなんか(怖いので一度も行ってない)してしまっていたかも知れない。
rootでないと起動できないので、rootのためにXサーバのアクセス権をアレンジする方法がインストールマニュアルに書いてあったが、はっきりいってこのSolaris9はわたしのパソコンだ。ゆえに臆面もなくrootでCDEに入ってjava -jar起動した。
たぶんインストールですらだいぶ速いように感じられた。だがここでわたしは一気に地獄に落とされる事実に気づいた。

Sun ONE Application Server 7はSolaris-x86版ってないんだヨ(2003年10月29日現在)

つまり・・・このパチロク版SE5は、Tomcatしか動かせないのだ。虎の檻で猫を飼うようなもの・・・EJBのコンパイルやモジュール作成はできても、テストする環境がない。JBossを導入して手動でデプロイ?いや、いやヨそんなの。最近、わたしもだいぶ妙な意地を張らなくなってきた(これでか)。それだったら最初っからチョッパヤIntelにWindows入れてWin版導入すりゃEJBだろうが.NETだろうが(SE5じゃ無理だって)何の苦労もないじゃん!

だがAS7もないのにSE5のパチロク版を出したSun様、冗談でなさったのではなかった。このSE5にはあの奇っ怪なJava Web Service Develper PackをGUIGUIと使用できるというすばらしい機能が残っていた。Apache AxisのあとにJWSDPをいじってみて何がなんだか全然わからず不満タラタラだったわたしにとっては福音であった。それはWebサービスの記事で詳しく述べたいと思う。

2003年10月15日

ページ先頭に戻る


今更のようにコンテキストルート

Sun ONE Studio(NetBeans)でWebモジュールを扱う場合、コンテキストルートディレクトリをマウントしなければならないので、内部Tomcatでこれにアクセスする場合は

http://localhost:8081/index.jsp

のようなURL指定になってしまう・・・とずっと思っていた。でもこの前気がついた。
エクスプローラの「File Systems」上で該当モジュールの「WEB-INF」アイコンのプロパティに「コンテキストルート」というのがあるのだ。そこにお好きな名前を入れればそれがこんてきすとルートになって、以後

http://localhost:8081/myweb/index.jsp

のようにアクセスできる。

いやまいった。実はEnterprise EditionっていうかSun ONE Studio 5ではすでにやってたことなんだけどね。今頃気づくとは、のにもヤキが回ったって言うか、最初っからヤキ入ってないからいいのか?

2003年10月15日

ページ先頭に戻る


さらばSun ONE Studio CE。でも・・・

そうこうしているうちにSun ONE Studioがバージョンアップすると、無償版はSun ONE ブランドからはずれた。だがそこはさすがSun様、御自身のJ2SEダウンロードサイトに、Netbeansバンドル版を用意してくださっている。
Netbeans IDEの3.5をゲットした。これは最近さんざ遊ばしてもらっているStudio 5の、まあCEにあたるもののようだ。
使ってみると、エディタの補完機能がゲロ良くなっている。
とすれば、これからはもうStudio CEの4をやめて、完全にNetbeans3.5に移行するか・・・と思ったところで、とんだ邪魔が入った。

「Netbeansモジュール開発」という、とんでもないオモチャを見つけたのである。

発端は。最近、またRelaxerでもやろうか、と考えたことによる。
Sun ONE Studioからrelaxerコマンドをかませたら、とても便利だろうと思ったのだ。
だが、Sun ONE Studioで「外部コマンド」をかます方法は?・・・調べてみると、どうやらSun ONE StudioっていうかNetBeansで考えている「External executor」とは、「External java executor」を前提としているようだ。
だが、できないこともなさそうだ。だってNetscapeのようなブラウザの起動も取り扱えるんだから・・・

などと思っているうちに、このまえ本屋で見つけて即買いした以下の本

「詳解Sun ONE Application Server7 パーフェクトガイド(サン・マイクロシステムズ(株)Sun ONE事業本部 著、技術評論社発行)」

の最後のほうに、「Netbeans Open APIsの活用」という、Netbeansモジュール開発に関する解説があった。
読んでみると、付録のサンプルアプリケーションの配備と実行の仕方が書いてあった。だがコードそのものは自分で勉強すれとある。
これで外部コマンドの起動のようなモジュールを作れないだろうか?と思ったのだ。

この付録のサンプルアプリケーションは、我がSun ONE Studio 4で見事に動いた。
だが、残念ながらNetbeans3.5では動かなかったのだ。
もっと正確に言うと、Netbeans3.5用のOpenAPIsで動かなかったのだ。
原因はかなり明白のようで、このSun ONE Studio 4用のOpen APIsでほぼ必須のように使っている
TopManagerというクラスが、Netbeans3.5用のOpen APIsにはないみたいなのだ。

てなわけで、とにかくサンプルが動く環境Studio 4 CEでもう少し遊んでみることにした。だから完全にサラバというわけにはいかないのだー。

そのNetbeans Open APIsについての詳細な格闘記は別ページを御覧ください。

2003年07月23日

ページ先頭に戻る


Sun ONE StudioだとWebServiceも簡単?

WebService。それは一体なんなのか?わたしにも何かいじれるものなのか?去年の秋に初めてこの言葉を知ってからずーっと悩んでいる。
だがSun ONE Studio(もうなにエディションか記す必要がなくなっているのが悲しい)ならWebServiceもむちゃくちゃ簡単にできる。初級っぽいものなら、だが。
WebServiceのチュートリアルもSunのドキュメントサイトには用意されている。それをやって見てひとつわかったのは、

EJBをWebServiceに乗っけてしまえばクライアントアプリケーションを作るのが超おラク

詳細は別ページ。でもたぶんこれがWebServiceの真相では絶対ない。

2003年07月15日

ページ先頭に戻る


Sun ONEで初めてのCMP

このようにしてデータベース接続はなんとか理解した。つぎはいよいよCMPである。Webを調べていると、もう風潮は、「データソースを使わなきゃJ2EEでない」から「CMPを使わなきゃJ2EEでない」みたいなところがあるのをひしひしと感じる。だが以前J2EE SDKでCMPを勉強したときはやたらに苦労した記憶があったので、なかなか手が出ないで今に至っていた・・・

しかし、今回Studio5 SEでCMPに再挑戦してみた。
非常に残念なことに、全く同じアプリケーションをMySQLデータソースで動かすことはできなかった。EJB-QLの実行に文法エラーがあるらしい。
以前Relaxerなどでもあったことだが、データベースによって、クウォーテーションマーク一個が必要だったり余分だったりとSQL文にビミョーな違いがあるらしい。
付属のPointBaseは実はコンソールもすぐ凍るしすごい使いにくいのだが、これでならできるのでしょうがない。渋々使っているうちに、それなりになれてきた。

欠かせないのは、Sunのページからダウンロードできるpdf形式の様々なチュートリアルドキュメントだ。Sunのドキュメントの配布サイトは実にいろいろなところに実にいろいろなルートでアクセスできるがハッキリ言ってわかりにくいぞー!・・・Sun ONE Studioをどのように使えばどのような技術が学べるか一番わかりやすいのはこのサイトかも知れない。

http://developers.sun.com/prodtech/javatools/reference/codesamples/index.html

ここから落とせる「ProductInventory」や「DiningGuide」のチュートリアルpdfを見ていただければ、ヘボのに子などがえばって報告などするまでもないのだろう。だがもっともおーっと簡単な例を一個挙げてミマショカ。せっかくやったんだし。

2003年07月15日

ページ先頭に戻る


EJBのコードも変わったのか?

そしてApplication Server 7上で動かすBMP Entity Beanのサンプルコードだが、実は同じと思っていたJ2EE SDK 1.3のサンプルと、Sun ONE Application Server 7のサンプルとで、コードが微妙に違っていた。データソースを扱う部分である。それがアプリケーションの動作に影響するのか、ていうかこの試みでさんざ出したエラーがその違いによるものだったのか、はわからない。だがそれまでは前者のサンプルコードにならってコードを書くことが多かったわたしだが、これからはAppServer7版のサンプルにならうことにした。

2003年06月23日

ページ先頭に戻る


ひとつ不思議な話:MySQLのアクセス問題

だがひとつ不思議な話がある。それは今Sun ONE Application Server 7と連携したSun ONE Studio 5でMySQLにアクセスを試みたとき、noniko@localhostからのアクセスが拒否されたのである。
そういうことはあるんだヨということは、たとえば

「MySQL徹底入門」(日本MySQLユーザ会編、翔泳社発行)

などにも詳しく書いてある。しかし、今まではMySQL対話式インタプリタ上で

grant all privileges on *.* to noniko@localhost.....

というコマンドをかませば、Sun ONE-Tomcatでも、J2EE SDK1.3でも、Strutsでも自作アプリmymysqlでもとにかく全然問題なくアクセスできていた。だが、なぜかここに来て、全く同じMySQLサーバなのに、アクセスが拒否されたのである。
そこで上記の本をもう一度見直す。mysqlデータベース、つまりユーザ権限やデータ構造の情報がテーブルに載っていてフツーのテーブルと同じように参照したり書き換えたりできる(ここがきっとMySQLが劇使いやすいと感じられるようになった理由に違いない)データベース領域である、そこにルート権限で入る。

そして、ここから先はお気楽主婦だからこそできる相当の暴挙である。良いSEや良いAEは決してまねをしてはいけません(するわけねーか・・・)。

select * from user;

とやるとユーザテーブルが暴露される。このうち

|  Host     |  User  |
+----------+-------+-
|  localhost  |  noniko |

にあたる列を見ると、各権限に対して

+--+--+--+--+--+--+--
| Y |Y |Y |Y |Y |Y |Y
+--+--+--+--+--+--+--

みたくずーっとYが並んでいる。そらそーだろ、もうオール権限をオールデータベースに対して与えといたんだから・・・と思っていたらひとつだけ「N」があった。
どこに?・・・あんまり列が多いので、実は見てない。ひどい、ひどすぎる超いい加減ぶりだ。そしてこのNをYに書き換えてみた(自作のmymysqlGUIアプリケーションではできるんだヨこれが!)
そしたら、アクセスできるようになった。ひでえ話である。だがとにかくこっちはデータベースに接続できるかどうかを確かめるのが急務だったからしょーがなかったんです!

2003年06月23日

ページ先頭に戻る


避けては通れない(んじゃないかな)DataSource問題

これでもうEJBはAppServer7で動かす体制になってしまった。とすると再びアノ問題に取り組まなければならない。それはWebSphereでさんざ勉強させられたDataSourceの利用だ!名無しサーバ「J2EE1.3リファレンス実装」においては、resource.propertiesファイルにチーチーパッパと書き加えればよかった。だがApplication Server 7では、やはりWebSphereと同様管理コンソールから設定することになっている。
その方法は、今ならできなくもなさそうに思える。だがStudio 5にはさすが8万円弱取るだけあるというかこれで8万円弱はお得ですヨ奥様というかベリーナイスなツールで簡単に接続できるので、まずそっちを報告しよう!

それについて学んだことがある。DataSourceというのは、コンテナが用意しているものでなく、各JDBCドライバに用意されているものだったのだ!そして我らがMySQLのMMM(元mm)ことMySQL Connector/Jドライバにも、実はちゃんと実装されていた!
わたしはその供給元ページでそれを知った。 DataSourceのクラス名は

com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource

というものだ。
そもそもそれにたどりついた理由というのは、Studio5の接続設定をがちゃがちゃやっていたら

org.glt.mm.mysql.jdbc2.optional.MysqlConnectionPoolDataSourceをよこせ

みたいなことをStudio5が言ってきやがった、いや言ってくださったからである。それで今の後継ドライバにも同じようなものがあるに違いないと踏んだわけで・・・

とにかく、これでApplication Server7でもフンダンにMySQLを使えるようになったゾ!

2003年06月23日

ページ先頭に戻る


今度こそAppServer7と連携だ

Studio_4EEはうっかりApplication Server 7との連携版でないヤツを落としてきてしまった。ゆえに「J2EE1.3リファレンス実装」などと呼ばれている,J2EE1.3SDKに組み込まれている名無しサーバを相変わらず使うハメになった。それでも相当苦労したわけだから相応だったのかも知れないが、今度こそAppServer 7と連携して使いたい。ていうか今度のヤツにはもう名無しサーバはついてないのだ。
AppServer7との連携の仕方は、Studio_5EE本体と同じダウンロードサイトに公開されているpdf形式のGetting Startedガイドに詳しく書いてあった。だがこれは最低限の概要のようなものをここにまとめておくとどなたかのお役に立つかもしれない。

まず、AppServerでアプリケーションを動かすには、これまではデフォルトのサーバインスタンスserver1とその管理ツールにroot権限で入ってあーだこーだやっていた。しかし、当然といえば当然なのかも知れないが、ヒラユーザ用のサーバインスタンスを作ることができるのだ。

一度rootに上がって以下のコマンドを打つ。

#asadmin create-domain --sysuser noniko --adminport 11111 \
--adminuser noniko --adminpassword nonipassword noniko

末尾の引数nonikoがサーバ名である。sysuserはOSに登録されているユーザ名、adminuserはAppServerを使うときに他の名前でログインしたけりゃできるゾというものらしい。adminpasswordはAppServerへのログインパスワードで、システムパスワードと同じものを使い回すのはよくないということなんだろう。adminportはシステム様がご使用になっておられないはずのデカ番で適当なものを自分でひねり出す。
結構めんどくさいコマンドだったが、何の問題もなく完了した。

Studio_5側の設定は、今までの「Sun ONE Studio EEを使い倒せ!」のページにそのまま書き倒すことにする。

2003年06月23日

ページ先頭に戻る


怪我の功名?Java大工事

それなら使ってみなければ主婦がすたるというものであるStudio5。ダウンロードしてみた。だがインストール方法の説明を読むとこいつはSolarisではroot権限で/optフォルダ配下に入れなければならないとある。おまけにJ2SE1.4.1_02以上でなければ動かないという。
つまりSolarisのシステムのJavaパッケージ(1.4.1_01)を一度削除して、最新版のパッケージをとってきて充て直さなければならないようであった。
それがめんどくさくてヤだったので、それまでは1.4.1_02などをnonikoの個人ホームディレクトリに入れて、そこに無理矢理パスを通して使ったりしていたのだが、さすがに小手先は通用しない状況のようだった。度胸を決めて探しに行くと、最新版は1.4.1_03になっていた。具体的な方法はここで敢えて記さなくともSunのインストラクションページに詳しく書かれている。ともあれこれでSolarisのシステムのJavaが最新になった。
個人ユーザの役得というのか。臆面もなくrootでコンソールログインして、GUIベースのインストーラでStudio 5を入れた。非常にサックリンコであった。

2003年06月23日

ページ先頭に戻る


晴天の霹靂Studio_5SE!

そんな6月も下旬に入ろうとするある日のこと、わたしはいつものようにSunのダウンロードページに行き、Sun ONE Studio の新しい情報でも出ているかしらとリンクをクリックしたら

Sun ONE Studio 5 Standard Edition

のページに飛ばされた。
それはどうやらStudio 4 EEの後継らしい。約8万円の値段がついている。8万円というのは実は前EEが10万とかそれ以上したのに比べるとかなり安い。だが主婦がおいそれと手を出せる金額ではない。そしてCEのような無償機能限定版についての情報はどこにもなかった。かわりにこの8万円エディションのお試し版がダウンロードできるという。
だがお試し版は所詮お試し版だ(偉そうに)恒久的に堂々と使える機能限定版はないのか?かなり青くなったわたしは他の情報を求めてネットバカボンしてみた。するとどうやらこの秋にはJava Server Facesなどをもりもりこんだ次世代アプリケーション、プロジェクトRaveが公開されるらしい。だがこのStudio 5に関する情報は見つからない。どうなっているのだろうか。?無償エディションの配布はもうしないということなのか・・・?だがStudio 4 CEはJ2SEのダウンロードサイトにちゃんと用意されていたのでかなり安心した。
そーか!Sunの思惑としては秋にプロジェクトRaveを出すわけだから、Studio 5はそれまでのツナギのようなものでだからわざわざCEなどは出さないというわけか。そしてStudio 5をタダで遊びたいヤツは、2ヶ月分のお試し版で秋まで持ちこたえろというのか!・・・・「それはねーだろ」と帰宅後のんのんに言われた。

2003年06月23日

ページ先頭に戻る


Enterprise Editionでゴー!

ではもっと複雑なJ2EEアプリケーションを作るためには・・・やはり、Sun ONE Studio Enterprise Editionが標準開発ツールになるのだろう。おそらくJ2EE SDKのdeploytoolに取って代わるのでは、という気さえ、のに個人的には、する。わかんないけど。だがとにかくSun ONEと名の付くものは全て試してみたいわたし、60日イッポンポンの評価版を落としてみた。
だが、ここでどじをやった。どうせならApplication Serverバンドル版を落とすべきだった。うっかり、内部サーバ(J2EEリファレンス実装ってヤツらしい)しか使えないヤツを落としてしまった・・・だがまずこっちのほうが「バフンウニ症候群」で慣れてるしまずこれでやってみよう。

Enterprise Editionのセットアップには「Sun Compiler Collection」なるものへのパスを求められ、空白でもセットアップはできるがまた立ち上げ時にこのパスが見つからないと言われる。だがどうやらこれは、Enterprise EditionがC++なども扱えることに関係するようだ。あまりうるさいグチでもないし、まあ聞き流しておく。

ではさっそく。同じような簡単なステートレスセッションBeanを作ってみよう。
さて、ユーザーフォルダは同じようにffjuser40eeというところにある。そしてなんと驚くべきことにこのフォルダの中にもj2sdkee1.3.1フォルダがあるのだ。そして内部サーバとして動くのはこっちのほうらしい。ユーザが自由に設定できるように、ということか・・・
下のハンドデプロイメントテスト用に作ったコードをそっくり使うことにした。 2003年04月24日

続いてBMP Entity Beanなども作れるようになった。結構使ってるぞお試し版!2003年06月01日

詳細は別ページに示す。

ページ先頭に戻る

 


AS:J2EEアプリのハンドデプロイメント!

以後(積み上げ方式なのでここから上のほうですが)Application ServerはASと省略させていただくことにして、こいつはJ2EE 1.3完全対応、という。ただしデプロイツールは、あるのだが、アーカイブまでは自分で作らなければならない。生のクラスファイルからモジュールそしてアプリケーションファイルまで作ってくれるJ2EE SDKとはそこが違う。
だがそこはさすがSun様である。ユーザーガイドに書いてあるのは、アプリケーションに用意されたビルドファイルのひな形と、それに対応したコマンドasantを使えば、かなーり楽にアプリケーションファイルを作れるということだった。あとはlocalhost:4848の管理コンソールからそのearファイルをデプロイしてやればよいというわけだ。

やってみた。アプリケーションは例の非常に簡単な、Nonikoと呼べばHello Nonikoと答える山のこだまの嬉しさヨというアレである。ただし今回はパッケージ属性をつけてしまった。たぶんつけなくてもやれるんだと思うが、お手本がつけていたので・・・

それぞれのクラス名は以下のようである。

リモートインタフェース:test.ejb.SayOnceMore
リモートホームインタフェース:test.ejb.SayOnceMoreHome
Bean:test.ejb.SayOnceMoreBean
クライアント:test.client.SayOnceMoreClient

そう。テストなんだからもっと短い名前にするべきだった。おかげで試行錯誤してたときファイル名やクラス名入力するのがめんどくせえのなんの。

手順はこうだ。詳しいことはプログラムの中身もふくめて別ページに示す。
ざっくらばん(ちゃうって)には、ASのインストールディレクトリ下、

/opt/SUNWappserver7/docs/getting-started/index.html

からリンクして

Deploying and Runnning the Sample Application

を見ると書いてある。ここではのに子流を紹介する。

まず、ASのインストールディレクトリの実行フォルダに、パスを通しておく。先日はこのディレクトリ名もいい加減でした。重ねてお詫びデス。デフォルトは

/opt/SUNWappserver7/bin

である。環境設定ファイルに書き込んでしまった。

そのインストールディレクトリ下にこんなフォルダがある。

/opt/SUNWappserver7/samples

このsamplesフォルダ直下にある

common.xml
common.properties

という二つのファイルがひじょーに重要な設定ファイルで、これには手を加えることはまかりならぬ、と思う。
加えて、たくさんサンプルがある。必要なものだけ持ってきてもいいのだが、いろいろお手本にするわけだから全部ひっくるめてこのフォルダごと自分の適当な場所に持ってくる。わたしは$HOME/j2eenonikoというフォルダを作ってそこに引っ張った。

$HOME/j2eenoniko/samples

というわけだ。その直下に

$HOME/j2eenoniko/samples/test

というフォルダを作る。このtestフォルダは単なる入れ物っていうか間仕切りである。この入れ物の中にさらに構築をする。

$HOME/j2eenoniko/samples/test/build
$HOME/j2eenoniko/samples/test/src
$HOME/j2eenoniko/samples/test/src/test
$HOME/j2eenoniko/samples/test/src/test/ejb
$HOME/j2eenoniko/samples/test/src/test/client

まずはクライアントはコンソールアプリケーションのみでやってみるわけだ。..../ejbフォルダにejbモジュールの構成ファイル、.../clientフォルダにクライアントファイルを、それぞれソースつまり.javaファイルで入れる。

それから・・・
$HOME/j2eenoniko/samples/ejb/stateless/converter
フォルダを見るのが、お手本としては一番いいだろう。
$HOME/j2eenoniko/ samples/ejb/stateless/converter/docs/index.htmlをひらけばこのアプリケーションについてのデプロイ方法も詳しく書いてある。問題は階層がクソ深いことであるが・・・さらにこいつを掘り下げ、

$HOME/j2eenoniko/samples/ejb/stateless/converter/src/sample/

の下に、

MANIFEST.MF
application-client.xml
application.xml
build.xml
ejb-jar.xml
sun-application-client.xml
sun-ejb-jar.xml
sun-web.xml
web.xml

というファイルがあるのをぜーんぶ、今俺デプロイをしようとしている

$HOME/j2eenoniko/samples/test/src/

の下に持ってくる。web.xml等のファイルは、今は使わないが、あっても悪さはしない。
これらの多くを、俺アプリに対応するように、ファイルパスを書き換えるのだ。書き換えの詳細は別ページに示す。
なお、ここにあるbuild.xmlはずっと上の階層にある

$HOME/j2eenoniko/samples/common.xml
$HOME/j2eenoniko/samples/common.properties

から、共通の処理を読み込むようになっているのが特徴だ。

書き換えが終わったら、

cd j2eenoniko/samples/test/src

で降りていって、

asant

ちなみにこの操作はヒラユーザでできるはずである。また、最初「アサント」ってどういう意味かなと思ったが、つまりはapplication serverのantという意味だったのね・・・

すると、まるで自分の仕事じゃないみたいに(実際ないんだけど)大がかりなbuild処理が行われ、気がつくと

$HOME/j2eenoniko/samples/test/sayoncemore.ear

というアプリケーションファイルができている。あと、assenbleというフォルダや、空だったbuildフォルダの中にコンパイルされたクラスファイルなども勝手にできている。どうぞ御勝手にお作りくださいという感じだが。とにかくearファイルを管理コンソールからデプロイする。

さてクライアントの実行をどうするか。アプリケーションの配備先は、実はこんな秘境の地だ!

/var/opt/SUNWappserver7/domain/domain1/server1/applications/j2ee-apps/sayoncemore_8

そこまで降りていく。すると、sayoncemoreClient.jarというファイルがある。これだけあればいいところが、前やっていたJ2EE SDKと違うところだ。実はクライアントの実行コマンドもちょと違う。

appclient -client sayoncemoreClient.jar -name SayOnceMoreClient -textauth

である。これについては、お手本として$HOME/j2eenoniko/ samples/ejb/stateless/converter/docs/index.htmlを開いたほうがわかりやすい。

すると、わらわらわらと情報メッセージが吐き出され、-textauthといってもデフォルトではエブリボデーアクセス可になっているらしくログインは起動しない。最後におまけのように

Once More Noniko!

みたく、出力結果が現れるというわけだ。

J2EEというのはアレだ。最初の簡単なテストプログラムを走らせている段階では、カスみたいな結果を得るためにボーダイな時間と作業量を必要とし、技術というものに対する不信感すら起こさせる。のに子のような家庭内プログラマとしては、きっとこれはおソトの一日10万件とかいうアプリサイトになれば、Tomcatよりずっと作業の手間がはぶける換算になるんだろうなと信じて進むしかないだろう・・・

さて、Webクライアントの場合だ。クライアントjspはパッケージ関係ないので、

$HOME/j2eenoniko/samples/test/src/docroot

というフォルダを作ってそこに入れる。名前はindex.jspとすれば、ブラウザから呼び出しやすいだろう。

そして、さっきの設定ファイルにweb関係の内容を書き加える。詳細はやはり別ページに示す。もう一度asantしてdeployして、ブラウザから

http://localhost/test

でアクセスしてやる。なんとアプリケーションサイトはポート80を使うのだ。だからApacheなどが自動起動ないようにしておく必要があるだろう。

ともあれ、これでJ2EEアプリケーション開発も、原則的には

テキストエディタ+Sun ONE Application Server PE

という組み合わせでできてしまうということになる。原則的には、だ。この先もっとまともなプログラムを作るのにはとーてー、金閣寺の天井に金箔を張り付ける(プロジェクトXでやっていた)ような作業になるのかも知れないが・・・

ページ先頭に戻る

2003年04月24日


Application Serverお詫びと訂正

最近Sun ONEにかなり接近できたなと調子こいたわたしは、久しぶりにSun ONE Application Serverをいじってみようとした。それでひどい目にあった。サーバの走らせ方を忘れてしまったのだ。
そこで以前このページに自分でコマンドをメモしておいたことを思い出し、その通りに打ってみたが、それは間違っていた。
おかげで、アプリケーションをアンインストール-再インストールするハメになった。なぜならインストール直後に、サーバーの起動コマンドがウィンドウ表示された記憶があったからである。
だがいい。もともと最初のインストールはかなりヘボかったのだ。今度はちゃんとrootでデスクトップログインして、グラフィカルなインストーラを立ち上げることができた。そして、多大な時間の消費とともにそれは現れてくれた。今度はぜってえ忘れねえようにそのウィンドウをスクリーンショットしてやった。

これ以上ガセ情報をたれ流すのは非常に心苦しいので、スクリーンショットをズバーッと出します。これだったらタイプミスも記憶違いもない!

ページ先頭に戻る

2003年04月24日


さらに相対パス問題

Webアプリケーションの場合は、ファイル参照はもっぱらURLを使えばよいのでまだよかった。次に、単体アプリケーションでファイルの読み込みを扱ったとき、問題が生じた。

プログラム内で

File myFile=("file.txt")

とか、
起動コマンドで

java treatFile subfolder/file.txt

のようにファイル名を引数に取ったりする場合、IDEから実行するとファイルが見つかりませんエラーとなる。

これについては、Sunのページの「Sun ONE Studio FAQ」に答えがあった。

  1. Explorer上で実行したいプログラムを右クリック
  2. 「Properties」ウィンドウを出して「Execution」タブをクリック
  3. 「Executer」「External Execution」とペアになってる行があるので「External Execution」のセルをクリック、するとコンボボックス&「...」になるので「...」をクリック
  4. すると「Property Editor:Executor」というウィンドウが現れるのでさらに「Expert」タブをクリック
  5. 「Working Directory」の行で隣のセルが空白になっているからそこをクリックすると、ファイルが参照できるように「...」が現れるのでそこをクリックして今実行したいプログラムのあるディレクトリを指定

結構長い道のりであるがこれでちゃんとファイルが捕まった。でもなんでこんなめんどくさいことしなきゃならないんだろ。

ページ先頭に戻る

2003年04月14日


よそ猫と比べて気がついたリンク問題

*この駄記事について、Sun ONE Studioでコンテキストルートを設定する方法、ちゃんとあることが後日わかりました。詳細はどーんと上の方

さて、こうして内部のTomcatも他ディレクトリのTomcatもIDEから動かせるようになってきて、実はひとつ両者に大きな差異があることに気がついた。

内部Tomcatを動かすために、コンテキストルートディレクトリnoniworldを、「Webモジュール」としてマウントする。この場合JSPファイルやサーブレットはツールボタン「Execute」で実行できるが、JSPファイルの場合ブラウザに現れたときのURLは

http://localhost:8081/myjsp.jsp

になっている。前から気づいていたことではある。だが相対パスであるからリンクには問題はないと思っていた。気をつけるのは、from.jspからto.jspへリンクする場合、リンク先を

<a href="/to.jsp">link to to.jsp</a>

とスラッシュ付きで書くと、内部Tomcatでは問題なくてもこれをそのまま外のTomcatに持っていくとリンクできない。
外のTomcatでは

http://localhost:8080/noniworld/myjsp.jsp

というURLで扱われる一方、上記のリンクは

http://localhost:8080/to.jsp

へリンクせよ、と解釈されるので、エラーになるのだ。これは

<a href="to.jsp">link to to.jsp</a>

と書けば、内部、外部いずれのTomcatでも「同じディレクトリ配下のファイル」として扱われ、リンクが正常に行われる・・・・

と、ここまではよかった。だが非常に深刻な問題が、InputJSP->Servlet->AnswerJSPへの連携にあたって、生じた。

かの有名な「RequestDispatcher」でサーブレットからAnswer.jspが呼び出され、このAnswer.jspからさらに他のページにリンクしようという場合である。

Answer.jsp中に

<a href="furthermore.jsp">link to furthermore.jsp</a>

と書くと、内猫でも外猫でもリンクエラーになる。なぜなら、

noniworld/servlet/furthermore.jspというファイルはありません

だからだ。サーブレットからAnswer.jspが呼び出されたとき、URLを見ると、呼び出して役目を終えたはずのサーブレットのアドレスがまんま残っている。そこから同じディレクトリ下のファイルを探そうとしているらしい。

内猫ならこんなときは

<a href="/furthermore.jsp">

スラッシュイッパツでコンテキストルート直下に戻ってくれる。だが、これは外猫には通用しない。

<a href="/noniworld/furthermore.jsp">

だったらオッケーだ。だが、

内部Tomcatで動かすのと外部Tomcatで動かすので別々のソースを用意しなきゃならないなんてアホだ

ということになる。わかっておられる方はもう最初からわかっておられるだろう。わたしにはわからなかったので探した。そして見つけた。

<a href=<%=request.getContextPath()%>/furthermore.jsp>

である。

実験してみると、JSP上で<%=request.getContextPath()%>は、内猫では何も返さず、外猫では"/noniworld"を返した。これで、どっちで動かしても同じ結果の出るソースを書くことができるようになったのである。いやーよかったよかった。

ページ先頭に戻る

2003年04月14日


よその猫も飼えるんだ!

さて、どーしてもStrutsアプリをSun ONE Studioで試したいわたし。いろいろ調べるとひとつ発見した。内蔵Tomcatの他に、別途用意した単体TomcatをSun ONE Studioから動かすことができるのだ。

そのために、まず「Project」を新しく作ることにした。初めてSun ONE Studioを立ち上げたときから使って来た「Project Default」はもうあっちゃこっちゃからファイルをマウントしまくっていて、エクスプローラからパッケージを探し出すのに一苦労状態になっている。
新規プロジェクトを作成するには、メニューバーの「Project」から「Project Manager」を選ぶ。「File」「New」とかから選ぶのではないところがちょっとわかりにくい。
ウィンドウが現れてExisting Projectsのリストが表示される。最初はProject Defaultしかない。「New」ボタンをつつくと新規プロジェクトの名前をきかれる。わたしは実は家計簿他WebアプリnoniworldのStruts版を作ってみるかという野望があるので「noniworldS」という名前にした。すると、「Project noniworldS」が新規作成された。

では、Explorerの「Runtime」タブを開く。ノード「Server Registry」->「Installed Servers」と開いていくと、「Tomcat 4.0」ノードが現れる。
最初は「Internal」ノードしかない。
そこで「Tomcat 4.0」ノード(猫の絵がついてるヤツ)を右クリックすると、メニューに「Add Tomcat 4.0 Installation」という項目が現れる。それを選ぶと、別途インストールしてあるTomcatのディレクトリを参照する画面になる。今の場合/export/home/noniko/tomcatがそれだ。
それとともに「IDE integration mode」というのがある。これはどうやら外のTomcatの設定を、IDE側から操作しやすいようにいくつか自動で書き換えるかなんかするらしい。わたしは最終的にサーバの単体Tomcatでアプリを動かしたいので、妙な書き換えをされると困ると思い、このモードをMinimumにした。
一方で、/export/home/noniko/tomcat/webapps/noniworldS というフォルダを、すでにstruts-blank.warの解凍により作ってあるので、このプロジェクトの「Filesysems」に新規マウントした。やはり妙な設定をされると困るので、「Web module」としてではなく、ただ単純にマウントしただけである。
それでも、「新規作成」で、作成場所に
/export/home/noniko/tomcat/webapps/noniworldS/WEB-INF/classes/noniworldS
を選んだところ、ちゃんと「package noniworldS」のファイルとして取り扱ってもらえた。

マウントしたディレクトリ内でJSPやプログラムの作成作業をして、起動するときは「Runtime」->「Server Registry」->「Installed Servers」->「Tomcat 4.0」->「/export/home/noniko/tomcat[Not Running]」を右クリックして「Start Server」 を選ぶ。
すると、ブラウザが立ち上がって、「http://localhost:8080」の、見慣れたあのページが上がってくる。
そこで、自分で表示したいページのURLを入れてやれば、アプリケーションの動作確認ができる。これでStrutsのアプリケーションはめでたく動いた。
ま、別途ターミナルからTomcatを起動したりブラウザを起動したりというより、全部IDEのウィンドウ内で行ったほうがチョット楽、という程度の設定ではあるが・・・

ページ先頭に戻る

2003年04月14日


内部Tomcatを飼い慣らせるのか?

Sun ONE Studio CEについている内部Tomcatサーバ、この前ようやくJSPとServletの連携のさせかたなどを習得したが、単体Tomcatのwebappsフォルダに実際にファイルをコピーして動かすのと完全に等価なのだろうか?

Jakarta Strutsの勉強を始めることになったわたしは、StrutsアプリケーションをS1S上で動かせるかどうか試してみたが、すぐにというわけにはいかなそうだ。
最初は、別の単体Tomcat上で、Strutsのblank.warの名前をtest.warに変えたものを解凍した。そしてできたフォルダを適当な場所に移す。
このフォルダを、S1S上で「新規Webモジュールフォルダ」としてマウントする。

それから内容を編集して、トップページとしてのindex.jspファイルをそこから起動しようとした。すると起動エラー。原因はこのjspの起動時コンパイルに際し

javax.servlet.jsp.tagext.TagExtraInfo

が見つからない、というClassdefnotfoundErrorだ。

これはちょっと不思議な話だ。というのはS1S上でタグハンドラなどを作ろうとすると上のファイルは必須インポートだが、そういうソースのコンパイルは全く問題なく行くのだ・・・

このクラスはかのTomcatの$TOMCAT_HOME/common/libに入っていることが有名なservlet.jarに入っているものだ。つまりこれまでさんざん使って使えているはずのもの・・・それがなぜStrutsアプリの起動に際してだけは見失われるのだろうか?

そこでわたしはservlet.jarをs1studio_jdk/jdk1.4.0_01/jre/lib/extに入れてみた。

そうしてS1Sを再起動してみると、たちまち問題が炸裂した。「HTTPサーバを起動できない。どうやらポートがふさがっているぞ」といういうメッセージが起動中から何度も表示される。だがIDEそのものは立ち上がった。
毒をくらわば、である。さっき作ったStrutsアプリのindex.jspをむりくり(東北弁)起動してみた。すると何度も上の警告が発せられながら、結局Netscapeは立ち上がり、ログインフォームなどを擁したページが表示された。

だが送信などをしてみると、エラーが出て目的のサーブレットに処理が渡されてくれない。もちろんこのフォルダは単体Tomcatのwebappsフォルダにコピーして動作確認済みである。

s1studio_jdk/jdk1.4.0_01/jre/lib/ext/servlet.jarを削除して再起動すると先のたくさんのHTTPサーバに関する警告は出なくなり、正常な動作が回復された。

というわけで、Sun ONE Studio CEの内部Tomcat でStrutsアプリを動かすことは、もう少し工夫すればできそうだが単純には行かないとわかった。まずはStrutsの勉強のほうが先なので、とりあえずこれは別途用意した単体Tomcatで動作を見ることにした。

ページ先頭に戻る

2002年12月15日


Sun ONE Application Serverの起動と操作

いつもの通り珍道中、みたいな形でインストールしたSun ONE Application Server7。Blade上ではこの起動はsuでrootに上がり

/opt/SUNWappserver7/bin/asadmin start-appserv(以前ウソ書いてました。ホントすみません)

で行う。しばらく時間がかかるので、コンソール画面にstartup completeと出てから、

http://localhost:4848

にアクセスすると管理コンソールが立ち上がる。Sun ONE Studioでテキトーに作ったWARファイルをデプロイしてみたら実にうまく行った(参考図面はWAR作成と同じ

2002年11月13日
2003年04月24日訂正

ページ先頭に戻る


Sun ONE Application Server 7のインストール

Sun ONE Application Server(前のiPlanet?)・・・その中でPlatForm Editionというのが、無償配布だ。
そこでありがたく配布していただくことにした。もちろん最初はSolais版をBladeに導入だ。かなりでかい。Unzipだけで死ぬほど時間がかかる。

さて、sun-appserver7というフォルダができた。わたしは、このダウンロードと解凍までを、ヒラユーザnonikoの権限で、そのホームディレクトリ内で行っていた。
何の気なしにそのフォルダを開け、setupという実行ファイルのアイコンをダブルクリック。
グラフィカルなインストーラウィンドウが立ち上がったが、「このインストーラはroot権限でなきゃダメっす」と言われた。
ああそうなの、と思ってコンソール上でsuでrootに上がる。そこでコマンドラインからsetup。

すると「rootにはX-Serverへのアクセス権がないからダメっす」と言われた。

な〜にイ〜
と憤ったわたしだが、そこで突き放されたほうがむしろよかったかも知れない。一度ログアウトしてrootでログインし直せばたぶん全ては解決したんだろう。ただその「ダメっす」のあとに親切にこうも書いてあったのだ。

「コンソール上でのインストールもできますけど。setup -consoleとやれば」

アハ〜ン。それならそれでいいわ。コンソールのほうがむしろ軽いし〜。などと少しはコンソールを使える気になってきたわたしはそれをやってみた。

「まずお約束事項です。以後の質問にはyesかnoか、あるいはパラメータを入れてください」
ハイハイ。

そのあと、契約事項がダ〜と流れる。「継続するにはリターンを押してください」・・・言われるままに押していく。もちろん何度か「同意しますかyes/no?」と言われているのに気づかず押し続けたりして、契約事項はクリアした。

ところがそのあとがなかなかめんどい。「Application Serverをインストールするディレクトリを指定してください[/opt/sunappserver7]?
ハイハイ・・・「yes」と打ってリターン。
「ディレクトリを新しく作成しますか?」・・・「yes」

「Application Serverをインストールするディレクトリとして/export/home/noniko/yesを設定しました

コラ〜!!ていうか、ちょっとしたコミュニケーションの失敗だった!!最初にyesかnoかで答えなさいとか念押されるからもー・・・

全て設定して、行けッinstall !・・・・
・・・・・・・・・
しーん、としている。CPUメータもHDDメータも動かない・・・もう終わったのか?・・・いろんなフォルダをひっくり返してみる。インストールされているようないないような・・・フォルダはできてるがファイルは・・・と5分くらい悩む。普通、インストールが終わったら、セットアップを行っていたウィンドウに終わりましたみたいなメッセージが出るはずだよな、それが出ないということは・・・と思っていると出た。

+-1%-

だー!これで1%かい!・・・とかなりメゲた直後いきなりCPUもHDDもバースト。今までヤツは何をやっていたんだろう。・・・そのあとはどちらも忙しく動き・・・まあ、許容できる速度で、

+-1%--10%-----50%-----

とコンソールへの出力が続く。そう、コンソールでのステータスバーなのだ。そして完了した。20分くらいかかったかな?
後日、Windows版をゲットしてインストーラを起動したが、こっちはユーザnonikoにAdmin権限を与えているので問題なくグラフィカルにインストールができた。とても簡単で、やっぱりコンソール操作はむづかしいと思った。

2002年11月13日

ページ先頭に戻る


WARファイルも作れるぞ!

作ったWebアプリケーションをWARファイルにまとめることも、S1S上でできる。これは詳しいことはかのSunONE本に書いてあるので、ここでは転載を控える(別にめんどくさがっているわけじゃなくて、この本マジで買って損はなかった)。
ただ、「New Wizard」で「JAR Receipe」を選び、ウィザード中の「Generated JAR Name」つまり作るべきファイル名にそしらぬ顔でnonipackage.warと命名するだけである。そしてターゲットディレクトリ・ターゲットファイル及びJAR Manifestの設定はすっ飛ばす。
「Finish」でできるのはアーカイブそのものではなくJAR Receipeという、まあなんなんでしょうか、とにかく実際にアーカイブを作るには、「Explorer(Filesystems)」上でそれを表すアイコンを右クリックして「Compile」を指定する。
これでちゃっかりnonipackage.warができてしまう。さてこれを・・・上に記すように、わたしはSun ONE Application Server 7に配備して試してみたらズバーッと動いた!まさにSun ONEで全てができるワン!
参考図面

2002年11月13日

ページ先頭に戻る


JSPとServletの連携アプリの実行のさせ方

JSP単独もしくはJSP同士の連携アプリならば、「Explorer(Filesystems)」上で今作ったJSPをさくっと右クリックで「実行」でオッケーだ。だがServletになると問題がややこしくなる、ように見える。特にパッケージに置きたいような場合だ。
だが一度わかれば簡単。要はTomcatでの配備を再現してやればいいのだ。

nonipackageというパッケージで作るとしよう。

  1. まず、適当なところに、nonipackageフォルダを作っておく。
  2. 「New Wizard」で「JSP&Servlet」のノード下にある、「Web Module」の新規作成を選ぶ。これはフォルダの場所を指定するだけだ。今作ったnonipackageフォルダを指定する。するとここにWEB-INFフォルダを作りますヨみたいなメッセージが出て作成が行われる。
  3. 「Explorer(Filesystems)」上でnonipackageフォルダがマウントされていることを確認する。ノードをつつくとWEB-INFノード(フォルダ)がある。それをつつくとClassesが出てくる。そこに右クリックで「フォルダの新規作成」をかまし、Classesの下にnonipackageフォルダを作る。そう。Tomcatでやってるのと同じだネ。
  4. WEB-INFノードの下にはlibというのもある。このアプリケーションでJDBCなど使いたい場合、そのドライバjarはこのlibの中に入れる。
  5. Servletを作る場合、新規作成ウィザードでは作成場所を慎重に選ぶ。ノードをがんがんつついて、この/nonipackage/WEB-INF/classes/nonipackageまで降りてって選ぶ。するとパッケージnonipackageに属するものと認識してくれるのだ。(参考図面
  6. Servletを作る場合さらに、新規作成ウィザードでは作成場所をえらびファイル名を指定してから、「次へ」進む。するとサーブレットのURLを指定する画面になるのだ!このときウィザードはちょいとオバカで、サーブレットのURL Patternはデフォルトが
    /servlet/nonipackage.noniServlet
    みたくなっている。そこを
    /nonipackage/servlet/nonipackage.Servlet
    と直すのがキモである!

そうしてやれば、JSPからServletの参照パスは、いつもやっているように
/nonipackage/servlet/nonipackage.Servlet
と参照してやればいい。
逆に、ServletからJSPへの参照は
/nonijsp.JSP
でなければならなかった。これはどーかな?もしかしたらTomat上では/nonipackage/nonijsp.JSPでなければならないかも知れません。

いずれにしろ、上の設定で、複数のJSPやServlet、そしてJavaBeansを使ったアプリケーションを作っては試し作っては試しすることができた。

2002年11月13日

ページ先頭に戻る


S1SからNetscape6を立ち上げる

Sun ONE Studioを知ったフリして勝手にS1Sと略させていただきましたSun様。SOSよりいいよね。
さてそのS1Sをupdate 1にした直後のことだった。今度はJSPに「実行」をかますと、以前はNetscape4.7が自動で立ち上がったのが立ち上がらなくなるという状態が起きた。警告ウィンドウが出て、xinfoが正しいブラウザを見つけられないのでブラウザを立ち上げることができない、Tools->OptionでIDEの設定を開きブラウザの設定を見直せというようなことが書いてある。

見直してみたつもりだがどーもわからない。前にできたことができなくなるというのはとてもブルーだ。そんな気持ちで買い物に行き、帰りに本屋さんで見つけたのが以下の本だった。

実践Sun ONE Studio4 Javaプログラミング入門(丸の内とら 著、ソーテック社発行)

この本は前にも店頭で見かけたが、あまりよく検討せず、GUI編集とかの初級本かなくらいにしか思っていなかった。だが今それをよく読んでみると、「IDEのカスタマイズ」とか「JARパッケージの作り方」とか、非常に有用な内容であることがわかってきた。この本のおかげで今の問題も含めかなりのことが解決した!本の内容をまるっとそのまま転載しちゃうのはよくないが、幸か不幸かこの本をきっかけに、のに子なりに少し違った解決策がいろいろ得られたのでそれは紹介することにする。

さて、SolarisでS1SからNetscape6を使う方法はこのようなものだ。

1.「Tools」->「Setup Wizard」を立ち上げる。これは最初の起動のときに設定項目として出てきたヤツだ。「Web Browser」のコンボボックスでExternal Browser(Command Line)を選ぶ。
デフォルトは「External Browser(UNIX)」となっていた。このオプションでも以下のように起動パスを指定することができるはずなのだが、なぜかこれではうまく行かなかったのヨ〜。なぜかな?

2.さて「Tools」->「Options」を開き、「IDE Configuration」のノードをつついて「Server and External Tool Settings」->「Web Browsers」さらにこれをつついて「External Browser(UNIX)」を出す。これを選ぶ。
すると右側のウィンドウに2行2列の表が現れる。2行目の「Browser Excutable」をチクっとつつくと、右列の項目が編集可能になり、...ボタンが現れるのでそこをさらにつつくと詳細設定画面となる。

「Process:」に「/usr/dt/bin/Netscape6」
「Arguments」に「{URL}」となっている。それには手をつけない。

これで、JSPを「Execute」すると、Netscape6が自動で立ち上がってその確認ができるようになった!ちょっと遅いけどなッ!768MBのメモリでも!

2002年11月13日

ページ先頭に戻る


落ち出すと止まらない!?

それからしばしの間ジローラモさんのように「すっげーえ、すっげーえ」と言いながらJSPなどを作っていたが、Blade100をSolaris9にアップグレードしたのち再びSun ONE Studio4 CEを入れたところちょっとした異変が起きた。
Ultra Sparc IIe 500MHz,256MBメモリでは、ちょっとかなり重いなと感じ始めていたこのツール、まだ画面がグズっているときにスクロールバーなどを無理に動かすとコアダンプするのだ。
特に、新規作成ウィザードでJSPを選ぶときには「JSP&Servlet」というノードを開かなければならずそれがウィンドウの下のほうにあってスクロールしなければ出てこない、ここで焦るとやられるのだ。
一度コアダンプすると、次に起動していくら慎重に画面が切り替わるのを待つようにしても、触っただけでゲロられる。アプリケーションをアンインストール-再インストールすれば復活するが、うっかり急いで触るとまた落ちる・・・

が、java.sun.comサイトに行くと、新しいバージョンとしてupdate1が出ていた。それを使うと今度はどうやら落ちなくなった。と思っているうちにBladeのメモリを768MBに増設できたので、画面がグズることそのものがなくなって、かなり安心して使うことができるようになった。

2002年11月13日

ページ先頭に戻る


PointBaseに接続

次。データベースに接続だ。それにはまず,Forteに付属のPointBaseを使ってみよう。
最初にPointBaseサーバを立ち上げる。

以下の詳細は別ページに記し,ここでは概略を述べる。
  1. まず,そもそも接続できるのかどうかを確かめたいので,テーブルの作成やデータの挿入はPointBaseのConsoleから行った。デフォルトのデータベースはあるが,やはり新しく「NONIDB」というデータベースを作る。PointBaseの場合はユーザ名とパスワードが必要だ。
  2. それからForteで「ツール」「JDBCフォームウィザード」を選ぶ。
  3. 「データベース接続を作成」ステップで「新規接続」を選ぶ。
  4. 「名前」はリストから「PointBase Embedded Server」を選ぶ。すると「ドライバ」は「com.pointbase.jdbc.jdbcUniversalDriver」が自動記入される。「データベースURL」に「jdbc:pointbase://localhost/NONIDB」と記入する。さらにユーザ名とパスワードを記入。
  5. 「次へ」をクリックすると「接続中」のようなウィンドウが現れる。
  6. フォームウィザードは「表の選択」へ進む。そこではさっきNONIDBデータベースに作った,たとえばNONITB1が選択できる。他の設定はどうしたらいいかわからないのでとりあえずデフォルト。
  7. 「列の選択」lに進む。やはりさっき作ったテーブル構造が現れる。ここでもやることはよくわからない。とりあえず「全てを編集可能」ボタンくらい押しておく。
  8. 「ウィザードの終了」画面で作成するファイル名を適当に記入する。たとえば「dbtest1」とか。
  9. 「GUI編集」ウィンドウに切り替わり,データベーステーブルっぽいフォームが編集ウィンドウに現れる。
  10. 一方,ソースエディタには「dbtest1」ファイルができていつの間にかたくさんのコードが自動的に記入されている。
  11. こいつを実行してみるとフォームが表示され,その中にはさっき入れておいたデータが出ている。
  12. ただ,これに新しいデータを挿入することは今のこの状態ではできなかった。たぶんこれから編集を加えていかなければならないのだろう。

他のデータベースにも接続できるか,これから何を作るか,それらはこれからということにして,とにかく今度のForteではいともカンタンにデータベース接続フォームを作ることができるとわかった。

2002年10月06日

ページ先頭に戻る


変わっただけじゃなくこれはすごすぎる

新しいSun ONE StudioことForte, ホントにSolaris版でも中にJDKは入っているのか?
$HOME/forte4jフォルダを開いてみると,いつものbinとかlibなどのフォルダと一緒に,確かにjdk1_4_0_01というフォルダが。しかしそれとともにわたしは信じられない名のフォルダをそこに発見した。
それはtomcat。
ということはアレか!?Forte上で内蔵Tomcatに接続して,編集したJSPやServletなどをその場でテストできるということか!?
以前のバージョンでもそれらしい匂いはしたっていうか,起動したときに「Tomcat3.2を読み込み中」とか,オプションにもTomcatがらみのアイコンのようなものがところどころに見つかっていたが,どう設定してどう使えばいいかわからなかったのだ。今度はどうか?

新しいJSPファイルを作成した。といっても骨組みはすでに作ってくれてある。そこに「こんにちえわ」と文章を打ち込むだけだ。実行すればブラウザ画面に「こんにちえわ」と表示されるはずだ。

その超いーかげんJSPファイルを,さてどうするか・・・きわめて無謀なことにソースエディタのそのソースのタブを右クリックしていきなり

「実行」

すると,いきなりアプリが騒ぎ出す。だが出てきたのは
「オブジェクトがWebモジュールにないか,オブジェクトを含むディレクトリがWebモジュールのルートディレクトリにマウントされていません。Webモジュールは,WEB-INFディレクトリを持つディレクトリにマウントする必要があります」
やっぱそーだよなと思うが,変なのはウィンドウのタイトルは「エラー」ではなく「質問」
そして選ぶのは「了解」か「取り消し」・・・「了解」を選んでみた。すると,

「内部Tomcatを起動しています」
というメッセージウィンドウとともに
「Webモジュールの代替ビューは現在のプロジェクトで使用可能です。「エクスプローラ」ウィンドウでプロジェクトタブをクリックして,このビューにアクセスしてください」

どえー。マジすか。と思っているうちにいきなりNetscapeが立ち上がり

こんにちえわ

そして,ユーザファイルを格納することになっているsampledirフォルダの直下に,いつのまにかWEB-INFフォルダができていた。
すっげー。これがCommunity Editionだヨ!ホントに無償なのか不安になって来ちゃうよ!

2002年10月06日

ページ先頭に戻る


Forteも変わった!

ところがもっと驚くことがあった。それはForteことSun ONE StudioCEだ!なんとJBuilderのように内部にJ2SDK1.4が入っている!
というのはWindows版ではつい先月か先々月,すでにForteでなくなっていたForteを新しくダウンロードしたときに気づいたものだったが,なんとSolaris版でも!・・・ダウンロードサイトで,JDK入りかJDK抜きかを選べるのだ。

実はSolarisののに子のホームディレクトリ環境はひどいことになっていた。
1.まずForteをシングルユーザモードでインストールして使っていた。
2.そこにJ2EESDKを導入した。するとこいつらがバッティングした。十中八九XMLのパーサ関係の参照が原因だ。j2ee.jarと,Forte付属のjaxp.jar, parser.jar, crimson.jar等(ハッキリ特定はしてないが)である。クラスパスにj2ee.jarを設定した状態で,Forteは起動したが「新規jsp」を作成しようとすると何をやっても例外エラーとなる。
だからJ2EESDKを使わないユーザを別に作ってForteをこっちのホームディレクトリにインストールし直して使っていた・・・

しかーし。今度は,J2EE用に設定した環境のホームディレクトリに,そのままJDK入りForteをインストールしてみた。
全く問題なし。/usr/j2seに入っているJ2SDK1.3については何も聞かれなかった。そうしてForteは何の問題もなく起動した!
って,Sun ONE Studioでしたね。でもフォルダ名にはForteって書いてあるもん。とにかくこうして今まで通りのJ2EESDKとForteをSolarisの同じユーザホームディレクトリで使えるようになった。助かる〜。

2002年10月06日

ページ先頭に戻る


J2SDK1.4 for Solarisが変わった!

今までSolarisのJavaはあまりにもOSと一体化していたので逆にWindowsのJavaより融通の利かないところがあった。J2SDK1.3からJ2SDK1.3.1へのバージョンアップは,pkgrmで前のバージョンのSDKを削除してからpkgaddで新しいバージョンを入れる必要があったのだ。そのかわりjavacもjavaも最初からコマンドパスが通っているとか,.javaのファイルを右クリックするだけでコンパイルできたとか言う利点も確かにあったが。
その点Window上ではあくまでJavaはお客さんなのであらゆるバージョンを並列に入れられた。環境設定を変更するだけで1.3も1.4も並行して使える。それがどーも,Sunの犬のわたしとしてはくやしかったわけで・・・最近いよいよ,J2SEも1.4に上げないとやってけそうにないなと思い始めたが,今使っているソルッ八ではJ2SDK1.3上にいろいろなマイシステムが構築されている。いずれも学習用とは言え,この状態でJ2SDK1.3を削除してJ2SDK1.4を入れ直したら何か不具合が起こりやしないか・・・
だが勇気を持ってSolarisでもJ2SDK1.4にバージョンアップすることにした。実はJ2SDK1.4は以前Solarisに入れたことがあるが,そのあとまたSolarisそのものを再セットアップする必要が生じて以来もとからの1.3を使っていた。だからそのときにダウンロードした1.4のパッケージを使ってもいいんだけど,今Sun ONE構想のもとに新しく位置づけられたJ2SDKにも,もしかして何か改良が施されてはいないだろうか?たとえば便利なインストーラがついたとか?
ダウンロードし直す。するとのに子の期待は裏切られなかった。
ダウンロードファイルの形態もインストールマニュアルも変わっていたのだ。
まずダウンロードリンクをつつくと,今度はj2sdk-1_4_0_02-solaris-sparc.shというものが降りてきた。前降りてきたのは確かzip形式で解凍するとSUNWjナントカというパッケージフォルダがいくつか出てきたはずだったが・・・
そしてマニュアルには,以前は上述したように前のバージョンを削除せよとあった記述がない。この.shを実行しろとある。実行すると,まるでWindowsのようなインストーラがGUIGUIと立ち上がった!
さらに,SDKをインストールする場所を指定せよとある。デフォルトは/usr/j2seだったが,$HOME/jdk1.4にしてみた。するとそういうフォルダはありませんが作成しますか,ときいてくれた!
オッケー!これなら,OS全体の1.3環境を壊すことなく,1.4を使いたいユーザを別に作ってそのホームディレクトリに1.4を入れればいい。BladeでバカバカSun ONEを試せるぜッ。

2002年10月06日

ページ先頭に戻る


Sun ONE 構想に対する苦言

だが理解する前にわたしにはこの新しい構想にひとつ苦言を呈したいことがある。それは

言いにくい

「サンワン」・・・いちど「ン」とハナに抜けてから「ワ」でまた「ン」とハナに抜けるこれが言いにくいのだ。きっと英語だと韻を踏んでるってヤツなんだろうが。
これについてはMSの「ドットネット」のほうが格段に言い易い。「ドット」というヤクザなニュアンスもオタクっぽくて悪くない(どこがどう)・・・わたしの記憶する限りではSunの「ドットコム」のほうが先で,「ドットネット」はそのまねッ子くさいところがあるように思うんだけど。少なくとも「フォルテ」を続けた方が「サンワンストゥディオ」よりは言いやすいのに。だが「ドットネットパスポート」よりは「リバティー・アライアンス」のほうが格段上品だ。そんなことはどーでもいーんだが。

2002年10月06日

ページ先頭に戻る