Что такое сервлет: Что такое сервлет и зачем нужен портлет? / Хабр

WEB: что такое Servlet ?

Интернет-приложения на JAVA

Когда начинающий программист (я тоже им был и испытывал подобные ощущения) первый раз сталкивается с программированием для Интернет, то количество информации, которое на него обрушивается настолько огромно, что может просто напугать. Странные сочетания TCP/IP, IP-адрес, HTTP, HTML, XML, WEB, JSP, SNMP, SMPP, ICMP, UDP, servlet, proxy, порт, DNS (и это только малая часть всего) могут любого заставить как минимум задуматься: «А смогу ли я это осилить ?». Смело заверяю вас — сможете 🙂
Я постараюсь провести вас через бОльшую часть моментов, которые вам потребуются для того, чтобы научиться программировать Интернет-приложения на Java. Конечно эта информация будет не полной и много информации вам придется искать самим, но небольшую тропинку через цикл создания такого рода программ мы пройдем.

Сетевые протоколы

Если вы уже знакомы с основными принципами работы Web-сервера, то возможно, что эта часть вам будет не очень интересна. Но все-таки мне бы хотелось остановиться на некоторых моментах, которые я считаю важными для понимания того, как писать Web-приложения на Java. В принципе кто-то может сказать — да и это в общем-то не особо важно, но тем не менее хотелось бы упомянуть. В конце концов это же моя статья, а не ваша 🙂
Итак, первое с чего мы начнем — это протоколы TCP/IP и HTTP. Для глубокого понимания TCP/IP вам надо прочитать немало книг. Но мне будет достаточно, если вы будете это воспринимать не так глубоко, а именно понимать две основные вещи:

1. IP адрес
2. порт

Рекомендуем: существует очень неплохой ресурс, на котором Вы можете найти немало статей по TCP/IP — Семейство протоколов TCP/IP. Также очень неплохая статья для тех, кто не знает ничего о протоколе — Руководство по TCP/IP для начинающих

Если рассматривать эти понятия очень коротко, то IP адрес — это число, которое говорит о том, какой адрес в сети у вашей машины. На сегодня наиболее распространенным адресом является 4-х байтное число — протокол версии 4 (v4). Для удобства его записывают в виде четырех чисел через точку. Например: 96.34.23.11
Т.к. машин в сети становится все больше, то сейчас уже вводится протокол версии 6 (v6). Для него на адрес отводится гораздо больше чисел и превысить это предел уже практически невозможно. Когда-то давно никто не думал, что машин будет столько и поэтому казалось, что 4 байта — это вполне достаточно. Ошиблись.
IP (Internet Protocol) — это специальный протокол, который описывает как пакеты передаются от одной машины в сети к другой. Причем отметим, что передача пакетов в данном протоколе не гарантируется. Могут доставить, а могут и не доставить.
Гарантированной доставкой занимается протокол TCP. Если сравнить IP и TCP с почтовой службой, то IP — это обычная почта, а TCP — это заказные письма с уведомлением о вручении, которые доставят обязательно и вы об этом узнаете. Кроме того, что TCP дает гарантии доставки, этот протокол также занимается тем, что доставляет пакет определенному приложению. Вы же можете запустить несколько приложений для работы с сетью — как они будут понимать, кому какой пакет пришел ? Делается это с помощью дополнительного расширения — порта. Порт — это число от 0 до 2^16. Чаще всего на компьютере какие-то порты уже заняты системными приложениями. Считается, что занимать порт ниже 1000 своим нестандартным приложением — плохой тон. Для работы с Web наиболее популярным портом является порт 80. Хоть он и меньше 1000, но Web все-таки очень важный момент и для него это можно.
Таким образом когда приложение хочет «выйти в сеть», оно запускается и просит у операционной системы занять определенный порт. Если порт свободен — приложение получает его в свое пользование и все пакеты, которые в будущем придут на данную машину на этот порт будут переданы именно этому приложению.

Что еще важно отметить в TCP — это его направленность на соединение. Т.е. пытаясь связаться с другим компьютером в сети (а точнее с приложением находящимся на другом компьютере) TCP сначала убедится, что приложение отвечает и после этого сообщит, что соединение установлено и можно посылать пакеты. В какой-то степени TCP это даже не заказная почта, а телефонный звонок. Раз трубку не подняли — значит ничего посылать нельзя. Если подняли — значит все в порядке, можно говорить, обмениваться информацией. Т.е. TCP использует для соединения IP адрес машины и порт, который используется определенным приложением на данном компьютере.

Таким образом легко сделать вывод — Web-сервер является специальной программой, которая запускается на компьютере и занимает определенный порт. Как уже упоминалось выше наиболее популярный порт — 80.

HTTP — кто это ?

И теперь несколько слов о HTTP. HTTP — это Hyper Text Transfer Protocol — протокол передачи гипертекста. По большому счету передается не какой-то загадочный гипертекст, а самый обычный текст, но раз уж назвали так, значит так тому и быть. Гипертекстом он становиться тогда, когда его показвает браузер. Именно браузер в соответствии с тэгами (мы о них поговорим чуть позже) форматирует текст, делает ссылки (именно это делает текст гипертекстом), показывает рисунки и т.д.
Когда приложение создает TCP/IP соединение с другим приложением (на другом компьютере или на вашем же), то это можно представить себе как некая труба, по которой теперь в обе стороны могут передаваться байты.
HTTP как раз и описывает какие байты (символы) и в каком порядке надо передавать, чтобы клиента и сервер понимали друг друга. HTTP возможно один из самых простых протоколов. На сегодняшний день существует две версии протокола HTTP — 1.0 и 1.1. Наиболее распространенными командами являются GET и POST. Формат запроса выглядит следующим образом:

GET <URL> HTTP/1.0
<Имя_заголовка_1>:<значение_заголовка_1>

Для 1.1 запрос несколько сложнее

GET <URL> HTTP/1.0
Host: <host>
<Имя_заголовка_1>:<значение_заголовка_1>

URL включает в себя путь до ресурса и параметры, которые передаются после пути. Ставим знак вопроса а потом идут пары <имя>=<значение> через знак &. Что-то вроде

GET /rfs/show?showName=direct&secondLetter=123

Как видите, здесь мы запросили ресурс /rfs/show а также передали параметры showName и secondLetter.

