Про конвертацию в String — уже успел наступить на эти грабли )) Там еще есть один нюанс есть, раз уж на то пошло…
Страницу считывать надо построчно, а не загружать целиком, а потом парсерить… Потому что страницы, в особенности блогов, могут быть просто гиганскими… И 80% из того текста, что будет загружаться — бесполезный. Столкнулся с этим просто уже )
ZyL — вы гениальны! =)) Есть такая штука, jspc И вот совсем недавно я прекомпилировал ей jsp'шки… В сгенерированном jspc web.xml идут вызовы реальных servlet'ов вместо jsp, ну и mapping, разумеется, тоже прописан. Так вот там mapping jsp'шек которые лежат у меня в /WEB-INF/jspf выглядит в точности так, как у вас в первом случае(что и логично, в принципе) А я совсем забыл про это!..
Сейчас вот только попробовал прописать подобный mapping сервлету — работает!
Для юзеров 404 Not Found, но другими сервлетами инклудится по url-mapping'у легко =)
Незнаю, может быть это и хак, но он ОЧЕНЬ простой и логичный. Это как раз то, что мне нужно
Я вообще бы url mapping в данном случае не использовал и делал бы как и раньше. Просто я не хочу нарушать спецификации. Должен быть стандартный способ сделать то, что я хочу, уверен.
Так же, я не думаю, что сервлеты по-определению все public accessed… В jsp это не так, значит, и в сервлетах должен быть аналогичный способ (и этот способ не фильтр =) )
С фильтрами же смотрите какая ситуация получается… Я создаю сервлет, имеющий, скажем так, public url. А затем создаю фильтр, который, работая перед сервлетом запрещает к нему ход… Это все равно, что я создаю дверь в стене и ставлю перед ней человека, который не разрешает туда заходить… Лучше же не создавать эту дверь! И я не хочу ее создавать… Я хочу инкапсулировать и оставить public servlets и private servlets(forward/include only), вот и все. В jsp это делается… ну, значит, должен быть и способ сделать тоже самое в servlet'ах
Тут дело то в том, что к этим компонетам в принципе пользователю ход закрыт. Тут даже фильтровать нечего — ни при каких обстоятельствах он не должен иметь возможность их вызвать, эти компонеты.
Фильтр же здесь будет работать как заглушка. Это годится, как временное решение. Костыль, если можно так сказать…
Вот я приведу другой, более эффективный способ и вы сможете его сравнить с вашим…
Можно mapping сервлетов просто не прописывать, а при include/forward использовать вот такой вызов:
В таком случае пользователь в принципе не может вызвать этот сервлет, потому что он не привязан к url.
И до недавнего времени я так и делал везде. Но похоже, спецификации требуют, чтобы у сервлетов был mapping к url Поэтому я ищу другой способ.
Тоже вариант, да… Но с точки зрения реализации, я считаю, он неправильный. Вот, к примеру, в JSP(коими суть являются те же сервлеты) есть простой способ ограничить доступ пользователй к jsp-шкам, которые включаются в другие — нужно просто поместить их в директорию /WEB-INF/jspf, например, и до них в принципе не смогут добраться пользователи… В моем случае решается аналогичная проблема, только с сервлетами… Использовать для этого фильтр мне кажется совершенно не верно. Должен быть какой-то другой способ, который предоставляет сам сервлет-контейнер, а не выдумывать что-то самому
Ну так удобнее просто… Если я 100% времени все пишу в IDE'шке, которая весит едва-ли не 250-500Mb оперативной памяти, комбинации клавиш которой уже в подкорке, редактор которой заточен и под SQL файлы тоже и имеет возможность коннектиться к базе, отображать структуру таблиц, подсказывать в редакторе названия таблиц, полей и проч… То, учитывая, все вышесказанное просто глупо использовать для написания SQL-скриптов какую-то стороннюю тулзу, в дополнение к этому монстру
Вообще, интегрированная среда она ведь как раз для того и предназначена, чтобы там делать все вообще имеющее отношение к проекту.
Я ж не голословного говорю. Как только прочитал ваш коммент, так сразу попробовал на своем примере и, к сожалению, полностью это не работает. Только для статики(css,js,img)
В общем я немного разобрался и теперь мне понятно, почему ваш вариант не работает у меня…
Дело в том, что у вас, в случае с php, апач serves(сорри, не знаю как иначе по-русски выразиться) и файлы php тоже. Т.е. он знает, что, к примеру, index.php, main.css, main.js — это все реально существующие в директории htdocs файлы, поэтому он, как вы и говорите, не будет применять правило к ним.
Однако я использую сервлеты. А они не лежат в папке htdocs. И не имеют расширений(это по поводу: RewriteRule ^(^.php)$ $1.php [L,QSA]) Поэтому для апача они не существуют. Да и к тому же физически таких файлов действительно нет, они динамически мапятся с классами .java. Поэтому прежде чем передать такие uri сервлет-контейнеру апач их переписывает согласно правилу, что не правильно.
Тем не менее, спасибо Вам. Вы мне все же помогли.
Глядя на ваш пример у меня появилась одна идея.
Я обновил текст вопроса.
Страницу считывать надо построчно, а не загружать целиком, а потом парсерить… Потому что страницы, в особенности блогов, могут быть просто гиганскими… И 80% из того текста, что будет загружаться — бесполезный. Столкнулся с этим просто уже )