◎ Продолжаю собирать пожелания

Добрый день, Алексей!

Я не совсем понял задачу. К какому url хочется добавить параметр?

Вообще JavaScript работает на стороне клиента, так что сессию он не модифицирует. А вот запрос - легко. Как правило, это делается так - создается hidden input, и в него пишется значение, которое надо передать на сервер. Можно даже модифицировать DOM и самостоятельно добавить нужное поле.

И к URL тоже можно добавить что угодно. Берется document.location.href, модифицируется и присваивается обратно. Присвоение вызовет переход по ссылке.

Добрый день, Алексей!

Объясняю популярно. Значение checkbox-а известно на стороне клиента, после того, как от сервера получена страница. А "наша могучая Java" работает на сервере - она генерирует эту самую страницу и отсылает ее клиенту. Эти два факта надо связывать для получения ответа на вопрос?

P.S. Если же Вы имеете в виду получение значения уже после отправки запроса обратно на сервер - тут проще. Это значение приходит в качестве параметра в request-е, но (!) ТОЛЬКО если checkbox выбран. Если не выбран - параметра не будет. Это достаточный признак для определения состояния checkbox-а.

protected-конструктор нужен для ситуаций, когда его вызывать может только наследник. Ну, например, там проводится не вся необходимая инициализация объекта, часть оставляется наследнику. Допустим, в базовом классе есть логика, основывающаяся на каком-либо классе (java.lang.Class), который знает только наследник. Причем этот класс должен тоже удовлетворять определенным условиям. В общем, может быть достаточно сложная ситуация.

Давать создавать такой объект пользователю, который не знает всех тонкостей - опасно. А тот, кто от класса унаследуется, с большой вероятностью изучит все его тонкости.

Для абстрактных классов разницы между protected и public конструкторами я с ходу не придумаю.

А вообще есть правило - необходимо уровень доступа делать минимально возможным, позволяющем решить задачу. Можно использовать protected вместо public - значит, нужно делать именно так. Чем меньше уровень доступа, там меньше возможно ошибок и побочных эффектов.

Да, убираются.

Стоит также помнить, что пул находится в области PermGen. И большой объем пула может вызвать OutOfMemory: PermGen space

Нет, к сожалению, не работал. Не только с tomcat - вообще.

Добрый день!

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

а) http://docs.oracle.com/javase/6/docs/api/java/io/PipedInputStream.html, http://docs.oracle.com/javase/6/docs/api/java/io/PipedOutputStream.html:

A pipe is said to be broken if a thread that was providing data bytes to the connected piped output stream is no longer alive.

The pipe is said to be broken if a thread that was reading data bytes from the connected piped input stream is no longer alive.

Это цитаты. Из документации :). Если поток, работающий с другой стороны, недоступен (проверяется через isAlive), то pipe считается поломанным. Возможно, и не совсем очевидно, но написано.

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

в) Честно сказать, я pipe-ы не использовал за 15 лет ни разу. Соответственно, задача отслеживания жизненного цикла не возникала. Я вообще слабо представляю, зачем в одном приложении нужно использовать pipe при наличии ссылок.

г) про блокировку в документации тоже написано - лучше оба конца в одном потоке не использовать, во избежание deadlock-а.

P.S. А если не секрет - что Вы такое делаете, что Вам pipe-ы понадобились?