Команда POST используется в случае, если параметр в строке не передать. Например, Вы хотите передать двоичный файл — в этом случае команда GET Вам вряд ли подойдет. Формат ее похоже на GET, только параметры передаются более сложным образом — не в строке, а уже после заголовков. Повторю еще раз — после того, как приложения установили между собой TCP соединение они передают друг другу байты (символы). Как аналог TCP-соединение можно рассматривать как — Вы дозвонились по нужному телефону и на том конце подняли трубку. Теперь Вы начинаете общаться — и вот это уже HTTP. Т.е. как говорят «HTTP работает поверх TCP».
Как уже упоминалось выше клиент запрашивает у Web-сервера какой-либо ресурс по имени — URL. И получив запрос сервер уже может решить, что же реально просит пользователь. Иногда это самый простой статический файл, который надо передать. Но очень часто используя URL сервер создает HTML-страницу «на лету». (Это что-то вроде — по телефону спросить: «Продиктуйте мне данные клиента А». В ответ могут продиктовать уже с готового листа, а могут послать запрос в 3-4 места и выдать уже скомпанованную информацию). Созданием такой страницы может заниматься посторонняя программа, которая выводит свои данные не на экран, а в область данных сервера (не совсем точно, но здесь это не требуется) — эта технология до сих пор существует. Называется она CGI — Common Gateway Interface. Работает очень медленно, имеет ужасные возможности по кэшированию. Но тем не менее пока существует.
Java предлагает более элегантное решение — сервлеты.

Первое слово о сервлетах

Что же такое сервлет ? В двух словах описать работу сервлета можно так: Web-сервер, который умеет работать с сервлетами, запускает Java-машину, которая в свою очередь выполняет сервлет, а сервлет отдает данные, которые он сформирует. Т.е. при приходе запроса от клиента сервер с помощью специального конфигурационного файла может определить, какой сервлет выполнить, сервлет выполняется и создает HTML-страницу, которую сервер отправляет клиенту.
А теперь еще раз и медленно 🙂
На сервер приходит запрос от клиента, запрос содержит внутри себя URL и параметры. Сервер имеет специальный конфигурационный файл, который ему сообщает о том, какой сервлет надо выполнить в случае прихода определенного URL. Сервлет выполняется (там вы можете использовать параметры) и создает HTML-страницу, которая отсылается клиенту.
Сервер по сути является контейнером (теперь уже не визуальных компонентов), который загружает сервлеты, выполняет их, вызывая определенные методы и получив от них результат, отправляет его клиенту.
Таким образом сервлет — это Java-класс, который наследуется обычно от класса • HttpServlet и переопределяет часть методов:
• doGet — если мы хотим, чтобы сервлет реагировал на GET запрос.
• doPost — если мы хотим, чтобы сервлет реагировал на POST запрос.
• doPut, doDelete — если мы хотим, чтобы сервлет реагировал на PUT и DELETE запрос (есть и такие в HTTP). Эти методы реализуются крайне редко, т.к. сами команды тоже очень редко встречаются.
• init, destroy — для управления ресурсами в момент создания сервлета и в момент его уничтожения.

Если же необходимо перехватывать все команды, то проще переопределить метод service. Именно этот метод вызывается при приходе запроса от клиента. В HttpServlet происходит разбор запроса и в соответствии с указанной командой вызывается метод doGet, doPost и т.д.
Мы напишем очень простой сервлет, который выведет традиционное Hello, world!.
Но прежде нам необходимо запустить Web-сервер, который поддерживает сервлеты. Наиболее простым для нас будет Tomcat.

HTML и XML

Для понимания дальнейшего материала вам необходимо иметь некоторые знания о двух языках разметки — HTML (Hyper Text Markup Language) и XML (eXtensible Markup Language).

Рекомендуем:
Мне очень понравилась статья по HTML — Изучение HTML 3.2 на примерах.
По XML Вы можете посмотреть статьи на том же ресурсе:
Язык XML — практическое введение
Язык XML — практическое введение. Часть 2

В двух словах — оба языка используют систему «тэгов». Тэг — это набор символов, который заключен в угловые скобки «<«, «>». Для примера:

<B>Жирный текст</B>

Как видите я «открыл» тэг B и после текста «закрыл» его. В принципе ничего сложного. Важно, что будет делать браузер (или другое приложение) который встретит такую последовательность. Для HTML это значит, что текст, который нажодится внутри должен быть выделен «жирным» шрифтом.
Важно понять, что HTML — это просто способ «рассказать» браузеру как форматировать ваш текст. Т.е. используя разные теги вы указываете в каком виде будет выводится ваша информация. Т.е. HTML имеет конкретный набор тэгов, с помощью которых происходит форматирование текста — размеры шрифта, выравнивание, цвет фона и т.д.
В отличии от HTML назначение XML — хранить структуру данных. Вы определяете именно структуру вашего документа, что где и в каком порядке находится, но показывать такой документ браузер по идее не может — ему надо подсказывать как интерпретировать тот или иной тег. Вы можете придумать ваши собственные теги, которые очень важны и понятны именно для вас и вашего документа. К сожалению (а может и к радости) эта тема требует отдельной книжки, поэтому здесь мы останавливаться не будем.
Очень прошу только одного — ознакомиться с общими понятиями HTML И XML для понимания дальнейшего. Хватит простого понимания — тонкости будете изучать сами в дальнейшей самостоятельной работе.

Запускаем Web-сервер Tomcat

Загрузить Tomcat можно с сервера — Apache Tomcat.
Слева вы увидите список версий Tomcat – выбирайте подходящую (я тестировал свое приложение на версии 6). ВНИМАНИЕ: Прежде чем загрузить файл посмотрите, какую версию JVM Вы используете. Если 1.4, то Tomcat версии 6.x/5.5 вам не подойдет. Существует дополнительная библиотека, которая решает проблему совместимости, но мой вам искренний совет — поставьте себе JVM 1.5 и вы избежите проблем с установкой. В принципе вы не должны были легко пройти предыдущие части, т.к. там тоже требуется версия Java 1.5 и выше.

По сути вы загрузите архив, который надо просто распаковать в какую-либо директорию. Я обычно создаю отдельную папку JAVA в которую устанавливаю все свои пакеты, IDE, JDK и прочие штуки. Само собой каждый пакет имеет свою собственную директорию.
В будущем я буду использовать значение TOMCAT_HOME, чтобы показать, в какой директории внутри установленного сервера Tomcat вы должны что-то запускать, устанавливать или менять.
Также ОЧЕНЬ ВАЖНО — вам надо установить переменную окружения JAVA_HOME. Она должна указывать на путь до корневой директории установленного JDK.
Для Windows это делается так:
Пуск->Настройка->Панель управления->Система->Дополнительно->Переменные среды.
Для Unix вам просто необходимо из командной строки создать переменную JAVA_HOME или прописать ее в начальных настройках. (Думаю, что для тех, кто пользуется Unix это не составит проблем).
Если мне не изменяет память, для ранних версий Tomcat необходимо было также сосздать переменную TOMCAT_HOME, но теперь это не обязательно. Так что можно не делать.
После того, как вы установили Tomcat давайте проверим его работоспособность. Для этого зайдите в директорию <TOMCAT_HOME>\bin и запустите файл startup.bat. Если вы ничего не напутали, то должно запуститься DOS-окно, в которое выводится разная информация. Посмотрите за тем, чтобы не было сообщений об ошибках — их сразу видно — обычно выдается полный стек методов. Самое главное сообщение для вас должно появиться в самом конце (обычно надо подождать 5-10 секунд — при условии, что Tomcat не содержит много приложений)

