Ignoralo .... HttpServlet è Serializable e il serialVersionUID serve per il "versionamento" delle classi serializzabili. La Servlet che ho postato l'ho generata da wizard di Eclipse e serialVersionUID l'ha messo in automatico. Senza questo serialVersionUID, Eclipse tra l'altro si lamenterebbe con un warning.Originariamente inviata da giannino1995
Anzi .... invece di ignorarlo, dovresti farti un minimo di "cultura" sulla serializzazione degli oggetti. Non è che serve tutti i giorni, ma se la conosci hai sicuramente qualcosa in più ....
Non hai ancora compreso come funziona tutto il ciclo della request/response, allora.
<c:url> serve in generale per "riscrivere" un URL. Il termine riscrivere indica la capacità di manipolare un URL aggiungendo/cambiando certe parti. E per <c:url> la capacità principale è il fatto di poter aggiungere al URL il Session ID (ovviamente solo SE necessario). E inoltre siccome "sa" del ServletContext è in grado di generare un url a partire dalla "server" root.
In:
<c:url value='/potenze-di-due'/>
il '/' indicato in rosso è relativo alla "context" root, perché <c:url> "sa" appunto del contesto della applicazione. L'URL generato è qualcosa tipo:
/nomecontesto/potenze-di-due
oppure se serve il session ID, qualcosa del tipo:
/nomecontesto/potenze-di-due;jsessionid=1C35DDFC4E4B951968AE807A70C8AC52
Dove nomecontesto è chiaramente il nome del contesto della applicazione. Il vantaggio di <c:url> (ignorando per un attimo la capacità di aggiungere il session ID) è almeno il fatto che è in grado di risolvere l'URL aggiungendo in automatico il nome del contesto.
Qui però come vedi non c'è nulla relativo a WEB-INF/views. Perché questo è un aspetto interno alla webapp. Tutto cio che c'è sotto WEB-INF è totalmente nascosto al client. Le specifiche Servlet dicono chiaramente che il servlet container non deve "esporre" tramite HTTP alcunché di quello sotto WEB-INF. Solo la webapp può accederci.
Quindi quando si invia il form, la action fa innanzitutto eseguire la servlet PotenzeDiDueServlet. Poi la servlet ad un certo punto fa un "forward" a "/WEB-INF/views/potenze-di-due.jsp". Il ciclo di request/response non termina quindi con la servlet ma viene semplicemente "passata la palla" ad un'altra risorsa interna della webapp che è appunto la pagina potenze-di-due.jsp.
Non ha importanza (fintanto che è corretto dal punto di vista di sintassi/struttura). Io ho postato solo dichiarazione/mapping della servlet, non il resto.
Fino alle specifiche Servlet 2.3 i tag figli di primo livello dentro <web-app> (es. <servlet>, <servlet-mapping>, ecc...) dovevano essere in un ordine ben preciso, perché il web.xml era validato tramite un DTD che imponeva una struttura abbastanza rigida. A partire dalle specifiche 2.4 la validazione è fatta con uno schema XSD che ha "allentato" un pochino le restrizioni, percui è possibile mettere <welcome-file-list> prima o dopo <servlet>, <servlet-mapping> prima o dopo <servlet>, ecc....
E tutto quello che ho segnato in rosso (giusto alcuni) cosa sono? Secondo te come faccio io a sapere cosa è MaxWD.java ???
Che cosa stavi cercando di fare? Hai scaricato e/o creato altro? Come faccio a capire così su 2 piedi cosa hai fatto?
Ascolta, crea un nuovo Dynamic Web Project seguendo quanto avevo detto qui e aggiungi i pezzi per il mio esempio delle potenze di due.ho anche provato ad aggiungere views al codice ma nulla...
P.S.: Come faccio su Eclipse ad andare a modificare quel valore di tomcat (2.4 o 2.5) di cui parlavamo in precedenza?
Non puoi sbagliare .....
Rispondi quotando