2021年09月16日

Creative Cloud Desktop に休日2日ほど食われた話

Adobe Creative Cloud Desktop。
何もない時は良いのだけれど、一旦トラブると底なしに時間を奪うやっかいなヤツ。

なんか知らないうちにAdobeソフトの認証外れてて。
認証得るためにCreative Cloud Desktop アプリを立ち上げたのですよ。そしたら。

「Creative Cloud読み込み中…」となったまま進まない現象に遭遇しました。

Adobeはなんだかんだ言ってネットサポートページが充実していますので
ネット検索を掛けたら、対応するAdobeのトラブルシューティングページはすぐ見つかりました。
けれど。トラブルに遭遇したことのある人ならおわかりでしょうけれど。
これが泥沼の始まりなのでした。

トラブルシューティングを上から順に試すも動かない。
全部試しても動かない。
関連ページを探してそこのトラブルシューティングを試してもやっぱり動かない。
……Adobeソフトあるあるですが。

ログ収集ツールを使って取得したよくわからない膨大なログを追いかけて、
何回か収集かけて差分を見て
ネットワーク周りで何かがタイムアウトしているのが原因っぽいというところまでは掴んだのですが、

Cleaner Tool でAdobe関係まるごと消してから再インストールしても問題が解決しない、とゆーのは流石に心折れますな。
AdobeのServer Statusのサイト見ても、障害が発生している様子はないし。

結局何が原因だったかはよくわからなかったのですけれど、
・Proxyの設定を「自動的に取得」ではなくて直接記述してみる
・VM上のNAT環境だったので、ブリッジ接続にしてみる
2つを同時に行ったら、無事サインインできましたよ。

んで一旦サインインできたら、こいつらを元に戻しても特段問題なさそうなんですよねー。
とゆーか元々別にこんなことしなくても使えていたのだし。
ホント、何が原因だったんだか。

Creative Cloud Desktopアプリには、
この春先にも「どうやってもAdobeサーバーに繋げない」というトラブルで数日ほど時間を食われています。
仕事の都合上Win7環境だったのですが、本当に何をやってもダメで。
ログ収集ツールで得たログで「Adobe側から蹴られている」ということはわかったので
最終手段としてWin10にアップグレードしたら、実にあっさり解決したのですが。
結局これはどうもTLS1.2が絡んでいたらしく。
今回のトラブルでAdobeのサイトを見たら、今年の春過ぎにそういう記事が追加された模様で。
そんなもんノーヒントでわかるかい
続きを読む
posted by Μεω. at 21:21| Comment(0) | TrackBack(0) | 日記

2021年07月04日

DBeaver 21.1.1+MariaDBで、日本語カラム名に設定された外部制約が表示されない

DBeaver、ちょー便利。

ただ日本語テーブル・日本語カラム名を持つ MariaDB なDBを開くと、DDLでは確かに定義されている外部制約がまるっと表示されないという状況が以前からありまして。H2 Databaseでは普通に表示されるのになーと思いながら使ってました。取りあえず表示だけなので。

ですが最近になって、MariaDB なDBについてDBeaverのER図を使いたいとなった時にどうしてもこの「外部制約がまるっと表示されない」という点が障害になってしまって。なんとかならんもんかといろいろ試したわけですよ。

結論は、日本語カラム名のときに外部制約が表示されない(DBeaverで、文字化けした日本語カラム名を外部制約先として探しに行こうとしてエラーになっている)、というものでした。
H2 Databaseでは普通に表示されるしER図も問題ないので、MariaDBを(もしかしたらMySQLも)扱う時のみの問題のようです。
日本語カラム名を使うという仕様なので困るー。

結局どうしたかと申しますと。MariaDBからDDL吐いて、SQLを修正してH2 Databaseに取り込みましたですよ。ER図を出すためだけに。

そのうち修正されるとは思いますが、この不具合を見つけて少なくとも年単位でそのままですので、issuesに登録しないと下手したらずっとこのままと言う可能性も。とはいえGitHubアカウント作らないとissuesに登録できない、というのも面倒だのう。
続きを読む
posted by Μεω. at 22:31| Comment(0) | TrackBack(0) | 日記

2019年04月21日

ちょっとハマったので書いておく

同じことに悩んでいる人がいるかもしれないので。


eclipse & modular (project jigsaw)なプロジェクトで、本番のコードツリーのmodule-info.javaにJUnit5への依存を残したくない

  • 本番のコードとテストのコードで、プロジェクトを分けます。
    eclipseでは一つのプロジェクトにはmodule-info.javaは一つしか置けないため、module-infoを切り替えるには、プロジェクトを分けるしかありません。
  • module-infoは本番のコードの方に置き、テストのコードの方には置きません。
  • テストのコードのビルドパス設定で、本番のコードのプロジェクトへの参照を記述します。このとき、
     本番のコードのプロジェクトはmodularとして記述します。
     かつ、そのプロジェクトにpatch-moduleするように設定します。junitへの add-reads も足しておきます。
  • このpatch-moduleとかの設定は、本来ならテストのコード側でJUnit runnerを実行させる時の実行設定に自動的に入るはずなのですが、上手く入らないことが多々あります。その場合、自分で実行設定に追記します。

buildshipを使っている場合は、eclipse pluginを設定して、そこで上のようなことを記述すればなんとかなるかも。buildshipでのテストとeclipse でのJUnit runnerの共存は諦める方が、精神衛生上は良いですが。


log4j2 2.10以上をeclipseのmodularなプロジェクトで使うと、なんか上手くビルドできない

eclipse 2018-12である程度マシに、2019-03でもう少しマシになっているようです。
log4j2(log4j.api)のみを使うなら2018-12でいけそうです。log4j.apiとlog4j.coreの両方を使う時は、log4j2 を2.9.1以下に落とすか、eclipse 2019-03以上を使ってください。


eclipse 2019-03で、modularなプロジェクトのリファクタリングが頻繁に失敗する(まともに動かない)

eclipse 2019-03 のバグです。BugID 545293
パッチが出てるようですので、当てましょう。


log4j2で、ログ出力をキャプチャしてGUIなどに表示したい

カスタムAppenderを作り、それをプログラム内で動的にConfigurationやLoggerなどにaddすれば実現できます。
なお、AutoClosableが設定されているからとtry-with-resourceで書いてしまうと、上手くいきません。close()呼び出しによってカスタムAppender設定が破棄されてしまうようです。キャプチャの用事が済んでからclose()してください。

タグ:JAVA Eclipse
posted by Μεω. at 23:33| Comment(0) | TrackBack(0) | 日記