気がついたら年が明けてしまいました。
前の更新から丸半年経った現在、
私は今の勤め先でシステムのテストを担当することが多くなったわけですが
追加開発をした後テスト仕様書を作成して単体・結合テストからシステムテストまで私は1人でやってます。
テスト仕様書を作るときなんかは、引き継いだ人の誰が見ても分かりやすく観点もMECEを心がけて残しています。(それでもなお上長のレビューで過不足している観点があったりして書き直しているわけですが)
テスト仕様書を作り終わったら今度はテスト自動化の為のテストコードをがりがり書いているわけです。
普段仕事では、Javaを使っているのでテスト自動化ツールはJUnitとか。
あとWebシステムのテスト自動化ツールとしてJenkinsとかSeleniumとか使っています。
とても地味な作業ですが確りしたシステムを構築するためには必要な工程です。
しかし夜、一人でテストコードを書いていてふと学生だった頃を思い出しました。
私は一技術大学学生でしたので
オブジェクト指向がどうこうのとか、クラスライブラリがどうなってるとか、
構築の話にばかり焦点が当てられ、テストや運用はあまり触れられておらず、
テストや保守の奥深さも知ることができませんでした。
Webシステム開発の演習という授業がありました。
当時はプログラミングの授業の中では、
実践に近い環境で企画から設計からコーディングまでして発表するプログラミング好きな大学生にとってはおいしい授業でした。
しかしそんなおいしい授業は成果物にだけ焦点が当てられ、その過程のテストだとか保守のしやすさとかは評価されません。
システム開発はどうやって手間をかけないで運用するとか。
どうやって自動でテストするようにするとか。
どうやってコードを書かないで、期待通りに効率的にシステム化するとか。
今思うとそういう中身のない、コスト面も運用面も品質も全く無視でただ作ることが目的になっている演習でした。
大学の講義でこそ、
テストの大切さと奥深さを教えたほうがいいのでは、
と思いながらテストケースを書いている日々でした。
作業報告ログ
techな作業logを淡々とechoしていく。 Google App Engine, Google Compute Engineが8割
2015年3月3日火曜日
2014年9月21日日曜日
リモートで電源を入れてリモートデスクトップ接続してみた
いろいろあってご無沙汰な更新になってしまいましたが、
Windows7 からリモートでUbuntu14.04 を操作できたので実現方法を書いておきます。
今日やりたいこと
まず、「リモートで電源を入れる」
これは電源が入っていないパソコンにLANをつなげて、クライアントマシンから電源制御の信号を送って電源を入れるということです。
そんなことできるのか…と調べてみるとマジックパケットという技術があるらしく、
リモートマシン側の設定とマジックパケット転送アプリで実現できるとのことです。
このアプリにリモートマシンのIPアドレスとMACアドレスを入れてパケット転送すると、そのマシンの電源が入るようになります。
IPアドレスとMACアドレスはクライアントマシンとリモートマシンをLANで接続したときに
ifconfigコマンド等で確認しておきます。
次は「リモートデスクトップの設定」です。
Windows7 からリモートでUbuntu14.04 を操作できたので実現方法を書いておきます。
今日やりたいこと
- リモートで電源を入れる
- リモートデスクトップ
まず、「リモートで電源を入れる」
これは電源が入っていないパソコンにLANをつなげて、クライアントマシンから電源制御の信号を送って電源を入れるということです。
そんなことできるのか…と調べてみるとマジックパケットという技術があるらしく、
リモートマシン側の設定とマジックパケット転送アプリで実現できるとのことです。
1.準備
クライアントマシン側(Windows7)
クライアントマシンにはマジックパケット転送アプリとしてWinWolを入れてみました。このアプリにリモートマシンのIPアドレスとMACアドレスを入れてパケット転送すると、そのマシンの電源が入るようになります。
IPアドレスとMACアドレスはクライアントマシンとリモートマシンをLANで接続したときに
ifconfigコマンド等で確認しておきます。
リモートマシン側(Ubuntu14.04)
BIOSにリモート電源制御(Wake on LAN)という項目があるので、もし「使用しない」になっていたら「使用する(Enable)」に変更します。
これで準備完了です。
試しにLANクライアントマシンからWinWolでマジックパケットを送ってみるとリモートPCは電源ボタンを押していないのにも関わらず電源がオンになりました。次は「リモートデスクトップの設定」です。
クライアントマシン側(Windows7)
リモートデスクトップのクライアントマシンに設定できるエディションが限られているのでこちらで確認します。リモートマシン側(Ubuntu14.04)
Ubuntu 14.04 にリモートデスクトップのサーバソフトウェアをインストールします。
sudo apt-get install xrdp
続いて、現状Unity(Ubuntu14.04に入ってるGUI)がリモートデスクトップに対応していないらしく、リモートマシンの描画の為にLXDEをインストールします。
sudo apt-get install lxde
.xsessionを作成します。
echo lxsession -s LXDE -e LXDE > ~/.xsession
これで設定完了です。XDRPを起動します。
sudo service xrdp restartログイン画面で下図赤枠のUbuntuマークをクリックしてUbuntu(デフォルト)からLXDEを選択して一度ログインします。
LXDEのデスクトップが表示されれば準備完了です。
* xrdpとlxdeはUbuntu14.04より古いバージョンだとリポジトリが古いので手動でインストールする必要があります。
2.接続方法
Windows7標準で入ってるリモートデスクトップ接続にリモートマシンのIPアドレスを入れます。
正常に接続するとxrdpの画面が表示されるのでログインします。
ログインが成功するとLXDEのデスクトップ画面が表示されます。
シャットダウンするときは、Terminalから
sudo shutdown -P now
を入れるだけでシャットダウンできます。これでPCを遠隔で付けたり消したりできるようになります。
2014年2月9日日曜日
[GAE/PHP] GAEでWordpressを動かす
Wordpressと縁のある昨今です。
今更ながら、Google App EngineでWordpressを動かしてみたいと思います。
Wordpressは、サーバとPHPとMySQLが揃っていれば動作しますが、Google App Engineでは、MySQLの代わりにGoogle Cloud SQLを使用します。また、Wordpressに画像をアップロードするときには、Wordpressフォルダ上に入れることができないので、Google Cloud Storageを使います。
https://cloud.google.com/console/project
Project IDは、my-wordpress-page にします。
続いて、こちらをダウンロードして展開してください。
http://ja.wordpress.org/latest-ja.zip
projectという名前を付けた新しいフォルダに、展開したwordpressを移して、app.yaml、cron.yaml、php.iniを新規作成します。
app.yaml、cron.yaml、php.iniには、それぞれ以下のように記述します。
【app.yaml】
applicationは、先ほど作成したProject IDのmy-wordpress-pageと書き換えます。
versionとは、このプロジェクトのversionです。今回は、バージョンを0-1-0にしました。
runtimeはphpを、api_versionは1に設定します。
handlersは、Javaでいうとweb.xmlに記載されたwebページのルーティング方法なので、今回はいじりません。
【php.ini】
【cron.yaml】
これもこの通りに書いてください。
左のメニューからCloud SQLを選択して、NEW INSTANCEでCloud SQLインスタンスを生成します。
CloudSQLインスタンスのInstance IDは、my-wordpress-page : ins-wordpressにします。
Project IDであるmy-wordpress-pageは既に決まっているので、ins-wordpressのみ書き入れます。
Billing Planですが、あまりアクセスがないのならPer Userで良いですが、頻繁にアクセスが有ると考えられる場合は、Packageの方が割安でしょう。
最後に右側のConfirmボタンでインスタンスを作成します。
インスタンスが生成されました。
予め、データベース名、データベースにアクセスする用のユーザ名、そのユーザのパスワードを決めておきます。
データベース名:wp-database
ユーザ名:devuser
パスワード:mypasswordpress
これをSQL文に書き写します。
【create.sql】
注意するべきところは、MySQLのホスト名です。
Google Cloud SQLでは、:/cloudsql/my-wordpress-page:ins-wordpress という書き方をします。
また、インスタンス名とデータベース名を混同しないようにしてください。(データベース接続エラーと表示されます。)
デプロイコマンドは、
appcfg.pyがありません等言われた場合は、フルパスで入れてください。それと、pythonで動きますので、pythonを使えるようにインストールしておきましょう。
http://my-wordpress-page.appspot.com/にアクセスすると、Wordpressが確認できました。
今更ながら、Google App EngineでWordpressを動かしてみたいと思います。
Wordpressは、サーバとPHPとMySQLが揃っていれば動作しますが、Google App Engineでは、MySQLの代わりにGoogle Cloud SQLを使用します。また、Wordpressに画像をアップロードするときには、Wordpressフォルダ上に入れることができないので、Google Cloud Storageを使います。
1.プロジェクト作成とWordpressダウンロード
こちらにて、プロジェクトを作成してください。https://cloud.google.com/console/project
Project IDは、my-wordpress-page にします。
続いて、こちらをダウンロードして展開してください。
http://ja.wordpress.org/latest-ja.zip
projectという名前を付けた新しいフォルダに、展開したwordpressを移して、app.yaml、cron.yaml、php.iniを新規作成します。
app.yaml、cron.yaml、php.iniには、それぞれ以下のように記述します。
【app.yaml】
application: my-wordpress-page
version: 0-1-0
runtime: php
api_version: 1
threadsafe: true
handlers:
- url: /(.*\.(htm$|html$|css$|js$))
static_files: wordpress/\1
upload: wordpress/(.*\.(htm$|html$|css$|js$))
application_readable: true
- url: /wp-content/(.*\.(ico$|jpg$|png$|gif$))
static_files: wordpress/wp-content/\1
upload: wordpress/wp-content/(.*\.(ico$|jpg$|png$|gif$))
application_readable: true
- url: /(.*\.(ico$|jpg$|png$|gif$))
static_files: wordpress/\1
upload: wordpress/(.*\.(ico$|jpg$|png$|gif$))
- url: /wp-admin/(.+)
script: wordpress/wp-admin/\1
secure: always
- url: /wp-admin/
script: wordpress/wp-admin/index.php
secure: always
- url: /wp-login.php
script: wordpress/wp-login.php
secure: always
- url: /wp-cron.php
script: wordpress/wp-cron.php
login: admin
- url: /xmlrpc.php
script: wordpress/xmlrpc.php
- url: /wp-comments-post.php
script: wordpress/wp-comments-post.php
- url: /(.+)?/?
script: wordpress/index.php
applicationは、先ほど作成したProject IDのmy-wordpress-pageと書き換えます。
versionとは、このプロジェクトのversionです。今回は、バージョンを0-1-0にしました。
runtimeはphpを、api_versionは1に設定します。
handlersは、Javaでいうとweb.xmlに記載されたwebページのルーティング方法なので、今回はいじりません。
【php.ini】
google_app_engine.enable_functions = "php_sapi_name, gc_enabled"Google App Engineでphpを有効にします。これはその通りに書いてください。
【cron.yaml】
cron:schedule: every 2 hours/wp-cron.phpを2時間毎に実行するようにcronを記述します。
- description: wordpress cron tasks
url: /wp-cron.php
これもこの通りに書いてください。
2. Google Cloud SQLインスタンスの生成
Google Cloud SQLは、プロジェクトにクレジットカードを登録して課金を有効にしないと使えませんので、有効にしてください。(使い方にもよりますが、私は月2000円はいかない程度です。また、設定はいつでも変更できます。課金の設定はこちらから)左のメニューからCloud SQLを選択して、NEW INSTANCEでCloud SQLインスタンスを生成します。
CloudSQLインスタンスのInstance IDは、my-wordpress-page : ins-wordpressにします。
Project IDであるmy-wordpress-pageは既に決まっているので、ins-wordpressのみ書き入れます。
Billing Planですが、あまりアクセスがないのならPer Userで良いですが、頻繁にアクセスが有ると考えられる場合は、Packageの方が割安でしょう。
最後に右側のConfirmボタンでインスタンスを作成します。
インスタンスが生成されました。
3. Google Cloud SQLインスタンスにデータベースを作成
WordpressがGoogle Cloud SQLのデータベースにアクセスできるようにします。予め、データベース名、データベースにアクセスする用のユーザ名、そのユーザのパスワードを決めておきます。
データベース名:wp-database
ユーザ名:devuser
パスワード:mypasswordpress
これをSQL文に書き写します。
【create.sql】
CREATE DATABASE IF NOT EXISTS wp-database;
CREATE USER 'devuser'@'localhost' IDENTIFIED BY 'mypasswordpress';
GRANT ALL PRIVILEGES ON wp-database.* TO 'devuser';
データベースとユーザを作成して、アクセス権限を付与させます。
続いて、Google Cloud Storageを有効にします。こちらも課金しないと使えないので課金を有効にしておいてください。今回、Google Cloud Storageを使用する理由は、Wordpressには直接関係ありませんが、上で作成したSQLファイルをアップロードしてCloud SQLインスタンスにインポートする為に必要です。ですので、Storageを有効にしてください。(インポートが完了したら無効にしてもかまいません)
Google Developer Consoleの左のメニューから、Cloud Storageを選択し、NEW BUCKETという赤いボタンをクリックします。New Bucketというウィンドウが表示されますのでバケット名(今回は、wp-backet)を入力してcreateし、新しく作成したバケットを開きます。
UploadからFIlesを選択します。
データベース生成用のSQLファイルがアップロードできました。
Cloud SQLの画面に戻り、my-wordpress-page : ins-wordpressを開きます。画面上側に import... があるので、クリックします。Import Dataといウィンドウが表示されますので、Google Storage Pathをgs://先ほど作成したバケット名wp-backet/先ほど作成したcreate.sqlにして、OKを押します。
Operationsから先ほどのSQLインポートの結果が確認できます。
Import from gs://wp-backet/create.sql succeeded.
wordpress/wp-config.phpを開いて、先ほど設定したID等に書き換えます。
Project ID:my-wordpress-page
インスタンス名:ins-wordpress
データベース名:wp-database
ユーザ名:devuser
パスワード:mypasswordpress
【create.sql】
続いて、Google Cloud Storageを有効にします。こちらも課金しないと使えないので課金を有効にしておいてください。今回、Google Cloud Storageを使用する理由は、Wordpressには直接関係ありませんが、上で作成したSQLファイルをアップロードしてCloud SQLインスタンスにインポートする為に必要です。ですので、Storageを有効にしてください。(インポートが完了したら無効にしてもかまいません)
Google Developer Consoleの左のメニューから、Cloud Storageを選択し、NEW BUCKETという赤いボタンをクリックします。New Bucketというウィンドウが表示されますのでバケット名(今回は、wp-backet)を入力してcreateし、新しく作成したバケットを開きます。
UploadからFIlesを選択します。
データベース生成用のSQLファイルがアップロードできました。
Cloud SQLの画面に戻り、my-wordpress-page : ins-wordpressを開きます。画面上側に import... があるので、クリックします。Import Dataといウィンドウが表示されますので、Google Storage Pathをgs://先ほど作成したバケット名wp-backet/先ほど作成したcreate.sqlにして、OKを押します。
Operationsから先ほどのSQLインポートの結果が確認できます。
Import from gs://wp-backet/create.sql succeeded.
4. Wordpress側でデータベースの設定
Google SQLの方は、準備が整いましたので、Wordpress側でデータベースの設定を行います。wordpress/wp-config.phpを開いて、先ほど設定したID等に書き換えます。
Project ID:my-wordpress-page
インスタンス名:ins-wordpress
データベース名:wp-database
ユーザ名:devuser
パスワード:mypasswordpress
【create.sql】
/** WordPress のためのデータベース名 */
define('DB_NAME', 'wp-database');
/** MySQL データベースのユーザー名 */
define('DB_USER', 'devuser');
/** MySQL データベースのパスワード */
define('DB_PASSWORD', 'mypasswordpress');
/** MySQL のホスト名 */
define('DB_HOST', ':/cloudsql/my-wordpress-page:ins-wordpress');
注意するべきところは、MySQLのホスト名です。
Google Cloud SQLでは、:/cloudsql/my-wordpress-page:ins-wordpress という書き方をします。
また、インスタンス名とデータベース名を混同しないようにしてください。(データベース接続エラーと表示されます。)
5. デプロイして確認
いよいよデプロイ(アップロード)します。SDK for PHP からappcfgツールをダウンロードしてきてください。デプロイコマンドは、
appcfg.py update project/projectフォルダはwordpressが入っているフォルダ名となります。
appcfg.pyがありません等言われた場合は、フルパスで入れてください。それと、pythonで動きますので、pythonを使えるようにインストールしておきましょう。
http://my-wordpress-page.appspot.com/にアクセスすると、Wordpressが確認できました。
2014年2月1日土曜日
[GCE] Google Compute EngineのVMインスタンスとローカル間でファイルのやりとりを行う
サーバとローカルで、ファイルをやりとりするのに、ftpやsftpを良く使いますが、Google Compute EngineのVMインスタンスに、ftpやsftpは使えないそうです。
それぞれ、こんな例で使用します。
(プロジェクトID:mywordpress上にあるwelcome-insインスタンスのdump.zipをローカル環境のDownloadへ持ってくる)
そこで、ftpやsftpの代わりになるコマンドがgcutilで使えるので紹介します。
push・・・ローカルPCからGAEのVMインスタンスへ送信
pull・・・GAEのVMインスタンスからローカルPCへ送信
gcutil --project_id={project_id} push {instance_name} {local_file} {remote_path}
gcutil --project_id={project_id} pull {instance_name} {file_names} {local_directory}
それぞれ、こんな例で使用します。
gcutil --project_id=mywordpress push welcome-ins C:¥Users¥iShimoli¥Desktop¥thema.zip /home/iShimoli
(プロジェクトID:mywordpress上にあるwelcome-insインスタンスの/home/iShimoliにローカル環境のthema.zipを送る)
gcutil --project_id=mywordpress pull welcome-ins dump.zip
C:¥Users¥iShimoli¥Download¥
2014年1月12日日曜日
backlog4jでプロジェクト一覧を取得してみる
Backlogというプロジェクト管理ツールのAPIを使用して、自分が参加しているプロジェクト一覧を取得してみました。
Perl、PHP、Pythonからでも取得できますが、今回はJavaで取得することにします。
JavaでBacklog APIにアクセスする為のクライアントライブラリが用意されていますので、
hakuraiさまのbacklog4jをプロジェクトに取り込んで使用します。
まず、一般ユーザのクライアントを生成します。
それでは自分のプロジェクトを取得してみます。
実行結果
続いて自分のプロジェクト(複数)を取得してみます。
キーがPJT_x-26の課題(issue)を取得してみます。
PJT_x-26の課題のサマリが取得できました。
課題一覧を取得してみます。
課題の状態(未対応・処理中・処理済み・完了)一覧を取得してみます。
課題の状態は静的フィールドかと思いきや、APIで取得しないと取れないものでした。
基本的に、Get****やFind****のオブジェクトにフィルタやソートをかけて、
executeした後に取れるオブジェクトが本体という仕様になっています。
次回は、コメントを追加します。
Perl、PHP、Pythonからでも取得できますが、今回はJavaで取得することにします。
JavaでBacklog APIにアクセスする為のクライアントライブラリが用意されていますので、
hakuraiさまのbacklog4jをプロジェクトに取り込んで使用します。
まず、一般ユーザのクライアントを生成します。
BacklogConfigureBuilder builder = new BacklogConfigureBuilder();
BacklogConfigure config = builder.buildBacklogConfigure();
config.setSpaceId(mySpaceId);
config.setUsername(myUsername);
config.setPassword(myPassword);
BacklogClient client = new BacklogClientFactory(config).newBacklogClient();mySpaceIdは、プロジェクトURL(https://ourSpace.backlog.jp/)のourSpaceに当たる部分です。myUsernameとmyPasswordは、一般ユーザとしてログインする時に入力するユーザ名とパスワードです。MalformedURLExceptionをスローできるようにしておきましょう。
それでは自分のプロジェクトを取得してみます。
GetProject getProject = backlogClient.getProject();
getProject.setProjectKey("PJT_x");
Project project = getProject.execute();
LOGGER.info(project.getName());
Xプロジェクトプロジェクトキーとは、課題のURL(https://ourSpace.backlog.jp/projects/PJT_x)のPJT_xに当たる部分です。このケースでは、PJT_xに対するプロジェクト名が取得できます。
続いて自分のプロジェクト(複数)を取得してみます。
GetProjects getProjects = client.getProjects();実行結果
ProjectList projectList = getProjects.execute();
Iterator<Project> it = projectList.iterator();
while (it.hasNext()) {
Project myProject = it.next();
LOGGER.info(myProject.getId()+" "+myProject.getName());
}
PJT_x XプロジェクトプロジェクトIDとプロジェクト名が取得できました。
PJT_y Yプロジェクト
PJT_z Zプロジェクト
コードを確認しますと、
GetProjectsのインスタンスに、フィルタをセットして、executeするクエリ的に扱います。
Project以外にも、課題やコメント、課題の状態にも同じ方法で取ってきます。キーがPJT_x-26の課題(issue)を取得してみます。
GetIssue getIssue = client.getIssue();実行結果
getIssue.setIssueKey("PJT_x-26");
Issue issue = getIssue.execute();
LOGGER.info(issue.getSummary());
PJT_x-26の課題のサマリが取得できました。
課題一覧を取得してみます。
FindIssue findIssue = client.findIssue();
findIssue.setProjectId(project.getId());
IssueList issueList = findIssue.execute();
Iterator<Issue> issues = issueList.iterator();
while (issues.hasNext()) {
Issue myIssue = issues.next();
LOGGER.info(myIssue.getId() + " "
+ myIssue.getStatus() + " " + myIssue.getSummary());
}
実行結果
1077583463 Status{name='処理済み'} 伝票番号欄が空欄になるバグ
1077346780 Status{name='未対応'} ファイルをアップロードする機能
1077204542 Status{name='処理中'} メニューから案件を選択する機能
1077580378 Status{name='未対応'} 決定ボタンをクリックすると画面が白くなる
1077583839 Status{name='完了'} 既存案件をアップロードするとエラーになる
findIssueは自分が閲覧できる全課題をとってきてます。
setProjectで単一プロジェクトでフィルタして取得してきています。
課題の状態(未対応・処理中・処理済み・完了)一覧を取得してみます。
GetStatuses getStatuses = backlogClient.getStatuses();実行結果
StatusList statusList = getStatuses.execute();
Iterator<Status> statuses = statusList.iterator();
while (statuses.hasNext()) {
Status myStatus = statuses.next();
LOGGER.info(myStatus.getId() + " " + myStatus.getName() + " " + myStatus.getCount());
}
1 未対応 null
2 処理中 null
3 処理済 null
4 完了 null
基本的に、Get****やFind****のオブジェクトにフィルタやソートをかけて、
executeした後に取れるオブジェクトが本体という仕様になっています。
次回は、コメントを追加します。
2014年1月4日土曜日
[GAE/J] Cronがon time failedになる
Google App EngineのCronサービスを使いたくて公式のドキュメントを見たのですが、
どうもダメそうなので試行錯誤してみました。
今回は、appspot.com/cron/backupをcronで動かすことにします。
まず、elipseプロジェクトにweb.xmlとcron.xmlを新規作成します。
cron.xmlを以下のように書きます。
以下の例は、/cron/backupを毎時間叩くように指定します。
cron.xml
はて、cronを動かす為にはqueue.xmlが必要だったのでしょうか。
どうもダメそうなので試行錯誤してみました。
今回は、appspot.com/cron/backupをcronで動かすことにします。
まず、elipseプロジェクトにweb.xmlとcron.xmlを新規作成します。
cron.xmlを以下のように書きます。
以下の例は、/cron/backupを毎時間叩くように指定します。
cron.xml
<?xml version="1.0" encoding="UTF-8"?>
<cronentries>
<cron>
<url>/cron/backup</url>
<description>save contents every 1 hours</description>
<schedule>every 1 hours</schedule>
<timezone>Asia/Tokyo</timezone>
<target>save</target>
</cron>
</cronentries>
次に、web.xmlでルーティングの設定を以下のように書きます。
<servlet>と<servlet-mapping>は、servlet-nameでひもづけします。
web.xml
試行錯誤して、queue.xmlを新規作成します。
queue.xmlは今回使わないので<queue-entries>タグのみ追加。
queue.xml
デプロイして確かめてみると、on time Success
queue.xmlを追加したところ、cronが動くようになりました。<servlet>と<servlet-mapping>は、servlet-nameでひもづけします。
web.xml
<?xml version="1.0" encoding="utf-8"?>デプロイして確かめてみると、on time Failed
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" version="2.5">
<servlet>
<servlet-name>Btools</servlet-name>
<servlet-class>jp.btools.backuperServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Btools</servlet-name>
<url-pattern>/cron/backup</url-pattern>
</servlet-mapping>
<security-constraint>
<web-resource-collection>
<url-pattern>/cron/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
</web-app>
試行錯誤して、queue.xmlを新規作成します。
queue.xmlは今回使わないので<queue-entries>タグのみ追加。
queue.xml
<queue-entries>
</queue-entries>
デプロイして確かめてみると、on time Success
はて、cronを動かす為にはqueue.xmlが必要だったのでしょうか。
登録:
投稿 (Atom)