発行元を確認できませんでした 回避策
発行元を確認できませんでした。回避策PartII
WindowsXP SP2からセキュリティ対策で導入された機能。 フリーソフトなどインターネットからダウンロードしたファイルを実行すると出るようになった警告である。 信頼できるサイトから落としてきた場合は余計なお世話なので解除する。 解除するには実行ファイル(ショートカットではだめ)のプロパティを開き先般タブの下のほうにブロック解除があるのでそれを選んで適用すればよい。
« 2008年12月 | メイン | 2009年02月 »
SeaSar2プロジェクトのSuperAgileStruts
設定ファイルを書かなくていい&HotDeploy対応なのでほんとさくさくと開発が進められる。
HelloWorldを出すのに何ステップも手順が必要だった従来のStrutsよりはるかに使いやすい
そして公式ドキュメントにも記載があるが、リクエストごとにActionインスタンスを生成するのでスレッドセーフである。
今まではUserAgentSwitcherを使っていたが、月日とともにさらに便利なものが出てくる。
というわけでFire Mobile Simulatorを利用してみた。
あらかじめ代表的な端末の設定がされており、見え方も携帯っぽくなるのでよろしい。
あまり需要がないかも知れないが、sambaの設定確認などで別のユーザとして入りなおしたいケースがある。ログオフすれば一発だが、それではめんどくさい。
そんなときはコマンドプロンプトからセッションを切ってやる。
ネットワーク接続されているフォルダが
\\network
であるならば、コマンドプロンプトで以下のように入力
net use \\network /delete
これでOK。反映されるにはちょっとタイムラグがある。
偽装というと悪の響きだが、実際には開発の現場においてCookieの中身を確かめたいときにも使える。
IEにもFirefoxにもCookie Editorというのがあり、実際以前の現場で使ったことがあった。
HTTPヘッダをいじれるツールがあればそれでもいいのだが、Cookieを変更したい時にはそれだけにフォーカスしているほうがわかりやすい。
昨日も出た。
前回のエントリーでは以前のバージョンでクラスのコンパイルし直しだったが、今回の根本原因はJDKが複数はいっており、古いJDKで実行しようとしていたことであった。
なのでJDK6にJAVA_HOMEを向けてやれば再コンパイル不要。
たまに行儀悪いアプリケーションが勝手にJDKのパスを書き換えて、知らない間に動作しなくなることもあるので、どのアプリを実行するにしても個別にJAVA_HOMEを設定しておくことをお勧めする。
こちらもより詳細にエントリーを書き直しました。リンク先を御覧ください。
これもよく遭遇するといえば遭遇するエラー
エラーメッセージの日本語訳が微妙なのと、該当コンテキスト以外はTomcatが正常に動いており、404を返すのでなんで??と思ってしまいがち。
根本原因はweb.xmlやfilterなどの設定がおかしいためこのコンテキストの初期化に失敗しており、その場合Tomcatはそのコンテキストが存在しないものとして扱う。というわけで404エラーがでていたらちゃんとTomcatのログを見よう。特にweb.xmlを大幅に編集する場合は、事前に動いているweb.xmlのバックアップを取得しておくべきだろう。
普通のメーラーだと振分け条件が一致したときはメールを移動して、それ以降の処理はそのメールに関しては適用されないのだが、さすがMS製品バグとも思える仕様で複数条件に該当すればその分メールがコピーされるというトホホな仕様。
最新の2007ではどうかわからないけど、2002と2003ではそう。
このメールダブりを防ぐためには仕分けルールの最後のフォルダ移動のタイミングで「ルールの処理を中止する」を付け加えなければならない。
outlokkなんぞ使いたくないが、exchangeと統合されており、他のPOPメーラーが使えないのでしょうがない。
とくにTomcatアプリを開発しているときにクラスを更新したときに、よく起こりがち。
この対処法としてはWindowsがおかしくなったときと同様再起動にかぎる。
Tomcatを再起動してみる。たいていこれでOK
それでもだめならeclipseも再起動。
eclipseは特定のフォルダーに依存はしないで、移動しても動くのだが、キャッシュなどが残って旧フォルダを参照しているときに動きがおかしいときの対処法