Какие-либо умные способы обработать контекст в веб-приложении?
Когда вы объявляете ссылочную переменную (т. е. объект), вы действительно создаете указатель на объект. Рассмотрим следующий код, в котором вы объявляете переменную примитивного типа int:
int x;
x = 10;
В этом примере переменная x является int, и Java инициализирует ее для 0. Когда вы назначаете его 10 во второй строке, ваше значение 10 записывается в ячейку памяти, на которую указывает x.
Но когда вы пытаетесь объявить ссылочный тип, произойдет что-то другое. Возьмите следующий код:
Integer num;
num = new Integer(10);
Первая строка объявляет переменную с именем num, но она не содержит примитивного значения. Вместо этого он содержит указатель (потому что тип Integer является ссылочным типом). Поскольку вы еще не указали, что указать на Java, он устанавливает значение null, что означает «Я ничего не указываю».
Во второй строке ключевое слово new используется для создания экземпляра (или создания ) объекту типа Integer и переменной указателя num присваивается этот объект. Теперь вы можете ссылаться на объект, используя оператор разыменования . (точка).
Exception, о котором вы просили, возникает, когда вы объявляете переменную, но не создавали объект. Если вы попытаетесь разыменовать num. Перед созданием объекта вы получите NullPointerException. В самых тривиальных случаях компилятор поймает проблему и сообщит вам, что «num не может быть инициализирован», но иногда вы пишете код, который непосредственно не создает объект.
Например, вы можете имеют следующий метод:
public void doSomething(SomeObject obj) {
//do something to obj
}
В этом случае вы не создаете объект obj, скорее предполагая, что он был создан до вызова метода doSomething. К сожалению, этот метод можно вызвать следующим образом:
doSomething(null);
В этом случае obj имеет значение null. Если метод предназначен для того, чтобы что-то сделать для переданного объекта, целесообразно бросить NullPointerException, потому что это ошибка программиста, и программисту понадобится эта информация для целей отладки.
Альтернативно, там могут быть случаи, когда цель метода заключается не только в том, чтобы работать с переданным в объекте, и поэтому нулевой параметр может быть приемлемым. В этом случае вам нужно будет проверить нулевой параметр и вести себя по-другому. Вы также должны объяснить это в документации. Например, doSomething может быть записано как:
/**
* @param obj An optional foo for ____. May be null, in which case
* the result will be ____.
*/
public void doSomething(SomeObject obj) {
if(obj != null) {
//do something
} else {
//do something else
}
}
Наконец, Как определить исключение & amp; причина использования Трассировки стека
10 ответов
Можно использовать JSTL для создания URL.
, Например, <c:url value="/images/header.jpg" /> снабдит префиксом корень контекста.
С CSS, это обычно не проблема для меня.
у меня есть веб-корневая структура как это:
изображения/css
/
В файле CSS, тогда просто необходимо использовать относительные URL (../images/header.jpg), и он не должен знать о корне контекста.
Что касается JavaScript, какие работы для меня включают некоторый общий JavaScript в верхний колонтитул страницы как это:
<script type="text/javascript">
var CONTEXT_ROOT = '<%= request.getContextPath() %>';
</script>
Тогда можно использовать корень контекста во всех сценариях (или, можно определить функцию для создания путей - может быть немного более гибким).
, Очевидно, это все зависит от Вашего использования JSPs и JSTL, но я использую JSF с Facelets, и включенные методы подобны - единственная реальная разница получает корень контекста по-другому.
При создании сайта с нуля, я принимаю сторону @Will - стремятся к последовательной и предсказуемой структуре URL так, чтобы можно было придерживаться относительных ссылок.
, Но вещи может стать действительно грязным, если Вы обновляете сайт, который был первоначально создан для работы непосредственно под корнем сайта "/" (довольно характерный для простых сайтов JSP) к формальному упаковка Java EE (где корень контекста будет некоторым путем под корнем).
, Который может означать много изменений кода.
, Если Вы хотите избежать или отложить изменения кода, но все еще гарантировать корректную корневую ссылку контекста, техника я протестировал, должен использовать фильтры сервлета. Фильтр может быть брошен в существующий proejct, ничего не изменяя (кроме web.xml), и повторно отобразит любые ссылки URL в исходящем HTML к корректному пути, и также гарантирует, что на перенаправления правильно ссылаются.
сайт в качестве примера и применимый код, доступный здесь: EnforceContextRootFilter-1.0-src.zip нбар: фактические правила отображения реализованы как regex в классе сервлета и обеспечивают довольно общее вместилище - но Вы, возможно, должны изменить для конкретных обстоятельств.
btw, я разветвил немного отличающийся вопрос обратиться мигрирующая существующая кодовая база от "/" до некорневого пути контекста
Я никакой средства утверждают, что следующее является изящной проблемой. На самом деле, задним числом, я не рекомендовал бы эту проблему, учитывая (наиболее вероятный) хит производительности.
JSPs Нашего веб-приложения были строго необработанными данными XML. Это, которое необработанные данные были тогда отправлены в XSL (серверная сторона), которая применила правильные теги CSS, и выложил XHTML.
у Нас был единственный template.xsl, который будет наследован несколькими файлами XSL, которые мы имели для различных компонентов веб-сайта. Наши пути были все определены в файле XSL под названием paths.xml:
<?xml version="1.0" encoding="UTF-8"?>
<paths>
<path name="account" parent="home">Account/</path>
<path name="css">css/</path>
<path name="home">servlet/</path>
<path name="icons" parent="images">icons/</path>
<path name="images">images/</path>
<path name="js">js/</path>
</paths>
внутренняя ссылка была бы в XML следующим образом:
<ilink name="link to icons" type="icons">link to icons</ilink>
Это обработать нашим XSL:
<xsl:template match="ilink">
<xsl:variable name="temp">
<xsl:value-of select="$rootpath" />
<xsl:call-template name="paths">
<xsl:with-param name="path-name"><xsl:value-of select="@type" /></xsl:with-param>
</xsl:call-template>
<xsl:value-of select="@file" />
</xsl:variable>
<a href="{$temp}" title="{@name}" ><xsl:value-of select="." /></a>
</xsl:template>
$rootPath был передан на каждый файл с ${applicationScope.contextPath} идея позади нас использующий XML вместо просто жесткого кодирования, которым это в файле JSP/Java было, мы не хотели должными быть перекомпилировать.
Снова, решением не является хорошее вообще..., но мы действительно использовали его однажды!
Редактирование : На самом деле сложность в нашей проблеме возникла, потому что мы не смогли использовать JSPs для нашего всего представления. Почему кто-то только не использовал бы ${applicationScope.contextPath} для получения пути контекста? Это хорошо работало для нас тогда.
Я использовал большинство этих методов (сохраните архитектуру XSLT).
я думаю, что затруднение (и согласие) проблемы имеет сайт с потенциально несколькими каталогами.
, Если Ваша глубина каталога (из-за отсутствия лучшего термина) является постоянной, то можно полагаться на относительные URL в вещах как CSS.
Мышление, расположение не должно быть абсолютно плоским, просто последовательным.
, Например, мы сделали иерархии как/css,/js, / распространенный, / администратор, / пользователь. Помещение соответствующих страниц и ресурсов в надлежащих каталогах. Наличие структуры как это работает очень хорошо с основанной на контейнере аутентификацией.
я также отобразил *.css и *.js к сервлету JSP, и сделал их динамичными, таким образом, я могу создать их на лету.
я просто надеялся, что было что-то еще, что я, возможно, пропустил.
За исключением особых случаев, я рекомендовал бы против использования абсолютных URL этот путь. Когда-либо. Абсолютные URL хороши для того, когда другое веб-приложение указывает на что-то в Вашем веб-приложении. Внутренне - когда один ресурс указывает на второй ресурс в том же контексте - ресурс должен знать, где это живет, таким образом, это должно быть в состоянии выразить относительный путь второму ресурсу.
, Конечно, Вы запишете модульные компоненты, которые не знают ресурс, это включает их. Например:
/myapp/user/email.jsp:
Email: <a href="../sendmail.jsp">${user.email}</a>
/myapp/browse/profile.jsp:
<jsp:include page="../user/email.jsp" />
/myapp/home.jsp:
<jsp:include page="../user/email.jsp" />
Так, как делает email.jsp, знают относительный путь sendmail.jsp? Очевидно ссылка повредится или на /myapp/browse/profile.jsp, или она повредится на /myapp/home.jsp. Ответ, сохраните все свои URL в том же плоском пространстве filepath. Таким образом, каждый URL не должен иметь никаких наклонных черт после /myapp/.
Это довольно легко выполнить, пока у Вас есть некоторое отображение между URL и фактическими файлами, которые генерируют содержание. (например, в Spring, используйте DispatcherServlet для отображения URL на файлы JSP или на представления.)
существуют особые случаи. например, если Вы пишете приложение стороны браузера в JavaScript, тогда становится более трудным поддержать плоское пространство filepath. В этом случае, или в других особых случаях, или просто если у Вас есть персональное предпочтение, это не действительно грандиозное предприятие использовать <%= request.getContextPath() %> для создания полного пути.
Можно использовать request.getContextPath () для создания абсолютных URL, которые не трудно кодируются к определенному контексту. Как более ранний обозначенный ответ, для JavaScript Вы просто устанавливаете переменную наверху своего JSP (или предпочтительно в шаблоне) и префикс что как контекст.
, Который не работает на замену изображения CSS, если Вы не хотите динамично генерировать файл CSS, который может вызвать другие проблемы. Но так как Вы знаете, где Ваш файл CSS относительно Ваших изображений, можно сойти с рук относительные URL.
По некоторым причинам, я испытал затруднения из-за IE, обрабатывающего относительные URL, и должен был отступить к использованию выражений с набором переменной JavaScript к контексту. Я просто отколол свои замены изображения IE в их собственный файл и использовал макросы IE для получения по запросу в корректных. Это не было грандиозное предприятие, потому что я уже должен был сделать это для контакта с прозрачным PNGs так или иначе. Это не симпатично, но это работает.
Одна опция состоит в том, чтобы использовать "плоскую" структуру приложения и относительные URL, когда это возможно.
"плоским" я подразумеваю, что нет никаких подкаталогов под Вашим корневым каталогом приложения, возможно, только немного каталогов для статического содержания как "изображения /". Весь Ваш JSP's, URL действия, сервлеты идут непосредственно под корнем.
Это не полностью решает Вашу проблему, но упрощает ее значительно.
Я использовал классы помощника для генерации тегов img и т.д. Этот класс помощника заботится о пути добавления префикса с contextPath приложения. (Это работает, но мне действительно не нравится он. Если у кого-либо есть какие-либо лучшие альтернативы, скажите.)
Для путей в css файлах и т.д. Я использую сценарий сборки Муравья, который использует site.production.css для site.css в продуктивной среде и site.development.css в разработке encironment.
, Кроме того, я иногда использую скрипт Ant что замены @token маркеры с надлежащими данными для различного environents. В этом случае @contextPAth маркер был бы заменен корректным путем контекста.
API Сервлета и JSP имеют средства, чтобы помочь управлять этим. Например, если, в сервлете, Вы делаете: response.sendRedirect ("/mypage.jsp"), контейнер будет предварительно ожидать контекст и создавать URL: http://example.com/myapp/mypage.jsp ".
А-ч, возможно, возможно, не - это зависит от Вашего контейнера и спецификации сервлета!
От Сервлет 2.3: Новые возможности представили :
И наконец, после долгих дебатов группой экспертов, сервлет API 2.3 разъяснил раз и навсегда точно, что происходит на res.sendRedirect ("/index.html"), призывают к сервлету, выполняющемуся в некорневом контексте. Проблема - то, что сервлет API 2.2 требует, чтобы неполный путь как "/index.html" был переведен контейнером сервлета в полный путь, но не говорит, как обрабатываются пути контекста. Если сервлет, выполняющий вызов, находится в контексте в пути "/contextpath", URI перенаправления должен перевести относительно контейнерного корня ( http://server:port/index.html ) или корня контекста ( http://server:port/contextpath/index.html )? Для максимальной мобильности обязательно определить поведение; после долгих дебатов эксперты приняли решение перевести относительно контейнерного корня. Для тех, кто хочет контекстно-зависимый, можно предварительно ожидать вывод от getContextPath () к URI.
Так не, с 2,3 Вашими путями не автоматически переведены для включения пути контекста.
Vilmantas сказал правильное слово здесь: относительные URL.
Все, что необходимо сделать в IMG, должно использовать
<img src="myimage.gif"/>
вместо
<img src="/myimage.gif"/>
, и это будет относительно контекста приложения (поскольку браузер интерпретирует URL для движения в)