just like the issue (WELD-2445) says, there was a problem of not loading XSD for 1.1 at all.
There was a clash where two schemas had identical namespaces (which is something we cannot really tackle).
So as a workaround we came with this - we check the file itself and based on that try to predict, which XSD to load.
There is very little you can assume about the file itself, it can even be empty for that matter, so searching for this string was the only option we came with.
So, to answer your questions:
Does this need to be done at all? If so can it be done a different way?
Yes, we need to do it otherwise one XSD will never be loaded (here it was 1.1 version) leading to an error if used.
I don't know if it can be done differently, I haven't figured any other way back there.
Isn't the thing that defines something as a beans element the element name and the namespace?
Yes, but how does this relate to the problem?
Could the version attribute be used? Could the version information be encoded in the namespace itself?
Technically speaking yes, practically no because this is not for us to choose. CDI spec dictates some requirements for beans.xml and that is all we can rely on, hence this solution.
We can only do this for Weld specific descriptor. E.g. in case you would validate the file against http://www.jboss.org/schema/weld/beans_1_1.xsd then we could impose some additional structure.
But mostly people would go with basic one.
I know that would be more of a CDI spec question.. If the xsd files are backwards compatible could the latest version just be used every time?
I think you cannot just hop on to the newest version because applications can define their beans.xml in different ways and basically deliberately declare older version of the schema.
About the backward compatibility - I do not know from the top of my head whether they are compatible like that. You can compare them here.
Do you have any actual problem with the current solution?
When I add a beans.xml file without a schema location wildfly is telling me that I don't have a beans element. If I add a comment <!-- beans_1_1.xml --> then the warning goes away. So it looks like the schema location is required and the beans element is identified by the element name, namespace, and the schema location. That's the actual problem I'm trying to solve. It's not that much work to just include the schema location. I'm mostly just here because I don't like how it works. It's like the schema locations is being used as the namespace. Does the CDI spec say you can't look for the version attribute? I don't think the empty file handling would prevent this as long as the file contents get replaced with the EMPTY_BEANS_XML content earlier than when you look for the attribute. Who decided to give all these XML files the same namespace?
Edit: Idk, it seems like these files should work without the schema location but if you can't check the version attribute and you still need to validate against old XSD files then I'm not sure there is a way to make this happen.
My understanding of how XSD checking works is that by default it tries to load the XSD files based on xmlns. Then you can specify schemaLocation - doing so will override the default and you specifically say where to find those schemas.
This is then further modified by parser used under the hood, you can override either of those two and provide your own schema - typically you want to provide some packed in JARs you have instead of downloading it. And that's what Weld does.
Normally we would just go and add bunch of schemas to validate your beans.xml against and based on namespaces, some of them will be matched.
Now comes into play the problem of clashing namespaces - this is probably an oversight when new schema for 2.0 was introduced. You just cannot have 1.1 and 2.0 together due to this problem.
It's sadly something we will have to live with as changing it would break existing deployments.
Hence the hack we added where we try some simple best-effort approach to detect whether you specifically asked for 1.1 schema (while running CDI 2.0), which is very rare, but can happen.
BTW can you post what warning are you getting exactly? I don't think WFLY itself does these checks.
18:46:52,919 WARN [org.jboss.weld.deployer] (MSC service thread 1-8) WFLYWELD0012: Warning while parsing vfs:/content/thesixcornersapp-1.0.0-SNAPSHOT.ear/thesixcornersapp-server-1.0.0-SNAPSHOT.war/WEB-INF/beans.xml:3 cvc-elt.1.a: Cannot find the declaration of element 'beans'.
The file looks like this:
<?xml version="1.0" encoding="UTF-8"?>
It's not that much work to just add the schemaLocation though.
Yea, I'd either add schemaLocation or just bump the version to 2.0.