Во-во, это была одной из причин, по которым я в свое время стал искать альтернативы EJB и открыл для себя светлые идеи Рода Джонсона (создателя Спринга), а позднее и все остальное: тест-дривен и аджайл девелопмент, IoP, аспекты и прочие толковые вещи.

2 Platon:

А у меня нет такого напряга. Я запускаю Томкат из-под Эклипсы, так что небольшие изменения в Java коде сразу видны в браузере. Бывает, правда, что система не может подхватить изменения. Ну что ж, приходится перезапускать Томкат и ждать, страшно сказать... целыч 6-7 секунд, пока он развернется 

А тесты запускаются вообще без участия контейнера, мухой. Нажал на кнопку - и готово. Телемаркет!

Так что может тебе лучше настроить девелоперское окружение? Или подрихтовать архитектуру? Сама-то по себе Java вполне себе адекватная платформа, вопрос в том, как ее использовать.

Нашел старую тему, где обсуждались различные меры защиты веб приложений.
Одной из которых, было переопределение 4хх и 5хх ошибок. У меня такой вопрос, их все перенаправлять на конкретную страницу ошибки, где в общем написанно, например, доступ запрещен или описать каждую. С одной стороны клиент не будет знать что произошло от его вредительских действий. С другой стороны клиент не сможет помочь ресурсу, т.е. сообщить вебмастеру что есть ошибка и примите меры.
З.Ы. Что за бот Ask?

diablero
Информацию о таких ошибках скорее нужно рассматривать не с технической точки зрения, а с точки зрения юзабилити. Вот статья об этом, к примеру.

Аналогично, но запускается секунд 20-30...(тачка очень слабая), временами ужасно бесит.. спасают только юнит тесты   

Maksym
Спасибо, познавательно. 
Особенно порадовал стиль изложения:

  

Тут вот какое дело. Поскольку у тебя не корпоративное веб-приложение, а скорее обычный вебсайт, то большинство ошибок будут банальными опечатками в УРЛах - как твои собственные (на внутренних страницах), так и тех людей, что будут ссылаться на твой сайт извне. Ну и плюс еще попытки несанкционированного доступа на защищенные страницы (ага, это как Рамблер углядел где-то в прокси-кэше адрес моей админки, и долго долбился туда, глупенький; а не лезь, куда не просят... ссылки же такой нигде не было, а руками люди мало ли куда ходят  ).

Да, так о чем бишь я? Ах, да, что ошибки будут по большей части тривиальные, в которых и отлаживать-то нечего. Если битая ссылка на самом сайте - поправить, если с внешнего ресурса - отписать ихнему админу. А еще лучше - приделать свой механизм переадрезации (по 301) для перемещенных/удаленных страниц, и его же использовать для переправления с битых сылок.

Нужен ли нам в таких ситуациях какой-то фидбак от юзера? Да не больно-то. Достаточно время от времени чекать логи посещений. Ну, это в любом случае надо делать, я уже об этом неоднократно говорил. Ну, я еще себе по почте уведомления об ошибках шлю, чтоб оперативно реагировать.

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

Вот так вота. А сам по себе текст сообщения об ошибке может быть совсем лаконичным: не обломилось вам, товарищ, бывает - пожалуйте на главную страницу. А что, почему - этого ему знать совсем не обязательно 

to Stampede
Ну в общем понятно что к чему, я определилися как все сделаю.

О мелочах, не догляделок, которых ты упоминал:
Они вскрылись сразу, стоило мне посмотреть свои логи. Там есть ошибочка в детекторах, из-за чего боты не регестрировались
Инфа о страницах перехода с поисковиков парсится четко.

Когда перейдем к "блокировщику" ?

Ну хорошо, давай делать блокировщика.

По своему опыту могу сказать, что штука эта исключительно полезная: сейчас мои логи практически не засираются всякими непрошеными ботами, а раньше порядком доставали. Почему я говорю "практически" - ну, время от времени приползает что-нибудь новенькое; приходится отслеживать и добавлять в "блокиратор".

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

Проще всего обеспечить универсальность, реализовав блокиратор в виде фильтра. Отсюда вот тебе спецификация на разработку:

Класс-блокировщик нежелательного трафа

Критерии отфутболивания

• по IP:
• по юзер агенту

Инициализация

Получить имя файла конфига блокиратора (из параметров описания фильтра в web.xml). Предусмотреть значение по умолчанию (в директории WEB-INF/conf).

Зачитать файл, поместить списки плхих IP и агентов в память

Действия

При входящем запросе проверить источника на присутствие в плохих списках. 

Форма отлупа

Код статуса ХТТП 403 (Forbidden).


На этом пока все. В ходе реализации добавим кое-какие детали. Просю.

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

Ну что ж, diablero, неплохо.

Теперь о возможных улучшениях. Во-первых, можно предусмотреть формат с wildcards. Например, все, что начинается с Java (выкачивалки, сделанные на базе URLConnection), записать как "Java*",

Во-вторых, хотелось бы иметь болше инфы в логах сервера: кому дали отлуп, когда, на каких основаниях.

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

Ну и подумай сам, как еще можно было бы улучшить "блокиратор".

А мне вот интересно. Мы тут запускаем цепочку фильтров

на сколько я понимаю, то цепочка отработает от первого фильтра до вывода странички. Правильно ли это? Может быть стоило сделать так:

привет всем!
Буду очень благодарен если поможете.
Создаю вэб-сайт на яве, как персистенс выступает xml файл содержащий структуру сайта примерно такого содержания:



отсюда должно следовать динамическое создание меню, простота и легкость 
вопрос в том, что при использовании конструкции #include('data/subjects.txt') Velocity ищет этот файл у себя только в папке с шаблонами. А хочется чтобы шаблоны оставались шаблонами а папка data была на одном уровне с templates. Можно содержимое ложить в контекст еще в сервлете конечно, но может кто-нибуть посоветовать что?
И вообще какие еще минусы и плюсы хранения структуры в xml?

Молодец, Platon, верно подметил. Получи плюс за зоркий глаз 


2 aranea: товарищ, вы тут не по адресу. Создайте отдельную тему и там и задайте свой вопрос.

нижайший поклон Stampede так удачно я нашол этот топик в самом начале своих мытарств "с чего начать яву в вебе", чему способствовало подходящее название топика... всё здорово и грамотно. ещё раз спасибо.

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

Это сообщение отредактировал(а) qnub - 21.5.2008, 11:58

Смысл в унификации всей логики работы с формами для разных видов форм. В основе этого решения лежит принцип, известный математикам как классическая задача о чайнике: как вскипятить воду в чайнике? Набрать воду, поставить на печку, вскипятить. Усложняем: чайник наполовину полон - как тогда? Так вот, часто оказывается, что самое простое - свести задачу к уже известной: вылить остатки и повторить для пустого.

Так и у нас с формами. В результате резко упрощается логика заполнения при ошибках валидации.