Dove e come leggere il file di configurazione delle risorse in servlet applicazione?

StackOverflow https://stackoverflow.com/questions/2161054

Domanda

Nella mia applicazione web che ho per l'invio di email di utenti predefiniti come finance@xyz.com, così vorrei aggiungere che, per un .properties file e l'accesso quando richiesto.Questa è una procedura corretta, se è così allora dove devo mettere questo file?Sto usando Netbeans IDE che è quella di avere due cartelle distinte per origine e file JSP.

È stato utile?

Soluzione

E 'la vostra scelta. Ci sono fondamentalmente tre modi in un archivio applicazioni Web Java (WAR):

1. Metterlo in classpath

In modo che si può caricare da ClassLoader#getResourceAsStream() con un percorso classpath-relativo: 

ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
InputStream input = classLoader.getResourceAsStream("foo.properties");
// ...
Properties properties = new Properties();
properties.load(input);

Qui foo.properties dovrebbe essere collocato in una delle radici che sono oggetto percorso classe predefinita di un webapp, ad esempio /WEB-INF/lib di webapp e /WEB-INF/classes, /lib del server, o /lib JDK / JRE di. Se il propertiesfile è specifico webapp, migliore è quella di metterlo in /WEB-INF/classes. Se si sta sviluppando un progetto di guerra di serie in un IDE, rilasciarlo nella cartella src (cartella di origine del progetto). Se si utilizza un progetto Maven, cadere nella cartella /main/resources.

È possibile, in alternativa anche metterlo da qualche parte al di fuori del percorso di classe di default e aggiungere il suo percorso al classpath del appserver. In Tomcat per esempio è possibile configurare come proprietà shared.loader di Tomcat/conf/catalina.properties.

Se si è collocato il foo.properties in una struttura del pacchetto Java come com.example, allora avete bisogno di caricarlo come di seguito 

ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
InputStream input = classLoader.getResourceAsStream("com/example/foo.properties");
// ...

Si noti che questo percorso di una classe contesto loader non deve iniziare con un /. Solo quando si utilizza un "parente" class loader, come SomeClass.class.getClassLoader(), allora avete davvero bisogno di iniziare con un /. 

ClassLoader classLoader = getClass().getClassLoader();
InputStream input = classLoader.getResourceAsStream("/com/example/foo.properties");
// ...

Tuttavia, la visibilità del file delle proprietà dipende quindi dal caricatore di classe in questione. È visibile solo alla stessa classe di carico come quella che ha caricato il classe. Quindi, se la classe viene caricato da esempio Server classloader comune invece di webapp classloader, e il file delle proprietà è all'interno webapp per sé, allora è invisibile. Il caricatore di classe contesto è la vostra scommessa più sicura in modo da poter posizionare il file delle proprietà "ovunque" nel percorso di classe e / o avete intenzione di essere in grado di sostituire un server fornito uno dalla webapp via.

2. Metterlo in webcontent

In modo che si può caricare da ServletContext#getResourceAsStream() con un percorso webcontent-relativo: 

InputStream input = getServletContext().getResourceAsStream("/WEB-INF/foo.properties");
// ...

Si noti che ho dimostrato di posizionare il file nella cartella /WEB-INF, altrimenti sarebbe stato pubblico accessibile da qualsiasi browser web. Si noti inoltre che il ServletContext è in ogni classe HttpServlet solo accessibili dal ereditato GenericServlet#getServletContext() e in Filter da FilterConfig#getServletContext() . Nel caso in cui non sei in una classe servlet, di solito è solo iniettabile mediante @Inject.

3. Metterlo in file system del disco locale

In modo che si può caricare il solito modo java.io con un percorso del file system del disco locale assoluto: 

InputStream input = new FileInputStream("/absolute/path/to/foo.properties");
// ...

Si noti l'importanza di utilizzare un percorso assoluto. percorsi di file system del disco locali relativi sono un assoluto no-go in un'applicazione web Java EE. Vedere anche il primo "Vedere anche" link qui sotto.

Quale scegliere?

Basta pesare i vantaggi / svantaggi a tuo propria opinione di manutenibilità.

Se i file sono proprietà "statico" e non ha bisogno di cambiare durante il runtime, allora si potrebbe tenerli nella guerra.

