When we have an 'xyzRef' attribute like jobStoreRef in:
<batchPersistence jobStoreRef="xyz"/>
we only do validation and code-assist in the XSD space. This doesn't capture the level of type-awareness we could provide if we built a model of the DS types of the elements configured within the server.xml.
(Here I'll stop and acknowledge I'm probably not using the correct terminology. Apologies for that).
On the other hand, WDT/LDT does build such a model and so it is able to offer a code action of specific values of elements of the right (DS) type .
So here I get a code action completion suggestion of the databaseStore-typed elements that are actually configured in this server.xml
and a diagnostic if the value doesn't match an actually-configured element of the right type:
The XSD validation is a much-simpler validation, just ensuring there are no spaces or commas.
Not sure if the WDT/LDT validation happens after all server config files (dropins/includes) are merged or not. (A bit of a separate issue though).
One more point
I could nitpick a bit with the WDT/LDT validation design with the above example. It seems to complain about a server.xml with just this:
<batchPersistence jobStoreRef="defaultDatabaseStore"/>
<dataSource id="DefaultDataSource">
saying An element of type 'databaseStore' with ID 'defaultDatabaseStore' could not be found.
Well, defaultDatabaseStore may not explicitly be listed in server.xml, but it's still active as a default instance defined at another level, in this case.
Perhaps since it's only a warning we are close enough. But something to think about before we add new code, libraries, etc. to the mix here.
When we have an 'xyzRef' attribute like jobStoreRef in:
<batchPersistence jobStoreRef="xyz"/>we only do validation and code-assist in the XSD space. This doesn't capture the level of type-awareness we could provide if we built a model of the DS types of the elements configured within the server.xml.
(Here I'll stop and acknowledge I'm probably not using the correct terminology. Apologies for that).
On the other hand, WDT/LDT does build such a model and so it is able to offer a code action of specific values of elements of the right (DS) type .
So here I get a code action completion suggestion of the databaseStore-typed elements that are actually configured in this server.xml
and a diagnostic if the value doesn't match an actually-configured element of the right type:
The XSD validation is a much-simpler validation, just ensuring there are no spaces or commas.
Not sure if the WDT/LDT validation happens after all server config files (dropins/includes) are merged or not. (A bit of a separate issue though).
One more point
I could nitpick a bit with the WDT/LDT validation design with the above example. It seems to complain about a server.xml with just this:
saying
An element of type 'databaseStore' with ID 'defaultDatabaseStore' could not be found.Well,
defaultDatabaseStoremay not explicitly be listed in server.xml, but it's still active as a default instance defined at another level, in this case.Perhaps since it's only a warning we are close enough. But something to think about before we add new code, libraries, etc. to the mix here.