<div class="key-takeaways"><ul><li>Solon WebSocket มีสถาปัตยกรรมที่แตกต่างจากมาตรฐาน JSR-356 ของ Java อย่างสิ้นเชิง</li><li>รองรับการใช้งานแบบพอร์ตแชร์ร่วมกับ HTTP ผ่านการตั้งค่า server.websocket.port</li><li>โค้ดที่ใช้ @ServerEndpoint แบบเดิมจำเป็นต้องเขียนใหม่ให้เข้ากับ Listener Interface</li><li>จุดเด่นคือทดสอบง่ายและทำ Routing ได้ชัดเจนโดยไม่ต้องพึ่งพา Annotation Scanning</li></ul></div><p>ระบบ WebSocket ของ Solon ถือเป็นหนึ่งในจุดที่นักพัฒนาสาย Java อาจต้องปรับตัวทำความเข้าใจใหม่ เนื่องจากแนวทางการออกแบบมีความแตกต่างจากมาตรฐานทั่วไปอย่าง JSR-356 ที่ใช้งานกันแพร่หลายใน Spring, Tomcat หรือคอนเทนเนอร์ Java EE อื่นๆ แม้จะไม่ใช่ระบบที่แย่กว่า แต่เป็นแนวคิดที่เลือกเดินคนละทาง เมื่อทำความเข้าใจรูปแบบของมันได้แล้ว จะพบว่ามีความสะอาดและเป็นระเบียบกว่ามากทีเดียว</p><p>โครงสร้างการทำงานหลักของ Solon WebSocket จะแบ่งออกเป็น 2 รูปแบบ ขึ้นอยู่กับปลั๊กอินของเซิร์ฟเวอร์ที่เลือกใช้งาน ดังนี้:</p><ul><li>การใช้งานแบบพอร์ตแชร์ (Shared port): การจราจรทั้ง HTTP และ WebSocket จะใช้พอร์ตเดียวกัน ซึ่งปลั๊กอินเซิร์ฟเวอร์ส่วนใหญ่รองรับการทำงานนี้ได้ทันที</li><li>การกำหนดค่าผ่านพารามิเตอร์ <code>server.websocket.port : 18080</code> โดยไม่ต้องกังวลเรื่องหมายเลขเวอร์ชันในการประกาศ dependency เนื่องจากระบบ Solon BOM จะทำหน้าที่จัดการให้ทั้งหมด</li></ul><p>ข้อควรระวังสำคัญคือ Solon WebSocket ไม่ได้ใช้งาน API ตามมาตรฐาน JSR-356 ดังนั้น หากนักพัฒนากำลังย้ายระบบโค้ดเดิมที่เรียกใช้คลาส <code>javax.websocket.Session</code>, แอนโนเทชัน <code>@ServerEndpoint</code> หรือระบบ Encoder/Decoder ของ JSR-356 โค้ดส่วนนั้นจำเป็นต้องถูกเขียนใหม่ทั้งหมดให้อยู่ในรูปแบบของ listener interface pattern แม้จะไม่ใช่การเขียนใหม่ทั้งหมดในปริมาณที่ใหญ่โต แต่มันก็เป็นงานที่ต้องลงมือทำจริงจัง</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/solon_websocket_java_ms7ro01u_inline_1_42a7ff4382.jpg" alt="software development architecture diagram code" loading="lazy" /><p class="color-gray-500 text-sm mt-10">ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง</p></div><div class="ai-insight"><p>การเปลี่ยนผ่านจาก Annotation มาเป็น Listener Interface ในทางวิศวกรรมซอฟต์แวร์ช่วยลดปัญหาความซับซ้อนที่เกิดจาก Magic Annotation (แอนโนเทชันวิเศษที่ซ่อนการทำงานเบื้องหลัง) ซึ่งมักสร้างความประหลาดใจหรือตรวจหาข้อผิดพลาดได้ยาก การใช้ Listener ตรงๆ ช่วยให้เราเห็นลำดับการทำงาน (Pipeline) ได้อย่างชัดเจนผ่านโค้ดตรงหน้า</p></div><p>ในทางกลับกัน ข้อดีที่ได้กลับคืนมาคือรูปแบบ listener นั้นช่วยให้การเขียน Unit Test กลายเป็นเรื่องง่ายดาย เพียงแค่สร้างอินสแตนซ์ของคลาส listener ขึ้นมาแล้วเรียกใช้งานเมธอดโดยตรง นอกจากนี้ยังช่วยเรื่องการประกอบระบบและการทำ routing ผ่าน path ได้อย่างชัดเจน อ่านง่าย โดยไร้ความประหลาดใจจากระบบสแกนแอนโนเทชันที่มักซ่อนอยู่เบื้องหลัง</p><p class="source-attribution">ที่มา: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/solonjava/solon-websocket-listener-interface-over-annotation-maze-3eja" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

