Domanda

home.jsp

<jsp:useBean id="username" class="java.lang.String" scope="application"/>

<%
      username="Jitendra";
%>

<jsp:include page="include.jsp"/>

include.jsp

<%=username%>

Questo dà un errore che dice che "nome utente" non è definito in include.jsp, anche se l'ambito di Bean è l'applicazione ...

È stato utile?

Soluzione

Per quanto riguarda il tuo problema, tutto ciò che dichiari a livello locale usando le vecchie sceneggiature è non collegato con a jsp:useBean. Inoltre, dichiarare una variabile di scriptlet locale è non Visibile nelle pagine incluse, è necessario inserirle esplicitamente almeno nell'ambito della richiesta. Come usare gli scriptlet è un cattiva pratica. Consiglio di dimenticarlo affatto.

Nel tuo caso specifico, basta creare un file vero java bean per tenere i dati. Cioè, una classe con un costruttore predefinito (implicito) e proprietà private che sono esposte da getter/set pubblici. Ecco un esempio di base:

public class User {

    private String name;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

}

Quindi è possibile utilizzare una classe servlet per preelaborare le richieste. Puoi usare Servlet's doGet() metodo per questo.

protected void doGet(HttpServletRequest request, HttpServletResponse response) {
    User user = new User();
    user.setName("Jitendra");
    request.setAttribute("user", user); // Store in request scope.
    request.getRequestDispatcher("/WEB-INF/show.jsp").forward(request, response);
}

Mappa questo servlet web.xml su un url-pattern di ad esempio /show. Questo servlet dovrebbe quindi essere accessibile da http://example.com/context/show e il suo doGet() verrebbe eseguito immediatamente.

Quindi modificare/creare il file JSP show.jsp in cui metti /WEB-INF per impedire l'accesso diretto (in modo che i clienti non possano accedervi http://example.com/context/show.jsp ma sono "forzati" a chiamare il servlet) con la seguente riga:

<p>User name: ${user.name}</p>

Il ${user} si riferisce all'oggetto associato a qualsiasi chiave di richiesta/sessione/applicazione user. Questo fa dietro le quinte jspContext.findAttribute("user"). Come restituito User l'istanza è conforme alle specifiche Javabean, il ${user.name} invocherà il getName() metodo sul User L'istanza e l'EL mostreranno il suo risultato.

Oh, dovrei aggiungere, lo fai non bisogno jsp:useBean Per questo poiché il servlet ha già creato e messo il fagiolo desiderato nell'ambito.

Detto questo, consiglio di iniziare con un tutorial/libro di servlet decente. Esempi:

Spero che sia di aiuto.

Altri suggerimenti

Il tuo codice è "malvagio" perché a java.lang.String non è proprio un fagiolo. Significativamente, non ha un metodo "set" per cambiare il suo testo (è intenzionale, è pensato per essere immutabile).

Il modo in cui accedi ai fagioli è dichiararne uno, quindi utilizzare le sue proprietà (cioè i nomi dietro i metodi get () e set ()) per cambiarlo. Non è possibile modificare direttamente l'istanza effettiva del fagiolo, solo i suoi valori.

Su tomcat 6, home.jsp è tradotto nel codice servlet:

java.lang.String username = null;
synchronized (application) {
  username = (java.lang.String) _jspx_page_context.getAttribute("username", 
                                                  PageContext.APPLICATION_SCOPE);
  if (username == null){
    username = new java.lang.String();
    _jspx_page_context.setAttribute("username", username,
                                                  PageContext.APPLICATION_SCOPE);
  }
}

username="Jitendra"; 

org.apache.jasper.runtime.JspRuntimeLibrary.include(request, response, 
                                                 "include.jsp", out, false);

Sebbene il comportamento sia lo stesso, il codice esatto generato dipende dall'implementazione del server delle applicazioni.

La portata del locale username La variabile non si estende nel servlet che verrà generato include.jsp. Non si sta impostando il valore "Jitendra" nell'ambito dell'applicazione, impostando solo il valore della variabile locale.

Come altri hanno sottolineato, una corda immutabile non è un fagiolo molto buono.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top