# Zugriff auf Files aus einer EAR Anwendung



## y0dA (16. Dez 2010)

Hallo!
Folgende Sachlage:
Ich habe hier ein Webprojekt (JSF 1.2) welches als EAR File gepackt wird, einen Websphere als Server und möchte mit Jasperreport Berichte erzeugen.

Nun besteht das Problem darin dass ich nicht weiß wo ich die *.jasper* Files für die Berichte ablegen sowie wie ich drauf zugreifen soll. Im Detail muss ich nämlich das Templatefile (.jasper) befüllen nur bekomme ich immer eine *FileNotFoundException* weil ich mittels:

```
FacesContext facesContext = FacesContext.getCurrentInstance();
		ServletContext servletContext = (ServletContext) facesContext
				.getExternalContext().getContext();
		String path = servletContext.getRealPath("/");
```

folgenden Pfad bekomme:

```
File "D:\Entwicklung\ProjektXY\tools\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\pc47348Node01Cell\Ear.ear\Web.war"
```


----------



## Deadalus (17. Dez 2010)

Du solltest in einer EAR Anwendung auf jeglichen Zugriff aufs Filesystem verzichten. Ich würde dir raten diese Files als Blob in der Datenbank zu speichern.  

Denk daran das eine EAR Anwendung auch in einem Cluster laufen sollte. Da kannst du dir nie sicher sein welche Node gerade den Task abarbeitet und ob da lokal die Files liegen.


----------



## JohannisderKaeufer (17. Dez 2010)

Liegen die .jasper Dateien zur Zeit des Deployments vor?

Dann kannst du per class.getResourceAsStream("Pfad") auf die im ear liegenden templates zugreifen.  JasperReports kann laut api auch mit streams umgehen.


----------



## y0dA (18. Dez 2010)

Danke für eure Antworten!

Das mit dem speichern in die Datenbank hatte ich mir schon als Alternative gedacht?

Ja die .jasper Dateien liegen zur Zeit des Deployments vor.

```
class.getResourceAsStream("Pfad")
```
Werde ich am Montag mal testen.

Was ist denn hierbei so "best practise"?
Also in die DB speichern, oder im Projekt ablegen oder ein separaten Folder am Server anlegen und dort die Jaspers ablegen.


----------



## maki (18. Dez 2010)

Best Practice ist, sich an den Standard zu halten, dieser verbietet die Nutzung von java.io.File, dafür gibt es zB. JTA.

Ansonsten sind Streams eindeutig erlaubt


----------



## y0dA (18. Dez 2010)

maki hat gesagt.:


> Best Practice ist, sich an den Standard zu halten, dieser verbietet die Nutzung von java.io.File, dafür gibt es zB. *JTA*.



Dem entnehme ich dass du .jasper Dateien in der Datenbank halten würdest?

Und wo steht dass man java.io.File nicht nutzen sollte?


----------



## maki (18. Dez 2010)

> Dem entnehme ich dass du .jasper Dateien in der Datenbank halten würdest?


Wenn Jasper Streams schluckt dann natürlich nicht.



> Und wo steht dass man java.io.File nicht nutzen sollte?


In der Spec.

java.io.File ist problematisch mit Clustering, Transaktionen und aufgrund der Tatsache dass es nie sicher ist ob die Archive (EAR,WAR) auch wirklich entpackt werden zu Dateien 
Es gibt JCAs um Files in EJBs zu nutzen, oder eben eine DB, aber wenn es nicht sein muss...

Ist zwar alt und nicht WAR/EAR spezifisch aber dennoch sehr interessant imho: Smartly load your properties - JavaWorld


----------



## y0dA (14. Jan 2011)

Sodale.

Ich habe den Sachverhalt nun mit Streams umgesetzt. Lustigerweise funktioniert alles lokal auf meinem Websphere, wenn ich jedoch auf unsere Testsystem deploye (auch Websphere) dann ist der *inputStream* NULL.


```
InputStream inputStream = getClass().getResourceAsStream(
				printConfiguration.getPrintTemplate());
```

Der Resourcenname ist einfach /package/Xyz.jasper also bspw.: /at/gv/print/DruckeLalelu.jasper.

Wollte dies hier nur mal gepostet haben vllt. hatte ja jemand schon ein ähnliches Problem und kann mir hierzu Tipps liefern..

Eventuell ein Classloader Problem?
Oder liegt es daran dass ich lokal Windows habe und das Testystem auf Linux läuft? Obwohl ja "/" auf Linux eh legitim ist=?


----------



## FArt (14. Jan 2011)

Classloader-Problem ist sehr wahrscheinlich. 

Nutze in einer Enterpriseumgebung nie den Classloader einer Klasse sondern den Kontext-Classloader. Die zwei könnten unterschiedlich sein und u.U. nicht gegenseitig delegieren, abhängig von Konfigurationsparametern am Applikationsserver.

Thread.currentThread().getContextClassloader()


----------

