[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-tabpanelfocusedCommentId=13794076#comment-13794076 ] Dora Rajappan commented on MYFACES-3786: MYFACES-3786-2.patch is very good. No need to change the priority of discovering the injection provider factory. Let it be container first. For all of factory artifacts to be injected by container, you can use @Named the parent factory impl and the custom implementations can use a dependency injection for parentFactory and container can inject those custom factories also. I have changed the PhaseListener and ELResolver to use new _callInjectAndPostConstruct method in FacesConfigurator in the cdirevised.patch. Validator/Convertor you have omitted for this patch. 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)
[VOTE] svn-keywords and @author tags
hi @ all, we already had a discussion as well as an agreement about it (starting point: [1]). in several modules the cleanup is finished. however, since we still have (even new) parts which contain svn-keywords and/or @author tags, i start this formal vote. please vote with - [ ] +1 for: stop using svn-keywords and @author tags (+ remove the remaining) [ ] +0 [ ] -1 for: we should keep svn-keywords and @author tags - regards, gerhard [1] http://s.apache.org/ZtS
Re: [VOTE] svn-keywords and @author tags
+1 Regards, Jakob 2013/10/14 Gerhard Petracek gpetra...@apache.org: hi @ all, we already had a discussion as well as an agreement about it (starting point: [1]). in several modules the cleanup is finished. however, since we still have (even new) parts which contain svn-keywords and/or @author tags, i start this formal vote. please vote with - [ ] +1 for: stop using svn-keywords and @author tags (+ remove the remaining) [ ] +0 [ ] -1 for: we should keep svn-keywords and @author tags - regards, gerhard [1] http://s.apache.org/ZtS -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] svn-keywords and @author tags
+1 for removing author tags. +1 for removing most svn tags There's value in having the svn version tag as you can't tell what version of the file you are working with once the file is used outside of svn. On the other hand, having the svn version tag can make diffing changes more difficult. So I guess I'm +0.01 on keeping the svn version tags, but I could easily go the other way. On Mon, Oct 14, 2013 at 9:49 AM, Jakob Korherr jakob.korh...@gmail.com wrote: +1 Regards, Jakob 2013/10/14 Gerhard Petracek gpetra...@apache.org: hi @ all, we already had a discussion as well as an agreement about it (starting point: [1]). in several modules the cleanup is finished. however, since we still have (even new) parts which contain svn-keywords and/or @author tags, i start this formal vote. please vote with - [ ] +1 for: stop using svn-keywords and @author tags (+ remove the remaining) [ ] +0 [ ] -1 for: we should keep svn-keywords and @author tags - regards, gerhard [1] http://s.apache.org/ZtS -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[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-tabpanelfocusedCommentId=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)
Re: [VOTE] svn-keywords and @author tags
+0 for removing author tags. Note there is code licensed under ASL that was originally taken from other sources, and it is a good idea to keep the references of where that code came from. For example: http://svn.apache.org/repos/asf/myfaces/core/trunk/shared/src/main/java/org/apache/myfaces/shared/util/StreamCharBuffer.java I don't like the idea of remove the @author tag in those places. But if people wants to get rid of @author tag, I will not object that. +1 for remove svn tags (not used at all). 2013/10/14 Mike Kienenberger mkien...@gmail.com +1 for removing author tags. +1 for removing most svn tags There's value in having the svn version tag as you can't tell what version of the file you are working with once the file is used outside of svn. On the other hand, having the svn version tag can make diffing changes more difficult. So I guess I'm +0.01 on keeping the svn version tags, but I could easily go the other way. On Mon, Oct 14, 2013 at 9:49 AM, Jakob Korherr jakob.korh...@gmail.com wrote: +1 Regards, Jakob 2013/10/14 Gerhard Petracek gpetra...@apache.org: hi @ all, we already had a discussion as well as an agreement about it (starting point: [1]). in several modules the cleanup is finished. however, since we still have (even new) parts which contain svn-keywords and/or @author tags, i start this formal vote. please vote with - [ ] +1 for: stop using svn-keywords and @author tags (+ remove the remaining) [ ] +0 [ ] -1 for: we should keep svn-keywords and @author tags - regards, gerhard [1] http://s.apache.org/ZtS -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] svn-keywords and @author tags
+0 from my side, I simply do not care, I can live with both solutions. Werner Am 14.10.13 16:18, schrieb Leonardo Uribe: +0 for removing author tags. Note there is code licensed under ASL that was originally taken from other sources, and it is a good idea to keep the references of where that code came from. For example: http://svn.apache.org/repos/asf/myfaces/core/trunk/shared/src/main/java/org/apache/myfaces/shared/util/StreamCharBuffer.java I don't like the idea of remove the @author tag in those places. But if people wants to get rid of @author tag, I will not object that. +1 for remove svn tags (not used at all). 2013/10/14 Mike Kienenberger mkien...@gmail.com mailto:mkien...@gmail.com +1 for removing author tags. +1 for removing most svn tags There's value in having the svn version tag as you can't tell what version of the file you are working with once the file is used outside of svn. On the other hand, having the svn version tag can make diffing changes more difficult. So I guess I'm +0.01 on keeping the svn version tags, but I could easily go the other way. On Mon, Oct 14, 2013 at 9:49 AM, Jakob Korherr jakob.korh...@gmail.com mailto:jakob.korh...@gmail.com wrote: +1 Regards, Jakob 2013/10/14 Gerhard Petracek gpetra...@apache.org mailto:gpetra...@apache.org: hi @ all, we already had a discussion as well as an agreement about it (starting point: [1]). in several modules the cleanup is finished. however, since we still have (even new) parts which contain svn-keywords and/or @author tags, i start this formal vote. please vote with - [ ] +1 for: stop using svn-keywords and @author tags (+ remove the remaining) [ ] +0 [ ] -1 for: we should keep svn-keywords and @author tags - regards, gerhard [1] http://s.apache.org/ZtS -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[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-tabpanelfocusedCommentId=13794207#comment-13794207 ] Gerhard Petracek commented on MYFACES-3786: --- @leo: the change itself works. you would be right if the key would be e.g. the class (because 2+ request scoped instances of the same class would lead to the same key in an application scoped map). however, the key is the identity-hash-code which is different. the only issue is: if we will have to support other scopes in the future, identity-hash-code might not be strong enough + we could get a potential leak (if the cleanup code wouldn't work properly). however, i thought about it already and i had the same (spi-)change in mind. i didn't do it, because i don't like that we would expose a detail of one implementation. - i planned to discuss such a change after the upcoming beta release. 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-tabpanelfocusedCommentId=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] [Created] (TOBAGO-1321) NPE in UserAgent.hasCapability
Volker Weber created TOBAGO-1321: Summary: NPE in UserAgent.hasCapability Key: TOBAGO-1321 URL: https://issues.apache.org/jira/browse/TOBAGO-1321 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 2.0.0-alpha-2 Reporter: Volker Weber Assignee: Volker Weber UserAgent konstants MSIE_6_0 and MSIE_7_0 are not correct initialized. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (TOBAGO-1322) Input elements behind Popup are not reenabled if popup was reloaded before closing
Volker Weber created TOBAGO-1322: Summary: Input elements behind Popup are not reenabled if popup was reloaded before closing Key: TOBAGO-1322 URL: https://issues.apache.org/jira/browse/TOBAGO-1322 Project: MyFaces Tobago Issue Type: Bug Components: Themes Environment: IE8 Reporter: Volker Weber Assignee: Volker Weber -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: [VOTE] svn-keywords and @author tags
@imported code: please never import code without ip clearance. if there is an issue with the imported code, the @author tag won't help you at all. (if you would like to have the information for other reasons, just add it to the commit-message.) regards, gerhard 2013/10/14 Leonardo Uribe lu4...@gmail.com +0 for removing author tags. Note there is code licensed under ASL that was originally taken from other sources, and it is a good idea to keep the references of where that code came from. For example: http://svn.apache.org/repos/asf/myfaces/core/trunk/shared/src/main/java/org/apache/myfaces/shared/util/StreamCharBuffer.java I don't like the idea of remove the @author tag in those places. But if people wants to get rid of @author tag, I will not object that. +1 for remove svn tags (not used at all). 2013/10/14 Mike Kienenberger mkien...@gmail.com +1 for removing author tags. +1 for removing most svn tags There's value in having the svn version tag as you can't tell what version of the file you are working with once the file is used outside of svn. On the other hand, having the svn version tag can make diffing changes more difficult. So I guess I'm +0.01 on keeping the svn version tags, but I could easily go the other way. On Mon, Oct 14, 2013 at 9:49 AM, Jakob Korherr jakob.korh...@gmail.com wrote: +1 Regards, Jakob 2013/10/14 Gerhard Petracek gpetra...@apache.org: hi @ all, we already had a discussion as well as an agreement about it (starting point: [1]). in several modules the cleanup is finished. however, since we still have (even new) parts which contain svn-keywords and/or @author tags, i start this formal vote. please vote with - [ ] +1 for: stop using svn-keywords and @author tags (+ remove the remaining) [ ] +0 [ ] -1 for: we should keep svn-keywords and @author tags - regards, gerhard [1] http://s.apache.org/ZtS -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[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-tabpanelfocusedCommentId=13794246#comment-13794246 ] Gerhard Petracek commented on MYFACES-3786: --- yes - that's the 2nd option i had in mind as well. and a 3rd one would be: void inject(Object instance) //default: application-scoped and void inject(Object instance, String scope) //can get added once it's needed and a 4th would be: void inject(Object instance, Map targetStorage) all options have at least one major disadvantage. 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] (TOBAGO-1321) NPE in UserAgent.hasCapability
[ https://issues.apache.org/jira/browse/TOBAGO-1321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13794258#comment-13794258 ] Hudson commented on TOBAGO-1321: FAILURE: Integrated in tobago-trunk #1130 (See [https://builds.apache.org/job/tobago-trunk/1130/]) TOBAGO-1321 - NPE in UserAgent.hasCapability (weber: http://svn.apache.org/viewvc/?view=revrev=1531950) * /myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/context/UserAgent.java NPE in UserAgent.hasCapability -- Key: TOBAGO-1321 URL: https://issues.apache.org/jira/browse/TOBAGO-1321 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 2.0.0-alpha-2 Reporter: Volker Weber Assignee: Volker Weber UserAgent konstants MSIE_6_0 and MSIE_7_0 are not correct initialized. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TOBAGO-1322) Input elements behind Popup are not reenabled if popup was reloaded before closing
[ https://issues.apache.org/jira/browse/TOBAGO-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13794257#comment-13794257 ] Hudson commented on TOBAGO-1322: FAILURE: Integrated in tobago-trunk #1130 (See [https://builds.apache.org/job/tobago-trunk/1130/]) TOBAGO-1322 - Input elements behind Popup are not reenabled if popup was reloaded before closing (weber: http://svn.apache.org/viewvc/?view=revrev=1531953) * /myfaces/tobago/trunk/tobago-theme/tobago-theme-standard/src/main/resources/org/apache/myfaces/tobago/renderkit/html/standard/standard/script/tobago-popup.js Input elements behind Popup are not reenabled if popup was reloaded before closing -- Key: TOBAGO-1322 URL: https://issues.apache.org/jira/browse/TOBAGO-1322 Project: MyFaces Tobago Issue Type: Bug Components: Themes Environment: IE8 Reporter: Volker Weber Assignee: Volker Weber -- 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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=13794281#comment-13794281 ] Gerhard Petracek commented on MYFACES-3786: --- the disadvantage of #2 and #3 is that all implementations have to support all possible jsf-scopes. once one scope is added, all implementations need to be updated. (that's mainly an issue for external implementations. they would need to use a fallback like the current approach.) 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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=13794407#comment-13794407
]
Gerhard Petracek commented on MYFACES-3786:
---
to avoid something like:
public void inject(Object instance, String scope) throws
InjectionProviderException
{
AnnotatedType annoType =
beanManager.createAnnotatedType(instance.getClass());
InjectionTarget target = beanManager.createInjectionTarget(annoType);
CreationalContext? creationalContext =
beanManager.createCreationalContext(null);
DependentInstanceStorage storage;
if (application.equals(scope))
{
storage = getApplicationScopedDependentInstanceStorage();
}
else if (request.equals(scope))
{
storage = getRequestScopedDependentInstanceStorage();
}
//else if -- for all known scopes
else
{
storage = getFallbackDependentInstanceStorage(); //that's the case
for new scopes
}
storage.add(new DependentInstanceEntry(instance, creationalContext));
target.inject(instance, creationalContext);
}
with #2 and #3, we would need to register one instance of a
(DependentInstance)Storage per scope (with a defined naming-convention for a
generic lookup by name).
so we could do something like:
public void inject(Object instance, String scope) throws
InjectionProviderException
{
AnnotatedType annoType =
beanManager.createAnnotatedType(instance.getClass());
InjectionTarget target = beanManager.createInjectionTarget(annoType);
CreationalContext? creationalContext =
beanManager.createCreationalContext(null);
DependentInstanceStorage storage = getScopedStorageFor(scope);
//generic lookup by name
storage.add(new DependentInstanceEntry(instance, creationalContext));
target.inject(instance, creationalContext);
}
and outside of this method, we have to store the instance in the same storage.
with that we could even support custom scopes later on (in case of cdi).
however, with #4 that's a bit easier since we would have:
public void inject(Object instance, DependentInstanceStorage storage /*or a
std. map/...*/) throws InjectionProviderException
{
AnnotatedType annoType =
beanManager.createAnnotatedType(instance.getClass());
InjectionTarget target = beanManager.createInjectionTarget(annoType);
CreationalContext? creationalContext =
beanManager.createCreationalContext(null);
storage.add(new DependentInstanceEntry(instance, creationalContext));
target.inject(instance, creationalContext);
}
it looks similar, but you don't need #getScopedStorageFor in 2 places (inside
and outside of InjectionProvider).
+ if we use the map interface, we don't need DependentInstanceStorage as a part
of the spi (we just can wrap the storage instance in a map or
DependentInstanceStorage just implements the map interface).
as a first step we just need to create a simple application-scoped map and add
the whole logic with DependentInstanceStorage once we need to support custom
scopes.
- void inject(Object instance, Map storage) throws InjectionProviderException
@who holds the context of the injected bean? cdi. (+ the paragraph before):
in the area we are in right now (which isn't the std. usage model) that isn't
correct at all.
cdi is context and dependency injection. if you manage instances on your own
without javax.enterprise.inject.spi.Bean (which is the case here), you only
have the dependency injection part handled by cdi. once you step out of
javax.enterprise.inject.spi.Bean, you bypass parts of cdi.
- what i said before is correct.
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
[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-tabpanelfocusedCommentId=13794412#comment-13794412 ] Gerhard Petracek commented on MYFACES-3786: --- @my last comment: it's easier to read the source-code in the mail-archive (there the format is preserve) 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] [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-tabpanelfocusedCommentId=13794412#comment-13794412 ] Gerhard Petracek edited comment on MYFACES-3786 at 10/14/13 8:12 PM: - @my last comment: it's easier to read the source-code in the mail-archive (there the format is preserve) or at http://s.apache.org/drr was (Author: gpetracek): @my last comment: it's easier to read the source-code in the mail-archive (there the format is preserve) 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] [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-tabpanelfocusedCommentId=13794407#comment-13794407
]
Gerhard Petracek edited comment on MYFACES-3786 at 10/14/13 8:16 PM:
-
to avoid something like:
{code}
public void inject(Object instance, String scope) throws
InjectionProviderException
{
AnnotatedType annoType =
beanManager.createAnnotatedType(instance.getClass());
InjectionTarget target = beanManager.createInjectionTarget(annoType);
CreationalContext? creationalContext =
beanManager.createCreationalContext(null);
DependentInstanceStorage storage;
if (application.equals(scope))
{
storage = getApplicationScopedDependentInstanceStorage();
}
else if (request.equals(scope))
{
storage = getRequestScopedDependentInstanceStorage();
}
//else if -- for all known scopes
else
{
storage = getFallbackDependentInstanceStorage(); //that's the case
for new scopes
}
storage.add(new DependentInstanceEntry(instance, creationalContext));
target.inject(instance, creationalContext);
}
{code}
with #2 and #3, we would need to register one instance of a
(DependentInstance)Storage per scope (with a defined naming-convention for a
generic lookup by name).
so we could do something like:
{code}
public void inject(Object instance, String scope) throws
InjectionProviderException
{
AnnotatedType annoType =
beanManager.createAnnotatedType(instance.getClass());
InjectionTarget target = beanManager.createInjectionTarget(annoType);
CreationalContext? creationalContext =
beanManager.createCreationalContext(null);
DependentInstanceStorage storage = getScopedStorageFor(scope);
//generic lookup by name
storage.add(new DependentInstanceEntry(instance, creationalContext));
target.inject(instance, creationalContext);
}
{code}
and outside of this method, we have to store the instance in the same storage.
with that we could even support custom scopes later on (in case of cdi).
however, with #4 that's a bit easier since we would have:
{code}
public void inject(Object instance, DependentInstanceStorage storage /*or a
std. map/...*/) throws InjectionProviderException
{
AnnotatedType annoType =
beanManager.createAnnotatedType(instance.getClass());
InjectionTarget target = beanManager.createInjectionTarget(annoType);
CreationalContext? creationalContext =
beanManager.createCreationalContext(null);
storage.add(new DependentInstanceEntry(instance, creationalContext));
target.inject(instance, creationalContext);
}
{code}
it looks similar, but you don't need #getScopedStorageFor in 2 places (inside
and outside of InjectionProvider).
+ if we use the map interface, we don't need DependentInstanceStorage as a part
of the spi (we just can wrap the storage instance in a map or
DependentInstanceStorage just implements the map interface).
as a first step we just need to create a simple application-scoped map and add
the whole logic with DependentInstanceStorage once we need to support custom
scopes.
-
{code}
void inject(Object instance, Map storage) throws InjectionProviderException
{code}
@who holds the context of the injected bean? cdi. (+ the paragraph before):
in the area we are in right now (which isn't the std. usage model) that isn't
correct at all.
cdi is context and dependency injection. if you manage instances on your own
without javax.enterprise.inject.spi.Bean (which is the case here), you only
have the dependency injection part handled by cdi. once you step out of
javax.enterprise.inject.spi.Bean, you bypass parts of cdi.
- what i said before is correct.
was (Author: gpetracek):
to avoid something like:
public void inject(Object instance, String scope) throws
InjectionProviderException
{
AnnotatedType annoType =
beanManager.createAnnotatedType(instance.getClass());
InjectionTarget target = beanManager.createInjectionTarget(annoType);
CreationalContext? creationalContext =
beanManager.createCreationalContext(null);
DependentInstanceStorage storage;
if (application.equals(scope))
{
storage = getApplicationScopedDependentInstanceStorage();
}
else if (request.equals(scope))
{
storage = getRequestScopedDependentInstanceStorage();
}
//else if -- for all known scopes
else
{
storage = getFallbackDependentInstanceStorage(); //that's the case
for new scopes
}
storage.add(new DependentInstanceEntry(instance, creationalContext));
target.inject(instance, creationalContext);
}
with #2 and #3, we would need to
[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-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=13794407#comment-13794407
]
Gerhard Petracek edited comment on MYFACES-3786 at 10/14/13 8:23 PM:
-
to avoid something like:
{code}
public void inject(Object instance, String scope) throws
InjectionProviderException
{
AnnotatedType annoType =
beanManager.createAnnotatedType(instance.getClass());
InjectionTarget target = beanManager.createInjectionTarget(annoType);
CreationalContext? creationalContext =
beanManager.createCreationalContext(null);
DependentInstanceStorage storage;
if (application.equals(scope))
{
storage = getApplicationScopedDependentInstanceStorage();
}
else if (request.equals(scope))
{
storage = getRequestScopedDependentInstanceStorage();
}
//else if -- for all known scopes
else
{
storage = getFallbackDependentInstanceStorage(); //that's the case
for new scopes
}
storage.add(new DependentInstanceEntry(instance, creationalContext));
target.inject(instance, creationalContext);
}
{code}
with #2 and #3, we would need to register one instance of a
(DependentInstance)Storage per scope (with a defined naming-convention for a
generic lookup by name).
so we could do something like:
{code}
public void inject(Object instance, String scope) throws
InjectionProviderException
{
AnnotatedType annoType =
beanManager.createAnnotatedType(instance.getClass());
InjectionTarget target = beanManager.createInjectionTarget(annoType);
CreationalContext? creationalContext =
beanManager.createCreationalContext(null);
DependentInstanceStorage storage = getScopedStorageFor(scope);
//generic lookup by name
storage.add(new DependentInstanceEntry(instance, creationalContext));
target.inject(instance, creationalContext);
}
{code}
and outside of this method, we have to store the instance in the same storage.
with that we could even support custom scopes later on (in case of cdi).
however, with #4 that's a bit easier since we would have:
{code}
public void inject(Object instance, DependentInstanceStorage storage /*or a
std. map/...*/) throws InjectionProviderException
{
AnnotatedType annoType =
beanManager.createAnnotatedType(instance.getClass());
InjectionTarget target = beanManager.createInjectionTarget(annoType);
CreationalContext? creationalContext =
beanManager.createCreationalContext(null);
storage.add(new DependentInstanceEntry(instance, creationalContext));
target.inject(instance, creationalContext);
}
{code}
it looks similar, but you don't need #getScopedStorageFor in 2 places (inside
and outside of InjectionProvider).
+ if we use the map interface, we don't need DependentInstanceStorage as a part
of the spi (we just can wrap the storage instance in a map or
DependentInstanceStorage just implements the map interface).
as a first step we just need to create a simple application-scoped map and add
the whole logic with DependentInstanceStorage once we need to support custom
scopes.
-
{code}
void inject(Object instance, Map storage) throws InjectionProviderException
public void postConstruct(Object instance, Map storage) throws
InjectionProviderException
public void preDestroy(Object instance, Map storage) throws
InjectionProviderException
{code}
@who holds the context of the injected bean? cdi. (+ the paragraph before):
in the area we are in right now (which isn't the std. usage model) that isn't
correct at all.
cdi is context and dependency injection. if you manage instances on your own
without javax.enterprise.inject.spi.Bean (which is the case here), you only
have the dependency injection part handled by cdi. once you step out of
javax.enterprise.inject.spi.Bean, you bypass parts of cdi.
- what i said before is correct.
was (Author: gpetracek):
to avoid something like:
{code}
public void inject(Object instance, String scope) throws
InjectionProviderException
{
AnnotatedType annoType =
beanManager.createAnnotatedType(instance.getClass());
InjectionTarget target = beanManager.createInjectionTarget(annoType);
CreationalContext? creationalContext =
beanManager.createCreationalContext(null);
DependentInstanceStorage storage;
if (application.equals(scope))
{
storage = getApplicationScopedDependentInstanceStorage();
}
else if (request.equals(scope))
{
storage = getRequestScopedDependentInstanceStorage();
}
//else if -- for all known scopes
else
{
storage = getFallbackDependentInstanceStorage(); //that's the case
for new scopes
[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-tabpanelfocusedCommentId=13794468#comment-13794468 ] Gerhard Petracek commented on MYFACES-3786: --- if we ever need to support custom cdi scopes here, we have to do the lookup outside anyway (to store the instance itself) and if we do it via the el-resolver it won't even depend on cdi directly (then it depends on the location/s of the storage/s - even different locations are possible). if we don't/never need custom scopes here (at least in the beginning), we can store the map (= storage) in the corresponding jsf-map (you don't lose functionality in this case since we are outside of the cdi internals for managing instances anyway) - there is already a clear separation with it (which we can control easily). we need a storage (jsf scope-map/bean, cdi bean,...) to store the instance we handle manually via InjectionProvider (outside of InjectionProvider) anyway. - with #4 the meta-data which might be needed later on (like CreationalContext) is just stored in the same storage and InjectionProvider doesn't need any code to handle scopes (again). 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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=13794717#comment-13794717 ] Gerhard Petracek commented on MYFACES-3786: --- no - maybe it wasn't clear enough. let's start from the beginning. the whole topic is only about supporting other scopes like request-scoped artifacts (which might be needed in the future) for jsf-artifacts which aren't managed by cdi (because we have to create the instances for proper wrapping). those jsf-artifacts might have dependent-scoped beans injected (injected but not managed by the cdi container, because they are dependent-scoped). what we have right now already works for them, but it would be better (in all cases #1-#4) to store the meta-data in the same scope (to be more solid in case of unexpected issues with our own cleanup logic, support session-replication in case of such session-scoped artifacts (if there will be any we have to support),...) as you said - it's a good idea to keep responsibilities separated - InjectionProvider is about handling injection and not storing meta-data in the correct scopes/contexts. with using a string (#2/#3) you would have: outside of InjectionProvider: FacesContext.getCurrentInstance().getExternalContext().getRequestMap().put(beanName, instance); - call InjectionProvider#inject(..., [scope-name]) - inside of InjectionProvider Map storage = getStorage(scopeName); //which is: FacesContext.getCurrentInstance().getExternalContext().getRequestMap() after checking the scope-name storage.put(uniqueIdForBeanInstance, creationalContext); ... - call InjectionProvider#preDestroy(..., [scope-name]) - inside of InjectionProvider Map storage = getStorage(scopeName); //which is: FacesContext.getCurrentInstance().getExternalContext().getRequestMap() after checking the scope-name storage.get(uniqueIdForBeanInstance); //call #release on the result ... and with #4 it would be: outside of InjectionProvider: Map storage = getStorage(scopeName); //which is: FacesContext.getCurrentInstance().getExternalContext().getRequestMap() storage.put(beanName, instance); - call InjectionProvider#inject(..., storage) - inside of InjectionProvider storage.put(uniqueIdForBeanInstance, creationalContext); ... Map storage = getStorage(scopeName); //which is: FacesContext.getCurrentInstance().getExternalContext().getRequestMap() - call InjectionProvider#preDestroy(..., storage) - inside of InjectionProvider storage.get(uniqueIdForBeanInstance); //call #release on the result ... #4 is nothing new, there are many libs which do such a separation. as mentioned before - all (#1-#4) have disadvantages and i know what you mean, the string approach also came to my mind initially. however, it just adds an indirection which isn't needed (one method call later it gets mapped back to the same map - in any useful case), mixes responsibilities and forces redundant lookups (you need the same lookup you did directly before). 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] [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-tabpanelfocusedCommentId=13794717#comment-13794717 ] Gerhard Petracek edited comment on MYFACES-3786 at 10/15/13 12:56 AM: -- no - maybe it wasn't clear enough. let's start from the beginning. the whole topic is only about supporting other scopes like request-scoped artifacts (which might be needed in the future) for jsf-artifacts which aren't managed by cdi (because we have to create the instances for proper wrapping). those jsf-artifacts might have dependent-scoped beans injected (injected but not managed by the cdi container, because they are dependent-scoped). what we have right now already works for the most important cases, but it would be better (in all cases #1-#4) to store the meta-data in the same scope (to be more solid in case of unexpected issues with our own cleanup logic (e.g. of such view-scoped artifacts (if there will be any we have to support)), support session-replication in case of such session-scoped artifacts (if there will be any we have to support),...) as you said - it's a good idea to keep responsibilities separated - InjectionProvider is about handling injection and not storing meta-data in the correct scopes/contexts. with using a string (#2/#3) you would have: outside of InjectionProvider: FacesContext.getCurrentInstance().getExternalContext().getRequestMap().put(beanName, instance); - call InjectionProvider#inject(..., [scope-name]) - inside of InjectionProvider Map storage = getStorage(scopeName); //which is: FacesContext.getCurrentInstance().getExternalContext().getRequestMap() after checking the scope-name storage.put(uniqueIdForBeanInstance, creationalContext); ... - call InjectionProvider#preDestroy(..., [scope-name]) - inside of InjectionProvider Map storage = getStorage(scopeName); //which is: FacesContext.getCurrentInstance().getExternalContext().getRequestMap() after checking the scope-name storage.get(uniqueIdForBeanInstance); //call #release on the result ... and with #4 it would be: outside of InjectionProvider: Map storage = getStorage(scopeName); //which is: FacesContext.getCurrentInstance().getExternalContext().getRequestMap() storage.put(beanName, instance); - call InjectionProvider#inject(..., storage) - inside of InjectionProvider storage.put(uniqueIdForBeanInstance, creationalContext); ... Map storage = getStorage(scopeName); //which is: FacesContext.getCurrentInstance().getExternalContext().getRequestMap() - call InjectionProvider#preDestroy(..., storage) - inside of InjectionProvider storage.get(uniqueIdForBeanInstance); //call #release on the result ... #4 is nothing new, there are many libs which do such a separation. as mentioned before - all (#1-#4) have disadvantages and i know what you mean, the string approach also came to my mind initially. however, it just adds an indirection which isn't needed (one method call later it gets mapped back to the same map - in any useful case), mixes responsibilities and forces redundant lookups (you need the same lookup you did directly before). was (Author: gpetracek): no - maybe it wasn't clear enough. let's start from the beginning. the whole topic is only about supporting other scopes like request-scoped artifacts (which might be needed in the future) for jsf-artifacts which aren't managed by cdi (because we have to create the instances for proper wrapping). those jsf-artifacts might have dependent-scoped beans injected (injected but not managed by the cdi container, because they are dependent-scoped). what we have right now already works for them, but it would be better (in all cases #1-#4) to store the meta-data in the same scope (to be more solid in case of unexpected issues with our own cleanup logic, support session-replication in case of such session-scoped artifacts (if there will be any we have to support),...) as you said - it's a good idea to keep responsibilities separated - InjectionProvider is about handling injection and not storing meta-data in the correct scopes/contexts. with using a string (#2/#3) you would have: outside of InjectionProvider: FacesContext.getCurrentInstance().getExternalContext().getRequestMap().put(beanName, instance); - call InjectionProvider#inject(..., [scope-name]) - inside of InjectionProvider Map storage = getStorage(scopeName); //which is: FacesContext.getCurrentInstance().getExternalContext().getRequestMap() after checking the scope-name storage.put(uniqueIdForBeanInstance, creationalContext); ... - call InjectionProvider#preDestroy(..., [scope-name]) - inside of InjectionProvider Map storage = getStorage(scopeName); //which is: FacesContext.getCurrentInstance().getExternalContext().getRequestMap() after checking the scope-name storage.get(uniqueIdForBeanInstance); //call #release on the result ... and with #4 it would be:
[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-tabpanelfocusedCommentId=13794746#comment-13794746 ] Gerhard Petracek commented on MYFACES-3786: --- however, since we don't need it right now, i'm ok with keeping it as it is. that's also the reason why i did it that way and postponed the discussion initially. 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-tabpanelfocusedCommentId=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)
