Вопросы Теги

svn: замените соединительную линию ответвлением

Существует три основные причины.

  1. FacesServlet не вызывается.
  2. Недопустимые URI пространства имен XML.
  3. Несколько JSF были загружены.

1. Убедитесь, что URL-адрес соответствует FacesServlet mapping

. URL-адрес ссылки (URL-адрес, который вы видите в адресной строке браузера) должен соответствовать файла FacesServlet, как определено в web.xml чтобы все работы JSF выполнялись. FacesServlet - это тот, который отвечает за разбор файла XHTML, сбор представленных значений формы, выполнение преобразования / проверки, обновление моделей, вызывание действий и создание выходных данных HTML. Если вы не вызываете FacesServlet по URL-адресу, то все, что вы получили (и увидите через rightclick, View Source в браузере), действительно является исходным исходным кодом XHTML.

Если , например, *.jsf, ссылка должна указывать на /register.jsf, а не на /register.xhtml. Если это, например, /faces/*, как и у вас, ссылка должна указывать на /faces/register.xhtml, а не на /register.xhtml. Один из способов избежать этой путаницы - просто изменить с /faces/* на *.xhtml. Таким образом, нижестоящее является идеальным отображением: 


    facesServlet
    javax.faces.webapp.FacesServlet


    facesServlet
    *.xhtml

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


    Restrict direct access to XHTML files
    
        XHTML files
        *.xhtml

Предстоящий JSF 2.3 решит все из вышеперечисленного, автоматически регистрируя FacesServlet в шаблоне URL-адреса *.xhtml во время запуска webapp.

См. также:

2. Убедитесь, что пространства имен XML соответствуют версии JSF

. С введением JSF 2.2 еще одна вероятная причина заключается в том, что пространства имен XML не соответствуют версии JSF. xmlns.jcp.org, как показано ниже, является новым с JSF 2.2 и не работает в старых версиях JSF. Символы почти такие же, как если бы FacesServlet не вызывался.

Если вы не можете перейти на JSF 2.2, вам нужно вместо этого использовать старые пространства имен java.sun.com XML:

См. также:

3. Было загружено несколько реализаций JSF

. Еще одна вероятная причина заключается в том, что несколько реализаций JSF были загружены вашим webapp, конфликтуя и разлагая друг друга. Например, когда ваш путь к классу среды выполнения Webapp загрязнен несколькими различными версиями JSF-библиотек или в конкретной комбинации Mojarra 2.x + Tomcat 8.x, когда в файле web.xml веб-приложения есть ненужная запись ConfigureListener, вызывающая ее загрузку дважды. 





    com.sun.faces.config.ConfigureListener

При использовании Maven убедитесь, что вы правильно определяете зависимости и понимаете области зависимостей. Важно: не связывайте зависимости в webapp, если они уже предоставлены целевым сервером.

См. Также:

Убедитесь, что вы учитесь JSF правильный путь

JSF имеет очень крутую кривую обучения для тех, кто не знаком с базовыми HTTP , HTML и сервлетами . В Интернете много ресурсов низкого качества. Пожалуйста, игнорируйте фрагменты скриншотов кода, поддерживаемые любителями, в основном ориентированные на доход от рекламы, а не на обучение, такие как розы, учебник, javabeat и т. Д. Они легко узнаваемы, нарушая рекламные ссылки / баннеры. Также, пожалуйста, игнорируйте ресурсы, связанные с юрским JSF 1.x. Они легко узнаваемы с помощью JSP-файлов вместо файлов XHTML. JSP как технология просмотра устарела с тех пор, как JSF 2.0 уже в 2009 году.

Чтобы начать правильно, начните с нашей вики-страницы JSF и закажите авторитетную книгу .

См. также:

151
задан Jacco 8 October 2009 в 14:49
поделиться

6 ответов

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

Примечание, которые копируют и перемещаются в работу svn как операции файла. Можно использовать их для перемещений/копирования материала вокруг в репозиторий, и эти изменения являются имеющими версию также. Думайте о "перемещении" как "copy+delete".

[РЕДАКТИРОВАНИЕ] Nilbus просто уведомил меня, что Вы получите конфликты слияния, когда Вы будете использовать svn move.

я все еще думаю, что это - корректный подход. Это вызовет конфликты, но если Вы объединяетесь тщательно, возможности состоят в том, что Вы не потеряете данных. Если это беспокоит Вас, используйте лучший VCS как Подвижный или Мерзавец .

117
ответ дан Ray Koren 23 November 2019 в 22:16
поделиться

Я соглашаюсь с использованием команды перемещения svn для выполнения этой цели.

я знаю, что другие здесь думают его необычное, но мне нравится делать это этот путь. Когда у меня есть ответвление функции, и готово объединить его с соединительной линией, которая имеет также быть значительно измененной, я объединю его с новым ответвлением, обычно называемым <FeatureBranchName>-Merged. Тогда я разрешаю конфликты и тестирую объединенный код. Как только это завершено, я перемещаю соединительную линию в папку тегов, таким образом, я ничего не теряю. Наконец я перемещаю мой <FeatureBranchName>-Merged в соединительную линию.

, Кроме того, я предпочитаю избегать рабочей копии при выполнении перемещений вот образцы команд: 

svn move https://SVNUrl/svn/Repo/trunk https://SVNUrl/svn/Repo/tags/AnyName

svn move https://SVNUrl/svn/Repo/branches/BranchName-Merged https://SVNUrl/svn/Repo/trunk

Примечание: Я использую 1.5

66
ответ дан dantiston 23 November 2019 в 22:16
поделиться

Рекомендуйте сделать эти изменения через инструмент браузера репозитория.

Пытающиеся большие delete+move операции с помощью рабочей копии отличный способ уничтожить рабочую копию. Если Вы вынуждены использовать рабочую копию, выполнить возрастающие фиксации после того, как каждый удалит или операция пересылки и ОБНОВИТ Вашу рабочую копию после каждой фиксации.

9
ответ дан Chris Nava 23 November 2019 в 22:16
поделиться

@Aaron Digulla и @kementeus решения осуществимы. Для Подрывной деятельности 1,4 репозитория копия/операции пересылки может сделать будущую миграцию к различной структуре репозитория или репозиториям разделения трудной.

я верю 1.5's, улучшения включают лучшее разрешение истории перемещения/копии, таким образом, это, вероятно, не была бы проблема для 1,5 репозиториев.

Для 1,4 репозиториев, я рекомендовал бы использовать svnadmin dump и svndumpfilter для выполнения перемещения существующей соединительной линии в другом месте, затем переместив ответвление в соединительную линию с тем же механизмом. Загрузите два dumpfiles в тестовый репозиторий, проверьте, затем переместите его в производство.

, Конечно, скопируйте свой существующий репозиторий перед запуском.

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

<час>

Редактирование: Согласно просьбе, документация 1,4 поведений, из 1.4 книг Из красной фасоли, История Репозитория Фильтрации

кроме того, скопированные пути могут дать Вам некоторую проблему. Подрывная деятельность поддерживает операции копии в репозитории, где новый путь уже создается путем копирования некоторых существующий путь. Возможно, что в какой-то момент во время жизни Вашего репозитория, Вы, возможно, скопировали файл или каталог с некоторого местоположения, которое svndumpfilter исключает к местоположению, которое это включительно Для создания автономной системы данных дампа, svndumpfilter потребности все еще показать добавление нового path— включая содержание любых файлов, созданных copy— и не представить, что дополнение как копия с источника, который не будет существовать в фильтрованном потоке данных дампа. Но потому что формат дампа репозитория Подрывной деятельности только показывает то, что было изменено в каждом пересмотре, содержание источника копии не могло бы быть легко доступным. Если Вы подозреваете, что у Вас есть любые копии этого вида в Вашем репозитории, Вы могли бы хотеть заново обдумать, Ваш набор включал/исключал пути, возможно, включая пути, которые служили источниками Ваших неприятных операций копии, также.

Это относится к миграциям/перестройкам с помощью svndumpfilter. Существуют времена, когда немного дополнительной работы теперь может сохранить большую дополнительную работу позже, и путем сохранения легкого использования svndumpfilter доступным для будущих миграций/перестроек снижает риск по относительно низкой цене.

3
ответ дан Ken Gentle 23 November 2019 в 22:16
поделиться

В то время как ответы выше будут работать, они не лучшая практика. Последний svn сервер и клиент отслеживают слияния для Вас. Таким образом, svn знает, какие изменения Вы объединили в ответвление и от где. Это помогает много при совершенствовании ответвления и затем слиянии его назад в соединительную линию.

, Неважно, какую версию Подверсии Вы используете однако, существует метод лучшей практики для получения изменений в ответвлении назад в соединительную линию. Это обрисовано в общих чертах в руководстве Подверсии: Управление версиями с Подверсией, Главой 4. Ветвление и Слияние, Сохраняя Ответвление в Синхронизации .

2
ответ дан 23 November 2019 в 22:16
поделиться

Это - действительно странная/необычная конфигурация в SVN, даже я думаю, что это далеко от того, чтобы быть "хорошей практикой" вообще, так или иначе, я предполагаю, что Вы могли сделать что-то как:

  • Контроль все sourcetree (svn co therootsourcetree)
  • Удаляют соединительную линию (svn соединительная линия комнаты)
  • Копия, ответвление к соединительной линии (svn CP branches/thebranch / соединительная линия)
  • Удаляет ответвление (svn комната branches/thebranch)
  • Фиксация изменения

Удача

-3
ответ дан kementeus 23 November 2019 в 22:16
поделиться
Другие вопросы по тегам:

Похожие вопросы: