Ein ControllerServlet für andere Servlets - Sinnvoll oder nicht?

[Stroker89]

Hallo liebe Leute,

ich bin momentan an einem Webprojekt zugange, das recht viele Servlets beherbegen wird (Kontrollschicht). Nun stellt sich mir die Frage ob es vielleicht sinnvoll wäre, wenn ich ein ControllerServlet schreibe, was bei jeder Aktion aufgurefen wird und das dann die Aufgabenverteilung an die anderen Servlets übernimmt.

Ist sowas überhaupt sinnvoll?

Gruß Martin

 

[mvitz]

Nennt sich dann FrontController (Core J2EE Patterns - Front Controller). Ich habe zuletzt für ein Projekt einmal so etwas selbst gebaut (va-mm - Revision 102: /trunk/src/java/de/hsnr/va/mm/mvc).

Wenn man das so macht, kann man jedoch auch darauf verzichten, dass alle deine Klassen Servlets sind, sondern es reicht, wenn dein FrontController ein Servlet ist.

 

[Stroker89]

Danke ich hab mir das ganze mal angeschaut und mir ist auch klar, wie der Frontcontroller zu den Handlern forwarded aber was mir nicht klar ist wie ich dann von dem handler wieder zurück zum Controller komme um dann das Ergebnis, auf den JSPs auszugeben

 

[mvitz]

Idealerweise geben deine Controller ein Ergebnis zurück, welches der Frontcontroller zu einer View (z.B. JSP) auflösen kann.

Der FrontController hat dann neben dem finden deines richtigen Controllers noch die Aufgabe, das Ergebnis des Controllers so weiter zu bearbeiten, dass die View anschließend angezeigt wird.

 

[Stroker89]

Danke erstmal für die Erklärung hab jetzt versucht mit einem Servlet den Pfad der Aufrufenden .jsp rauszufinden, was aber komischerweise nicht ganz klappt

mit

String fromView = request.getRequestURI();

bekomme ich immer den Pfad des Servlets zurück

 

[mvitz]

request.getPathInfo();

 

[Stroker89]

Jetzt hab ich endlich verstanden wie es funktioniert

Im Prinzip muss man das HandlerServlet vom Frontcontroller gar nicht aufrufen sonder könnte es rein theoretisch einfach instanzieren und dann eine Methode im Handler implentieren der den Pfad zur View zurück gibt und dann im Frontcontroller zur View dispatchen.

Sehe ich das richtig?

 

[mvitz]

So ganz habe ich nicht verstanden, was du genau möchtest, evtl. hilft mir ein Beispiel auf die Sprünge.

 

[SlaterB]

der Frontcontroller muss kein anderes Servlet mit public void doGet() aufrufen, richtig,
die Bearbeitung kann losgelöst von allen Frameworks in beliebigen eigenen Klassen geschehen solange am Ende irgendjemand an eine View weiterleitet

 

[Stroker89]

Also im Moment habe ich das so:

Frontcontroller:

protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException, InstantiationException, IllegalAccessException, ClassNotFoundException {
        String pathInfo = request.getPathInfo();
        PrintWriter out = response.getWriter();
        String view = null;
        if (pathInfo == null || "/".equals(pathInfo)) {
           response.sendError(HttpServletResponse.SC_BAD_REQUEST);
        }
        String servlet = pathInfo.substring(1);
        
        if(servlet.equals("register")){
            Class clazz = Class.forName("handlers.register");
            register r = (register) clazz.newInstance();
            view = r.processRequest(request, response);
        }
        
        RequestDispatcher dispatcher = getServletContext().getRequestDispatcher(view);
        dispatcher.forward(request, response);
        
        
    }

Wenn ich jetzt http://domain/projekt/controller/register aufruf, leitet der Controller die Anfrage an der register-Handler weiter. Der sieht so aus:

register.java (Servlet):

@WebServlet("/register")
public class register extends HttpServlet {
    private static final long serialVersionUID = 1L;
       
    @EJB user UserBean;
    @EJB MD5encrypt MD5Bean;
    
