Base Resource should not be an alias

[tesshucom]

Problem description

A WARN is output to the startup log. So far, no major injuries have been confirmed. I just feel sick.

Base Resource should not be an alias

INFO --- c.t.j.d.base.LegacyHsqlDaoHelper         : Embedded database shutdown complete.
INFO --- com.tesshu.jpsonic.Application           : Starting Application v114.2.0-SNAPSHOT using Java 21.0.3 with PID 10934 (/jpsonic/jpsonic.war started by jpsonic in /jpsonic)
INFO --- com.tesshu.jpsonic.Application           : The following 1 profile is active: "host"
WARN --- o.e.j.s.handler.ContextHandler           : Base Resource should not be an alias
INFO --- c.t.j.service.VersionService             : Starting Jpsonic 114.2.0-SNAPSHOT (c969088b941f74940c6e9f6564600df1500dae4b), Java: 21.0.3, OS: Linux
INFO --- com.tesshu.jpsonic.Application           : Started Application in 26.459 seconds (process running for 28.31)

It's very similar to a Jetty glitch that existed a long time ago.

Steps to reproduce

Just run Jpsonic.

System information

• Jpsonic version: 114.1.0
• Tomcat/standalone: Both Standalone and Docker. But only if Jetty is used.

[tesshucom]

Hmm... Windows Standalone can be improved so that this warning does not appear. The warning when starting Docker(Linux) doesn't seem to go away. A little more investigation is required.

ttps://github.com/jetty/jetty.project/issues/5956

If it is a regression of AliasChecker, it is faster to suppress it.

ttps://github.com/jetty/jetty.project/issues/687

---

ttps://github.com/jetty/jetty.project/pull/11279

Ah. That might be it.🙄

---

Although the specification change appears to be controversial, it appears that opinions are being carefully exchanged regarding the desired operational specifications for a general-purpose Web Server. (On the other hand, this is a known design issue for Apps under Spring Framework.) There is no harm, so I think there is no problem in suppressing it.

• It's easy to change the log level, but I don't want to suppress the entire ContextHandler.
• It also briefly touches on its suppression. Well, what they're talking about is a bit uncommon, so I can't think of an implementation right away. It would be nice if implementations were added to conform to the new specification. (I would like some guidance? new document? 🥱)
• It's not an emergency, so you may not need to stick to hotfixes.

[tesshucom]

I guess this is what it boils down to.
for resources registered in nested springboot jar

This is troublesome 🥱

This is probably the front line.

ttps://github.com/jetty/jetty.project/issues/11492

[tesshucom]

#2638

There is currently a log issue that requires reverting to avoid the issue. That reverting suppresses this problem (because it reverts to before the specification change that caused the problem).

Therefore, the fix for this issue is temporarily on hold. It would be better to keep pace with the progress of jetty/jetty.project#11492.

[tesshucom]

In v114.1.2, rollbacks covered up this issue. However, Spring Boot will be updated to 3.3 in v114.1.3. (Including inevitable security updates) Spring Boot 3.3 relies on ClassMatcher for Jetty 12.0.9 or later. Jetty 12.0.9 is therefore a mandatory requirement. I guess I'll have to face this problem a little more.

It was assumed that the issue would be so minor that it would not require a hotfix, but that may not be the case. As stated in Additional notes, it appears that the status display on the UI will no longer be Green in DSM. This is very confusing for users, so it's better to suppress the warning somehow.

Well, this is most likely a misunderstanding on my part. If #2645 is resolved, it may be resolved.

Therefore there are two Paths

• Add code for Jetty's Alias Checker
• Do nothing and wait for Jetty's functionality to be updated. (Users will be anounced as a known issue)

[tesshucom]

Well...

Therefore there are two Paths

• Add code for Jetty's Alias Checker
• Do nothing and wait for Jetty's functionality to be updated. (Users will be anounced as a known issue)

This may be a bit of an engineer's way of thinking. In either case, it will be acceptable as long as the circumstances are explained. No one is at fault. If the other party is an engineer.

However, if a normal user sees a warning like the following:

WARN --- o.e.j.s.handler.ContextHandler : Base Resource should not be an alias

Also, if users have to read a redundant explanation of what it is, it will be more or less stressful. 🤔🤔🤔

Here is the expected reaction:

Did I make a mistake in some settings!?😵😨🤨
I read it, but...I don't really understand it.😵😨🤨

Users just want to manage and listen to music. We don't think I want to acquire more knowledge than necessary. So, although an engineer might be confused for a moment, the following method seems to be effective.

• Suppress warnings due to false positives by directly changing the log level of ContextHandler

Of course, its effectiveness is conditional on it being an interim response during a transitional period. Also, to be honest, alias checking is not necessary due to requirements.