IntelliJ IDEA 运行 Tomcat 报错:Please, configure Web Facet first!

IntelliJ IDEA 运行 Tomcat 报错:Please, configure Web Facet first!

适用:IntelliJ IDEA Ultimate
关键点:Web Facet + Artifact(war exploded)+ Tomcat Deployment
本文同时覆盖两种项目结构:
1)普通 Web 目录结构(例如项目里有 web/WEB-INF)
2)Maven 标准结构(src/main/webapp)

0. 你遇到的现象是什么?

当你在 IDEA 里运行 Tomcat(或尝试打开浏览器访问)时,弹出提示:

Browser Error
Please, configure Web Facet first!

这句话的真实含义是:IDEA 还没把你的模块识别为 Web 模块,因此无法正确识别 Web 根目录、WEB-INF、web.xml,也就没法生成部署结构并交给 Tomcat 跑起来。


1. 为什么会出现这个错?

常见原因主要有三类:

  1. 模块没有 Web FacetIDEA 不知道你的 Module 是“Web 应用”,自然也不知道 Web 根目录在哪里。
  2. 没有生成 Artifact(war / war exploded)Tomcat 运行配置的 Deployment 需要“部署产物”,否则 Tomcat 不知道部署什么。
  3. Web 根目录未配置(Web Resource Directory)比如你的静态资源、JSP、WEB-INF 并不在默认路径,需要手动告诉 IDEA。

2. 解决方案(通用步骤,按截图一步一步来)

步骤 1:打开 Project Structure

菜单栏:File → Project Structure…

(macOS 常用快捷键:⌘ ;,Windows/Linux:Ctrl + Alt + Shift + S)


步骤 2:添加 Web Facet

左侧选择 Facets → 点击左上角 “+” → 选择 Web

这一步等于告诉 IDEA:

“这个 Module 是 Web 应用,需要 Web 根目录、WEB-INF、web.xml 等配置。”

步骤 3:选择要添加 Web Facet 的模块

弹出 Choose Module 后,选择你真正要部署到 Tomcat 的模块(例如 Test)→ 点击 OK

多模块项目尤其要注意:
别选错模块,否则 Artifact 会建在错误模块上,部署时会一直 404 或找不到资源。

步骤 4:配置 Web 根目录(Web Resource Directory)与 web.xml

进入 Web Facet 配置页后,核心配置是:

4.1 Web Resource Directories(Web 根目录)

把你的 Web 根目录加入(例如 …/Test/web 或 src/main/webapp)

右侧 Relative path 一般保持 /(部署根路径)。

4.2 Deployment Descriptors(可选)

如果你使用 web.xml,确认路径是 WEB-INF/web.xml 对应的真实位置。


步骤 5:创建 Artifact(推荐 war exploded)

左侧切换到 Artifacts → 点击左上角 “+” → 选择:

Web Application: Exploded → From Modules…

为什么推荐 Exploded

  • 开发阶段更友好(目录形式)
  • 修改 JSP / 静态资源更方便验证
  • 部署调试体验更好

步骤 6:选择模块生成 war exploded

Select Modules 窗口中选择模块(如 Test)→ 点击 OK

IDEA 会生成一个类似:Test:war exploded


步骤 7:Apply/OK 保存配置

确认:

  • Type 是 Web Application: Exploded
  • Output Layout 里有 Web facet resources

最后点击:Apply → OK


3. 最后一步:把 Artifact 部署到 Tomcat

很多人做到上面不报错了,但 Tomcat 还是跑不起来,原因是:没部署 Artifact

