[JAVA] leggere query da file xml

[TorpedoBlu]

Ho a disposizione java 4 su websphere 5.... posso usare xsdbeans ad esempio..

vorrei poter creare un file xml dove inserire le quesy del mio progetto, in modo da richiamarle semplicemente con un ID (evitando di inserirle nei singoli DAO)

per fare questo pensavo di fare una classe che caricasse il file xml all'avvio, e che mi mantenga la formattazione della query in modo che sia stampabile dai logs e leggibile (non tutto su una riga)

qualcuno ha qualche esempio?

[gokan]

La classe java.util.Properties mette a disposizione il comodissimo loadFromXML(InputStream is), peccato che si possa usare da java 5 in poi.
Se non vuoi ricorrere a librerie esterne ti conviene quasi quasi che te lo leggi a manina con un BufferedReader :D

[vladix]

La classe java.util.Properties mette a disposizione il comodissimo loadFromXML(InputStream is), peccato che si possa usare da java 5 in poi.
Se non vuoi ricorrere a librerie esterne ti conviene quasi quasi che te lo leggi a manina con un BufferedReader :D

che bisogno c'e di un file xml se te lo leggi come un qualsiasi file di testo :mbe:

anche io uso java 4 con con websphere 5 , e x leggere xml uso xerces. Potresti fare un xml strutturato in questo modo:

<?xml version="1.0" encoding="ISO-8859-1"?>
<root>
<query id="query1">
<![CDATA[
select * from universe
]]>
</query>
</root>


dopo di che ti leggi tutti i tag query e ti fai una "mappa" con l'id come chiave e la query come valore

cmq se usi un framework come hibernate le query le puoi scrivere nel file xml di configurazione della classe bean e te la chiama in automatico quando fai una query ( o insert , update ... )

[TorpedoBlu]

che bisogno c'e di un file xml se te lo leggi come un qualsiasi file di testo :mbe:

anche io uso java 4 con con websphere 5 , e x leggere xml uso xerces. Potresti fare un xml strutturato in questo modo:

<?xml version="1.0" encoding="ISO-8859-1"?>
<root>
<query id="query1">
<![CDATA[
select * from universe
]]>
</query>
</root>


dopo di che ti leggi tutti i tag query e ti fai una "mappa" con l'id come chiave e la query come valore

cmq se usi un framework come hibernate le query le puoi scrivere nel file xml di configurazione della classe bean e te la chiama in automatico quando fai una query ( o insert , update ... )

no hibernate e no java5... non sono ufficialmente riconosciuti dal cliente (banca che fino a oggi faceva tutto con stored procedure COBOL...)

Ho risolto con xsdbeans che è integrato in WebSpehere 5.1

Nel frattempo sto riflettendo su quale pattern utilizzare:

l'applicazione è fatta da diversi EAR e ognuno avrà il suo file di statement (con le query ) e quindi una classe che faccia da repository, tale classe si caricherà alla prima chiamata (singleton) l'elenco delle query e le offrirà con una hashmap passando semplicemente un queryID.

PEr rendere più dinamica la cosa (poter fare il load di diversi file di statement in fase di collaudo).
Ho centralizzato le location dei vari file in un file di properties

elenco_statements.xml

che conterrà gli URL remoti dei vari statement :


[ statementId1, statement1.xml ]
[ statementId2, statement2.xml ]
...
[ statementIdN, statementN.xml ]

Ogni classe repositori leggerà il proprio url da tale file e caricherà lo statement corretto. Ripeto che ogni repository per ovvii motivi sarà singleton (caricherà lo statement<X>.xml solo una volta, a meno che non si invochi da una servlet ad hoc un metodo reload() ).

Il problema è ora scrivere una classe AbstractRepository che venga estesa da ogni EAR, visto che non è possibile fare un singleton abstract.. ma ho la necessità che lo sviluppatore definisca solamente quale statement caricare (passando uno statementId e leggendo il file di properties)

Dovrei farmi una factory dei repository, evitando che ogni repo sia singleton e basandomi sul fatto che sia la classe stessa ad essere singleton e a restituire sempre le stesse istanze dei repository... ma la vedo pericolosa.. dovrebbe a questo punto incapsulare le singole istanze e fornire direttamente la query corretta (perdendo però la possibilità del polimorfismo e centralizzando tutto nell'EAR centrale)

qualcuno ha consigli?

i file di properties e xml saranno su una nas e non sul server dove gira l'applicazione (per ovvii motivi di comodità ).

Tutto il discorso nasce dall'esigenza di offrire nel progetto centrale il "framework" di persistenza, ma se si aggiunge un progetto esso dovrà solo implementare i propri dao e limitare al massimo le modifiche al progetto centrale (le factory invece mi obbligano a inserire nuove entry per i nuovi progetti oltre che agiornare i file di configurazione, cosa che eviterei con l'ereditarietà)

[vladix]

ma forse a te e più comodo definirti una tabella su qualche db e caricare tutte le query su quella tabella , e poi ogni volta che ti serve una query te la vai a cercare su quella tabella ... cosi eviti qualsiasi tipo di configurazione e di caricare tutte le query in memoria ( ogni ear avrà si le sue query ... ma scommetto che gli ear gireranno sullo stesso server ) . Ed in più eviti di riscrivere il programma se da websphere passi a jboss ... oppure se da la 5 migri alla 7 ( casomai la libreria xml cambiasse )

[TorpedoBlu]

ma forse a te e più comodo definirti una tabella su qualche db e caricare tutte le query su quella tabella , e poi ogni volta che ti serve una query te la vai a cercare su quella tabella ... cosi eviti qualsiasi tipo di configurazione e di caricare tutte le query in memoria ( ogni ear avrà si le sue query ... ma scommetto che gli ear gireranno sullo stesso server ) . Ed in più eviti di riscrivere il programma se da websphere passi a jboss ... oppure se da la 5 migri alla 7 ( casomai la libreria xml cambiasse )

il gatto che si morde la coda? faccio una query per avere la query da eseguire? overhead a manetta? ogni query ne faccio 2? no grazie, è la stessa cagata che hanno fatto qui, vuoi mettere avere un file xml su una nas e cambiare la configurazone al volo per collaudo ecc...?

e poi per caricare le query nuove su db? conta che in certi ambienti mica puoi avere un client su db2 e vai a brucio su db... difficile che una banca dia ad un esterno questa possibilità.. e cmq è davvero poco dinamico in fase di sviluppo/test/collaudo...