INFO: Server startup in 8828 ms

Количество миллисекунд конечно может быть не таким. Если все прошло успешно запустите браузер и наберите в нем

http://localhost:8080/

8080 — это порт по умолчанию, который занимает Tomcat. Порт 80 он не трогает. Хотя если вам необходимо использовать другой

Сервлет — это… Что такое Сервлет?

Сервлет является Java-программой, выполняющейся на стороне сервера и расширяющей функциональные возможности сервера. Сервлет взаимодействует с клиентами посредством принципа запрос-ответ.

Сервлеты должны реализовывать Servlet интерфейс, который определяет методы жизненного цикла.

Хотя сервлеты могут обслуживать любые запросы, они обычно используются для расширения веб-серверов. Для таких приложений технология Java Servlet определяет HTTP-специфичные сервлет классы.

Пакеты javax.servlet и javax.servlet.http обеспечивают интерфейсы и классы для создания сервлетов.

История

Первая спецификация сервлетов была создана в Sun Microsystems (версия 1.0 была закончена в июне 1997). Начиная с версии 2.3, спецификация сервлетов разрабатывалась под руководством Java Community Process. Стандарт JSR 53 определял как Servlet 2.3, так и спецификацию JavaServer Page 1.2. JSR 154 включает в себя спецификации Servlet 2.4 и текущую на данный момент 2.5.

Жизненный цикл Сервлета

Жизненный цикл сервлета состоит из следующих шагов:

1. В случае отсутствия сервлета в контейнере.
   1. Класс сервлета загружается контейнером.
   2. Контейнер создает экземпляр класса сервлета.
   3. Контейнер вызывает метод init(). Этот метод инициализирует сервлет и вызывается в первую очередь, до того, как сервлет сможет обслуживать запросы. За весь жизненный цикл метод init() вызывается только однажды.
2. Обслуживание клиентского запроса. Каждый запрос обрабатывается в своем отдельном потоке. Контейнер вызывает метод service() для каждого запроса. Этот метод определяет тип пришедшего запроса и распределяет его в соответствующий этому типу метод для обработки запроса. Разработчик сервлета должен предоставить реализацию для этих методов. Если поступил запрос, метод для которого не реализован, вызывается метод родительского класса и обычно завершается возвращением ошибки инициатору запроса.
3. В случае если контейнеру необходимо удалить сервлет, он вызывает метод destroy(), который снимает сервлет из эксплуатации. Подобно методу init(), этот метод тоже вызывается единожды за весь цикл сервлета.

Пример

import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
 
public class NewServlet extends HttpServlet {
 
    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
 
        // Параметр
        String parameter = request.getParameter("parameter");
 
        // Старт HTTP сессии
        if (request.getSession() == null) {
            HttpSession session = request.getSession(true);
            session.setAttribute("parameter", parameter);
        }
 
        response.setContentType("text/html;charset=UTF-8");
        PrintWriter out = response.getWriter();
        try {
            out.println("<html>");
            out.println("<head>");
            out.println("<title>Заголовок</title>");
            out.println("</head>");
            out.println("<body>");
            out.println("<h2>Пример сервлета"+parameter+"</h2>");
            out.println("</body>");
            out.println("</html>");
        } finally {
            out.close();
        }
    } 
 
    @Override
    public String getServletInfo() {
        return "Пример сервлета";
    }
 
}

См. также

Серверы

Ссылки

Сервлет (Java) — это… Что такое Сервлет (Java)?

Сервлет является Java-интерфейсом, реализация которого расширяет функциональные возможности сервера. Сервлет взаимодействует с клиентами посредством принципа запрос-ответ.

Хотя сервлеты могут обслуживать любые запросы, они обычно используются для расширения веб-серверов. Для таких приложений технология Java Servlet определяет HTTP-специфичные сервлет классы.

Пакеты javax.servlet и javax.servlet.http обеспечивают интерфейсы и классы для создания сервлетов.

История

Первая спецификация сервлетов была создана в Sun Microsystems (версия 1.0 была закончена в июне 1997). Начиная с версии 2.3, спецификация сервлетов разрабатывалась под руководством Java Community Process. Стандарт JSR 53 определял как Servlet 2.3, так и спецификацию JavaServer Page 1.2. JSR 154 включает в себя спецификации Servlet 2.4 и 2.5. Текущая спецификация на 24 апреля 2012 года — Servlet 3.0 (описана в JSR-315).

Жизненный цикл Сервлета

Жизненный цикл сервлета состоит из следующих шагов:

1. В случае отсутствия сервлета в контейнере.
   1. Класс сервлета загружается контейнером.
   2. Контейнер создает экземпляр класса сервлета.
   3. Контейнер вызывает метод init(). Этот метод инициализирует сервлет и вызывается в первую очередь, до того, как сервлет сможет обслуживать запросы. За весь жизненный цикл метод init() вызывается только однажды.
2. Обслуживание клиентского запроса. Каждый запрос обрабатывается в своем отдельном потоке. Контейнер вызывает метод service() для каждого запроса. Этот метод определяет тип пришедшего запроса и распределяет его в соответствующий этому типу метод для обработки запроса. Разработчик сервлета должен предоставить реализацию для этих методов. Если поступил запрос, метод для которого не реализован, вызывается метод родительского класса и обычно завершается возвращением ошибки инициатору запроса.
3. В случае если контейнеру необходимо удалить сервлет, он вызывает метод destroy(), который снимает сервлет из эксплуатации. Подобно методу init(), этот метод тоже вызывается единожды за весь цикл сервлета.

Пример

import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
 
public class NewServlet extends HttpServlet {
 
    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
 
        // Параметр
        String parameter = request.getParameter("parameter");
 
        // Старт HTTP сессии
        HttpSession session = request.getSession(true);
        session.setAttribute("parameter", parameter);
 
        response.setContentType("text/html;charset=UTF-8");
        PrintWriter out = response.getWriter();
        try {
            out.println("<html>");
            out.println("<head>");
            out.println("<title>Заголовок</title>");
            out.println("</head>");
            out.println("<body>");
            out.println("<h2>Пример сервлета"+parameter+"</h2>");
            out.println("</body>");
            out.println("</html>");
        } finally {
            out.close();
        }
    } 
 
    @Override
    public String getServletInfo() {
        return "Пример сервлета";
    }
 
}

