なんか良くわからないエラー (no [ライブラリ名] in java.library.path みたいなヤツ) が出てきたのだけれど、解決方法が java.library.path の設定ではなく、LD_LIBRARY_PATH の設定だったりした。この手のエラーに苦しめられ続けており、そのあたり、ちょっと掘り下げてみる。 java.library.path java.library.path がどこで使われているかというと、ClassLoader で使われている。 実際、ClassLoader#findLibrary の JavaDoc には ネイティブ・ライブラリの絶対パス名を返します。VMは、このメソッドを呼び出して、このクラス・ローダーによってロードされたクラスのネイティブ・ライブラリを検索します。このメソッドがnullを返す場合、VMは「java.library.path」プロパ

認証情報を内部で持っているのだが、認証に関しての手順はすっ飛ばしてた。 Cloud API サービスに対する認証に書いてある通りに手順を実行してサービスアカウントのJSONファイルをダウンロードした。 どうやってその内容をライブラリに渡すか。。 ネットで調べると大体専用の環境変数に突っ込んでパスを参照するように書かれていた。 恐らくサンプルコードはそれで動くのだろう。 でも環境変数からパス取得って。。 ちゃんとアプリケーションプロパティから取りたい。 ImageAnnotatorClientのJavadocを読んでみると次のような記載が。 This class can be customized by passing in a custom instance of ImageAnnotatorSettings to create(). For example: InstantiatingC

先日 Azure App Service on LinuxのJava対応プレビューが公開されました。 azure.microsoft.com まあ他の言語と違ってJavaの場合は、(Azure上の)Windowsの環境にデプロイして動いているんだったらそれでよくね、という話もあるのですが、LinuxのPaaS上でJavaが動くとうれしいこともあるのでしょう。多分。 本エントリーでは、Spring Boot2.0のアプリケーションをAzure App Service on Linuxにデプロイしてみます。 デプロイするアプリケーションをWAR形式にする。 Azure App Service on Linuxで動かすにはWAR形式のデプロイが必要なので、Springのドキュメントに従って アプリケーションをWAR形式にします。Spring Initializrで作成されるアプリケーションからの

フィードバックを送信 Cloud Endpoints for gRPC コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 gRPC は、Google が開発した高性能で汎用的なオープンソース RPC フレームワークです。gRPC を使用すると、クライアント アプリケーションは、別のマシンのサーバー アプリケーション上のメソッドを、ローカル オブジェクトと同様に直接呼び出すことができます。これにより、分散アプリケーションや分散サービスを簡単に作成できます。 gRPC を使用する主な利点は、ドキュメントです。サービス構成と API インターフェース定義ファイルを使用して、API のリファレンス ドキュメントを生成できます。詳細については、デベロッパー ポータルの概要をご覧ください。 API 管理 Endpoints は、Extensible Service Pr

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

Spring BootでWARを作成して別のTomcatにデプロイするでも書いた通り、開発中はSpring Bootの組み込みTomcatを使って開発するが、テスト環境や本番環境では予め用意されている別のTomcatにWARをデプロイして動作させる、なんてケースがあると思います。その時のapplication.propertiesってどうしていますか？という話です。 例えば、dev1～dev3という環境があるとします。dev1にはdev1の設定(DBの接続先やスキーマ等)を持っているapplication.propertiesを、dev2にはdev2の設定を持っているapplication.propertiesを、dev3にはdev3の設定を持っているapplication.propertiesをビルド時にWARに含めちゃえばいいと思いませんか？ Spring Bootのprofile機能

.Net Coreアプリ作ったのならLinuxで公開したい！って思ったものの、あまり必要性が感じられなかったので手付かずだったのですが値段見たらまぁびっくり！ Windows Linux ３０００円近くも変わるじゃん！前はほぼ値段変わらなかったのになぜにこんな差が。。まぁそんなこんなでみんなの洋楽ランキングLinuxサーバに移行計画を立てました。PaaSだからGithubブランチ指定してすんなり行くと思いきや、まったくダメで情報も全然無くて結構大変だったので丁寧に書いておきます。 Web Appをたてる OSはLinux、公開はコード、ランタイムスタックは.Net Core 2.1で。Dockerの方が値段安いっぽいけどちゃんと調べてないから次回へ（たぶんやる）。しかも今ならB1インスタンスが１ヶ月無料なのでやりたい放題っす。 Githubのブランチからデプロイ Github、Bitbuc