Oggi una persona mi ha detto che "I programmatori Java EE non scrivono sui file". Perché non posso scrivere su file da un contenitore Java EE (ad esempio da JBoss)? Che c'è?I programmatori Java EE non scrivono sui file
la pagina migliore per guardare è questa: http://www.oracle.com/technetwork/java/restrictions-142267.html
Esso copre in dettaglio le restrizioni rispetto al modello di programmazione Java EE.
Oltre al punto menzionato sopra, Sicurezza, Portabilità, Clustering, Threading considerano anche le transazioni e la gestione degli errori (i file system non sono transazionali).
Tuttavia, non vi è alcuna magia nera in JVM e puoi creare file (purché tu disponga dei diritti corrispondenti), utilizzare variabili statiche e creare thread se sai cosa stai facendo.
Meglio prendersi il tempo per capire perché queste restrizioni sono in genere suggerite, piuttosto che saltare e scrivere un connettore JCA per il gusto di essere conformi.
Si dovrebbe fare tutto all'interno del contenitore Java EE stesso: non si ha la certezza che si avrà un accesso coerente al filesystem. Ci sono molte ragioni per questo, la più ovvia che le applicazioni in esecuzione in un contenitore avrà:
Si dovrebbe anche pensare che non si deve:
Anche se si ha accesso al file system, con sistemi distribuiti è possibile Si assicuri che la prossima volta che verrà chiamato un metodo, verrà gestito sulla stessa macchina in cui è stato scritto il file.
Poiché la specifica Java EE non offre un'API per scrivere file. Naturalmente, puoi semplicemente utilizzare la normale API IO di Java per creare file, ma devi assicurarti che questo codice sia sicuro per i thread, che qualcuno pulisca i file, che il nome del file venga passato al bean successivo, che il file sia migrato quando il bean viene spostato su un altro nodo nel cluster, ecc.
Così, mentre lo si può fare, nella pratica, si incontrano molti piccoli problemi che rendono davvero difficile la gestione dei file in Java EE.
Assurdità: la specifica J2EE non offre la propria API per un sacco di cose, come la generazione di immagini al volo. –
E il tuo punto è? Se l'API di generazione di immagini è compatibile con J2EE, allora va tutto bene. Quando non lo è e crea file locali, sei nei guai. Ma è un dato di fatto che l'API IO non è conforme a J2EE. –
Se l'istanza non è in cluster o si può garantire che tutte le istanze possano utilizzare un'unità di rete, non è proprio un problema utilizzare i file apis per leggere/scrivere file. Tuttavia, occorre prestare attenzione per ottenere le giuste vie e ripulire se necessario. Spesso non ci sono reali necessità di scrivere file, quindi pensaci di nuovo. Il motivo principale per cui la maggior parte delle persone dà è che in un cluster server diversi non vedono lo stesso file che cambiano i percorsi e così via. Alla fine molte piccole app non vengono eseguite in un cluster simile ...
Per le specifiche Java EE, agli EJB è severamente vietato accedere a qualsiasi risorsa esterna con qualsiasi mezzo che non sia tramite un "gestore risorse" (JDBC, JNDI, JCA, ecc.) E questo include in particolare l'accesso al file system locale attraverso le classi del pacchetto java.io. Inoltre, non è possibile utilizzare ClassLoader per tale accesso, ad esempio per caricare un file di proprietà dal classpath dell'applicazione.
Le ragioni di questa sono già state date in altre risposte:
In ultima analisi, la miglior risorsa per questi argomenti sono un database.
Si dovrebbe considerare un filesystem come EIS (Enterprise Information System). Quindi è possibile creare un ResourceAdapter che accede a questo EIS, in modo simile a un adattatore JDBC che accede a un database. Le specifiche sono qui: http://java.sun.com/j2ee/connector/download.html. Ciò significa che l'accesso ai file è possibile, ma molto più complicato. Questa specifica ti consente persino di creare una sorta di "thread" chiamati Work.
Per interagire con sistemi legacy non j2ee, occasionalmente devi fare "cose cattive" come i/o socket, scrivere in file, ecc. Nel migliore dei mondi, la specifica di j2ee sarebbe seguiti rigorosamente, ma le persone se la cavano con roba non-jeeee tutto il tempo per motivi di convenienza e per portare a termine il lavoro. Ci sono modi per liberare queste cose in modo sicuro e ponderato.
Anche se potrebbe non esserci "magia nera", il gestore della sicurezza JVM del contenitore potrebbe essere stato impostato in modo tale che la creazione di file non sia possibile –
Il collegamento è rotto, stupido Oracle chi uccide Java –
@ BorisŠuška Questo link sembra molto simile al originale: http://www.oracle.com/technetwork/java/restrictions-142267.html – ewernli