There is a web application that was created in the Java 1.4 era a long time ago and still uses active Tomcat. This is a story when Embed Tomcat was introduced to such a Web application development environment by chance. Detailed setting information about the introduction is scattered all over the place, so here is a quick read of the process. .. ..
All applications and server settings are stored in Git in Eclipse project format. Basically, the environment construction should have been almost completed by importing the project including the introduction of the server function Tomcat. (The members so far were okay with that) Then, what is the difference from the development members so far? .. ..
The development machine is ** Mac **!
What is that? At most, the project structure was such that it wouldn't work when the environment changed to Mac! !!
As mentioned at the beginning, because it is a web application from the old days and the framework is also unique, Better yet, while having a delusion that it would be okay if I moved to Spring (Boot) However, I came to consider a method like a matter that refers to the framework of the current generation.
Speaking of the taste of Java, if it is made into bytecode, it does not depend on the environment! Of course Tomcat is no exception, so try not to depend on the OS or IDE as much as possible. I vowed to move to Embed Tomcat.
All the necessary jars are manually inserted into the build path, because it is a project format with no dependencies or crap. Download the jar below and add it to your build path.
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;
}
I will omit the detailed process explanation, but "WebResourceRoot # addPreResources" is required to make the compiled classes directory appear to be under WEB-INF of Embed Tomcat.
Execution-> When started with a Java application, it was confirmed that the "load-on-startup" defined in web.xml was executed in sequence. This is an error for a while I thought it was cool!
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
Upon examination, it seems that the JNDI initial position "java: comp / env" itself is not defined. In the API reference, it was written as follows, so it seemed that Embed had to enable it manually. (Or, is there a setting for activation somewhere in the normal server function? I haven't investigated that much, I'm sorry)
Enables JNDI naming which is disabled by default.
Therefore, I added the following line to the startup method.
LaunchEmbedTomcat.java
tomcat.enableNaming();
The following display appears on the console.
12 11, 2017 12:47:48 AM org.apache.coyote.AbstractProtocol start Info: Starting ProtocolHandler ["ajp-nio-8009"]
Apparently, it started normally. I was able to confirm the normal operation of the application by communicating via AJP.
It is much faster than Tomcat started from the Eclipse server function. I haven't investigated what the overhead is, but the feeling is so light that I can feel it. This was lucky.
Actually, I haven't actually tried it on a Mac yet (because this post came earlier in terms of date and time ...) I think it's okay due to the characteristics of Java. I will report the result at a later date! !! it must be no problem! → It worked fine without any problems! !! !!
I have created a gradle task for the build, but I would like to add a task to start Tomcat as well.
I am glad that I was able to eliminate even one setting that depends on the environment. However, I just can't get rid of my feelings now. I want to move to a modern framework as soon as possible! !!
Tomorrow is @ yam0918.
Recommended Posts