RF 4.3.4: Configuring ResourceServlet in Servlet 3.0

[leolo]

Hello,

in the RF DeveloperGuide http://docs.jboss.org/richfaces/latest_4_3_X/Developer_Guide/en-US/pdf/Developer_Guide.pdf one can read, that the ResourceServlet is automatically registered with Servlet 3.0.

We use JBoss EAP 6.1.1, JSF 2.1 and RF 4.3.4, so Servlet 3.0 is available. Every setting we have found is pointing to servlet 3.0.

1)

If we don't use RF Resource optimization (org.richfaces.resourceOptimization.enabled = false) we get a HTTP 500 error:

HTTP 500 GET skinning.ecss.xhtml?db=eAHjW!XqPQAE!QKS

http://localhost:8080/ourApp/rfRes/skinning.ecss.xhtml?db=eAHjW!XqPQAE!QKS

2)

If we use RF Resource optimization (org.richfaces.resourceOptimization.enabled = true) and don't configure the ResourceServlet explicitly, we get

HTTP 404 Errors for skinning.css, jquery.js and packed.js

Requests are like this one: http:localhost:8080/ourApp/org.richfaces.resources/javax.faces.resource/org.richfaces.staticResource/4.3.4.Final/PackedCompressed/DEFAULT/skinning.css" />

So it seems, that the ResourceServlet is not registered/not working.

3)

If we register the ResourceServlet explicitly...

<servlet>

<servlet-name>Resource Servlet</servlet-name>

<servlet-class>org.richfaces.webapp.ResourceServlet</servlet-class>

<load-on-startup>1</load-on-startup>

</servlet>

<servlet-mapping>

<servlet-name>Resource Servlet</servlet-name>

<url-pattern>/org.richfaces.resources/*</url-pattern>

</servlet-mapping>

...everything works fine.

So, my 2 questions are:

- Why do we get the HTTP 500-error described at point 1) while getting skinning.ecss.xhtml?db=eAHjW!XqPQAE!QKS?

- Why do we have to register the ResourceServlet explicitly?

Regards,

Hardy Massen

[bleathem]

Our "kitchensink quickstart" uses resource optimisation without explicitly enabling the resource servlet.  It runs well on JBoss EAP 6.1.1.  See the web.xml:

https://github.com/richfaces/jdf-quickstarts/blob/master/kitchensink-rf/src/main/webapp/WEB-INF/web.xml

Can you share your web.xml for the analogous configuration?  We'll see if we can figure out what's going wrong.

[leolo]

Hi Brian, thanks for your answer!

I debugged a little bit further and found the cause of the problem, but no solution yet.

Problem is, that we configured RichFaces to work as a JBoss module. If I put the richfaces-libraries in the /WEB-INF/lib-folder of the webapp, the resource-servlet works as designed.

I can recreate the issue with our JBoss EAP 6.1.1, if I take modules.zip and jboss-as-helloworld-rf.war from [RF-12896] Richfaces TopicsContext.lookup() returns null after redeployment when Richfaces is deployed as a module in JB… Note: I have to add one dependency in the module.xml of org.richfaces  <module name="javaee.api"/> to get it working, but the rest is as it's attached to the ticket.

Same Issue is described in [RF-12797] rich:editor not rendered when using RichFaces module - JBoss Issue Tracker https://community.jboss.org/

Can anyone reproduce the issue with JBoss EAP 6.1.1, if you take modules.zip and jboss-as-helloworld-rf.war from [RF-12896]? This would eliminate the possibility of a mis-configuration of our JBoss.

In [RF-12008] Add RichFaces AS7 module to distribution - JBoss Issue Tracker one can read, that for now "RichFaces as JBoss AS module." is not (fully) supported. (Fix-Version 5-Future).

So what is the recommended way to include RichFaces-4-Jars with JBoss AS until this issue is fixed? Putting the RichFaces-jars in every application-ear can't be the solution, right?

Regards,

Hardy

[bleathem]

Right, we currently don't support RichFaces running as a WildFly/EAP module.  We don't plan on re-visiting this until after RichFaces 5.0.0.Final, but if someone in the community want to make the changes required to get it working we will gladly accept the Pull Request.

In the mean time, the solution is to include RichFaces separately in each deployment.

[leolo]

Hi Brian,

maybe it would be a good idea to put the info in the RichFaces-Developer-Guide, that "RichFaces as a JBoss-Module" is not supported and may cause funky issues.

We just started migrating from RF 3 to RF 4.3.4 and were stuck with several issues which at the end had their cause in RF being a JBoss-Module

Regards,

Hardy