Il y a des applications Web qui ont été créées il y a longtemps à l'ère de Java 1.4 et qui utilisent toujours Tomcat actif. C'est une histoire quand Embed Tomcat a été introduit par hasard dans un tel environnement de développement d'applications Web. Des informations détaillées sur les paramètres de l'introduction sont dispersées partout, voici donc une lecture rapide du processus. .. ..
Toutes les applications et tous les paramètres du serveur sont stockés dans Git au format de projet Eclipse. Fondamentalement, la construction de l'environnement aurait dû être presque terminée par l'importation du projet, y compris l'introduction de la fonction serveur Tomcat. (Les membres jusqu'à présent étaient d'accord avec ça) Alors, quelle est la différence avec les membres du développement jusqu'à présent? .. ..
La machine de développement est ** Mac **!
Qu'est-ce que c'est? Tout au plus, la structure du projet était telle qu'elle ne fonctionnait pas lorsque l'environnement était passé à Mac! !!
Comme mentionné au début, car il s'agit d'une application Web de l'ancien temps et que le framework est également unique, Mieux encore, tout en ayant l'illusion que ce serait bien si je passais à Spring (Boot) Cependant, j'en suis venu à considérer une méthode comme une matière qui renvoie au cadre de la génération actuelle.
En parlant de la bonté de Java, s'il est transformé en byte code, cela ne dépend pas de l'environnement! Bien sûr, Tomcat ne fait pas exception, alors essayez de ne pas dépendre autant que possible du système d'exploitation ou de l'EDI. J'ai promis de passer à Embed Tomcat.
Tous les fichiers JAR nécessaires sont insérés manuellement dans le chemin de construction, car il s'agit d'un format de projet sans dépendances ni merde. Téléchargez le fichier ci-dessous et ajoutez-le à votre chemin de construction.
LaunchEmbedTomcat.java
public static void main(String[] args) throws Exception {
Tomcat tomcat = new Tomcat();
StandardContext ctx = (StandardContext) tomcat.addWebapp("/hogecontext",
Paths.get("WebContent/").toAbsolutePath().toString());
WebResourceRoot resources = new StandardRoot(ctx);
DirResourceSet dirSet = new DirResourceSet();
dirSet.setBase(Paths.get("build/classes").toAbsolutePath().toString());
dirSet.setWebAppMount("/WEB-INF/classes");
resources.addPreResources(dirSet);
ctx.setResources(resources);
tomcat.getService().addConnector(createAJPConnector());
ctx.getNamingResources().addResource(createDBContext());
tomcat.start();
tomcat.getServer().await();
}
static Connector createAJPConnector() {
Connector ajpConnector = new Connector("AJP/1.3");
ajpConnector.setPort(8009);
return ajpConnector;
}
static ContextResource createDBContext() {
ContextResource jdbcResource = new ContextResource();
jdbcResource.setName("jdbc/hogedb");
jdbcResource.setType(DataSource.class.getName());
jdbcResource.setAuth("Container");
jdbcResource.setProperty("factory", BasicDataSourceFactory.class.getName());
jdbcResource.setProperty("driverClassName", org.postgresql.Driver.class.getName());
jdbcResource.setProperty("url", "jdbc:postgresql://192.168.33.10:5432/hogedb");
jdbcResource.setProperty("username", "user");
jdbcResource.setProperty("password", "password");
return jdbcResource;
}
Je n'entrerai pas dans les détails, mais vous avez besoin de "WebResourceRoot # addPreResources" pour que le répertoire des classes compilées ressemble à celui sous WEB-INF de Embed Tomcat.
Exécution-> Lors du démarrage avec une application Java, il a été confirmé que le "chargement au démarrage" défini dans web.xml était exécuté dans l'ordre. Une erreur s'est produite alors que je pensais que c'était ikeru!
javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial
Après examen, il semble que la position initiale JNDI "java: comp / env" elle-même ne soit pas définie. Dans la référence de l'API, il était écrit comme suit, il semblait donc que Embed devait l'activer manuellement. (Ou y a-t-il un paramètre d'activation quelque part dans la fonction de serveur normale? Je n'ai pas beaucoup enquêté, je suis désolé)
Enables JNDI naming which is disabled by default.
Par conséquent, j'ai ajouté la ligne suivante à la méthode de démarrage.
LaunchEmbedTomcat.java
tomcat.enableNaming();
L'affichage suivant apparaît sur la console.
12 11, 2017 12:47:48 AM org.apache.coyote.AbstractProtocol start Informations: Démarrage de ProtocolHandler ["ajp-nio-8009"]
Apparemment, ça a commencé normalement. Nous avons pu confirmer le fonctionnement normal de l'application en communiquant via AJP.
C'est beaucoup plus rapide que Tomcat démarré à partir de la fonction serveur Eclipse. Je n'ai pas enquêté sur ce que sont les frais généraux, mais la sensation est si légère que je peux la ressentir. C'était chanceux.
En fait, je ne l'ai pas encore essayé sur Mac (car cet article est arrivé plus tôt en termes de date et d'heure ...) Je pense que ça va en raison des caractéristiques de Java. Je rapporterai le résultat à une date ultérieure! !! ça ne doit pas poser de problème! → Cela a bien fonctionné sans aucun problème! !! !!
J'ai créé une tâche gradle pour la construction, mais je voudrais également ajouter une tâche pour démarrer Tomcat.
Je suis heureux d'avoir pu éliminer ne serait-ce qu'un paramètre qui dépend de l'environnement. Cependant, je ne peux tout simplement pas me débarrasser de mes sentiments maintenant. Je souhaite passer au plus vite dans un cadre moderne! !!
Demain, c'est @ yam0918.
Recommended Posts