Сервлет входа в систему OpenLaszlo 4.9 DHTML пересылает, но не загружает страницу

В настоящий момент у меня возникают проблемы при использовании LoginServlet OL 4.9 на Tomcat 7.

  • У меня Tomcat настроен так, чтобы crossContext было true, и это позволяет мне работать с другими контекстами приложений на том же сервере. В частности, Login Servlet. Еще одним моим приложением является сервер презентаций OpenLaszlo LPS(lps-4.9.0).
  • Я использую Tomcat Request Filter, который отслеживает входящие адреса и ищет определенный файл cookie для аутентификации, который затем попадает в LoginServlet, который выполняет пересылку на страницу OpenLaszlo. Это было сделано для СОХРАНЕНИЯ файла cookie, когда фильтр запросов был активирован при загрузке страницы OpenLaszlo.

Все это сейчас работает.

  • В файле lps.log или localhost.<date>.log нет ошибок или предупреждений, однако загрузка страницы продолжается бесконечно и никогда не завершается.

Может быть, я что-то передаю в переадресованном URL-адресе? Я использую как минимум 2 параметра, чтобы установить lzr на «dhtml», а затем lzt на «html».

Я даже не могу получить простую <canvas> страницу с простой кнопкой для загрузки. Кто-нибудь видел это и смог решить проблему?

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

Вот сценарий: я использую Tomcat 7 и установил файл WAR для OpenLaszlo 4.9. Наряду с этим я создал иерархию и код LoginServlet, а также файл web.xml прямо в разделе «webapps»; тот же уровень, что установлен lps-4.9.0.

Последовательность событий следующая: 1. Появляется страница входа в систему, которая принимает имя пользователя и пароль и отправляет их в / LoginServlet для обработки. Примечание. Я также написал и зарегистрировал фильтр запросов для Tomcat, который останавливает обход beyone /lps-4.9.0 и проверяет правильность аутентификации, когда я извлекаю файлы cookie из запросов, пытающихся получить доступ к этим уровням. 2. В LoginServlet я создаю MACH COOKIE, который я отправлю вместе с ответом, чтобы фильтр позволил мне пройти уровень /lps-4.9.0. Для этого мне пришлось выполнить операцию FORWARD, чтобы сохранить файл cookie. ПЕРЕНАПРАВЛЕНИЕ просто сбросит их. Поскольку вы не можете указать относительный путь выше корня сервлета, мне пришлось включить функцию «crossContext» Tomcat, которая позволяет мне делать это в том же домене. И я считаю, что оба контекста зарегистрированы в каталоге Tomcat conf в server.xml. Во всяком случае, это работает. Я могу взять контекст /lps-4.9.0, получить диспетчер запросов, а затем использовать этот диспетчер для ПЕРЕДАЧИ пары запрос / ответ в мой файл OpenLaszlo (файл LZX).

Так что, похоже, дошло до ЗАГРУЗКИ страницы OpenLaszlo, но когда я просмотрел сообщения консоли в отладчике Chrome Developer Tools, он показал, что на самом деле он пытался использовать контекст исходного запроса (например, / LoginServlet); и, конечно, этого не существует. Я предполагаю, что когда я передал исходную пару запрос / ответ, запрос использовал ПЕРВЫЙ контекст, а затем попытался получить относительный путь к файлу из этого.

ВОПРОС: Могу ли я просто скопировать материал из исходного запроса, но изменить контекст и переслать ТО?  Или с архитектурной точки зрения попробовать что-нибудь еще?

Спасибо, C


person user3295088    schedule 11.02.2014    source источник


Ответы (1)


И ответ ... ВЫ НЕ МОЖЕТЕ ЭТО СДЕЛАТЬ ... Период.

КСТАТИ. Сервер веб-сайта Openlaszlo DOWN, DEAD, KAPUT, NIX, GONE, НЕТ БОЛЬШЕ ...

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

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

Я почти уверен, что мы, как программисты, не настолько параноики по поводу потери работы, что думаем, что должны тратить много часов НА КОДИРОВАНИЕ интерфейса, чтобы сохранить его в секрете.

Я определенно не параноик по этому поводу. Я знаю, что есть NET BEANS для GUIS типа Swing, и я слышал, что GWT теперь принял нечто подобное, и поэтому я буду продолжать искать это идеальное изобретение и разбираться с тем, что осталось.

Critical Path, должно быть, тоже был куплен кем-то другим, поэтому у спонсора сайта нет мотивации поддерживать его, пока он умирает медленной смертью.

person The J-Man    schedule 14.04.2014