]
Brian Leathem commented on SEAMFACES-158:
-----------------------------------------
Thanks for taking the time to provide this patch Christian. I like the way your patch
tries to retrieve the BeanManager from the Servlet Context before falling back on the
BeanManageLocator. What concerns me about the approach is the non-standard nature of
these lookups from the Servlet context.
I'm don't know whether the trade-off of the performance of the non-standard
lookups warrants breaking portability, given that the lookup falls back on the portable
BeanManageLocator. I'm curious what others in the Seam community think about this.
One idea I wanted to investigate was to have the RewriteConfiguration implement the CDI
Extension interface. Although I'm not sure this would work, given that the lifecycle
of the class is managed by PrettyFaces.
URLRewriting in ViewConfig does not work in Tomcat/Servlet Container
--------------------------------------------------------------------
Key: SEAMFACES-158
URL:
https://issues.jboss.org/browse/SEAMFACES-158
Project: Seam Faces
Issue Type: Bug
Components: URL Rewriting
Affects Versions: 3.0.1
Reporter: Lincoln Baxter III
Fix For: 3.0.2
Hello i am using jsf 2, pretty 3.2.1 seam-faces 3.0.1, weld 1.1.0, and tomcat 7.0.11.
If i use only pretty faces (without seam-faces) everything works. Also if i only use
seam-faces (without pretty faces)everything works. But if i use those two together
everythings fails on startup. I was looking at the source code and i found this:
At startup i get this message from weld:
INFO: Tomcat detected, CDI injection will be available in Servlets and Filters. Injection
into Listeners is not supported
And i guess that is fine because i am in servlet. But then:
There is a class in seam-faces:
{code}(a)Requires("com.ocpsoft.pretty.faces.spi.ConfigurationProvider")
public class RewriteConfiguration implements ConfigurationProvider {
public static final String PRETTYFACES_CONFIG_SERVLETCONTEXT_KEY =
"org.jboss.seam.faces.com.ocpsoft.pretty.faces.spi.ConfigurationProvider";
@Override
public PrettyConfig loadConfiguration(ServletContext sc) {
WebXmlParser webXmlParser = new WebXmlParser();
try {
webXmlParser.parse(sc);
} catch (IOException ex) {
throw new RuntimeException(ex);
} catch (SAXException ex) {
throw new RuntimeException(ex);
}
BeanManager beanManager = (BeanManager)
sc.getAttribute(BeanManagerServletContextListener.BEANMANAGER_SERVLETCONTEXT_KEY);
ViewConfigStore store = BeanManagerUtils.getContextualInstance(beanManager,
ViewConfigStore.class);{code}
Which is dependant on the presence of pretty-faces. It tries to get the beanManager from
the servlet context under the key know as
BeanManagerServletContextListener.BEANMANAGER_SERVLETCONTEXT_KEY.But that key is not
there, here is why:
BeanManagerServletContextListener class:
{code}public class BeanManagerServletContextListener implements ServletContextListener {
public static final String BEANMANAGER_SERVLETCONTEXT_KEY =
"org.jboss.seam.faces.javax.enterprise.spi.BeanManager";
@Inject
private BeanManager beanManager;
public void contextDestroyed(ServletContextEvent sce) {
}
public void contextInitialized(ServletContextEvent sce) {
sce.getServletContext().setAttribute(BEANMANAGER_SERVLETCONTEXT_KEY, beanManager);
}
}{code}
This class tries to inject beanmanager. But this is a listener so injections don't
work in servlet containers (tomcat). So this class always stores null reference under the
key BEANMANAGER_SERVLETCONTEXT_KEY.
And then somwhere else along the way stuff explodes with null pointer exception trying to
obtain a reference to beanmanager.
I described this on seam forums too here:
http://seamframework.org/Community/SeamfacesWithTomcat
But no body seams to read those forums at all. So i decided to try here :). This is
related to pretty faces as well.
I fixed it like this: I put the BeanManagerServletContextListener in my workspace and i
change contextInitialized method into this:
{code}public void contextInitialized(ServletContextEvent sce) {
if (beanManager == null){
String name = Listener.class.getPackage().getName() + "." +
BeanManager.class.getName();
beanManager = (BeanManager)sce.getServletContext().getAttribute(name);
}
sce.getServletContext().setAttribute(BEANMANAGER_SERVLETCONTEXT_KEY, beanManager);
}{code}
So now if the injection fails we try to get the bean manager from the listener. It is a
hack, and don't think it will work on other servlets/cdi implementations but it is a
place to start.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: