[jira] [Resolved] (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:all-tabpanel ] Volker Weber resolved TOBAGO-1322. -- Resolution: Fixed Fix Version/s: 2.0.0-alpha-3 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 Fix For: 2.0.0-alpha-3 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (TOBAGO-1321) NPE in UserAgent.hasCapability
[ https://issues.apache.org/jira/browse/TOBAGO-1321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Volker Weber resolved TOBAGO-1321. -- Resolution: Fixed Fix Version/s: 2.0.0-alpha-3 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 Fix For: 2.0.0-alpha-3 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] (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=13794977#comment-13794977
]
Gerhard Petracek commented on MYFACES-3786:
---
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.
if you would like to try something, then we can try a #5.
all proper cdi scopes use some kind of entry to bind the instance together with
the CreationalContext.
(please remember what you copied from deltaspike (see
ContextualInstanceInfo)...)
in those cases the storage is clear - it's the context itself.
here we don't implement a context, but we can just use the same concept since
the basic issue is the same:
{code}
public class BeanEntry
{
private final Object instance;
private MapString, Object metaData = new HashMapString, Object();
public BeanEntry(Object instance)
{
this.instance = instance;
}
public Object getInstance()
{
return instance;
}
public MapString, Object getMetaData()
{
return metaData;
}
}
public abstract class InjectionProvider
{
public abstract void inject(BeanEntry entry) throws
InjectionProviderException;
public abstract void postConstruct(BeanEntry entry) throws
InjectionProviderException;
public abstract void preDestroy(BeanEntry entry) throws
InjectionProviderException;
//...
}
{code}
also here we have to store the BeanEntry in the target-scope.
it's the only approach for the current need for which you don't have to create
a key to find the meta-data (like the CreationalContext) for a given object.
for what we need right now the impact is smaller than it might sound. there is
no change for the jsf-artifacts, you just create an additional entry for them
in a list (instead of a map). during the shutdown you iterate through the whole
list and pass the entries to InjectionProvider#preDestroy.
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
+1 but I've no problem with leaving code like it is for special situations Leonardo described. Udo Am 14.10.13 17:32, schrieb Werner Punz: +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] (TOBAGO-1321) NPE in UserAgent.hasCapability
[ https://issues.apache.org/jira/browse/TOBAGO-1321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795011#comment-13795011 ] Hudson commented on TOBAGO-1321: FAILURE: Integrated in tobago-trunk #1131 (See [https://builds.apache.org/job/tobago-trunk/1131/]) TOBAGO-1321 - NPE in UserAgent.hasCapability: fix checkstyle errors (weber: http://svn.apache.org/viewvc/?view=revrev=1532230) * /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 Fix For: 2.0.0-alpha-3 UserAgent konstants MSIE_6_0 and MSIE_7_0 are not correct initialized. -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: [VOTE] svn-keywords and @author tags
+1 On Oct 14, 2013 3:46 PM, Gerhard Petracek gpetra...@apache.org wrote: 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
[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=13795077#comment-13795077 ] Gerhard Petracek commented on MYFACES-3786: --- see the patch of the first draft 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-tabpanelfocusedCommentId=13795121#comment-13795121 ] Dora Rajappan commented on MYFACES-3786: Sounds to me that you are replicating the scope handling of container in jsf. In future everything goes to container and the cdiscope handling become obsolete or a failover. And for now this #4 and #5 are equally good. But how will you listen to the scope changes in jsf and perform clean up #preDestroy? When session expires perform a clean up and also perform the cleanup when the application is shutdown, renderesponse phase for view scoped instances and so forth. How about request and flowscope clean-ups? How about custom scopes? How will you determine the scope of jsf artifact that is in annotation and not even in faces-config to store it against a scope in #4 and #5? Scoping doubts are applicable for Validator/Convertor.ie a Validator in @RequestScoped Is scope Valid for StateManager or NavigationHandler? I analysed the patch. ListBeanEntry injectedBeanStorage can be MapClass?, ListBeanEntry injectedBeanStorage for ease of predestroy by Class? and object. 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)
Re: [VOTE] svn-keywords and @author tags
+1 On Mon, Oct 14, 2013 at 5:20 PM, Matthias Wessendorf mat...@apache.org wrote: +1 On Oct 14, 2013 3:46 PM, Gerhard Petracek gpetra...@apache.org wrote: 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
[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=13795131#comment-13795131 ] Dora Rajappan commented on MYFACES-3786: Is CDI managing javax.enterprise.context scopes? Then no work need to be done in jsf for scope. 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-tabpanelfocusedCommentId=13795144#comment-13795144 ] Gerhard Petracek commented on MYFACES-3786: --- @dora: for now we don't have to listen to scope changes since those jsf-artifacts dependent to the application. - on a shutdown they get disposed (as before). if we would have to support e.g. request-scoped jsf-artifacts in the future, we just store the corresponding bean-entries (in case of #5) in the request-scope and the cleanup logic is the same (at the end of the request we iterate through the bean-entry-storage in the jsf-request-map and call #preDestroy). the same is true for every scoped artifact manually managed by jsf itself (instead of cdi). - with MYFACES-3797 validators and converters are now managed by the cdi container - we don't have to handle them the same way. we don't have to care about custom cdi scopes, since they have to handle all those topics internally. (yes javax.enterprise.* is the package 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, 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-tabpanelfocusedCommentId=13795158#comment-13795158 ] Gerhard Petracek commented on MYFACES-3786: --- the clear advantage of #5 (vs #1-#4) is that we don't need an unique id per instance to find the meta-data later on (in #preDestroy). that's way more solid. 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] [Created] (TOBAGO-1323) AJAX call breaks view state on WebSphere 8.5
Udo Schnurpfeil created TOBAGO-1323: --- Summary: AJAX call breaks view state on WebSphere 8.5 Key: TOBAGO-1323 URL: https://issues.apache.org/jira/browse/TOBAGO-1323 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 2.0.0-alpha-1 Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil After one AJAX call no other calls are possible: ViewExpiredException. The WebSphere 8.5.0.2 and 8.5.5.0 has an old MyFaces 2.0 implementation inside, and you can't update when you want to use CDI. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (TOBAGO-1323) AJAX call breaks view state on WebSphere 8.5
[ https://issues.apache.org/jira/browse/TOBAGO-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil resolved TOBAGO-1323. - Resolution: Fixed Fix Version/s: 2.0.0-alpha-3 AJAX call breaks view state on WebSphere 8.5 Key: TOBAGO-1323 URL: https://issues.apache.org/jira/browse/TOBAGO-1323 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 2.0.0-alpha-1 Environment: MyFaces 2.0.5 and earlier Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Fix For: 2.0.0-alpha-3 After one AJAX call no other calls are possible: ViewExpiredException. The WebSphere 8.5.0.2 and 8.5.5.0 has an old MyFaces 2.0 implementation inside, and you can't update when you want to use CDI. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (TOBAGO-1319) SessionSecret will not be checked in 2.0.0 alpha
[ https://issues.apache.org/jira/browse/TOBAGO-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil resolved TOBAGO-1319. - Resolution: Fixed Fix Version/s: 2.0.0-alpha-3 SessionSecret will not be checked in 2.0.0 alpha Key: TOBAGO-1319 URL: https://issues.apache.org/jira/browse/TOBAGO-1319 Project: MyFaces Tobago Issue Type: Bug Affects Versions: 2.0.0-alpha-2 Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Fix For: 2.0.0-alpha-3 -- 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=13795180#comment-13795180 ] Dora Rajappan commented on MYFACES-3786: ListBeanEntry injectedBeanStorage can be MapType, ListBeanEntry injectedBeanStorage for ease of predestroy by Type and object since the artifacts that are configurable are derived. 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-tabpanelfocusedCommentId=13795185#comment-13795185 ] Gerhard Petracek commented on MYFACES-3786: --- agreed - if we have to guarantee the order. i just kept it simple for this first draft. such internals can be changed at any time. 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] (TOBAGO-1323) AJAX call breaks view state on WebSphere 8.5
[ https://issues.apache.org/jira/browse/TOBAGO-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795184#comment-13795184 ] Hudson commented on TOBAGO-1323: SUCCESS: Integrated in tobago-trunk #1133 (See [https://builds.apache.org/job/tobago-trunk/1133/]) TOBAGO-1323: AJAX call breaks view state on WebSphere 8.5 (with MyFaces 2.0.5 and earlier) (lofwyr: http://svn.apache.org/viewvc/?view=revrev=1532325) * /myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/ajax/AjaxResponseRenderer.java AJAX call breaks view state on WebSphere 8.5 Key: TOBAGO-1323 URL: https://issues.apache.org/jira/browse/TOBAGO-1323 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 2.0.0-alpha-1 Environment: MyFaces 2.0.5 and earlier Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Fix For: 2.0.0-alpha-3 After one AJAX call no other calls are possible: ViewExpiredException. The WebSphere 8.5.0.2 and 8.5.5.0 has an old MyFaces 2.0 implementation inside, and you can't update when you want to use CDI. -- 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=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-tabpanelfocusedCommentId=13795196#comment-13795196 ] Dora Rajappan commented on MYFACES-3786: True. Instead of putting the injected beans in external context that is in this patch put in corresponding scope objects. But the scope of artifacts are not known to jsf and better not to support from jsf. 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-tabpanelfocusedCommentId=13795212#comment-13795212 ] Gerhard Petracek commented on MYFACES-3786: --- again: cdi can't do it if you need to manage instances externally - that's the point i tried to explain in the previous comments over and over again. if you bypass the cdi context-management, you have to do the equivalent on your own. #1 and #5 are very similar (what you have to do with the result is the same: store it in the same scope the instance gets stored). it's more a matter of taste if you force an implementation to return *something* and manage it or pass in a data-structure to store additional meta-data. #5 just allows to extend it later on without breaking backward compatibility (you just add properties to bean-entry once they are needed, instead of changing the parameters). i can also provide a patch for #1, there isn't a lot to change for it. 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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=13795246#comment-13795246 ] Dora Rajappan commented on MYFACES-3786: Thank @Gerald for explaining the rule when cdi context management is bypassed. Leonardo suggested scope to go in signature in #1 for supporting scope for artifacts. But that's not required these jsf aritifcats(Excluding Validator/Convertor). There is no way of jsf knowing the scope of these artifacts now. #5 is very good with bean entry having meta data. 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-tabpanelfocusedCommentId=13795249#comment-13795249 ] Gerhard Petracek commented on MYFACES-3786: --- no - that's not correct in case of the mandatory cleanup. you have to follow the cdi spec., if you do something manually. forget a ri which is broken in that part (if it really ignores it). there is no rule that we have to do the same mistakes. (i'll provide the patch for #1 in some min.) 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] [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=13795249#comment-13795249 ] Gerhard Petracek edited comment on MYFACES-3786 at 10/15/13 2:59 PM: - @leo: no - that's not correct in case of the mandatory cleanup. you have to follow the cdi spec., if you do something manually. forget a ri which is broken in that part (if it really ignores it). there is no rule that we have to do the same mistakes. (i'll provide the patch for #1 in some min.) was (Author: gpetracek): no - that's not correct in case of the mandatory cleanup. you have to follow the cdi spec., if you do something manually. forget a ri which is broken in that part (if it really ignores it). there is no rule that we have to do the same mistakes. (i'll provide the patch for #1 in some min.) 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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=13795281#comment-13795281 ] Gerhard Petracek commented on MYFACES-3786: --- then you again have the issue with the need for an unique id, duplicated scope-handling, hardcoded support of specific scopes and all the issues i listed 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, 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-tabpanelfocusedCommentId=13795283#comment-13795283 ] Gerhard Petracek commented on MYFACES-3786: --- the latest patch is the preview for #1 (i've to double check it later on due to the missing type-safety of the new parameter) 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-tabpanelfocusedCommentId=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] [Created] (TOBAGO-1324) Warning in log file when FacesMessages are rendered
Udo Schnurpfeil created TOBAGO-1324: --- Summary: Warning in log file when FacesMessages are rendered Key: TOBAGO-1324 URL: https://issues.apache.org/jira/browse/TOBAGO-1324 Project: MyFaces Tobago Issue Type: Bug Components: Themes Affects Versions: 2.0.0-alpha-2 Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Priority: Trivial Since 2.0 the method FacesMessage.rendered() should be called. -- 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=13795299#comment-13795299 ] Gerhard Petracek commented on MYFACES-3786: --- @leo: no and sorry, but i won't explain it over and over again instead of moving in a circle we should pick an approach. - #0 (= what we have right now): -0.5 if we want to support custom scopes later on and we need a stable spi right now #1 -0.5 (+1 if it's the only agreement we can get) #2/#3 -1 #4 +0 #5: +1 +1 for the small improvement suggested by dora 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] [Resolved] (TOBAGO-1324) Warning in log file when FacesMessages are rendered
[ https://issues.apache.org/jira/browse/TOBAGO-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil resolved TOBAGO-1324. - Resolution: Fixed Fix Version/s: 2.0.0-alpha-3 Warning in log file when FacesMessages are rendered --- Key: TOBAGO-1324 URL: https://issues.apache.org/jira/browse/TOBAGO-1324 Project: MyFaces Tobago Issue Type: Bug Components: Themes Affects Versions: 2.0.0-alpha-2 Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Priority: Trivial Fix For: 2.0.0-alpha-3 Since 2.0 the method FacesMessage.rendered() should be called. -- 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=13795268#comment-13795268 ] Gerhard Petracek commented on MYFACES-3786: --- in a cdi specific InjectionProvider we have to follow cdi rules. 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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=13795334#comment-13795334 ] Gerhard Petracek commented on MYFACES-3786: --- initially i said that we can change it for custom scopes once it's needed and you said that you don't like to change the spi later on. however, the positive effect is that we have an approach which doesn't need unique-ids per instance to find the meta-data for that instance (in #preDestroy). that's imo the most important reason for using #1 or #5 (and not using #2-#4). since we have the patches already, there is no reason to postpone it. i'll commit #1 soon. we can to the internal change suggested by dora at any time. 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-tabpanelfocusedCommentId=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] (TOBAGO-1324) Warning in log file when FacesMessages are rendered
[ https://issues.apache.org/jira/browse/TOBAGO-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795348#comment-13795348 ] Hudson commented on TOBAGO-1324: FAILURE: Integrated in tobago-trunk #1135 (See [https://builds.apache.org/job/tobago-trunk/1135/]) TOBAGO-1324: Warning in log file when FacesMessages are rendered (lofwyr: http://svn.apache.org/viewvc/?view=revrev=1532393) * /myfaces/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/java/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/tag/MessagesRenderer.java Warning in log file when FacesMessages are rendered --- Key: TOBAGO-1324 URL: https://issues.apache.org/jira/browse/TOBAGO-1324 Project: MyFaces Tobago Issue Type: Bug Components: Themes Affects Versions: 2.0.0-alpha-2 Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Priority: Trivial Fix For: 2.0.0-alpha-3 Since 2.0 the method FacesMessage.rendered() should be called. -- 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=13795357#comment-13795357 ] Gerhard Petracek commented on MYFACES-3786: --- there is never one ultimate api/spi style everybody can(/has to) agree with. it's your opinion and i respect it (but i don't have to agree). hopefully you also respect other opinions in such cases (even if you don't agree). anyway, since we have a compromise, we can finish it and move on. 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-tabpanelfocusedCommentId=13795381#comment-13795381 ] Dora Rajappan commented on MYFACES-3786: Is there a problem sending an object that has no injection annotations to beanManager and inject via InjectionTarget ? Will the object remain intact? 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-tabpanelfocusedCommentId=13795387#comment-13795387 ] Gerhard Petracek commented on MYFACES-3786: --- @dora: that isn't an issue - the bean-manager won't find injection points - nothing will happen. 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)
Re: [VOTE] svn-keywords and @author tags
+1 All the 'hard facts' (means who committed what and when) are in our SCM anyway. Noone need to fear that his merrit vanishes only because we remove the @author tags. People know exactly who does the vast majority of the work - so it's also time to say txs to Leo and all other passionate MyFaces hackers for putting so much heart into it :) LieGrue, strub From: Matthias Wessendorf mat...@apache.org To: MyFaces Development dev@myfaces.apache.org Sent: Monday, 14 October 2013, 17:20 Subject: Re: [VOTE] svn-keywords and @author tags +1 On Oct 14, 2013 3:46 PM, Gerhard Petracek gpetra...@apache.org wrote: 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
[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)
[VOTE] release of MyFaces Test 1.0.5
Hi, I was running the needed tasks to get the 1.0.5 release of Apache MyFaces Test out. Note these artifacts are necessary to start the release of Myfaces Core 2.2.0-beta. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.test v1.0.5 [1] The artifacts are deployed to nexus repository [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Please take a look at the 1.0.5 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-181/org/apache/myfaces/test/ https://repository.apache.org/content/groups/staging/org/apache/myfaces/test/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfacestest105binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310951version=12325276
Re: [VOTE] release of MyFaces Test 1.0.5
+1 2013/10/15 Leonardo Uribe lu4...@gmail.com Hi, I was running the needed tasks to get the 1.0.5 release of Apache MyFaces Test out. Note these artifacts are necessary to start the release of Myfaces Core 2.2.0-beta. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.test v1.0.5 [1] The artifacts are deployed to nexus repository [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Please take a look at the 1.0.5 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-181/org/apache/myfaces/test/ https://repository.apache.org/content/groups/staging/org/apache/myfaces/test/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfacestest105binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310951version=12325276
[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] [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-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] [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-tabpanelfocusedCommentId=13795705#comment-13795705 ] Gerhard Petracek commented on MYFACES-3797: --- hint for later: we could test all final weld based ee7 servers, if they still have issues with ear-files (see CDI-129). if they still have an issue and we would like to support them, we could refactor MYFACES-3797 to a mixed approach (based on MYFACES-3786). 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 Attachments: MYFACES-3797_wrapper.patch with context-param param-nameorg.apache.myfaces.CDI_MANAGED_CONVERTERS_ENABLED/param-name param-valuetrue/param-value /context-param and context-param param-nameorg.apache.myfaces.CDI_MANAGED_VALIDATORS_ENABLED/param-name param-valuetrue/param-value /context-param 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] [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-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-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: h:outputLabel value=aLabel for=nonExistentId styleClass=rowTitle / 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] [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-tabpanelfocusedCommentId=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 ui:debug/ 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] [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 ui:debug/ 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] [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.faces.webapp.FacesServlet.service(FacesServlet.java:197) ... 19 more -- This message was sent by Atlassian JIRA