См. также

Серверы

Ссылки

Что такое Java-сервлет?

сервлет по своей сути является классом java; который может обрабатывать HTTP-запросы.
Как правило, внутренняя мелочь чтения HTTP-запроса и ответа по проводу заботится о контейнерах, таких как Tomcat. Это делается для того, чтобы в качестве разработчика на стороне сервера вы могли сосредоточиться на том, что делать с HTTP-запросом и ответами, а не беспокоиться о работе с кодом, который имеет дело с сетью и т. д. Контейнер позаботится о таких вещах, как упаковка всего этого в HTTP-ответ объект и отправить его клиенту (скажем, браузер).

теперь следующий логический вопрос: кто решает, что должен делать контейнер? И ответ: в мире Java, по крайней мере, он руководствуется (обратите внимание, что я не использовал слово controlled) спецификациями. Например, спецификации сервлета (см. ресурс 2) диктуют, что сервлет должен уметь делать. Поэтому, если вы можете написать реализацию для спецификации, поздравляем вас с тем, что вы только что создали контейнер (технически контейнеры, такие как Tomcat, также реализуют другие спецификации и делают сложные вещи, такие как пользовательские загрузчики классов и т. д., Но вы получаете идею).

предполагая, что у вас есть контейнер, ваши сервлеты теперь являются классами java, жизненный цикл которых будет поддерживаться контейнером, но их реакция на входящие HTTP-запросы будет решена вами. Вы делаете это, написав, что вы хотите сделать в заранее определенных методах, таких как init (), doGet (), doPost() и т. д. Посмотрите на ресурс 3.

вот это весело упражнение для вас. Создайте простой сервлет, как в Resource 3, и напишите несколько систем.из.операторы println() в его методе конструктора (Да, вы можете иметь конструктор сервлета), методы init (), doGet (), doPost() и запустить сервлет в tomcat. См. журналы консоли и журналы tomcat.

надеюсь, это поможет, счастливого обучения.

ресурсы

1. посмотрите, как выглядит сервлет HTTP здесь(Tomcat образец.)

2. сервлет спецификация.

3. Простой Сервлет пример.

4. начать чтение книги онлайн / PDF
   Он также предоставляет вам загрузку всей книги. Может быть это поможет.
   если вы только начинаете сервлеты, возможно, это хорошая идея прочитать материал вместе с API сервлетов. это более медленный процесс обучения, но он более полезен для получения основы ясны.

Что такое сервлет, java httpservlet

Устранение неполадок администрирования

Приведенная в этом разделе информация поможет вам исправить существующие неполадки, связанные с WebSphere Portal, а также предотвратить их появление в будущем. Информацию об отдельных компонентах можно найти в соответствующих разделах, посвященных устранению неполадок.

Устранение неполадок, возникающих при работе с порталом

В этом разделе описаны неполадки, которые могут возникнуть во время работы с порталом или во время администрирования портала.

Неполадка: В портале не отображаются страницы (системы Unix с DB2)

Если во время установки портала была выбрана опция развертывания основных портлетов (административных портлетов и портлетов настройки, применяемых порталом), однако при открытии портала ни одна страница не была показана, а файлы протокола установки базы данных содержат следующие сообщения об ошибках, значит возникла ошибка общей памяти в источниках данных DB2 и WebSphere Application Server:

com.ibm.wps.util.DataBackendException: Error during database access! Nested Exception is com.ibm.websphere.ce.cm.StaleConnectionException: [IBM][CLI Driver] SQL1224N A database agent could not be started to service a request, or was terminated as a result of a database system shutdown or a force command. SQLSTATE=55032

Исправление: В системах Unix базу данных WebSphere Portal нельзя использовать напрямую. Нужно определить локальный псевдоним базы данных. Этот псевдоним подключается к базе данных WebSphere Portal по соединению TCP/IP. Необходимые инструкции приведены в WebSphere Portal Information Center. Найдите инструкции по настройке DB2.

Неполадка: Когда несколько пользователей входят в систему с одного клиента, браузер переключается на другой сеанс

Если пользователь войдет в портал, а затем откроет другой экземпляр браузера и еще раз войдет в портал под именем другого пользователя, то второй экземпляр браузера может переключиться на первый сеанс пользователя. Не исключены и другие неполадки.

Исправление: В тех случаях, когда в портал нужно войти под именем другого пользователя, используя тот же клиент, следует выполнить одну из следующих процедур:

• Если сеанс первого пользователя сохранять не нужно, закройте этот сеанс, а затем войдите в систему от имени другого пользователя.
• Если одновременно должны быть открыты сеансы двух пользователей, откройте сеанс второго пользователя в браузере другого типа. Например, откройте первый сеанс в Netscape Navigator, а второй сеанс — в Microsoft Internet Explorer.

Неполадка: Изменение информации о пользователе в WebSphere Portal приводит к непредвиденным результатам

Если при изменении информации о пользователе в WebSphere Portal было выдано сообщение об ошибке «Сбой базовой системы хранения данных. Повторите попытку позже» или атрибуты пользователя не были изменены в LDAP, то, возможно, необходимо изменить параметры настройки производительности DB2 и IBM Tivoli Directory Server.

Исправление: По умолчанию применяются следующие параметры DB2:

APP_CTL_HEAP_SZ 128 APPLHEAP_SZ 128

Этих значений недостаточно для системы IBM Tivoli Directory Server WebSphere Portal AIX с 2000 записей о пользователях.

Размер кучи UDB применяется при вставке и обновлении данных.

WebSphere Portal запускает сложные транзакции на сервере LDAP при выполнении любых операций, в частности, при изменении атрибутов пользователей, которое требует выполнения нескольких операций обновления и вставки. Для устранения этой неполадки рекомендуется настроить производительность WebSphere Portal следующим образом:

su -ldapdb2 db2 -c update db cfg for ldap using APP_CTL_HEAP_SZ 1024 db2 -c update db cfg for ldap using APPLHEAP_SZ 1024

Неполадка: Ошибка приложения Изменить макет и информационное наполнение

После выбора задачи Изменить страницу может возникнуть ошибка приложения. Эта ошибка возникает после выполнения следующей последовательности действий:

1. В портале регистрируется новый пользователь.
2. Пользователь входит в систему.
3. Пользователь выбирает страницу, с которой он планирует работать.
4. Пользователь выбирает задачу Изменить страницу.
5. Пользователь выбирает портлет на странице и щелкает на значке Изменить портлет.

   Открывается окно Изменить портлет.

6. Пользователь изменяет портлет и нажимает кнопку OK. Окно Изменить портлет закрывается.
7. Пользователь снова щелкает на значке Изменить портлет. Открывается окно Изменить портлет с сообщением .

