2015-01-12 2 views
0

У меня возникла проблема, когда я развертываю войну проекта grails (2.4.0) в weblogic 12.1.2. Война прекрасно работает при развертывании в кота. Проблема заключается в том, когда война развертывается в weblogic. Как только пользователь входит в систему, процесс аутентификации с использованием LDAP также отлично работает. Затем главная страница должна быть отображена с помощью страницы GSP, но, похоже, weblogic не может отобразить страницу GSP. Он бросает 404 в браузер.Грааля не может отобразить GSP при развертывании в weblogic

Как только я войду в приложение, если я прямо использую любой URL-адрес в браузере, поток переходит к контроллеру и выполняет все требуемое выполнение кода в контроллере, но он не может вернуться к просмотру и отображению GSP страница, упомянутая в блоке «render».

код действия My Controller, как показано ниже:

def index(){ 
    log.debug("**********Reached MyHomeController**********") 
    MyHome myHome = new MyHome() 
    myHome.setMessageId(1) 
    myHome.setMessageText("***TEST MESSAGE***") 

    render (view: 'myhome') 
} 

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

def index(){ 
    log.debug("**********Reached MyHomeController.testCall**********") 
    render ("*@***Reached MyHomeController.testCall**********") 
} 

Я проверил WebLogic проблемы в Grails месте ([здесь] [1]) и сделали средства правовой защиты, указанные там. Но я думаю, что проблема заключается в том, что запросы передаются правильному контроллеру, но, возвращаясь к пользовательскому интерфейсу, weblogic не может найти GSP (там, где у tomcat нет проблем с ним).

Помогите нам решить, как сделать рендеринг GSP при развертывании в weblogic. Ниже приведено исключение в журнале, когда weblogic выбрасывает 404 в браузере: Не знаете, почему он пытается найти файл * .jsp.

: MyHomeController - ********** ********** Достигнута MyHomeController ::: [2c5cb87d-29ad-4006-8294-4a1f355e124e] [Lokajit_Tikayatray]: OptimizedAutowireCapableBeanFactory - Возвращаемый кешированный экземпляр одноэлементного bean 'groovyPagesUriService' ::: [2c5cb87d-29ad-4006-8294-4a1f355e124e] [Lokajit_Tikayatray]: AbstractGrailsControllerHelper - действие [testCall1] выполнено с результатом [null] и именем вида [/ myHome/index] ::: [2c5cb87d-29ad-4006-8294-4a1f355e124e] [Lokajit_Tikayatray]: AbstractGrailsControllerHelper - действие [testCall1] обработано, создана модель Spring и вид [ModelAndView: ссылка на просмотр с именем/myHome/myhome '; model is {}] ::: [2c5cb87d-29ad-4006-8294-4a1f355e124e] [Lokajit_Tikayatray]: SimpleGrailsController - [SimpleGrailsController] Экспериментальная модель и вид [ModelAndView: ссылка на просмотр с именем/myHome/myhome '; модель {}] с классом [/ MYHOME/MyHome] ::: [2c5cb87d-29ad-4006-8294-4a1f355e124e] [Lokajit_Tikayatray]: CompositeInterceptor - postHandle SecurityContextHolderAwareRequestWrapper [org.springframework.security.web.context.HttpSessionSecurityContextRepository $ Servlet3SaveToSessionRequestWrapper @ 320c8103], org.springframework.security.web.context.Ht[email protected]52ea05a0, or[email protected]4720353f, ModelAndView: ссылка на просмотр с именем '/ myHome/myhome «; model is {} ::: [2c5cb87d-29ad-4006-8294-4a1f355e124e] [Lokajit_Tikayatray]: GrailsDispatcherServlet - просмотр рендеринга [org.codehaus.groovy.grails.web.sitemesh.SitemeshLayoutView: unnamed; URL [null]] в DispatcherServlet с именем «grails» ::: [2c5cb87d-29ad-4006-8294-4a1f355e124e] [Lokajit_Tikayatray]: JstlView - переадресация на ресурс [/ WEB-INF/grails-app/views/myHome /myhome.jsp] in InternalResourceView 'null' ::: [2c5cb87d-29ad-4006-8294-4a1f355e124e] [Lokajit_Tikayatray]: GrailsDispatcherServlet - просмотр рендеринга ошибок [org.codehaus.groovy.grails.web.sitemesh.SitemeshLayoutView: неназванный; URL [null]] в DispatcherServlet с именем 'grails' java.lang.NullPointerException в weblogic.servlet.internal.StubSecurityHelper $ ServletServiceAction.run (StubSecurityHelper.java:280) в weblogic.servlet.internal.StubSecurityHelper $ ServletServiceAction.run (StubSecurityHelper.java:254) в weblogic.servlet.internal.StubSecurityHelper .invokeServlet (StubSecurityHelper.java:136) на weblogic.servlet.internal.ServletStubImpl.execute (ServletStubImpl.java:341) на weblogic.servlet.internal.TailFilter.doFilter (TailFilter.java:25) в weblogic.servlet .internal.FilterChainImpl.doFilter (FilterChainImpl.java:79) на weblogic.servlet.internal.FilterChainImpl.doFilter (FilterChainImpl.java:79) на weblogic.servlet.internal.FilterChainImpl.doFilter (FilterChainImpl.java:79) в weblogic.servlet.internal.FilterChainImpl.doFilter (FilterChainImpl.java:79) на weblogic.servlet.internal.RequestDispatcherImpl.invokeServlet (RequestDispatcherImpl.java:574) на weblogic.servlet.internal.RequestDispatcherImpl.forward (RequestDispatcherImpl.java: 272) в weblogic.servlet.internal.FilterChainImpl.doFilter (FilterChainImpl.java:79) в grails.plugin.springsecurity.web.filter.GrailsAnonymousAuthenticationFilter.doFilter (GrailsAnonymousAuthenticationFilter.java:53) в grails.plugin.springsecurity. web.authentication.RequestHolderAuthenticationFilter.doFilter (RequestHolderAuthenticationFilter.java:49) at grails.plugin.springsecurity.web.authentication.logout.MutableLogoutFilter.doFilter (MutableLogoutFilter.java:82) at weblogic.servlet.internal.FilterChai nImpl.doFilter (FilterChainImpl.java:79) на weblogic.servlet.internal.FilterChainImpl.doFilter (FilterChainImpl.java:79) на weblogic.servlet.internal.FilterChainImpl.doFilter (FilterChainImpl.java:79) на WebLogic. servlet.internal.FilterChainImpl.doFilter (FilterChainImpl.java:79) в weblogic.servlet.internal.WebAppServletContext $ ServletInvocationAction.wrapRun (WebAppServletContext.java:3367) в weblogic.servlet.internal.WebAppServletContext $ ServletInvocationAction.run (WebAppServletContext. java: 3333) at weblogic.security.acl.internal.AuthenticatedSubject.doAs (AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs (SecurityManager.java:120) на weblogic.servlet.provider. WlsSubjectHandle.run (WlsSubjectHandle. Java: 57) в weblogic.servlet.internal.WebAppServletContext.doSecuredExecute (WebAppServletContext.java:2220) на weblogic.servlet.internal.WebAppServletContext.securedExecute (WebAppServletContext.java:2146) на weblogic.servlet.internal.WebAppServletContext. выполнить (WebAppServletContext.java:2124) в weblogic.servlet.internal.ServletRequestImpl.run (ServletRequestImpl.java:1564) в weblogic.servlet.provider.ContainerSupportProviderImpl $ WlsRequestExecutor.run (ContainerSupportProviderImpl.java:254) в WebLogic. work.ExecuteThread.execute (ExecuteThread.java:295) at weblogic.work.ExecuteThread.run (ExecuteThread.java:254)

