cancel
Showing results for 
Search instead for 
Did you mean: 

PageLookup fails

sam1980
Champ in-the-making
Champ in-the-making
I've encountered a problem when deploying my wqs-based webapp to WebLogic 10.3.5. All of a sudden the page lookup mechanism fails. The only other reference I found to this problem is in this spanish forum post: https://forums.alfresco.com/es/viewtopic.php?f=11&t=3634 which also encounted the problem in an Tomcat setup. I've tested my webapp in both Tomcat and Glassfish, and it works fine there.

These are the related codelines in org.alfresco.wcm.client.viewresolver.DynamicPageViewResolver:90

            Page page = lookupPage(template);
//this returns null - hence the exception is thrown
            if (page == null)
            {
                throw new EditorialException("Invalid template page \"" + template + "\" specified for "
                        + asset.getContainingSection().getPath() + asset.getName(), "template.none", asset
                        .getContainingSection().getPath()
                        + asset.getName() + asset.getName());
            }

I am a bit in the dark here, and i post this in hope that someone could provide me with some pointers. Seems like some of the *Persisters has not loaded the webapps pages properly (classpath problem?), but I am not sure where the wiring of this happens.

Grateful for any advice.

Relevant stack trace:
org.alfresco.wcm.client.exception.EditorialException: Invalid template page "homepage" specified for /index.html
        at org.alfresco.wcm.client.viewresolver.DynamicPageViewResolver.buildView(DynamicPageViewResolver.java:90)
        at org.springframework.web.servlet.view.UrlBasedViewResolver.loadView(UrlBasedViewResolver.java:419)
        at org.springframework.web.servlet.view.AbstractCachingViewResolver.createView(AbstractCachingViewResolver.java:158)
        at org.springframework.web.servlet.view.UrlBasedViewResolver.createView(UrlBasedViewResolver.java:384)
        at org.springframework.web.servlet.view.AbstractCachingViewResolver.resolveViewName(AbstractCachingViewResolver.java:69)
        at org.springframework.web.servlet.DispatcherServlet.resolveViewName(DispatcherServlet.java:1091)
        at org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1040)
        at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:798)
        at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:716)
        at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:647)
        at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:552)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
5 REPLIES 5

bremmington
Champ on-the-rise
Champ on-the-rise
Are you deploying your app as a WAR file?

sam1980
Champ in-the-making
Champ in-the-making
Yes, as a WAR

bremmington
Champ on-the-rise
Champ on-the-rise
Hmm. OK. I've seen some similar kinds of issues when deploying as an exploded WAR in JBoss, but not as a WAR.

I'm not sure why that may be happening in WebLogic - it's been a while since I've used WebLogic. I'll ask around here to see if anyone has any ideas. I know that Share works in WebLogic, so it must be achievable.

ddraper
World-Class Innovator
World-Class Innovator
If the exactly the same application works on other app servers, and the pages should ultimately be loaded from ClassPathStores (which they almost certainly are) then it's almost certainly a classpath configuration problem with WebLogic. Unfortunately I don't know anything about configuring WebLogic nor very much about WQS (although I know about Spring Surf) but I'm guessing you might need to explicitly configure the Classpath access for the application (?)

You shouldn't need to re-configure the Spring application context that defines the Surf object stores that are used to look up the pages if they are working on other app servers. It doesn't look like the default WQS application overrides any of the Spring Surf defaults. The object stores/persister configuration is quite complex and scattered across several Spring application context configuration files in the Spring Surf and Spring WebScripts JAR files… they in the "org.springframework.extensions.webscripts." and "org.springframework.extensions.surf." packages. There is also an "autowire" service which updates some of the persistence/object store configuration… however, as I said - if it's working on other app servers you really shouldn't need to touch any of that.  However, it might be useful as reference for working out how configure your applications Classpath in WebLogic.

Hope this helps, apologies if it's a bit vague but the best I can do without deep WebLogic or WQS knowledge,

Regards,
Dave

sam1980
Champ in-the-making
Champ in-the-making
Thanks for your feedback.

It sure was a classpath problem. The workaround involved reorganising the web app folder strukture in order for surf to pick up the correct places to look for pages, templates and webscripts.

Old:

WEB-INF
—- pages
—- templates
—- webscripts

New:

WEB-INF
—- classes
——– surf
———— site       
—————– templates\*.xml
—————– pages
———— templates\*.flt
———— webscripts

Not the most elegant solution, but feasible workaround. We'll just make our own weblogic profile in our maven build that takes care of the reorganizing parts.

For future reference this might be related: http://forum.springsource.org/showthread.php?86713-Surf-autowire-runtime .