Being a Journal of my Java Web-App Development Journey

Basically, at the top/system level for the entire Tomcat web server.

tl;dr: It should have worked.

https://tomcat.apache.org/tomcat-9.0-doc/jndi-datasource-examples-howto.html#Context_versus_GlobalNamingResources

@ApplicationScoped
public class LayLeadershipSqliteRepository implements LayLeadershipRepository
{
   private static final String DATABASE_JNDI_NAME = "jdbc/LayLeadership";
   @Resource( name = DATABASE_JNDI_NAME) // Automatically prefixes "java:comp/env" onto this resource.  SUPPOSEDLY, you can use 'lookup =' to give a complete path.
   private DataSource _dataSource;

There are a couple of things going on here (I think):

1. We put @ApplicationScoped on the bean to make sure the container knows it's a managed bean ("managed" by CDI). I don't think the exact scope matters, so long as there's a CDI scope attribute so the container knows it's managed. We do this because resource injection only happens on managed objects.

   (Note that we might need to do this anyway if we're going to move the "Repository" interface back to another Maven module, like the Svc module.)

2. We put a @Resource attribute on the thing we want injected from the JNDI directory. Since we used the name argument, we automatically get shunted off to java:comp/env.

   Internet rumor has it that you can use resource to specify an entirely different path in the JNDI directory.

   I noticed (by accident) that if you get the name of the resource wrong, you get a big, nasty error in the web app itself (like… a faceful of stack trace), which is good. At least you know the lookup is being attempted. If you put in an intentionally wrong resource name and get no errors, you know the lookup isn't being attempted at all. For what that's worth.

mvn help:effective-pom

Shows super-POM merged w/your POM (or inherited POM hierarchy, if you are so bold).

Looks like Maven generates POMs that need a little more detail. (Or sometimes, they have too much detail, like for really old JDK versions.)

I put these property definitions at the end of the "header" section of the POM:

<properties>
  <maven.compiler.source>11</maven.compiler.source>
  <maven.compiler.target>11</maven.compiler.target>
  <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

See https://maven.apache.org/pom.html#Dependencies

compile

Available in all classpaths

provided

Referenced dependency doesn't need to be packaged w/the output of Maven because it will already been present in the container at deploy-time.

runtime

Not required for compilation but must be present at run-time.

test

Referenced dependency is only needed at unit-test time (or up until then)

Servlet source code goes in web project, in directory src/main/java/<package-directory-structure>/FooServlet.java. Binary winds up in the war file in WEB-INF/classes.

Tomcat 9 provides:

I'm guessing we won't need the JSP and EL specs, since we'll (probably) be emiting JSON, not HTML.

So, we need something like the following:

<dependency>
  <groupId>javax.servlet</groupId>
  <artifactId>javax.servlet-api</artifactId>
  <version>3.0.1</version>
  <scope>provided</scope>  <!--  "provided" means we need this JAR for a successful compile, but it won't be included in
                                 the generated output, because we expect the container to which the generated WAR is
                                 deployed to provide its own compatible version of the JAR.
                           -->
</dependency>

But the version we need is probably 4.0.x?

The effective POM has Maven Central at https://repo.maven.apache.org/maven2. So… from the versions listed at https://repo.maven.apache.org/maven2/javax/servlet/javax.servlet-api/, it looks like maybe 4.0.1 is the version we want.

Searching at https://search.maven.org/ with search g:javax.servlet a:javax.servlet-api yields a hit. Clicking on the result (try the artifact id or the version count) yields a snippet of info, including the GitHub repository and home page.

And, finally, after all that… we build (mvn package), and… voila! (It got automatically downloaded and the compile succeeds, after we updated our tiny class to have a dependency on HttpServlet.)

deimos$ pwd
/Users/john/.m2/repository/javax/servlet/javax.servlet-api/4.0.1

deimos$ lscf
_remote.repositories                      javax.servlet-api-4.0.1.jar
javax.servlet-api-4.0.1-javadoc.jar       javax.servlet-api-4.0.1.jar.sha1
javax.servlet-api-4.0.1-javadoc.jar.sha1  javax.servlet-api-4.0.1.pom
javax.servlet-api-4.0.1-sources.jar       javax.servlet-api-4.0.1.pom.sha1
javax.servlet-api-4.0.1-sources.jar.sha1  m2e-lastUpdated.properties

(Whether it runs is something we'll find out later. (Answer: it does.))

The next step, I think, is to fix up routing so a url will go to the servlet. See Servlet Routing.

I don't think I need all of the J2EE project stuff, such as the EJBs and the "ear" folder, but the rest are probably good. I guess I could just delete the unwanted directories and remove references to them from the ancester POMs. Then, the final deliverable is the "servlets" (or "servlets/servlet") project, packaged as war.

The project dir root contains the following ( open questions are presented in the indicated style):

• pom.xml – overall POM
• primary-source – core/unique business logic
  • pom.xml – sub-POM for the main source, which is a jar
  • src
    • main
      • java
        • com
          • how_hard_can_it_be.com
            • offtotheraces
    • test
      • java
  • target – all the magic that Maven does, probably includes the jar generated from primary-source
• projects – secondary/reusable source, I guess
  • pom.xml
  • logging – sample project
    • pom.xml – each project gets its own POM
    • src
      • main
        • java
      • test
        • java
    • target – Maven-generated
• servlets (plural) – actual JSPs and servlets, which should be thin logic around the business logic. Note also that, buried below here, are the static files for the web app (js, css, images, etc.)
  • pom.xml
  • servlet (singular) – Not sure why there's a singular "servlet" directory under the plural "servlets" directory.
    • src
      • main
        • java
        • webapp
          • WEB-INF
            • web.xml
          • index.jsp
          • (other JSPs and static resources (css, js, images, etc.), presumably
      • test
        • java
    • target
• ejbs – I guess these are also thin layers around business logic
  • pom.xml
  • src
    • main
      • java
      • resource – resource bundles for configuration, i18n, similar stuff?
        • META-INF
          • ejb-jar.xml - No idea what this is
    • test
      • java
  • target
• ear – I have no idea what goes in here
  • pom.xml
  • src
    • main
      • java
    • test
      • java
  • target

https://maven.apache.org/archetypes/maven-archetype-j2ee-simple/index.html

Supposedly simple tutorial at https://hradecek.github.io/posts/cdi-in-tomcat.

Also, the Weld reference manual has info in the chapter on "Application servers and environments supported by Weld" (specifically, the sections on "Servlet containers" and "Tomcat"). It's mostly a matter of adding the Maven dependency blobs specified in the reference manual to your pom.xml, web.xml, and context.xml.

From https://projects.eclipse.org/proposals/jakarta-contexts-and-dependency-injection:

Unlike most of the Java EE specifications, Contexts and Dependency Injection was led by a non-Oracle organization, namely Red Hat.

The project aims to continue the standardization work of the Contexts and Dependency Injection (CDI) specification, which is part of the Java EE platform, but which also is designed since version 2.0 for use in Java SE environments. Previous revisions of that specification were created under the Java Community Process (JCP):

• CDI 1.0 (JSR 299), part of Java EE 6
• CDI 1.1 and 1.2 (JSR 346), part of Java EE 7
• CDI 2.0 (JSR 365), part of Java EE 8

• CLOSING NOTE [2020-04-12 Sun 12:17]
  Picked SQLite, now handling sub-issues (see below).

But maybe Derby later as an exercise in another d/b layer.

• CLOSING NOTE [2020-05-09 Sat 22:12]
  CDI problem fixed last weekend, I think.
• State "HOLD" from "TODO" [2020-05-03 Sun 19:54]
  Straightening out problem with CDI bean and interface in separate modules.

See https://weld.cdi-spec.org/documentation/#7

Add the following to $CATALINA_HOME/conf/logging.properties:

org.jboss.weld.level=FINE

See https://wiki.eclipse.org/EclipseLink/Examples/JPA/Logging

Include the following in the persistence unit defined in persistence.xml:

<persistence-unit>
  <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
  <properties>
    <!-- I think you need to specify the provider if you're going to use provider-specific settings like the following. -->
    <property name="eclipselink.logging.level" value="FINEST"/>
  </properties>
</persistence-unit>

• CLOSING NOTE [2020-05-13 Wed 21:30]
  Chose MapStruct.

• State "HOLD" from "IN-PROGRESS" [2020-05-12 Tue 09:40]
  Maybe I won't use this, in lieu of Mapstruct. Recent Reddit post (6 months old!) seems to prefer Mapstruct, sort of; and I'm finding the JMapper docs pretty awful. Gonna go research Mapstruct now.

  One good thing I learned from my foray into JMapper is how easy it is to load a resource from a jar file, something I had forgotten.

Don't want to annotate business-class objects with JMapper annotations because that introduces a dependency on JMapper in the business class, which we don't want to do (onion core (1), no dependencies, pls).

So, we're trying an XML mapper.

Turns out the classpath for a JAR file is… the root of the JAR, duh. So, we can put the xml mapping (named whatever we want) into src/main/resources/META-INF for the Data module, which puts it in /META-INF in the root of the jar, and we can pull it right back at run time via path "META-INF/jmapper.xml" (or whatever we named it).

See https://stackoverflow.com/a/4585668.

Looks like there are two pieces you need: mapstruct-core and mapstruct-processor.

Core is, I guess, the runtime part you need, and Processor is the compile-time part you need, as a compiler plugin (so I guess it doesn't stick around after that phase).

From the docs:

The general philosophy of MapStruct is to generate code which looks as much as possible as if you had written it yourself from hand. In particular this means that the values are copied from source to target by plain getter/setter invocations instead of reflection or similar.

• CLOSING NOTE [2020-05-10 Sun 13:35]
  Yes, I think it is. The JPA stuff just gets us DTO, not full-blown business objects.

• CLOSING NOTE [2020-05-10 Sun 13:36]
  Yes, I think it is. The JPA stuff just gets us DTO, not full-blown business objects.

• CLOSING NOTE [2020-05-04 Mon 11:27]
  Figured out that runtime dependencies need to be declared in Maven POM.
• CLOSING NOTE [2020-04-25 Sat 12:37]
  Annotate the beans properly, and you're good.

Unsatisfied dependencies for type LayLeadershipRepository with qualifiers @Default
  at injection point [BackedAnnotatedField] @Inject private com.how_hard_can_it_be.layleadership.servlet.MembersServlet._layLeadershipRepository
  at com.how_hard_can_it_be.layleadership.servlet.MembersServlet._layLeadershipRepository(MembersServlet.java:0)

Apparently the interface and the implementation must be in the same JAR file. (Really? Do we really believe that? No, right? Because then how could you have a third-party bean satisfy an interface and be injected?).

Answer: no, they don't have to be in the same JAR/module. But, apparently, you do have to annotate the beans you expect this to work for, so the CDI container knows that they are beans to be managed.

      Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type LayLeadershipRepository with qualifiers @Default
at injection point [BackedAnnotatedField] @Inject private com.how_hard_can_it_be.layleadership.servlet.MembersServlet._layLeadershipRepository
at com.how_hard_can_it_be.layleadership.servlet.MembersServlet._layLeadershipRepository(MembersServlet.java:0)
Possible dependencies: 
- Managed Bean [class com.how_hard_can_it_be.layleadership.data.LayLeadershipSqliteRepository] with qualifiers [@Any @Default],
- Managed Bean [class com.how_hard_can_it_be.layleadership.data.LayLeadershipRepositoryScaffold] with qualifiers [@Any @Default]

I believe the problem here is that both injectable beans are defaulting to qualifiers @Any and @Default because we haven't given them any other qualifiers.

The fix is to declare a Mock qualifier annotation and use it to annotate the "scaffold" version so it no longer has the default @Default qualifier.

@Qualifier
@Retention( RUNTIME )
@Target( {TYPE, FIELD, METHOD, PARAMETER} )
public @interface Mock {}

Let's see if we've even got sqlite set up correctly. We'll modify the injected bean to directly connect to the d/b.

putting

conn = DriverManager.getConnection( "jdbc:sqlite:/usr/local/var/LayLeadership/tasks.db");

in LayLeadershipSqliteRepository.getAllMembers() results in:

No suitable driver found for jdbc:sqlite:/usr/local/var/LayLeadership/tasks.db

So… progress?

Debugging and dumping out the result of System.getProperties() (expression evaluation window) gives:

java.class.path

"/opt/apache-tomcat-9.0.31/bin/bootstrap.jar:/opt/apache-tomcat-9.0.31/bin/tomcat-juli.jar"

Well, that's unhelpful. Probably Tomcat has a separate classloader for each app, and this system property is meaningless.

So… it turns out this works if you do a couple of things just right:

1. Get the url right. Be sure you're referring to a d/b file that exists, and the "tomcat" user has read/write permission to it. (At some point, I switched from tasks.db to layleadership.db.)
2. Explicitly load the class in code with a call to Class.forName( "org.sqlite.JDBC" ).
3. Iterate through the drivers obtained via DriverManager.getDrivers(), asking each driver if it can accept the url.

This doesn't seem right; Tomcat should be handling all this for us. I suspect I've still got something misconfigured, but at least we can access the database somehow.

• CLOSING NOTE [2020-04-22 Wed 21:50]
  Don't use copyXML. Instead….
• CLOSING NOTE [2020-04-19 Sun 21:45]
  This way lies madness. Turn back, O mortal.

[head exploded after reading both the spec and the various .xsd files involved.]

Might be best to move the server.xml part out of the global naming whatsis and into context.xml in the deployed files (.war). Tomcat allows this file to be "externalized", by placing it in the conf hierarchy, which allows it to be preserved between deploys (although TODO: find out if the copyXML attribute of the host will overwrite this file; reading the docs leaves the answer unclear (it's ok for "start" but what about "deploy". Will deploying a new version of the WAR file result in the copied context.xml being overwritten?).

Answer: it overwrites the older, extracted version. So, I guess the answer is: don't use copyXML. Instead, copy context.xml to conf/<engine>/<host>/<context>.xml and edit (once) as needed.

Where <engine> is probably Cataline and <host> may be localhost and <context> is the context path of the application (which may corresponds to the name of the WAR file used to deploy it).