UPnP migration verification

[tesshucom]

Overview

v114 requires UPnP Servlet6.0Support. Since there is no UPnP library compatible with Servlet 6.0, it is assumed that the 3rd-party lib will be patched. cling or jupnp. There are two paths.

Problem description

The most important aspect is whether it works the same as before.

• jupnp is a fork of cling, but its operation has not been confirmed. This will take the most time, but if successful, the implementation will be modernized and No CVE Warn will be achieved. If it works as is by applying a patch to jupnp, that is the easiest. If you patch jupnp and it works as is, it will be beneficial in the long run. Probably jupnp will also be compatible with the next generation, so in that case the patch will not be necessary.
  • OSGI jakarta support is slow : osgi/osgi/issues/552. Therefore, servlet migration in the main stream of jupnp will wait for osgi. (Jpsonic does not wait for this)
• If there is any major problem with jupnp, cling will be migrated to avoid it. Since it has already been confirmed to work with Java 21, only servlet support will be required.
  • cling has already removed OSGI Support, so you don't need to worry about it.
  • However, in this case Android Support will be removed like jupnp. Because it will continue to drag down ancient Java.

Scenario

Compared to cling that is already EOL, jupnp has better configuration management. Since we would like to use jupnp if possible, jupnp will be verified first.

jupnp

• 1. In the development branch, a jupnp migration verification will be performed before applying Spring Boot 3.2.
  • Starting from Commit Point 01f33ce
  • That is Java17 or 21, && jetty 10.x and tomcat 9.x
  • Cling itself is for Jetty9.x. So Jetty10.x will be verified after downgrading to Jetty9.x.
  • Jetty9.x. and Jetty10.x seem to be almost the same, but Header editing may be affected.
    • Modifying of HTTP headers in HttpChannel.Listener#onResponseBegin is no longer possible with Jetty 10 jetty/jetty.project#7818
    • Other than that, unknown 😗
    • I've tried not to touch it as much as possible, but I'll probably have to reimplement Client/Server 😩
• 2. If there are no problems, jakarata support will be applied to jpunp, and Patched-libs compiled for Servlet 6.0 will be created.
  • In short, all you need is core and support, so the rest will be omited.
• 3. Combining 1 and 2, operation verification will be performed on the HEAD of the current develop branch (i.e. Spring Boot 3.2).

---

I misunderstood 😚

If we apply jupnp to the develop head (Spring 2.3) and compile it, it will fail with an error. I thought this was caused by a mismatch in servlet implementation, but the correct answer is a mismatch in apache libs versions. (It's true that the current jupnp hasn't undergone Jakarta Migration yet, but those classes are not used in Jpsonic.) Therefore, you can use the jupnp currently published on Maven Central as is (cling can be removed from jpsonic's local Repository).

All we have to do is implement the UPnP clint and server. In that case, we will need to avoid and migrate Apache libs, which have already been deprecated.

• Client is not that difficult. will be recreated with new Apache libraries.
• In the case of Server, there are various methods. There are three methods that are relatively portable. (Jpsonic maintains a compile of Jetty and Tomcat. App Server implementation dependency will be avoided.)
  • Use the old Cling implementation as is (it still works). Socket implementation.
  • Rewrite the old Cling server with the latest Apache Libs. Socket implementation.
  • Use Java's vanilla HTTP server.

So.

---

If it doesn't work with Vanilla HTTP server, it will be implemented with Socket 😏

• Validate with Java standard HTTP server
• Client migration -> Done.
• Legacy Server based on Cling implementation -> Works.
• Rewrite Legacy Server with the latest Apache Libs -> Intuitively, super complex than httpserver. I can't stop my nosebleed.
• Vanilla HTTP server -> It works, but it's non-Latin and garbled. There doesn't seem to be strange code about it .. ? I have a little nosebleed.

At this point, it is certain that UPnP will not be a blocker when migrating to Spring Boot3.2. It would be nice to be able to renew the server implementation if possible, but if you can't investigate a little more and determine the cause, it would be better to postpone it. (In that case, only the server implementation will use the legacy implementation.)

---

Hmm, there seems to be an excessive encoding problem between cling's org.fourthline.cling.transport.impl.apache.HttpExchangeUpnpStream and UpnpMessage. It seems that UMS is also referring to legacy code in the same way. I don't know if Universal Media Server has garbled characters or not.

It'll probably work out somehow. Nosebleed stopped.