Wildfly复合组件重渲染异常：NoSuchMethodException io.undertow.servlet.spec.PartImp.<init>()

这问题我之前帮团队排查过类似的，核心矛盾在于Undertow和WebSphere Liberty（WLP）对Servlet API中Part实例的序列化/实例化逻辑差异，导致重渲染时触发了PartImp的无参构造调用（而这个类本身就没提供无参构造）。

为什么会出现这个异常？ #

• 当你的复合组件因显示/隐藏面板触发重渲染时，底层组件框架（比如JSF）可能会尝试序列化或恢复视图状态中的对象。如果代码不小心把Part（文件上传对象）实例存到了视图作用域、会话作用域的bean里，或者直接绑定到了组件状态中，框架就会在重渲染时尝试实例化这个对象。
• WLP的Part实现类（IBM自家的实现）大概率提供了无参构造，或者WLP的序列化机制对Java Bean规范的要求更宽松；但Undertow的PartImp是严格按照Servlet API实现的，只提供了带参数的构造函数，完全不支持通过无参构造实例化，所以就抛出了NoSuchMethodException。

具体解决步骤 #

• 核心原则：不要直接持有Part实例
  1. 在请求处理阶段（比如文件上传的提交方法里），就把Part中的关键信息提取出来，存到自定义的普通Java对象里——比如创建一个UploadedFile类，包含文件名、文件内容、类型这些字段，给它加上无参构造和getter/setter，之后只在bean里保存这个自定义对象。

  // 示例自定义类
  public class UploadedFile {
      private String fileName;
      private byte[] content;
      private String contentType;
  
      // 必须要有无参构造
      public UploadedFile() {}
  
      // 带参构造、getter/setter省略
  }
  

  2. 检查复合组件的绑定逻辑，确保没有把Part直接绑定到组件的value属性里，避免框架把它纳入视图状态管理。
  3. 如果用的是JSF这类框架，检查@ViewScoped或@SessionScoped的bean，确保里面没有持有Part实例——这类作用域的bean会被序列化，而Part是请求作用域的对象，本就不该被跨请求保存。

额外验证点 #

可以在本地调试时，查看视图状态中到底序列化了哪些对象，确认是否存在PartImp的引用，这能帮你快速定位到代码中不小心持有Part的地方。

内容的提问来源于stack exchange，提问作者scarvy