[jira] [Commented] (MYFACES-4224) AnnotatedFlowConfigurator.configureAnnotatedFlows is broken
[
https://issues.apache.org/jira/browse/MYFACES-4224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437884#comment-16437884
]
Mark Struberg commented on MYFACES-4224:
The issue is already fixed in myfaces-2.3.0!
> AnnotatedFlowConfigurator.configureAnnotatedFlows is broken
> ---
>
> Key: MYFACES-4224
> URL: https://issues.apache.org/jira/browse/MYFACES-4224
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-372
>Affects Versions: 2.2.12
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
>
> When running MyFaces on Tomcat with any CDI container
> AnnotatedFlowConfigurator.configureAnnotatedFlows get's called way too early
> which leads to the following Exception:
> {noformat}
> Apr 12, 2018 4:00:55 PM org.apache.myfaces.webapp.AbstractFacesInitializer
> initFaces
> SCHWERWIEGEND: An error occured while initializing MyFaces: It's not allowed
> to call getBeans(Type, Annotation...) before AfterBeanDiscovery
> java.lang.IllegalStateException: It's not allowed to call getBeans(Type,
> Annotation...) before AfterBeanDiscovery
> at
> org.apache.webbeans.container.InjectableBeanManager.checkAfterBeanDiscoveryProcessed(InjectableBeanManager.java:423)
> at
> org.apache.webbeans.container.InjectableBeanManager.getBeans(InjectableBeanManager.java:129)
> at org.apache.myfaces.cdi.util.CDIUtils.lookup(CDIUtils.java:45)
> at
> org.apache.myfaces.flow.cdi.DefaultCDIFacesFlowProvider.getAnnotatedFlows(DefaultCDIFacesFlowProvider.java:52)
> at
> org.apache.myfaces.flow.impl.AnnotatedFlowConfigurator.configureAnnotatedFlows(AnnotatedFlowConfigurator.java:42)
> at
> org.apache.myfaces.config.FacesConfigurator.configureFlowHandler(FacesConfigurator.java:1672)
> at
> org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:614)
> at
> org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:416)
> at
> org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:74)
> at
> org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:172)
> at
> org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:121)
> at
> org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4937)
> at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5434)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> This happens because the CDI spec disallows to call BeanManager#getBeans()
> before the container is started (AfterDeploymentValidation and later)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MYFACES-4225) [perf] Cache whether a library exists in ExternalContextResourceLoader
[
https://issues.apache.org/jira/browse/MYFACES-4225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437672#comment-16437672
]
Mark Struberg commented on MYFACES-4225:
Probably just an oversight. Ofc for every negative cache which can be triggered
by an external request should have a configurable max size. Otherwise it might
be possible to create an OOM by just firing requests with a UUID for example ;)
> [perf] Cache whether a library exists in ExternalContextResourceLoader
> --
>
> Key: MYFACES-4225
> URL: https://issues.apache.org/jira/browse/MYFACES-4225
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.2.11
>Reporter: Christian Beikov
>Priority: Major
>
> I'm seeing many {{sun.nio.fs.UnixException}} being thrown in the underlying
> code because {{ExternalContextResourceLoader.libraryExists}} calls
> {{ExternalContext.getResource}} which in the end checks if a file exists on
> the FS. I'd suggest when the project stage is PRODUCTION, this should be
> cached. Maybe this could be done by installing an {{ExternalContextWrapper}}
> that caches all resource lookups? I just see that parsing a XHTML causes many
> exceptions to be thrown internally which negatively affects performance.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MYFACES-4224) AnnotatedFlowConfigurator.configureAnnotatedFlows is broken
[
https://issues.apache.org/jira/browse/MYFACES-4224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436349#comment-16436349
]
Mark Struberg edited comment on MYFACES-4224 at 4/12/18 9:45 PM:
-
It didn't stop there :(
{noformat}
SCHWERWIEGEND: An error occured while initializing MyFaces: It's not allowed to
call getBeans(Type, Annotation...) before AfterBeanDiscovery
java.lang.IllegalStateException: It's not allowed to call getBeans(Type,
Annotation...) before AfterBeanDiscovery
at
org.apache.webbeans.container.InjectableBeanManager.checkAfterBeanDiscoveryProcessed(InjectableBeanManager.java:423)
at
org.apache.webbeans.container.InjectableBeanManager.getBeans(InjectableBeanManager.java:129)
at org.apache.myfaces.cdi.util.CDIUtils.lookup(CDIUtils.java:45)
at
org.apache.myfaces.cdi.impl.CDIManagedBeanHandlerImpl.(CDIManagedBeanHandlerImpl.java:54)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at
org.apache.myfaces.shared.util.ClassUtils.newInstance(ClassUtils.java:429)
at
org.apache.myfaces.shared.util.ClassUtils.newInstance(ClassUtils.java:392)
at
org.apache.myfaces.spi.impl.DefaultViewScopeProviderFactory.getViewScopeHandler(DefaultViewScopeProviderFactory.java:49)
at
org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:177)
at
org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:121)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4937)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5434)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
was (Author: struberg):
It didn't stop there :(
{noscript}
SCHWERWIEGEND: An error occured while initializing MyFaces: It's not allowed to
call getBeans(Type, Annotation...) before AfterBeanDiscovery
java.lang.IllegalStateException: It's not allowed to call getBeans(Type,
Annotation...) before AfterBeanDiscovery
at
org.apache.webbeans.container.InjectableBeanManager.checkAfterBeanDiscoveryProcessed(InjectableBeanManager.java:423)
at
org.apache.webbeans.container.InjectableBeanManager.getBeans(InjectableBeanManager.java:129)
at org.apache.myfaces.cdi.util.CDIUtils.lookup(CDIUtils.java:45)
at
org.apache.myfaces.cdi.impl.CDIManagedBeanHandlerImpl.(CDIManagedBeanHandlerImpl.java:54)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at
org.apache.myfaces.shared.util.ClassUtils.newInstance(ClassUtils.java:429)
at
org.apache.myfaces.shared.util.ClassUtils.newInstance(ClassUtils.java:392)
at
org.apache.myfaces.spi.impl.DefaultViewScopeProviderFactory.getViewScopeHandler(DefaultViewScopeProviderFactory.java:49)
at
org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:177)
at
org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:121)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4937)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5434)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
[jira] [Commented] (MYFACES-4224) AnnotatedFlowConfigurator.configureAnnotatedFlows is broken
[
https://issues.apache.org/jira/browse/MYFACES-4224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436349#comment-16436349
]
Mark Struberg commented on MYFACES-4224:
It didn't stop there :(
{noscript}
SCHWERWIEGEND: An error occured while initializing MyFaces: It's not allowed to
call getBeans(Type, Annotation...) before AfterBeanDiscovery
java.lang.IllegalStateException: It's not allowed to call getBeans(Type,
Annotation...) before AfterBeanDiscovery
at
org.apache.webbeans.container.InjectableBeanManager.checkAfterBeanDiscoveryProcessed(InjectableBeanManager.java:423)
at
org.apache.webbeans.container.InjectableBeanManager.getBeans(InjectableBeanManager.java:129)
at org.apache.myfaces.cdi.util.CDIUtils.lookup(CDIUtils.java:45)
at
org.apache.myfaces.cdi.impl.CDIManagedBeanHandlerImpl.(CDIManagedBeanHandlerImpl.java:54)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at
org.apache.myfaces.shared.util.ClassUtils.newInstance(ClassUtils.java:429)
at
org.apache.myfaces.shared.util.ClassUtils.newInstance(ClassUtils.java:392)
at
org.apache.myfaces.spi.impl.DefaultViewScopeProviderFactory.getViewScopeHandler(DefaultViewScopeProviderFactory.java:49)
at
org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:177)
at
org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:121)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4937)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5434)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noscript}
> AnnotatedFlowConfigurator.configureAnnotatedFlows is broken
> ---
>
> Key: MYFACES-4224
> URL: https://issues.apache.org/jira/browse/MYFACES-4224
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-372
>Affects Versions: 2.2.12, 2.3.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
>
> When running MyFaces on Tomcat with any CDI container
> AnnotatedFlowConfigurator.configureAnnotatedFlows get's called way too early
> which leads to the following Exception:
> {noformat}
> Apr 12, 2018 4:00:55 PM org.apache.myfaces.webapp.AbstractFacesInitializer
> initFaces
> SCHWERWIEGEND: An error occured while initializing MyFaces: It's not allowed
> to call getBeans(Type, Annotation...) before AfterBeanDiscovery
> java.lang.IllegalStateException: It's not allowed to call getBeans(Type,
> Annotation...) before AfterBeanDiscovery
> at
> org.apache.webbeans.container.InjectableBeanManager.checkAfterBeanDiscoveryProcessed(InjectableBeanManager.java:423)
> at
> org.apache.webbeans.container.InjectableBeanManager.getBeans(InjectableBeanManager.java:129)
> at org.apache.myfaces.cdi.util.CDIUtils.lookup(CDIUtils.java:45)
> at
> org.apache.myfaces.flow.cdi.DefaultCDIFacesFlowProvider.getAnnotatedFlows(DefaultCDIFacesFlowProvider.java:52)
> at
> org.apache.myfaces.flow.impl.AnnotatedFlowConfigurator.configureAnnotatedFlows(AnnotatedFlowConfigurator.java:42)
> at
> org.apache.myfaces.config.FacesConfigurator.configureFlowHandler(FacesConfigurator.java:1672)
> at
> org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:614)
> at
> org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:416)
> at
> org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:74)
> at
> org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:172)
> at
> org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:121)
> at
>
[jira] [Created] (MYFACES-4224) AnnotatedFlowConfigurator.configureAnnotatedFlows is broken
Mark Struberg created MYFACES-4224:
--
Summary: AnnotatedFlowConfigurator.configureAnnotatedFlows is
broken
Key: MYFACES-4224
URL: https://issues.apache.org/jira/browse/MYFACES-4224
Project: MyFaces Core
Issue Type: Bug
Components: JSR-372
Affects Versions: 2.3.0, 2.2.12
Reporter: Mark Struberg
Assignee: Mark Struberg
When running MyFaces on Tomcat with any CDI container
AnnotatedFlowConfigurator.configureAnnotatedFlows get's called way too early
which leads to the following Exception:
{noformat}
Apr 12, 2018 4:00:55 PM org.apache.myfaces.webapp.AbstractFacesInitializer
initFaces
SCHWERWIEGEND: An error occured while initializing MyFaces: It's not allowed to
call getBeans(Type, Annotation...) before AfterBeanDiscovery
java.lang.IllegalStateException: It's not allowed to call getBeans(Type,
Annotation...) before AfterBeanDiscovery
at
org.apache.webbeans.container.InjectableBeanManager.checkAfterBeanDiscoveryProcessed(InjectableBeanManager.java:423)
at
org.apache.webbeans.container.InjectableBeanManager.getBeans(InjectableBeanManager.java:129)
at org.apache.myfaces.cdi.util.CDIUtils.lookup(CDIUtils.java:45)
at
org.apache.myfaces.flow.cdi.DefaultCDIFacesFlowProvider.getAnnotatedFlows(DefaultCDIFacesFlowProvider.java:52)
at
org.apache.myfaces.flow.impl.AnnotatedFlowConfigurator.configureAnnotatedFlows(AnnotatedFlowConfigurator.java:42)
at
org.apache.myfaces.config.FacesConfigurator.configureFlowHandler(FacesConfigurator.java:1672)
at
org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:614)
at
org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:416)
at
org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:74)
at
org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:172)
at
org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:121)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4937)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5434)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
This happens because the CDI spec disallows to call BeanManager#getBeans()
before the container is started (AfterDeploymentValidation and later)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MYFACES-4160) ViewState not written for Ajax request
[
https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435820#comment-16435820
]
Mark Struberg commented on MYFACES-4160:
Folks, I also get the following issue when starting up MyFaces with plain
tomcat and OWB:
{noformat}
An error occured while initializing MyFaces: It's not allowed to call
getBeans(Type, Annotation...) before AfterBeanDiscovery
java.lang.IllegalStateException: It's not allowed to call getBeans(Type,
Annotation...) before AfterBeanDiscovery
at
org.apache.webbeans.container.InjectableBeanManager.checkAfterBeanDiscoveryProcessed(InjectableBeanManager.java:423)
at
org.apache.webbeans.container.InjectableBeanManager.getBeans(InjectableBeanManager.java:129)
at org.apache.myfaces.cdi.util.CDIUtils.lookup(CDIUtils.java:45)
at
org.apache.myfaces.flow.cdi.DefaultCDIFacesFlowProvider.getAnnotatedFlows(DefaultCDIFacesFlowProvider.java:52)
at
org.apache.myfaces.flow.impl.AnnotatedFlowConfigurator.configureAnnotatedFlows(AnnotatedFlowConfigurator.java:42)
at
org.apache.myfaces.config.FacesConfigurator.configureFlowHandler(FacesConfigurator.java:1672)
at
org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:614)
at
org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:416)
at
org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:74)
at
org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:172)
at
org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:121)
{noformat}
Should this be fixed with this commit or is this another issue which we need to
address?
> ViewState not written for Ajax request
> --
>
> Key: MYFACES-4160
> URL: https://issues.apache.org/jira/browse/MYFACES-4160
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Thomas Andraschko
>Assignee: Werner Punz
>Priority: Major
> Fix For: 2.3.0
>
> Attachments: test1.xhtml
>
>
> If you run the application from MYFACES-4156 via mvn jetty:run, the
> viewStateId isn't rendered again after the first ajax request.
> Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it
> skips.
> [~lu4242] Could you please check that?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MYFACES-4021) blacklist org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan in MyFacesObjectInputStream
[ https://issues.apache.org/jira/browse/MYFACES-4021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15031126#comment-15031126 ] Mark Struberg commented on MYFACES-4021: The serialisation used to be required by the spec. But we do this actually _before_ we store it in the Http session. The point is that you can only make sure a view state is truly separated from the previous version by serialising it. You kind of need to get a deep copy, otherwise changes done on references will also modify old view states. This requirement only got dropped from the spec as it was made clear that the RI itself doesn't implement it ;) > blacklist > org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan > in MyFacesObjectInputStream > - > > Key: MYFACES-4021 > URL: https://issues.apache.org/jira/browse/MYFACES-4021 > Project: MyFaces Core > Issue Type: Bug >Reporter: Romain Manni-Bucau >Priority: Blocker > > https://github.com/apache/incubator-batchee/commit/cfd133c309c21a82fb24cfcc9a7c2365aee4678a#diff-acd0bc06477ce776b0ad8fdda76f8b7eR56 > mecanism can be used > (due to recent vulnerability discovered in [collections], spring, groovy we > can't suppose we don't run with these libraries so we need this fix as well) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-4021) blacklist org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan in MyFacesObjectInputStream
[ https://issues.apache.org/jira/browse/MYFACES-4021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15030092#comment-15030092 ] Mark Struberg commented on MYFACES-4021: If someone uses client side state saving and no encryption, then he is doomed anyway imo ;) Serious: we should probably update our docs. If the client state is encrypted then there is no problem imo. > blacklist > org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan > in MyFacesObjectInputStream > - > > Key: MYFACES-4021 > URL: https://issues.apache.org/jira/browse/MYFACES-4021 > Project: MyFaces Core > Issue Type: Bug >Reporter: Romain Manni-Bucau >Priority: Blocker > > https://github.com/apache/incubator-batchee/commit/cfd133c309c21a82fb24cfcc9a7c2365aee4678a#diff-acd0bc06477ce776b0ad8fdda76f8b7eR56 > mecanism can be used > (due to recent vulnerability discovered in [collections], spring, groovy we > can't suppose we don't run with these libraries so we need this fix as well) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MYFACES-3998) improve BanManger lookup for CDI-1.1
Mark Struberg created MYFACES-3998: -- Summary: improve BanManger lookup for CDI-1.1 Key: MYFACES-3998 URL: https://issues.apache.org/jira/browse/MYFACES-3998 Project: MyFaces Core Issue Type: Bug Components: JSR-344 Affects Versions: 2.2.8 Reporter: Mark Struberg Assignee: Mark Struberg We currently do partly unportable stuff to look up the BeanManager. This could be replaced by dynamically using CDI.current().get(). This should be done via reflection to avoid blowing up if no CDI-1.1 environment is present. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MYFACES-3999) Contextual Instance lookup code is broken
Mark Struberg created MYFACES-3999: -- Summary: Contextual Instance lookup code is broken Key: MYFACES-3999 URL: https://issues.apache.org/jira/browse/MYFACES-3999 Project: MyFaces Core Issue Type: Bug Components: JSR-344 Affects Versions: 2.2.8 Reporter: Mark Struberg Assignee: Mark Struberg Our CDI instance lookup code is wrong. We must not simply put the first instance from the iterator but use BeanManager#resolve etc to get it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-3998) improve BanManger lookup for CDI-1.1
[ https://issues.apache.org/jira/browse/MYFACES-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14583558#comment-14583558 ] Mark Struberg commented on MYFACES-3998: CDI.current() is designed to give you the correct BeanManager in that case. We have exactly the correct TCCL when CDI.current() is used. improve BanManger lookup for CDI-1.1 Key: MYFACES-3998 URL: https://issues.apache.org/jira/browse/MYFACES-3998 Project: MyFaces Core Issue Type: Bug Components: JSR-344 Affects Versions: 2.2.8 Reporter: Mark Struberg Assignee: Mark Struberg We currently do partly unportable stuff to look up the BeanManager. This could be replaced by dynamically using CDI.current().get(). This should be done via reflection to avoid blowing up if no CDI-1.1 environment is present. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MYFACES-3998) improve BanManger lookup for CDI-1.1
[ https://issues.apache.org/jira/browse/MYFACES-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved MYFACES-3998. Resolution: Fixed improve BanManger lookup for CDI-1.1 Key: MYFACES-3998 URL: https://issues.apache.org/jira/browse/MYFACES-3998 Project: MyFaces Core Issue Type: Bug Components: JSR-344 Affects Versions: 2.2.8 Reporter: Mark Struberg Assignee: Mark Struberg We currently do partly unportable stuff to look up the BeanManager. This could be replaced by dynamically using CDI.current().get(). This should be done via reflection to avoid blowing up if no CDI-1.1 environment is present. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MYFACES-3999) Contextual Instance lookup code is broken
[ https://issues.apache.org/jira/browse/MYFACES-3999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved MYFACES-3999. Resolution: Fixed Contextual Instance lookup code is broken - Key: MYFACES-3999 URL: https://issues.apache.org/jira/browse/MYFACES-3999 Project: MyFaces Core Issue Type: Bug Components: JSR-344 Affects Versions: 2.2.8 Reporter: Mark Struberg Assignee: Mark Struberg Our CDI instance lookup code is wrong. We must not simply put the first instance from the iterator but use BeanManager#resolve etc to get it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-3863) Possible performance enchanchment in postback lifecycle processing
[ https://issues.apache.org/jira/browse/MYFACES-3863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13917788#comment-13917788 ] Mark Struberg commented on MYFACES-3863: Agree with Leo. Usually the performance issues don't come from the JSF container itself but from expensive calls to backing beans or tons of complex EL expressions. I have really huge and pretty complex pages with 1600 rows in a h:dataTable and they still render in below 200ms (for the whole page). Try to use a profiler like YourKit and count the invocations to your backing beans and you will be surprised. If those operations are dirt cheyp, then you will not have much issue. If they operate against the db without using some init in a preRenderView phase, then this might be the bummer. Possible performance enchanchment in postback lifecycle processing -- Key: MYFACES-3863 URL: https://issues.apache.org/jira/browse/MYFACES-3863 Project: MyFaces Core Issue Type: Improvement Reporter: Karl Trumstedt Assignee: Leonardo Uribe Priority: Minor Hello, I've been looking and reading a lot about JSF's lifecycle. I'm no expert in any sense and have not fully grasped what happens in each phase. I have debugged our application and seen how much time is spent in each cycle. For larger pages it can be quite a lot (500 ms for each APPLY, VALIDATION, UPDATE). Even for smaller pages there can be ~10-20ms in the cycle when posting to the server. As far as I have gathered, the component tree is traversed for each of these cycles. For us, every ms counts :) Now, my application doesn't use the JSF validation framework. There isn't any f:validator stuff anywhere. For me, I don't see that I need to execute that phase, ever. So I would like to turn off that phase. But even better, maybe when parsing the XHTML facelet (or constructing the view or something), couldn't the UIViewRoot have information on if there are any f:validator stuff on the page? If not, it could skip the validation phase completely? As I said, I don't fully grasp what's happening behind the scenes so maybe something else would stop working? And maybe the validation phase does more the execute f:validator tags. I realize this scenario might be special since we don't use the f:validator stuff, we reuse our own legacy validation framework, but there still could be pages in a regular JSF application with lots of components (big tables etc) and no validation (or custom validation). Any pointers for how I could patch and skip the validation phase myself would be nice:) Thanks -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (EXTCDI-305) review validation of EXTCDI-265
[ https://issues.apache.org/jira/browse/EXTCDI-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved EXTCDI-305. -- Resolution: Fixed Fix Version/s: 1.0.6 The check will now only be done for EntityManagers review validation of EXTCDI-265 --- Key: EXTCDI-305 URL: https://issues.apache.org/jira/browse/EXTCDI-305 Project: MyFaces CODI Issue Type: Bug Components: JEE-JPA1-Module Affects Versions: 1.0.5 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 1.0.6 Attachments: OWB-305.patch CODI-1.0.5 added a 'validation' for qualifiers of the bean. In fact this is too strict. This only makes sense for injected EntityManagers, but not if you like to store information which has nothing to do with EntityManagers. In our case we e.g. like to track information we collect via @PostUpdate JPA EntityListeners and evaluate them in the @PreDestroy of an @TransactionScoped bean. This is *explicitely* default scoped and not assigned to any special EntityManager! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTCDI-305) review validation of EXTCDI-265
Mark Struberg created EXTCDI-305: Summary: review validation of EXTCDI-265 Key: EXTCDI-305 URL: https://issues.apache.org/jira/browse/EXTCDI-305 Project: MyFaces CODI Issue Type: Bug Components: JEE-JPA1-Module Affects Versions: 1.0.5 Reporter: Mark Struberg Assignee: Mark Struberg CODI-1.0.5 added a 'validation' for qualifiers of the bean. In fact this is too strict. This only makes sense for injected EntityManagers, but not if you like to store information which has nothing to do with EntityManagers. In our case we e.g. like to track information we collect via @PostUpdate JPA EntityListeners and evaluate them in the @PreDestroy of an @TransactionScoped bean. This is *explicitely* default scoped and not assigned to any special EntityManager! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3652) Define default view key algorithm
[ https://issues.apache.org/jira/browse/MYFACES-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501109#comment-13501109 ] Mark Struberg commented on MYFACES-3652: Hi Leo, thanks for the feedback. I did a quick test and while the SessionIdGenerator from tomcat creates a much more unpredictable value it is also much slower than XorShiftRandom. And currently we encrypt that as well, so this looks a bit like an overkill to me. - the viewId hashcode protects against use one valid key for one view in other view, But an attacker can easily disable this vector by using the same view for the hack. So this information is not of stellar use in practice. I agree that with B we _theoretically_ would not need encryption + mac. But I have my doubts as well. Please look at the ThreadsafeXorShiftRandom I committed in 2.2.x. Imo this also creates the unpredictability we need. Even if the random sequence can be predicted if you know the algorighm and the former seed value, you actually don't know which thread you will hit next and if there are requests from different users inbetween. In any case it's way superior than just adding the viewId which always remains the same. Define default view key algorithm - Key: MYFACES-3652 URL: https://issues.apache.org/jira/browse/MYFACES-3652 Project: MyFaces Core Issue Type: Sub-task Components: JSR-344 Affects Versions: 2.2.0, 2.1.9 Reporter: Mark Struberg Assignee: Mark Struberg Currently we have a few different viewkey generator implementations. Those got added only in 2.1.9. Before that the only had a TicketCounter in each Session. The original implementation also had no viewId in the key. If you think about it, then it makes no sense at all to add the viewId. Despite it's an int hashCode we have 2 problems which completely trashes the purpose: a.) hashCode is not guaranteed to be unique b.) the hashCode is always the same for the same view. Think about an application with only one xhtml page. In that case the viewId would add no additional info. With 4 pages you would only reduce the collision rate to over 25%. Since the application will most times mainly hit by a few entry points like index.html you gain barely anything from adding this information. IF we have had problems with any collisions, then we shall add an XorShift random generator instead of the viewId. Leo, I didn't an issue report for such a problem. Do you have any tip for me where I can find that? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3655) add pluggable Serialization strategies
Mark Struberg created MYFACES-3655: -- Summary: add pluggable Serialization strategies Key: MYFACES-3655 URL: https://issues.apache.org/jira/browse/MYFACES-3655 Project: MyFaces Core Issue Type: Bug Components: JSR-344 Affects Versions: 2.2.0 Reporter: Mark Struberg Assignee: Mark Struberg We might check if we can get an even better performance by using a different serialisation strategy. This might heavily improve the performance of ClientSideStateSaving and ViewMap serialisation(if enabled). There are a few alternative libraries like XStream and Kryo available: * http://xstream.codehaus.org * http://code.google.com/p/kryo/ Thomas from the OWB team did a nice benchmark for his clustering project: http://code.google.com/p/memcached-session-manager/wiki/SerializationStrategyBenchmark Definitely worth taking a look imo. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3652) Define default view key algorithm
[ https://issues.apache.org/jira/browse/MYFACES-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501142#comment-13501142 ] Mark Struberg commented on MYFACES-3652: a few more thoughts: The xorshiftrandom is _only_ predictable if we serialize the _full_ long number to the client. So lets just cut off the two least significant bytes. Or even from somewhere in the middle. In that case we still have 48 bits random which is good enough as the sequencer is there as well. But an attacker doesn't have the seed and thus is not able to generate the next number. The hit ratio would be: 1 : 2^16 * threadcount * chance_of_other_user_request_inbetween and a new game with even better ratio on each subsequent retry. I think even unencoded this is superior to our current sequencer + viewid_hash + encoding +mac. The reason is that any encoding which only generates a low number of bytes can be cracked. And the entropy of the encoded values is really low: * the viewIdHash is easy to predict * the MAC is stable * the sequencer is easy to predict too did I miss something? Define default view key algorithm - Key: MYFACES-3652 URL: https://issues.apache.org/jira/browse/MYFACES-3652 Project: MyFaces Core Issue Type: Sub-task Components: JSR-344 Affects Versions: 2.2.0, 2.1.9 Reporter: Mark Struberg Assignee: Mark Struberg Currently we have a few different viewkey generator implementations. Those got added only in 2.1.9. Before that the only had a TicketCounter in each Session. The original implementation also had no viewId in the key. If you think about it, then it makes no sense at all to add the viewId. Despite it's an int hashCode we have 2 problems which completely trashes the purpose: a.) hashCode is not guaranteed to be unique b.) the hashCode is always the same for the same view. Think about an application with only one xhtml page. In that case the viewId would add no additional info. With 4 pages you would only reduce the collision rate to over 25%. Since the application will most times mainly hit by a few entry points like index.html you gain barely anything from adding this information. IF we have had problems with any collisions, then we shall add an XorShift random generator instead of the viewId. Leo, I didn't an issue report for such a problem. Do you have any tip for me where I can find that? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3652) Define default view key algorithm
[ https://issues.apache.org/jira/browse/MYFACES-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501150#comment-13501150 ] Mark Struberg commented on MYFACES-3652: btw: - It should not be possible to use the key for one view in other view. I do _not_ agree with this. Instead I'd say: - It must not be possible to use the key for a different request in the session. The view itself really doesn't matter. Usually XSRF happens on the same view via javascript so the viewId has not much practical impact from my experience. Define default view key algorithm - Key: MYFACES-3652 URL: https://issues.apache.org/jira/browse/MYFACES-3652 Project: MyFaces Core Issue Type: Sub-task Components: JSR-344 Affects Versions: 2.2.0, 2.1.9 Reporter: Mark Struberg Assignee: Mark Struberg Currently we have a few different viewkey generator implementations. Those got added only in 2.1.9. Before that the only had a TicketCounter in each Session. The original implementation also had no viewId in the key. If you think about it, then it makes no sense at all to add the viewId. Despite it's an int hashCode we have 2 problems which completely trashes the purpose: a.) hashCode is not guaranteed to be unique b.) the hashCode is always the same for the same view. Think about an application with only one xhtml page. In that case the viewId would add no additional info. With 4 pages you would only reduce the collision rate to over 25%. Since the application will most times mainly hit by a few entry points like index.html you gain barely anything from adding this information. IF we have had problems with any collisions, then we shall add an XorShift random generator instead of the viewId. Leo, I didn't an issue report for such a problem. Do you have any tip for me where I can find that? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3651) review/refactor/document ViewState handling in JSF-2.2
Mark Struberg created MYFACES-3651: -- Summary: review/refactor/document ViewState handling in JSF-2.2 Key: MYFACES-3651 URL: https://issues.apache.org/jira/browse/MYFACES-3651 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Reporter: Mark Struberg Assignee: Mark Struberg We currently have a few things in our ViewState handling which could get even further improved. There are 3 main goals we achieve (in order of importance): 1.) security - it should not be easily possible to create state key clashes 2.) performance - we still use java 1.3 tricks and e.g. barely use java.util.concurrent 3.) memory - we shall keep the mem footprint as low as possible -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3652) Define default view key algorithm
Mark Struberg created MYFACES-3652: -- Summary: Define default view key algorithm Key: MYFACES-3652 URL: https://issues.apache.org/jira/browse/MYFACES-3652 Project: MyFaces Core Issue Type: Sub-task Components: JSR-344 Affects Versions: 2.1.9, 2.2.0 Reporter: Mark Struberg Assignee: Mark Struberg Currently we have a few different viewkey generator implementations. Those got added only in 2.1.9. Before that the only had a TicketCounter in each Session. The original implementation also had no viewId in the key. If you think about it, then it makes no sense at all to add the viewId. Despite it's an int hashCode we have 2 problems which completely trashes the purpose: a.) hashCode is not guaranteed to be unique b.) the hashCode is always the same for the same view. Think about an application with only one xhtml page. In that case the viewId would add no additional info. With 4 pages you would only reduce the collision rate to over 25%. Since the application will most times mainly hit by a few entry points like index.html you gain barely anything from adding this information. IF we have had problems with any collisions, then we shall add an XorShift random generator instead of the viewId. Leo, I didn't an issue report for such a problem. Do you have any tip for me where I can find that? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3652) Define default view key algorithm
[ https://issues.apache.org/jira/browse/MYFACES-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13500255#comment-13500255 ] Mark Struberg commented on MYFACES-3652: Also please note that the XorShift random long generator would also easily fulfil our security requirements and allows us to get rid of the pretty expensive SecureRandom SessionIdGenerator as well. Btw no need for a pluggable ViewKey. All the abstraction is done in SessionViewStorageFactory anyway. And even this currently is not fully pluggable. We have 4 different abstractions for this area and none of them is clean atm. I prefer having slightly less but more general SPI interfaces. And fully pluggable of course! I'm not sure about StateCache. There is currently no documentation what the generic types K and V represent. But that might be a good point of abstraction granularity. Define default view key algorithm - Key: MYFACES-3652 URL: https://issues.apache.org/jira/browse/MYFACES-3652 Project: MyFaces Core Issue Type: Sub-task Components: JSR-344 Affects Versions: 2.2.0, 2.1.9 Reporter: Mark Struberg Assignee: Mark Struberg Currently we have a few different viewkey generator implementations. Those got added only in 2.1.9. Before that the only had a TicketCounter in each Session. The original implementation also had no viewId in the key. If you think about it, then it makes no sense at all to add the viewId. Despite it's an int hashCode we have 2 problems which completely trashes the purpose: a.) hashCode is not guaranteed to be unique b.) the hashCode is always the same for the same view. Think about an application with only one xhtml page. In that case the viewId would add no additional info. With 4 pages you would only reduce the collision rate to over 25%. Since the application will most times mainly hit by a few entry points like index.html you gain barely anything from adding this information. IF we have had problems with any collisions, then we shall add an XorShift random generator instead of the viewId. Leo, I didn't an issue report for such a problem. Do you have any tip for me where I can find that? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3654) implement small threadsafe Random algorithm
Mark Struberg created MYFACES-3654: -- Summary: implement small threadsafe Random algorithm Key: MYFACES-3654 URL: https://issues.apache.org/jira/browse/MYFACES-3654 Project: MyFaces Core Issue Type: Sub-task Components: JSR-344 Affects Versions: 2.2.0 Reporter: Mark Struberg Assignee: Mark Struberg java.util.Random always locks and thus creates a bottleneck in heavy threaded server scenarios. In Java 7 a new ThreadLocalRandom got introduced which fixes that but we cannot use this as we still need to support java5 and 6. The algorithm used in java.util.Random also is not the best in terms of spreading. I propose to introduce a small XorShift random generator which has a very good spreading and is vastly faster than java.util.Random as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MYFACES-3654) implement small threadsafe Random algorithm
[ https://issues.apache.org/jira/browse/MYFACES-3654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved MYFACES-3654. Resolution: Fixed Fix Version/s: 2.2.0 implement small threadsafe Random algorithm --- Key: MYFACES-3654 URL: https://issues.apache.org/jira/browse/MYFACES-3654 Project: MyFaces Core Issue Type: Sub-task Components: JSR-344 Affects Versions: 2.2.0 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 2.2.0 java.util.Random always locks and thus creates a bottleneck in heavy threaded server scenarios. In Java 7 a new ThreadLocalRandom got introduced which fixes that but we cannot use this as we still need to support java5 and 6. The algorithm used in java.util.Random also is not the best in terms of spreading. I propose to introduce a small XorShift random generator which has a very good spreading and is vastly faster than java.util.Random as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3654) implement small threadsafe Random algorithm
[ https://issues.apache.org/jira/browse/MYFACES-3654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13500481#comment-13500481 ] Mark Struberg commented on MYFACES-3654: implemented in XorShiftRandom and ThreadsafeXorShiftRandom implement small threadsafe Random algorithm --- Key: MYFACES-3654 URL: https://issues.apache.org/jira/browse/MYFACES-3654 Project: MyFaces Core Issue Type: Sub-task Components: JSR-344 Affects Versions: 2.2.0 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 2.2.0 java.util.Random always locks and thus creates a bottleneck in heavy threaded server scenarios. In Java 7 a new ThreadLocalRandom got introduced which fixes that but we cannot use this as we still need to support java5 and 6. The algorithm used in java.util.Random also is not the best in terms of spreading. I propose to introduce a small XorShift random generator which has a very good spreading and is vastly faster than java.util.Random as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3648) some jsf files contain illegal UTF characters
Mark Struberg created MYFACES-3648: -- Summary: some jsf files contain illegal UTF characters Key: MYFACES-3648 URL: https://issues.apache.org/jira/browse/MYFACES-3648 Project: MyFaces Core Issue Type: Bug Components: JSR-344 Affects Versions: 2.2.0 Reporter: Mark Struberg Assignee: Mark Struberg some jsf files contain illegal UTF characters and thus our 2.2 build is broken -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MYFACES-3648) some jsf files contain illegal UTF characters
[ https://issues.apache.org/jira/browse/MYFACES-3648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved MYFACES-3648. Resolution: Fixed Fix Version/s: 2.2.0 some jsf files contain illegal UTF characters - Key: MYFACES-3648 URL: https://issues.apache.org/jira/browse/MYFACES-3648 Project: MyFaces Core Issue Type: Bug Components: JSR-344 Affects Versions: 2.2.0 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 2.2.0 some jsf files contain illegal UTF characters and thus our 2.2 build is broken -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3649) myfaces-shaded-impl always unpacks myfaces-2.1.1
Mark Struberg created MYFACES-3649: -- Summary: myfaces-shaded-impl always unpacks myfaces-2.1.1 Key: MYFACES-3649 URL: https://issues.apache.org/jira/browse/MYFACES-3649 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 2.1.9, 2.2.0, 2.1.10 Reporter: Mark Struberg Assignee: Mark Struberg Priority: Blocker myfaces-shared-impl hardcoded unpacks mf-2.1.1 right now. How can this work? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3649) myfaces-shaded-impl always unpacks myfaces-2.1.1
[
https://issues.apache.org/jira/browse/MYFACES-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13498690#comment-13498690
]
Mark Struberg commented on MYFACES-3649:
I added the implicit dependency and got the following:
[ERROR] The projects in the reactor contain a cyclic reference: Edge between
'Vertex{label='org.apache.myfaces.core:myfaces-impl:2.1.10-SNAPSHOT'}' and
'Vertex{label='org.apache.myfaces.core.internal:myfaces-impl-ee6:2.1.10-SNAPSHOT'}'
introduces to cycle in the graph
org.apache.myfaces.core.internal:myfaces-impl-ee6:2.1.10-SNAPSHOT --
org.apache.myfaces.core.internal:myfaces-shaded-impl:2.1.10-SNAPSHOT --
org.apache.myfaces.core:myfaces-impl:2.1.10-SNAPSHOT --
org.apache.myfaces.core.internal:myfaces-impl-ee6:2.1.10-SNAPSHOT - [Help 1]
And guess what? Maven is right! We have a perfect build cycle which messes up
all our releases.
myfaces-shaded-impl always unpacks myfaces-2.1.1
Key: MYFACES-3649
URL: https://issues.apache.org/jira/browse/MYFACES-3649
Project: MyFaces Core
Issue Type: Bug
Components: build process
Affects Versions: 2.2.0, 2.1.9, 2.1.10
Reporter: Mark Struberg
Assignee: Mark Struberg
Priority: Blocker
myfaces-shared-impl hardcoded unpacks mf-2.1.1 right now. How can this work?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3649) myfaces-shaded-impl always unpacks myfaces-2.1.1
[ https://issues.apache.org/jira/browse/MYFACES-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13498702#comment-13498702 ] Mark Struberg commented on MYFACES-3649: This can only properly get resolved by removing the cycle. Currently the ee6 module only contains the MyFacesContainerInitializer. It is perfectly fine to keep this in core-impl as this class will not even get loaded. Upgrading core-impl to servlet-3.0 is also much easier than doing all this dirty hacks. We already effectively ship the ServletContainerInitializer with our jars since 2.0.5 anyway. So what? We might think about adding a CI profile which excludes the ee6 package and compiles with servlet-2.5. The clean alternative would be to keep core-impl servlet-2.5 and ship an additional artifact for ee6. myfaces-shaded-impl always unpacks myfaces-2.1.1 Key: MYFACES-3649 URL: https://issues.apache.org/jira/browse/MYFACES-3649 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 2.2.0, 2.1.9, 2.1.10 Reporter: Mark Struberg Assignee: Mark Struberg Priority: Blocker myfaces-shared-impl hardcoded unpacks mf-2.1.1 right now. How can this work? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3650) myfaces-2.2.x poms not properly set up
Mark Struberg created MYFACES-3650: -- Summary: myfaces-2.2.x poms not properly set up Key: MYFACES-3650 URL: https://issues.apache.org/jira/browse/MYFACES-3650 Project: MyFaces Core Issue Type: Bug Components: JSR-344 Affects Versions: 2.2.0 Reporter: Mark Struberg Assignee: Mark Struberg the current 2.2.x branch contains a few 2.2.0-SNAPSHOT dependencies and a few to 2.1.x. That all should get moved to 2.2.0-SNAPSHOT -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3648) some jsf files contain illegal UTF characters
[ https://issues.apache.org/jira/browse/MYFACES-3648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13498902#comment-13498902 ] Mark Struberg commented on MYFACES-3648: maven scm URLs are also all still referring to trunk some jsf files contain illegal UTF characters - Key: MYFACES-3648 URL: https://issues.apache.org/jira/browse/MYFACES-3648 Project: MyFaces Core Issue Type: Bug Components: JSR-344 Affects Versions: 2.2.0 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 2.2.0 some jsf files contain illegal UTF characters and thus our 2.2 build is broken -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3649) myfaces-shaded-impl always unpacks myfaces-2.1.1
[ https://issues.apache.org/jira/browse/MYFACES-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13498965#comment-13498965 ] Mark Struberg commented on MYFACES-3649: It is perfectly possible to do both in core/impl. See the ee5 profile I added in core/impl/pom.xml The trick is to do the 'standard' compile with servlet-3.0 and add an ee5 profile which we can run in CI. This ee5 profile switches the build to servlet-2.5 and excludes the org.apache.myfaces.ee6 package in the maven-compiler-plugin configuration. This works already. I'm now just removing the leftovers which are not used anymore. myfaces-shaded-impl always unpacks myfaces-2.1.1 Key: MYFACES-3649 URL: https://issues.apache.org/jira/browse/MYFACES-3649 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 2.2.0, 2.1.9, 2.1.10 Reporter: Mark Struberg Assignee: Mark Struberg Priority: Blocker Attachments: myfaces-3649.patch myfaces-shared-impl hardcoded unpacks mf-2.1.1 right now. How can this work? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MYFACES-3649) myfaces-shaded-impl always unpacks myfaces-2.1.1
[ https://issues.apache.org/jira/browse/MYFACES-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved MYFACES-3649. Resolution: Fixed Fix Version/s: 2.1.10 2.2.0 fixed by completely getting rid of implee6 and shaded-impl myfaces-shaded-impl always unpacks myfaces-2.1.1 Key: MYFACES-3649 URL: https://issues.apache.org/jira/browse/MYFACES-3649 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 2.2.0, 2.1.9, 2.1.10 Reporter: Mark Struberg Assignee: Mark Struberg Priority: Blocker Fix For: 2.2.0, 2.1.10 Attachments: myfaces-3649.patch myfaces-shared-impl hardcoded unpacks mf-2.1.1 right now. How can this work? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MYFACES-3650) myfaces-2.2.x poms not properly set up
[ https://issues.apache.org/jira/browse/MYFACES-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved MYFACES-3650. Resolution: Fixed Fix Version/s: 2.2.0 myfaces-2.2.x poms not properly set up -- Key: MYFACES-3650 URL: https://issues.apache.org/jira/browse/MYFACES-3650 Project: MyFaces Core Issue Type: Bug Components: JSR-344 Affects Versions: 2.2.0 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 2.2.0 the current 2.2.x branch contains a few 2.2.0-SNAPSHOT dependencies and a few to 2.1.x. That all should get moved to 2.2.0-SNAPSHOT -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3642) enable console output for checkstyle
Mark Struberg created MYFACES-3642: -- Summary: enable console output for checkstyle Key: MYFACES-3642 URL: https://issues.apache.org/jira/browse/MYFACES-3642 Project: MyFaces Core Issue Type: Improvement Components: Master POM Reporter: Mark Struberg Assignee: Mark Struberg maven-checkstyle-plugin has an option to output checkstyle errors to the console. That makes it easier to fix them. I'll enable this configuration in our master pom. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MYFACES-3642) enable console output for checkstyle
[ https://issues.apache.org/jira/browse/MYFACES-3642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved MYFACES-3642. Resolution: Fixed fixed in myfaces parent 15 enable console output for checkstyle Key: MYFACES-3642 URL: https://issues.apache.org/jira/browse/MYFACES-3642 Project: MyFaces Core Issue Type: Improvement Components: Master POM Reporter: Mark Struberg Assignee: Mark Struberg maven-checkstyle-plugin has an option to output checkstyle errors to the console. That makes it easier to fix them. I'll enable this configuration in our master pom. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3643) upgrade myfaces parent to apache-parent 12
Mark Struberg created MYFACES-3643: -- Summary: upgrade myfaces parent to apache-parent 12 Key: MYFACES-3643 URL: https://issues.apache.org/jira/browse/MYFACES-3643 Project: MyFaces Core Issue Type: Improvement Components: Master POM Reporter: Mark Struberg Assignee: Mark Struberg there is an apache parent 12 available already which upgrades lots of system dependencies. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MYFACES-3643) upgrade myfaces parent to apache-parent 12
[ https://issues.apache.org/jira/browse/MYFACES-3643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved MYFACES-3643. Resolution: Fixed fixed in myfaces-parent 15 upgrade myfaces parent to apache-parent 12 -- Key: MYFACES-3643 URL: https://issues.apache.org/jira/browse/MYFACES-3643 Project: MyFaces Core Issue Type: Improvement Components: Master POM Reporter: Mark Struberg Assignee: Mark Struberg there is an apache parent 12 available already which upgrades lots of system dependencies. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3644) cleanup ViewState handling
Mark Struberg created MYFACES-3644: -- Summary: cleanup ViewState handling Key: MYFACES-3644 URL: https://issues.apache.org/jira/browse/MYFACES-3644 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Reporter: Mark Struberg Assignee: Mark Struberg Currently our ViewState handling is pretty complicated. We shall review it and get rid of unused stuff. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MYFACES-3638) NPE in ServerSideStateCacheImpl
[
https://issues.apache.org/jira/browse/MYFACES-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved MYFACES-3638.
Resolution: Fixed
NPE in ServerSideStateCacheImpl
---
Key: MYFACES-3638
URL: https://issues.apache.org/jira/browse/MYFACES-3638
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.9
Reporter: Mark Struberg
Assignee: Mark Struberg
Fix For: 2.0.16, 2.1.10
Attachments: MYFACES-3638-alternate-fix-1.patch, MYFACES-3638.patch,
MYFACES-3638-proposal.diff
I'm getting the following NPE when having a request which leads to a 404:
{code}
Nov 9 09:00:45 j02 java.lang.NullPointerException
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl$CounterSessionViewStorageFactory.createSerializedViewKey(ServerSideStateCacheImpl.java:1413)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl$CounterSessionViewStorageFactory.createSerializedViewKey(ServerSideStateCacheImpl.java:1392)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl.saveSerializedViewInServletSession(ServerSideStateCacheImpl.java:318)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl.saveSerializedView(ServerSideStateCacheImpl.java:1036)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.html.HtmlResponseStateManager.saveState(HtmlResponseStateManager.java:149)
Nov 9 09:00:45 j02 at
org.apache.myfaces.application.StateManagerImpl.saveView(StateManagerImpl.java:253)
Nov 9 09:00:45 j02 at
org.apache.myfaces.shared.view.JspViewDeclarationLanguageBase.renderView(JspViewDeclarationLanguageBase.java:221)
Nov 9 09:00:45 j02 at
org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
org.apache.myfaces.tomahawk.application.ResourceViewHandlerWrapper.renderView(ResourceViewHandlerWrapper.java:93)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116)
Nov 9 09:00:45 j02 at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
Nov 9 09:00:45 j02 at
org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.render(CodiLifecycleWrapper.java:126)
Nov 9 09:00:45 j02 at
javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3645) review/refactor/document ViewState handling
Mark Struberg created MYFACES-3645: -- Summary: review/refactor/document ViewState handling Key: MYFACES-3645 URL: https://issues.apache.org/jira/browse/MYFACES-3645 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Reporter: Mark Struberg Assignee: Mark Struberg We currently have a few things in our ViewState handling which could get even further improved. There are 3 main goals we achieve (in order of importance): 1.) security - it should not be easily possible to create state key clashes 2.) performance - we still use java 1.3 tricks and e.g. barely use java.util.concurrent 3.) memory - we shall keep the mem footprint as low as possible -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3645) review/refactor/document ViewState handling
[ https://issues.apache.org/jira/browse/MYFACES-3645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13498102#comment-13498102 ] Mark Struberg commented on MYFACES-3645: quite some configuration gets resolved every request it seems. We should only resolve this config once and store it in the Application. review/refactor/document ViewState handling --- Key: MYFACES-3645 URL: https://issues.apache.org/jira/browse/MYFACES-3645 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Reporter: Mark Struberg Assignee: Mark Struberg We currently have a few things in our ViewState handling which could get even further improved. There are 3 main goals we achieve (in order of importance): 1.) security - it should not be easily possible to create state key clashes 2.) performance - we still use java 1.3 tricks and e.g. barely use java.util.concurrent 3.) memory - we shall keep the mem footprint as low as possible -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3646) remove unused src/main/old from core-impl
Mark Struberg created MYFACES-3646: -- Summary: remove unused src/main/old from core-impl Key: MYFACES-3646 URL: https://issues.apache.org/jira/browse/MYFACES-3646 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.1.9 Reporter: Mark Struberg Assignee: Mark Struberg This seems to be an unused leftover from ancient times. Let's get rid of it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3647) remove JspStateManagerImpl and other unused stuff in this area
Mark Struberg created MYFACES-3647: -- Summary: remove JspStateManagerImpl and other unused stuff in this area Key: MYFACES-3647 URL: https://issues.apache.org/jira/browse/MYFACES-3647 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.1.9 Reporter: Mark Struberg Assignee: Mark Struberg JspStateManagerImpl and a few other classes usage got remove a long time it seems. Nontheless this classes still are in the code and make it hard to read and maintain the codebase. Let's just drop it! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MYFACES-3646) remove unused src/main/old from core-impl
[ https://issues.apache.org/jira/browse/MYFACES-3646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved MYFACES-3646. Resolution: Fixed Fix Version/s: 2.1.10 remove unused src/main/old from core-impl - Key: MYFACES-3646 URL: https://issues.apache.org/jira/browse/MYFACES-3646 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.1.9 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 2.1.10 This seems to be an unused leftover from ancient times. Let's get rid of it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (MYFACES-3647) remove JspStateManagerImpl and other unused stuff in this area
[ https://issues.apache.org/jira/browse/MYFACES-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13498656#comment-13498656 ] Mark Struberg edited comment on MYFACES-3647 at 11/16/12 7:31 AM: -- no, deferred to 2.1.11 or 2.2 depending on the VOTE which is currently running! You still didn't proof that this is still used! All your arguments in this direction so far got trashed in the ground. was (Author: struberg): no, deferred to 2.1.11 or 2.2 depending on the VOTE which is currently running! remove JspStateManagerImpl and other unused stuff in this area -- Key: MYFACES-3647 URL: https://issues.apache.org/jira/browse/MYFACES-3647 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Mark Struberg Assignee: Mark Struberg JspStateManagerImpl and a few other classes usage got remove a long time it seems. Nontheless this classes still are in the code and make it hard to read and maintain the codebase. Let's just drop it! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3647) remove JspStateManagerImpl and other unused stuff in this area
[ https://issues.apache.org/jira/browse/MYFACES-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13498656#comment-13498656 ] Mark Struberg commented on MYFACES-3647: no, deferred to 2.1.11 or 2.2 depending on the VOTE which is currently running! remove JspStateManagerImpl and other unused stuff in this area -- Key: MYFACES-3647 URL: https://issues.apache.org/jira/browse/MYFACES-3647 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Mark Struberg Assignee: Mark Struberg JspStateManagerImpl and a few other classes usage got remove a long time it seems. Nontheless this classes still are in the code and make it hard to read and maintain the codebase. Let's just drop it! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MYFACES-3638) NPE in ServerSideStateCacheImpl
[
https://issues.apache.org/jira/browse/MYFACES-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg updated MYFACES-3638:
---
Resolution: Fixed
Fix Version/s: 2.1.10
Status: Resolved (was: Patch Available)
patch committed as well. txs to Bütt for the patch
NPE in ServerSideStateCacheImpl
---
Key: MYFACES-3638
URL: https://issues.apache.org/jira/browse/MYFACES-3638
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.9
Reporter: Mark Struberg
Assignee: Mark Struberg
Fix For: 2.1.10
Attachments: MYFACES-3638.patch
I'm getting the following NPE when having a request which leads to a 404:
{code}
Nov 9 09:00:45 j02 java.lang.NullPointerException
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl$CounterSessionViewStorageFactory.createSerializedViewKey(ServerSideStateCacheImpl.java:1413)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl$CounterSessionViewStorageFactory.createSerializedViewKey(ServerSideStateCacheImpl.java:1392)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl.saveSerializedViewInServletSession(ServerSideStateCacheImpl.java:318)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl.saveSerializedView(ServerSideStateCacheImpl.java:1036)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.html.HtmlResponseStateManager.saveState(HtmlResponseStateManager.java:149)
Nov 9 09:00:45 j02 at
org.apache.myfaces.application.StateManagerImpl.saveView(StateManagerImpl.java:253)
Nov 9 09:00:45 j02 at
org.apache.myfaces.shared.view.JspViewDeclarationLanguageBase.renderView(JspViewDeclarationLanguageBase.java:221)
Nov 9 09:00:45 j02 at
org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
org.apache.myfaces.tomahawk.application.ResourceViewHandlerWrapper.renderView(ResourceViewHandlerWrapper.java:93)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116)
Nov 9 09:00:45 j02 at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
Nov 9 09:00:45 j02 at
org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.render(CodiLifecycleWrapper.java:126)
Nov 9 09:00:45 j02 at
javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (MYFACES-3641) ViewDeclarationLanguageFactoryImpl.getViewDeclarationLanguage(String viewId) should not throw exception if no associate VDL can be found
[ https://issues.apache.org/jira/browse/MYFACES-3641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reopened MYFACES-3641: Assignee: Mark Struberg (was: Leonardo Uribe) Leo, it's just plain to rely on a hash for a key which must be ensured to be unique! I gonna open a VOTE about principal design rules and in the meantime revert your commit ViewDeclarationLanguageFactoryImpl.getViewDeclarationLanguage(String viewId) should not throw exception if no associate VDL can be found Key: MYFACES-3641 URL: https://issues.apache.org/jira/browse/MYFACES-3641 Project: MyFaces Core Issue Type: Bug Reporter: Leonardo Uribe Assignee: Mark Struberg Fix For: 2.0.16, 2.1.10 This exception is thrown from ViewDeclarationLanguageFactoryImpl.getViewDeclarationLanguage(String viewId): javax.faces.FacesException: Cannot find a valid PDL for view id /hxome.view.xml org.apache.myfaces.view.ViewDeclarationLanguageFactoryImpl.getViewDeclarationLanguage(ViewDeclarationLanguageFactoryImpl.java:93) org.apache.myfaces.application.ViewHandlerImpl.getViewDeclarationLanguage(ViewHandlerImpl.java:179) org.apache.myfaces.shared.application.DefaultViewHandlerSupport.checkResourceExists(DefaultViewHandlerSupport.java:546) org.apache.myfaces.shared.application.DefaultViewHandlerSupport.handleSuffixMapping(DefaultViewHandlerSupport.java:484) org.apache.myfaces.shared.application.DefaultViewHandlerSupport.calculateViewId(DefaultViewHandlerSupport.java:114) org.apache.myfaces.application.ViewHandlerImpl.deriveLogicalViewId(ViewHandlerImpl.java:118) org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:157) org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:170) org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117) javax.faces.webapp.FacesServlet.service(FacesServlet.java:197) Instead throw an exception it return null, which indicates that the viewId has not associate VDL. Other algorithms in myfaces has already expect that, like DefaultViewHandlerSupport.checkResourceExists() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (MYFACES-3638) NPE in ServerSideStateCacheImpl
[
https://issues.apache.org/jira/browse/MYFACES-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg reopened MYFACES-3638:
NPE in ServerSideStateCacheImpl
---
Key: MYFACES-3638
URL: https://issues.apache.org/jira/browse/MYFACES-3638
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.9
Reporter: Mark Struberg
Assignee: Mark Struberg
Fix For: 2.0.16, 2.1.10
Attachments: MYFACES-3638-alternate-fix-1.patch, MYFACES-3638.patch,
MYFACES-3638-proposal.diff
I'm getting the following NPE when having a request which leads to a 404:
{code}
Nov 9 09:00:45 j02 java.lang.NullPointerException
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl$CounterSessionViewStorageFactory.createSerializedViewKey(ServerSideStateCacheImpl.java:1413)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl$CounterSessionViewStorageFactory.createSerializedViewKey(ServerSideStateCacheImpl.java:1392)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl.saveSerializedViewInServletSession(ServerSideStateCacheImpl.java:318)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl.saveSerializedView(ServerSideStateCacheImpl.java:1036)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.html.HtmlResponseStateManager.saveState(HtmlResponseStateManager.java:149)
Nov 9 09:00:45 j02 at
org.apache.myfaces.application.StateManagerImpl.saveView(StateManagerImpl.java:253)
Nov 9 09:00:45 j02 at
org.apache.myfaces.shared.view.JspViewDeclarationLanguageBase.renderView(JspViewDeclarationLanguageBase.java:221)
Nov 9 09:00:45 j02 at
org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
org.apache.myfaces.tomahawk.application.ResourceViewHandlerWrapper.renderView(ResourceViewHandlerWrapper.java:93)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116)
Nov 9 09:00:45 j02 at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
Nov 9 09:00:45 j02 at
org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.render(CodiLifecycleWrapper.java:126)
Nov 9 09:00:45 j02 at
javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3638) NPE in ServerSideStateCacheImpl
Mark Struberg created MYFACES-3638:
--
Summary: NPE in ServerSideStateCacheImpl
Key: MYFACES-3638
URL: https://issues.apache.org/jira/browse/MYFACES-3638
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.9
Reporter: Mark Struberg
Assignee: Mark Struberg
I'm getting the following NPE when having a request which leads to a 404:
{code}
Nov 9 09:00:45 j02 java.lang.NullPointerException
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl$CounterSessionViewStorageFactory.createSerializedViewKey(ServerSideStateCacheImpl.java:1413)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl$CounterSessionViewStorageFactory.createSerializedViewKey(ServerSideStateCacheImpl.java:1392)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl.saveSerializedViewInServletSession(ServerSideStateCacheImpl.java:318)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl.saveSerializedView(ServerSideStateCacheImpl.java:1036)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.html.HtmlResponseStateManager.saveState(HtmlResponseStateManager.java:149)
Nov 9 09:00:45 j02 at
org.apache.myfaces.application.StateManagerImpl.saveView(StateManagerImpl.java:253)
Nov 9 09:00:45 j02 at
org.apache.myfaces.shared.view.JspViewDeclarationLanguageBase.renderView(JspViewDeclarationLanguageBase.java:221)
Nov 9 09:00:45 j02 at
org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
org.apache.myfaces.tomahawk.application.ResourceViewHandlerWrapper.renderView(ResourceViewHandlerWrapper.java:93)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116)
Nov 9 09:00:45 j02 at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
Nov 9 09:00:45 j02 at
org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.render(CodiLifecycleWrapper.java:126)
Nov 9 09:00:45 j02 at
javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3638) NPE in ServerSideStateCacheImpl
[
https://issues.apache.org/jira/browse/MYFACES-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13496485#comment-13496485
]
Mark Struberg commented on MYFACES-3638:
That sounds perfectly reasonable.
Is there some edge case where the FaceletViewDeclarationLanguage could have the
same problem?
And what about error pages afterwards? If we set responseComplete() does this
have some effect on the error handling on our side?
Will need to think through the different use cases.
In any case the caching algorithm needs improvement and can be done much
simpler without affecting the performance. The current impl potentially creates
key clashes and must get fixed anyway. I'm working on that already.
NPE in ServerSideStateCacheImpl
---
Key: MYFACES-3638
URL: https://issues.apache.org/jira/browse/MYFACES-3638
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.9
Reporter: Mark Struberg
Assignee: Mark Struberg
Attachments: MYFACES-3638.patch
I'm getting the following NPE when having a request which leads to a 404:
{code}
Nov 9 09:00:45 j02 java.lang.NullPointerException
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl$CounterSessionViewStorageFactory.createSerializedViewKey(ServerSideStateCacheImpl.java:1413)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl$CounterSessionViewStorageFactory.createSerializedViewKey(ServerSideStateCacheImpl.java:1392)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl.saveSerializedViewInServletSession(ServerSideStateCacheImpl.java:318)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl.saveSerializedView(ServerSideStateCacheImpl.java:1036)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.html.HtmlResponseStateManager.saveState(HtmlResponseStateManager.java:149)
Nov 9 09:00:45 j02 at
org.apache.myfaces.application.StateManagerImpl.saveView(StateManagerImpl.java:253)
Nov 9 09:00:45 j02 at
org.apache.myfaces.shared.view.JspViewDeclarationLanguageBase.renderView(JspViewDeclarationLanguageBase.java:221)
Nov 9 09:00:45 j02 at
org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
org.apache.myfaces.tomahawk.application.ResourceViewHandlerWrapper.renderView(ResourceViewHandlerWrapper.java:93)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116)
Nov 9 09:00:45 j02 at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
Nov 9 09:00:45 j02 at
org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.render(CodiLifecycleWrapper.java:126)
Nov 9 09:00:45 j02 at
javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3638) NPE in ServerSideStateCacheImpl
[
https://issues.apache.org/jira/browse/MYFACES-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13496608#comment-13496608
]
Mark Struberg commented on MYFACES-3638:
I've committed a refactoring of that area which solves the key clashes and also
the NPE.
We might additionally add the attached patch, but this needs an in depth review
of the possible error handling scenarios first.
NPE in ServerSideStateCacheImpl
---
Key: MYFACES-3638
URL: https://issues.apache.org/jira/browse/MYFACES-3638
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.9
Reporter: Mark Struberg
Assignee: Mark Struberg
Attachments: MYFACES-3638.patch
I'm getting the following NPE when having a request which leads to a 404:
{code}
Nov 9 09:00:45 j02 java.lang.NullPointerException
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl$CounterSessionViewStorageFactory.createSerializedViewKey(ServerSideStateCacheImpl.java:1413)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl$CounterSessionViewStorageFactory.createSerializedViewKey(ServerSideStateCacheImpl.java:1392)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl.saveSerializedViewInServletSession(ServerSideStateCacheImpl.java:318)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl.saveSerializedView(ServerSideStateCacheImpl.java:1036)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.html.HtmlResponseStateManager.saveState(HtmlResponseStateManager.java:149)
Nov 9 09:00:45 j02 at
org.apache.myfaces.application.StateManagerImpl.saveView(StateManagerImpl.java:253)
Nov 9 09:00:45 j02 at
org.apache.myfaces.shared.view.JspViewDeclarationLanguageBase.renderView(JspViewDeclarationLanguageBase.java:221)
Nov 9 09:00:45 j02 at
org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
org.apache.myfaces.tomahawk.application.ResourceViewHandlerWrapper.renderView(ResourceViewHandlerWrapper.java:93)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116)
Nov 9 09:00:45 j02 at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
Nov 9 09:00:45 j02 at
org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.render(CodiLifecycleWrapper.java:126)
Nov 9 09:00:45 j02 at
javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3638) NPE in ServerSideStateCacheImpl
[
https://issues.apache.org/jira/browse/MYFACES-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13496705#comment-13496705
]
Mark Struberg commented on MYFACES-3638:
The sequenceId is not even used in the problematic code. It solely compares the
viewIds.
NPE in ServerSideStateCacheImpl
---
Key: MYFACES-3638
URL: https://issues.apache.org/jira/browse/MYFACES-3638
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.9
Reporter: Mark Struberg
Assignee: Mark Struberg
Attachments: MYFACES-3638.patch
I'm getting the following NPE when having a request which leads to a 404:
{code}
Nov 9 09:00:45 j02 java.lang.NullPointerException
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl$CounterSessionViewStorageFactory.createSerializedViewKey(ServerSideStateCacheImpl.java:1413)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl$CounterSessionViewStorageFactory.createSerializedViewKey(ServerSideStateCacheImpl.java:1392)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl.saveSerializedViewInServletSession(ServerSideStateCacheImpl.java:318)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl.saveSerializedView(ServerSideStateCacheImpl.java:1036)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.html.HtmlResponseStateManager.saveState(HtmlResponseStateManager.java:149)
Nov 9 09:00:45 j02 at
org.apache.myfaces.application.StateManagerImpl.saveView(StateManagerImpl.java:253)
Nov 9 09:00:45 j02 at
org.apache.myfaces.shared.view.JspViewDeclarationLanguageBase.renderView(JspViewDeclarationLanguageBase.java:221)
Nov 9 09:00:45 j02 at
org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
org.apache.myfaces.tomahawk.application.ResourceViewHandlerWrapper.renderView(ResourceViewHandlerWrapper.java:93)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116)
Nov 9 09:00:45 j02 at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
Nov 9 09:00:45 j02 at
org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.render(CodiLifecycleWrapper.java:126)
Nov 9 09:00:45 j02 at
javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3104) MyFaces 2 with EL 2.2 in Websphere 7
[
https://issues.apache.org/jira/browse/MYFACES-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13488809#comment-13488809
]
Mark Struberg commented on MYFACES-3104:
what would be the benefit of using the full JSF lifecycle for resources? There
is no data which needs to be validated/converted/applied, etc.
Btw I personally recommended to NOT use EL and other dynamic stuff in JSF
resources! This is just painfully slow and erroneous.
Reason is that resources most likely get cached by browsers (default is 14
days). So if you e.g. resolve the language via ln=.. it will only be evaluated
at the first resource request. And if the user switches his language later on
this change gets completely ignored.
You can use MyFaces shared ResourceHandler which treats JSF resources
REST-fully and thus are fully cachable. This also introduces a version so you
can upgrade your JavaScripts, CSS etc _without_ having to wait 14 days for all
Clients to pick it up properly ;)
We discussed this with Ed quite some time ago and it got proposed to be fixed
in JSF-2.2, but not sure if that issue made it to the final list...
MyFaces 2 with EL 2.2 in Websphere 7
Key: MYFACES-3104
URL: https://issues.apache.org/jira/browse/MYFACES-3104
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.0.4
Environment: WebSphere Platform 7.0.0.13
Host Operating System is Windows XP, version 5.1 build 2600 Service Pack 3
Java version = 1.6.0, Java Compiler = j9jit24, Java VM name = IBM J9 VM
Servlet API : 2.5
JSP API : 2.1
Reporter: mansour
Attachments: MyFacesEL2Sample_was7.zip
We have followed your documentation on the wiki in order to enable EL 2.2
(http://wiki.apache.org/myfaces/HowToEnableEl22), it doesn't work on
Websphere 7.
- we have added the 2 jars (el-api-2.2.jar and el-impl-2.2.jar from Glassfish
implementation) in th classpath of the web application
- we have configured the web.xml like this :
context-param
param-nameorg.apache.myfaces.EXPRESSION_FACTORY/param-name
param-valuecom.sun.el.ExpressionFactoryImpl/param-value
/context-param
[...]
listener
listener-classorg.apache.myfaces.webapp.StartupServletContextListener/listener-class
/listener
The web application starts without errors,
Problem :
1) When the web application starts we have this first exception :
[04/04/11 11:24:39:136 CEST] 000a DefaultFacesC I Reading standard
config META-INF/standard-faces-config.xml
[04/04/11 11:24:39:277 CEST] 000a DefaultFacesC I Reading config
/WEB-INF/faces-config.xml
[04/04/11 11:24:39:823 CEST] 000a ExternalSpeci I MyFaces Bean
Validation support disabled
[04/04/11 11:24:39:855 CEST] 000a ApplicationIm I Couldn't discover the
current project stage, using Production
[04/04/11 11:24:39:855 CEST] 000a FacesConfigur I Serialization
provider : class
org.apache.myfaces.shared_impl.util.serial.DefaultSerialFactory
[04/04/11 11:24:39:855 CEST] 000a DefaultLifecy I Using
LifecycleProvider
org.apache.myfaces.config.annotation.AllAnnotationLifecycleProvider
[04/04/11 11:24:39:933 CEST] 000a FfdcProvider W
com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I: Incident FFDC émis
sur
C:\IBM\SDP75\runtimes\base_v7\profiles\was70profile2\logs\ffdc\server1_48704870_11.04.04_11.24.39.8706071861720806063404.txt
com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated 1341
[04/04/11 11:24:39:933 CEST] 000a webappE
com.ibm.ws.webcontainer.webapp.WebApp notifyServletContextCreated SRVE0283E:
Exception interceptée lors de l''initialisation du contexte : {0}
java.lang.VerifyError:
javax/servlet/jsp/JspApplicationContext.addELResolver(Ljavax/el/ELResolver;)V
at
org.apache.myfaces.webapp.Jsp21FacesInitializer.configureResolverForJSP(Jsp21FacesInitializer.java:123)
at
org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:77)
at
org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:126)
at
org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:111)
at
com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:1681)
at
com.ibm.ws.webcontainer.webapp.WebApp.commonInitializationFinish(WebApp.java:374)
at
com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:299)
at
com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication(WebGroupImpl.java:100)
at
[jira] [Commented] (MYFACES-3104) MyFaces 2 with EL 2.2 in Websphere 7
[
https://issues.apache.org/jira/browse/MYFACES-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13489075#comment-13489075
]
Mark Struberg commented on MYFACES-3104:
Please check what else you have registered as ResourceHandler or
ResourceHandlerWrapper. There might be quite some code already executed before
the MyFaces RH gets invoked...
MyFaces 2 with EL 2.2 in Websphere 7
Key: MYFACES-3104
URL: https://issues.apache.org/jira/browse/MYFACES-3104
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.0.4
Environment: WebSphere Platform 7.0.0.13
Host Operating System is Windows XP, version 5.1 build 2600 Service Pack 3
Java version = 1.6.0, Java Compiler = j9jit24, Java VM name = IBM J9 VM
Servlet API : 2.5
JSP API : 2.1
Reporter: mansour
Attachments: MyFacesEL2Sample_was7.zip
We have followed your documentation on the wiki in order to enable EL 2.2
(http://wiki.apache.org/myfaces/HowToEnableEl22), it doesn't work on
Websphere 7.
- we have added the 2 jars (el-api-2.2.jar and el-impl-2.2.jar from Glassfish
implementation) in th classpath of the web application
- we have configured the web.xml like this :
context-param
param-nameorg.apache.myfaces.EXPRESSION_FACTORY/param-name
param-valuecom.sun.el.ExpressionFactoryImpl/param-value
/context-param
[...]
listener
listener-classorg.apache.myfaces.webapp.StartupServletContextListener/listener-class
/listener
The web application starts without errors,
Problem :
1) When the web application starts we have this first exception :
[04/04/11 11:24:39:136 CEST] 000a DefaultFacesC I Reading standard
config META-INF/standard-faces-config.xml
[04/04/11 11:24:39:277 CEST] 000a DefaultFacesC I Reading config
/WEB-INF/faces-config.xml
[04/04/11 11:24:39:823 CEST] 000a ExternalSpeci I MyFaces Bean
Validation support disabled
[04/04/11 11:24:39:855 CEST] 000a ApplicationIm I Couldn't discover the
current project stage, using Production
[04/04/11 11:24:39:855 CEST] 000a FacesConfigur I Serialization
provider : class
org.apache.myfaces.shared_impl.util.serial.DefaultSerialFactory
[04/04/11 11:24:39:855 CEST] 000a DefaultLifecy I Using
LifecycleProvider
org.apache.myfaces.config.annotation.AllAnnotationLifecycleProvider
[04/04/11 11:24:39:933 CEST] 000a FfdcProvider W
com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I: Incident FFDC émis
sur
C:\IBM\SDP75\runtimes\base_v7\profiles\was70profile2\logs\ffdc\server1_48704870_11.04.04_11.24.39.8706071861720806063404.txt
com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated 1341
[04/04/11 11:24:39:933 CEST] 000a webappE
com.ibm.ws.webcontainer.webapp.WebApp notifyServletContextCreated SRVE0283E:
Exception interceptée lors de l''initialisation du contexte : {0}
java.lang.VerifyError:
javax/servlet/jsp/JspApplicationContext.addELResolver(Ljavax/el/ELResolver;)V
at
org.apache.myfaces.webapp.Jsp21FacesInitializer.configureResolverForJSP(Jsp21FacesInitializer.java:123)
at
org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:77)
at
org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:126)
at
org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:111)
at
com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:1681)
at
com.ibm.ws.webcontainer.webapp.WebApp.commonInitializationFinish(WebApp.java:374)
at
com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:299)
at
com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication(WebGroupImpl.java:100)
at
com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication(VirtualHostImpl.java:166)
at
com.ibm.ws.webcontainer.WSWebContainer.addWebApp(WSWebContainer.java:731)
at
com.ibm.ws.webcontainer.WSWebContainer.addWebApplication(WSWebContainer.java:616)
at
com.ibm.ws.webcontainer.component.WebContainerImpl.install(WebContainerImpl.java:376)
at
com.ibm.ws.webcontainer.component.WebContainerImpl.start(WebContainerImpl.java:668)
at
com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:1122)
at
com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectStart(DeployedApplicationImpl.java:1319)
at
com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:609)
at
[jira] [Comment Edited] (MYFACES-3104) MyFaces 2 with EL 2.2 in Websphere 7
[
https://issues.apache.org/jira/browse/MYFACES-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13489075#comment-13489075
]
Mark Struberg edited comment on MYFACES-3104 at 11/1/12 10:17 PM:
--
Please check what else you have registered as ResourceHandler or
ResourceHandlerWrapper. There might be quite some code already executed before
the MyFaces RH gets invoked...
PS: did you already try to debug into the various HttpServletResponse methods?
was (Author: struberg):
Please check what else you have registered as ResourceHandler or
ResourceHandlerWrapper. There might be quite some code already executed before
the MyFaces RH gets invoked...
MyFaces 2 with EL 2.2 in Websphere 7
Key: MYFACES-3104
URL: https://issues.apache.org/jira/browse/MYFACES-3104
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.0.4
Environment: WebSphere Platform 7.0.0.13
Host Operating System is Windows XP, version 5.1 build 2600 Service Pack 3
Java version = 1.6.0, Java Compiler = j9jit24, Java VM name = IBM J9 VM
Servlet API : 2.5
JSP API : 2.1
Reporter: mansour
Attachments: MyFacesEL2Sample_was7.zip
We have followed your documentation on the wiki in order to enable EL 2.2
(http://wiki.apache.org/myfaces/HowToEnableEl22), it doesn't work on
Websphere 7.
- we have added the 2 jars (el-api-2.2.jar and el-impl-2.2.jar from Glassfish
implementation) in th classpath of the web application
- we have configured the web.xml like this :
context-param
param-nameorg.apache.myfaces.EXPRESSION_FACTORY/param-name
param-valuecom.sun.el.ExpressionFactoryImpl/param-value
/context-param
[...]
listener
listener-classorg.apache.myfaces.webapp.StartupServletContextListener/listener-class
/listener
The web application starts without errors,
Problem :
1) When the web application starts we have this first exception :
[04/04/11 11:24:39:136 CEST] 000a DefaultFacesC I Reading standard
config META-INF/standard-faces-config.xml
[04/04/11 11:24:39:277 CEST] 000a DefaultFacesC I Reading config
/WEB-INF/faces-config.xml
[04/04/11 11:24:39:823 CEST] 000a ExternalSpeci I MyFaces Bean
Validation support disabled
[04/04/11 11:24:39:855 CEST] 000a ApplicationIm I Couldn't discover the
current project stage, using Production
[04/04/11 11:24:39:855 CEST] 000a FacesConfigur I Serialization
provider : class
org.apache.myfaces.shared_impl.util.serial.DefaultSerialFactory
[04/04/11 11:24:39:855 CEST] 000a DefaultLifecy I Using
LifecycleProvider
org.apache.myfaces.config.annotation.AllAnnotationLifecycleProvider
[04/04/11 11:24:39:933 CEST] 000a FfdcProvider W
com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I: Incident FFDC émis
sur
C:\IBM\SDP75\runtimes\base_v7\profiles\was70profile2\logs\ffdc\server1_48704870_11.04.04_11.24.39.8706071861720806063404.txt
com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated 1341
[04/04/11 11:24:39:933 CEST] 000a webappE
com.ibm.ws.webcontainer.webapp.WebApp notifyServletContextCreated SRVE0283E:
Exception interceptée lors de l''initialisation du contexte : {0}
java.lang.VerifyError:
javax/servlet/jsp/JspApplicationContext.addELResolver(Ljavax/el/ELResolver;)V
at
org.apache.myfaces.webapp.Jsp21FacesInitializer.configureResolverForJSP(Jsp21FacesInitializer.java:123)
at
org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:77)
at
org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:126)
at
org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:111)
at
com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:1681)
at
com.ibm.ws.webcontainer.webapp.WebApp.commonInitializationFinish(WebApp.java:374)
at
com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:299)
at
com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication(WebGroupImpl.java:100)
at
com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication(VirtualHostImpl.java:166)
at
com.ibm.ws.webcontainer.WSWebContainer.addWebApp(WSWebContainer.java:731)
at
com.ibm.ws.webcontainer.WSWebContainer.addWebApplication(WSWebContainer.java:616)
at
com.ibm.ws.webcontainer.component.WebContainerImpl.install(WebContainerImpl.java:376)
at
com.ibm.ws.webcontainer.component.WebContainerImpl.start(WebContainerImpl.java:668)
at
[jira] [Created] (MYFACES-3629) StartupServletContextListener crashes if FacesServlet is defined in web-fragments.
Mark Struberg created MYFACES-3629: -- Summary: StartupServletContextListener crashes if FacesServlet is defined in web-fragments. Key: MYFACES-3629 URL: https://issues.apache.org/jira/browse/MYFACES-3629 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.1.9 Reporter: Mark Struberg I'm trying to move all my common web.xml content from my 12 webapps in an EAR into a web-fragment.xml which gets referenced. MyFaces fails with the following Exception if the FacesServlet is defined in a web-fragment rather than web.xml: If you did that and find nothing, the mistake might be due to the fact that you use some special web-containers which do not support registering context-listeners via TLD files and a context listener is not setup in your web.xml. A typical config looks like this; listener listener-classorg.apache.myfaces.webapp.StartupServletContextListener/listener-class /listener In general the StartupServletContextListener defined in JSF-2.1 is pure PITA as it does crash apps which do not have any JSF content at all!. We should scan if we either find a faces-config.xml or any *.xhtml files in the app and if not we shall not start JSF. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTCDI-298) [perf] reduce overhead in ClassUtils
[ https://issues.apache.org/jira/browse/EXTCDI-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13411441#comment-13411441 ] Mark Struberg commented on EXTCDI-298: -- please don't cache classes. This has a huge impact. The easy solution is to not run in a doPrivileged block if no SecurityManager is available. Will fix this. [perf] reduce overhead in ClassUtils Key: EXTCDI-298 URL: https://issues.apache.org/jira/browse/EXTCDI-298 Project: MyFaces CODI Issue Type: Improvement Reporter: Thomas Andraschko Assignee: Mark Struberg Attachments: EXTCDI-298.patch As discussed with gerhard, i removed the #doPriviliged which improved the method execution duration from 50ms to 0ms (30.000 invocations / request) I also added a class cache which improves loadClassForName from 62ms to 6ms for 9600 invocations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTCDI-298) [perf] reduce overhead in ClassUtils
[ https://issues.apache.org/jira/browse/EXTCDI-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13411454#comment-13411454 ] Mark Struberg commented on EXTCDI-298: -- Can you please test now? I've at least removed the doPrivileged for you. It will now only get executed if a SecurityManager is present. For fixing the loadClassForName I would need a stacktrace. And the number of times this gets called. A cache as you did it is not possible since org.mypackage.MyClass might be different for WebAppA and a WebAppB... [perf] reduce overhead in ClassUtils Key: EXTCDI-298 URL: https://issues.apache.org/jira/browse/EXTCDI-298 Project: MyFaces CODI Issue Type: Improvement Reporter: Thomas Andraschko Assignee: Mark Struberg Attachments: EXTCDI-298.patch As discussed with gerhard, i removed the #doPriviliged which improved the method execution duration from 50ms to 0ms (30.000 invocations / request) I also added a class cache which improves loadClassForName from 62ms to 6ms for 9600 invocations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTCDI-298) [perf] reduce overhead in ClassUtils
[ https://issues.apache.org/jira/browse/EXTCDI-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13411549#comment-13411549 ] Mark Struberg commented on EXTCDI-298: -- Therefore i added the classloader, too :) ok, then it's fine. But still it's much better to prevent invoking the whole chain if possible. [perf] reduce overhead in ClassUtils Key: EXTCDI-298 URL: https://issues.apache.org/jira/browse/EXTCDI-298 Project: MyFaces CODI Issue Type: Improvement Reporter: Thomas Andraschko Assignee: Mark Struberg Attachments: EXTCDI-298.patch As discussed with gerhard, i removed the #doPriviliged which improved the method execution duration from 50ms to 0ms (30.000 invocations / request) I also added a class cache which improves loadClassForName from 62ms to 6ms for 9600 invocations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (EXTCDI-258) @TransactionScoped outside of a request
[ https://issues.apache.org/jira/browse/EXTCDI-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reopened EXTCDI-258: -- we must revert this commit. This basically breaks the whole setup of @TransactionScoped beans in a CDI container. You just cannot assume that a transaction is always a single thread is not valid with async requests anymore. We really must use the platform provided mechanics for it. @TransactionScoped outside of a request --- Key: EXTCDI-258 URL: https://issues.apache.org/jira/browse/EXTCDI-258 Project: MyFaces CODI Issue Type: Improvement Components: JEE-JPA1-Module Affects Versions: 1.0.3 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 1.0.4 it should be possible to use @TransactionScoped without the need of a request -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTCDI-291) [CSWH] add UserAgent hook to ClientConfig
Mark Struberg created EXTCDI-291: Summary: [CSWH] add UserAgent hook to ClientConfig Key: EXTCDI-291 URL: https://issues.apache.org/jira/browse/EXTCDI-291 Project: MyFaces CODI Issue Type: Improvement Components: JEE-JSF20-Module Affects Versions: 1.0.5 Reporter: Mark Struberg Assignee: Mark Struberg The decision to render ClientSideWindowHandlers intermediate page is often based on the current UserAgent. It should be easier to overwrite the ClientConfig and plug in an own detection algorithm. In our project we e.g. do not use blacklisting but whitelisting (explicitely enable the intermediate page for known browsers via regexp) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTCDI-288) [CSWH] WindowContextConfig#isUnknownWindowIdsAllowed() should default to true
Mark Struberg created EXTCDI-288: Summary: [CSWH] WindowContextConfig#isUnknownWindowIdsAllowed() should default to true Key: EXTCDI-288 URL: https://issues.apache.org/jira/browse/EXTCDI-288 Project: MyFaces CODI Issue Type: Improvement Components: JEE-JSF20-Module Affects Versions: 1.0.5 Reporter: Mark Struberg Assignee: Mark Struberg If we like to support a target=xyz... then we need to allow managing of unknownWindowIds. The windowId is set by the window.name of the browser tab. This will also allow mixed operation mode with other frameworks which utilize the window.name for browser tab detection. This mode is also *essential* for EARs and portlets! Please note that this will _not_ introduce a security problem as the windowId is just a sub-context of the session (which is well protected already). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3532) Add tomcat7-maven-plugin to myfaces 2.0 archetypes
[ https://issues.apache.org/jira/browse/MYFACES-3532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258831#comment-13258831 ] Mark Struberg commented on MYFACES-3532: not only that, we should also use it in our internal tests. Will add it to CODI. There is only one nasty piece: you currently have to add a dependencyManagement section which contains all the tomcat artifacts to update the version. Add tomcat7-maven-plugin to myfaces 2.0 archetypes -- Key: MYFACES-3532 URL: https://issues.apache.org/jira/browse/MYFACES-3532 Project: MyFaces Core Issue Type: Improvement Components: Archetype Reporter: Leonardo Uribe Assignee: Leonardo Uribe Add tomcat7-maven-plugin to myfaces 2.0 archetypes -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTCDI-223) Provide @TransactionScoped Context for @Transactional
Provide @TransactionScoped Context for @Transactional - Key: EXTCDI-223 URL: https://issues.apache.org/jira/browse/EXTCDI-223 Project: MyFaces CODI Issue Type: New Feature Components: JEE-JPA1-Module Affects Versions: 1.0.1 Reporter: Mark Struberg Assignee: Mark Struberg We currently only support@RequestScoped EntityManagers. By automatically starting a @TransactionScoped Context at the beginning of any outermost TransactionalInterceptor (in the current Thread) and closing it when leaving the outermost @Transactional call again, we might easily implement an own Context for it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTCDI-224) Support REQUIRES_NEW and other javax.ejb.TransactionAttributeTypes in our @Transactional
Support REQUIRES_NEW and other javax.ejb.TransactionAttributeTypes in our @Transactional Key: EXTCDI-224 URL: https://issues.apache.org/jira/browse/EXTCDI-224 Project: MyFaces CODI Issue Type: New Feature Components: JEE-JPA1-Module Affects Versions: 1.0.1 Reporter: Mark Struberg Assignee: Mark Struberg We currently have the REQUIRED behaviour as default for our @Transactional interceptor. Imo we should _not_ import the javax.ejb.TransactionAttributeType to not add any additional dependency, but we should stay very close to it. I intend to implement the following TransactionAttributeTypes: * REQUIRED (as default) * REQUIRES_NEW * NEVER * SUPPORTS * MANDATORY not sure about the other ones A good overview can be found in OpenEJB: http://openejb.apache.org/3.0/transaction-annotations.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTCDI-225) upgrade to myfaces-parent-10
upgrade to myfaces-parent-10 Key: EXTCDI-225 URL: https://issues.apache.org/jira/browse/EXTCDI-225 Project: MyFaces CODI Issue Type: Improvement Components: Core Affects Versions: 1.0.1 Reporter: Mark Struberg Assignee: Mark Struberg upgrade to myfaces-parent-10 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3307) update myfaces parent pom to use latest apache-parent and other dependencies
update myfaces parent pom to use latest apache-parent and other dependencies Key: MYFACES-3307 URL: https://issues.apache.org/jira/browse/MYFACES-3307 Project: MyFaces Core Issue Type: Improvement Components: build process Affects Versions: 2.1.2 Reporter: Mark Struberg Assignee: Mark Struberg This is needed because we have an issue in the current setup of the checkstyle plugin -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3307) update myfaces parent pom to use latest apache-parent and other dependencies
[ https://issues.apache.org/jira/browse/MYFACES-3307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13106064#comment-13106064 ] Mark Struberg commented on MYFACES-3307: maven-assembly-plugin .. 2.2 - 2.2.1 maven-checkstyle-plugin .. 2.6 - 2.7 maven-compiler-plugin 2.3.1 - 2.3.2 maven-jar-plugin . 2.3.1 - 2.3.2 maven-javadoc-plugin . 2.7 - 2.8 maven-project-info-reports-plugin 2.2 - 2.4 maven-release-plugin ... 2.1 - 2.2.1 maven-resources-plugin . 2.4.3 - 2.5 maven-site-plugin .. 2.1.1 - 3.0 maven-surefire-plugin 2.5 - 2.9 maven-surefire-report-plugin . 2.5 - 2.9 org.codehaus.mojo:findbugs-maven-plugin .. 2.3.1 - 2.3.2 I removed the explicit mentioning of the maven-site-plugin because this gets handled generic in the apache parent pom, depending if one uses maven2 or 3. update myfaces parent pom to use latest apache-parent and other dependencies Key: MYFACES-3307 URL: https://issues.apache.org/jira/browse/MYFACES-3307 Project: MyFaces Core Issue Type: Improvement Components: build process Affects Versions: 2.1.2 Reporter: Mark Struberg Assignee: Mark Struberg This is needed because we have an issue in the current setup of the checkstyle plugin -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTCDI-226) upgrade codi to use OWB-1.1.1
upgrade codi to use OWB-1.1.1 - Key: EXTCDI-226 URL: https://issues.apache.org/jira/browse/EXTCDI-226 Project: MyFaces CODI Issue Type: Improvement Components: Core Affects Versions: 1.0.1 Reporter: Mark Struberg Assignee: Mark Struberg we currently use owb-1.1.0, but 1.1.1 is already released - so we should update -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (EXTCDI-226) upgrade codi to use OWB-1.1.1
[ https://issues.apache.org/jira/browse/EXTCDI-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved EXTCDI-226. -- Resolution: Fixed Fix Version/s: 1.0.2 upgrade codi to use OWB-1.1.1 - Key: EXTCDI-226 URL: https://issues.apache.org/jira/browse/EXTCDI-226 Project: MyFaces CODI Issue Type: Improvement Components: Core Affects Versions: 1.0.1 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 1.0.2 we currently use owb-1.1.0, but 1.1.1 is already released - so we should update -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTCDI-221) windowId parameter gets added twice
windowId parameter gets added twice --- Key: EXTCDI-221 URL: https://issues.apache.org/jira/browse/EXTCDI-221 Project: MyFaces CODI Issue Type: Bug Reporter: Mark Struberg Assignee: Gerhard Petracek Priority: Minor As seen in our jsf20 playground sample examples/jsf-playground/hello_myfaces-codi_jsf20 I have the following page open in my browser: http://localhost:8080/playground-jsf20/viewAccessBeanPage.xhtml?windowId=f54 If I restart the server and hit enter in my browser, I end up having the windowId parameter encoded twice in the URL: http://localhost:8080/playground-jsf20/viewAccessBeanPage.xhtml?windowId=f54windowId=ed9 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTCDI-218) defer final deletion of @ViewAccessScoped beans
defer final deletion of @ViewAccessScoped beans --- Key: EXTCDI-218 URL: https://issues.apache.org/jira/browse/EXTCDI-218 Project: MyFaces CODI Issue Type: New Feature Components: JEE-JSF12-Module, JEE-JSF20-Module Affects Versions: 1.0.1 Reporter: Mark Struberg Assignee: Mark Struberg I have a tricky problem in production with @ViewAccessScoped beans in conjunction with the lazy windowId dropping script http://wiki.apache.org/myfaces/Drafts/WindowId The problem arises if the user is on the browsers tabA (windowId=123) which has a @ViewAccessScoped bean and opens a link from this window in a new tabB. In this case a request with the old windowId=123 (*) will be sent to the server and the response will be rendered to tabB. When the dropWindowId script detects that tabB is a fresh browser tab, it will issue a new request and drops the windowId to get a new one (windowId=124 now for tabB) The problem is that in step (*) we get a request with the _old_ windowId onto a new view, thus we drop the @ViewAccessScoped bean used in tabA. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTCDI-218) defer final deletion of @ViewAccessScoped beans
[ https://issues.apache.org/jira/browse/EXTCDI-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13093496#comment-13093496 ] Mark Struberg commented on EXTCDI-218: -- A few ways to solve this: 1.) use the ClientSideWindowHandler: This is the only known fully functional solution for windowId handling. The problem is that it leads to slight flickering for the users (because an 'intermediate page' has to be rendered which detects any fresh browser window and loads the real destination via JavaScript) 2.) Instead of terminating @ViewAccessScoped immediately when a new viewId gets detected we only 'defer' them and clean them up on the following request. If he dropWindowId.js script detects a fresh browser window, it can pass the originalWindowId=123 as parameter so we can 'rollback' the deferring. I know that this is not an optimal solution but it would probably be the easiest way to fix the behaviour. 3.) Implement a history for @ViewAccessScoped beans. This is something which we thought about since a long time already. This would allow recovering on browser back buttons. defer final deletion of @ViewAccessScoped beans --- Key: EXTCDI-218 URL: https://issues.apache.org/jira/browse/EXTCDI-218 Project: MyFaces CODI Issue Type: New Feature Components: JEE-JSF12-Module, JEE-JSF20-Module Affects Versions: 1.0.1 Reporter: Mark Struberg Assignee: Mark Struberg I have a tricky problem in production with @ViewAccessScoped beans in conjunction with the lazy windowId dropping script http://wiki.apache.org/myfaces/Drafts/WindowId The problem arises if the user is on the browsers tabA (windowId=123) which has a @ViewAccessScoped bean and opens a link from this window in a new tabB. In this case a request with the old windowId=123 (*) will be sent to the server and the response will be rendered to tabB. When the dropWindowId script detects that tabB is a fresh browser tab, it will issue a new request and drops the windowId to get a new one (windowId=124 now for tabB) The problem is that in step (*) we get a request with the _old_ windowId onto a new view, thus we drop the @ViewAccessScoped bean used in tabA. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTCDI-218) defer final deletion of @ViewAccessScoped beans
[ https://issues.apache.org/jira/browse/EXTCDI-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13093704#comment-13093704 ] Mark Struberg commented on EXTCDI-218: -- folks, I cannot find where we call Contextual#destroy() for the bean which gets dropped in DefaultConversation#removeBean() I remember that we had this. Did we loose this while refactoring? defer final deletion of @ViewAccessScoped beans --- Key: EXTCDI-218 URL: https://issues.apache.org/jira/browse/EXTCDI-218 Project: MyFaces CODI Issue Type: New Feature Components: JEE-JSF12-Module, JEE-JSF20-Module Affects Versions: 1.0.1 Reporter: Mark Struberg Assignee: Mark Struberg I have a tricky problem in production with @ViewAccessScoped beans in conjunction with the lazy windowId dropping script http://wiki.apache.org/myfaces/Drafts/WindowId The problem arises if the user is on the browsers tabA (windowId=123) which has a @ViewAccessScoped bean and opens a link from this window in a new tabB. In this case a request with the old windowId=123 (*) will be sent to the server and the response will be rendered to tabB. When the dropWindowId script detects that tabB is a fresh browser tab, it will issue a new request and drops the windowId to get a new one (windowId=124 now for tabB) The problem is that in step (*) we get a request with the _old_ windowId onto a new view, thus we drop the @ViewAccessScoped bean used in tabA. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTCDI-219) ConversationAware must either be made public and moved to api or completely removed
ConversationAware must either be made public and moved to api or completely removed --- Key: EXTCDI-219 URL: https://issues.apache.org/jira/browse/EXTCDI-219 Project: MyFaces CODI Issue Type: Bug Components: Core Affects Versions: 1.0.1 Reporter: Mark Struberg Assignee: Mark Struberg ConversationAware is currently used internally for hardcoded casts. Either we make this interface public or drop it completely and add/subclass the functionality to ConversationExpirationEvaluator -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTCDI-220) ViewAccessScoped beans are not properly destroyed
ViewAccessScoped beans are not properly destroyed - Key: EXTCDI-220 URL: https://issues.apache.org/jira/browse/EXTCDI-220 Project: MyFaces CODI Issue Type: Bug Components: Core Affects Versions: 1.0.1 Reporter: Mark Struberg Assignee: Mark Struberg Priority: Critical currently we don't invoke Contextual#destroy() while removing ViewAccessScoped beans from the context on expiration. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (EXTCDI-220) ViewAccessScoped beans are not properly destroyed
[ https://issues.apache.org/jira/browse/EXTCDI-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reopened EXTCDI-220: -- JsfWindowContext#closeSubGroups and a few others call to EditableConversation#removeBeanEntry() ViewAccessScoped beans are not properly destroyed - Key: EXTCDI-220 URL: https://issues.apache.org/jira/browse/EXTCDI-220 Project: MyFaces CODI Issue Type: Bug Components: Core Affects Versions: 1.0.1 Reporter: Mark Struberg Assignee: Mark Struberg Priority: Minor currently we don't invoke Contextual#destroy() while removing ViewAccessScoped beans from the context on expiration. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTCDI-220) ViewAccessScoped beans are not properly destroyed
[ https://issues.apache.org/jira/browse/EXTCDI-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13093927#comment-13093927 ] Mark Struberg commented on EXTCDI-220: -- yes true, it's not a general ViewAccessScoped problem but rather a subgroup one. will fix the title of the issue ViewAccessScoped beans are not properly destroyed - Key: EXTCDI-220 URL: https://issues.apache.org/jira/browse/EXTCDI-220 Project: MyFaces CODI Issue Type: Bug Components: Core Affects Versions: 1.0.1 Reporter: Mark Struberg Assignee: Mark Struberg Priority: Minor currently we don't invoke Contextual#destroy() while removing ViewAccessScoped beans from the context on expiration. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (EXTCDI-220) @PreDestroy not called when closing sub-groups
[ https://issues.apache.org/jira/browse/EXTCDI-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved EXTCDI-220. -- Resolution: Fixed Fix Version/s: 1.0.2 fixed in r1163305. @PreDestroy not called when closing sub-groups -- Key: EXTCDI-220 URL: https://issues.apache.org/jira/browse/EXTCDI-220 Project: MyFaces CODI Issue Type: Bug Components: Core Affects Versions: 1.0.1 Reporter: Mark Struberg Assignee: Mark Struberg Priority: Minor Fix For: 1.0.2 currently we don't invoke Contextual#destroy() while removing sub-groups. grouped conversations aren't affected - only subgroups. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTCDI-220) @PreDestroy not called when closing sub-groups
[ https://issues.apache.org/jira/browse/EXTCDI-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13093996#comment-13093996 ] Mark Struberg commented on EXTCDI-220: -- Imo the last commit should get rollbacked. Removal from teh BeanStorage doesn't automatically mean the object wont be used anymore. A use case: bean history to get rid of the browser back button problem. The Contextual#destroy must only be called if the instance get dropped from the history. But the BeanStorage has not sufficient knowledge about this! @PreDestroy not called when closing sub-groups -- Key: EXTCDI-220 URL: https://issues.apache.org/jira/browse/EXTCDI-220 Project: MyFaces CODI Issue Type: Bug Components: Core Affects Versions: 1.0.1 Reporter: Mark Struberg Assignee: Mark Struberg Priority: Minor Fix For: 1.0.2 currently we don't invoke Contextual#destroy() while removing sub-groups. grouped conversations aren't affected - only subgroups. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTCDI-212) improve logging in the ActivationExtension and ProjectStage producer
improve logging in the ActivationExtension and ProjectStage producer Key: EXTCDI-212 URL: https://issues.apache.org/jira/browse/EXTCDI-212 Project: MyFaces CODI Issue Type: New Feature Components: Core Affects Versions: 1.0.0 Reporter: Mark Struberg Assignee: Mark Struberg The ActivationExtension should log information about any vetoed bean. It's currently really hard to understand what's happening. We should also log the current ProjectStage, etc -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (EXTCDI-212) improve logging in the ActivationExtension and ProjectStage producer
[ https://issues.apache.org/jira/browse/EXTCDI-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved EXTCDI-212. -- Resolution: Fixed Fix Version/s: 1.0.1 fixed in r1156720 improve logging in the ActivationExtension and ProjectStage producer Key: EXTCDI-212 URL: https://issues.apache.org/jira/browse/EXTCDI-212 Project: MyFaces CODI Issue Type: New Feature Components: Core Affects Versions: 1.0.0 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 1.0.1 The ActivationExtension should log information about any vetoed bean. It's currently really hard to understand what's happening. We should also log the current ProjectStage, etc -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTCDI-213) ProjectStageProducer doesn't evaluate JNDI settings correctly.
ProjectStageProducer doesn't evaluate JNDI settings correctly. -- Key: EXTCDI-213 URL: https://issues.apache.org/jira/browse/EXTCDI-213 Project: MyFaces CODI Issue Type: Bug Components: Core, JEE-JSF20-Module Affects Versions: 1.0.0 Reporter: Mark Struberg Assignee: Mark Struberg Priority: Critical setting the faces.PROJECT_STAGE via JNDI doesn't work any longer in CODI-1.0.0 I use the following setting in my tomcat6 conf/context.xml: Environment name=jsf/ProjectStage value=SystemTest type=java.lang.String override=false/ This used to work in older CODI versions but not with 1.0.0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (EXTCDI-213) ProjectStageProducer doesn't evaluate JNDI settings correctly.
[ https://issues.apache.org/jira/browse/EXTCDI-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved EXTCDI-213. -- Resolution: Fixed Fix Version/s: 1.0.1 fixed in r1156808 ProjectStageProducer doesn't evaluate JNDI settings correctly. -- Key: EXTCDI-213 URL: https://issues.apache.org/jira/browse/EXTCDI-213 Project: MyFaces CODI Issue Type: Bug Components: Core, JEE-JSF20-Module Affects Versions: 1.0.0 Reporter: Mark Struberg Assignee: Mark Struberg Priority: Critical Fix For: 1.0.1 setting the faces.PROJECT_STAGE via JNDI doesn't work any longer in CODI-1.0.0 I use the following setting in my tomcat6 conf/context.xml: Environment name=jsf/ProjectStage value=SystemTest type=java.lang.String override=false/ This used to work in older CODI versions but not with 1.0.0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MYFACES-3235) Create infrastructure for improved logging
[ https://issues.apache.org/jira/browse/MYFACES-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13070716#comment-13070716 ] Mark Struberg edited comment on MYFACES-3235 at 7/25/11 7:51 PM: - +1. Logging cannot replace a debugging session. Please do not add too much logger.debug info! Especially not in ELResolvers and stuff which gets called millions of itmes per second! Most people seems not to be aware that even a logger.isDebugEnabled() is already pretty expensive compared to the tasks which get executed sometimes! An example: we had such a logger in OWBs Interceptor stack and after kicking it out, our total performance was more then twice as good! was (Author: struberg): +1. Logging cannot replace a debugging session. Please do not add too much debug info! Especially not in ELResolvers and stuff which gets called millions of itmes per second! Most people seems not to be aware that even a logger.isDebugEnabled() is already pretty expensive compared to the tasks which get executed sometimes! An example: we had such a logger in OWBs Interceptor stack and after kicking it out, our total performance was more then twice as good! Create infrastructure for improved logging --- Key: MYFACES-3235 URL: https://issues.apache.org/jira/browse/MYFACES-3235 Project: MyFaces Core Issue Type: Sub-task Components: General Reporter: Martin Kočí Assignee: Martin Kočí Priority: Minor Attachments: MYFACES-3235.patch Create classes like MyfacesLogger, MyfacesLogRecord etc. like Trinidad has. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3235) Create infrastructure for improved logging
[ https://issues.apache.org/jira/browse/MYFACES-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13070716#comment-13070716 ] Mark Struberg commented on MYFACES-3235: +1. Logging cannot replace a debugging session. Please do not add too much debug info! Especially not in ELResolvers and stuff which gets called millions of itmes per second! Most people seems not to be aware that even a logger.isDebugEnabled() is already pretty expensive compared to the tasks which get executed sometimes! An example: we had such a logger in OWBs Interceptor stack and after kicking it out, our total performance was more then twice as good! Create infrastructure for improved logging --- Key: MYFACES-3235 URL: https://issues.apache.org/jira/browse/MYFACES-3235 Project: MyFaces Core Issue Type: Sub-task Components: General Reporter: Martin Kočí Assignee: Martin Kočí Priority: Minor Attachments: MYFACES-3235.patch Create classes like MyfacesLogger, MyfacesLogRecord etc. like Trinidad has. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3235) Create infrastructure for improved logging
[ https://issues.apache.org/jira/browse/MYFACES-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13070249#comment-13070249 ] Mark Struberg commented on MYFACES-3235: Hi! Just my $0.02: i18n in logs is TOTALLY overrated! Ever tried to google for a MyFaces error message in hungarian? Bet you wont find much! Seriously, in most cases having an internationalized log is a real pita for any system. This is of course something completely different for messages which get presented to the end user, like Validation messages. Create infrastructure for improved logging --- Key: MYFACES-3235 URL: https://issues.apache.org/jira/browse/MYFACES-3235 Project: MyFaces Core Issue Type: Sub-task Components: General Reporter: Martin Kočí Assignee: Martin Kočí Priority: Minor Attachments: MYFACES-3235.patch Create classes like MyfacesLogger, MyfacesLogRecord etc. like Trinidad has. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTCDI-205) GroupedConversationContext#isActive crashes with a NPE if FacesContext is not active or null
GroupedConversationContext#isActive crashes with a NPE if FacesContext is not active or null Key: EXTCDI-205 URL: https://issues.apache.org/jira/browse/EXTCDI-205 Project: MyFaces CODI Issue Type: Bug Components: JEE-JSF12-Module, JEE-JSF20-Module Affects Versions: 0.9.5 Reporter: Mark Struberg Assignee: Mark Struberg isActive must return false if the FacesContext is null. This is needed if e.g. a CDI Event gets fired in a servlet filter and will be @Observes by a bean. In this case the CDI container will only deliver the event to beans in *active* contexts. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (EXTCDI-205) GroupedConversationContext#isActive crashes with a NPE if FacesContext is not active or null
[ https://issues.apache.org/jira/browse/EXTCDI-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved EXTCDI-205. -- Resolution: Fixed Fix Version/s: 1.0.0 GroupedConversationContext#isActive crashes with a NPE if FacesContext is not active or null Key: EXTCDI-205 URL: https://issues.apache.org/jira/browse/EXTCDI-205 Project: MyFaces CODI Issue Type: Bug Components: JEE-JSF12-Module, JEE-JSF20-Module Affects Versions: 0.9.5 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 1.0.0 isActive must return false if the FacesContext is null. This is needed if e.g. a CDI Event gets fired in a servlet filter and will be @Observes by a bean. In this case the CDI container will only deliver the event to beans in *active* contexts. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTCDI-200) TransactionalInterceptor: flush EntityManagers before commit
TransactionalInterceptor: flush EntityManagers before commit Key: EXTCDI-200 URL: https://issues.apache.org/jira/browse/EXTCDI-200 Project: MyFaces CODI Issue Type: Improvement Reporter: Mark Struberg Assignee: Mark Struberg Currently we do a commit over all EntityManagers. To reduce the risk of committing into one database but failing later on another one, we should flush all EntityManagers upfront. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTCDI-188) BeanResolver
[ https://issues.apache.org/jira/browse/EXTCDI-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13035229#comment-13035229 ] Mark Struberg commented on EXTCDI-188: -- What I meant was not a wrapper over the BeanManager (where this method will get added in CDI-1.1) but just a new method in BeanManagerProvider itself. Will hack that in today. BeanResolver Key: EXTCDI-188 URL: https://issues.apache.org/jira/browse/EXTCDI-188 Project: MyFaces CODI Issue Type: New Feature Components: Core Affects Versions: 1.0.0 Reporter: Mark Struberg Assignee: Gerhard Petracek it should be possible to inject (or get with BeanManagerProvider.getInstance().getBeanResolver()) a convenience wrapper of the bean-manager which allows to easily query beans. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTCDI-188) BeanResolver
[ https://issues.apache.org/jira/browse/EXTCDI-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13035453#comment-13035453 ] Mark Struberg commented on EXTCDI-188: -- It's really just about the 3 functions to resolve a contextual reference. BeanResolver Key: EXTCDI-188 URL: https://issues.apache.org/jira/browse/EXTCDI-188 Project: MyFaces CODI Issue Type: New Feature Components: Core Affects Versions: 1.0.0 Reporter: Mark Struberg Assignee: Gerhard Petracek it should be possible to inject (or get with BeanManagerProvider.getInstance().getBeanResolver()) a convenience wrapper of the bean-manager which allows to easily query beans. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTCDI-188) BeanResolver
[ https://issues.apache.org/jira/browse/EXTCDI-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13035454#comment-13035454 ] Mark Struberg commented on EXTCDI-188: -- It's really just about the 3 functions to resolve a contextual reference. BeanResolver Key: EXTCDI-188 URL: https://issues.apache.org/jira/browse/EXTCDI-188 Project: MyFaces CODI Issue Type: New Feature Components: Core Affects Versions: 1.0.0 Reporter: Mark Struberg Assignee: Gerhard Petracek it should be possible to inject (or get with BeanManagerProvider.getInstance().getBeanResolver()) a convenience wrapper of the bean-manager which allows to easily query beans. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (EXTCDI-188) BeanResolver
[ https://issues.apache.org/jira/browse/EXTCDI-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved EXTCDI-188. -- Resolution: Fixed Fix Version/s: 1.0.0 fixed in revision 1124392 BeanResolver Key: EXTCDI-188 URL: https://issues.apache.org/jira/browse/EXTCDI-188 Project: MyFaces CODI Issue Type: New Feature Components: Core Affects Versions: 1.0.0 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 1.0.0 it should be possible to inject (or get with BeanManagerProvider.getInstance().getBeanResolver()) a convenience wrapper of the bean-manager which allows to easily query beans. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTCDI-174) Introduce @PropertyActivated or @ConfigActivated
[
https://issues.apache.org/jira/browse/EXTCDI-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13034834#comment-13034834
]
Mark Struberg commented on EXTCDI-174:
--
Interpreter is a neat idea, but most probably way to complicated for casual
users. Also the name should really match with the already existing
@ProjectStageActivated.
Btw, what do you mean with 'any expression' ?
Introduce @PropertyActivated or @ConfigActivated
Key: EXTCDI-174
URL: https://issues.apache.org/jira/browse/EXTCDI-174
Project: MyFaces CODI
Issue Type: New Feature
Components: Core
Reporter: Mark Struberg
Assignee: Gerhard Petracek
While at JAX, I got pretty often asked if there is a way to configure
alternatives automatically via configuration. I pointed them to
@ProjectStageActivated and this solved 60% of the problems.
But there are pretty often more complex scenarios where users like to switch
between e.g. database vendors based on an external configuration.
This could e.g. be a normal java properties file and something like
{code}
@PropertyActivated(user.databyse, mysql)
{code}
where the first parameter is the name and the 2nd is the value which must be
set.
Please add further ideas for ways to change those configurations.
The actual implementation should be trivial as we have most of the work done
already in ProjectStageActivationExtension.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTCDI-183) CODI doesn't seem to work at all in JBoss 6
[ https://issues.apache.org/jira/browse/EXTCDI-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13033941#comment-13033941 ] Mark Struberg commented on EXTCDI-183: -- Hi Daniel! It looks like JBossAS6 is heavily broken and already a step child of the JBoss folks. They are really hard working on JBossAS7 and the available Beta is already MUCH better then JBossAS6.Final! JBossAS7 looks really neat, but 6 is a complete waste imo. It would be great if you could try your code in JBossAS7 and report back if it is still broken or working fine. txs and LieGrue, strub CODI doesn't seem to work at all in JBoss 6 --- Key: EXTCDI-183 URL: https://issues.apache.org/jira/browse/EXTCDI-183 Project: MyFaces CODI Issue Type: Bug Environment: System 1: Mac OSX, JBoss 6 Final, Weld 1.1.0 - 1.1.1, Mojarra 2.0.3 - 2.1.1, CODI 0.9.2 - 0.9.5 System 2: Mac OSX, Glassfish 3.0.1 Final, Weld 1.0.1, Mojarra 2.0.1 -2.0.4, CODI 0.9.2 - 0.9.5 System 3: Mac OSX Glassfish 3.1 Final, Weld 1.1.0 - 1.1.1, Mojarra 2.1.1, CODI 0.9.2 - 0.9.5 Reporter: Daniel Sachse Priority: Minor After the first recommandation of https://issues.apache.org/jira/browse/EXTCDI-176 I migrated to CODI-JSF to make use of the provided Events(i.e. InitView, PrerenderView) and the Type-Safe Navigation. My application didn't work on System 1 as described above with the various Framework combinations I tested. So I tried to deploy an example application(https://bitbucket.org/os890/codi-examples) which worked in System 2. System 3 didn't work at all. System 1 started but as soon as I tried to use the navigation cases, I got errors, that no navigation-cases could be found. Additionally there was no output that the Eventmethods(PrerenderView) have been called. These were the exact same errors I got in my own application. To me the JSF-Module seems to be totally broken in JBoss 6. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
