Schema XML di configurazione Spring: con o senza versione?

Sono nuovo per la spring. Una cosa che mi confonde è che a volte vedo file di configurazione XML con schemi con versioni, ma a volte con quelli senza versioni. Ad esempio, a volte vedo qualcosa di simile

     

E a volte in questo modo:

      

Si noti che gli schemi spring-beans e spring-context sono diversi nei due esempi.

Quindi, la mia domanda è, quale stile useresti e perché? In particolare, lo schema versione diventerà non disponibile in futuro e lo schema non versione sarà compatibile con un’applicazione corrente quando Spring aggiornerà lo schema?

Una domanda a parte è: dove posso trovare un elenco degli schemi primaverili con versione?

Grazie molto!

Si consiglia di utilizzare gli XSD “senza versione”, perché sono mappati alla versione corrente del framework che si sta utilizzando nell’applicazione.

Le applicazioni e gli strumenti non devono mai provare a recuperare tali XSD dal Web , poiché tali schemi sono inclusi nei JAR. In tal caso, di solito significa che la tua app sta tentando di utilizzare un XSD più recente rispetto alla versione del framework che stai utilizzando o che il tuo IDE / strumento non è configurato correttamente.

A mia conoscenza, c’è solo un caso in cui si desidera utilizzare specifiche versioni XSD: quando si tenta di utilizzare un attributo XML che è stato deprecato / modificato in una versione più recente. Questo non succede spesso a dir poco.

Ad ogni modo, il team di Spring dovrebbe abbandonare gli schemi di versione per Spring 5.0, vedere SPR-13499 .

Altro su “versionless == current version”:

Questi file XSD sono inclusi nei JAR di spring: l’XSD “senza versione” è mappato all’ultima versione durante la compilazione (vedere i file spring.schemas che effettivamente creano quel collegamento). Inoltre, i file disponibili online sono costruiti allo stesso modo (vedi la destinazione “schemaZip” nella build gradle ).

Non sono sicuro che la loro sia una guida, ma la mia preferenza personale è quella di fare riferimento agli schemi non in versione – in generale, se stai lavorando contro le versioni più recenti dei progetti Spring (Spring core, integrazione ecc.), Allora puoi fare riferimento agli schemi non risolti.

Gli schemi non risolti puntano all’ultima versione dei progetti, quindi è ansible che potrebbero non essere la grammatica corretta se si utilizza la versione veramente vecchia di Spring (ad esempio la versione 2.5 rispetto alla versione 4.0 attualmente rilasciata), in questi casi potrebbe essere migliore puntare agli schemi di versione.

Un altro punto da sottolineare è che se ansible è meglio evitare del tutto xml e andare con lo stile @Configuration basato su Java per configurare i bean Spring.

So che la domanda ha più di due anni, ma è mia intenzione procedere con caucanvas.

Nel mio caso stavo sviluppando uno strumento CLI stand-alone, un barattolo di barattoli. E quando i miei XSD dichiarati erano senza versione (sic), avrei notato errori molto strani. Considera il seguente frammento xml:

inserisci la descrizione dell'immagine qui

Senza le versioni, l’attributo value-separator nel segnaposto della proprietà causerà il seguente errore:

 org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 22 in XML document from class path resource [META-INF/slitools/sli-cli-applicationContext.xml] is invalid; nested exception is org.xml.sax.SAXParseException: cvc-complex-type.3.2.2: Attribute 'value-separator' is not allowed to appear in element 'context:property-placeholder'. at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:399) 

Si potrebbe provare a vedere cosa viene trascinato via dalle dipendenze transitive (anche se un’attenta ispezione ha mostrato che stavamo tirando i vasi giusti contenenti gli xsds giusti (e ci assicuravamo di fare la giusta proprietà unendoci al plugin per lo schermo quando stavamo costruendo l’uber -jars.)

Ovviamente YMMV. Se funziona per un progetto, meglio è. Ma se mai inizi a vedere strani errori che sfidano la spiegazione e non hai la larghezza di banda per inseguirli fino alla causa principale, meglio essere precisi.

Il contro-argomento di questo è che se cambi mai la versione delle tue dipendenze primaverili, devi assicurarti che la versione xsd esplicita sia corretta. Nel software, si tratta di trade-off (e sapendo cosa si ottiene con le proprie decisioni).

Troverai il file META-INF / spring.schemas nel tuo Jar. Quel file definisce tutte le versioni compatibili xsd. Se punti all’URL senza alcun numero di versione, per impostazione predefinita sarebbe compatibile con il tuo file Jar. Per quanto tu non abbia due diverse versioni di spring jar in classpath, l’applicazione non avrà errori di runtime.

Mi sono iscritto per il corso di spring su udemy. Ho seguito ogni passaggio che il mio istruttore mi mostra di fare. Quindi se stai usando mvc molla e ibernazione potresti incontrare questo errore Imansible leggere il documento dello schema ‘ http://www.springframework.org/schema/tx/spring-tx.xsd ‘ ecc per:

  and  elements 

nel mio file di configurazione di spring avevo questi due URL

  http://www.springframework.org/schema/mvc http://www.springframework.org/schema/mvc/spring-mvc.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx.xsd 

in xsi: schemaLocation, con cui ho sostituito

  http://www.springframework.org/schema/mvc http://www.springframework.org/schema/mvc/spring-mvc-4.2.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-4.2.xsd 

in realtà ho visitato questi due siti http://www.springframework.org/schema/mvc/ e http://www.springframework.org/schema/tx/ e ho appena aggiunto l’ultima versione di spring-mvc e spring-tx ie , spring-mvc-4.2.xsd e spring-tx-4.2.xsd

Quindi, a mio parere, specificare esplicitamente la versione non è una buona pratica. Spero che questo ti aiuti. Grazie.

Prendi in considerazione l’utilizzo di xsd senza versione. Questo farà sì che gli strumenti raccolgano la versione di xsd corrispondente alla versione del jar a molla che stai usando (guarda il file spring.schemas nel tuo barattolo). In caso di incompatibilità durante l’aggiornamento delle tue librerie primaverili (che dovrebbe essere davvero raro) dovresti riuscire a prenderle durante la compilazione.

Ciò fornirà l’opportunità di decidere se è necessario introdurre xsd con versione per quel file o in realtà evolvere dall’uso di un attributo / elemento arcaico e deprecato. Spero che sarà il dopo.

Altrimenti il ​​rischio è di usare per sempre un ansible attributo / elemento deprecato.