You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Andrew Robinson <an...@gmail.com> on 2009/12/16 04:44:45 UTC
[Trinidad 2] Trinidad render kit not compatible with JSF 2
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
Re: [Trinidad 2] Trinidad render kit not compatible with JSF 2
Posted by Andrew Robinson <an...@gmail.com>.
I added an annotated client behavior class to the demo project. When
the annotations are scanned and they find an client behavior, the code
attempts to register it with the render kit and our render kit fails
to load. We never saw it before because (1) we have not been using
annotations and (2) we had no client behaviors in the demo
-Andrew
On Wed, Dec 16, 2009 at 1:43 PM, Max Starets <ma...@oracle.com> wrote:
> Andrew,
>
> Do you have any idea why we haven't seen this during our initial testing of
> Trinidad
> with JSF 2.0?
>
> Max
>
> 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 <sc...@oracle.com>
>> 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
>>> <an...@gmail.com>
>>> 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
>>>>
>
>
Re: [Trinidad 2] Trinidad render kit not compatible with JSF 2
Posted by Max Starets <ma...@oracle.com>.
Andrew,
Do you have any idea why we haven't seen this during our initial testing
of Trinidad
with JSF 2.0?
Max
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 <sc...@oracle.com> 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 <an...@gmail.com>
>> 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
>>>
Re: [Trinidad 2] Trinidad render kit not compatible with JSF 2
Posted by Scott O'Bryan <sc...@oracle.com>.
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 <sc...@oracle.com> 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 <an...@gmail.com>
>> 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
>>>
Re: [Trinidad 2] Trinidad render kit not compatible with JSF 2
Posted by Andrew Robinson <an...@gmail.com>.
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 <sc...@oracle.com> 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 <an...@gmail.com>
> 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
>
Re: [Trinidad 2] Trinidad render kit not compatible with JSF 2
Posted by Scott O'Bryan <sc...@oracle.com>.
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 <andrew.rw.robinson@gmail.com
> 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