]
Christian Kaltepoth commented on SEAMFACES-158:
-----------------------------------------------
Hi Brian,
thank you for your feedback. I totally understand your concerns regrading the usage of
these non-standard attributes for the lookup. I really don't like the fact that the
major CDI implementations use different names here. Thus I've already created CDI-117
to address this issue.
One reason I added these additional lookups before falling back to the BeanManagerLocator
is that the BeanManagerLocator solely uses JNDI lookups to obtain the BeanManager.
Unfortunately JNDI is not supported in all environments, like GAE for example. So I think
it is reasonable to perform lookups in the servlet context before falling back to JNDI.
Certainly a solution using a CDI extension would be more elegant, but I'm unsure if
this is possible.
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: