# Best Practice - mit EJB's Kongfigurationsdateien bearbeiten?



## TheDarkRose (20. Aug 2011)

Im Moment bin ich dabei ein kleines Servermanagement Tool zu schreiben. Dazu muss ich aber am Server auch gewisse Konfigrationsdateien bearbeiten. Fakt ist ja, dass man aus einem Application Server nicht direkt auf Dateien zugreift. Aber wie macht man das dann? Schreibt man ein kleines lokales eigenständiges Tool, welches per JMS mit dem AS kommuniziert und das Tool modifiziert dann die Dateien. Oder gibt es andere Wege dies zu lösen?


----------



## Marcinek (20. Aug 2011)

TheDarkRose hat gesagt.:


> Fakt ist ja, dass man aus einem Application Server nicht direkt auf Dateien zugreift



Woher kommt den dieser Fakt? ;D

Ich frage das ernsthaft, weil ich das nun zum zweiten mal gehört habe... Aber iwie nichth nachvollziehen kann.


----------



## maki (20. Aug 2011)

Marcinek hat gesagt.:


> Woher kommt den dieser Fakt? ;D
> 
> Ich frage das ernsthaft, weil ich das nun zum zweiten mal gehört habe... Aber iwie nichth nachvollziehen kann.


Das steht so in der EJB Spek


----------



## mvitz (20. Aug 2011)

Die Idee über JMS geht bestimmt, ansonsten gibt es afaik für jeden AS die Möglichkeit sich einen (dann natürlich speziell auf den AS abgestimmten) FileProvider zu schreiben, den man dann wiederum aus einer EJB nutzen kann. Ansonsten Konfiguration nicht in nem File, sondern in der DB abspeichern?


----------



## Marcinek (20. Aug 2011)

maki hat gesagt.:


> Das steht so in der EJB Spek



Sorry finde ich nicht ;D


----------



## mvitz (20. Aug 2011)

EJB Restrictions

ansonsten evtl noch Interessant (da wird auch auf meine Lösung [JCA] eingegangen)
File access in EJB | Java.net


----------



## Marcinek (20. Aug 2011)

Ahja ;D - Danke.

Das Problem bekommt man nur, wnen man direkt in die EJB die Fachlogik unterbringt.

Wie wäre es, wenn man die EJB Schicht nur dazu nutzt um entsprechende Business Logik aufzurufen.

Client <--> EJB <---> BO's

EJB sucht in ihrem Kontext die entsprechenden BOS und leitet die Anfrage weiter.

Die BOs liefern die Antwort an die EJB.

Die BOs dürfen dann natürlich keine EJB-Container funktionen nutzen um weiter portalbel zu sein.


----------



## TheDarkRose (20. Aug 2011)

mvitz hat gesagt.:


> Die Idee über JMS geht bestimmt, ansonsten gibt es afaik für jeden AS die Möglichkeit sich einen (dann natürlich speziell auf den AS abgestimmten) FileProvider zu schreiben, den man dann wiederum aus einer EJB nutzen kann. Ansonsten Konfiguration nicht in nem File, sondern in der DB abspeichern?



Ja, das meiste kommt eh in eine Datenbank oder auch LDAP (Java und LDAP = grausam). Aber manche Serverdienste lassen sich leider nicht gegen ein DB-Backend konfigurieren. Und dabei fällt mir gerade auf, dass es auch der Fall sein kann, dass sich die Serverdienste auf einem anderen Server als wie der AS befinden. Dann bleibt eh nur mehr lokales Tool und Kommunikation mit JMS übrig, oder? Btw. lässt sich JMS über SSL verschlüsseln?


----------



## mvitz (21. Aug 2011)

Marcinek hat gesagt.:


> Ahja ;D - Danke.
> 
> Das Problem bekommt man nur, wnen man direkt in die EJB die Fachlogik unterbringt.
> 
> ...



Also, wenn in den BOs dann auf Files zugegriffen wird (außer der Zugriff ist lesend und dann sollte er über getResourceAsStream erfolgen), ist es weiterhin verboten. Nur weil du eine Schicht zwischen EJB und File Access legst, greift die EJB immer noch auf Files zu, was verboten ist


----------



## Marcinek (21. Aug 2011)

Jein.

Es geht hier nur um die Portabilität deiner EJB zwischen EJB Containern.

Wenn die BO Schicht nicht auf den EJB Container angeweisen ist (was ist gefordert habe), dann kannst du die nun kleine (schlanke) EJB Schicht leicht portieren. (E.g. Remote Interfaces oder Annotationen ändern).

Wenn du in deinen EJBs Containerspezifischen Code nutzt, dann hast du ehh verloren ;D


----------



## TheDarkRose (21. Aug 2011)

Nee, EJB's programmiere ich brav gegen die JavaEE Api, und nicht spezifisch gegen einen AS. Ist eh schon verrückt genug, dass man für einen Application Client AS-spezifisch programmieren muss.

Was haltet ihr von der JMS-Lösung?


----------



## mvitz (21. Aug 2011)

Bleiben dann ja nur die folgenden Möglichkeiten

1. AS spezifischen Filesystem Adapter
2. JMS Kommunikation mit externem System
3. RMI Kommunikation mit externem System
4. WS Kommunikation mit externem System (SOAP oder REST)


----------

