fix: Log4j configurations and wording

[vy]

The current Log4j 2 documentation contains configurations with deprecated and redundant packages attributes, which cause runtime warnings for users – see apache/logging-log4j2#2966. This PR

• Removes the usage of the deprecated (and redundant) packages attribute
• Removes the usage of the redundant status attribute
• Adds XML namespace (to enable IDE assistance while users are editing)
• Adapt Log4j component and XML naming conventions
• Replaces occurrences of Log4j2 in text with Log4j 2

IS YOUR CHANGE URGENT?

Not urgent, can wait up to 1 week+

REVIEWERS

• @maciejwalkowiak
• @adinauer
• @ppkarwasz

PRE-MERGE CHECKLIST

Make sure you've checked the following before merging your changes:

• Checked Vercel preview for correctness, including links
• PR was reviewed and approved by any necessary SMEs (subject matter experts)
• PR was reviewed and approved by a member of the Sentry docs team

[vercel]

@vy is attempting to deploy a commit to the Sentry Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
changelog	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 19, 2024 5:20pm
develop-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 19, 2024 5:20pm
sentry-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 19, 2024 5:20pm

[lizokm]

@bitsandfoxes could you take a look at this when you have a moment?

[ppkarwasz]

@vy, looks great, but I would skip the schema location in the examples. Since Sentry is not in the generated XML Schema, the examples would not validate.

Some context for the Sentry team

We recently added a log4j-docgen tool that generates documentation and XML schemas from the Javadoc of elements annotated with @Plugin*.
You can find more information on the Log4j Docgen website.

A priori the tool could generate an XML Schema, which includes the Sentry element and all its options, but it is still pretty much rough around the edges and currently we only use it for our internal artifacts.

The long term plan, however, is:

• We ask Log4j Plugin vendors to publish a *-log4jdoc.xml artifact with each release.
• We configure Dependabot to watch for updates to sentry-log4j2.
• At each new release we regenerate our Plugin Reference to include Sentry,
• At each new release we regenerate our XSD Schemas to include a Sentry element.

As I mentioned before, right now such a process would be far from being easy, but in time it could show the size of the Log4j community and make logging.apache.org more of a common effort.

[ppkarwasz]

Suggested change

	<Configuration xmlns="https://logging.apache.org/xml/ns"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="https://logging.apache.org/xml/ns https://logging.apache.org/xml/ns/log4j-config-2.xsd">
	<Configuration xmlns="https://logging.apache.org/xml/ns">

[ppkarwasz]

Suggested change

	<Configuration xmlns="https://logging.apache.org/xml/ns"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="https://logging.apache.org/xml/ns https://logging.apache.org/xml/ns/log4j-config-2.xsd">
	<Configuration xmlns="https://logging.apache.org/xml/ns">

[ppkarwasz]

Suggested change

	<Configuration xmlns="https://logging.apache.org/xml/ns"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="https://logging.apache.org/xml/ns https://logging.apache.org/xml/ns/log4j-config-2.xsd">
	<Configuration xmlns="https://logging.apache.org/xml/ns">

[vy]

@ppkarwasz, Thanks so much for the review.

I would skip the schema location in the examples. Since Sentry is not in the generated XML Schema, the examples would not validate.

I prefer to keep the schema location, since, contrary to the current situation (and your proposal) where there is no IDE assistance, my proposal will enable complete IDE assistance except for one line: <Sentry .../>. As can be seen from the user report in apache/logging-log4j2#2966, a typical Sentry user's log4j2.xml contains dozens of lines of code that can take advantage of the XML schema. All in all, I leave it at the discretion of the Sentry team whether to keep the XML schema location or not.

The long term plan, however, is:

Log4j team can ping Sentry again when this plan is realized.

[ppkarwasz]

I prefer to keep the schema location, since, contrary to the current situation (and your proposal) where there is no IDE assistance, my proposal will enable complete IDE assistance except for one line: <Sentry .../>. As can be seen from the user report in apache/logging-log4j2#2966, a typical Sentry user's log4j2.xml contains dozens of lines of code that can take advantage of the XML schema. All in all, I leave it at the discretion of the Sentry team whether to keep the XML schema location or not.

I think this is a problem that <xsd:include> could fix. A small XML schema could include the one at logging.apache.org add a Sentry type and override the org.apache.logging.log4j.core.Appender element group.