How many attributes can a servlet have?

[Alan Smith]

Hi,

does anybody know how many attributes a servlet can have? I am asking because I have a simple html input form that takes name, job, salary, description (few lines of text) and a county. When I set them as attributes I can only read two of them on the processing page.

HTML form:

 <form name="add" action="addUser" method="POST">
        Name: <input type="text" name="name" value="" size="20" />
        Job: <input type="text" name="age" value="" size="10" />
        Salary: <input type="text" name="age" value="" size="10" />
        Description: <textarea name="description" rows="4" cols="20">
        </textarea>
        <select name="counties">
            <option>Carlow</option>
            <option>Cavan</option>
            <option>Clare</option>
            <option>Cork</option>
            <option>Donegal</option>
            <option>Dublin</option>
            <option>Galway</option>
            <option>Kerry</option>
            <option>Kildare</option>
            <option>Kilkenny</option>
            <option>Laois</option>
            <option>Leitrim</option>
            <option>Limerick</option>
            <option>Longford</option>
            <option>Louth</option>
            <option>Mayo</option>
            <option>Meath</option>
            <option>Monaghan</option>
            <option>Offaly</option>
            <option>Roscommon</option>
            <option>Sligo</option>
            <option>Tipperary</option>
            <option>Waterford</option>
            <option>Westmeath</option>
            <option>Wexford</option>
            <option>Wicklow</option>
        </select>
        <input type="submit" value="Submit" name="submit" />
    </form>