    public register() {
        super();
    }

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        processRequest(request, response);

    }

    
    protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        processRequest(request, response);
    }
    
    public String processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        String view = null;
        boolean userregister = false;
        String vorname = request.getParameter("jsname");
        String nachname = request.getParameter("jsusername");
        String email = request.getParameter("jsemail");
        String passwordclear = request.getParameter("jspassword");
        
        String password = MD5Bean.EncryptPassword(passwordclear);
 
        userregister = UserBean.createUser(vorname, nachname, password, email);
        
        if(userregister==true){
            view = "views/register2.jsp";
        }
        else{
            view = "error/registererr.jsp";
        }
        
        return view;
    }

}

Wie man sehen kann, werden hier noch zwei EJB benutzt.
Das komische ist jetzt, dass ich vom Server eine NullPointerException bekommen unzwar an dieser Stelle:

userregister = UserBean.createUser(vorname, nachname, password, email);

worauf ich zurück schliesse, dass der request leer ist. Aber warum? Ich übergebe ja den Request und Response an den Handler

Daten kommen übrigens aus einem Registrierungsformular.

Hat jemand eine Idee? Werd daraus irgendwie nicht ganz schlau

 

[SlaterB]

Klassen unbedingt groß schreiben, Variablen klein

und schau dir doch an, was an Parametern ankommt (Logging, Debugging?), die einzelnen Parameter + den Querystring an sich,
im Register sowie vorher im FrontController, durch den Methodenaufruf sollte es da keinen Unterschied geben

 

[Stroker89]

Ok alles klar danke für den Hinweis. Irgendwie war das Problem auch an den Namen dass die Beans null waren.

Aber nun hab ich eine ander nullpointerexception und zwar beim dispatch

dispatcher.forward(request, response);

 

[SlaterB]

view ist gesetzt, ist ein Wert wie "views/register2.jsp"?
funktioniert es von anderen Servlets aus, nur vom FrontController nicht?

wenn überall nicht, dann eine Frage der allgemeinen XML-Konfigurationen,
ansonsten vielleicht auch eine Konfigurationsfrage (ist eingeschränkt, von wo nach wo weitergeleitet werden darf)
oder sonst fällt mir nix ein

----
wozu eigentlich so kompliziert an anderer Stelle:

> Class clazz = Class.forName("handlers.register");
> register r = (register) clazz.newInstance();

wenn du die Klasse eh kennst, dann schreibe
Register r = new Register();

 

[Stroker89]