Исправление: При возникновении такой ошибки пользователь должен выйти из системы, а затем снова войти в систему. В следующий раз ошибка не возникнет.

Неполадка: Портлет не показан в портале

Исправление: Убедитесь в том, что:

• У вас есть права доступа к портлету.
• Портлет был добавлен на страницу портала.
• Открыта страница, содержащая портлет.
• Устройство, применяемое для просмотра портала, поддерживает язык описаний портлета.

Неполадка: Пустое окно портлета

Если Web-приложение с портлетами недоступно, например, остановлено сервером приложений, то соответствующие портлеты не покажут сообщение об ошибке, а просто покажут пустое окно. В этом случае в файл протокола будет занесено одно из следующих сообщений:

• PEPC0001E: ServletContext, относящийся к сервлету XX, не найден.
• PEPC0003E: Поиск ServletContext для XX вернул контекст портала. Ожидался другой контекст.

Исправление: С помощью Административной консоли сервера приложений убедитесь, что приложение запущено.

Неполадка: Портлет стал недоступен после обновления его приложения

Исправление: В течение некоторого времени после обновления приложения с портлетами обновленные портлеты могут быть недоступны. Выйдите из системы, а затем снова войдите в систему.

Неполадка: После возникновения тайм-аута LTPA и последующего тайм-аута сеанса появилось сообщение об ошибке

После возникновения тайм-аута LTPA и последующего тайм-аута сеанса может быть выдано сообщение об ошибке . В этом случае необходимо снова войти в систему.

Исправление: Обновите содержимое окна браузера одним из следующих способов:

• В Netscape щелкните на значке Обновить, удерживая нажатой клавишу Shift.
• В Internet Explorer щелкните на значке Обновить, удерживая нажатой клавишу Shift.

Неполадка: При поиске пользователей и групп происходит тайм-аут или возвращается слишком много результатов

При выполнении поиска, который должен вернуть большое число пользователей и групп может произойти тайм-аут. Кроме того, возможна ситуация, когда число записей, возвращенных операцией поиска, превысит максимальное число записей, которое может быть обработано системой.

Исправление: Вы можете настроить функцию поиска, ограничив максимальное число результатов или время выполнения операции. Подробные инструкции приведены в разделе Управление пользователями и группами.

Неполадка: Обновление окна браузера приводит к выполнению операции портлета

В портлетах, использующих операции со строками, обновление окна браузера может привести к повторному выполнению операции портлетом, что может привести к неправильной работе некоторых портлетов. Например, обновив окно браузера, пользователь может обнаружить, что изменилось количество помещенных в корзину товаров.

Исправление: Измените портлет, добавив следующий параметр конфигурации:

com.ibm.wps.portlet.action.redirect = true

Этот параметр позволяет перезагружать страницу и портлет без параметров действий в URL. Для добавления и настройки параметров конфигурации выберите опцию Администрирование,Портлеты,Управление портлетами. Выберите портлет для изменения и нажмите кнопку Изменить параметры.

Неполадка: Сообщение о тайм-ауте сеанса

Когда пользователь входит в защищенную область WebSphere Portal (например, myportal) с другого экземпляра сервера приложений домена единого входа в систему WebSphere Portal, используя cookie сеанса с именем JSESSIONID и путем, совпадающим с URL портала (например, со значением по умолчанию /), то будет показано сообщение о тайм-ауте сеанса. Причина этого состоит в том, что WebSphere Portal не может определить, был ли cookie браузера создан им самим или другим экземпляром сервера приложений.

Исправление: Если возникает эта неполадка, следует исправить путь cookie так, чтобы можно было различать URL WebSphere Portal в различных экземплярах сервера приложений, входящих в один домен единого входа в систему. Задайте уникальный путь для cookie с именем JSESSIONID в параметрах управления сеансом на странице Администрирование WebSphere Application Server.

Примечание: Если вы укажете путь cookie с помощью опции «заменить» в параметрах управления сеансом на уровне, отличном от уровня Web-контейнера, то вам потребуется еще раз задать параметры распределенного сеанса на этом уровне, даже если они уже были заданы на уровне Web-контейнера.

Неполадка: После входа в систему двух пользователей в браузере Mozilla показан только один пользователь

Браузеры Mozilla, подключающиеся к порталу с одного и того же IP-адреса, используют один сеанс WebSphere Portal. Если пользователь войдет в систему портала сразу под двумя именами, то браузер продолжит применять лишь одно из имен, причем сообщение о том, какой именно пользователь работает с WebSphere Portal, не будет выдано. Например, если в одном окне браузера пользователь вошел в систему под именем UserA, а в другом окне — под именем UserB, то оба окна будут обрабатываться как открытые пользователем UserB, т.е. вся показанная информация и параметры будут относиться к пользователю UserB.

Исправление: Для входа в систему под другим именем пользователя с помощью браузера Mozilla необходимо предварительно закрыть все экземпляры браузера.

Неполадка: При отсутствии администратора заданий не выполняется параллельное отображение портлетов

Если во время установки портала не был создан администратор заданий, то портал выдает следующее сообщение об ошибке:

Данное сообщение указывает на то, что администратор заданий не был создан во время установки. Обычно это происходит по следующим причинам:

• Не установлен компонент PME (расширения модели программирования)
• При установке PME не были выбраны асинхронные компоненты JavaBean

В результате не работает функция параллельного отображения портлетов (PPR). Компонент PPR заносит в протокол указанное выше сообщение об ошибке PEEX0100E. Данное сообщение может также указывать на тот факт, что не выполнена инициализация процесса параллельного отображения. В этом случае параллельное отображение автоматически выключается. Портал продолжает нормальную работу без применения этой функции. Все портлеты отображаются последовательно.

Исправление: Для правильной работы компонента PPR необходимо перед установкой портала обеспечить выполнение всех требований, обязательных для работы этого компонента.

Собеседование по Java EE — JEE Servlet API (вопросы и ответы)

Ниже перечислены требования, которые должны быть выполнены:

1. Должен быть установлен сервер приложений с PME.
2. В состав PME входят JavaBean асинхронной связи, необходимые для создания диспетчера нагрузки.
3. Во время установки портала должен быть создан диспетчер нагрузки .

Неполадка: Портлет Поиск документов не работает на анонимной странице

Если поместить портлет Поиск документа на анонимной странице, для работы с которой пользователю не требуется входить в систему, то портлет не будет работать.

Исправление: Следует разрешить общедоступные сеансы работы с порталом.

Причиной ошибки является то, что портлету поиска документов необходим доступный сеанс, а на страницах для анонимных пользователей портала по умолчанию сеансы отключены. По умолчанию сеансы создаются только после идентификации пользователя и его входа на сервер портала.