操作如下:

  1. Run → Edit Configurations… 打开你的 Tomcat(Local)配置
  2. 切到 Deployment 页签
  3. 点击 +
  4. 选择 xxx:war exploded
  5. 设置 Application context(常用两种)
    • /:根路径(http://localhost:8080/)
    • /test:子路径(http://localhost:8080/test)
  6. Run 启动 Tomcat

4. 针对普通 Web 目录版Maven 标准版这两种项目结构的“具体落地配置”

版本 A:普通 Web 目录结构

目录示例

Test/ ├─ src/(可有可无) ├─ web/ │ ├─ index.jsp │ └─ WEB-INF/ │ ├─ web.xml(可选) │ └─ lib/(可选) └─ ...

Web Facet 该怎么配?

Web Facet 页面:

  • Web Resource Directory:选择 …/Test/web
  • Relative path:/

如果有 web.xml:

  • Deployment Descriptor:…/Test/web/WEB-INF/web.xml

Artifact 建议

  • 选择:Web Application: Exploded
  • From Modules… 选择你的模块(Test)

Tomcat Deployment

  • 部署 Test:war exploded
  • context 建议 /test 或 /(看你访问习惯)

版本 B:Maven 标准 Web 项目(src/main/webapp)

Maven 标准目录结构

your-app/ ├─ src/ │ ├─ main/ │ │ ├─ java/ (Servlet/Controller 等) │ │ ├─ resources/ (配置文件) │ │ └─ webapp/ (Web 根目录) │ │ ├─ index.jsp │ │ └─ WEB-INF/ │ │ ├─ web.xml(可选) │ │ └─ views/... │ └─ test/... ├─ pom.xml └─ ...

Maven 项目为什么也会遇到这个错?

有些情况下:

  • 项目导入不完整
  • IDEA 没自动识别成 Web(尤其是你把它当普通 Java 工程导入时)
  • module 没带 Web Facet

Web Facet 该怎么配?

Web Facet 页面:

  • Web Resource Directory:选择 src/main/webapp
  • Relative path:/

如果使用 web.xml:

  • src/main/webapp/WEB-INF/web.xml

Artifact 建议

仍然是:

  • Web Application: Exploded → From Modules…

Tomcat Deployment

部署 xxx:war exploded,访问:

  • http://localhost:8080/你的context/
如果你用的是 Servlet 3.0+(全注解),没有 web.xml 也没关系,但 Web Root 必须正确是 src/main/webapp。

5. 常见问题排查

1)Facets 里没有 Web 选项?

  • 你可能用的是 IDEA Community(社区版不带完整 JavaEE/Tomcat 集成)

2)部署后访问 404?

  • 检查 Tomcat → Deployment 是否添加了 war exploded
  • 检查 Application context 是否正确(是不是 /test 但你访问了 /)

3)静态资源 / JSP 访问不到?

  • Web Resource Directory 配错了:普通项目应该是 web/,Maven 应该是 src/main/webapp

4)还是弹“configure Web Facet”?

  • Web Facet 没加在正确模块上(多模块选错)
  • 配完没点 Apply/OK 保存

5)web.xml 找不到 / 报 descriptor 错误?

  • 真实路径不是 WEB-INF/web.xml
  • 或你项目根本没用 web.xml(注解方式),可不配 descriptor

结尾

        配置 Web Facet 的本质是“让 IDEA 认识你的模块是 Web 应用”,创建 Artifact 的本质是“生成 Tomcat 可部署的产物”。只要把 Web 根目录war exploded 两件事配对,Please, configure Web Facet first! 基本就不会再出现。

Read more

亲测VibeThinker-1.5B-WEBUI:AIME解题效果惊艳

亲测VibeThinker-1.5B-WEBUI:AIME解题效果惊艳 你有没有试过对着一道AIME真题盯了二十分钟,草稿纸写满三页却卡在关键一步?有没有在Codeforces比赛倒计时五分钟时,突然想不起那个最优的DP状态转移方程?我也有。直到上周,我在ZEEKLOG星图镜像广场点开VibeThinker-1.5B-WEBUI,输入第一道AIME24第12题——三分钟后,屏幕上跳出完整推导、清晰注释和最终答案。不是冷冰冰的数字,而是一段像人类教练一样边讲边算的解题过程。 这不是GPT-4或Claude的云端调用,而是跑在我本地RTX 3060上的一个仅1.5B参数的模型。它不聊天气,不写情书,就专注做一件事:把数学题拆开、嚼碎、再一步步拼回正确答案。今天这篇实测笔记,不讲参数量对比,不列训练成本曲线,只说它在真实解题场景里——到底有多好用。 1. 部署极简:三步启动,五秒加载 VibeThinker-1.5B-WEBUI的部署体验,彻底刷新了我对“小模型”的理解。它不像动辄要配8张A100的庞然大物,而更像一个即插即用的解题U盘。 1.1 一键式环境准备 镜像已预装全部