Ja view ist definitiv gesatzt egal ob die Action erfolgreich ist oder nicht.
In der web.xml ist nur das Mapping für den frontcontroller drin also /Controller/* so wie es sein soll.

Ja werde das noch ändern mit der instanzierung

 

[SlaterB]

die wichtigste Frage ist noch, ob der Forward je funktioniert hat mit 'normalen' Servlets?
wenn nicht oder nie getestet, dann ist es weiter ein Problem, hat aber dann möglicherweise nichts mit der Umstellung auf FrontController zu tun,

wie sind dann die Verzeichnisse aufgebaut usw.?, wobei ich da nichts konkretes sagen kann,
anfangs nach einem Tutorial richten bis der erste dispachter-view-forward klappt

 

[Stroker89]

Nein der forward hat noch nicht funktioniert, da ich ein bestehendes Projekt gerade Umbau bzw. neu gestalte. Ich habe jetzt einfach mal mit dem ersten Servlet angefangen. Dem register. Aber irgendwie will das alles nicht

 

[Stroker89]

Habs hinbekommen *freu*

 

[Stroker89]

Für diejenigen die es interessiert

Das Problem lag daran, dass die Annotions nicht in einem Servlet funktionieren, dass von einem anderen Servlet instanziert wird? Warum auch immer...

Ich benutze in den Handlern EJBs als Helper und die waren immer null hab das so gelöst, dass ich die EJBs und EntityManager schon im Frontcontroller injecte und dann die die gebraucht werden mit an den aufzurufenden Handler übergeb

Vielen Dank an alle für eure Hilfe

Gruß Martin

 

[mvitz]

Wollte das eigentlich auch gesagt haben, habe aber dann irgendwie gedacht die NullPointer kämen wo anders her.

Das die @EJB nicht injeziert werden liegt halt daran, dass deine Servlets (bzw. die Klassen müssen ja keine Servlets mehr sein) nun nicht mehr vom Webcontainer verwaltet werden, sondern von dir --> du musst dich um das injecten kümmern.

 

[Stroker89]

Danke für den Hinweis ich bin recht neu in J2EE und weiß solche Gegebenheiten leider noch nicht

Gruß Martin

 

[ruutaiokwu]

das thema ist zwar schon alt, aber ich möchte trotzdem noch meinen "senf" dazugeben:

wir haben mal eine konstruktion gemacht, welche ingesamt 3 webapplkationen beinhaltet, jedoch nur aus einem servlet besteht:

1. eine klasse ServletDispatcher (extends HttpServlet) erstellen

2. bei 3 webapps 3 klassen erstellen, diesen im konstruktor die HttpServletResponse sowie den HttpServletRequest übergeben, und diese anschliessend als member zur verfügung stellen & in diesen klassen eine funktion void processRequest().
(oo-puristen machen selbstverständlich noch ein interface oder eine abstr klasse dazu!)

3. in der web.xml die 3 url's zum ServletDispatcher mappen...

4. im ServletDispatcher in der service-funktion die url auflösen, und je nach url resp. fall eine andere der unter punkt 2 beschriebenen klassen instanzieren (konstruktor unter punkt 2 beschr.) und die processRequest funktion aufrufen.

5. in der processRequest-funktion kann man dann schlussendlich an das jsp oder xhtml-facelet (jsf 2.0), oder was auch immer für die view, per requestdispatching forwarden. oder aber den outputstream abfangen in einen string umwandeln und diesen per HttpServletResponse.getWriter().println(generated_html_client_code) an "ort und stelle" ausgeben... in diesem fall müsste man aber ein include, anstatt eines forwards, verwenden...



wenn ich ehlich sein darf: frameworks sind was für weicheier, zumindest mvc-frameworks. jsf z.b. verwende ich NICHT als komplettes mvc-framework, sondern nur wie oben beschreiben, per facelet 2.0 (also für den viel-teil von mvc: xhtml ist geil!!!) und einem normalen HttpServlet... des weiteren unterstützt java "von haus aus" zumindest view (-> jsp) und controller (-> serlvet) und irgendwelche beans (-> model) für irgendwelche daten (z.b. ContactFormBean mit kontaktformularfelder- settern & -gettern), welche man im controller (servlet) per HttpServletRequest.getParameter(...) holt und was auch immer damit anfängt...

das ganze ist doch relativ trivial... sehe nicht im geringsten ein, wozu man dafür ein framework mit 27 jar's in der grösse von 50 mb benötigt? ;-)


anders sehe ich die sache client-seitig, javascript & ajax und so... aber eher wegen browser-kompatiblitätsproblemen...


grüsse, jan

 

[ruutaiokwu]

noch den grund für diese konstruktion: alle 3 webapps mussten sich eine session teilen, so dass man sich nicht bei jeder webapp einzeln einloggen musste...

 

[maki]

enn ich ehlich sein darf: frameworks sind was für weicheier,

jmar, mal ganz ehrlich: Für jemanden der nicht mal weiss wie man einen Iterator richtig verwendet, machst du den mund ganz schön weit auf.

Und jetzt mal ganz böse: Den Pfusch, den du hier oft als "Lösung" postest, den würde ich an deiner Stelle ganz tief im Garten vergraben, aber keinesfalls als "Lösung" verkaufen und dafür Geld nehmen.

So, musste mal gesagt werden...

 

[ruutaiokwu]

na ja, diesen Iterator brauche ich auch höööchst selten, da ich

a.) relativ selten über maps iteriere, es sei denn diese befinden sich in einem sortierten zustand oder sind LinkedHashMap's...

b.) für java.util.List implementierende klassen normalerweise das verwende:

for(int cnt = 0; cnt < list.size(); cnt++)
{

}

und NICHT:

while(listIterator.hasNext())
{
Object element = listIterator.next(); // ohne das gibt's nen absturz... das ist doch doof!?
}


die entwicker verdummen mit solchen sachen:

while(listIterator.hasNext())

und manche möchtegerne-programmierer/framework-einsetzer/selbsternannte oo-spezialisten sind dann total überfordert mit dem hier:

for(int cnt = 0; cnt < list.size(); cnt++)

...und können das kaum nachvollziehen... traurig aber wahr...

glücklicherweise haben mir perl-, c/c++-, (x)basic- und assembler-entwickler die logik von programmiersprachen beigebracht! (und nicht irgendwelche "java enterprise application senior architects" blablabla wie auch immer töntsupergut-titel-träger, die nicht mal wissen wie ein bubblesort funktioniert, geschweige denn jemals einen verschlüsselungs-algorithmus implementiert haben, oder nicht wissen, dass sich eine (eigentlich) rekursive funktion mithilfe von stacks nicht-rekursiv realisieren lässt)

und: es gibt noch viele sachen, wo ich gegen den strom schwimme, z.b. stringvergleich per String.intern(), das macht NIEMAND ausser mir. auch bei collections könnte man es meist auch lassen, die instanz zu typisieren...

also

List<String> str = new ArrayList();


alles immer "standard" zu machen, ist definitiv nicht die lösung...

und dass man eine datenstruktur nicht verändern darf, während man eine iteration über diese macht, finde ich aus rein algorithmischer sichtweise VÖLLIG SCHWACHSINNIG... HALLO???


hier:

    private List<String> list;

    @SuppressWarnings("unchecked")
    private void prepare()
    {
        list = new ArrayList();

        for (int cnt = 0; cnt < 10; cnt++)
        {
            list.add("" + cnt);
        }
    }

// kein problem hier...
public void test1()
    {
        prepare();

        for (int cnt = 0; cnt < list.size(); cnt++)
        {
            String element = list.get(cnt);

            if ((cnt + 1) % 5 == 0)
            {
                System.out.println("now");
                list.add(cnt, element.toLowerCase());
            }
        }
    }

    public void test2()
    {
        prepare();

        Iterator<String> i = list.iterator();

        int cnt = 0;
        try
        {
            while (i.hasNext())
            {
                String element = i.next();

                if ((cnt + 1) % 5 == 0)
                {

                    list.add(cnt, element.toLowerCase());

                }

                cnt++;

            }
        }
        catch (ConcurrentModificationException e)
        {
            System.out.println("");
        }
    }

(der output von test2 wendet sich nicht an dich ;-))

solche sachen nerven mich. für mich schlicht degenerierter auswuchs... bei maps kommt man ja nicht um den iterator herum (korrigere mich, wennn ich falsch liege) - klarer fall. bei listen diesen zu verwenden, das ist (aus meiner sicht) definitiv was für weicheier und dabei passieren so sachen wie bei test2... und wenn man nur lesen will: wennschon die variante mit dem doppelpunkt, "enhanced for loop".

und begründe mir bitte, sachlich-rational, was an unserer (meine team & ich) servlet-lösung so falsch ist..?

gruss, jan

 

[maki]

(der output von test2 wendet sich nicht an dich )

Solltest die Verwarnung ernst nehmen.

"Weicheier" ist ein bei dir wohl ein Begriff für alle, die dir überlegen sind?

das macht NIEMAND ausser mir

Das ist bestimmt sehr oft der Fall.

Ansonsten: Wenn du einfach mal die Doku lesen würdest, bräuchtest du diese Fragen nicht mehr stellen (und sicherlich nicht solche schrägen Konstrukte programmieren), ist alles definiert & erklärt (Konsistenz, "fail fast", etc. pp.), den Link zum Colletions Tutorial hab ich dir bereits geschickt, aber da du ja keine Zeit zum lesen hast, nehme ich mir nicht mehr die Zeit dir solche einfachen und grundlegenden Sachverhalte zu erklären, scheint ja sowieso nicht auf fruchtbaren Boden zu fallen.

 

[Stroker89]

@jmar83

Der Grund warum ich einen eigenen FrontController implementieren wollte und habe, hing damit zusammen, dass er Teil eines Studienprojekts von mir war. Ich wollte nicht einfach nur blind irgend ein Framework benutzen, ohne wirklich zu verstehen wie es funktioniert und arbeitet. Im Nachhinein kann ich wirklich behaupten, aus dieser Sache wirklich viel gelernt zu haben, da es mein erstes JEE Projekt war.

Der Grund warum Frameworks benutzt werden ist, dass man sich eben nicht mehr um solche grundlegenden Funktiunalitäten als Entwickler auseinander setzen muss. Das ist ja auch Sinn und Zweck von der Geschichte. Ich musste wirklich viel Zeit in den FrontController investieren, da es für mich komplettes Neuland war.

Wenn du so programmierst wie es niemand anderes tut, sagt es mir nur eins: Du bist nicht Teamfähig, dein Code ist schwer, wenn überhaupt wartbar und du wirst mit dieser Haltung in keinem Unternehmen Fuß fassen.

Wenn du natürlich "nur" hobbymäßig ein bisschen codest, dann kannst du das halten wie ein Dachdecker, aber gleichzeitig kannst du nicht deine Art zu programmieren, als den Weg schlechthin darstellen. Das finde ich einfach nur anmaßend. In diesem Forum gibt wirklich sehr fähige Leute, die immer super Tipps geben und mir schon sehr viel geholfen haben.
Wenn mir jemand einen Tipp gibt mit dem ich leichter zum Ziel komme, dann nehme ich diesen dankbar an und bin froh, dass es einen leichteren Weg gibt, als den den ich mir zuerst überlegt habe.

Hoffe du verstehst meinen Haltung.

Auf jeden Fall bin ich froh dass es noch so ein Forum wie das hier gibt, da solche Leute wie hier eher die Seltenheit geworden sind. Die die mir schon geholfen haben, dürfen sich gerne angesprochen fühlen

Danke

 

[Gast2]

und: es gibt noch viele sachen, wo ich gegen den strom schwimme, z.b. stringvergleich per String.intern(), das macht NIEMAND ausser mir. auch bei collections könnte man es meist auch lassen, die instanz zu typisieren...

also

List<String> str = new ArrayList();


alles immer "standard" zu machen, ist definitiv nicht die lösung...

und dass man eine datenstruktur nicht verändern darf, während man eine iteration über diese macht, finde ich aus rein algorithmischer sichtweise VÖLLIG SCHWACHSINNIG... HALLO???

Hä? Was erzählst du für ein wirres Zeug? Nur weil du es so machst heißt es noch lange nicht das es gut ist? Bei Collections den Rawtype zu nutzen ist definitiv nicht die bessere Wahl. Stringvergleiche mit String.intern()? Schön und gut, aber außer dem Fakt das du dich damit als Exot in der Programmierwelt positionierst sehe ich da keine Vorteile und spätere Maintainer werden ihre Freude haben.

solche sachen nerven mich. für mich schlicht degenerierter auswuchs... bei maps kommt man ja nicht um den iterator herum (korrigere mich, wennn ich falsch liege) - klarer fall. bei listen diesen zu verwenden, das ist (aus meiner sicht) definitiv was für weicheier und dabei passieren so sachen wie bei test2... und wenn man nur lesen will: wennschon die variante mit dem doppelpunkt, "enhanced for loop".

und begründe mir bitte, sachlich-rational, was an unserer (meine team & ich) servlet-lösung so falsch ist..?

Sachlich rational? Damit hast du ja schon direkt gebrochen (Weicheier, degenerierter Auswuchs, ...). Es gibt durchaus Gründe bei Listen mit einem Iterator zu arbeiten. Zum Beispiel um in der Liste änderungen beim durchlaufen über den Iterator vorzunehmen. Siehe meine erste Quote von deinem vorherigen Kommentar und überleg noch mal worauf sich das bezieht...

Du und ein Team könnt euch freuen das eure "Lösung" funktioniert. Eine saubere JEE Architektur sieht allerdings anders aus. Es gibt Standards und Best Practices nicht umsonst, aber das mit dir zu diskutieren würde wohl den Rahmen dieses Topics sprengen.

 

[ruutaiokwu]

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...

 

[Stroker89]

Und die Servlet Spezifikation ist kein Teil von JEE?

 

[maki]

Und die Servlet Spezifikation ist kein Teil von JEE?

Ja, ist sie, schon immer gewesen.

Es gibt aber offensichtlich mindestens ein sehr verwirrtes Team das gar nicht weiss was es da eigentlich macht *g*

 

[ruutaiokwu]

hallo fassy,

"Bei Collections den Rawtype zu nutzen ist definitiv nicht die bessere Wahl."

auf jeden fall kann ich damit das downcasting zur "konkreten" klasse verhindern... das reicht mir. genau das brauche ich auch in diesem fall, nicht mehr, nicht weniger.

google collections api (ist zwar was anderes...) macht das auch nicht.

String.intern() ist für mich das sauberste & logischste. aber auch das ist natürlich ansichtssache...

"Fakt das du dich damit als Exot in der Programmierwelt positionierst"

ja, einige sind da nicht immer so begeistert... andererseits bekomme ich manchmal komplimente in der art "du weisst aber viel"... na ja...

"Sachlich rational? Damit hast du ja schon direkt gebrochen (Weicheier, degenerierter Auswuchs, ...)."

ja, da hast du auch wieder recht, versuche aber so gut es geht zu begründen. (nicht wie viele andere: das macht man halt einfach so und punkt...)

"Zum Beispiel um in der Liste änderungen beim durchlaufen über den Iterator vorzunehmen."

na ja, das schaffe ich mit einer listen-iteration im c/c++-stiel (also for-schleife, wie bei der antwort auf maki's beitrag...)

aber wer unbedingt den iterator verwenden will, der soll... finde den anderen weg "algorithmisch" offensichtlicher, oder wie man dem sagen soll...?


"Eine saubere JEE Architektur sieht allerdings anders aus."

wie schon bei vorherigen beitrag java-webapps != j(2)ee

zum glück brauchen wie keine "fette" jee-archtektur, sondern machen "schlanke" webanwendungen, nur mit tomcat. dynamisch html ausgeben und requests entgegennehmen und verarbeiten. das ist alles, was wir brauchen...

 

[ruutaiokwu]

Stroker89,

habe deinen beitrag nicht gesehen, habe inzwischen geschrieben... ;-)

dann erklärt mir doch bitte (auch maki!) warum ein tomcat NICHT als j2ee-application-server bezeichnet wird?

dann würde ich sagen, wir machen keine "richtigen" j2ee-anwendungen...?


grüsse, jan

 

[ruutaiokwu]

@maki:

"Es gibt aber offensichtlich mindestens ein sehr verwirrtes Team das gar nicht weiss was es da eigentlich macht *g*"

scheinbar produktiveres als du mit deinen kommentaren...?

 

[maki]

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

Das war wiedermal vollkommen falsch, so wie einiges was du von dir gibst.

mehr weiss ich auch nicht. schliesslich verwenden wir KEIN jee/j2ee (wie es auch immer heisst!),

Naja, zumindest im ersten Satz hasst du damit fast ein bisschen Recht, der letzte ist mal wieder... s.o.

Servlets sind Teil von Java EE, aber zu Java EE gehört auch noch mehr, zB. wie JNDI auch, und JAAS, EJBs, etc. pp.

Für einen vollwertigen Java EE Server braucht man aber mehr als nur ein 2 Implementierungen der Java EE Speks (Tomcat hat aber noch mehr implementiert, aber eben nicht alle notwendigen), da gibt es auch Mindestanfonderungen.

Tomcat war früher (vor Glassfish) die Referenzimplementierung der Servlet Spek. (und damit eines ServletContainers), diese ist eben nur ein Teil von Java EE.

Wie dem auch sei, ich denke, die ganze Diskussion bringt niemandem mehr wirklich etwas, denn du jmar, wärst schon längst in der Lage gewesen mehr Zeit zu haben, die du für lesen hättest nutzen können, wenn du die Zeit nicht darin investiert hättest, inhaltlich falsche Beiträge zu verfassen.

 

[ruutaiokwu]

hallo maki,

ok, dann wäre das auch geklärt, habe die sache mit tomcat!=jee vom "hörensagen"... (vorher hatte ich das auch so im kopf, tomcat=jee, wurde aber scheinbar im nachhinein "falsch" belehrt...)

aber bekanntlich sollte man grundsätzlich nicht alles glauben, wenn man sich nicht selbst vergewissert hat...