[jira] [Commented] (MYFACES-3816) missing window-handling for initial requests
[ https://issues.apache.org/jira/browse/MYFACES-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13812402#comment-13812402 ] Leonardo Uribe commented on MYFACES-3816: - I'm not saying that the logic does not have sense, of course it has sense. What I'm saying is the default mode should have the default behavior. If the default mode has a bug, raise an issue against the spec, not change the default behavior because that could open a hole and cause problems later in the compatibility test. Unfortunately we don't have choice, that's the reason why there is a "reference implementation". > missing window-handling for initial requests > > > Key: MYFACES-3816 > URL: https://issues.apache.org/jira/browse/MYFACES-3816 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-344 >Affects Versions: 2.2.0-beta >Reporter: Gerhard Petracek >Assignee: Leonardo Uribe > > for an initial request there is no window-id added to the url. > (tested with 'url' for javax.faces.CLIENT_WINDOW_MODE) > -> in case of a page refresh a new window-id will be created and it isn't > possible to get back the original one. that can also happen with a > page-refresh after multiple requests, if only ajax requests are used. > that's a major issue for all scopes based on the window-id. > it can be done with an initial redirect (default in codi) or js (with html5 > compliant browsers) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3816) missing window-handling for initial requests
[ https://issues.apache.org/jira/browse/MYFACES-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13812398#comment-13812398 ] Leonardo Uribe commented on MYFACES-3816: - Is it really broken? or we are dealing with an specific non frequent case? what could be wrong? The code was taken directly from CODI, so is CODI broken in as well? If a new windowId is created in a page refresh, it doesn't matter, because if it reuse the previous one or the new one, the state in session will be just the same. Why do we have to go back to the previous one that is not being used?. The worst that can happen is create a bean twice (one in a previous context and the second in the current context). It is still looks like an implementation detail of the specific used mode. If the user care about that, just add a new mode and problem solved. > missing window-handling for initial requests > > > Key: MYFACES-3816 > URL: https://issues.apache.org/jira/browse/MYFACES-3816 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-344 >Affects Versions: 2.2.0-beta >Reporter: Gerhard Petracek >Assignee: Leonardo Uribe > > for an initial request there is no window-id added to the url. > (tested with 'url' for javax.faces.CLIENT_WINDOW_MODE) > -> in case of a page refresh a new window-id will be created and it isn't > possible to get back the original one. that can also happen with a > page-refresh after multiple requests, if only ajax requests are used. > that's a major issue for all scopes based on the window-id. > it can be done with an initial redirect (default in codi) or js (with html5 > compliant browsers) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3816) missing window-handling for initial requests
[ https://issues.apache.org/jira/browse/MYFACES-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13812392#comment-13812392 ] Leonardo Uribe commented on MYFACES-3816: - I don't think this is a bug. The "url" mode works just like the same mode in Mojarra does, and it is better to keep this mode in that way, to ensure compatibility in testing. Instead we could create a new mode "url-redirect" that do what you propose. Note the "client" mode, implemented in CODIClientSideWindow.java do the redirect. > missing window-handling for initial requests > > > Key: MYFACES-3816 > URL: https://issues.apache.org/jira/browse/MYFACES-3816 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-344 >Affects Versions: 2.2.0-beta >Reporter: Gerhard Petracek >Assignee: Leonardo Uribe > > for an initial request there is no window-id added to the url. > (tested with 'url' for javax.faces.CLIENT_WINDOW_MODE) > -> in case of a page refresh a new window-id will be created and it isn't > possible to get back the original one. that can also happen with a > page-refresh after multiple requests, if only ajax requests are used. > that's a major issue for all scopes based on the window-id. > it can be done with an initial redirect (default in codi) or js (with html5 > compliant browsers) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MYFACES-3815) Lazy instantiation of Renderer classes
Leonardo Uribe created MYFACES-3815: --- Summary: Lazy instantiation of Renderer classes Key: MYFACES-3815 URL: https://issues.apache.org/jira/browse/MYFACES-3815 Project: MyFaces Core Issue Type: Improvement Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe The initialization algorithm create all Renderer instances at startup time. The side effect is a lot of classes are loaded into permgen memory without need. With a clever trick we can avoid that, providing a custom interfaces LazyRenderKit and making html basic renderkit implements it. Then, in the init code we check for that interface and if is present, we use it to register the Renderer in a lazy way, otherwise we use the standard form. Add the required method to RenderKit looks like a good idea for include it in the spec. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3814) Allow ServiceProviderFinder to be initialized at startup
[ https://issues.apache.org/jira/browse/MYFACES-3814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13811368#comment-13811368 ] Leonardo Uribe commented on MYFACES-3814: - I changed the name of the issue, because put that information in FacesConfig does not work very well. The reason is SPI lookup needs to be setup before config code. The idea is add two methods: public Map> calculateKnownServiceProviderMapInfo(ExternalContext ectx, String[] knownServices) public void initKnownServiceProviderMapInfo(ExternalContext ectx, Map> map) At startup, MyFaces calls calculateKnownServiceProviderMapInfo and provide the list of known services used by ServiceProviderFinder. By default it returns null, but the idea is custom implementations can provide the logic that scan the classpath and find the configuration. If the configuration has been serialized somewhere the idea is put there the code that restore that information. Then MyFaces will call initKnownServiceProviderMapInfo and it will pass the map, so the default implementation can grab the map and use it into its logic. > Allow ServiceProviderFinder to be initialized at startup > > > Key: MYFACES-3814 > URL: https://issues.apache.org/jira/browse/MYFACES-3814 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > > The code inside ServiceProviderFinder usually involves classpath scanning and > read files from different locations. That code is ok, but it would be great > if we can put that into FacesConfig as a configuration information. > The idea is just list all SPI interfaces we are using in MyFaces Core, and do > the scanning of everything we need right at startup and finally store that > information into FacesConfig, just like it was done for Facelet tag lib > configuration. > If FacesConfig is serialized and deserialized, that scanning will not be > necessary and the startup will be faster. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MYFACES-3814) Integrate default ServiceProviderFinder into FacesConfig
Leonardo Uribe created MYFACES-3814: --- Summary: Integrate default ServiceProviderFinder into FacesConfig Key: MYFACES-3814 URL: https://issues.apache.org/jira/browse/MYFACES-3814 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe The code inside ServiceProviderFinder usually involves classpath scanning and read files from different locations. That code is ok, but it would be great if we can put that into FacesConfig as a configuration information. The idea is just list all SPI interfaces we are using in MyFaces Core, and do the scanning of everything we need right at startup and finally store that information into FacesConfig, just like it was done for Facelet tag lib configuration. If FacesConfig is serialized and deserialized, that scanning will not be necessary and the startup will be faster. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MYFACES-3813) Cleanup org.apache.myfaces.config.impl.digester.elements package
Leonardo Uribe created MYFACES-3813: --- Summary: Cleanup org.apache.myfaces.config.impl.digester.elements package Key: MYFACES-3813 URL: https://issues.apache.org/jira/browse/MYFACES-3813 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe The classes at org.apache.myfaces.config.impl.digester.elements has the same names as in org.apache.myfaces.config.element That becomes a real pain because most of the times you need both the interface and the implementation, and you end up writing the full package name all over the places. We need to fix that and use *Impl suffix for the classes that implement something. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MYFACES-3812) Cleanup Facelets Initialization Code and decouple facelets taglibrary config parsing
Leonardo Uribe created MYFACES-3812: --- Summary: Cleanup Facelets Initialization Code and decouple facelets taglibrary config parsing Key: MYFACES-3812 URL: https://issues.apache.org/jira/browse/MYFACES-3812 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe In JSF 2.0, Facelets initialization code was just put in place to work right from facelets 1.1.x, but there was not included properly into MyFaces algorithm that loads configuration. In this moment, half of the initialization of MyFaces Core is done at startup and the other half is done when FaceletViewDeclarationLanguage is created, which happens at the first request. The code that parse facelets .taglib.xml is a simple sax parser that manipulates directly a TagLibrary. The problem with this is this config information once parsed cannot be serialized. Parse files is a slow process, so we need some classes like with org.apache.myfaces.config.element.FacesConfig, and provide implementation that can be serialized. The idea is just attach the information to FacesConfig using custom classes, and add a new source for FacesConfig information. In that way, it is possible to provide custom implementations of org.apache.myfaces.spi.FacesConfigurationProvider and override all MyFaces configuration in one step. The only exception is all web config params, but that's not a problem, because that information is managed and optimized for fast access by the web server. This is something we need to do before 2.2.x release. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MYFACES-3811) Fix c:forEach behavior once for all
Leonardo Uribe created MYFACES-3811: --- Summary: Fix c:forEach behavior once for all Key: MYFACES-3811 URL: https://issues.apache.org/jira/browse/MYFACES-3811 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe It is well known c:forEach tag is broken, and that it is advised to users to avoid this tag or at least ensure the collection that iterates this component to be static over the application lifetime. But users keep trying over and over to use this tag, perceiving this behavior as a bug. See: - MYFACES-3570 - MYFACES-3389 - MYFACES-3329 A lot of important fixes has been done in MyFaces code, and with the introduction of 2.2.x, we can finally try to fix this problem once for all. The challenge for this issue is we need to save the iteration data (only if the data is Serializable or StateHolder) into the component state and synchronize this with the generated ids, so if a new element is added or an existing one is removed, we keep the state and the id generation consistent. Now we have the environment set to do the job: an stable id generation algorithm, a well understood algorithm for PSS and we are in the process to get a release of 2.2 branch. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MYFACES-3810) Add compatibility mode for facelets 1.1.x behavior
Leonardo Uribe created MYFACES-3810: --- Summary: Add compatibility mode for facelets 1.1.x behavior Key: MYFACES-3810 URL: https://issues.apache.org/jira/browse/MYFACES-3810 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Some big improvements and fixes has been done over the time in MyFaces 2.0.x / 2.1.x . But on the way some changes were done over some tags like: - c:set - ui:param - user custom tag handlers And others. See this issues: - MYFACES-3169 - MYFACES-2753 - MYFACES-2293 The current changes are completely justified and there is no turning back. These changes are very important to allow techniques like EL expression caching to work correctly. But it is also true that Mojarra still has the old behavior, and there are still web applications out there that relies on that behavior. Users trying to migrate from Mojarra to MyFaces usually found this problem. The proposal for this issue is create a web config param called org.apache.myfaces.STRICT_JSF_2_FACELETS_COMPATIBILITY by default false that when is enabled, the old way to do things is activated. Legacy versions of c:set, uiparam and user tag handler are activated. The aim is just provide a workaround for those cases and incentive users to change their application code to a more standard and stable form. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3066) CLONE - UIView.createUniqueId shouldn't call encodeNameSpace to build the id (1.2.x branch).
[ https://issues.apache.org/jira/browse/MYFACES-3066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807077#comment-13807077 ] Leonardo Uribe commented on MYFACES-3066: - The issue you describe is not related to this one or to MyFaces. In theory, UIViewRoot id should be prefixed in portlet environment, to make a difference between different windows. It should be something related to richfaces, in my humble opinion. > CLONE - UIView.createUniqueId shouldn't call encodeNameSpace to build the id > (1.2.x branch). > > > Key: MYFACES-3066 > URL: https://issues.apache.org/jira/browse/MYFACES-3066 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 1.2.10, 2.0.4 >Reporter: Michael Freedman >Assignee: Leonardo Uribe > Fix For: 1.2.11 > > > Submitting a new bug based on one I recently reopened as it pertains to 1.2 > and 2.0 impls as well: > Referer bug: https://issues.apache.org/jira/browse/MYFACES-702 > Problem reported in the above bug is related to the component's id being > prefixed with the portletNamespace which is caused by calling > encodeNamespace. Why is this api called in generating the component id. > encodeNamespace was added to external context by and large for the portlet > environment to allow it to prefix client ids to be unique on the page they > are being incorporated into. Is there a reason for needing this when > generating the component id? FYI ... Mojarra doesn't make this call from > createUniqureId. > Hopefully, this is something that can be fixed by just removing the call -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3066) CLONE - UIView.createUniqueId shouldn't call encodeNameSpace to build the id (1.2.x branch).
[ https://issues.apache.org/jira/browse/MYFACES-3066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807027#comment-13807027 ] Leonardo Uribe commented on MYFACES-3066: - This issue is pretty old, but I remember the fix was done in all branches since 1.2.x, so 2.0.x, 2.1.x and 2.2.x has the fix. > CLONE - UIView.createUniqueId shouldn't call encodeNameSpace to build the id > (1.2.x branch). > > > Key: MYFACES-3066 > URL: https://issues.apache.org/jira/browse/MYFACES-3066 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 1.2.10, 2.0.4 >Reporter: Michael Freedman >Assignee: Leonardo Uribe > Fix For: 1.2.11 > > > Submitting a new bug based on one I recently reopened as it pertains to 1.2 > and 2.0 impls as well: > Referer bug: https://issues.apache.org/jira/browse/MYFACES-702 > Problem reported in the above bug is related to the component's id being > prefixed with the portletNamespace which is caused by calling > encodeNamespace. Why is this api called in generating the component id. > encodeNamespace was added to external context by and large for the portlet > environment to allow it to prefix client ids to be unique on the page they > are being incorporated into. Is there a reason for needing this when > generating the component id? FYI ... Mojarra doesn't make this call from > createUniqureId. > Hopefully, this is something that can be fixed by just removing the call -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Deleted] (MYFACES-3808) Add http://java.sun.com/jstl/core as a valid namespace for "c" jstl library in facelets
[ https://issues.apache.org/jira/browse/MYFACES-3808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe deleted MYFACES-3808: > Add http://java.sun.com/jstl/core as a valid namespace for "c" jstl library > in facelets > --- > > Key: MYFACES-3808 > URL: https://issues.apache.org/jira/browse/MYFACES-3808 > Project: MyFaces Core > Issue Type: Task >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > > This namespace was used in the early stages of JSF 2.0 development, but later > it was fixed to use the same syntax for jsp. But some applications still uses > the old syntax and it is too hard to fix hundreds of files using this > namespace, so in JSF 2.2 it was decided to add this namespace as an > alternative synonym. I discover this one trying to run the compatibility test > against the latest snapshot. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (MYFACES-3807) Add http://java.sun.com/jstl/core as a valid namespace for "c" jstl library in facelets
[ https://issues.apache.org/jira/browse/MYFACES-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3807. - Resolution: Fixed Fix Version/s: 2.2.0-beta > Add http://java.sun.com/jstl/core as a valid namespace for "c" jstl library > in facelets > --- > > Key: MYFACES-3807 > URL: https://issues.apache.org/jira/browse/MYFACES-3807 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0-beta > > > This namespace was used in the early stages of JSF 2.0 development, but later > it was fixed to use the same syntax for jsp. But some applications still uses > the old syntax and it is too hard to fix hundreds of files using this > namespace, so in JSF 2.2 it was decided to add this namespace as an > alternative synonym. I discover this one trying to run the compatibility test > against the latest snapshot. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MYFACES-3809) Add http://java.sun.com/jstl/core as a valid namespace for "c" jstl library in facelets
Leonardo Uribe created MYFACES-3809: --- Summary: Add http://java.sun.com/jstl/core as a valid namespace for "c" jstl library in facelets Key: MYFACES-3809 URL: https://issues.apache.org/jira/browse/MYFACES-3809 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe This namespace was used in the early stages of JSF 2.0 development, but later it was fixed to use the same syntax for jsp. But some applications still uses the old syntax and it is too hard to fix hundreds of files using this namespace, so in JSF 2.2 it was decided to add this namespace as an alternative synonym. I discover this one trying to run the compatibility test against the latest snapshot. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MYFACES-3807) Add http://java.sun.com/jstl/core as a valid namespace for "c" jstl library in facelets
Leonardo Uribe created MYFACES-3807: --- Summary: Add http://java.sun.com/jstl/core as a valid namespace for "c" jstl library in facelets Key: MYFACES-3807 URL: https://issues.apache.org/jira/browse/MYFACES-3807 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe This namespace was used in the early stages of JSF 2.0 development, but later it was fixed to use the same syntax for jsp. But some applications still uses the old syntax and it is too hard to fix hundreds of files using this namespace, so in JSF 2.2 it was decided to add this namespace as an alternative synonym. I discover this one trying to run the compatibility test against the latest snapshot. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MYFACES-3808) Add http://java.sun.com/jstl/core as a valid namespace for "c" jstl library in facelets
Leonardo Uribe created MYFACES-3808: --- Summary: Add http://java.sun.com/jstl/core as a valid namespace for "c" jstl library in facelets Key: MYFACES-3808 URL: https://issues.apache.org/jira/browse/MYFACES-3808 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe This namespace was used in the early stages of JSF 2.0 development, but later it was fixed to use the same syntax for jsp. But some applications still uses the old syntax and it is too hard to fix hundreds of files using this namespace, so in JSF 2.2 it was decided to add this namespace as an alternative synonym. I discover this one trying to run the compatibility test against the latest snapshot. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (MYFACES-2799) JSF 2.1: jsf.js viewstate handling does not entirely work out (bug filed on the spec tracker
[ https://issues.apache.org/jira/browse/MYFACES-2799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2799. - Resolution: Fixed The changes were done in the spec for 2.2 long time ago. > JSF 2.1: jsf.js viewstate handling does not entirely work out (bug filed on > the spec tracker > > > Key: MYFACES-2799 > URL: https://issues.apache.org/jira/browse/MYFACES-2799 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.2-SNAPSHOT, 2.1.0 >Reporter: Werner Punz > Fix For: 2.2.0-beta > > > Only issuer form and render target forms currently are updated, execute forms > should be as well. > This entire update mess again is caused by portlets constraints > theoretically all forms within the document should be updated with their > viewstates on server side state saving, we cannot do that due to > having also to be able to run in portlets > , we need a reliable portlet detection to fix this issue properly. > (Burgreport on the jsf side is filed) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (MYFACES-3797) cdi support for converters and validators
[ https://issues.apache.org/jira/browse/MYFACES-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3797. - Resolution: Fixed > cdi support for converters and validators > - > > Key: MYFACES-3797 > URL: https://issues.apache.org/jira/browse/MYFACES-3797 > Project: MyFaces Core > Issue Type: New Feature > Components: JSR-344 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek > Fix For: 2.2.0-beta > > Attachments: MYFACES-3797_wrapper.patch > > > with > > > org.apache.myfaces.CDI_MANAGED_CONVERTERS_ENABLED > true > > and > > > org.apache.myfaces.CDI_MANAGED_VALIDATORS_ENABLED > true > > it should be possible to enable cdi support for converters/validators. > we need the config, because it was postponed for the spec. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Reopened] (MYFACES-3797) cdi support for converters and validators
[ https://issues.apache.org/jira/browse/MYFACES-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe reopened MYFACES-3797: - Detected transitive class dependency to CDI through ExternalArtifactResolver. The fix is just make ExternalArtifactResolver abstract and move the code to another class, so when the classloader loads Application in memory it does not load the CDI api. > cdi support for converters and validators > - > > Key: MYFACES-3797 > URL: https://issues.apache.org/jira/browse/MYFACES-3797 > Project: MyFaces Core > Issue Type: New Feature > Components: JSR-344 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek > Fix For: 2.2.0-beta > > Attachments: MYFACES-3797_wrapper.patch > > > with > > > org.apache.myfaces.CDI_MANAGED_CONVERTERS_ENABLED > true > > and > > > org.apache.myfaces.CDI_MANAGED_VALIDATORS_ENABLED > true > > it should be possible to enable cdi support for converters/validators. > we need the config, because it was postponed for the spec. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[ https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3786. - Resolution: Fixed > Web Container injection support should be provided for additional lifecycle > artifacts (not just managed beans) > -- > > Key: MYFACES-3786 > URL: https://issues.apache.org/jira/browse/MYFACES-3786 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0-beta > > Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, > cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, > cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, > cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, > MYFACES-3786-2.patch, MYFACES-3786_bean-entry_draft_01.patch, > MYFACES-3786_internal_bean-entry_draft.patch > > > This issue is all about how to inject beans into jsf artifacts. > See JSF 2.2 section 5.4.1 > The problem here is in some point we need to give the control to the > underlying environment to inject beans into the artifacts, but we don't know > much about how to properly do it, so we need to try with examples. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[ https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13804588#comment-13804588 ] Leonardo Uribe commented on MYFACES-3786: - Added improvement enforce CDI integration by default before web server integration. > Web Container injection support should be provided for additional lifecycle > artifacts (not just managed beans) > -- > > Key: MYFACES-3786 > URL: https://issues.apache.org/jira/browse/MYFACES-3786 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0-beta > > Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, > cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, > cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, > cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, > MYFACES-3786-2.patch, MYFACES-3786_bean-entry_draft_01.patch, > MYFACES-3786_internal_bean-entry_draft.patch > > > This issue is all about how to inject beans into jsf artifacts. > See JSF 2.2 section 5.4.1 > The problem here is in some point we need to give the control to the > underlying environment to inject beans into the artifacts, but we don't know > much about how to properly do it, so we need to try with examples. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Reopened] (MYFACES-3780) _ComponentAttributesMap return null when no property descriptor is available and null value is passed to map
[ https://issues.apache.org/jira/browse/MYFACES-3780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe reopened MYFACES-3780: - Found compatibility test that fails if this patch is applied, reverting fix and closing it as invalid. > _ComponentAttributesMap return null when no property descriptor is available > and null value is passed to map > > > Key: MYFACES-3780 > URL: https://issues.apache.org/jira/browse/MYFACES-3780 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314, JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.0.19, 2.1.13, 2.2.0-beta > > > Checking some stuff I have found that there is an old check for null in > ComponentAttributesMap.put(...) > This check doesn't have sense, because null values are valid for hashmap, and > in that sense the check is useless. > The fix is very simple, just remove the unnecessary check. I just comment the > related code, to prevent other people to try to add it in the future. > The fix will be done on 2.0.x, 2.1.x and 2.2.x branches -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (MYFACES-3674) Implement f:viewAction
[ https://issues.apache.org/jira/browse/MYFACES-3674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3674. - Resolution: Fixed Fix Version/s: 2.2.0-beta > Implement f:viewAction > -- > > Key: MYFACES-3674 > URL: https://issues.apache.org/jira/browse/MYFACES-3674 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0-beta > > > Implement f:viewAction as described in JSF 2.2 spec. > Note there are some pending details that needs to be fixed before close this > issue. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (MYFACES-3685) Implement f:attributes facelet tag
[ https://issues.apache.org/jira/browse/MYFACES-3685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3685. - Resolution: Fixed Fix Version/s: 2.2.0-beta > Implement f:attributes facelet tag > -- > > Key: MYFACES-3685 > URL: https://issues.apache.org/jira/browse/MYFACES-3685 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0-beta > > > Implement f:attributes facelet tag as described in JSF 2.2 spec -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (MYFACES-3686) Implement f:passThroughAttribute and f:passThroughAttributes
[ https://issues.apache.org/jira/browse/MYFACES-3686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3686. - Resolution: Fixed Fix Version/s: 2.2.0-beta > Implement f:passThroughAttribute and f:passThroughAttributes > > > Key: MYFACES-3686 > URL: https://issues.apache.org/jira/browse/MYFACES-3686 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0-beta > > > Implement f:passThroughAttribute and f:passThroughAttributes as described in > JSF 2.2 spec > Note this one is tricky, because these attributes are rendered using > ResponseWriter instead add some code in the Renderer implementation, and care > must be taken to keep code as fast as possible. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (MYFACES-3692) Implement jsf:element tag and default TagDecorator
[ https://issues.apache.org/jira/browse/MYFACES-3692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3692. - Resolution: Fixed Fix Version/s: 2.2.0-beta > Implement jsf:element tag and default TagDecorator > -- > > Key: MYFACES-3692 > URL: https://issues.apache.org/jira/browse/MYFACES-3692 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0-beta > > > Implement jsf:element tag as described in the spec -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (MYFACES-3679) Implement javax.faces.application.ApplicationConfigurationPopulator
[ https://issues.apache.org/jira/browse/MYFACES-3679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3679. - Resolution: Fixed Fix Version/s: 2.2.0-beta > Implement javax.faces.application.ApplicationConfigurationPopulator > --- > > Key: MYFACES-3679 > URL: https://issues.apache.org/jira/browse/MYFACES-3679 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0-beta > > > This is a new way to provide faces-config configuration. We should do the > necessary changes. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (MYFACES-3676) Implement FlashFactory and related events
[ https://issues.apache.org/jira/browse/MYFACES-3676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3676. - Resolution: Fixed Fix Version/s: 2.2.0-beta > Implement FlashFactory and related events > - > > Key: MYFACES-3676 > URL: https://issues.apache.org/jira/browse/MYFACES-3676 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0-beta > > > Implement FlashFactory and related events as described in JSF 2.2 spec -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (MYFACES-3747) Implement new JSF 2.2 ViewScope specification
[ https://issues.apache.org/jira/browse/MYFACES-3747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3747. - Resolution: Fixed Fix Version/s: 2.2.0-beta Assignee: Leonardo Uribe > Implement new JSF 2.2 ViewScope specification > - > > Key: MYFACES-3747 > URL: https://issues.apache.org/jira/browse/MYFACES-3747 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0-beta > > > JSF 2.2 spec includes some changes related to view scope behavior: > - There is a new CDI annotation javax.faces.view.ViewScoped > - In UIViewRoot.getViewMap() javadoc it says: "... For reasons made clear in > ViewScoped, this map must ultimately be stored in the session. For this > reason, a true value for the create argument will force the session to be > created with a call to ExternalContext.getSession(boolean). " > - Both @ViewScoped annotations javadoc include this: "... The runtime must > ensure that any methods on the bean annotated with PostConstruct or > PreDestroy are called when the scope begins and ends, respectively. Two > circumstances can cause the scope to end. ..." > - "... In the session expiration case, the runtime must ensure that > FacesContext.getCurrentInstance() returns a valid instance if it is called > during the processing of the @PreDestroy annotated method. The set of methods > on FacesContext that are valid to call in this circumstance is identical to > those documented as "valid to call this method during application startup or > shutdown". On the ExternalContext returned from that FacesContext, all of the > methods documented as "valid to call this method during application startup > or shutdown" are valid to call. In addition, the method > ExternalContext.getSessionMap() is also valid to call. ..." -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MYFACES-3806) Destroy ViewScope beans when view is discarded from view state.
Leonardo Uribe created MYFACES-3806: --- Summary: Destroy ViewScope beans when view is discarded from view state. Key: MYFACES-3806 URL: https://issues.apache.org/jira/browse/MYFACES-3806 Project: MyFaces Core Issue Type: Improvement Components: JSR-344 Reporter: Leonardo Uribe According to JSF 2.2 spec, view scope beans are destroyed when the session is destroyed, but it could be better if we destroy the beans when the associated view is discarded by server side state saving algorithm. We probably need to duplicate the view map key but it is ok to do so in this case, because a view scope bean can increate session size faster than the additional view map key. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3805) check handling of serializable converters and validators
[ https://issues.apache.org/jira/browse/MYFACES-3805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799273#comment-13799273 ] Leonardo Uribe commented on MYFACES-3805: - Does it work as specified in the reference implementation (Mojarra)? Probably these lines comes from 1.0, and on the way with the introduction of PSS something changed, or in this case Serializable converters were never a concern (I can't find any). Probably with the problem about injection on converters and validators this becomes relevant. > check handling of serializable converters and validators > > > Key: MYFACES-3805 > URL: https://issues.apache.org/jira/browse/MYFACES-3805 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Affects Versions: 2.2.0 >Reporter: Gerhard Petracek >Assignee: Leonardo Uribe > > it doesn't work as specified in paragraph 7.8.1. > once we change something here, we also have to handle it for MYFACES-3797. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3606) Flash scope looses values on redirect when immediate=true
[
https://issues.apache.org/jira/browse/MYFACES-3606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799253#comment-13799253
]
Leonardo Uribe commented on MYFACES-3606:
-
Thanks for the example, it has been helpful.
> Flash scope looses values on redirect when immediate=true
> -
>
> Key: MYFACES-3606
> URL: https://issues.apache.org/jira/browse/MYFACES-3606
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.1.8
> Environment: JDK 1.6, Tomcat 7, JSF 2.1.8
>Reporter: Luis Roche
>Assignee: Leonardo Uribe
> Attachments: MyFaces.zip
>
>
> I have the following button:
> action="#{testBean.actionTest}">
> As part of the testBean.actionTest, I am adding a message to Flash Scope.
> public String actionTest() {
>
> FacesContext.getCurrentInstance().getExternalContext().getFlash().put("infoMessage","TEST
> IMMEDIATE");
> return "page2?faces-redirect=true";
> }
> I do not see the flash message displayed on the next screen when I press the
> command button. I will
> see the message if immediate is set to false.
> This works fine with Mojarra 2.1.12
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (MYFACES-3752) Flash.setKeepMessages(true) does not work with immediate-Commandbutton
[ https://issues.apache.org/jira/browse/MYFACES-3752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3752. - Resolution: Fixed Fix Version/s: 2.1.13 2.0.19 Assignee: Leonardo Uribe Thanks for the example and the tip to solve this issue. > Flash.setKeepMessages(true) does not work with immediate-Commandbutton > -- > > Key: MYFACES-3752 > URL: https://issues.apache.org/jira/browse/MYFACES-3752 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.1.12 > Environment: Java 7.0_02, Tomcat 7.0.32 >Reporter: Martin Maier-Moessner >Assignee: Leonardo Uribe > Fix For: 2.0.19, 2.1.13 > > Attachments: jsfTest.zip > > > If you set Flash.setKeepMessages(true) in an action of an > immediate-true-button, the messages do not survive the Request-Redirect-Post > cycle. If the button is set to immediate="false", setKeepMessages works as > advertised. > I will attach a simple test case that shows this problem. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3752) Flash.setKeepMessages(true) does not work with immediate-Commandbutton
[ https://issues.apache.org/jira/browse/MYFACES-3752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799239#comment-13799239 ] Leonardo Uribe commented on MYFACES-3752: - I have finally found a solution for this one. Definitively the problem is inside _isLastPhaseInRequest() . It only check redirect flag if the current phase is INVOKE_APPLICATION, which sound enough in the context of a Post-Redirect-Get pattern. In this case we can take advantage of a side effect of redirect, that according to the spec calls responseComplete(). Instead check for INVOKE_APPLICATION phase, we can check if getResponseComplete() is true, and if that so and it is found the redirect flag, we can be sure that the current phase is the last phase. > Flash.setKeepMessages(true) does not work with immediate-Commandbutton > -- > > Key: MYFACES-3752 > URL: https://issues.apache.org/jira/browse/MYFACES-3752 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.1.12 > Environment: Java 7.0_02, Tomcat 7.0.32 >Reporter: Martin Maier-Moessner > Attachments: jsfTest.zip > > > If you set Flash.setKeepMessages(true) in an action of an > immediate-true-button, the messages do not survive the Request-Redirect-Post > cycle. If the button is set to immediate="false", setKeepMessages works as > advertised. > I will attach a simple test case that shows this problem. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MYFACES-3804) Use the same key in server side state saving for ajax requests
Leonardo Uribe created MYFACES-3804: --- Summary: Use the same key in server side state saving for ajax requests Key: MYFACES-3804 URL: https://issues.apache.org/jira/browse/MYFACES-3804 Project: MyFaces Core Issue Type: Improvement Components: JSR-344 Reporter: Leonardo Uribe The current code for server side state saving creates one key per request to store the view state. This is ok, but it is not necessary for ajax requests. The reason why is not necessary is because you can never go back to a page when using ajax. If you are on page A and the current request is an ajax request and it returns to the same page and the view is the same that the one that has been restored, the key or the token sent does not need to change, what changes is the internal state of the view. From the client side the page is the same. We can take advantage of this fact and just update the state stored in SerializedViewCollection for the view. The challenge here is detect when this strategy is applicable. For example, what happen if there is an ajax redirect? It looks is a good idea for implement in 2.2, because it avoids to store unnecessary information into session and optimize the use of each view slot. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3752) Flash.setKeepMessages(true) does not work with immediate-Commandbutton
[ https://issues.apache.org/jira/browse/MYFACES-3752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798663#comment-13798663 ] Leonardo Uribe commented on MYFACES-3752: - This issue is a duplicate of MYFACES-3606. > Flash.setKeepMessages(true) does not work with immediate-Commandbutton > -- > > Key: MYFACES-3752 > URL: https://issues.apache.org/jira/browse/MYFACES-3752 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.1.12 > Environment: Java 7.0_02, Tomcat 7.0.32 >Reporter: Martin Maier-Moessner > Attachments: jsfTest.zip > > > If you set Flash.setKeepMessages(true) in an action of an > immediate-true-button, the messages do not survive the Request-Redirect-Post > cycle. If the button is set to immediate="false", setKeepMessages works as > advertised. > I will attach a simple test case that shows this problem. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3736) Occasional ResourceHandlerImpl Error trying to load resource jsf.js with library javax.faces
[ https://issues.apache.org/jira/browse/MYFACES-3736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798605#comment-13798605 ] Leonardo Uribe commented on MYFACES-3736: - I have updated the code to include the exception in the log message. The stack trace shows it is something that happens in the container, not in MyFaces. Anyway I'll keep this issue open in case something arise > Occasional ResourceHandlerImpl Error trying to load resource jsf.js with > library javax.faces > > > Key: MYFACES-3736 > URL: https://issues.apache.org/jira/browse/MYFACES-3736 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.1.10 > Environment: Windows Server 2008 R2 > Java 1.7.0_07 > Apache Tomcat 7.0.39 >Reporter: Moshe Elisha > > From time to time I encountered the following error: > ERROR http-apr-80-exec-2 ResourceHandlerImpl:425: Error trying to load > resource jsf.js with library javax.faces :null > That is all I have. I can't tell what the exact request details or what is > the IOException. > Can you please also make it possible to log the IOException stacktrace? > Thanks. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3728) "javax.faces.partial.execute=@none" still process "javax.faces.source" component
[ https://issues.apache.org/jira/browse/MYFACES-3728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798398#comment-13798398 ] Leonardo Uribe commented on MYFACES-3728: - Checking the code and the log it seems there is a code in PartialViewContextImpl.getExecuteIds() that includes the component associated with javax.faces.source even if @none is used. It has this description (See MYFACES-2458): // The "javax.faces.source" parameter needs to be added to the list of // execute ids if missing (otherwise, we'd never execute an action associated // with, e.g., a button). One use case is this: "javax.faces.partial.execute=@none" still process "javax.faces.source" > component > > > Key: MYFACES-3728 > URL: https://issues.apache.org/jira/browse/MYFACES-3728 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.1.10 >Reporter: Thomas Andraschko > Fix For: 2.1.13 > > > i found a weird issue that if i use p:ajax on inputText with process="@none", > the InputTextRenderer#decode method will be still invoked. > This works fine with f:ajax in myfaces and mojarra. > p:ajax only works expected on mojarra. > The only difference i found is, that p:ajax sends the > "javax.faces.partial.execute" param and f:ajax not. > Here is a list with the post params (without my inputs): > PrimeFaces: > javax.faces.ViewState=N%2F6uUZMB9%2BPXSBTJVus5p6rncWDWwUAgQ9UIOweKuerVM0Z7 > javax.faces.partial.ajax=true > javax.faces.source=xxx > javax.faces.partial.execute=%40none > javax.faces.partial.render=%40none > javax.faces.behavior.event=change > javax.faces.partial.event=change > form_SUBMIT=1 > MyFaces: > javax.faces.ViewState=EHCQlskNw%2BLXSBTJVus5pyzjdxWpT%2B72t7rvnK11Nffi10%2Bl > javax.faces.partial.ajax=true > javax.faces.source=xxx > javax.faces.behavior.event=change > javax.faces.partial.event=change > javax.faces.windowId=2cc > form_SUBMIT=1 > form=form -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (MYFACES-3749) columnClasses not working correctly in DataTable Component
[
https://issues.apache.org/jira/browse/MYFACES-3749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved MYFACES-3749.
-
Resolution: Fixed
I have committed a modified version of the patch, just add a protected method
to get the right column count that represents each component, to be able to
modify the code correctly in Tomahawk. I also created TOMAHAWK-1668 to fix this
stuff there.
Thanks to Paul Nicolucci for provide this patch.
> columnClasses not working correctly in DataTable Component
> --
>
> Key: MYFACES-3749
> URL: https://issues.apache.org/jira/browse/MYFACES-3749
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.18, 2.1.12
>Reporter: Paul Nicolucci
>Assignee: Leonardo Uribe
> Fix For: 2.0.19, 2.1.13
>
> Attachments: MyFaces-3749.patch, MyFaces-3749-Patch2.patch
>
>
> Sample JSF page:
>
> styleClass="order-table"
> headerClass="order-table-header"
> rowClasses="order-table-odd-row,order-table-even-row"
> columnClasses="col0,col1,col2,col3"
> >
>
>
>
> Column1
> #{o.str1}
>
>
>
> Column2
> #{o.str2}
>
>
>
> Column3
> #{o.str3}
>
>
>
> Column4
> #{o.str4}
>
>
> Sample CSS:
> .order-table{
> border-collapse:collapse;
> }
> .order-table-header{
> text-align:center;
> }
> .order-table-odd-row{
> text-align:center;
> }
> .order-table-even-row{
> text-align:center;
> }
> .col0{
> text-align:center;
> }
> .col1{
> text-align:center;
> }
> .col2{
> text-align:center;
> }
> .col3{
> text-align:center;
> }
> Problem description:
> The rendered output of one of the rows of the above page is the following:
>
> test1
>
> test2
>
> test3
>
> test4
>
> As you can see the last column has no definition of a columnClass ( class=""
> ). The same page works if we remove the definition from within
> the
> . If the f:param tag is removed then I see that all of the
> columns have a defined class as expected ( the number of columns is less than
> or equal to the
> defined columnClasses so each of the columns should have a class defined.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (TOMAHAWK-1668) Update code after fix for MYFACES-3749
Leonardo Uribe created TOMAHAWK-1668: Summary: Update code after fix for MYFACES-3749 Key: TOMAHAWK-1668 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1668 Project: MyFaces Tomahawk Issue Type: Task Components: Extended Datatable Reporter: Leonardo Uribe Assignee: Leonardo Uribe The fix that will be done in MYFACES-3749 requires to update HtmlTableRenderer for tomahawk if it includes code from version 2.0.19 and 2.1.13 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (MYFACES-3719) Executing action of a disabled Button
[ https://issues.apache.org/jira/browse/MYFACES-3719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3719. - Resolution: Fixed Fix Version/s: 2.1.13 2.0.19 Assignee: Leonardo Uribe I agree it is absurd to allow the event on server side. Disabled should means disabled in both sides. > Executing action of a disabled Button > - > > Key: MYFACES-3719 > URL: https://issues.apache.org/jira/browse/MYFACES-3719 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.1.11 >Reporter: dennis hoersch >Assignee: Leonardo Uribe > Fix For: 2.0.19, 2.1.13 > > > I have a commandButton with a specific action which is disabled. The button > is rendered with a disabled attribute and gets a bit different onclick script. > Problem is, when the user removes the disabled and onclick attributes, with > for example Firebug, it is possible to click the button. And JSF does not > prevent the action from being executed. > I expected that the execution is prevented also on server-side. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3791) [perf] reuse _SelectItemsIterator in UISelectOne.validateValue
[ https://issues.apache.org/jira/browse/MYFACES-3791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798197#comment-13798197 ] Leonardo Uribe commented on MYFACES-3791: - It seems in MYFACES-3710 we did something different to reuse _SelectItemsIterator, just creating a simple array that hold the values. 1) I think it could happen in UISelectMany. 2) There is a hard copy so any changes in _SelectItemsIterator should be done in shared SelectItemsIterator I think the solution applied in MYFACES-3710 is better, so I'll close this one as duplicate. Thanks anyway for the patch. > [perf] reuse _SelectItemsIterator in UISelectOne.validateValue > -- > > Key: MYFACES-3791 > URL: https://issues.apache.org/jira/browse/MYFACES-3791 > Project: MyFaces Core > Issue Type: Improvement > Environment: myfaces core trunk >Reporter: Martin Kočí >Priority: Minor > Attachments: MYFACES-3791-v1.patch > > > Current implementation of UISelectOne.validateValue creates (when > component.requred = true) two instances of _SelectItemsIterator, iterates 2x > and evaluates ValueExpression for SelectItem(s) 2x. > We can create one instance of SelectItemsIterator and store the > noSelectionOption direct in the _SelectItemsIterator instance and reuse in > noSelectionOption-block. > Similar issue MYFACES-3710. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3402) Partial Response Writer always returns an ignoring the response encoding
[ https://issues.apache.org/jira/browse/MYFACES-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798173#comment-13798173 ] Leonardo Uribe commented on MYFACES-3402: - This issue was clarified and fixed in 2.2.x branch. My personal opinion is it is better to let things as is in 2.1.x. > Partial Response Writer always returns an encoding='utf-8'?> ignoring the response encoding > --- > > Key: MYFACES-3402 > URL: https://issues.apache.org/jira/browse/MYFACES-3402 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.10, 2.1.4 >Reporter: Werner Punz >Assignee: Leonardo Uribe > Attachments: JIRA-MYFACES-3402.patch > > > While I was testing different ajax encodings I discovered that the Partial > Response writer always returns the header listed on the headline of this > issue. It ignores simply the original encoding. > A blackbox test against Mojarra showed in that exact case the proper encoding > not UTF-8 static. > I guess the fix simply should be to make this part of the partial response > writer more dynamic and to fetch > the encoding in from the request header. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MYFACES-3506) Improve exception handling for "duplicate id "id" found"
[ https://issues.apache.org/jira/browse/MYFACES-3506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-3506: Resolution: Fixed Fix Version/s: 2.1.13 Status: Resolved (was: Patch Available) Thanks to Martin Koci for provide this patch > Improve exception handling for "duplicate id "id" found" > > > Key: MYFACES-3506 > URL: https://issues.apache.org/jira/browse/MYFACES-3506 > Project: MyFaces Core > Issue Type: Sub-task > Components: General >Reporter: Martin Kočí >Assignee: Martin Kočí >Priority: Trivial > Fix For: 2.1.13 > > Attachments: MYFACES-3506.patch > > > Myfaces generate a message "component with duplicate id "id" found." > currently completely without information where is the first, or the second > component with duplicate id. > In big view with many lines and naming containers or with multilevel > templating is very hard to solve this problem. > Provide information about: > 1) first component > 2) second component with duplicate id > 3) lines/columns in xhtml -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3587) Not existing viewId will not be handled
[ https://issues.apache.org/jira/browse/MYFACES-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798007#comment-13798007 ] Leonardo Uribe commented on MYFACES-3587: - Added web config param org.apache.myfaces.STRICT_JSF_2_VIEW_NOT_FOUND and fixed case when org.apache.myfaces.SUPPORT_JSP_AND_FACES_EL=false (catch filenotfoundexception and throw 404 response, and if vdl is not found throw 404 response too) > Not existing viewId will not be handled > --- > > Key: MYFACES-3587 > URL: https://issues.apache.org/jira/browse/MYFACES-3587 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 2.1.8 > Environment: Jetty/Tomcat, JUEL, CODI, ExtVal >Reporter: Thomas Andraschko >Assignee: Leonardo Uribe > Fix For: 2.1.13 > > > If i call a page, which does not exist, following exceptions occurs: Cannot > reset buffer after response has been committed. > After digging deeper into this problem, i found out that > getViewHandlerSupport()#calculateViewId returns null and the > JspViewDeclarationLanguageStrategy will be used -> > Cannot reset buffer after response has been committed. > occurs. > I added a null check for the logicalViewId in RestoreViewExecutor#execute to > call HttpServletResponse#sendError. > It does not work as expected because it just renders the errorPage and no > redirect will be done. > Why there is not such null check? > Is it possible to add this check and redirect to the web.xml defined 404 or > common error page? Or should it use the ErrorHandler? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (MYFACES-3587) Not existing viewId will not be handled
[ https://issues.apache.org/jira/browse/MYFACES-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3587. - Resolution: Fixed Fix Version/s: 2.1.13 > Not existing viewId will not be handled > --- > > Key: MYFACES-3587 > URL: https://issues.apache.org/jira/browse/MYFACES-3587 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 2.1.8 > Environment: Jetty/Tomcat, JUEL, CODI, ExtVal >Reporter: Thomas Andraschko >Assignee: Leonardo Uribe > Fix For: 2.1.13 > > > If i call a page, which does not exist, following exceptions occurs: Cannot > reset buffer after response has been committed. > After digging deeper into this problem, i found out that > getViewHandlerSupport()#calculateViewId returns null and the > JspViewDeclarationLanguageStrategy will be used -> > Cannot reset buffer after response has been committed. > occurs. > I added a null check for the logicalViewId in RestoreViewExecutor#execute to > call HttpServletResponse#sendError. > It does not work as expected because it just renders the errorPage and no > redirect will be done. > Why there is not such null check? > Is it possible to add this check and redirect to the web.xml defined 404 or > common error page? Or should it use the ErrorHandler? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (MYFACES-3743) ... has been renamed to in navigation case
[ https://issues.apache.org/jira/browse/MYFACES-3743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3743. - Resolution: Fixed Fix Version/s: 2.1.13 2.0.19 > ... has been renamed to in > navigation case > > > Key: MYFACES-3743 > URL: https://issues.apache.org/jira/browse/MYFACES-3743 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314, JSR-344 >Affects Versions: 2.0.18, 2.1.12 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.0.19, 2.1.13 > > > See: > https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-698 > still works so the only change we need to do is add > the proper rules into the parser. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3790) DISABLE_BEAN_VALIDATOR vs. DISABLE_DEFAULT_BEAN_VALIDATOR
[
https://issues.apache.org/jira/browse/MYFACES-3790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797175#comment-13797175
]
Leonardo Uribe commented on MYFACES-3790:
-
It seems to be a bug in the spec, so I filled:
https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1231
I think it is not necessary to implement the other name, because both MyFaces
and Mojarra uses javax.faces.validator.DISABLE_DEFAULT_BEAN_VALIDATOR
> DISABLE_BEAN_VALIDATOR vs. DISABLE_DEFAULT_BEAN_VALIDATOR
> --
>
> Key: MYFACES-3790
> URL: https://issues.apache.org/jira/browse/MYFACES-3790
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-344
>Affects Versions: 2.2.0
>Reporter: Martin Kočí
>Priority: Minor
>
> During the configuring of a new project I found these two params in JSF spec
> 2.2:
> 1)
> javax.faces.validator.DISABLE_DEFAULT_BEAN_VALIDATOR
> If this param is set, and calling toLowerCase().equals("true") on a String
> representation of its value returns true, the runtime must not automatically
> add the validator with validator-id equal to the value of the symbolic
> constant javax.faces.validator.VALIDATOR_ID to the list of default
> validators. Setting this parameter to true will have the effect of disabling
> the automatic installation of Bean Validation to every input component in
> every view in the application, though manual installation is still possible.
> 2)
> javax.faces.validator.DISABLE_BEAN_VALIDATOR
> In environments that include Bean Validation, the following additional
> actions must be taken at startup time. If the
> javax.faces.validator.DISABLE_BEAN_VALIDATOR exists and its
> value is true, the following step must be skipped:
> The runtime must guarantee that the validator id javax.faces.Bean is included
> in the result from a call to
> Application.getDefaultValidatorInfo() (see Section 7.1.12.1 “Default
> Validator Ids”), regardless of any
> configuration found in the application configuration resources or via the
> @FacesValidator annotation.
> I don't see a difference really. I guess, this is a error in the spec.
> But I didn't found the DISABLE_BEAN_VALIDATOR in Myfaces source code - should
> we implement it nevertheless ?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (MYFACES-3800) HtmlLinkRendererBase encodes url using encodeResourceURL instead encodeActionURL
[ https://issues.apache.org/jira/browse/MYFACES-3800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797157#comment-13797157 ] Leonardo Uribe commented on MYFACES-3800: - That part is dictated by JSF spec, and it is not possible to change it. I think there is no need to call encodeActionURL from that point (or no strong reason has been given to do such change) I'll close this issue as invalid. > HtmlLinkRendererBase encodes url using encodeResourceURL instead > encodeActionURL > > > Key: MYFACES-3800 > URL: https://issues.apache.org/jira/browse/MYFACES-3800 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 2.1.12 >Reporter: Jan Dosoudil >Priority: Minor > > Link to resource is IMHO less frequent then to an action. (I don't think > there is frequent purpose for resource linking) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (MYFACES-3744) Vertical tab character (\u000B) destroys AJAX-response
[ https://issues.apache.org/jira/browse/MYFACES-3744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3744. - Resolution: Fixed Fix Version/s: 2.1.13 2.0.19 Assignee: Leonardo Uribe > Vertical tab character (\u000B) destroys AJAX-response > -- > > Key: MYFACES-3744 > URL: https://issues.apache.org/jira/browse/MYFACES-3744 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 2.1.12 > Environment: jdk1.7.0_21; apache-tomcat-7.0.42; Firefox; >Reporter: Alexey Shakov >Assignee: Leonardo Uribe > Fix For: 2.0.19, 2.1.13 > > Attachments: messages.properties, vtab.xhtml > > > If AJAX response contains \u000B-character (i.e., as value of outputText), > then 'not well formed xml'-error is displayed in js-console. Request is not > processed properly. > Works with Mojarra 2.1.24 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3744) Vertical tab character (\u000B) destroys AJAX-response
[ https://issues.apache.org/jira/browse/MYFACES-3744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796961#comment-13796961 ] Leonardo Uribe commented on MYFACES-3744: - According to this link from W3C: http://www.w3.org/International/questions/qa-controls control characters should be ignored. Also this link: http://www.w3.org/MarkUp/html3/specialchars.html Says the only valid characters are HT, LF, CR (0x09, 0x0A, 0x0D) and: "... In HTML, there are only three control characters which are used. The remaining 55 control characters are shunned and should not appear in an HTML document. ..." HtmlResponseWriterImpl should honor that in those places where html escaping is done, like in writeText or writeAttribute. > Vertical tab character (\u000B) destroys AJAX-response > -- > > Key: MYFACES-3744 > URL: https://issues.apache.org/jira/browse/MYFACES-3744 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 2.1.12 > Environment: jdk1.7.0_21; apache-tomcat-7.0.42; Firefox; >Reporter: Alexey Shakov > Attachments: messages.properties, vtab.xhtml > > > If AJAX response contains \u000B-character (i.e., as value of outputText), > then 'not well formed xml'-error is displayed in js-console. Request is not > processed properly. > Works with Mojarra 2.1.24 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (MYFACES-3792) ConcurrentModificationException in org.apache.myfaces.config.ManagedBeanDestroyer - when using TomcatAnnotationLifecycleProvider
[ https://issues.apache.org/jira/browse/MYFACES-3792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3792. - Resolution: Fixed Fix Version/s: 2.1.13 2.0.19 Assignee: Leonardo Uribe The stack trace shows there is a modification over the view map while the beans are destroyed. You should have some code in view scope bean under @PreDestroy. But anyway, we can avoid that problem just creating a copy of the keys before iterate. > ConcurrentModificationException in > org.apache.myfaces.config.ManagedBeanDestroyer - when using > TomcatAnnotationLifecycleProvider > > > Key: MYFACES-3792 > URL: https://issues.apache.org/jira/browse/MYFACES-3792 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.1.11 > Environment: Linux >Reporter: Tomasz Szlek >Assignee: Leonardo Uribe > Fix For: 2.0.19, 2.1.13 > > > Sometimes exception below occurs. It looks like map in ManagedBeanDestroyer > is not a concurrence map and this could be an issue. > lifecycle provider: > org.apache.myfaces.config.annotation.TomcatAnnotationLifecycleProvider > stack trace: > testjavax.servlet.ServletException > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:229) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve. > java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve. > java:191) > at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:563) > > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:1 > 27) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:1 > 02) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.ja > va:109) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293 > ) > at > org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:448) > at > org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpAprProtocol.java:399) > > at > org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1675) > at java.lang.Thread.run(Thread.java:662) > Caused by: java.util.ConcurrentModificationException > at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793) > at java.util.HashMap$KeyIterator.next(HashMap.java:828) > at > org.apache.myfaces.config.ManagedBeanDestroyer.processEvent(ManagedBeanDestroyer.java:100) > > at > javax.faces.event.SystemEvent.processListener(SystemEvent.java:43) > at > org.apache.myfaces.application.ApplicationImpl._traverseListenerList(ApplicationImpl.java:2410) > > at > org.apache.myfaces.application.ApplicationImpl.access$000(ApplicationImpl. > java:119) > at > org.apache.myfaces.application.ApplicationImpl$SystemListenerEntry.publish(ApplicationImpl.java:2601) > > at > org.apache.myfaces.application.ApplicationImpl.publishEvent(ApplicationImp > l.java:592) > at > org.apache.myfaces.application.ApplicationImpl.publishEvent(ApplicationImp > l.java:607) > at > javax.faces.component.UIViewRoot$ViewScope.clear(UIViewRoot.java:1596) > at > org.apache.myfaces.application.NavigationHandlerImpl.handleNavigation(NavigationHandlerImpl.java:133) > > at > org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:89) > > at javax.faces.component.UICommand.broadcast(UICommand.java:120) > at > javax.faces.component.UIViewRoot._broadcastAll(UIViewRoot.java:1028) > at > javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:286) > at javax.faces.component.UIViewRoot._process(UIViewRoot.java:1375) > at > javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:752) > at > org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:38) > > at > org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java > :170) > at > org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117) > at javax.face
[jira] [Resolved] (MYFACES-3795) ErrorPageWriter cause memory leak in visitedFacetCount map
[ https://issues.apache.org/jira/browse/MYFACES-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3795. - Resolution: Fixed Fix Version/s: 2.1.13 2.0.19 Assignee: Leonardo Uribe Thanks to Tomasz Szlek for investigate this issue. > ErrorPageWriter cause memory leak in visitedFacetCount map > -- > > Key: MYFACES-3795 > URL: https://issues.apache.org/jira/browse/MYFACES-3795 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.1.11 > Environment: Linux >Reporter: Tomasz Szlek >Assignee: Leonardo Uribe > Fix For: 2.0.19, 2.1.13 > > > We have noticed that there is a memory leak in class > org.apache.myfaces.renderkit.ErrorPageWriter, map: visitedFacetCount. > This memory leak occurs when is used. > Description of problem: > Ui debug component tree page use visitedFacetCount as a temporary source of > UI components in order to generate html page based on such components. > This generator use visitor : ExtendedComponentTreeVisitCallback class. > Inside method visit we have following lines : > 972: _incrementVisitedFacetCount(parent); //put compnent into > visitedFacetCount map > ... > 1131: _removeVisitedFacetCount(parent); // remove visited component from > visitedFacetCount map. > Unfortunatelly visited component is removed from visitedFacetCount map only > if there are no children for component. > Thus it looks like components are never removed properly from > visitedFacetCount. > Possible solution: > Parrent componet should be removed from visitedFacetCount when it back from > recursion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3795) ErrorPageWriter cause memory leak in visitedFacetCount map
[ https://issues.apache.org/jira/browse/MYFACES-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795780#comment-13795780 ] Leonardo Uribe commented on MYFACES-3795: - It seems the bug was introduced in MYFACES-2777. It is clear that map should be in FacesContext attribute map. I'll fix that. > ErrorPageWriter cause memory leak in visitedFacetCount map > -- > > Key: MYFACES-3795 > URL: https://issues.apache.org/jira/browse/MYFACES-3795 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.1.11 > Environment: Linux >Reporter: Tomasz Szlek > > We have noticed that there is a memory leak in class > org.apache.myfaces.renderkit.ErrorPageWriter, map: visitedFacetCount. > This memory leak occurs when is used. > Description of problem: > Ui debug component tree page use visitedFacetCount as a temporary source of > UI components in order to generate html page based on such components. > This generator use visitor : ExtendedComponentTreeVisitCallback class. > Inside method visit we have following lines : > 972: _incrementVisitedFacetCount(parent); //put compnent into > visitedFacetCount map > ... > 1131: _removeVisitedFacetCount(parent); // remove visited component from > visitedFacetCount map. > Unfortunatelly visited component is removed from visitedFacetCount map only > if there are no children for component. > Thus it looks like components are never removed properly from > visitedFacetCount. > Possible solution: > Parrent componet should be removed from visitedFacetCount when it back from > recursion. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MYFACES-3788) Improve log message in RendererUtils.getClientId with component location
[ https://issues.apache.org/jira/browse/MYFACES-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-3788: Resolution: Fixed Fix Version/s: 2.2.0 Assignee: Martin Kočí Status: Resolved (was: Patch Available) Thanks to Martin Koci for provide this patch > Improve log message in RendererUtils.getClientId with component location > > > Key: MYFACES-3788 > URL: https://issues.apache.org/jira/browse/MYFACES-3788 > Project: MyFaces Core > Issue Type: Sub-task > Components: General >Affects Versions: 2.2.0 > Environment: myfaces core trunk >Reporter: Martin Kočí >Assignee: Martin Kočí >Priority: Trivial > Fix For: 2.2.0 > > Attachments: MYFACES-3788.patch > > > for example: > > displays: > "Unable to find component 'nonExistentId' (calling findComponent on component > 'j_id_61:j_id_6h:j_id_6t')." > 1) show component location in development stage > 2) take into consideration project stage for log-level -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MYFACES-3578) NumberConverter: implement workaround for http://bugs.sun.com/view_bug.do?bug_id=4510618
[
https://issues.apache.org/jira/browse/MYFACES-3578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe updated MYFACES-3578:
Resolution: Fixed
Fix Version/s: 2.1.13
2.0.19
1.2.13
Status: Resolved (was: Patch Available)
Thanks to Martin Koci for provide this patch.
> NumberConverter: implement workaround for
> http://bugs.sun.com/view_bug.do?bug_id=4510618
>
>
> Key: MYFACES-3578
> URL: https://issues.apache.org/jira/browse/MYFACES-3578
> Project: MyFaces Core
> Issue Type: Bug
> Environment: myfaces trunk
>Reporter: Martin Kočí
>Assignee: Martin Kočí
>Priority: Minor
> Fix For: 1.2.13, 2.0.19, 2.1.13
>
> Attachments: MYFACES-3578.patch
>
>
> http://bugs.sun.com/view_bug.do?bug_id=4510618
> mojarra already implements a workaround
> (http://java.net/jira/browse/JAVASERVERFACES-755)
> Myfaces NumberConverter partially implements it already, but:
> value = value.replace('\u00a0', ' ');
> part is missing.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (MYFACES-3787) Make WRAP_SCRIPT_CONTENT_WITH_XML_COMMENT_TAG=false default
[ https://issues.apache.org/jira/browse/MYFACES-3787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-3787: Resolution: Fixed Fix Version/s: 2.2.0 Assignee: Leonardo Uribe Status: Resolved (was: Patch Available) Thanks to Martin Koci for provide this patch > Make WRAP_SCRIPT_CONTENT_WITH_XML_COMMENT_TAG=false default > --- > > Key: MYFACES-3787 > URL: https://issues.apache.org/jira/browse/MYFACES-3787 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.2.0 > Environment: myfaces core trunk >Reporter: Martin Kočí >Assignee: Leonardo Uribe >Priority: Trivial > Fix For: 2.2.0 > > Attachments: MYFACES-3787.patch > > > As discussed [1], now with 2.2 release is the time to switch the default > behaviour. Myfaces render all scripts > with > and that is in 2013 a little not topical. > [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg56743.html -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MYFACES-3723) JSF 2.2: Support parameter javax.faces.SERIALIZE_SERVER_STATE
[ https://issues.apache.org/jira/browse/MYFACES-3723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-3723: Resolution: Fixed Fix Version/s: 2.2.0 Assignee: Leonardo Uribe Status: Resolved (was: Patch Available) It seems the change was applied at some point. I added the documentation and deprecated the old param. Thanks to Michael Kurz for provide this patch. > JSF 2.2: Support parameter javax.faces.SERIALIZE_SERVER_STATE > - > > Key: MYFACES-3723 > URL: https://issues.apache.org/jira/browse/MYFACES-3723 > Project: MyFaces Core > Issue Type: New Feature > Components: JSR-344 >Affects Versions: 2.2.0 >Reporter: Michael Kurz >Assignee: Leonardo Uribe > Fix For: 2.2.0 > > Attachments: MYFACES-3723.patch > > > The JSF 2.2 spec defines a new context parameter > javax.faces.SERIALIZE_SERVER_STATE. This parameter controls state > serialization for server side state saving. As far as I see it, it should be > the same as the MyFaces parameter > org.apache.myfaces.SERIALIZE_STATE_IN_SESSION. > Maybe org.apache.myfaces.SERIALIZE_STATE_IN_SESSION can even be deprecated > for 2.2? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MYFACES-3683) Implement AjaxBehavior resetValues and delay
[ https://issues.apache.org/jira/browse/MYFACES-3683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-3683: Resolution: Fixed Fix Version/s: 2.2.0 Assignee: Leonardo Uribe Status: Resolved (was: Patch Available) > Implement AjaxBehavior resetValues and delay > > > Key: MYFACES-3683 > URL: https://issues.apache.org/jira/browse/MYFACES-3683 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0 > > Attachments: MYFACES-3683-delay1.patch, MYFACES-3683-delay2.patch, > MYFACES-3683-delay3.patch, resetValuesNew.patch, resetValues.patch, > UIInput.patch > > > Implement AjaxBehavior resetValues and delay as described in the spec. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MYFACES-3796) 'style' attribute updates do not show any visible changes in IE 7/8
[ https://issues.apache.org/jira/browse/MYFACES-3796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-3796: Resolution: Fixed Fix Version/s: 2.1.13 2.0.19 Assignee: Leonardo Uribe Status: Resolved (was: Patch Available) I asked Werner about this patch and it is ok. Thanks to Mircea Toma for provide this patch. > 'style' attribute updates do not show any visible changes in IE 7/8 > --- > > Key: MYFACES-3796 > URL: https://issues.apache.org/jira/browse/MYFACES-3796 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 2.1.12 > Environment: Internet Explorer 7 or 8 >Reporter: Mircea Toma >Assignee: Leonardo Uribe > Fix For: 2.0.19, 2.1.13 > > Attachments: MYFACES-3796.patch, test.war > > > The partial updates for the 'style' attribute do not work as expected in IE > 7/8. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (MYFACESTEST-63) Add JSF 2.2 branch for MyFaces Test
[ https://issues.apache.org/jira/browse/MYFACESTEST-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACESTEST-63. --- Resolution: Fixed Fix Version/s: 1.0.5-SNAPSHOT > Add JSF 2.2 branch for MyFaces Test > --- > > Key: MYFACESTEST-63 > URL: https://issues.apache.org/jira/browse/MYFACESTEST-63 > Project: MyFaces Test > Issue Type: Task >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 1.0.5-SNAPSHOT > > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MYFACESTEST-63) Add JSF 2.2 branch for MyFaces Test
Leonardo Uribe created MYFACESTEST-63: - Summary: Add JSF 2.2 branch for MyFaces Test Key: MYFACESTEST-63 URL: https://issues.apache.org/jira/browse/MYFACESTEST-63 Project: MyFaces Test Issue Type: Task Reporter: Leonardo Uribe Assignee: Leonardo Uribe -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[ https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795346#comment-13795346 ] Leonardo Uribe commented on MYFACES-3786: - If you are building an spi interface you want a clean and stable interface, that's for sure. Do we have choice here? Unfortunately no, that's the point. So, after thinking about this, I have realized that we can't go too far in the future, thinking how things should be done and instead I'm trying to choose a proposal that can be as simple as possible, without enter in too many details that later we probably will change in future versions of JSF. In that way we minimize the impact of a possible change. That's the reason why I prefer #1 instead of #5, because #1 can become more flexible in its implementation. Agreed, please commit #1. > Web Container injection support should be provided for additional lifecycle > artifacts (not just managed beans) > -- > > Key: MYFACES-3786 > URL: https://issues.apache.org/jira/browse/MYFACES-3786 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0 > > Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, > cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, > cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, > cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, > MYFACES-3786-2.patch, MYFACES-3786_bean-entry_draft_01.patch, > MYFACES-3786_internal_bean-entry_draft.patch > > > This issue is all about how to inject beans into jsf artifacts. > See JSF 2.2 section 5.4.1 > The problem here is in some point we need to give the control to the > underlying environment to inject beans into the artifacts, but we don't know > much about how to properly do it, so we need to try with examples. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[ https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795319#comment-13795319 ] Leonardo Uribe commented on MYFACES-3786: - First, we only need to support the scopes JSF artifacts require. For now it is only application scope, because all JSF injected artifacts are application scope, and that will not change until 2.3. Forget about the problem with n scopes. It is just smoke. #0 +1 because we can extend it in the future if we require to do so. #1 +0.5 #2/#3 +1 because we can extend it in the future if we require to do so. #4 -1 #5 -1 Conclusion: #0 (keep things as is) > Web Container injection support should be provided for additional lifecycle > artifacts (not just managed beans) > -- > > Key: MYFACES-3786 > URL: https://issues.apache.org/jira/browse/MYFACES-3786 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0 > > Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, > cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, > cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, > cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, > MYFACES-3786-2.patch, MYFACES-3786_bean-entry_draft_01.patch, > MYFACES-3786_internal_bean-entry_draft.patch > > > This issue is all about how to inject beans into jsf artifacts. > See JSF 2.2 section 5.4.1 > The problem here is in some point we need to give the control to the > underlying environment to inject beans into the artifacts, but we don't know > much about how to properly do it, so we need to try with examples. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[ https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795293#comment-13795293 ] Leonardo Uribe commented on MYFACES-3786: - All those issues are problem of CDI, not a problem of JSF. I don't see why an unique id is required or why a "duplicate scope handling" is a problem. Anyway, if things works it doesn't matter. But if with #1 we can avoid that let's do #1. > Web Container injection support should be provided for additional lifecycle > artifacts (not just managed beans) > -- > > Key: MYFACES-3786 > URL: https://issues.apache.org/jira/browse/MYFACES-3786 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0 > > Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, > cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, > cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, > cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, > MYFACES-3786-2.patch, MYFACES-3786_bean-entry_draft_01.patch, > MYFACES-3786_internal_bean-entry_draft.patch > > > This issue is all about how to inject beans into jsf artifacts. > See JSF 2.2 section 5.4.1 > The problem here is in some point we need to give the control to the > underlying environment to inject beans into the artifacts, but we don't know > much about how to properly do it, so we need to try with examples. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[ https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795261#comment-13795261 ] Leonardo Uribe commented on MYFACES-3786: - Note JSF spec doesn't mention CDI as supported technology. That's the point, it is not required, it is optional. Anyway, +1 for a patch implementing #1. > Web Container injection support should be provided for additional lifecycle > artifacts (not just managed beans) > -- > > Key: MYFACES-3786 > URL: https://issues.apache.org/jira/browse/MYFACES-3786 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0 > > Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, > cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, > cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, > cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, > MYFACES-3786-2.patch, MYFACES-3786_bean-entry_draft_01.patch > > > This issue is all about how to inject beans into jsf artifacts. > See JSF 2.2 section 5.4.1 > The problem here is in some point we need to give the control to the > underlying environment to inject beans into the artifacts, but we don't know > much about how to properly do it, so we need to try with examples. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[ https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795277#comment-13795277 ] Leonardo Uribe commented on MYFACES-3786: - Which supports my case in favor of #3 (use String) if the rules comes from CDI, and it can be solved inside InjectionProvider it should be solved there. As simple as that. > Web Container injection support should be provided for additional lifecycle > artifacts (not just managed beans) > -- > > Key: MYFACES-3786 > URL: https://issues.apache.org/jira/browse/MYFACES-3786 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0 > > Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, > cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, > cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, > cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, > MYFACES-3786-2.patch, MYFACES-3786_bean-entry_draft_01.patch > > > This issue is all about how to inject beans into jsf artifacts. > See JSF 2.2 section 5.4.1 > The problem here is in some point we need to give the control to the > underlying environment to inject beans into the artifacts, but we don't know > much about how to properly do it, so we need to try with examples. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[ https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795241#comment-13795241 ] Leonardo Uribe commented on MYFACES-3786: - "... if you bypass the cdi context-management, you have to do the equivalent on your own. ..." that depends on how far you want to go in the integration. The minimum is go as far as the reference implementation (Mojarra) goes. Going further is insist in solve a problem that clearly is out of the scope of JSF 2.2, and no matter how hard we try, it will be always a partial solution. Does JSF need to know what's inside the metadata? no. The only thing that JSF needs to know is that this piece of information needs to be stored somewhere. In #5, it introduce some extra objects that are only used in the context of the InjectionProvider, which means JSF doesn't care about that. #1 avoid extra instantiation. > Web Container injection support should be provided for additional lifecycle > artifacts (not just managed beans) > -- > > Key: MYFACES-3786 > URL: https://issues.apache.org/jira/browse/MYFACES-3786 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0 > > Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, > cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, > cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, > cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, > MYFACES-3786-2.patch, MYFACES-3786_bean-entry_draft_01.patch > > > This issue is all about how to inject beans into jsf artifacts. > See JSF 2.2 section 5.4.1 > The problem here is in some point we need to give the control to the > underlying environment to inject beans into the artifacts, but we don't know > much about how to properly do it, so we need to try with examples. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[ https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795191#comment-13795191 ] Leonardo Uribe commented on MYFACES-3786: - #5 is way more complex. Now we need to create one instance of some class and a full hashmap to inject one object. Doesn't that sound like JSF doing things that CDI should do? In the integration code with a web server, doesn't that sound just silly? I think it is inconvenient. The reason is no matter what we put on InjectionProvider, the most probable outcome is that we need to deprecate that in the future in favor to a better CDI integration. Precisely what I want to avoid is end with a code in JSF that do things that other library should do. "... trying something only makes sense if you aren't sure about the result. we know the result already - so trying something with obvious flaws doesn't make a lot of sense. ..." In this case no matter what you put in InjectionProvider, the most probably outcome is things will change. All solutions has flaws, the question is which one is less worse. In my opinion, the less worse is the one who avoid unnecessary complexity and put the code in the right place, so it is #3 (using string for scope). If #4 or #5 are the options, +1 to keep the code the way it is right now. In the future, we can discuss how to deal with this in the context of JSF 2.3, and how to fix this properly. There is no need to waste time in this for now. Now going back to this solution: public Object inject(Object instance) throws InjectionProviderException public void postConstruct(Object instance, Object context) throws InjectionProviderException public void preDestroy(Object instance, Object context) throws InjectionProviderException It starts to looks even better. The inject(...) can return the context, so if you don't have it, just return null, and if you have it, JSF only knows what it needs to know: store the context somewhere to call postConstruct and preDestroy. Simple, less classes, no unnecessary logic, no extra classes, no extra object instantiation. After see the alternatives, I like this solution. > Web Container injection support should be provided for additional lifecycle > artifacts (not just managed beans) > -- > > Key: MYFACES-3786 > URL: https://issues.apache.org/jira/browse/MYFACES-3786 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0 > > Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, > cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, > cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, > cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, > MYFACES-3786-2.patch, MYFACES-3786_bean-entry_draft_01.patch > > > This issue is all about how to inject beans into jsf artifacts. > See JSF 2.2 section 5.4.1 > The problem here is in some point we need to give the control to the > underlying environment to inject beans into the artifacts, but we don't know > much about how to properly do it, so we need to try with examples. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[ https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794804#comment-13794804 ] Leonardo Uribe commented on MYFACES-3786: - Let's try the solution using the String. Just add one param to inject(...) method, and we'll get the biggest gain with the minimum change. Given our options is our best shot. > Web Container injection support should be provided for additional lifecycle > artifacts (not just managed beans) > -- > > Key: MYFACES-3786 > URL: https://issues.apache.org/jira/browse/MYFACES-3786 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0 > > Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, > cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, > cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, > cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, > MYFACES-3786-2.patch > > > This issue is all about how to inject beans into jsf artifacts. > See JSF 2.2 section 5.4.1 > The problem here is in some point we need to give the control to the > underlying environment to inject beans into the artifacts, but we don't know > much about how to properly do it, so we need to try with examples. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[ https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794609#comment-13794609 ] Leonardo Uribe commented on MYFACES-3786: - Let's be clear about this. LifecycleProvider is needed to inject servlet 2.5 annotations into jsf managed beans. How we handle the injection depends of the JSF artifacts that needs to be injected. So, the inclusion of a new logic there depends on the lifespan the JSF artifact that needs to be injected. I think maybe in this point we are thinking too far. We don't really need to take care about that. It is necessary a storage in jsf to store the injected instances via InjectionProvider? Depend of the injected artifact. Since all artifacts are instantiated by JSF, we can just take them from their locations. For example, in FactoryFinder there is already a map holding the factory instances, so why create another storage to get the same?. On the other side, SystemEventListener requires a place to hold those references (RuntimeConfig) because we can access it directly from Application object. How that is implemented is responsibility of JSF, that's it. If there is a need to do an external lookup from CDI perspective it is ok to do so. That's not a big deal. Simplicity, that's the key point. Impose a storage as a map sounds too restrictive and complex for something that can be as simple as just say "inject this JSF artifact that has applicationScope lifetime". If in the future InjectionProvider needs a change it will be for 2.3 or upper versions, it is more, maybe we will not need of it and instead we'll be forced to deprecate it. I'm starting to think the solution right now in trunk is ok, I don't like to hold a map in the provider because it is something inherently "broken by design", that only requires a change in the spec to fail or create a memory leak, but it will work for now. After all, "... the alternatives can become a lot much worse ...". > Web Container injection support should be provided for additional lifecycle > artifacts (not just managed beans) > -- > > Key: MYFACES-3786 > URL: https://issues.apache.org/jira/browse/MYFACES-3786 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0 > > Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, > cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, > cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, > cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, > MYFACES-3786-2.patch > > > This issue is all about how to inject beans into jsf artifacts. > See JSF 2.2 section 5.4.1 > The problem here is in some point we need to give the control to the > underlying environment to inject beans into the artifacts, but we don't know > much about how to properly do it, so we need to try with examples. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[ https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794427#comment-13794427 ] Leonardo Uribe commented on MYFACES-3786: - Use: public void inject(Object instance, String scope) throws InjectionProviderException Shines because it is quite simple to understand. Additionally, the logic behind DependentInstanceStorage falls into CDI domain. It is not something JSF should be aware of. The reason is that object is used only "inside" the InjectionProvider. I think we should aim to make a clear distinction about what JSF should do and what CDI should do. All that logic behind cdi should be kept at cdi level, and do not throw that responsibility to JSF. In this case it is clear that it is only required to have "dependency injection" handled by cdi, because we can't do something better either. Unfortunately that's not optional, the spec forces us to do it in that way. > Web Container injection support should be provided for additional lifecycle > artifacts (not just managed beans) > -- > > Key: MYFACES-3786 > URL: https://issues.apache.org/jira/browse/MYFACES-3786 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0 > > Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, > cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, > cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, > cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, > MYFACES-3786-2.patch > > > This issue is all about how to inject beans into jsf artifacts. > See JSF 2.2 section 5.4.1 > The problem here is in some point we need to give the control to the > underlying environment to inject beans into the artifacts, but we don't know > much about how to properly do it, so we need to try with examples. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[ https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794325#comment-13794325 ] Leonardo Uribe commented on MYFACES-3786: - In this case, since all injected artifacts are managed by JSF, it is defined beforehand the scope of the objects, so there is no need of update more than the necessary between major versions of JSF. For JSF 2.2, injection will be used for JSF artifacts that are application scope. Really say "... all implementations have to support all possible jsf-scopes ..." is not accurate. Instead " ... CDI have to support all possible jsf-scopes ..." because after all things are working the way they are right now. The case we want to solve is the injection of dependant beans, right?. Also, we are providing an InjectionProvider specifically designed for CDI to deal with that logic, so in the long term, we will be able to update the integration code. I think it is important to keep the responsibilities in the right place. Who holds the instances? JSF. Who hold the context of the injected bean? CDI. What happen if there is no context? Things will keep working, because the context is only relevant for the bean container. Yes, it is true dependant beans will not work as expected, but all the rest will do it just fine. In my opinion it is not a disadvantage, it is just something that belongs to the logic of the injection provider and specifically in the context of injection from a bean container, in this case CDI. Really in this issue we have some constraints that limits the options we have at hand. The best is "get married" with CDI and give it the control over JSF artifacts, but we already know that this is not possible o feasible, at least for now. > Web Container injection support should be provided for additional lifecycle > artifacts (not just managed beans) > -- > > Key: MYFACES-3786 > URL: https://issues.apache.org/jira/browse/MYFACES-3786 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0 > > Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, > cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, > cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, > cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, > MYFACES-3786-2.patch > > > This issue is all about how to inject beans into jsf artifacts. > See JSF 2.2 section 5.4.1 > The problem here is in some point we need to give the control to the > underlying environment to inject beans into the artifacts, but we don't know > much about how to properly do it, so we need to try with examples. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[ https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794263#comment-13794263 ] Leonardo Uribe commented on MYFACES-3786: - I would prefer only one abstract method. abstract void inject(Object instance, String scope) and this one void inject(Object instance) with a default implementation that call inject(instance,null). But I like keep things simple and avoid multiple methods in that part to override, so better one abstract method, because after all, this method will be called only by JSF internals. Anyway is the same. Who defines the scope of the injected object in this case? JSF. So as long as the bean container provides the scope we need, everything will work well. Any disadvantage? I don't see anything from JSF perspective. We are providing the necessary information to deal with the injection to the bean container, that's it. It is up to the bean container how to deal with that. Theorically there should be some structure that holds the injected reference to call preDestroy in the right time. But in that sense, it is resposibility of JSF to deal with that logic. If the instance is a Factory, FactoryFinder holds the instances. If is an application scope artifact, the same and so on. There is no need to hold both the creationalContext and the instance on the same place, more if we consider that creationalContext is a implementation detail of CDI. > Web Container injection support should be provided for additional lifecycle > artifacts (not just managed beans) > -- > > Key: MYFACES-3786 > URL: https://issues.apache.org/jira/browse/MYFACES-3786 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0 > > Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, > cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, > cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, > cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, > MYFACES-3786-2.patch > > > This issue is all about how to inject beans into jsf artifacts. > See JSF 2.2 section 5.4.1 > The problem here is in some point we need to give the control to the > underlying environment to inject beans into the artifacts, but we don't know > much about how to properly do it, so we need to try with examples. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[ https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794219#comment-13794219 ] Leonardo Uribe commented on MYFACES-3786: - @Gerhard : I see. We could try pass the information about the scope instead: public void inject(Object instance, String scope) throws InjectionProviderException public void postConstruct(Object instance) throws InjectionProviderException public void preDestroy(Object instance) throws InjectionProviderException And as scopes we have: "applicationScoped", "sessionScoped", "requestScoped", "flowScoped", "viewScoped". With this we provide CDI the necessary information to know where to store the creationalContext for the injected bean, without enter into implementation details over the context. This approach looks better, don't you think so? > Web Container injection support should be provided for additional lifecycle > artifacts (not just managed beans) > -- > > Key: MYFACES-3786 > URL: https://issues.apache.org/jira/browse/MYFACES-3786 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0 > > Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, > cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, > cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, > cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, > MYFACES-3786-2.patch > > > This issue is all about how to inject beans into jsf artifacts. > See JSF 2.2 section 5.4.1 > The problem here is in some point we need to give the control to the > underlying environment to inject beans into the artifacts, but we don't know > much about how to properly do it, so we need to try with examples. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[ https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794127#comment-13794127 ] Leonardo Uribe commented on MYFACES-3786: - @Gerhard unfortunately the change you did will not work, because it assume all injected beans has application lifespan. Theorically that's true for now but will it be in the future? It is more, LifecycleProvider inject all JSF managed beans, so we can't rely on that fact. The problem is if exists a problem with dependant beans with like you said, we'll be forced in the future to change InjectionProvider interface again, and that's something we should avoid. The only thing that will work is pass the creational context after the inject, but without reference the object itself or the implementation. We could change InjectionProvider from this: public void inject(Object instance) throws InjectionProviderException public void postConstruct(Object instance) throws InjectionProviderException public void preDestroy(Object instance) throws InjectionProviderException To this: public Object inject(Object instance) throws InjectionProviderException public void postConstruct(Object instance, Object context) throws InjectionProviderException public void preDestroy(Object instance, Object context) throws InjectionProviderException And delegate the resposibility to hold the context over JSF artifact lifespan to JSF in the places we require to do so. Do you agree with this proposal? @Dora : the final version of the patch was already committed into trunk, including all cases. Again, converter/validator case is handled in MYFACES-3937, which was already committed too as an extension, disabled by default. > Web Container injection support should be provided for additional lifecycle > artifacts (not just managed beans) > -- > > Key: MYFACES-3786 > URL: https://issues.apache.org/jira/browse/MYFACES-3786 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0 > > Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, > cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, > cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, > cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, > MYFACES-3786-2.patch > > > This issue is all about how to inject beans into jsf artifacts. > See JSF 2.2 section 5.4.1 > The problem here is in some point we need to give the control to the > underlying environment to inject beans into the artifacts, but we don't know > much about how to properly do it, so we need to try with examples. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[ https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13793727#comment-13793727 ] Leonardo Uribe commented on MYFACES-3786: - Thanks Gerhard for take a look into this. Thinking more about this, maybe it is a good idea to just give priority to CDI InjectionProvider and fallback to the web server injection and if not found put the dummy one. In other words, if CDI is available use CDI injection provider (is delegation pattern over the injection provider valid to isolate the CDI api? in theory a classnotfoundexception is thrown on the injection factory and by that effect other injection providers are scanned). The big question is if CDI is properly integrated, does the CDI injection handles annotations like @EJB and others that are not part of CDI? In theory and according to InjectionTarget javadoc it should be, but I have not tested it yet. Remember one requeriment we have for this stuff is allow other bean containers like Spring to hook MyFaces 2.2. > Web Container injection support should be provided for additional lifecycle > artifacts (not just managed beans) > -- > > Key: MYFACES-3786 > URL: https://issues.apache.org/jira/browse/MYFACES-3786 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Gerhard Petracek > Fix For: 2.2.0 > > Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, > cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, > cdiphaselistener1.patch, cdiphaselistener2.patch, cdiValidatorSource.zip, > cdiValidator.war, MYFACES-3786-1.patch, MYFACES-3786-2.patch > > > This issue is all about how to inject beans into jsf artifacts. > See JSF 2.2 section 5.4.1 > The problem here is in some point we need to give the control to the > underlying environment to inject beans into the artifacts, but we don't know > much about how to properly do it, so we need to try with examples. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[ https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13793565#comment-13793565 ] Leonardo Uribe commented on MYFACES-3786: - The proposed solution goes as far as the reference implementation (in this case Mojarra) goes, so my interest in this stuff for now (I want to get a beta out as soon as possible, and the solution committed allows that). Maybe you can propose a way to modify InjectionProvider interface without include CDI specific API to do what you want. Remember we have these cases: - Web server not using CDI, but using other annotations or other injection container. - Web server using CDI as a library but not integrated. - Web server integrated with CDI. And the big question is how to fill the gap in all possible cases. Maybe you understand better how CDI works, so from this point it is all yours. > Web Container injection support should be provided for additional lifecycle > artifacts (not just managed beans) > -- > > Key: MYFACES-3786 > URL: https://issues.apache.org/jira/browse/MYFACES-3786 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0 > > Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, > cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, > cdiphaselistener1.patch, cdiphaselistener2.patch, cdiValidatorSource.zip, > cdiValidator.war, MYFACES-3786-1.patch, MYFACES-3786-2.patch > > > This issue is all about how to inject beans into jsf artifacts. > See JSF 2.2 section 5.4.1 > The problem here is in some point we need to give the control to the > underlying environment to inject beans into the artifacts, but we don't know > much about how to properly do it, so we need to try with examples. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13793495#comment-13793495
]
Leonardo Uribe commented on MYFACES-3786:
-
I have found a code in
org.apache.myfaces.spi.impl.AllAnnotationInjectionProvider . It seems this
provider is activated when javax.ejb.EJB is detected and no specific container
provider has been found. It has a // TODO @EJBs on the top. If that so the
code should be trivial, just add something like this:
if (field.isAnnotationPresent(EJB.class))
{
EJB annotation = field.getAnnotation(EJB.class);
lookupFieldResource(context, instance, field,
calculateBeanName(instance.getClass().getName()));
}
Am I right? Maybe this should be fixed for LifecycleProvider too. In that case,
this is a new bug, so I suppose it is better to close this issue again and
raise a new one, because the fix can be done for 2.0.x, 2.1.x and 2.2.x (even
for 1.2.x)
> Web Container injection support should be provided for additional lifecycle
> artifacts (not just managed beans)
> --
>
> Key: MYFACES-3786
> URL: https://issues.apache.org/jira/browse/MYFACES-3786
> Project: MyFaces Core
> Issue Type: Task
> Components: JSR-344
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.2.0
>
> Attachments: cdiELresolverWeb.zip, cdiELResolver.zip,
> cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch,
> cdiphaselistener1.patch, cdiphaselistener2.patch, cdiValidatorSource.zip,
> cdiValidator.war, MYFACES-3786-1.patch, MYFACES-3786-2.patch
>
>
> This issue is all about how to inject beans into jsf artifacts.
> See JSF 2.2 section 5.4.1
> The problem here is in some point we need to give the control to the
> underlying environment to inject beans into the artifacts, but we don't know
> much about how to properly do it, so we need to try with examples.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[ https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13793482#comment-13793482 ] Leonardo Uribe commented on MYFACES-3786: - The problem is that code is out of JSF control. What we are doing is just provide the injection interface to integrate with the web server. Which kind of handling can we do for @EJB annotations? none, because those annotations are handled by third party libraries. I can't imagine how to fix that from MyFaces side. If there is a bug there, we should raise an issue it against the container or the third party library we are testing. > Web Container injection support should be provided for additional lifecycle > artifacts (not just managed beans) > -- > > Key: MYFACES-3786 > URL: https://issues.apache.org/jira/browse/MYFACES-3786 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0 > > Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, > cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, > cdiphaselistener1.patch, cdiphaselistener2.patch, cdiValidatorSource.zip, > cdiValidator.war, MYFACES-3786-1.patch, MYFACES-3786-2.patch > > > This issue is all about how to inject beans into jsf artifacts. > See JSF 2.2 section 5.4.1 > The problem here is in some point we need to give the control to the > underlying environment to inject beans into the artifacts, but we don't know > much about how to properly do it, so we need to try with examples. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[ https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13793477#comment-13793477 ] Leonardo Uribe commented on MYFACES-3786: - What do you mean? Could you provide a concrete example for this one? As far as I know, from jsf point of view we just have to provide the interface to inject the annotations. After that, if the annotations works or not is resposibility of the container. > Web Container injection support should be provided for additional lifecycle > artifacts (not just managed beans) > -- > > Key: MYFACES-3786 > URL: https://issues.apache.org/jira/browse/MYFACES-3786 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0 > > Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, > cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, > cdiphaselistener1.patch, cdiphaselistener2.patch, cdiValidatorSource.zip, > cdiValidator.war, MYFACES-3786-1.patch, MYFACES-3786-2.patch > > > This issue is all about how to inject beans into jsf artifacts. > See JSF 2.2 section 5.4.1 > The problem here is in some point we need to give the control to the > underlying environment to inject beans into the artifacts, but we don't know > much about how to properly do it, so we need to try with examples. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MYFACES-3799) ProcessError in _AjaxResponse ignores errorName in IE8
[ https://issues.apache.org/jira/browse/MYFACES-3799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-3799: Resolution: Fixed Fix Version/s: 2.1.13 2.0.19 Assignee: Leonardo Uribe Status: Resolved (was: Patch Available) Thanks to Jan Dosoudil for provide this patch > ProcessError in _AjaxResponse ignores errorName in IE8 > -- > > Key: MYFACES-3799 > URL: https://issues.apache.org/jira/browse/MYFACES-3799 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 2.1.12 > Environment: Internet explorer 8 >Reporter: Jan Dosoudil >Assignee: Leonardo Uribe > Fix For: 2.0.19, 2.1.13 > > > Internet explorer doesn't implement textContent on XMLNode so errorName is > evaluated to "". -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[ https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-3786: Resolution: Fixed Fix Version/s: 2.2.0 Status: Resolved (was: Patch Available) > Web Container injection support should be provided for additional lifecycle > artifacts (not just managed beans) > -- > > Key: MYFACES-3786 > URL: https://issues.apache.org/jira/browse/MYFACES-3786 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0 > > Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, > cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, > cdiphaselistener1.patch, cdiphaselistener2.patch, cdiValidatorSource.zip, > cdiValidator.war, MYFACES-3786-1.patch, MYFACES-3786-2.patch > > > This issue is all about how to inject beans into jsf artifacts. > See JSF 2.2 section 5.4.1 > The problem here is in some point we need to give the control to the > underlying environment to inject beans into the artifacts, but we don't know > much about how to properly do it, so we need to try with examples. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[ https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13793363#comment-13793363 ] Leonardo Uribe commented on MYFACES-3786: - I think it is clear the justification behind the solution proposed, so I have finally committed the solution for this issue. Thanks to Gerhard and Dora for the help provided at the time to clarifying this issue. > Web Container injection support should be provided for additional lifecycle > artifacts (not just managed beans) > -- > > Key: MYFACES-3786 > URL: https://issues.apache.org/jira/browse/MYFACES-3786 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0 > > Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, > cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, > cdiphaselistener1.patch, cdiphaselistener2.patch, cdiValidatorSource.zip, > cdiValidator.war, MYFACES-3786-1.patch, MYFACES-3786-2.patch > > > This issue is all about how to inject beans into jsf artifacts. > See JSF 2.2 section 5.4.1 > The problem here is in some point we need to give the control to the > underlying environment to inject beans into the artifacts, but we don't know > much about how to properly do it, so we need to try with examples. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3797) cdi support for converters and validators
[ https://issues.apache.org/jira/browse/MYFACES-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792973#comment-13792973 ] Leonardo Uribe commented on MYFACES-3797: - I have checked the last patch and it looks good. It is ok to include it in the beta. > cdi support for converters and validators > - > > Key: MYFACES-3797 > URL: https://issues.apache.org/jira/browse/MYFACES-3797 > Project: MyFaces Core > Issue Type: New Feature > Components: JSR-344 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek > Attachments: MYFACES-3797_2.patch, MYFACES-3797.patch, > MYFACES-3797_with_external_bean_aware_wrapper_2.patch, > MYFACES-3797_with_external_bean_aware_wrapper.patch > > > with > > > org.apache.myfaces.CONVERTER_INJECTION_ENABLED > true > > and > > > org.apache.myfaces.VALIDATOR_INJECTION_ENABLED > true > > it should be possible to enable cdi support for converters/validators. > we need the config, because it was postponed for the spec. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3797) cdi support for converters and validators
[ https://issues.apache.org/jira/browse/MYFACES-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792914#comment-13792914 ] Leonardo Uribe commented on MYFACES-3797: - Could you please wait to commit this feature after the beta? I'm trying to get a beta of 2.2.x out and I would like to have time to study the solution. I'm very close to solve MYFACES-3786 and after that I want to propose a beta release. > cdi support for converters and validators > - > > Key: MYFACES-3797 > URL: https://issues.apache.org/jira/browse/MYFACES-3797 > Project: MyFaces Core > Issue Type: New Feature > Components: JSR-344 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek > Attachments: MYFACES-3797_2.patch, MYFACES-3797.patch, > MYFACES-3797_with_external_bean_aware_wrapper.patch > > > with > > > org.apache.myfaces.CONVERTER_INJECTION_ENABLED > true > > and > > > org.apache.myfaces.VALIDATOR_INJECTION_ENABLED > true > > it should be possible to enable cdi support for converters/validators. > we need the config, because it was postponed for the spec. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3797) cdi support for converters and validators
[ https://issues.apache.org/jira/browse/MYFACES-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792814#comment-13792814 ] Leonardo Uribe commented on MYFACES-3797: - I'm starting to think that a solution without use a wrapper is possible, the problem there is conceptual: who handles converter/validator instantiation? CDI or JSF? if is JSF the wrapper should not be needed if things are correctly done (the hack over the state is not required, because only if a converter is marked as serializable or stateholder/partialstateholder, it will be saved/restored), but if is CDI, the wrapper is required to do the gap over state handling. > cdi support for converters and validators > - > > Key: MYFACES-3797 > URL: https://issues.apache.org/jira/browse/MYFACES-3797 > Project: MyFaces Core > Issue Type: New Feature > Components: JSR-344 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek > Attachments: MYFACES-3797_2.patch, MYFACES-3797.patch, > MYFACES-3797_with_external_bean_aware_wrapper.patch > > > with > > > org.apache.myfaces.CONVERTER_INJECTION_ENABLED > true > > and > > > org.apache.myfaces.VALIDATOR_INJECTION_ENABLED > true > > it should be possible to enable cdi support for converters/validators. > we need the config, because it was postponed for the spec. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[ https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792807#comment-13792807 ] Leonardo Uribe commented on MYFACES-3786: - I have attached another patch, I'm still working on the details, but my intention with show the patch is just provide a reference point for the discussion, so the people can see a possible alternative to solve this issue. The default of other web servers is CDIAnnotationInjectionProvider. If the CDI implementation is correctly set up, it will work in other web servers as well (tested in jetty 8 + OWB), but I suppose in some cases custom implementations of this interface are required, but that will be provided by server vendors. Remember not only CDI annotations needs to be handled, but all JavaEE annotations, and CDI will not be always on the classpath. Without CDI, use @PostConstruct or @PreDestroy should still be valid. Can JSF 2.2 work without any CDI library on the classpath? Yes, of course. In that sense, CDI is optional. It is clear in that mode some features that depends on CDI will not work, for example CDI @FlowScope and @ViewScope, but note in MyFaces 2.2 now there are 2 new SPI interfaces for that (FacesFlowProvider and ViewScopeProvider). The idea is take care of the invocations to specific CDI api and make sure classes doing does references are not loaded if they are not required. In this case, we have cases where we need to call specific constructor methods to support wrapping and so on. Simply it is not possible to delegate the construction step to CDI, by all reasons exposed. The case for converter/validator will not be done in this issue. In this issue, the only concern for now if implement what the spec says about injection. > Web Container injection support should be provided for additional lifecycle > artifacts (not just managed beans) > -- > > Key: MYFACES-3786 > URL: https://issues.apache.org/jira/browse/MYFACES-3786 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, > cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, > cdiphaselistener1.patch, cdiphaselistener2.patch, cdiValidatorSource.zip, > cdiValidator.war, MYFACES-3786-1.patch, MYFACES-3786-2.patch > > > This issue is all about how to inject beans into jsf artifacts. > See JSF 2.2 section 5.4.1 > The problem here is in some point we need to give the control to the > underlying environment to inject beans into the artifacts, but we don't know > much about how to properly do it, so we need to try with examples. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[ https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792253#comment-13792253 ] Leonardo Uribe commented on MYFACES-3786: - I have attached a prototype for this issue. Basically the code refactor what we have already in LifecycleProvider and include the new logic related to CDI, and fix injection on Factories and in PhaseListener. I changed the name of the spi interface to InjectionProvider too and add the method to check if the provider is available or not. It also includes a trick to check if a bean is injected or not using the web server api (tomcat 7). It has a pure CDI injection provider in case there is no matching InjectionProvider and CDI is available on the environment. I have done some tests with tomee and it works so far. The solution still needs more work, but I think the patch reflects the basic structure of the solution. > Web Container injection support should be provided for additional lifecycle > artifacts (not just managed beans) > -- > > Key: MYFACES-3786 > URL: https://issues.apache.org/jira/browse/MYFACES-3786 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, > cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, > cdiphaselistener1.patch, cdiphaselistener2.patch, cdiValidatorSource.zip, > cdiValidator.war, MYFACES-3786-1.patch > > > This issue is all about how to inject beans into jsf artifacts. > See JSF 2.2 section 5.4.1 > The problem here is in some point we need to give the control to the > underlying environment to inject beans into the artifacts, but we don't know > much about how to properly do it, so we need to try with examples. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[ https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792001#comment-13792001 ] Leonardo Uribe commented on MYFACES-3786: - Precisely what I want to show here is the constraints we are bound, at least in JSF 2.2. I know that the best scenario is all JSF artifacts can be managed by CDI. If all objects are managed by CDI, things are easier. Just use BeanManager API from start and don't care about make CDI library optional and all reflection code made to keep it in that way, and we will not have the problem to call postConstruct or preDestroy, because if everything is managed by CDI, the scope of the instance will take care of that, but unfortunately that is not the current situation. In this case we are forced to deprecate LifecycleProvider and introduce a new spi interface for that. That's not something I would want to but its what it takes to get the job done. I agree the spec is highly ambiguous in this part. But we don't have much choice in this part. It is clear CDI is an optional library for JSF 2.2. There is a section in JSF 2.2 (Preface / Related Technologies ) and there is not any mention to CDI at all. If you look in the spec pdf, the word CDI only appears in section 5.4 and in relationship with CDI ViewScope. > Web Container injection support should be provided for additional lifecycle > artifacts (not just managed beans) > -- > > Key: MYFACES-3786 > URL: https://issues.apache.org/jira/browse/MYFACES-3786 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, > cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, > cdiphaselistener1.patch, cdiphaselistener2.patch, cdiValidatorSource.zip, > cdiValidator.war > > > This issue is all about how to inject beans into jsf artifacts. > See JSF 2.2 section 5.4.1 > The problem here is in some point we need to give the control to the > underlying environment to inject beans into the artifacts, but we don't know > much about how to properly do it, so we need to try with examples. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[ https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791789#comment-13791789 ] Leonardo Uribe commented on MYFACES-3786: - @gerhard: I have seen them. The problem is CDI is optional, so we are forced to deal with the case when CDI is not available or the case where we are not in a JavaEE compliant server. So, we need a layer that hides the details behind injection, but in an environment where CDI is present, the code should prefer integrate with CDI instead integrate with the server. The key point is still valid, JSF artifacts are managed by JSF, not by CDI. Think about this example: @ApplicationScoped public class CustomNavigationHandler extends extends ConfigurableNavigationHandler Is that valid? of course not, because the navigation handler needs to be registered in faces-config.xml to make it available. JSF controls its instantiation and lifecycle, but it requires the injection stuff from the underlying environment. In words of the spec "... the following JSF artifacts are also injectable ..." Unfortunately we can't do the same like deltaspike, without change the spec. > Web Container injection support should be provided for additional lifecycle > artifacts (not just managed beans) > -- > > Key: MYFACES-3786 > URL: https://issues.apache.org/jira/browse/MYFACES-3786 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, > cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, > cdiphaselistener1.patch, cdiphaselistener2.patch, cdiValidatorSource.zip, > cdiValidator.war > > > This issue is all about how to inject beans into jsf artifacts. > See JSF 2.2 section 5.4.1 > The problem here is in some point we need to give the control to the > underlying environment to inject beans into the artifacts, but we don't know > much about how to properly do it, so we need to try with examples. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791397#comment-13791397
]
Leonardo Uribe commented on MYFACES-3786:
-
Thinking more about this really the use of createNewInstanceAndInject(String
className) is very limited, because in JSF artifacts we usually have situations
when we need to wrap multiple objects and in those cases we pass the inner
instance as a parameter of the constructor, so we get back to this:
public abstract class org.apache.myfaces.spi.InjectionLifecycleProvider
{
public abstract void inject(Object instance) throws
InjectionLifecycleProviderException;
public abstract void postConstruct(Object instance) throws
InjectionLifecycleProviderException;
public abstract void preDestroy(Object instance) throws
InjectionLifecycleProviderException;
}
This means we cannot reuse the existing logic in LifecycleProvider2. But we can
take advantage of the fact that CDI has something similar it its code. If CDI
is present, the default method just try to inject using BeanManager API. If no
CDI is present, an implementation will be required, but to keep things working
just use LifecycleProvider2 stuff in JSF ManagedBeans only.
> Web Container injection support should be provided for additional lifecycle
> artifacts (not just managed beans)
> --
>
> Key: MYFACES-3786
> URL: https://issues.apache.org/jira/browse/MYFACES-3786
> Project: MyFaces Core
> Issue Type: Task
> Components: JSR-344
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Attachments: cdiELresolverWeb.zip, cdiELResolver.zip,
> cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch,
> cdiphaselistener1.patch, cdiphaselistener2.patch, cdiValidatorSource.zip,
> cdiValidator.war
>
>
> This issue is all about how to inject beans into jsf artifacts.
> See JSF 2.2 section 5.4.1
> The problem here is in some point we need to give the control to the
> underlying environment to inject beans into the artifacts, but we don't know
> much about how to properly do it, so we need to try with examples.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791143#comment-13791143
]
Leonardo Uribe edited comment on MYFACES-3786 at 10/10/13 3:27 AM:
---
There is a confusion behind how CDI affects JSF artifacts. To be clear, JSF
artifacts are managed by JSF, not by CDI. Why? because in this case those
objects are not bound to an specific scope inside CDI, and there is no
delegation of the instantiation process to CDI.
In that sense, the existing rules related to CDI beans like hold the
CreationalContext until destroy and so on does not apply. What we need here is
implement these 3 steps:
- Injection
- invoke PostConstruct methods
- invoke PreDestroy methods
There is already an SPI interface for that in JSF called LifecycleProvider. The
idea is we have an interface called LifecycleProvider2 with these methods:
Object newInstance(String className)
void postConstruct(Object o)
void destroyInstance(Object o)
This has worked well for a long time, and server vendors have usually a custom
implementation of this interface. This is used to handle servlet 2.5 annotation
in jsf managed beans (this is the clue left in JSF 2.2 spec section 5.4.1).
Unfortunately, LifecycleProvider2 was an interface added to fix an issue and to
avoid break things. As part of the cleanup for JSF 2.2 we need to provide a new
SPI interface for this point.
Taking into account the CDI InjectionTarget:
voidinject(T instance, CreationalContext ctx)
voidpostConstruct(T instance)
voidpreDestroy(T instance)
I would like to add the following spi interface:
public abstract class org.apache.myfaces.spi.InjectionLifecycleProvider
{
public abstract Object createNewInstanceAndInject(String className) throws
InjectionLifecycleProviderException;
public abstract void inject(Object instance) throws
InjectionLifecycleProviderException;
public abstract void postConstruct(Object instance) throws
InjectionLifecycleProviderException;
public abstract void preDestroy(Object instance) throws
InjectionLifecycleProviderException;
}
Other model to keep in mind is the one used by Mojarra for the same case:
public interface InjectionProvider {
public void inject(Object managedBean) throws InjectionProviderException;
public void invokePreDestroy(Object managedBean) throws
InjectionProviderException;
public void invokePostConstruct(Object managedBean) throws
InjectionProviderException;
}
Basically the diffence against the implementation in Mojarra is the use of an
abstract class instead of a interface and the addition of a method
createNewInstanceAndInject(String className), which most of the time comes in
handy (and follows the old approach).
The default implementation theorically should just call existing
LifecycleProvider stuff, and try to use createNewInstanceAndInject(String
className) instead inject(...) as much as possible. The problem is there is a
chance we need the inject(...) method, so it is better to include it since
start.
Note CDI has something similar in order to work with the underlying web server,
so one option is use that integration, but in some cases that's not true (for
example if we are not in a JavaEE compliant server and CDI are added as a
library, we also need to deal with that logic).
I don't like very much the idea of provide a new spi InjectionLifecycleProvider
to do "almost" the same as LifecycleProvider2, but in this case really we don't
have choice. That's what we need to get it done right.
was (Author: lu4242):
There is a confusion behind how CDI affects JSF artifacts. To be clear, JSF
artifacts are managed by JSF, not by CDI. Why? because in this case those
objects does are not bound to an specific scope inside CDI, and there is no
delegation of the instantiation process to CDI.
In that sense, the existing rules related to CDI beans like hold the
CreationalContext until destroy and so on does not apply. What we need here is
implement these 3 steps:
- Injection
- invoke PostConstruct methods
- invoke PreDestroy methods
There is already an SPI interface for that in JSF called LifecycleProvider. The
idea is we have an interface called LifecycleProvider2 with these methods:
Object newInstance(String className)
void postConstruct(Object o)
void destroyInstance(Object o)
This has worked well for a long time, and server vendors have usually a custom
implementation of this interface. This is used to handle servlet 2.5 annotation
in jsf managed beans (this is the clue left in JSF 2.2 spec section 5.4.1).
Unfortunately, LifecycleProvider2 was an interface added to fix an issue and to
avoid break things. As part of the cleanup for JSF 2.2 we need to provide a new
SPI interface for this point.
Taking into account the CDI InjectionTarget:
voidinject(T instance, CreationalContext
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791143#comment-13791143
]
Leonardo Uribe commented on MYFACES-3786:
-
There is a confusion behind how CDI affects JSF artifacts. To be clear, JSF
artifacts are managed by JSF, not by CDI. Why? because in this case those
objects does are not bound to an specific scope inside CDI, and there is no
delegation of the instantiation process to CDI.
In that sense, the existing rules related to CDI beans like hold the
CreationalContext until destroy and so on does not apply. What we need here is
implement these 3 steps:
- Injection
- invoke PostConstruct methods
- invoke PreDestroy methods
There is already an SPI interface for that in JSF called LifecycleProvider. The
idea is we have an interface called LifecycleProvider2 with these methods:
Object newInstance(String className)
void postConstruct(Object o)
void destroyInstance(Object o)
This has worked well for a long time, and server vendors have usually a custom
implementation of this interface. This is used to handle servlet 2.5 annotation
in jsf managed beans (this is the clue left in JSF 2.2 spec section 5.4.1).
Unfortunately, LifecycleProvider2 was an interface added to fix an issue and to
avoid break things. As part of the cleanup for JSF 2.2 we need to provide a new
SPI interface for this point.
Taking into account the CDI InjectionTarget:
voidinject(T instance, CreationalContext ctx)
voidpostConstruct(T instance)
voidpreDestroy(T instance)
I would like to add the following spi interface:
public abstract class org.apache.myfaces.spi.InjectionLifecycleProvider
{
public abstract Object createNewInstanceAndInject(String className) throws
InjectionLifecycleProviderException;
public abstract void inject(Object instance) throws
InjectionLifecycleProviderException;
public abstract void postConstruct(Object instance) throws
InjectionLifecycleProviderException;
public abstract void preDestroy(Object instance) throws
InjectionLifecycleProviderException;
}
Other model to keep in mind is the one used by Mojarra for the same case:
public interface InjectionProvider {
public void inject(Object managedBean) throws InjectionProviderException;
public void invokePreDestroy(Object managedBean) throws
InjectionProviderException;
public void invokePostConstruct(Object managedBean) throws
InjectionProviderException;
}
Basically the diffence against the implementation in Mojarra is the use of an
abstract class instead of a interface and the addition of a method
createNewInstanceAndInject(String className), which most of the time comes in
handy (and follows the old approach).
The default implementation theorically should just call existing
LifecycleProvider stuff, and try to use createNewInstanceAndInject(String
className) instead inject(...) as much as possible. The problem is there is a
chance we need the inject(...) method, so it is better to include it since
start.
Note CDI has something similar in order to work with the underlying web server,
so one option is use that integration, but in some cases that's not true (for
example if we are not in a JavaEE compliant server and CDI are added as a
library, we also need to deal with that logic).
I don't like very much the idea of provide a new spi InjectionLifecycleProvider
to do "almost" the same as LifecycleProvider2, but in this case really we don't
have choice. That's what we need to get it done right.
> Web Container injection support should be provided for additional lifecycle
> artifacts (not just managed beans)
> --
>
> Key: MYFACES-3786
> URL: https://issues.apache.org/jira/browse/MYFACES-3786
> Project: MyFaces Core
> Issue Type: Task
> Components: JSR-344
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Attachments: cdiELresolverWeb.zip, cdiELResolver.zip,
> cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch,
> cdiphaselistener1.patch, cdiphaselistener2.patch, cdiValidatorSource.zip,
> cdiValidator.war
>
>
> This issue is all about how to inject beans into jsf artifacts.
> See JSF 2.2 section 5.4.1
> The problem here is in some point we need to give the control to the
> underlying environment to inject beans into the artifacts, but we don't know
> much about how to properly do it, so we need to try with examples.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (MYFACES-3802) CDI FlowBuilderFactoryBean declares javax.faces.bean.ApplicationScoped (JSF managed bean annotation)
[ https://issues.apache.org/jira/browse/MYFACES-3802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-3802: Resolution: Fixed Fix Version/s: 2.2.0 Assignee: Leonardo Uribe Status: Resolved (was: Patch Available) Thanks to Martin Koci for provide this patch > CDI FlowBuilderFactoryBean declares javax.faces.bean.ApplicationScoped (JSF > managed bean annotation) > > > Key: MYFACES-3802 > URL: https://issues.apache.org/jira/browse/MYFACES-3802 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-344 >Affects Versions: 2.2.0 >Reporter: Martin Kočí >Assignee: Leonardo Uribe > Fix For: 2.2.0 > > Attachments: MYFACES-3802.patch > > > https://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/flow/cdi/FlowBuilderFactoryBean.java > declares @javax.faces.bean.ApplicationScoped; > but I think that should be javax.enterprise.context.ApplicationScoped (=CDI > ApplicationScoped) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)
[ https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790719#comment-13790719 ] Leonardo Uribe commented on MYFACES-3786: - This problem is not about CDI at all. Is about support of JavaEE 5 and 6 annotations, and that includes CDI too. In this case we need to track down not only JSF spec but JavaEE spec too. I have done some tests and now I have an idea how to fix it properly. It seems we need a CDI extension for this one, but only as a fallback in those cases where there is not a JavaEE server (for example, when you are using CDI and Tomcat or Jetty only). I'll start to work on a patch for this one, the trick with this one is how to assemble all pieces together. > Web Container injection support should be provided for additional lifecycle > artifacts (not just managed beans) > -- > > Key: MYFACES-3786 > URL: https://issues.apache.org/jira/browse/MYFACES-3786 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, > cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, > cdiphaselistener1.patch, cdiphaselistener2.patch, cdiValidatorSource.zip, > cdiValidator.war > > > This issue is all about how to inject beans into jsf artifacts. > See JSF 2.2 section 5.4.1 > The problem here is in some point we need to give the control to the > underlying environment to inject beans into the artifacts, but we don't know > much about how to properly do it, so we need to try with examples. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (MYFACES-3801) Passthrough attributes does not require URI encoding like in writeURIAttribute
[ https://issues.apache.org/jira/browse/MYFACES-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3801. - Resolution: Fixed Fix Version/s: 2.2.0 > Passthrough attributes does not require URI encoding like in writeURIAttribute > -- > > Key: MYFACES-3801 > URL: https://issues.apache.org/jira/browse/MYFACES-3801 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.2.0 > > > In the renderkit javadoc of jsf 2.2 spec says this (Rendering Pass Through > Attributes): > "... The ResponseWriter must ensure that any pass through attributes are > rendered on the outer-most markup element for the component. If there is a > pass through attribute with the same name as a renderer specific attribute, > the pass through attribute takes precedence. Pass through attributes are > rendered as if they were passed to ResponseWriter.writeURIAttribute(). ..." > Note here it says "attributes are rendered as if they were passed", instead > say "... attributes are encoded and rendered as if ...". Black box testing > against RI shows that there is no URI encoding at all in this part, so in > this case the best is do the same here. After all, it is resposibility of the > one who set the passthrough attribute to do the proper encoding in cases when > a URI is provided. There are some simple use cases like the one provided here: > http://markmail.org/message/bpqolsarmnsakhl6 > That shows that do any URI encoding here is not wanted. > However, that does not means the attribute should not be encoded as other > attributes. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MYFACES-3801) Passthrough attributes does not require URI encoding like in writeURIAttribute
Leonardo Uribe created MYFACES-3801: --- Summary: Passthrough attributes does not require URI encoding like in writeURIAttribute Key: MYFACES-3801 URL: https://issues.apache.org/jira/browse/MYFACES-3801 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe In the renderkit javadoc of jsf 2.2 spec says this (Rendering Pass Through Attributes): "... The ResponseWriter must ensure that any pass through attributes are rendered on the outer-most markup element for the component. If there is a pass through attribute with the same name as a renderer specific attribute, the pass through attribute takes precedence. Pass through attributes are rendered as if they were passed to ResponseWriter.writeURIAttribute(). ..." Note here it says "attributes are rendered as if they were passed", instead say "... attributes are encoded and rendered as if ...". Black box testing against RI shows that there is no URI encoding at all in this part, so in this case the best is do the same here. After all, it is resposibility of the one who set the passthrough attribute to do the proper encoding in cases when a URI is provided. There are some simple use cases like the one provided here: http://markmail.org/message/bpqolsarmnsakhl6 That shows that do any URI encoding here is not wanted. However, that does not means the attribute should not be encoded as other attributes. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3797) cdi support for converters and validators
[ https://issues.apache.org/jira/browse/MYFACES-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13788512#comment-13788512 ] Leonardo Uribe commented on MYFACES-3797: - I think the best way to analyze the advantages or disadvantages is to try to forecast the future a bit. Suppose you have a custom input component that does not extend from UIComponentBase but from UIComponent and you need to write the state saving logic. What do you do? you read the spec, and make custom implementations based on the descriptions there. But you haven't realized that small detail done inside UIComponentBase or DeltaStateHelper, that has changed the behavior of a method that has a clear description in the spec javadoc. At the end, your code will not work, because from outside you don't know what's inside myfaces code. And the solution? do some ugly myfaces specific hack that only god knows how to do in your third party code and you'll pray that on further versions it will not get broken. On the other side, the solution using an adapter just introduce a fine layer between the converter validator implementation and the component tree, that will be added only in those cases where CDI injection is required, so by default it is disabled. Using FacesWrapper, we can always get the inner instance. Will the existing code keep working? Yes, of course, remember the wrapper is optional. Now the question is which third party libraries do a type check over the new converter / validator instances that are injected. But more important than that is just using the spec, the third party developer can do the necessary code to inspect the wrapper and check the type correctly. In fact, the code is just trivial. Do we care about existing 3rd party libs for a new feature to be added in MyFaces 2.2.x and that by default is disabled? Absolutely no. That's a load that we don't require to carry on. JSF 2.2 is a major release, it is reasonable to write 2.2 versions of the libraries affected, but remember FacesWrapper is there since 2.0, so the necessary code can be added in 2.0 branches as well. In this case, we have a solution that just breaks encapsulation principle (which means you don't need to know what's inside the code to make it work together) against another (using an adapter) that does not. Now the state problem. To be clear, with a wrapper we don't add state. How is that possible? You can make the wrapper implement PartialStateHolder and with that the problem is solved. I know that, because there are some examples inside MyFaces Core that do precisely that. Write the wrapper can be tricky, but it will work, no doubt about that in my mind. The solution using the adapter could be discussed and included in the spec. Inclusive, we can make an SPI interface for this one. What's the deal about the adapter solution? there is no problem, it is feasible and its drawbacks are minimal compared with the alternative. > cdi support for converters and validators > - > > Key: MYFACES-3797 > URL: https://issues.apache.org/jira/browse/MYFACES-3797 > Project: MyFaces Core > Issue Type: New Feature > Components: JSR-344 >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek > Attachments: MYFACES-3797_2.patch, MYFACES-3797.patch > > > with > > > org.apache.myfaces.CONVERTER_INJECTION_ENABLED > true > > and > > > org.apache.myfaces.VALIDATOR_INJECTION_ENABLED > true > > it should be possible to enable cdi support for converters/validators. > we need the config, because it was postponed for the spec. -- This message was sent by Atlassian JIRA (v6.1#6144)