Qwen3-0.6B-FP8实战教程:构建跨平台AI助手——Web/Telegram/Discord多端统一后端

Qwen3-0.6B-FP8实战教程:构建跨平台AI助手——Web/Telegram/Discord多端统一后端 1. 开篇:为什么需要一个多端统一的AI助手? 想象一下这个场景:你正在电脑前写代码,突然想到一个问题,于是打开浏览器,访问一个AI对话页面提问。过了一会儿,你出门了,在手机上收到朋友的消息,想用同一个AI助手帮忙想个点子,却不得不切换到另一个App。晚上,你和团队在Discord上讨论项目,又想调用AI来辅助决策,结果发现还得重新部署一套服务。 是不是很麻烦?这就是我们今天要解决的问题。 Qwen3-0.6B-FP8是一个小巧但强大的语言模型,它能在资源有限的环境下流畅运行。但光有模型还不够,我们需要一个能同时服务Web页面、Telegram机器人和Discord机器人的统一后端。这样,无论你在哪里,用什么设备,都能无缝使用同一个AI助手。 这篇文章,我就带你一步步搭建这样一个系统。不需要高深的编程知识,跟着做就行。 2. 环境准备与模型部署 2.1 你需要准备什么 在开始之前,确保你有以下环境: * 一台Linux服务器:可以是云服务器,也可以是

阿里通义Z-Image-Turbo WebUI风格迁移实战:快速打造品牌视觉形象

阿里通义Z-Image-Turbo WebUI风格迁移实战:快速打造品牌视觉形象 对于初创公司而言,建立统一的品牌视觉形象是提升市场竞争力的关键,但传统设计流程往往需要投入大量时间和人力成本。阿里通义Z-Image-Turbo WebUI风格迁移技术提供了一种高效解决方案,通过AI技术快速生成符合品牌调性的图像,保持视觉一致性。这类任务通常需要GPU环境支持,目前ZEEKLOG算力平台提供了包含该镜像的预置环境,可快速部署验证。 什么是阿里通义Z-Image-Turbo WebUI风格迁移 阿里通义Z-Image-Turbo WebUI是基于阿里云通义实验室最新图像生成技术构建的Web用户界面,其核心能力是通过风格迁移技术将参考图片的视觉特征(如色彩搭配、纹理样式、构图比例等)快速应用到新生成的图片上。 主要解决三类问题: * 品牌视觉一致性:将企业LOGO、主色调、设计语言等特征批量应用到宣传物料 * 设计资源复用:基于少量样本图片快速生成同风格系列作品 * 创意效率提升:10分钟内产出原本需要专业设计师数小时完成的方案 提示:风格迁移不同于普通AI绘图,它能精确

Web Crawling 网络爬虫全景:技术体系、反爬对抗与全链路成本分析

Web Crawling 网络爬虫全景:技术体系、反爬对抗与全链路成本分析

核心结论:爬虫生态数万个工具的繁荣不是技术丰富的标志,而是持续对抗中高损耗率的副产品。爬虫问题的本质不是"能不能爬到",而是全链路成本函数——爬、存、ETL、维护——谁先扛不住。 一、爬虫技术体系全景 1.1 技术类别收敛图 工具数万,但底层技术类别高度收敛。整个爬虫技术栈可以压缩为以下几层: ┌──────────────────────────────────────────────────────┐ │ 应用层(目标适配) │ │ 针对特定网站的解析规则、登录流程、分页逻辑 │ ├──────────────────────────────────────────────────────┤ │ 解析层(数据提取) │ │ HTML解析、JSON提取、正则、XPath、CSS选择器 │ ├──────────────────────────────────────────────────────┤ │ 渲染层(页面执行) │ │ 静态请求(requests/httpx)vs 动态渲染(浏览器引擎) │ ├─────────────────────────────────