spring-book-starter-loggingとspring-book-starter-web

アプリケーションログとspring-book-starter-loging
Javaのログシステムは多種多様であり、java.utilからデフォルトで提供されたログサポート、log 4 j、log 4 j 2、commons logingなど、複雑で多様なので、アプリケーションログシステムの構成は特殊であり、spring-boot-starter-logingも特殊であり、以下は私たちが初めて知っている自動配置依存モジュールとします.
maven依存にspring-boot-starter-loggingが追加された場合、以下のコードの通りです.

<dependency>
    <groupId> org.springframework.boot groupId>
    <artifactId> spring-boot-starter-logging artifactId>
dependency>

じゃ、私達のSprigBootアプリケーションは自動的にlogbackをアプリケーションログフレームとして使用します.SprigBootが起動する時、org.sprigframe eweet.boot.logging.Logg-Applicatin-Listenerは状況によって初期化して使用します.
SpringBootは私達に多くのデフォルトのログ構成を提供してくれます.だから、spring-boot-starter-logingを現在のアプリケーションに依存して参加しているclasspathであれば、「開梱即用」で、余分な配置は必要ないですが、デフォルトのSpring Bootに提供されるアプリケーションログの設定を調整すると、いくつかの方法で配置調整ができます.

はlogbackの約束に従い、classipathに自分でカスタマイズしたlogback.xmlのプロファイルを使用する.

は、ファイルシステムのいずれかの位置に自分のlogback.xmlプロファイルを提供し、その後、このプロファイルに対してloging.co nfig構成項目を介してこのプロファイルを指すことによって、appication.propertiesで以下のような構成を指定する.

logging.config=/{some.path.you.defined}/any-logfile-name-I-like.log

SpringBootデフォルトでは、プロファイルやコマンドラインなどのプロファイルやloging.fileやlogging.pathを使って定義されたログファイルの名前や保存先からのパスを許可していますが、Spring Bootフレームであらかじめ定義されているデフォルトログシステムの設定をもとに、限定的な設定をするだけで、より柔軟な構成を望むなら、フレームの特定の構成によって、対応するプロファイルを提供し、その後、loging.co nfigによって有効化することが望ましい.
もし皆さんがロゴ4 jやロゴ4 j 2を使用することに慣れているなら、それに対応するspring-boot-starter依存モジュールをMaven依存モジュールに追加しても良いです.

<dependency>
    <groupId> org.springframework.boot groupId>
    <artifactId> spring-boot-starter-log4j artifactId>
dependency>

または

<dependency>
    <groupId> org.springframework.boot groupId>
    <artifactId> spring-boot-starter-log4j2 artifactId>
dependency>

しかし、これらの同じ目的を達成したspring-boot-starterを依存に加えないでください.
高速Webアプリケーション開発とspring-boot-starter-web
このインターネット時代、Springフレームを使って、少数の独立したアプリケーションを開発する以外に、ほとんどの場合は実際にSprigMVCを使ってwebアプリケーションを開発しています.高速なウェブプロジェクトを簡単に構築して開発するために、Spring Bootはspring-boot-starter-web自動配置モジュールを提供してくれました.
spring-boot-starter-webをプロジェクトに参加するmaven依存であれば、

<dependency>
    <groupId>org.springframework.bootgroupId>
    <artifactId>spring-boot-starter-webartifactId>
dependency>

直接実行可能なWebアプリケーションを入手しました.現在のプロジェクトでmvn spring-boot:runは組み込み型tomcatサービス要求を使用したWebアプリケーションを直接起動できます.ただし、サービスWeb要求のControllerはまだ提供されていません.だから、どんな経路でもSpringBootデフォルトで提供されたエラーページに戻ります.(一般的にはwhitelabel error pageと呼ばれています.)現在のプロジェクトの下でサービスルートのWeb要求のControllerを新たに作成することができます.

@RestController
public class IndexController {
    @RequestMapping("/")
    public String index() {
        return "hello, there";
    }
}

mvn spring-boot:runを再起動してアクセスします.http://localhost8080、エラーページは私たちのControllerが返信するメッセージに取って代わられます.簡単なWebアプリケーションはこのように完成しました.
しかし、簡単な裏には、多くの「暗黙のルール」があります.私たちはこれらの「暗黙のルール」を十分に理解してこそ、よりよくスプリング・book-starter-webを使うことができます.
プロジェクトの構造レベルの約束項目の構造レベルと伝統的なwarにパッケージされたJava Webアプリケーションの違いは、静的なファイルとページテンプレートの保存位置が変わったことにあります.元々はsrc/main/webappディレクトリの下に置かれていた一連のリソースが、現在はSrc/main/resource対応サブディレクトリの下に統一されています.

src/main/resource/staticは、css、jsなどの各種の静的リソースを保存するために使用されます.

src/main/resource/templatesは、＊.vmなどのテンプレートファイルを保存するために使用されます.

もちろん、SpringBootではなく、warパッケージとして、独立したjarパッケージ形式でWebアプリケーションをリリースしたいなら、Java Webアプリケーションの元のプロジェクト構造の予約を継続することもできます.
SpringMVCフレームレベルの約束とカスタマイズspring-boot-starter-webデフォルトは以下のようなSprigMVC必須コンポーネントを自動的に配置します.

必要なView Resolover、例えばContingNegotitView ResolaverとBen-Name View Resoliver.

必要なコンバクタ、GeneraicCoverter、FormaterなどのbeanをIoC容器に登録します.

は、ウェブ要求および対応するタイプ変換をサポートするために、一連のHttpMessage Coverterを追加する.

自動的にMessage CodesResolaverを設定して登録します.

その他.

いつでも、デフォルトで提供されたSpringMVCコンポーネントの設定に不満があれば、IoC容器に新しい同タイプのbean定義を登録して置換したり、WebMvcConfigrer Adapterタイプに基づくbean定義を直接提供してカスタマイズしたり、@EnbaleWebMvcと表示された@Configration配置類を直接提供してもすべてのSpringVC Mfrationを接収します.の関連配置について、自分で完全に再配置します.