Hi:
Thank you for your answer Simon. Here are again those portions from the web.xml
file that are relevant to this issue. I missed some of them before. Maybe
there is something else wrong.
Regarding your observation that the users can access directly the jsp pages,
actually the access to the jsp pages is blocked through security constraints
except the index.jsp page which uses response.sendRedirect("p/home.jsp") to
navigate to p/home.jsp which is protected and which triggers the login page (I
use the Form auth-method). If the user logs in successfully then weblogic will
forward the user to p/home.jsp (p is the folder name that I use instead of
faces).
Regarding the thread-safety, there was only one user at the time which
triggered the error. I don't think this is a thread-safety issue.
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";>
<context-param>
<description>Comma separated list of URIs of (additional) faces config
files.(e.g. /WEB-INF/my-config.xml) See JSF 1.0 PRD2, 10.3.2</description>
<param-name>javax.faces.CONFIG_FILES</param-name>
<param-value>/WEB-INF/common-faces-config.xml</param-value>
</context-param>
<context-param>
<description>State saving method: "client" or "server" (= default) See JSF
Specification 2.5.2</description>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>
<context-param>
<param-name>org.apache.myfaces.DETECT_JAVASCRIPT</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>org.apache.myfaces.ALLOW_JAVASCRIPT</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>org.apache.myfaces.AUTO_SCROLL</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>org.apache.myfaces.ADD_RESOURCE_CLASS</param-name>
<param-value>org.apache.myfaces.component.html.util.StreamingAddResource</param-value>
</context-param>
<context-param>
<param-name>org.apache.myfaces.RESOURCE_VIRTUAL_PATH</param-name>
<param-value>/faces/myFacesExtensionResource</param-value>
</context-param>
<context-param>
<param-name>org.apache.myfaces.SERIAL_FACTORY</param-name>
<param-value>org.bchousing.common.jsf.JbossSerialFactory</param-value>
</context-param>
<context-param>
<description>For JSF 1.1</description>
<param-name>org.apache.myfaces.validate</param-name>
<param-value>true</param-value>
</context-param>
<filter>
<filter-name>shale</filter-name>
<filter-class>org.apache.shale.faces.ShaleApplicationFilter</filter-class>
</filter>
<filter>
<filter-name>MyFacesExtensionsFilter</filter-name>
<filter-class>org.apache.myfaces.webapp.filter.ExtensionsFilter</filter-class>
<init-param>
<description>We allow for maximum 1gb uploads</description>
<param-name>uploadMaxFileSize</param-name>
<param-value>1000m</param-value>
</init-param>
<init-param>
<param-name>uploadThresholdSize</param-name>
<param-value>10k</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>shale</filter-name>
<url-pattern>/p/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>MyFacesExtensionsFilter</filter-name>
<servlet-name>Faces Servlet</servlet-name>
</filter-mapping>
<filter-mapping>
<filter-name>MyFacesExtensionsFilter</filter-name>
<url-pattern>/faces/myFacesExtensionResource/*</url-pattern>
<dispatcher>ERROR</dispatcher>
<dispatcher>FORWARD</dispatcher>
<dispatcher>INCLUDE</dispatcher>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
<listener>
<listener-class>org.apache.shale.view.faces.LifecycleListener</listener-class>
</listener>
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
...
</servlet>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>/p/*</url-pattern>
</servlet-mapping>
This exception does not happen at startup, it's generated during handling of a
request if some tomahawk component tries to declare a dependency on some
resource (eg a css or javascript file), and the tomahawk resource-management
code detects that the request has not passed through the ExtensionsFilter.
In your separate email, you do appear to have the filter set up correctly, so
that it is applied to every JSF request:
MyFacesExtensionsFilter
Faces Servlet
The error message you report is only output if code calls AddResourceFactory,
and the only thing that does that is Tomahawk components. And those components
will not be executed except inside a JSF request. But your servlet mapping
correctly ensures that the extensions filter runs whenever the FacesServlet
runs.
Hmm..I wonder if it is possible that some of your users are occasionally typing
in raw urls like "/foo.jsp", causing the pages to be run as jsp pages rather
than as jsf pages? The components would then run without the ExtensionsFilter.
The page would certainly fail eventually, but I don't know whether the
ExtensionsFilter error or some other error would be reported first. It's not
likely this is the cause, but maybe worth checking that you correctly block
.jsp urls...
Otherwise I would guess that there is some thread-unsafe code somewhere in
ExtensionsFilter or AddResourceFactory or similar. That certainly matches your
description: an intermittent failure that only happens under production load.
Finding thread-safety problems is unfortunately not easy. I have had a quick
look at the code, and cannot see any problems. It's really pretty simple: add
flag to request-scope in the ExtensionsFilter, then later look in the
request-scope to see if the flag is there. And there should never be
thread-safety issues checking the request-scope vars.
Well, one other remote possibility is a bug in weblogic that sometimes doesn't
run the right filters, but that's fairly unlikely.
Hmm..from a quick look at the code, this looks a bit worrying
thread-safety-wise:
if (extctx.getApplicationMap().containsKey(ENV_CHECKED_KEY))
{
// already checked
return;
}
The application-scope vars are being accessed without a lock. Reading from a
normal Map object is not thread-safe. The Sun javadoc for getApplicationMap do
not mention anything about what kind of locking is required to access
application-scoped data. Probably needs further investigation, but it is
unlikely to be the cause of your problem anyway. At worst, this should cause
the slightly time-consuming check to be repeated when not necessary.
NB: the official config docs for ExtensionsFilter are here:
http://myfaces.apache.org/tomahawk/extensionsFilter.html
Regards,
Simon
---------------------------------
Be smarter than spam. See how smart SpamGuard is at giving junk email the boot
with the All-new Yahoo! Mail