+0

Поскольку Grails поддерживает как GSP, так и JSP, если данный .gsp не найден, grails пытается найти файл jsp с тем же именем в той же папке. Вот почему ошибка выше дает, наконец, JSP не найдена ошибка. Я добавил jsp с таким же именем в данной папке, чтобы посмотреть, можно ли получить доступ к нему, но по-прежнему та же ошибка, то есть не удается найти файл в данном месте по weblogic. происходит нечто сверхъестественное: - // –

ответ

0

Наконец, развертывание выполнено w ith weblogic с правильной навигацией с одной страницы на другую. Проблема заключалась в соглашении об именах для папок вида. Кажется, weblogic нуждается в имени папки просмотра точно так же (с учетом регистра), как URL-адрес, сгенерированный каркасом.

журнал напечатал:
Forwarding на ресурс [/ WEB-INF/Grails-приложение/мнения/MYHOME /myhome.jsp]

Итак, WebLogic пытался найти файле 'MyHome' GSP внутри «my H ome» (с H в столице), но все мои имена папок списка были в нижнем регистре. Следовательно, weblogic не смог найти GSP в URL-адресе.Даже когда я скопировал аналогичный JSP на нужный путь, он все равно не смог его найти. Получив подсказку из журнала, я изменил имена своих имен в том же случае, что и URL, и он работал нормально. :)

То же самое не имеет место с Tomcat. Tomcat не использует URL как чувствительный к регистру. Он может найти путь URL в любом случае. Вот почему мое приложение отлично работало с tomcat, даже когда URL был/my H ome/**, но мое имя папки просмотра было 'my h ome'. Поскольку tomcat смог правильно идентифицировать URL-адрес, поэтому мне не удавалось обнаружить, что weblogic будет проводить поиск по URL-адресу, чувствительный к регистру (до тех пор, пока не исчерпываются все возможные варианты устранения проблемы :)).

Смежные вопросы