如何在Tomcat 8.5上部署Broadleaf 5.2社区演示项目？

Hey there! Let's walk through getting your Broadleaf Community Demo modules (site, admin, api, plus core) packaged into WARs and deployed to Tomcat 8.5 on your AWS EC2 instance (running JVM 1.7). I’ve broken this down into actionable steps based on Broadleaf’s core configuration guidelines:

First, let’s make sure your local setup is aligned with the EC2 environment to avoid deployment headaches:

• Verify JDK Version Consistency: Double-check that Eclipse is using JDK 1.7 for all modules. Right-click each project → Properties → Java Build Path → Libraries to confirm the JRE System Library is 1.7. Then head to Java Compiler and ensure the compliance level is set to 1.7 too.
• Lock in Core Module Dependencies: Since core is a shared dependency, run a Maven install on it first to push its JAR to your local repository. Right-click the core project → Run As → Maven Install (check -DskipTests to speed things up if you don’t need to run tests).
• Strip Eclipse Server Specifics: Remove any Eclipse-built-in Tomcat customizations (like project-specific server.xml entries) — these don’t belong in your production WARs.

Broadleaf relies on Maven for builds, so follow these steps for each module:

• Package Core First: Open Eclipse’s Terminal (or a local command prompt), navigate to your core module directory, and run:

  mvn clean install -DskipTests
  

  This builds the core JAR and makes it available to the site, admin, and api modules.
• Build Site/Admin/API WARs: For each of these modules, navigate to their directories and run:

  mvn clean package -DskipTests -DwarName=broadleaf-site
  

  Swap broadleaf-site with broadleaf-admin or broadleaf-api for the other modules. The -DwarName flag lets you name the WARs clearly for deployment.
• Validate WAR Contents: After building, check the target folder of each module. Unzip the WAR and confirm WEB-INF/lib includes the core JAR and all required dependencies — missing JARs are a top cause of deployment failures.

Now prep your EC2 Tomcat instance to run Broadleaf:

• Tweak JVM Memory Settings: Edit Tomcat’s bin/setenv.sh (Linux) to allocate enough memory — Broadleaf needs more than the default. Add these lines:

  export CATALINA_OPTS="-Xmx2048m -Xms1024m -XX:MaxPermSize=512m -Djava.awt.headless=true"
  

  Note: JVM 1.7 uses MaxPermSize, so don’t switch to Metaspace (that’s for 1.8+).
• Configure Data Sources: For each WAR, create a context XML file in Tomcat’s conf/Catalina/localhost directory (e.g., broadleaf-site.xml). Here’s a template for your database connection:

  <Context docBase="/opt/tomcat/webapps/broadleaf-site.war" reloadable="false">
      <Resource name="jdbc/web" auth="Container" type="javax.sql.DataSource"
                maxTotal="100" maxIdle="30" maxWaitMillis="10000"
                username="your-db-username" password="your-db-password"
                driverClassName="com.mysql.jdbc.Driver"
                url="jdbc:mysql://your-db-endpoint:3306/broadleaf-db?useSSL=false"/>
      <!-- Add other required Broadleaf data sources like jdbc/webSecure, jdbc/catalog here -->
  </Context>
  

  Replace the database details with your AWS RDS (or accessible DB) credentials.
• Set Production Environment Variables: Add these lines to bin/setenv.sh to tell Broadleaf it’s running in production:

  export JAVA_OPTS="$JAVA_OPTS -Dbroadleaf.environment=production -Dbroadleaf.config.location=file:/opt/broadleaf-config/"
  

  Create the /opt/broadleaf-config/ directory on EC2 and drop your production properties files there (like database overrides, storage settings).

• Transfer WARs to EC2: Use scp to copy your local WARs to the Tomcat webapps directory on EC2:

  scp ./target/broadleaf-site.war ec2-user@your-ec2-public-ip:/opt/tomcat/webapps/
  

  Repeat this for admin and API WARs.
• Restart Tomcat: SSH into your EC2 instance and restart Tomcat to deploy the WARs:

  sudo /opt/tomcat/bin/shutdown.sh
  sudo /opt/tomcat/bin/startup.sh
  

• Debug with Logs: Check Tomcat’s logs to catch any startup issues:

  tail -f /opt/tomcat/logs/catalina.out
  

  Common fixes: Adjust security groups to allow DB access, fix dependency mismatches, or increase memory if you see out-of-memory errors.

• ClassNotFoundExceptions: Double-check your Maven pom.xml files — ensure all dependencies have scope=compile (except container-provided ones like servlet-api) and that core was installed correctly.
• UnsupportedClassVersionError: You compiled with a newer JDK! Confirm Eclipse is using JDK 1.7 for all modules and EC2’s java -version returns 1.7.x.
• Database Connection Failures: Verify your EC2 security group allows inbound traffic to your DB port (e.g., 3306), and that your DB user has permissions to connect from the EC2 instance’s IP.

内容的提问来源于stack exchange，提问作者Jon D Cruz