Для того чтобы включить общедоступные сеансы, откройте файл и присвойте параметру значение . Перезапустите WebSphere Application Server и WebSphere Portal, чтобы изменения вступили в силу.

Неполадка: Портлеты поиска не работают после замены локальной службы на удаленную или наоборот

Если в конфигурации портлетов поиска заменить локальную службу поиска на удаленную службу, или наоборот, то портлеты перестанут работать. Это относится к административному портлету Управление наборами документов и к портлету пользовательскому портлету Поиск документов.

Причина: Встроенный компонент поиска можно настроить для работы с локальной службой поиска, либо с удаленной службой поиска посредством интерфейса SOAP (Web-службы). Портлет, настроенный на использование локальной или удаленной службы поиска, нельзя настроить на использование другого типа службы поиска. При попытке сделать это портлет перестанет работать.

Исправление: Портлет можно переключить на использование другого типа службы поиска (например, удаленной вместо локальной) только вручную. Для этого следует создать другую копию портлета и настроить ее на использование другого типа службы поиска. Для использования локальной службы поиска параметр URL SOAP следует оставить пустым, а для использования удаленной службы — указать его значение.

Устранение неполадок, связанных с поддержкой национальных языков

В этом разделе описаны ошибки, которые могут возникать при просмотре информации на различных языках в WebSphere Portal.

Неполадка: Неполадки Netscape в системе AIX с турецкой локалью

При просмотре портала в браузере Netscape, установленном в системе AIX с турецкой локалью и турецкой раскладкой клавиатуры, некоторые турецкие символы могут выводиться неправильно. Кроме того, может быть запрещен вход в систему. Это связано с тем, что Netscape для AIX поставляется на условиях ограниченной гарантии.

Исправление: При возникновении подобных неполадок рекомендуется воспользоваться другим браузером или браузером, установленным в другой операционной системе.

Неполадка: Неполадке при просмотре информации DBCS на различных языках

Если браузер работает в локали или , то текст на трех остальных языках может не отображаться.

Исправление: Выполните следующие действия:

1. Войдите в систему портала.
2. Выберите Администрирование > Параметры портала > Поддерживаемые языки описания.
3. Выберите HTML.
4. Выберите Изменить язык описания.
5. Выберите Параметры, зависящие от локали.
6. Выберите требуемый язык.
7. Выберите Изменить параметр для выбранного языка.
8. Задайте в поле Кодировка.
9. Нажимая OK, подтвердите свой выбор и вернитесь в главное окно портлета Управление языками описания.

Неполадка: Ошибки отображения двухбайтовых символов в полях выбора в браузере

Данная информация относится к языкам с набором двухбайтовых символов (DBCS). Если поля выбора содержат информацию DBCS (например, поле для выбора страницы), то в некоторых случаях все символы отображаются в виде прямоугольников. Эта неполадка возникает случайным образом, поэтому невозможно указать, для каких версий браузеров и операционных систем она характерна.

Исправление: Исправление в настоящее время не предусмотрено.

Неполадка: Неполадки функции поиска в Information Center и справке по порталу

Если вы открыли WebSphere Portal Information Center или справку по порталу в Microsoft Internet Explorer 6.x, а затем воспользовались функцией поиска, то результаты поиска могут содержать искаженные символы.

Исправление: Список других поддерживаемых Web-браузеров приведен в разделе Требования справочной системы Information Center.

Неполадка: Неполадки Microsoft Internet Explorer в системе с японской локалью

Исправление:

• При обращении к порталу с японской локалью с помощью Microsoft Internet Explorer при нажатии клавиши с символом японской йены в полях ввода портала может отображаться символ обратной косой черты. Это связано с особенностями поддержки кодировки UTF-8 в Microsoft Internet Explorer. Для устранения этой неполадки используйте другие браузеры, например, Netscape или Mozilla, либо смените набор символов портала с UTF-8 на Shift_JIS. Дополнительная информация приведена в разделе Изменение набора символов языка.
• Компонент текстового редактора из набора инструментальных компонентов WebSphere Portal позволяет изменять обычный формат на формат заголовка и обратно. При обращении к порталу с японской локалью с помощью Microsoft Internet Explorer эта функция может не работать. Используйте другие браузеры, например, Mozilla.

Устранение неполадок администрирования портала

Неполадка: Невозможно использовать интерфейс конфигурации XML, если применяется внешняя функция защиты

Если виртуальный ресурс , представляющий доступ к интерфейсу конфигурации XML, перевести под защиту внешнего администратора защиты, дальнейшее использование интерфейса конфигурации XML станет невозможно.

Исправление: Если управление доступом к WebSphere Portal передается внешнему администратору защиты, такому как Tivoli Access Manager, то следует проследить за тем, чтобы виртуальный ресурс интерфейса конфигурации XML не был передан под управление внешнего администратора.

Неполадка: Исчезает ссылка на режим редактирования портлета

Во время изменения страницы с помощью портлета Редактирование макета эта страница деактивируется, а ссылка для перехода в режим редактирования портлета, расположенного на этой странице, удаляется.

Причина: Страница деактивируется в момент выполнения любого действия в портлете Редактирование информационного наполнения и макета, например при добавлении портлета или перемещении портлета или контейнера.

Исправление: Если страница была деактивирована в результате выполнения какого-либо действия, нажмите Готово, чтобы выйти из страницы. Страница будет активирована повторно. Щелкните на ссылке Редактировать страницу, чтобы была показана ссылка Редактировать портлет.

Неполадка: Не загружается Административная консоль

WebSphere Portal устанавливает на сервере WebSphere Application Server приложение административной консоли WebSphere Portal Application Server, с помощью которого можно управлять сервером приложений, не настраивая и не запуская второй экземпляр сервера приложений (по умолчанию это server1). По умолчанию номер порта равен 9081.

Исправление: В системах Windows 2000 для запуска Административной консоли создается пункт меню Пуск. Если при выборе этого пункта меню консоль не загружается и выдается сообщение об ошибке HTTP 404, значит для сервера приложений задан порт администрирования, отличный от указанного в ярлыке для пункта меню Пуск.

Измените свойство Административной консоли WebSphere Application Server в меню Пуск Windows 2000 (Пуск > Программы > IBM WebSphere > Application Server Version 5.0 > Административная консоль). Например, измените

на

Связанная информация

Library | Support | Terms of use | Feedback
Information Center last updated: Friday, November 19, 2004
IBM WebSphere Portal for Multiplatforms 5.1 | (c) Copyright IBM Corporation 2000, 2004

С чего начинается Web

С чего начинается Web

Прежде,чем приступить к практическим вопросам web-программирования, мне бы хотелось немного поговорить о причинах возникновения Internet и intranet систем. Потому что на мой взгляд, это крайне важно — понять, какие задачи хотелось решать и какие инструменты возникли для решения этих задач.