Servlet doPost method:

 @Override
    protected void doPost(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {

        String userPath = request.getServletPath();

        if (userPath.equals("/addUser")) {
            String name = request.getParameter("name");
            String job = request.getParameter("job");
            String salary = request.getParameter("salary");
            String description = request.getParameter("age");
            String county = request.getParameter("county");

            request.setAttribute("name", name);
            request.setAttribute("job", job);
            request.setAttribute("salary", salary);
            request.setAttribute("description", description);
            request.setAttribute("county", county);
        }

        String url = "/WEB-INF/view" + userPath + ".jsp";

        try {
            request.getRequestDispatcher(url).forward(request, response);
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }

JSP that reads attributes:

<p>${name}

        ${job}

        ${salary}

        ${description}

        ${county}</p>

Only name and job are reading on the output. Any help would be appreciated. Also, does anyone know how to read the index of the dropdown box as opposed to its content. I want to read the county into a database table as an integer id.

Thanks

[Matthew Brown]

I think you just need to be more careful with your markup. For your Salary input, you've given in the name "age" - so "salary" doesn't exist in the form. And your markup has "counties" whereas you're trying to extract "county".

For the last part, you need to put a value into the <option> tag: <option value="1">Carlow</option>.

[Alan Smith]

Matthew Brown wrote:I think you just need to be more careful with your markup. For your Salary input, you've given in the name "age" - so "salary" doesn't exist in the form. And your markup has "counties" whereas you're trying to extract "county".

For the last part, you need to put a value into the <option> tag: <option value="1">Carlow</option>.

Whoops, how embarressing! Thanks for pointing that out, its always the little things. And thanks for the tip on the option tag. If I put in the option value though how do I set it to an attribute? The getParameter method only takes a Stringas far as I can tell. Sorry I am quite new to web programming.

Thanks.

[Tim Holloway]

Request attributes are a Map object and its maximum size is limited only by available memory. An HTTP GET can sometimes be too large, due to server limitations on total text length, but an HTTP POST is effectively unlimited as far as the number of attributes (parameters) that it supports.

HTTP is a 100% text protocol, which is why getParameter and its friends only return String objects. And, in case you're wondering how binary objects such as GIF images can be sent over a text-only protocol, they're encoded as text by the server and decoded from text to binary by the client. The technique was originally designed for email (which is also text-only), and is known as MIME (Multipurpose Internet Mail Extensions).

[Alan Smith]

Tim Holloway wrote:Request attributes are a Map object and its maximum size is limited only by available memory. An HTTP GET can sometimes be too large, due to server limitations on total text length, but an HTTP POST is effectively unlimited as far as the number of attributes (parameters) that it supports.

HTTP is a 100% text protocol, which is why getParameter and its friends only return String objects. And, in case you're wondering how binary objects such as GIF images can be sent over a text-only protocol, they're encoded as text by the server and decoded from text to binary by the client. The technique was originally designed for email (which is also text-only), and is known as MIME (Multipurpose Internet Mail Extensions).

Hi,

thanks for the reply. The getParameter method returns the option value if it is present and the option tags inner text if not. This solved my problem. I can now parse the String with the number to an integer and pass it into an object as an id.

[Bear Bibeault]

Your terminology is off. The data values passed in the HTTP request are parameters, not "attributes". As scoped variables a are often called "attributes", this is an important distinction.

[Alan Smith]

Bear Bibeault wrote:Your terminology is off. The data values passed in the HTTP request are parameters, not "attributes". As scoped variables a are often called "attributes", this is an important distinction.

So when you assign a request parameter to a request attribute that attribute becomes available to whatever page you forward to using the RequestDispatcher? Can you forward back to the same page that contained the form that made the request? As in, click submit and then have the sent parameters appear under the form as request attributes.

Thanks

[Tim Holloway]

Well, this is interesting. I had to go back and RTFM.

ServletRequests support 2 different maps: parameters (from the URL or POST data) and attributes. I'm so used to the other scopes using "attribute" that I was thinking that they were synonymous.

Parameters should be considered as read-only. Some J2EE servers will throw exceptions if you attempt to alter them or add parameters of your own in application code.

The way I read it, ServletRequest attributes, on the other hand, are writable, and - to a limited extent - forwardable. Although I'd have to study more before I would accept it as advisable to employ them in application code. This is an area where I haven't done much playing around for quite a few years now.

[Pete Nelson]

Tim Holloway wrote:HTTP is a 100% text protocol, which is why getParameter and its friends only return String objects. And, in case you're wondering how binary objects such as GIF images can be sent over a text-only protocol, they're encoded as text by the server and decoded from text to binary by the client. The technique was originally designed for email (which is also text-only), and is known as MIME (Multipurpose Internet Mail Extensions).

I am not sure how accurate this is ... MIME is not about encoding binary to text, but separating different chunks of content. In the old days, when you needed to send an image through a text-only e-mail system, you had to uuencode the image to turn it into ASCII (and then uudecode it to view it). With MIME, we can include binary data & ASCII data in the same message (but different chunks). No encoding/decoding required.

HTTP transport makes no distinction between text & binary. It simply sends the bytes it finds, regardless if those bytes come from a text file or an image (or your servlet).

[Tim Holloway]

It goes roughly like this.

Before the email protocols we know and love today, the primary way of getting chunks of data between servers in store-and-forward form in the nascent Internet was by uucopying them. However, not all of the computers on the original ARPAnet were ASCII-based. Many of them were IBM mainframes, almost all of which worked in EBCDIC. Some of them were even stranger, with things like 56-bit words. As long as things were kept in text form, handling them was fairly easy - a straight character-for-character translation table would work as long as everyone stuck to the basic characters.

Transferring binary information threw a monkey wrench into this process. As I noted earlier, word lengths could vary considerably. So did byte ordering - where bytes even applied at all. System A might be ASCII, relayed through EBCDIC systems B and C to end up at ASCII system D. Worse yet, a lot of systems used the 8th bit of a byte as a parity bit, and not always in the same way. System A might be using a Motorola-style CPU and System D might be a VAX, which has a differing "endian" scheme. So to avoid having the data get chopped up in transport, the UUENCODE scheme of encoding/decoding was developed. Using uuencode, any binary data stream could be converted to 7-bit text (ignoring the parity bit), which could then be routed as text and decoded back to binary.

MIME took this step one stage further by supporting segmenting of the data stream, thus allowing email with attachments, including binary attachments. It does this by flagging the (text) datastream as being MIME-encoded and using special text lines as delimiters for the attachments.

MIME email is ALWAYS 100% text, even the binary parts. That's mandated by RFC821, which defines how SMTP works. It's not only text, it's 7-bit text. In HTTP, the headers are always text, but the body has some leeway these days.

The term "MIME type" in relation to HTTP has to do with the fact that email and web clients share certain resources, so regardless of whether a PDF comes in via email or the web, the same viewer program can be mapped to it without having 2 maintain 2 distinct content-type/application mapping databases.

[Hussein Baghdadi]

Thank you Tim for the journey.