<div class="key-takeaways"><ul><li>Solon WebSocket features an architecture that clearly diverges from the standard Java JSR-356 specification.</li><li>It supports shared port configurations where HTTP and WebSocket traffic use the same port.</li><li>Legacy code using @ServerEndpoint must be refactored to fit the listener interface pattern.</li><li>The core advantage is easier unit testing and explicit routing without annotation scanning surprises.</li></ul></div><p>Solon's WebSocket support is one of those areas where the design diverges clearly from what most Java developers expect. If you have built WebSocket endpoints with JSR-356—the standard followed by Spring, Tomcat, and most Java EE containers—Solon handles things differently. It is not worse, simply different, and once the pattern clicks, it proves to be noticeably cleaner.</p><p>Solon WebSocket operates under specific configurations based on the server plugin in use:</p><ul><li>Shared port configuration allows HTTP and WebSocket traffic to share a single port, supported out of the box by most server plugins.</li><li>Configuration is managed via <code>server.websocket.port : 18080</code>, with no version numbers required in dependency declarations since the Solon BOM handles them.</li></ul><p>A crucial detail is that Solon WebSocket does not implement the JSR-356 API. Developers migrating legacy code that directly utilizes <code>javax.websocket.Session</code>, <code>@ServerEndpoint</code> in the <code>javax.websocket</code> namespace, or standard encoders/decoders will need to rewrite that code to adopt the listener interface pattern. While not a massive rewrite, it is certainly a tangible migration effort.</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/solon_websocket_java_ms7ro01u_inline_1_42a7ff4382.jpg" alt="software development architecture diagram code" loading="lazy" /><p class="color-gray-500 text-sm mt-10">Stock photo for illustration only, not from the actual event</p></div><div class="ai-insight"><p>Transitioning away from annotation-heavy frameworks toward explicit listener interfaces often benefits enterprise applications by eliminating hidden 'magic' behaviors. Explicit pipelines and path listeners make debugging straightforward because the routing logic resides directly in the code rather than being inferred by background reflection scanners.</p></div><p>On the flip side, the listener pattern is remarkably easier to test—developers can simply instantiate the listener class and invoke its methods directly. Furthermore, it simplifies component composition, giving you explicit, readable routing pathways without the usual surprises associated with annotation scanning.</p><p class="source-attribution">Source: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/solonjava/solon-websocket-listener-interface-over-annotation-maze-3eja" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

medium_solon-websocket-java-ms7ro01u.jpg

small_solon-websocket-java-ms7ro01u.jpg

thumbnail_solon-websocket-java-ms7ro01u.jpg

solon-websocket-java-ms7ro01u.jpg

เจาะลึกการทำงานของ Solon WebSocket ที่ฉีกแนวจากมาตรฐาน JSR-356 แบบเดิมๆ ด้วยรูปแบบ Listener Interface ที่ทดสอบและควบคุมง่ายกว่า

A deep dive into how Solon WebSocket diverges from standard Java JSR-356, offering a cleaner listener interface pattern that is easier to test and route.

Inewgen

Inewgen

#JSR-356

Decoding Solon WebSocket: Moving Beyond the Annotation Maze

Inewgen