Se si preferisce essere in grado di modificare i file di proprietà al di fuori dell'applicazione web senza la necessità di ricostruire e ridistribuire la guerra ogni volta, poi metterlo nel percorso di classe al di fuori del progetto (senecessario aggiungere la directory al classpath).

Se si preferisce essere in grado di modificare le proprietà dei file di codice da dentro l'applicazione web utilizzando il metodo Properties#store(), metterlo fuori dell'applicazione web. Come il Properties#store() richiede un Writer, non si può andare in giro con un percorso del file system del disco. Questo percorso può essere a sua volta passato alla applicazione web come un argomento VM o di proprietà di sistema. Come precauzione, non uso getRealPath() . Tutte le modifiche nella cartella Deploy si perde su un redeploy per la semplice ragione che le modifiche non vengono riflesse indietro nel file WAR originale.

Vedi anche:

Altri suggerimenti

Un avvertimento: se si mette i file di configurazione nella cartella WEB-INF/classes, e il vostro IDE, dire Eclipse, si fa un pulito / ricostruzione, sarà attaccato il tuo file conf meno che non fossero nella directory dei sorgenti di Java. grande risposta di BalusC allude a quella opzione 1, ma ho voluto aggiungere enfasi.

Ho imparato nel modo più duro che se un progetto web "copia" in Eclipse, si fa un pulito / ricostruire da eventuali cartelle di origine. Nel mio caso avevo aggiunto un "dir origine collegata" della nostra biblioteca POJO Java, sarebbe la compilazione della cartella WEB-INF/classes. Facendo un pulito / ricostruzione in quel progetto (non il progetto web app) ha causato lo stesso problema.

Ho pensato di mettere i miei confs nella cartella src POJO, ma questi sono tutti per confs librerie 3a parte (come il quarzo o URLRewrite) che sono nella cartella WEB-INF/lib, in modo che non ha senso. Ho in programma di testare metterlo nella cartella progetti web "src" quando ottengo intorno ad esso, ma quella cartella è vuoto e avere file conf a quanto pare poco elegante.

Quindi, io voto per mettere i file conf in WEB-INF/commonConfFolder/filename.properties, Avanti per la cartella classi, che è l'opzione Balus 2.

Ex:In web.xml file tag

<context-param>
        <param-name>chatpropertyfile</param-name>
        <!--  Name of the chat properties file. It contains the name and description                   of rooms.-->     
        <param-value>chat.properties</param-value>
    </context-param>

E chat.le proprietà che è possibile dichiarare la vostra proprietà come questa

Per Es :

Jsp = Discussion about JSP can be made here.
Java = Talk about java and related technologies like J2EE.
ASP = Discuss about Active Server Pages related technologies like VBScript and JScript etc.
Web_Designing = Any discussion related to HTML, JavaScript, DHTML etc.
StartUp = Startup chat room. Chatter is added to this after he logs in.

E 'solo bisogno di essere nel classpath (aka assicurarsi che finisce sotto / WEB-INF / classes nella .war come parte della costruzione).

È possibile con la vostra cartella di origine così ogni volta che si costruisce, questi file vengono automaticamente copiati nella directory di classi.

Invece di file utilizzando le proprietà, il file XML uso.

Se i dati è troppo piccolo, si può anche utilizzare web.xml per accedere alle proprietà.

Si prega di notare che uno di questi approccio richiederà il riavvio del server app per modifiche vengano riflesse.

Si supponga il codice è alla ricerca per il file dicono app.properties. Copiare questo file a qualsiasi dir e aggiungere questo dir per classpath, creando una setenv.sh nella directory bin Tomcat.

Nel vostro setenv.sh di Tomcat (se questo file non è esistente, crearne uno, Tomcat verrà caricato questo file setenv.sh. #!/bin/sh CLASSPATH="$CLASSPATH:/home/user/config_my_prod/"

Non si dovrebbe avere i file di proprietà in ./webapps//WEB-INF/classes/app.properties

Tomcat class loader sovrascriverà con quella da WEB-INF / classes /

Una buona lettura: https://tomcat.apache.org/tomcat-8.0- doc / class-loader-HOWTO.html

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top