Spring Boot + JSF 2.2 + PrettyFaces | Failing to get @URLMapping to function.

Splash Forums PrettyFaces Users Spring Boot + JSF 2.2 + PrettyFaces | Failing to get @URLMapping to function.

This topic contains 9 replies, has 3 voices, and was last updated by  Christian Kaltepoth 5 months, 2 weeks ago.

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #26605

    Meister
    Participant

    Summary:
    When I turn on my Spring Boot application. (Running on the embedded Tomcat 8 server) I never receive the:

    INFO  [org.ocpsoft.rewrite.servlet.RewriteFilter] RewriteFilter starting up...
    ...
    INFO  [org.ocpsoft.rewrite.servlet.RewriteFilter] Loaded [] org.ocpsoft.rewrite.config.ConfigurationProvider [org.ocpsoft.rewrite.prettyfaces.PrettyFacesRewriteConfigurationProvider<1>]
    INFO  [org.ocpsoft.rewrite.servlet.RewriteFilter] RewriteFilter initialized.

    Log notifications. For some reason PrettyFaces isn’t starting up, and I don’t know why.

    Technologies: Spring Boot 1.2.0.RELEASE, Java 8, Maven for dependency management. Embedded Tomcat 8.0.15 Server.

    Focusing on Java Configuration as much as possible. Previously I tried to use Rewrite, but it gave me an equal amount of gruff. Feel like I’m missing something obvious.

    Here’s a link to my current code base. (It’s pretty small, just working on the foundation for a new project, nothing major implemented yet.)

    https://github.com/MeisterGit/FoundationServer

    Maven Dependency:

    <dependency>
    	<groupId>com.ocpsoft</groupId>
    	<artifactId>prettyfaces-jsf2</artifactId>
    	<version>3.3.3</version>
    </dependency>

    Other Maven Dependency Tried:

    <!-- PrettyFaces -->
    <dependency>
        <groupId>org.ocpsoft.rewrite</groupId>
        <artifactId>rewrite-servlet</artifactId>
        <version>2.0.12.Final</version>
    </dependency>
    <dependency>
        <groupId>org.ocpsoft.rewrite</groupId>
        <artifactId>rewrite-config-prettyfaces</artifactId>
        <version>2.0.12.Final</version>
    </dependency>
    

    Both version yield the same result. No startup messages.

    I’m trying to keep XML to an absolute minimum. I have faces-config set up with:

    <faces-config xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"             
    			xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd"
    			version="2.2">
    		
    		<!-- Allow Spring Beans to be accessible to JSF. -->
            <application>
                <el-resolver>org.springframework.web.jsf.el.SpringBeanFacesELResolver</el-resolver>
            </application>
    </faces-config>

    and my controller is topped by:

    @Controller
    @URLMapping(id = UserController.INDEX,
    			pattern = "/",
    			viewId = "/content/index.xhtml") // Home page.

    Here’s my web.xml

    <?xml version="1.0" encoding="UTF-8"?>
    <web-app xmlns="http://java.sun.com/xml/ns/javaee"
    		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    		 xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
    		id="foundation-server"
    		version="3.1">
    	
    	<!-- PrettyFaces: Specify which package to scan for @UrlMapping annotations -->	
    	<context-param>
    	   <param-name>com.ocpsoft.pretty.BASE_PACKAGES</param-name>
    	   <param-value>foundation</param-value>
    	</context-param>
    	
    	<!--  No Pretty Filter required, servlet 3.0+ automatically registers the filter. -->
    	<filter-mapping>
    		<filter-name>springSecurityFilterChain</filter-name>
    		<url-pattern>/*</url-pattern>
    		<dispatcher>FORWARD</dispatcher>
    		<dispatcher>REQUEST</dispatcher>
    	</filter-mapping>
    </web-app>

    Any help on what I’m doing wrong? The server turns on, I can hit http://localhost:8080/content/index.xhtml just fine, and the JSF template loads. The Spring Bean backs it up. . . But no URL mapping is functioning. If I hit http://localhost:8080/ I just get an error.

    • This topic was modified 1 year, 7 months ago by  Meister.
    • This topic was modified 1 year, 7 months ago by  Meister.
    • This topic was modified 1 year, 7 months ago by  Meister.
    • This topic was modified 1 year, 7 months ago by  Meister.
    • This topic was modified 1 year, 7 months ago by  Meister.
    • This topic was modified 1 year, 7 months ago by  Meister.
    #26615

    Try to manually register the required filter in your web.xml. Perhaps Spring Boot doesn’t pick up web-fragment.xml files?

    #26617

    Meister
    Participant

    Turns out that Spring Boot completely ignores web.xml and web-fragment.xml.

    Adding this got PrettyFaces to turn on (and print startup info):

    @Configuration
    public class PrettyConfig
    {
    	@Bean
    	public FilterRegistrationBean prettyFilter() {
    	    FilterRegistrationBean prettyFilter = new FilterRegistrationBean(new RewriteFilter());
    	    prettyFilter.setDispatcherTypes(DispatcherType.FORWARD, DispatcherType.REQUEST,
    	            DispatcherType.ASYNC, DispatcherType.ERROR);
    	    prettyFilter.addUrlPatterns("/*");
    	    
    	    return prettyFilter;
    	}
    }

    But PrettyFaces is still not hitting @URLMapping mapped functions on my controller. Seems to me that maybe the BASE_PACKAGES parameter isn’t getting processed. Thoughts? In this case I’m trying to configure Spring Boot’s embedded Tomcat server.

    I found this: http://docs.spring.io/spring-boot/docs/current/reference/html/common-application-properties.html

    Which seems to imply something like:
    server.context-parameters.com.ocpsoft.pretty.BASE_PACKAGES=foundation

    Would work to set what web.xml described with the context-param . . . But even with this specified my @URLMapping is still not functioning.

    My repository on Github has been updated to match my current state.

    • This reply was modified 1 year, 7 months ago by  Meister.
    • This reply was modified 1 year, 7 months ago by  Meister.
    • This reply was modified 1 year, 7 months ago by  Meister.
    #26625

    Meister
    Participant

    This is my current Rewrite loading printout: Seems to end with an issue in loading classes. I figure the class issue is why my URLMappings aren’t being found.

    ...
    2014-12-16 14:14:17.817  WARN 11212 --- [ost-startStop-1] unknown.jul.logger  : Cannot find classes folder: /WEB-INF/classes/
    2014-12-16 14:14:17.818  WARN 11212 --- [ost-startStop-1] unknown.jul.logger  : Cannot find classes folder: /WEB-INF/classes/
    2014-12-16 14:14:17.819  INFO 11212 --- [ost-startStop-1] unknown.jul.logger  : Rewrite 2.0.12.Final initialized.

    To remove these warnings, I adjusted my Java Build Path to write class files into my WEB-INF/classes folder (instead of the old default target/ folder)

    Warnings are gone now, but my @URLMapping is still not functioning. My goodness.

    Edit: Just updated my repository again. Since web.xml is now serving no purpose in my project whatsoever, and isn’t read, I removed it. Still hoping for a bit of insight on what is going wrong.

    • This reply was modified 1 year, 7 months ago by  Meister.
    • This reply was modified 1 year, 7 months ago by  Meister.
    • This reply was modified 1 year, 7 months ago by  Meister.
    • This reply was modified 1 year, 7 months ago by  Meister.
    #26630

    Meister
    Participant

    Edit: Switching dependencies and moving my build path to WEB-INF/classes allowed @URLMapping to function, but now I have to run: mvn clean install after every code change to run the new version, instead of automatically building like before. Ack.

    Switching back from:

    <!-- PrettyFaces -->
    <dependency>
        <groupId>org.ocpsoft.rewrite</groupId>
        <artifactId>rewrite-servlet</artifactId>
        <version>2.0.12.Final</version>
    </dependency>
    <dependency>
        <groupId>org.ocpsoft.rewrite</groupId>
        <artifactId>rewrite-config-prettyfaces</artifactId>
        <version>2.0.12.Final</version>
    </dependency>

    To:

    <dependency>
    	<groupId>com.ocpsoft</groupId>
    	<artifactId>prettyfaces-jsf2</artifactId>
    	<version>3.3.3</version>
    </dependency>

    In combination with my moving compiled classes to WEB-INF/classes has caused the @URLMapping to start functioning! Fantastic news.

    Any thoughts on why the rewrite version exploded so spectacularly? I’d like to eventually upgrade from 3.3.3 to your newer code base, and there seems to be a hiccup in the process for me.

    • This reply was modified 1 year, 7 months ago by  Meister.
    • This reply was modified 1 year, 7 months ago by  Meister.
    #26636

    Meister
    Participant

    I think my final and most condensed question at this point is:

    Is there any way I can configure PrettyFaces to find annotated classes in /FoundationServer/target/classes instead of /FoundationServer/src/main/webapp/WEB-INF/classes ?

    #26639

    Meister
    Participant

    Looking through PrettyFaces source code, it looks like /WEB-INF/classes is assumed on a hard-coded level in the code base.

    To resolve my issue, I created a Hard Link from /target/classes to /WEB-INF/ — Application now recompiles and updates .class files automatically again, and PrettyFaces can read them to turn on. It’s not perfect, but it’ll do for now.

    • This reply was modified 1 year, 7 months ago by  Meister.
    • This reply was modified 1 year, 7 months ago by  Meister.
    #26642

    Hey, sorry for the late response.

    Yes, that’s correct. The annotation scanning code is basically hand-written. And it assumes a standard WAR archive with /WEB-INF/classes and /WEB-INF/lib folders. I agree that this may not be ideal. Especially when using something like Spring Boot.

    I thought a lot about whether Rewrite should use some library for annotation scanning like Reflections or something similar. Perhaps this would be a better choice. But I’m not sure about that.

    #27357

    persapiens
    Participant

    Hi, is it possible to run this application with spring-boot “jar” packaging?

    Thanks in advance.

    #27358

    Unfortunately our annotation scanning code does work well with such packagings. There are plans to replace our annotation scanning code with a library like Reflections, but I currently don’t find much time to work on this.

Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.

Comments are closed.