Auf Thema antworten

hallo Stroker89,


"aber gleichzeitig kannst du nicht deine Art zu programmieren, als den Weg schlechthin darstellen. Das finde ich einfach nur anmaßend."


nein will ich auch nicht, was ich schreibe / erzähle ist meine meinung, und sicher nicht absolut...


...für mich ist aber auch nicht absolut, was "die grosse masse" erzählt  (nicht nur im it-bereich!)


wenn alle alles immer nur "standard" machen, na ja...



"Im Nachhinein kann ich wirklich behaupten, aus dieser Sache wirklich viel gelernt zu haben, da es mein erstes JEE Projekt war."


eben. so lernst du noch einigermassen, was im hintergrund "abgeht". viele framework-einsetzer haben nicht den geringsten schimmer davon, oder sind halt nicht daran interessiert. (im sinne von "das ist ein framework, das läuft halt einfach...")



und, nur so als hinweis: java-webapplikationen != jee


servlets's, jsp's, etc. dafür brauch man eine "servlet-engine", nicht aber einen "richtigen" j2ee-server (-> jboss, glassfish, weblogic) tomcat könnte man mit "openEJB" erweitern...


auch web-mvc frameworks (struts, spring, jsf & co.) brauchen keinen "richtigen" j2ee-server, sondern nur einen servlet-container.


zu j2ee gehören bspw.:


- ejb's (enterprise java beans)

- jms (java message service)

- irgendwelche CORBA-konnektoren um legacy-systeme in die "systemlandschaft" miteinzubeziehen. (da bin ich mir nicht 100%-ig sicher, bei den oberen punkten schon!)

- mehr weiss ich auch nicht. schliesslich verwenden wir KEIN jee/j2ee (wie es auch immer heisst!), sondern haben tomcat als app server. relativ simple webapplikationen, der app server muss einfach html ausgeben können. nicht mehr, nicht weniger. dafür brauchen wir keine jee-features, grundsätzlich zum glück nicht, wobei ich in ein, zwei fällen aber auch schon an eine ejb-lösung gedacht habe... schlussendlich liess sich die sache aber problemlos & elegant OHNE ejb's realisieren...



Oben