В конце 80-х — начале 90-х годов XX-го столетия практически все системы все еще строились по принципу клиент-сервер. На компьютере работника было установлено графическое (или текстовое) приложение, которое обращалось к базе данных с запросами на изменение или получение данных.

Таким образом было две стороны:
Во-первых — клиент (как сейчас принято говорить, “толстый”), который имел какую-то логику и и давал возможность пользователю что-то делать с данными.
Во-вторых — сервер (обычно СУБД типа SQL), на котором выполнялись запросы на получение данных и их изменение. За счет возможности писать сохраненные процедуры (Stored Procedure) на каком-то расширении стандартного SQL (для Oracle — PL/SQL, для Sybase (и Microsoft) — TransactSQL, для DB2 — SQL PL). Такого рода процедуры позволяли писать достаточно сложную логику обработки данных, не перекладывая эту работу на клиента. Да и изменение логики было удобно сделать — в одном месте поменял и готово.
Клиентское приложение конечно же надо было в случае чего обновлять.

До какого-то момента всем казалось, что это работает замечательно.

Но потом появились ПОТРЕБНОСТЬ. Именно так — с большой буквы. ПОТРЕБНОСТЬ.

Системы клиент-сервер требовали сотрудника. Если клиент хочет сделать заказ — он должен связаться с сотрудником, который занесет его заказ в базу данных с помощью своего клиентского приложения.
Достаточно прямолинейное решение — дать клиентам приложение (пусть и ограниченное) было бы слишком опрометчивым. Во-первых — его надо сделать. В-вторых — его надо менять под потребности клиентов и каждый раз обновлять у этих самых клиентов.
В-третьих — система все чаще становилась зависимой не от одной базы данных, а от многих источников информации.
И что самое главное — БЕЗОПАСНОСТЬ. Клиентское приложение ходит в базу данных. Центральное хранилище “открывать” наружу — это уже не безопасность. Это по сути дела “дать всем ключи от квартиры, где деньги лежат”.

Итак, выросли три задачи. Хотя может и больше, но на мой взгляд именно эти моменты стали определяющими:

1. Безопасность
2. Клиентское приложение с возможностью обновления для сотен тысяч пользователей
3. Возможность принимать запросы от универсального клиента и писать логику для распределенных источников информации

Безопасность
Вполне логичным решением было введение промежуточного звена, которое принимало запросы от клиентов, проверяло бы их и транслировало бы дальше внутрь корпоративной сети. Таким образом все хранилища будут закрыты извне. Будет только один шлюз/вход, через который будут проходить все запросы. Такой вход гораздо легче контролировать.

Универсальный клиент
Самое очевидное решение — нужна программа, которая “на лету” исполняет код, который в нее загружается. И это браузер.
Со временем браузеры совершенствовались, язык отображения HTML (Hyper Text Markup Language — язык разметки гипертекста), становился более сложным и изощренным. Появились javaScript, который мог исполнять браузер и таким образом сделать страницы более интерактивными.В версии HTML 4.0 появились CSS (Cascade Style Sheets — каскадные таблицы стилей). Потом появилась и прижилась технология AJAX. В общем браузер сегодня — это действительно универсальный клиент.
Но даже в очень простой реализации, которая когда-то была, браузер может загрузить данные, отобразить их, позволить что-то ввести в текстовые поля и отправить данные на web-сервер.

Сервер приложений
Он-то и должен предоставить “возможность принимать запросы от универсального клиента и писать логику для распределенных источников информации”.
В простом варианте это была обычная программа, которая, говоря терминами предыдущей статьи о сетевом взаимодействии, открывала серверный сокет и ждала запросы от внешних программ. Причем в ранних версиях у такого сервера не было даже многопоточности — она просто порождала свою копию в виде отдельного процесса и передавала туда обработку запроса.
Также программа предоставляла возможность писать другие программы, которые могли быть ею запущены для исполнения запросов.

Вот такая вот схема выстроилась для решения ПОТРЕБНОСТИ.
Браузер, как универсальный клиент, который обратиться к серверу приложений (по определенному протоколу).
Сервер приложений в свою очередь запустит на выполнение программу, которая написана по определенным правилам.
Программа обработает запрос, что-то поменяет, что-то считает и отдаст результат (какие-то данные) в браузер, который это отобразит.

Как видим, мы пришли к очень неплохим выводам:

1. Нам нужен браузер — и он у нас есть
2. Нам нужна программа для приема сетевых запросов
3. Программа должна предоставлять возможности интегрировать в нее другие программы, которые будут решать специализированные задачи.

Сервер приложений

Программа, которая просто принимает сетевые запросы может быть очень простой. Мы даже написали что-то подобное в разделе “Сетевое взаимодействие”. Наш серверный сокет принимал запросы и отвечал — можно сказать, это наш сервер. Убогонький конечно, но все-таки — СЕРВЕР :).
Я пишу все эти слова с целью донести мысль о том, что сервер приложений в общем-то — это программа. И ее надо запускать. Просто запускать, как обычную программу. Не трепещите перед термином “сервер приложений” — это ОБЫЧНАЯ программа. Возможно, что сложная, с большим количеством возможностей, которые надо изучать. Но это ОБЫЧНАЯ программа.

Конечно же наша простенькая программа мало что может. Она слушает TCP-порт и отвечает достаточно просто. Но ее можно научить отвечать что-то более разумное для какого-то количества входных слов — научить определенному “протоколу общения”.
Помните, мы говорили об этом термине. Клиенту и серверу (да в общем-то любым двум программам) надо научиться разговаривать друг с другом. Сервер должен понимать, что клиент у него спрашивает, а клиент должен понимать, что сервер ему отвечает. Это и есть протокол. Набор слов (байтов), которые можно использовать для общения. Чуть ниже мы подробно поговорим о протоколе для Интернет, а пока продолжим рассуждать о сервере приложений.

Итак, мы уже увидели, что сервер приложений должен уметь слушать TCP-порт. А что еще должен уметь сервер ? На самом деле, если немного пофантазировать, то вы придумаете много чего.
Раз уж только что говорили о протоколе — ну как минимум сервер приложений должен уметь общаться по этому протоколу.
Немного помечтать и вот оно — наверняка многим программам, которые будут “подключаться” к нашему серверу (встраиваться в него, устанавливаться на нем, развертываться на нем) потребуется соединение с базой данных. Почему-бы не научить сервер приложений создавать уже готовые соединения и давать их “в аренду” другим ? А еще организовать механизм распределенных транзакций — чтобы можно было в рамках одной транзакции работать с несколькими базами данных.
Или вот еще — нужна система безопасности. Почему бы серверу приложений не обладать такой системой. Все остальные могут ею пользоваться.
А если встроить систему установки приложений ? А консоль управления параметрами сервера и тех же приложений ? И использовать для консоли браузер.
Можно вспомнить о загадочных web-services, SOAP и ReST. Что-то я увлекся 🙂

