[jira] Updated: (MYFACES-2904) javascript _Dom._outerHtml does not handle table items (tr, tbody. ...)
[ https://issues.apache.org/jira/browse/MYFACES-2904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-2904: Status: Patch Available (was: Open) javascript _Dom._outerHtml does not handle table items (tr, tbody. ...) --- Key: MYFACES-2904 URL: https://issues.apache.org/jira/browse/MYFACES-2904 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.1 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Attachments: MYFACES-2904-1.patch Checking some stuff in tomahawk, I found that when a fragment starts with tr or some tag that should be used inside table are trimmed when are replaced on an ajax request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2904) javascript _Dom._outerHtml does not handle table items (tr, tbody. ...)
javascript _Dom._outerHtml does not handle table items (tr, tbody. ...) --- Key: MYFACES-2904 URL: https://issues.apache.org/jira/browse/MYFACES-2904 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.1 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Attachments: MYFACES-2904-1.patch Checking some stuff in tomahawk, I found that when a fragment starts with tr or some tag that should be used inside table are trimmed when are replaced on an ajax request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [JSF2] absolute-ordering warning
HEy Christian, I will take a look. I think I have not seen this issue w/ Trinidad, which has a similar entry: https://svn.apache.org/repos/asf/myfaces/trinidad/trunk/trinidad-impl/src/main/conf/META-INF/faces-config-base.xml -M On Thu, Sep 2, 2010 at 6:43 AM, Christian Kaltepoth christ...@kaltepoth.de wrote: Hello, I'm committer on the PrettyFaces project and we are currently preparing our next release. While testing the release in different environments I discovered that MyFaces 2.0.1 prints a warning to the console: WARNING: absolute-ordering element found in application configuration resource prettyfaces. This description will be ignored and the actions described in ordering elements will be taken into account instead. The weird thing about this is that we DON'T use absolute-ordering in our faces-config.xml at all. Our ordering configuration looks like this: ordering before others/ /before /ordering See: https://prettyfaces.googlecode.com/svn/prettyfaces/trunk/impl-jsf2/src/main/resources/META-INF/faces-config.xml I looked at the MyFaces code and found the code emitting this warning: http://myfaces.apache.org/core20/myfaces-impl/xref/org/apache/myfaces/config/FacesConfigurator.html#982 We discussed this issue on the prettyfaces-dev list. We think that it is a bug in MyFaces. http://groups.google.com/group/prettyfaces-dev/msg/da44e1e6660887c6 What do you think? Is it a bug? Christian -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [JSF2] absolute-ordering warning
Hey Matthias, thank you very much. You can use this sample app to reproduce this issue: http://github.com/chkal/prettyfaces-tests Just checkout the jsf2 branch and run via mvn tomcat:run-war and you will see the warning. Christian 2010/9/2 Matthias Wessendorf mat...@apache.org: HEy Christian, I will take a look. I think I have not seen this issue w/ Trinidad, which has a similar entry: https://svn.apache.org/repos/asf/myfaces/trinidad/trunk/trinidad-impl/src/main/conf/META-INF/faces-config-base.xml -M On Thu, Sep 2, 2010 at 6:43 AM, Christian Kaltepoth christ...@kaltepoth.de wrote: Hello, I'm committer on the PrettyFaces project and we are currently preparing our next release. While testing the release in different environments I discovered that MyFaces 2.0.1 prints a warning to the console: WARNING: absolute-ordering element found in application configuration resource prettyfaces. This description will be ignored and the actions described in ordering elements will be taken into account instead. The weird thing about this is that we DON'T use absolute-ordering in our faces-config.xml at all. Our ordering configuration looks like this: ordering before others/ /before /ordering See: https://prettyfaces.googlecode.com/svn/prettyfaces/trunk/impl-jsf2/src/main/resources/META-INF/faces-config.xml I looked at the MyFaces code and found the code emitting this warning: http://myfaces.apache.org/core20/myfaces-impl/xref/org/apache/myfaces/config/FacesConfigurator.html#982 We discussed this issue on the prettyfaces-dev list. We think that it is a bug in MyFaces. http://groups.google.com/group/prettyfaces-dev/msg/da44e1e6660887c6 What do you think? Is it a bug? Christian -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
[jira] Commented: (MYFACES-2904) javascript _Dom._outerHtml does not handle table items (tr, tbody. ...)
[ https://issues.apache.org/jira/browse/MYFACES-2904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12905447#action_12905447 ] Werner Punz commented on MYFACES-2904: -- Wow now this is a nice patch, I never intented the outerHTML to be used this way and yes there are problems with IE. All I can say is wow... go ahead and commit it otherwise I will do :-) Really nice stuff, thanks for doing it, I guess we now have a kickass outerHTML function. javascript _Dom._outerHtml does not handle table items (tr, tbody. ...) --- Key: MYFACES-2904 URL: https://issues.apache.org/jira/browse/MYFACES-2904 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.1 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Attachments: MYFACES-2904-1.patch Checking some stuff in tomahawk, I found that when a fragment starts with tr or some tag that should be used inside table are trimmed when are replaced on an ajax request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [JSF2] absolute-ordering warning
I think I need new glasses... WARNING: absolute-ordering element found in application configuration resource trinidad. This description will be ignored and the actions described in ordering elements will be taken into account instead. -M On Thu, Sep 2, 2010 at 9:24 AM, Christian Kaltepoth christ...@kaltepoth.de wrote: Hey Matthias, thank you very much. You can use this sample app to reproduce this issue: http://github.com/chkal/prettyfaces-tests Just checkout the jsf2 branch and run via mvn tomcat:run-war and you will see the warning. Christian 2010/9/2 Matthias Wessendorf mat...@apache.org: HEy Christian, I will take a look. I think I have not seen this issue w/ Trinidad, which has a similar entry: https://svn.apache.org/repos/asf/myfaces/trinidad/trunk/trinidad-impl/src/main/conf/META-INF/faces-config-base.xml -M On Thu, Sep 2, 2010 at 6:43 AM, Christian Kaltepoth christ...@kaltepoth.de wrote: Hello, I'm committer on the PrettyFaces project and we are currently preparing our next release. While testing the release in different environments I discovered that MyFaces 2.0.1 prints a warning to the console: WARNING: absolute-ordering element found in application configuration resource prettyfaces. This description will be ignored and the actions described in ordering elements will be taken into account instead. The weird thing about this is that we DON'T use absolute-ordering in our faces-config.xml at all. Our ordering configuration looks like this: ordering before others/ /before /ordering See: https://prettyfaces.googlecode.com/svn/prettyfaces/trunk/impl-jsf2/src/main/resources/META-INF/faces-config.xml I looked at the MyFaces code and found the code emitting this warning: http://myfaces.apache.org/core20/myfaces-impl/xref/org/apache/myfaces/config/FacesConfigurator.html#982 We discussed this issue on the prettyfaces-dev list. We think that it is a bug in MyFaces. http://groups.google.com/group/prettyfaces-dev/msg/da44e1e6660887c6 What do you think? Is it a bug? Christian -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [JSF2] absolute-ordering warning
Should be easy fix -M On Thu, Sep 2, 2010 at 10:57 AM, Matthias Wessendorf mat...@apache.org wrote: I think I need new glasses... WARNING: absolute-ordering element found in application configuration resource trinidad. This description will be ignored and the actions described in ordering elements will be taken into account instead. -M On Thu, Sep 2, 2010 at 9:24 AM, Christian Kaltepoth christ...@kaltepoth.de wrote: Hey Matthias, thank you very much. You can use this sample app to reproduce this issue: http://github.com/chkal/prettyfaces-tests Just checkout the jsf2 branch and run via mvn tomcat:run-war and you will see the warning. Christian 2010/9/2 Matthias Wessendorf mat...@apache.org: HEy Christian, I will take a look. I think I have not seen this issue w/ Trinidad, which has a similar entry: https://svn.apache.org/repos/asf/myfaces/trinidad/trunk/trinidad-impl/src/main/conf/META-INF/faces-config-base.xml -M On Thu, Sep 2, 2010 at 6:43 AM, Christian Kaltepoth christ...@kaltepoth.de wrote: Hello, I'm committer on the PrettyFaces project and we are currently preparing our next release. While testing the release in different environments I discovered that MyFaces 2.0.1 prints a warning to the console: WARNING: absolute-ordering element found in application configuration resource prettyfaces. This description will be ignored and the actions described in ordering elements will be taken into account instead. The weird thing about this is that we DON'T use absolute-ordering in our faces-config.xml at all. Our ordering configuration looks like this: ordering before others/ /before /ordering See: https://prettyfaces.googlecode.com/svn/prettyfaces/trunk/impl-jsf2/src/main/resources/META-INF/faces-config.xml I looked at the MyFaces code and found the code emitting this warning: http://myfaces.apache.org/core20/myfaces-impl/xref/org/apache/myfaces/config/FacesConfigurator.html#982 We discussed this issue on the prettyfaces-dev list. We think that it is a bug in MyFaces. http://groups.google.com/group/prettyfaces-dev/msg/da44e1e6660887c6 What do you think? Is it a bug? Christian -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Created: (MYFACES-2905) [JSF2] absolute-ordering warning
[JSF2] absolute-ordering warning Key: MYFACES-2905 URL: https://issues.apache.org/jira/browse/MYFACES-2905 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.1 Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf See thread for this http://markmail.org/message/cco2pdvuzlecs6da -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2905) [JSF2] absolute-ordering warning
[
https://issues.apache.org/jira/browse/MYFACES-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12905460#action_12905460
]
Matthias Weßendorf commented on MYFACES-2905:
-
Problem is that in:
else if (!appConfigResources.isEmpty())
{
//Relative ordering
for (FacesConfig resource : appConfigResources)
{
if (resource.getOrdering() != null)
{
if (log.isLoggable(Level.WARNING))
{
log.warning(absolute-ordering element found in
application +
configuration resource +resource.getName()+.
+
This description will be ignored and the
actions described +
in ordering elements will be taken into
account instead.);
}
}
}
..
we check incorrectly for ordering.
changing to if (resource.getAbsoluteOrdering() != null) is the fix
[JSF2] absolute-ordering warning
Key: MYFACES-2905
URL: https://issues.apache.org/jira/browse/MYFACES-2905
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.1
Reporter: Matthias Weßendorf
Assignee: Matthias Weßendorf
See thread for this
http://markmail.org/message/cco2pdvuzlecs6da
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [JSF2] absolute-ordering warning
https://issues.apache.org/jira/browse/MYFACES-2905 On Thu, Sep 2, 2010 at 10:58 AM, Matthias Wessendorf mat...@apache.org wrote: Should be easy fix -M On Thu, Sep 2, 2010 at 10:57 AM, Matthias Wessendorf mat...@apache.org wrote: I think I need new glasses... WARNING: absolute-ordering element found in application configuration resource trinidad. This description will be ignored and the actions described in ordering elements will be taken into account instead. -M On Thu, Sep 2, 2010 at 9:24 AM, Christian Kaltepoth christ...@kaltepoth.de wrote: Hey Matthias, thank you very much. You can use this sample app to reproduce this issue: http://github.com/chkal/prettyfaces-tests Just checkout the jsf2 branch and run via mvn tomcat:run-war and you will see the warning. Christian 2010/9/2 Matthias Wessendorf mat...@apache.org: HEy Christian, I will take a look. I think I have not seen this issue w/ Trinidad, which has a similar entry: https://svn.apache.org/repos/asf/myfaces/trinidad/trunk/trinidad-impl/src/main/conf/META-INF/faces-config-base.xml -M On Thu, Sep 2, 2010 at 6:43 AM, Christian Kaltepoth christ...@kaltepoth.de wrote: Hello, I'm committer on the PrettyFaces project and we are currently preparing our next release. While testing the release in different environments I discovered that MyFaces 2.0.1 prints a warning to the console: WARNING: absolute-ordering element found in application configuration resource prettyfaces. This description will be ignored and the actions described in ordering elements will be taken into account instead. The weird thing about this is that we DON'T use absolute-ordering in our faces-config.xml at all. Our ordering configuration looks like this: ordering before others/ /before /ordering See: https://prettyfaces.googlecode.com/svn/prettyfaces/trunk/impl-jsf2/src/main/resources/META-INF/faces-config.xml I looked at the MyFaces code and found the code emitting this warning: http://myfaces.apache.org/core20/myfaces-impl/xref/org/apache/myfaces/config/FacesConfigurator.html#982 We discussed this issue on the prettyfaces-dev list. We think that it is a bug in MyFaces. http://groups.google.com/group/prettyfaces-dev/msg/da44e1e6660887c6 What do you think? Is it a bug? Christian -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Resolved: (MYFACES-2905) [JSF2] absolute-ordering warning
[ https://issues.apache.org/jira/browse/MYFACES-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf resolved MYFACES-2905. - Fix Version/s: 2.0.2-SNAPSHOT Resolution: Fixed [JSF2] absolute-ordering warning Key: MYFACES-2905 URL: https://issues.apache.org/jira/browse/MYFACES-2905 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.1 Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf Fix For: 2.0.2-SNAPSHOT See thread for this http://markmail.org/message/cco2pdvuzlecs6da -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2906) NullPointerException in ResolverBuilderBase.sortELResolvers()
NullPointerException in ResolverBuilderBase.sortELResolvers() - Key: MYFACES-2906 URL: https://issues.apache.org/jira/browse/MYFACES-2906 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.2-SNAPSHOT Reporter: Matthias Weßendorf Using 2.0.2-SNAPSHOT and Trinidad trunk (2.0.0.3-SNAPSHOT) I do get NPE in the ResolverBuilderBase class. However, there was an overhaul in MYFACES-2873 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2906) NullPointerException in ResolverBuilderBase.sortELResolvers()
[ https://issues.apache.org/jira/browse/MYFACES-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12905462#action_12905462 ] Matthias Weßendorf commented on MYFACES-2906: - stacktrace java.lang.NullPointerException at org.apache.myfaces.el.unified.ResolverBuilderBase.sortELResolvers(ResolverBuilderBase.java:113) at org.apache.myfaces.el.unified.ResolverBuilderForFaces.build(ResolverBuilderForFaces.java:77) at org.apache.myfaces.application.ApplicationImpl.createFacesResolver(ApplicationImpl.java:346) at org.apache.myfaces.application.ApplicationImpl.getELResolver(ApplicationImpl.java:338) at org.apache.myfaces.trinidadinternal.config.LazyValueExpression$MockELContext.init(LazyValueExpression.java:193) at org.apache.myfaces.trinidadinternal.config.LazyValueExpression._getELContext(LazyValueExpression.java:141) at org.apache.myfaces.trinidadinternal.config.LazyValueExpression._createValueExpressionFromApplication(LazyValueExpression.java:174) at org.apache.myfaces.trinidadinternal.config.LazyValueExpression.createValueExpression(LazyValueExpression.java:53) at org.apache.myfaces.trinidadinternal.skin.SkinUtils._createTranslationSourceValueExpression(SkinUtils.java:649) at org.apache.myfaces.trinidadinternal.skin.SkinUtils._addSkinToFactory(SkinUtils.java:612) at org.apache.myfaces.trinidadinternal.skin.SkinUtils._registerSkinExtensionsAndAdditions(SkinUtils.java:411) at org.apache.myfaces.trinidadinternal.skin.SkinUtils.registerSkinExtensions(SkinUtils.java:131) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.init(GlobalConfiguratorImpl.java:406) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:205) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:155) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) at org.apache.myfaces.trinidaddemo.webapp.RedirectFilter.doFilter(RedirectFilter.java:97) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:536) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:915) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:539) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:405) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) NullPointerException in ResolverBuilderBase.sortELResolvers() - Key: MYFACES-2906 URL: https://issues.apache.org/jira/browse/MYFACES-2906 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.2-SNAPSHOT Reporter: Matthias Weßendorf Using 2.0.2-SNAPSHOT and Trinidad trunk (2.0.0.3-SNAPSHOT) I do get NPE in the ResolverBuilderBase class. However, there was an overhaul in MYFACES-2873 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2904) javascript _Dom._outerHtml does not handle table items (tr, tbody. ...)
[ https://issues.apache.org/jira/browse/MYFACES-2904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12905465#action_12905465 ] Jakob Korherr commented on MYFACES-2904: great stuff :) javascript _Dom._outerHtml does not handle table items (tr, tbody. ...) --- Key: MYFACES-2904 URL: https://issues.apache.org/jira/browse/MYFACES-2904 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.1 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Attachments: MYFACES-2904-1.patch Checking some stuff in tomahawk, I found that when a fragment starts with tr or some tag that should be used inside table are trimmed when are replaced on an ajax request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2906) NullPointerException in ResolverBuilderBase.sortELResolvers()
[
https://issues.apache.org/jira/browse/MYFACES-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12905466#action_12905466
]
Matthias Weßendorf commented on MYFACES-2906:
-
we create Mock since FC is not present at this time
private static ELContext _getELContext(Application application)
{
FacesContext fContext = FacesContext.getCurrentInstance();
if (fContext != null)
{
return fContext.getELContext();
}
else
{
// use a dummy ELContext if FacesContext is null
return new MockELContext(application);
}
}
NullPointerException in ResolverBuilderBase.sortELResolvers()
-
Key: MYFACES-2906
URL: https://issues.apache.org/jira/browse/MYFACES-2906
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.2-SNAPSHOT
Reporter: Matthias Weßendorf
Assignee: Jakob Korherr
Using 2.0.2-SNAPSHOT and Trinidad trunk (2.0.0.3-SNAPSHOT) I do get NPE in
the ResolverBuilderBase class.
However, there was an overhaul in MYFACES-2873
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1901) Make Trinidad OSGi ready
Make Trinidad OSGi ready Key: TRINIDAD-1901 URL: https://issues.apache.org/jira/browse/TRINIDAD-1901 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 2.0.0.3-core Reporter: Frank Mittag Hi, it would be great to create an OSGi ready version of Trinidad (and MyFaces). I'm using Trinidad together with MyFaces in the Eclipse Virgo runtime (former Spring DM Server), but the problems are valid for every OSGi environment. In the first place the API and the IMPL jars need an updated/improved OSGi-ready MANIFEST file exposing the typical OSGi metadata. The content could be created with tools like BND from Peter Kriens which could run as part of the build process (see other projects like Apache Felix, etc.) But normally this is not enough the make a library OSGi-ready. The nature of OSGi allows to run several TRINIDAD's in parallel in the same runtime even in different versions. This leads often to conflicts with singleton objects or class loading issues. There are different usage scenarios where Trinidad should fit: 1. Scenario: Usage of TRINIDAD in two different web apps inside an OSGi runtime. So you have ideally 1 API bundle 1. WAR with the IMPL jar in the lib folder 2. WAR with the IMPL jar in the lib folder or 1. WAR with the API jar and the IMPL jar in the lib folder 2. WAR with the API jar and the IMPL jar in the lib folder 2.Scenario: Usage of TRINIDAD in different web apps in two different versions inside an OSGi runtime. So you have ideally 1 API bundle 1.2.14 1 API bundle 2.0.0.3 1. WAR with the IMPL 1.2.14 jar in the lib folder 2. WAR with the IMPL 2.0.0.3 jar in the lib folder 3. WAR with the IMPL 2.0.0.3 jar in the lib folder or 1. WAR with the API jar and IMPL 1.2.14 jar in the lib folder 2. WAR with the API jar and IMPL 2.0.0.3 jar in the lib folder 3. WAR with the API jar and IMPL 2.0.0.3 jar in the lib folder Even more better would be to have just one API and IMPL bundle in the whole runtime and just reference the bundles from the web app, but I guess this would probably require some refactoring of TRINIDAD. The pattern also applies to the MYFACES libs. Regards, Frank -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [JSF2] absolute-ordering warning
Thank you very much! :-) Christian 2010/9/2 Matthias Wessendorf mat...@apache.org: https://issues.apache.org/jira/browse/MYFACES-2905 On Thu, Sep 2, 2010 at 10:58 AM, Matthias Wessendorf mat...@apache.org wrote: Should be easy fix -M On Thu, Sep 2, 2010 at 10:57 AM, Matthias Wessendorf mat...@apache.org wrote: I think I need new glasses... WARNING: absolute-ordering element found in application configuration resource trinidad. This description will be ignored and the actions described in ordering elements will be taken into account instead. -M On Thu, Sep 2, 2010 at 9:24 AM, Christian Kaltepoth christ...@kaltepoth.de wrote: Hey Matthias, thank you very much. You can use this sample app to reproduce this issue: http://github.com/chkal/prettyfaces-tests Just checkout the jsf2 branch and run via mvn tomcat:run-war and you will see the warning. Christian 2010/9/2 Matthias Wessendorf mat...@apache.org: HEy Christian, I will take a look. I think I have not seen this issue w/ Trinidad, which has a similar entry: https://svn.apache.org/repos/asf/myfaces/trinidad/trunk/trinidad-impl/src/main/conf/META-INF/faces-config-base.xml -M On Thu, Sep 2, 2010 at 6:43 AM, Christian Kaltepoth christ...@kaltepoth.de wrote: Hello, I'm committer on the PrettyFaces project and we are currently preparing our next release. While testing the release in different environments I discovered that MyFaces 2.0.1 prints a warning to the console: WARNING: absolute-ordering element found in application configuration resource prettyfaces. This description will be ignored and the actions described in ordering elements will be taken into account instead. The weird thing about this is that we DON'T use absolute-ordering in our faces-config.xml at all. Our ordering configuration looks like this: ordering before others/ /before /ordering See: https://prettyfaces.googlecode.com/svn/prettyfaces/trunk/impl-jsf2/src/main/resources/META-INF/faces-config.xml I looked at the MyFaces code and found the code emitting this warning: http://myfaces.apache.org/core20/myfaces-impl/xref/org/apache/myfaces/config/FacesConfigurator.html#982 We discussed this issue on the prettyfaces-dev list. We think that it is a bug in MyFaces. http://groups.google.com/group/prettyfaces-dev/msg/da44e1e6660887c6 What do you think? Is it a bug? Christian -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
[jira] Created: (TRINIDAD-1902) Provide FacesContext for configuration tasks
Provide FacesContext for configuration tasks Key: TRINIDAD-1902 URL: https://issues.apache.org/jira/browse/TRINIDAD-1902 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 2.0.0.3-core Reporter: Jakob Korherr Assignee: Jakob Korherr MYFACES-2906 shows that Trinidad does not provide a FacesContext for code which normally runs at a time at which a FacesContext is available. The solution is to provide a Pseudo-FacesContext which implements some useful tasks and to set this one as the current instance while configuration is done. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1902) Provide FacesContext for configuration tasks
[ https://issues.apache.org/jira/browse/TRINIDAD-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr resolved TRINIDAD-1902. - Fix Version/s: 2.0.0.3-core Resolution: Fixed Provide FacesContext for configuration tasks Key: TRINIDAD-1902 URL: https://issues.apache.org/jira/browse/TRINIDAD-1902 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 2.0.0.3-core Reporter: Jakob Korherr Assignee: Jakob Korherr Fix For: 2.0.0.3-core MYFACES-2906 shows that Trinidad does not provide a FacesContext for code which normally runs at a time at which a FacesContext is available. The solution is to provide a Pseudo-FacesContext which implements some useful tasks and to set this one as the current instance while configuration is done. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1902) Provide FacesContext for configuration tasks
[ https://issues.apache.org/jira/browse/TRINIDAD-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12905478#action_12905478 ] Jakob Korherr commented on TRINIDAD-1902: - This fix is a first solution for this problem. For the long term it would be better to provide an own (Config-)FacesContext which allows more tasks then the current PseudoFacesContext for the whole filter. Provide FacesContext for configuration tasks Key: TRINIDAD-1902 URL: https://issues.apache.org/jira/browse/TRINIDAD-1902 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 2.0.0.3-core Reporter: Jakob Korherr Assignee: Jakob Korherr Fix For: 2.0.0.3-core MYFACES-2906 shows that Trinidad does not provide a FacesContext for code which normally runs at a time at which a FacesContext is available. The solution is to provide a Pseudo-FacesContext which implements some useful tasks and to set this one as the current instance while configuration is done. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-912) tc:validateFileItem define multiple contentType
tc:validateFileItem define multiple contentType --- Key: TOBAGO-912 URL: https://issues.apache.org/jira/browse/TOBAGO-912 Project: MyFaces Tobago Issue Type: New Feature Components: Core Affects Versions: 1.0.28 Reporter: Guido Dubois Is it possible - if yes, how to do this - or it woul'd be nice to be able to define multiple content types in tag tc:validateFileItem for file uploads like follows tc:validateFileItem maxSize=5242880 contentType=application/pdf, application/vnd.ms-excel / -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1901) Make Trinidad OSGi ready
[ https://issues.apache.org/jira/browse/TRINIDAD-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12905495#action_12905495 ] Matthias Weßendorf commented on TRINIDAD-1901: -- Frank, for myfaces - there was some work (in order to run w/ geronimo) done, I think... (talking about MyFaces2) regarding trinidad I see no reason why to do it for older stuff. If we do, than 2.x IMO Make Trinidad OSGi ready Key: TRINIDAD-1901 URL: https://issues.apache.org/jira/browse/TRINIDAD-1901 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 2.0.0.3-core Reporter: Frank Mittag Priority: Minor Hi, it would be great to create an OSGi ready version of Trinidad (and MyFaces). I'm using Trinidad together with MyFaces in the Eclipse Virgo runtime (former Spring DM Server), but the problems are valid for every OSGi environment. In the first place the API and the IMPL jars need an updated/improved OSGi-ready MANIFEST file exposing the typical OSGi metadata. The content could be created with tools like BND from Peter Kriens which could run as part of the build process (see other projects like Apache Felix, etc.) But normally this is not enough the make a library OSGi-ready. The nature of OSGi allows to run several TRINIDAD's in parallel in the same runtime even in different versions. This leads often to conflicts with singleton objects or class loading issues. There are different usage scenarios where Trinidad should fit: 1. Scenario: Usage of TRINIDAD in two different web apps inside an OSGi runtime. So you have ideally 1 API bundle 1. WAR with the IMPL jar in the lib folder 2. WAR with the IMPL jar in the lib folder or 1. WAR with the API jar and the IMPL jar in the lib folder 2. WAR with the API jar and the IMPL jar in the lib folder 2.Scenario: Usage of TRINIDAD in different web apps in two different versions inside an OSGi runtime. So you have ideally 1 API bundle 1.2.14 1 API bundle 2.0.0.3 1. WAR with the IMPL 1.2.14 jar in the lib folder 2. WAR with the IMPL 2.0.0.3 jar in the lib folder 3. WAR with the IMPL 2.0.0.3 jar in the lib folder or 1. WAR with the API jar and IMPL 1.2.14 jar in the lib folder 2. WAR with the API jar and IMPL 2.0.0.3 jar in the lib folder 3. WAR with the API jar and IMPL 2.0.0.3 jar in the lib folder Even more better would be to have just one API and IMPL bundle in the whole runtime and just reference the bundles from the web app, but I guess this would probably require some refactoring of TRINIDAD. The pattern also applies to the MYFACES libs. Regards, Frank -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
absolute-ordering warning
Hello, I'm committer on the PrettyFaces project and we are currently preparing our next release. While testing the release in different environments I discovered that MyFaces 2.0.1 prints a weird warning to the console: WARNING: absolute-ordering element found in application configuration resource prettyfaces. This description will be ignored and the actions described in ordering elements will be taken into account instead. The weird thing about this is that we DON'T use absolute-ordering in our faces-config.xml at all. Our ordering configuration looks like this: ordering before others/ /before /ordering See: https://prettyfaces.googlecode.com/svn/prettyfaces/trunk/impl-jsf2/src/main/resources/META-INF/faces-config.xml I looked at the MyFaces code and found the code emitting this warning: http://myfaces.apache.org/core20/myfaces-impl/xref/org/apache/myfaces/config/FacesConfigurator.html#982 We discussed this issue on the prettyfaces-dev list. We think that it is a bug in MyFaces. http://groups.google.com/group/prettyfaces-dev/msg/da44e1e6660887c6 What do you think? Is it a bug? Christian -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
[jira] Created: (TOMAHAWK-1545) Components inside detailStamp facet requires clientId reset each time setRowIndex is called
Components inside detailStamp facet requires clientId reset each time setRowIndex is called --- Key: TOMAHAWK-1545 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1545 Project: MyFaces Tomahawk Issue Type: Bug Components: Extended Datatable Affects Versions: 1.1.9 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Checking detailStamp behavior, it was found that sometimes setRowIndex does not reset clientId field using UIComponent.setId(getId()), which could cause problems with invokeOnComponent/visitTree algorithm. It was also found that we have some code on processDetails(FacesContext, int) that saves the state of the row, that it is no longer necessary by the fix done on TOMAHAWK-1534. I think it is better instead save detailStamp state in AbstractHtmlDataTable, change the iterator overriding saveDescendantComponentStates() and restoreDescendantComponentStates(Object state), and on jsf 1.1 and 1.2 branches remove the hack for prevent processing detailStamp removing and adding from facets map. We can also remove the hack for deleteRowStateForRow() on AbstractHtmlDataTable, because since the state will be in just one place, this problem is already handled on HtmlDataTableHack -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-1545) Components inside detailStamp facet requires clientId reset each time setRowIndex is called
[ https://issues.apache.org/jira/browse/TOMAHAWK-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved TOMAHAWK-1545. -- Fix Version/s: 1.1.10-SNAPSHOT Resolution: Fixed Components inside detailStamp facet requires clientId reset each time setRowIndex is called --- Key: TOMAHAWK-1545 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1545 Project: MyFaces Tomahawk Issue Type: Bug Components: Extended Datatable Affects Versions: 1.1.9 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 1.1.10-SNAPSHOT Checking detailStamp behavior, it was found that sometimes setRowIndex does not reset clientId field using UIComponent.setId(getId()), which could cause problems with invokeOnComponent/visitTree algorithm. It was also found that we have some code on processDetails(FacesContext, int) that saves the state of the row, that it is no longer necessary by the fix done on TOMAHAWK-1534. I think it is better instead save detailStamp state in AbstractHtmlDataTable, change the iterator overriding saveDescendantComponentStates() and restoreDescendantComponentStates(Object state), and on jsf 1.1 and 1.2 branches remove the hack for prevent processing detailStamp removing and adding from facets map. We can also remove the hack for deleteRowStateForRow() on AbstractHtmlDataTable, because since the state will be in just one place, this problem is already handled on HtmlDataTableHack -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (TOMAHAWK-1544) org.apache.myfaces.custom.date.HtmlDateRenderer.encodeEnd() broken
[
https://issues.apache.org/jira/browse/TOMAHAWK-1544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12905563#action_12905563
]
Denis A. edited comment on TOMAHAWK-1544 at 9/2/10 12:06 PM:
-
Core12 version is broken too, the provided patch does not address this one
was (Author: dangi):
Core12 version is broken, in the same way too, the provided patch does not
address this one
org.apache.myfaces.custom.date.HtmlDateRenderer.encodeEnd() broken
--
Key: TOMAHAWK-1544
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1544
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Date
Affects Versions: 1.1.9
Reporter: Denis A.
Attachments: TOMAHAWK-1544_bugfix_patch.txt
Original Estimate: 1h
Remaining Estimate: 1h
the problem is in the decoding of date:
if (token.startsWith(year=))
{
userData.setYear(token.substring(5));
}
if (token.startsWith(month=))
{
userData.setYear(token.substring(6));
}
if (token.startsWith(day=))
{
userData.setYear(token.substring(4));
.
userData.setYear() is called for each case, while it should be setMonth(),
setDay() and so on.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1903) Window manager and per window page flow scope
Window manager and per window page flow scope
-
Key: TRINIDAD-1903
URL: https://issues.apache.org/jira/browse/TRINIDAD-1903
Project: MyFaces Trinidad
Issue Type: New Feature
Affects Versions: 1.2.14-core
Reporter: Michael Kurz
Priority: Minor
Some time ago Mark Badorrek posted a development request for a
PageFlowScopeProvider that supports having one page flow scope and one view
cache for every window /tab of the browser. The original request explaining the
problem can be found at [1]. Mark has a working solution for this problem that
supports five hardcoded page flow scopes and view caches (details below).
What he wants to have is a generic solution that comes as part of Trinidad.
Blake suggested that this should be done with a window manager implementation.
I started working on this and provide some very basic code to discuss the
problems involved.
Details for the existing solution:
---
Mark's existing solution mainly consists of a custom page flow scope provider
implementation. This implementation supports a default page flow scope map and
five additional scope maps with predefined names. The names are supplied via
request parameters.
Additionally, they have a custom state manager that also checked the request
parameters and store a separate view cache for each of the five named windows
(including a default view cache).
The following scenario demonstrates how this solution is used. If the user
clicks on a link, a new window using a new page flow scope and view cache is
opened. The JSP fragment looks like this:
tr:goLink textAndAccessKey=... destination=#
onclick=window.open( '#{myBackingBean.getURL}', '...'/
public class MyBackingBean{
public void getURL(){
MapString, Object pageFlowScope = ThePageFlowProviderImpl.
getEmptyPageFlowScopeForRelatedWorkItems();
// Initialize some stuff and put it in the new page flow scope
pageFlowScope.put(key, value);
return ../my/new/frame.jsp? + ThePageFlowProviderImpl.
RELATED_WORK_ITEMS_PAGE_FLOW_SCOPE + =true;
}
}
Effectively the URL assigned to the goLink tag becomes :
../my/new/frame.jsp?relatedworkitems_pageflowscope=true
Once trinidad opens the new window and begins to create the view, it eventually
starts using the new page flow scope defined by the magic key in the URL
(relatedworkitems_pageflowscope) to determine which pageflowscope to use.
---
[1]: http://markmail.org/message/ijyve7oj2ik5l57k
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1899) SessionChangeManager performance and behavior improvements
[ https://issues.apache.org/jira/browse/TRINIDAD-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Sullivan resolved TRINIDAD-1899. -- Resolution: Fixed Resolved in revision 992031 on main Resolved in revision 992030 on 1.2.x SessionChangeManager performance and behavior improvements -- Key: TRINIDAD-1899 URL: https://issues.apache.org/jira/browse/TRINIDAD-1899 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 1.2.14-core , 2.0.0.3-core Reporter: Blake Sullivan Assignee: Blake Sullivan Attachments: trin_1899_1_2_x.diff, trin_1899_main.diff Original Estimate: 48h Remaining Estimate: 48h Currently the SessionChangeManager when working with JSPs maintains a single list of changes to be applied and applies them in order. While the list does support collapsing attribute changes even across component moves, this approach has some performance limitations in and of itself and decreases our ability to make other performance improvements: 1) Because some changes affect multiple components, we wait to the end of the document tag to apply the changes (so that all components exist). Unfortunately this means that when the tags are executing, they don't actually have any values that were modified by a change available to them. This prevents us from applying optimizations where we don't even execute the tags that are subtrees that won't be visited by the lifecycle (for example undisclosed tabs). 2) Because the changes are not applied at the time of tag execution, we need to do a separate findComponent() for each change that we want to apply. This can get expensive for large numbers of changes. The solution is to group changes into 1) Changes that apply to a single component a) Collapsible single changes 2) Cross component changes a) Cross component changes that can change the identity of a component 1) Changes that are applied to a single component are saved under the component's original scoped identifier. The collapsible changes are collapsed. 2) Cross component changes are maintained in a single page wide list 3) Cross component changes that change the identify of a component update a mapping from the new (current scoped identifier) for the component to the original scoped identifier so that as new changes are applied, they are applied to the correct entry in 1) 4) For efficiency, the serialized form of the changes is a single list of changes with all collapsible entries collapsed, even across changes that change the identity. The rename maps and a single component changes can be rebuilt on demand from this list. The upshot of these changes are that: 1) We can apply all of the single component changes to a component at tag execution time, even if that component had a change that moved it. This opens up optimizations where we don't execute child tags 2) Since all collapsible changes, like attribute changes are collapsed, we have fewer changes to apply 3) Only the rare, cross-component changes need to be applied using separate findComponent calls To apply the changes at tag execution time, we need a new api on ChangeManager: /** * Apply non-cross-component changes to a component in its original location. This is typically * only called by tags that need to ensure that a newly created component instance is * as up-to-date as possible. * @param context * @param component Component to apply the simple changes to */ public void applySimpleComponentChanges(FacesContext context, UIComponent component) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2904) javascript _Dom._outerHtml does not handle table items (tr, tbody. ...)
[ https://issues.apache.org/jira/browse/MYFACES-2904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-2904: Status: Resolved (was: Patch Available) Fix Version/s: 2.0.2-SNAPSHOT Resolution: Fixed Ok, thanks Werner for check this one. javascript _Dom._outerHtml does not handle table items (tr, tbody. ...) --- Key: MYFACES-2904 URL: https://issues.apache.org/jira/browse/MYFACES-2904 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.1 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.2-SNAPSHOT Attachments: MYFACES-2904-1.patch Checking some stuff in tomahawk, I found that when a fragment starts with tr or some tag that should be used inside table are trimmed when are replaced on an ajax request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2907) AjaxBehavior does not save ValueExpression instances in the state
AjaxBehavior does not save ValueExpression instances in the state - Key: MYFACES-2907 URL: https://issues.apache.org/jira/browse/MYFACES-2907 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.1 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Checking some ajax stuff, it was found AjaxBehavior uses a map that is not serialized on the state. I think it is better to use a variant _DeltaStateHelper class and handle ValueExpression in a similar way as UIComponentBase does, because that class was tested using many junit tests and to make easier synchronize that code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2907) AjaxBehavior does not save ValueExpression instances in the state
[ https://issues.apache.org/jira/browse/MYFACES-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2907. - Fix Version/s: 2.0.2-SNAPSHOT Resolution: Fixed AjaxBehavior does not save ValueExpression instances in the state - Key: MYFACES-2907 URL: https://issues.apache.org/jira/browse/MYFACES-2907 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.1 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.2-SNAPSHOT Checking some ajax stuff, it was found AjaxBehavior uses a map that is not serialized on the state. I think it is better to use a variant _DeltaStateHelper class and handle ValueExpression in a similar way as UIComponentBase does, because that class was tested using many junit tests and to make easier synchronize that code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2908) UIViewRoot.addComponentResource() adding multiple components with same ID instead of replacing
UIViewRoot.addComponentResource() adding multiple components with same ID instead of replacing -- Key: MYFACES-2908 URL: https://issues.apache.org/jira/browse/MYFACES-2908 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.2-SNAPSHOT Reporter: Michael Concini Assignee: Michael Concini Looks like when MYFACES-2854 was committed, there were two issues it caused where we break spec compliance. Both are around behavior that If the component ID of componentResource matches the the ID of a resource that has allready been added, remove the old resource. The first is that it looks like the else if (componentId != null) statement is in the wrong place. If a UIComponent is added with the same ID as an existing component, we'll never get to this check since we'll be false on the isInView() check. This will cause duplicate ID exceptions to be thrown if multiple objects with the same ID are added. This is easily resolved by moving the else if to kick in whenever isInView() is false. The second issue, and the more important since this is breaking a TCK test, is that since we were only comparing to the parent's ID to the location prefix, we weren't handling the case where the same object gets added a second time after updating the target. This can be resolved by changing if (componentResource.getParent() != null componentResource.getParent().getId() != null componentResource.getParent().getId().startsWith(JAVAX_FACES_LOCATION_PREFIX)) ... to if (componentResource.getParent() != null componentResource.getParent().getId() != null componentResource.getParent().getId().equals(JAVAX_FACES_LOCATION_PREFIX + target)) I'll attach a patch for review while I wait for our CTS team to try the change out. I probably wont' be able to commit until after the US Labor Day holiday since I'm away Friday. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2908) UIViewRoot.addComponentResource() adding multiple components with same ID instead of replacing
[ https://issues.apache.org/jira/browse/MYFACES-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Concini updated MYFACES-2908: - Status: Patch Available (was: Open) UIViewRoot.addComponentResource() adding multiple components with same ID instead of replacing -- Key: MYFACES-2908 URL: https://issues.apache.org/jira/browse/MYFACES-2908 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.2-SNAPSHOT Reporter: Michael Concini Assignee: Michael Concini Attachments: MYFACES-2908-patch.txt Looks like when MYFACES-2854 was committed, there were two issues it caused where we break spec compliance. Both are around behavior that If the component ID of componentResource matches the the ID of a resource that has allready been added, remove the old resource. The first is that it looks like the else if (componentId != null) statement is in the wrong place. If a UIComponent is added with the same ID as an existing component, we'll never get to this check since we'll be false on the isInView() check. This will cause duplicate ID exceptions to be thrown if multiple objects with the same ID are added. This is easily resolved by moving the else if to kick in whenever isInView() is false. The second issue, and the more important since this is breaking a TCK test, is that since we were only comparing to the parent's ID to the location prefix, we weren't handling the case where the same object gets added a second time after updating the target. This can be resolved by changing if (componentResource.getParent() != null componentResource.getParent().getId() != null componentResource.getParent().getId().startsWith(JAVAX_FACES_LOCATION_PREFIX)) ... to if (componentResource.getParent() != null componentResource.getParent().getId() != null componentResource.getParent().getId().equals(JAVAX_FACES_LOCATION_PREFIX + target)) I'll attach a patch for review while I wait for our CTS team to try the change out. I probably wont' be able to commit until after the US Labor Day holiday since I'm away Friday. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (TOMAHAWK-1460) ClassCastException when testing Tomahawk 1.1.9 table demos when preserveDataModel=true
[
https://issues.apache.org/jira/browse/TOMAHAWK-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe reopened TOMAHAWK-1460:
--
I have to revert the patch, go back to stage 1, and try other alternatives
ClassCastException when testing Tomahawk 1.1.9 table demos when
preserveDataModel=true
Key: TOMAHAWK-1460
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1460
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Extended Datatable
Affects Versions: 1.1.9
Environment: Mac OS 10.5.8
JDK 1.6.0
Mojarra 2.0.0-SNAPSHOT
Glassfish V3
Reporter: Ryan Lubke
Assignee: Leonardo Uribe
Fix For: 1.1.10-SNAPSHOT
When executing 'Paged and Sortable', 'Master-Detail', and 'Optional
Header/Footer', a class cast exception is raised during post-back operations
to
update the view.
java.lang.ClassCastException: javax.faces.model.ListDataModel cannot be cast
to
org.apache.myfaces.component.html.ext._SerializableDataModel
at
org.apache.myfaces.component.html.ext.AbstractHtmlDataTable.updateModelFromPreservedDataModel(AbstractHtmlDataTable.java:493)
at
org.apache.myfaces.component.html.ext.AbstractHtmlDataTable.processUpdates(AbstractHtmlDataTable.java:479)
at
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:1108)
at javax.faces.component.UIForm.processUpdates(UIForm.java:265)
at
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:1108)
at javax.faces.component.UIViewRoot.processUpdates(UIViewRoot.java:1238)
I've done some debugging here and have found this block of code being executed
during processRestoreState():
protected DataModel getDataModel()
{
if (_preservedDataModel != null)
{
setDataModel(_preservedDataModel);
_preservedDataModel = null;
}
return super.getDataModel();
}
The call stack at this point in time is:
at
org.apache.myfaces.component.html.ext.AbstractHtmlDataTable.getDataModel(AbstractHtmlDataTable.java:839)
at
org.apache.myfaces.component.html.ext.HtmlDataTableHack.setRowIndex(HtmlDataTableHack.java:282)
at
org.apache.myfaces.component.html.ext.AbstractHtmlDataTable.setRowIndex(AbstractHtmlDataTable.java:276)
at javax.faces.component.UIData.visitColumnsAndRows(UIData.java:1539)
at javax.faces.component.UIData.visitTree(UIData.java:1207)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1454)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1454)
at javax.faces.component.UIForm.visitTree(UIForm.java:333)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1454)
at
javax.faces.component.UIViewRoot.processRestoreState(UIViewRoot.java:868)
The interesting point here is that _preserveDataModel is set to null.
Later, during processUpdates(), updateModelFromPreservedDataModel() will
call getDataModel (as listed above), however, since _preservedDataModel was
set
to null, the call is delegated to the super class, UIData, which returns
ListDataModel.
This change in the code path is new spec required functionality where
UIViewRoot.processRestoreState()
uses the TreeVisitor to notify components of the PostRestoreStateEvent.
Given this, I'm sure the
problem will be manifest with MyFaces 2.0.0.
WORKAROUND: set preservDataModel to false.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-1546) Allow detailStamp to be Ajaxified using f:ajax
Allow detailStamp to be Ajaxified using f:ajax
--
Key: TOMAHAWK-1546
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1546
Project: MyFaces Tomahawk
Issue Type: Improvement
Components: Extended Datatable
Affects Versions: 1.1.9
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
Attachments: TOMAHAWK-1546-1.patch
The idea is allow detailStamp row to be ajaxified, using a new inner facet
called detailStampRow with a component with the same id, that will render the
detailStamp including its clientId, to make possible use it through ajax. The
idea is something like this:
t:dataTable id=data styleClass=standardTable
headerClass=standardTable_Header footerClass=standardTable_Header
rowClasses=standardTable_Row1,standardTable_Row2
columnClasses=standardTable_Column,standardTable_ColumnCentered,standardTable_Column
var=currentCountry
value=#{countryList.countries} preserveDataModel=true
varDetailToggler=detailToggler preserveRowComponentState=true
h:column
f:facet name=header
h:outputText value=#{example_messages['label_country_name']}/
/f:facet
t:commandLink action=go_country immediate=true
h:outputText value=#{currentCountry.name}/
!-- for convenience: MyFaces extension. sets id of current row in
countryForm --
!-- you don't have to implement a custom action! --
t:updateActionListener property=#{countryForm.id}
value=#{currentCountry.id}/
/t:commandLink
/h:column
h:column
f:facet name=header
h:outputText value=#{example_messages['label_country_iso']}/
/f:facet
h:outputText value=#{currentCountry.isoCode}/
/h:column
h:column
f:facet name=header
h:outputText value=#{example_messages['label_country_cities']}/
/f:facet
t:div id=panel
h:commandLink rendered=#{detailToggler.currentDetailExpanded}
action=#{detailToggler.toggleDetail}
h:outputText value=Hide/
f:ajax render=panel detailStampRow/
/h:commandLink
h:commandLink rendered=#{!detailToggler.currentDetailExpanded}
action=#{detailToggler.toggleDetail}
h:outputText value=Show/
f:ajax render=panel detailStampRow/
/h:commandLink
/t:div
/h:column
f:facet name=detailStamp
t:dataTable id=cities styleClass=standardTable_Column var=city
value=#{currentCountry.cities} preserveDataModel=true
preserveRowComponentState=true
h:column
h:outputText value=#{city} style=font-size: 11px/
/h:column
h:column
h:selectBooleanCheckbox id=selcity value=#{city.selected}
onclick=this.blur();
f:ajax/
/h:selectBooleanCheckbox
/h:column
h:column
h:commandLink action=#{city.unselect} value=Unselect
f:ajax execute=@this render=cities/f:ajax
/h:commandLink
/h:column
/t:dataTable
/f:facet
/t:dataTable
I'll commit the proposal, but let this one open until all tests for this
feature will be done.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-1460) ClassCastException when testing Tomahawk 1.1.9 table demos when preserveDataModel=true
[
https://issues.apache.org/jira/browse/TOMAHAWK-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved TOMAHAWK-1460.
--
Resolution: Fixed
After testing it, it seems the problem was caused by TOMAHAWK-1545. I'll close
this one as fixed for now, because with the latest code I can't reproduce it
after previous fixes. Anyway, I added a check for _SerializableDataModel on
updateModelFromPreservedDataModel, because it is possible in jsf 2.0 to reach
that point with a non serializable datamodel, and the are not side effects if
that so.
ClassCastException when testing Tomahawk 1.1.9 table demos when
preserveDataModel=true
Key: TOMAHAWK-1460
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1460
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Extended Datatable
Affects Versions: 1.1.9
Environment: Mac OS 10.5.8
JDK 1.6.0
Mojarra 2.0.0-SNAPSHOT
Glassfish V3
Reporter: Ryan Lubke
Assignee: Leonardo Uribe
Fix For: 1.1.10-SNAPSHOT
When executing 'Paged and Sortable', 'Master-Detail', and 'Optional
Header/Footer', a class cast exception is raised during post-back operations
to
update the view.
java.lang.ClassCastException: javax.faces.model.ListDataModel cannot be cast
to
org.apache.myfaces.component.html.ext._SerializableDataModel
at
org.apache.myfaces.component.html.ext.AbstractHtmlDataTable.updateModelFromPreservedDataModel(AbstractHtmlDataTable.java:493)
at
org.apache.myfaces.component.html.ext.AbstractHtmlDataTable.processUpdates(AbstractHtmlDataTable.java:479)
at
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:1108)
at javax.faces.component.UIForm.processUpdates(UIForm.java:265)
at
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:1108)
at javax.faces.component.UIViewRoot.processUpdates(UIViewRoot.java:1238)
I've done some debugging here and have found this block of code being executed
during processRestoreState():
protected DataModel getDataModel()
{
if (_preservedDataModel != null)
{
setDataModel(_preservedDataModel);
_preservedDataModel = null;
}
return super.getDataModel();
}
The call stack at this point in time is:
at
org.apache.myfaces.component.html.ext.AbstractHtmlDataTable.getDataModel(AbstractHtmlDataTable.java:839)
at
org.apache.myfaces.component.html.ext.HtmlDataTableHack.setRowIndex(HtmlDataTableHack.java:282)
at
org.apache.myfaces.component.html.ext.AbstractHtmlDataTable.setRowIndex(AbstractHtmlDataTable.java:276)
at javax.faces.component.UIData.visitColumnsAndRows(UIData.java:1539)
at javax.faces.component.UIData.visitTree(UIData.java:1207)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1454)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1454)
at javax.faces.component.UIForm.visitTree(UIForm.java:333)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1454)
at
javax.faces.component.UIViewRoot.processRestoreState(UIViewRoot.java:868)
The interesting point here is that _preserveDataModel is set to null.
Later, during processUpdates(), updateModelFromPreservedDataModel() will
call getDataModel (as listed above), however, since _preservedDataModel was
set
to null, the call is delegated to the super class, UIData, which returns
ListDataModel.
This change in the code path is new spec required functionality where
UIViewRoot.processRestoreState()
uses the TreeVisitor to notify components of the PostRestoreStateEvent.
Given this, I'm sure the
problem will be manifest with MyFaces 2.0.0.
WORKAROUND: set preservDataModel to false.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
