Logback config XML format detection: if the URL ends with .xml, it should also be considered as XML format.

Some URLs' path referring to XML files do not end with ".xml".

for example, http://${spring.cloud.nacos.config.server-addr}/nacos/v1/cs/configs?group=DEFAULT_GROUP&dataId=logback.xml refers to my logback configuration, but its path ("/nacos/v1/cs/configs") doesn't end with ".xml", so it cannot be loaded correctly.

Comment From: pivotal-cla

@ily433664 Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

Comment From: pivotal-cla

@ily433664 Thank you for signing the Contributor License Agreement!

Comment From: philwebb

I'm concerned this is a bit brittle. Can't you also write your URL as http://${spring.cloud.nacos.config.server-addr}/nacos/v1/cs/configs?dataId=logback.xml&group=DEFAULT_GROUP?

Can you provide some more background about why your path cannot end in .xml?

Comment From: ily433664

I'm concerned this is a bit brittle. Can't you also write your URL as http://${spring.cloud.nacos.config.server-addr}/nacos/v1/cs/configs?dataId=logback.xml&group=DEFAULT_GROUP?

Can you provide some more background about why your path cannot end in .xml?

I use Nacos to centrally manage configuration files, and the URL needs to be written as an HTTP link. In versions prior to Spring Boot 2.x, the URL check was done using url.toString().endsWith(".xml"). Now, in version 3.x, the check is done using url.getPath().endsWith(".xml"). After upgrading Spring Boot from 2.x to 3.x, I can no longer use the previous method, so I have added this additional check.

Comment From: philwebb

Thanks for the extra details. This still feels like a bit of an abuse of the dataId parameter and something that was working by accident rather than designed before. I'm not sure on the best way to fix this, but I'm not sure we should revert back to checking if toString() ends with .xml.

I'm starting to wonder if our check for .xml is really necessary. Perhaps we should just let JoranConfigurator surface any failures. According to commit 6fdc6fa6197d6e4e333e952e1151716d410f7743, logback now only supports XML.

Comment From: ily433664

Thanks for the extra details. This still feels like a bit of an abuse of the dataId parameter and something that was working by accident rather than designed before. I'm not sure on the best way to fix this, but I'm not sure we should revert back to checking if toString() ends with .xml.

I'm starting to wonder if our check for .xml is really necessary. Perhaps we should just let JoranConfigurator surface any failures. According to commit 6fdc6fa, logback now only supports XML.

Although this approach seems a bit inappropriate, it's currently the only way to meet my usage scenario.

I think your suggestion to have JoranConfigurator display failures is also good. If we're going to check for .xml files, I hope we can add (url.toString().endsWith(".xml")), as this would meet my needs.

Comment From: wilkinsona

I'm starting to wonder if our check for .xml is really necessary. Perhaps we should just let JoranConfigurator surface any failures. According to commit https://github.com/spring-projects/spring-boot/commit/6fdc6fa6197d6e4e333e952e1151716d410f7743, logback now only supports XML.

I think that's what we should do.

doConfigure on SpringBootJoranConfigurator is inherited from GenericXMLConfigurator. If the contents of the URL's resource isn't XML, parsing will fail and Logback will report an error. This is the same as it does today for a URL that does identify itself as XML but that cannot be parsed as XML.

Comment From: ily433664

I'm starting to wonder if our check for .xml is really necessary. Perhaps we should just let JoranConfigurator surface any failures. According to commit 6fdc6fa, logback now only supports XML.

I think that's what we should do.

doConfigure on SpringBootJoranConfigurator is inherited from GenericXMLConfigurator. If the contents of the URL's resource isn't XML, parsing will fail and Logback will report an error. This is the same as it does today for a URL that does identify itself as XML but that cannot be parsed as XML.

The situation I am currently encountering is that the content of the URL resource is in XML format, but the URL path does not end with ".xml". I expect that the resource should work properly since the content is in XML format, but right now it shows an error.

Comment From: philwebb

We discussed this today and we're going to remove the XML check entirely. I've opened #42985.