В этих рассуждениях вся суть сервера приложений. Эта программа предоставляет широко используемые сервисы. Уже заранее готовые и настроенные.
Если говорить о Java, то упрощенно, это уже готовый набор объектов или классов, которые можно использовать. Эти объекты создает сервер приложений по настройкам и любая программа, которая на сервере установлена, может их использовать.

Теперь не надо писать для каждого приложения кучу кода или подключать кучу библиотек — они уже есть. С любовью отобранные, оттестированные. Мечта, да и только. И мы увидим некоторые из этих возможностей уже достаточно скоро.

Немного забегая вперед, скажу, что список этих классов, интерфейсов и прочая имеет даже свое название — Java Enterprise Edition Specification — Java EE.
На данный момент самая последняя версия — 7.0. Готовится версия 8.0, но пока официально ее не публиковали.

А пока давайте вернемся к земному — погорим о протоколе.

Протокол HTTP

HTTP — HyperText Transfer Protocol — протокол передачи гипертекста. Основа основ на мой взгляд. Если вы не понимаете, что и как он делает, то многое в программировании для Интернет вы будете постигать с большим трудом.
Мы уже с ним встре

Что такое сервлет — Javapapers

Последнее изменение: Джо 27 июля 2014 г.

Сервлет — это тип класса Java, используемого в веб-приложениях Java, который расширяет возможности сервера. Эти сервлеты Java работают в контейнере сервера веб-приложений. Эти сервлеты используются для создания HTML-содержимого, отображаемого в веб-браузере. На самом низком уровне это не что иное, как класс Java.

Сервлеты

предназначены для ответа на запрос браузера пользователя и отправки содержимого ответа.Сервлет в основном реализован для протокола HTTP и, следовательно, называется HTTP Servlet. В платформе Java сервлеты используются для генерации динамического HTML-контента в целом. Их также можно использовать для создания и ответа с помощью XML, Excel, pdf, json и любых других форматов по мере необходимости.

Запрос сервлета, модель отклика

Обычно веб-браузер является клиентом в модели ответа на запрос сервлета. Браузер отправит запрос, и он будет обслуживаться HTTP-сервером. В бэкэнде HTTP-сервер будет использовать службы контейнера сервлетов для генерации динамического содержимого.

Важные классы и пакеты Servlet API:

• GenericServlet
• HttpServlet
• ServletRequest
• Ответ сервлета
• javax.servlet.http содержит классы сервлетов HTTP

Обзор сервлета

• Сервлет — это серверная технология в стеке платформы Java.
• Сервлет отвечает на входящий запрос от клиента браузера ответом.
• Хотя изначально предназначался для генерации HTML-контента в веб-приложениях, в настоящее время используется в основном на уровнях контроллера.
• JSP взял на себя работу по созданию HTML-содержимого. Но под капотом JSP генерируют классы сервлетов, которые и являются реальным элементом, отвечающим на запросы.

Выпуски сервлетов

• Сервлет 3.1: май 2013 г .: Неблокирующий ввод-вывод, механизм обновления протокола HTTP
• Servlet 3.0: декабрь 2009 г .: возможность подключения, простота разработки, асинхронный сервлет, безопасность, загрузка файлов
• Servlet 2.5: сентябрь 2005 г .: требуется JavaSE 5, поддерживает аннотацию
• Сервлет 2.4: ноябрь 2003 г .: web.xml использует схему XML

Сервлет

• 2.3: август 2001: добавлен фильтр
• Servlet 2.2: август 1999: Становится частью J2EE, представлены независимые веб-приложения в файлах .war
• Servlet 2.1: ноябрь 1998: первая официальная спецификация, добавлены RequestDispatcher, ServletContext
• Servlet 2.0: июнь 1998: часть Java Servlet Development Kit 2.0
• Servlet 1.0: июнь 1997: начальный выпуск

.

вики-тегов ‘сервлетов’ — qaruQaruSite

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

.

Servlet против JSP: в чем разница?

• Домой

• Тестирование

  • • Назад
    • Гибкое тестирование
    • BugZilla
    • Cucumber
    • Тестирование базы данных
    • Тестирование ETL
    • 0003
    • Jmeter Jmeter
    • Загрузка Jmeter
    • Ручное тестирование
    • Мобильное тестирование
    • Mantis
    • Почтальон
    • QTP
    • Назад
    • Центр качества (ALM)
    • RPA
    • SAP Testing
    • Selenium

  • SAP

    • • Назад
      • ABAP
      • APO
      • Начало er
      • Basis
      • BODS
      • BI
      • BPC
      • CO
      • Назад
      • CRM
      • Crystal Reports
      • FICO
      • Pay4
      • HR

      Назад

      • PI / PO
      • PP
      • SD
      • SAPUI5
      • Безопасность
      • Менеджер решений
      • Successfactors
      • SAP Tutorials
  • Назад

    Web

  • Angular

    Web

    • • ASP.Net
      • C
      • C #
      • C ++
      • CodeIgniter
      • СУБД
      • JavaScript
      • Назад
      • Java
      • JSP
      • Kotlin
      • Linux
      • Linux
      • Kotlin
      • Linux

      js

      • Perl
      • Назад
      • PHP
      • PL / SQL
      • PostgreSQL
      • Python
      • ReactJS
      • Ruby & Rails
      • Scala
      • SQL

      000

      • SQL

      000

      0003 SQL

      000

      0003 SQL

      000

      • UML
      • VB.Net
      • VBScript
      • Веб-службы
      • WPF

    • Обязательно учите!

      • • Назад
        • Бухгалтерский учет
        • Алгоритмы
        • Android
        • Блокчейн
        • Business Analyst
        • Создание веб-сайта
        • CCNA
        • Облачные вычисления
        • 00030003 COBOL
          9000 Compiler
          9000 Встроенные системы
          • 00030002 9000 Compiler
            • Ethical Hacking
            • Учебники по Excel
            • Программирование на Go
            • IoT
            • ITIL
            • Jenkins
            • MIS
            • Сети
            • Операционная система
            • 0003
            • Назад
            • Управление проектами Обзоры
            • Salesforce
            • SEO
            • Разработка программного обеспечения
            • VB A

          • Big Data

            • • Назад
              • AWS
              • BigData
              • Cassandra
              • Cognos
              • Хранилище данных

              0003

              • HBOps

              0003

              • HBOps

              0003

              • MicroStrategy
              • MongoDB

          .

          No related posts.