Well the configurator framework can be initialized at any time really.
There already is a context listener but right now it only shuts down the
configurators because Adam was concerned that Faces FactoryFinder would
not be initialized when the ContextListener is run and we have some
configurator code which is dependent on retrieving the Application.
Scott
Andrew Robinson wrote:
Yes it should be enough at web startup as that is when the Annotations
are processed and the framework is trying to load the render kit. That
is being called from a web context listener, but the filter would
definitely be too late as this happens on application server startup,
not on the first request.
On Wed, Dec 16, 2009 at 6:41 AM, Scott O'Bryan <[email protected]> wrote:
Hey Andrew, so would executing this during web application startup (like
during a filter or FacesServlet.Init) be early enough?
Sent from my iPhone
On Dec 15, 2009, at 8:44 PM, Andrew Robinson <[email protected]>
wrote:
On my quest to write the support of the JSF 2 client behavior support,
I ran across a problem with the Trinidad render kit and JSF 2. In JSF
2, the ConfigManager starts the call chain for configuring faces
elements when the faces context is parsed. The render kit is
org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator and
it relies on using the Trinidad RequestContext to get a
getApplicationScopedConcurrentMap to store the render kit in. The
problem I am having is the RequestContext is setup by the global
configurator which seems to be initializing the contexts when the
request is processed. Since the config manager runs before the global
configurator is processed, the request context is not available to get
the map.
I am not as familiar with this area of our framework and do not feel
confident making changes to fix this issue. We need to somehow be able
to instantiate the RenderKit instance when the ConfigManager runs, not
when the request is processed. I am not sure if we want to relocate
the code from RequestContext to a non-request based object or make
changes to the configurator to setup the information during faces
config parsing and not upon the request processing.
Ideas?
Thanks,
Andrew
PS - here is the stack trace so you can see when the call is taking
place (Ignore the line in the RenderKitDecorator as I have tried some
changes):
Dec 15, 2009 8:41:07 PM com.sun.faces.config.ConfigureListener
contextInitialized
INFO: Initializing Mojarra 2.0.1 (FCS b02) for context '/trinidad-demo'
Dec 15, 2009 8:41:10 PM com.sun.faces.config.ConfigManager initialize
INFO: Unsanitized stacktrace from failed start...
javax.faces.FacesException: java.lang.NullPointerException
at
com.sun.faces.application.annotation.RenderKitConfigHandler.push(RenderKitConfigHandler.java:144)
at
com.sun.faces.application.annotation.AnnotationManager.applyConfigAnntations(AnnotationManager.java:196)
at
com.sun.faces.config.processor.AbstractConfigProcessor.processAnnotations(AbstractConfigProcessor.java:327)
at
com.sun.faces.config.processor.RenderKitConfigProcessor.process(RenderKitConfigProcessor.java:165)
at
com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:113)
at
com.sun.faces.config.processor.ManagedBeanConfigProcessor.process(ManagedBeanConfigProcessor.java:269)
at
com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:113)
at
com.sun.faces.config.processor.ValidatorConfigProcessor.process(ValidatorConfigProcessor.java:119)
at
com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:113)
at
com.sun.faces.config.processor.ConverterConfigProcessor.process(ConverterConfigProcessor.java:125)
at
com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:113)
at
com.sun.faces.config.processor.ComponentConfigProcessor.process(ComponentConfigProcessor.java:116)
at
com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:113)
at
com.sun.faces.config.processor.ApplicationConfigProcessor.process(ApplicationConfigProcessor.java:336)
at
com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:113)
at
com.sun.faces.config.processor.LifecycleConfigProcessor.process(LifecycleConfigProcessor.java:115)
at
com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:113)
at
com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:222)
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:335)
at
com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:219)
at
org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:136)
at
org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250)
at
org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
at
org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467)
at
org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:115)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at
org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(Server.java:224)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132)
at
org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:441)
at
org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:383)
at
org.mortbay.jetty.plugin.Jetty6RunWarExploded.execute(Jetty6RunWarExploded.java:170)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:453)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:513)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:301)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: java.lang.NullPointerException
at
org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.getRenderKit(RenderKitDecorator.java:136)
at
org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.addClientBehaviorRenderer(RenderKitDecorator.java:77)
at
com.sun.faces.application.annotation.RenderKitConfigHandler.push(RenderKitConfigHandler.java:141)
... 56 more
