[jira] [Commented] (MYFACES-3528) CLONE - Performance Improvements
[ https://issues.apache.org/jira/browse/MYFACES-3528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258160#comment-13258160 ] Krashan Brahmanjara commented on MYFACES-3528: -- This patch can help users of myfaces 1.1 with infinite loop problems like: MYFACES-1162 (_ComponentAttributesMap.getPropertyDescriptor appears to get hung in a HashMap under peak load.) or MYFACES-3442 (infinite loop under heavy load) CLONE - Performance Improvements Key: MYFACES-3528 URL: https://issues.apache.org/jira/browse/MYFACES-3528 Project: MyFaces Core Issue Type: Improvement Reporter: Krashan Brahmanjara Assignee: Martin Marinschek Fix For: 1.2.2 Attachments: ApplicationImpl.java, _ComponentAttributesMap.java Last week I did some JMeter testing, profiling and code checking on MyFaces to try increase the overall performance. Here are my suggestions for improvement: *) _ComponentAttributesMap I introduced a cache for maps with component attributes. This cache avoids rebuilding the map for every instance of the same component class. It is implemented using a WeakHashMap to allow the GC to remove entries that are not referenced in any instance. *) UIComponentBase Made a few changes in isIdValid as it is called quite often. The new id is now checked against the old id and if it is the same it is assumed as valid (avoids checking chars). Additionally I use isLetterOrDigit() and access string chars directly insted of fetching an array first. *) ImplicitObjectResolver I replaced List with Map to avoid iteration over lists. *) HtmlResponseWriterImpl Use new method of HTMLEncoder for char[] *) HTMLEncoder Improved performance of encode mthod and added a new one that takes a char[] und directly writes to a writer. *) UnicodeEncoder Replaced StringBuffer with StringBuilder. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2258) Add Chunked File Upload support to the Trinidad Upload Framwork
[ https://issues.apache.org/jira/browse/TRINIDAD-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258401#comment-13258401 ] Kentaro Kinebuchi commented on TRINIDAD-2258: - The proposed solution to this issue is to split large files into chunks and upload them sequentially. Once all the chunks have been uploaded, the Upload Framework can returned a combined file. The largest supported chunk can be 2GB so that it will work with all browsers. Any files greater than 2GB will be chunked. In addition, the chunk size should be configurable via trinidad-config.xml since it is possible for users to configure the application server to only accept HTTP requests smaller than a certain size. Add Chunked File Upload support to the Trinidad Upload Framwork --- Key: TRINIDAD-2258 URL: https://issues.apache.org/jira/browse/TRINIDAD-2258 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.0.1-core Reporter: Kentaro Kinebuchi The Trinidad Upload Framework does not currently support uploading files larger than 2GB. This is due to two reasons: 1. The servlet API getContentLength returns an int byte size value: http://docs.oracle.com/javaee/5/api/javax/servlet/ServletRequest.html#getContentLength() This API is used in a number of places in the upload framework. 2. Browser support for 2GB is not very good. IE and FF don't support it while Chrome does. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2258) Add Chunked File Upload support to the Trinidad Upload Framwork
[ https://issues.apache.org/jira/browse/TRINIDAD-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258409#comment-13258409 ] Kentaro Kinebuchi commented on TRINIDAD-2258: - Attached a patch file which the changes. Add Chunked File Upload support to the Trinidad Upload Framwork --- Key: TRINIDAD-2258 URL: https://issues.apache.org/jira/browse/TRINIDAD-2258 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.0.1-core Reporter: Kentaro Kinebuchi Attachments: chunked_file_upload_trinidad.patch The Trinidad Upload Framework does not currently support uploading files larger than 2GB. This is due to two reasons: 1. The servlet API getContentLength returns an int byte size value: http://docs.oracle.com/javaee/5/api/javax/servlet/ServletRequest.html#getContentLength() This API is used in a number of places in the upload framework. 2. Browser support for 2GB is not very good. IE and FF don't support it while Chrome does. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3528) CLONE - Performance Improvements
[ https://issues.apache.org/jira/browse/MYFACES-3528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257632#comment-13257632 ] Leonardo Uribe commented on MYFACES-3528: - A lot of improvements has been already done in 2.1.x / 2.0.x, but they are not ported yet to 1.2.x / 1.1.x because since these two versions are in maintenance stage, care must be taken to ensure do not break existing applications, and most of the interest is in JSF 2.0/2.1/2.2. If you provide a patch, I'll check it and commit it for you. Note for most of the changes, it s a backport, which means just take the improvement from 2.0.x or 1.2.x and apply it in 1.1.x. CLONE - Performance Improvements Key: MYFACES-3528 URL: https://issues.apache.org/jira/browse/MYFACES-3528 Project: MyFaces Core Issue Type: Improvement Reporter: Krashan Brahmanjara Assignee: Martin Marinschek Fix For: 1.2.2 Last week I did some JMeter testing, profiling and code checking on MyFaces to try increase the overall performance. Here are my suggestions for improvement: *) _ComponentAttributesMap I introduced a cache for maps with component attributes. This cache avoids rebuilding the map for every instance of the same component class. It is implemented using a WeakHashMap to allow the GC to remove entries that are not referenced in any instance. *) UIComponentBase Made a few changes in isIdValid as it is called quite often. The new id is now checked against the old id and if it is the same it is assumed as valid (avoids checking chars). Additionally I use isLetterOrDigit() and access string chars directly insted of fetching an array first. *) ImplicitObjectResolver I replaced List with Map to avoid iteration over lists. *) HtmlResponseWriterImpl Use new method of HTMLEncoder for char[] *) HTMLEncoder Improved performance of encode mthod and added a new one that takes a char[] und directly writes to a writer. *) UnicodeEncoder Replaced StringBuffer with StringBuilder. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3530) Implicit Navigation Does Not Work After ViewExpiredException
[ https://issues.apache.org/jira/browse/MYFACES-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258016#comment-13258016 ] Paul Nicolucci commented on MYFACES-3530: - I've tested the fix locally and everything looks to be working as expected now. I'm just looking for input and for someone to take a look over my patch. Implicit Navigation Does Not Work After ViewExpiredException Key: MYFACES-3530 URL: https://issues.apache.org/jira/browse/MYFACES-3530 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.13 Environment: MyFaces 2.0.13 running on WebSphere Application Server Reporter: Paul Nicolucci Attachments: NavigationHandlerImpl.txt, NavigationHandlerImplTest.txt, ViewExpiredException.war Original Estimate: 4h Remaining Estimate: 4h When implementing a Custom ExceptionHandler to deal with ViewExpiredExceptions as suggested here: http://weblogs.java.net/blog/edburns/archive/2009/09/03/dealing-gracefully-viewexpiredexception-jsf2 The implicit navigation to viewExpired does not work due to the fact that a / is not added to the viewIdToTest in NavigationHandlerImpl.getOutcomeNavigationCase. The algorithm was correct until we pulled in MYFACES-3101 to avoid a NullPointerException after a ViewExpiredException. The exception we see without the patch is the following: [4/19/12 20:52:15:323 EDT] 0028 webappE com.ibm.ws.webcontainer.webapp.WebApp logServletError SRVE0293E: [Servlet Error]-[Faces Servlet]: org.apache.myfaces.lifecycle.ViewNotFoundException: A view is required to execute RENDER_RESPONSE(6) at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:62) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:239) The view does exist but is no longer found since we don't add a / since the viewId is null. I've also added a couple of additional null checks that look to have been missed in MyFaces-3101. A test Application will be provided as well as a diff showing my changes to NavigationHandlerImpl.java and NavigationHandlerImplTest.java ( the ViewExpiredException test needs to look for /viewExpired not viewExpired after the fix...which to me seems correct ) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3442) Infinite loop when calling ApplicationImpl._handleListenerForAnnotations under heavy load
[ https://issues.apache.org/jira/browse/MYFACES-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256287#comment-13256287 ] Krashan Brahmanjara commented on MYFACES-3442: -- Please apply this patch also for 1.1 and 1.2 branch. Infinite loop when calling ApplicationImpl._handleListenerForAnnotations under heavy load - Key: MYFACES-3442 URL: https://issues.apache.org/jira/browse/MYFACES-3442 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.3 Reporter: Michael Dietrich Assignee: Leonardo Uribe Fix For: 2.0.12, 2.1.6 Hi, when doing Load Tests, we recognize that we sometimes got stuck in an infinite loop, when calling the _handleListenerForAnnotations method of the ApplicationImpl class. According to our analysis, this is related to the _classToListenerForMap attribute that is is defined as plain HashMap, so no synchronisation takes place when it is accessed from several threads. Our suggestion would be, to define it as a ConcurrentHashMap instead, because according to our experience, such kind of infinite loops due to concurrency don't occur with ConcurrentHashMaps. Kind regards, Michael -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3528) CLONE - Performance Improvements
[ https://issues.apache.org/jira/browse/MYFACES-3528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256388#comment-13256388 ] Krashan Brahmanjara commented on MYFACES-3528: -- Please apply this patch also to the 1.1 branch. CLONE - Performance Improvements Key: MYFACES-3528 URL: https://issues.apache.org/jira/browse/MYFACES-3528 Project: MyFaces Core Issue Type: Improvement Reporter: Krashan Brahmanjara Assignee: Martin Marinschek Fix For: 1.2.2 Last week I did some JMeter testing, profiling and code checking on MyFaces to try increase the overall performance. Here are my suggestions for improvement: *) _ComponentAttributesMap I introduced a cache for maps with component attributes. This cache avoids rebuilding the map for every instance of the same component class. It is implemented using a WeakHashMap to allow the GC to remove entries that are not referenced in any instance. *) UIComponentBase Made a few changes in isIdValid as it is called quite often. The new id is now checked against the old id and if it is the same it is assumed as valid (avoids checking chars). Additionally I use isLetterOrDigit() and access string chars directly insted of fetching an array first. *) ImplicitObjectResolver I replaced List with Map to avoid iteration over lists. *) HtmlResponseWriterImpl Use new method of HTMLEncoder for char[] *) HTMLEncoder Improved performance of encode mthod and added a new one that takes a char[] und directly writes to a writer. *) UnicodeEncoder Replaced StringBuffer with StringBuilder. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2257) When a resource fails to load, add an exception if the cached temp directory doesn't match the current temp directory
[ https://issues.apache.org/jira/browse/TRINIDAD-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256709#comment-13256709 ] Mark Yvanovich commented on TRINIDAD-2257: -- Code changes reviewed by Blake. When a resource fails to load, add an exception if the cached temp directory doesn't match the current temp directory - Key: TRINIDAD-2257 URL: https://issues.apache.org/jira/browse/TRINIDAD-2257 Project: MyFaces Trinidad Issue Type: Improvement Components: Infrastructure Reporter: Mark Yvanovich Attachments: TempDirectoryResourceLoader.patch Original Estimate: 48h Remaining Estimate: 48h We have been seeing issues periodically where resources are failing to load. Based on debugging information, it seems that this may be a case where the temp directory that is initially cached by the DirectoryResourceLoader is now different from the the current temp directory of the ServletContext object. Create a new package-private class TempDirectoryResourceLoader that extends DirectoryResourceLoader and will throw a state exception if on resouce load failure the temp directories don't match. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-119) InputDate popup crashes when using extension mapping
[ https://issues.apache.org/jira/browse/TRINIDAD-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256833#comment-13256833 ] Andy K commented on TRINIDAD-119: - Is it resolved? Can someone please send me the workaround for this issue. InputDate popup crashes when using extension mapping Key: TRINIDAD-119 URL: https://issues.apache.org/jira/browse/TRINIDAD-119 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.1-core Environment: Apache Tomcat 6.0.13, JDK 1.6.02, Facelets 1.1.11, Trinidad 1.2.1, MyFaces 1.2.0, Ajax4jsf 1.0.6 Reporter: Jan-Kees van Andel Attachments: MyFacesBugFixFilter.java, MyFacesBugFixFilter.java, TRINIDAD-119-trinidad-impl.patch If I use extension mapping (*.faces), my inputDate component crashes with a 404 when I click on the button. The message is: The requested resource (/mblf/__ADFv__) is not available. When using prefix mapping (/faces/), everything works fine. The URL it references is: http://localhost:8080/mblf/faces/__ADFv__?_t=fred_red=cdvalue=118505880loc=en -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TOMAHAWK-1605) ValueExpressions for SelectItems are evaluated too often for checboxes or radios with spread layout
[ https://issues.apache.org/jira/browse/TOMAHAWK-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256139#comment-13256139 ] Leonardo Uribe commented on TOMAHAWK-1605: -- I checked the code and it seems the implementation changed completely in tomahawk20, so the duplicate call is not there anymore in a new version of shared. I know it is not optimal from perf perspective, but I think we should let it as is in 1.2 branch. If there is a problem with caching at application scope and change it later, that stuff should be handled by app itself, taking the data from app scope and storing it in request scope for example. This is a common bug, but the framework cannot help, because if the data is stored in app scope, in that location is the only place where thread safety can be warranted. I'll close this one as not a problem, because the latest code does not have the related lines anymore. Thanks for the report. ValueExpressions for SelectItems are evaluated too often for checboxes or radios with spread layout --- Key: TOMAHAWK-1605 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1605 Project: MyFaces Tomahawk Issue Type: Bug Components: selectOneRadio / radio Affects Versions: 1.1.9, 1.1.10 Environment: Myfaces 1.2.9/ 1.2.10, Richfaces 3.3.3, Facelets, Tomcat 6.0.32 Reporter: Michael Heinen The method HtmlCheckboxRenderer.renderSingleCheckbox (or HtmlRadioRenderer.renderRadio) calls for each checkbox RendererUtils.getSelectItemList(uiSelectMany) two times. RendererUtils creates a new SelectItemsIterator which evaluates the value expression again for each checkbox that should be rendered and creates each time a new List with SelectItems. It is caused by - method call getConverter(facesContext, uiSelectMany) which calls RendererUtils.getSelectItemList(uiSelectMany) - and few lines later by direct call of RendererUtils.getSelectItemList(uiSelectMany) From a performance point of view this is not optimal. It would be better to create the list once during response rendering and cache it somewhere (maybe in request scope). But even worse (and therefore from my pov a bug) is that this repeated evaluation could result in synchronization problems during the rendering of the response if the bound SelectItems array or collection is changed. This could easily happen if the SelectItems are cached in an application scoped bean. An IndexOutOfBoundsException will occur during response rendering if an item is removed by another thread. This does not happen with list or page layout because the expression to get the SelectItems is evaluated once and then stored as a local var. RendererUtils.internalGetSelectItemList contains already a comment for this: TODO: Shall we cache the list in a component attribute? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3522) collectionType attribute of selectManyCheckbox not processed correctly
[ https://issues.apache.org/jira/browse/MYFACES-3522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13252891#comment-13252891 ] Leonardo Uribe commented on MYFACES-3522: - Once is fixed in shared, it is fixed in tomahawk too. It seems I forgot to synch javax.faces.component._SharedRendererUtils, but for the issue mentioned it is not necessary. Anyway, I updated the code in trunk. Thanks for remember me that. collectionType attribute of selectManyCheckbox not processed correctly -- Key: MYFACES-3522 URL: https://issues.apache.org/jira/browse/MYFACES-3522 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.6 Environment: Tomcat 6.0.35 myFaces 2.1.6 Reporter: Michael Heinen Assignee: Leonardo Uribe Priority: Critical Fix For: 2.0.13, 2.1.7 Attachments: z.war The collectionType attribute of h:selectManyCheckbox is not processed correctly. The value attribute of selectManyCheckbox points to a Map with an ArrayList containing Strings as values, representing the selected values. The checkboxes are initially correctly checked, but after ajax submission the model (MapSting,Object) contains StringArrays instead of ArrayLists. This worked well since JSF 1.0, but it does not work with 2.1 anymore. It can be easily reproduced with MyFaces only. I see this as critical because ClassCastException are thrown as a result in application code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-1904) Exception encoding selectOneMenu when value has an intermediate node null
[
https://issues.apache.org/jira/browse/MYFACES-1904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253026#comment-13253026
]
Leonardo Uribe commented on MYFACES-1904:
-
I think it is because the description of the issue is incomplete. Note the
description of this issue does not have the logic inside the bean.
By that reason, it is not possible to see what's wrong, and fix it.
Additionally, it is not a common scenario. If you can provide a patch, or if
you can provide a test case, I'll check it and fix it.
Exception encoding selectOneMenu when value has an intermediate node null
-
Key: MYFACES-1904
URL: https://issues.apache.org/jira/browse/MYFACES-1904
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.3
Environment: geronimo 2.1.2
Reporter: Antoni Reus
I have a managed bean called treeManager, with a selectedNode property
that is null the first time.
I have three input components: 2 inputText, and a selectOneMenu, the JSP code
is this:
...
h:outputLabel for=nodeName value=Nom/
h:inputText id=nodeName value=#{treeManager.selectedNode.name} /
h:outputLabel for=nodeDescription value=Descripció/
h:inputText id=nodeDescription
value=#{treeManager.selectedNode.description} /
h:outputLabel for=ambitType value=Àmbit/
h:selectOneMenu id=ambitType value=#{treeManager.selectedNode.ambit}
f:selectItem itemLabel=Global itemValue=global/
f:selectItem itemLabel=Organisme itemValue=organisme/
f:selectItem itemLabel=Procediment itemValue=procediment/
/h:selectOneMenu
When I try the JSF I get this error.
|javax.faces.FacesException: Exception while calling encodeEnd on component :
{Component-Path : [Class: org.ajax4jsf.component.AjaxViewRoot,ViewId:
/dissenyador/estructures.jsp][Class:
javax.faces.component.html.HtmlPanelGrid,Id: j_id_jsp_305935947_1]}|
| at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:610)|
Caused by: ...
|Caused by: org.apache.jasper.el.JspPropertyNotFoundException:
/dissenyador/estructures.jsp(60,8) '#{treeManager.selectedNode.ambit}' Target
Unreachable, 'selectedNode' returned null|
| at
org.apache.jasper.el.JspValueExpression.getType(JspValueExpression.java:61)|
| at
org.apache.myfaces.shared_impl.renderkit._SharedRendererUtils.findUIOutputConverter(_SharedRendererUtils.java:58)|
| at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.findUIOutputConverter(RendererUtils.java:391)|
| at
org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils.findUIOutputConverterFailSafe(HtmlRendererUtils.java:393)|
| at
org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils.internalRenderSelect(HtmlRendererUtils.java:316)|
| at
org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils.renderMenu(HtmlRendererUtils.java:288)|
| at
org.apache.myfaces.shared_impl.renderkit.html.HtmlMenuRendererBase.encodeEnd(HtmlMenuRendererBase.java:57)|
| at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:607)|
Comments from Simon Kitching on the mailing list:
Interesting. From the stacktrace it look like the problem is when trying
to determine the *type* that this expression returns.
When actually asking for the value, null is simply returned if the
intermediate object is not there.
But when asking what static type of object would be returned from the
bound property, of course there is a real problem if the intermediate
node is not there.
Here's the code from SharedRendererUtils.findUIOutputConverter; the
getType call is the problem:
Class valueType = vb.getType(facesContext); // boom when an
intermediate node in the EL is null
if (valueType == null) return null;
if (String.class.equals(valueType)) return null;//No
converter needed for String type
if (Object.class.equals(valueType)) return null;//There is
no converter for Object class
The HtmlRendererUtils.internalRenderSelect uses
converter = findUIOutputConverterFailSafe
-- which obviously is not quite so fail safe :-)
I'm not quite sure what the converter is being used for during rendering
of the select component, but I do know that the rules about converters
and select-components are quite complex. The HTML select component must
always render strings for its options, but JSF requires typed objects to
be passed between the select *component* and the backing beans. So
conversions are required to be invoked at various times.
I think a JIRA issues should definitely be filed for this. If a
converter is optional here, then the code should catch this exception
and not use a converter. Even if a converter is mandatory (ie an error
should be reported if the value-type cannot
[jira] [Commented] (MYFACES-3524) MyFaces returns a blank page whenever there's some error. Nothing on the log, either.
[ https://issues.apache.org/jira/browse/MYFACES-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253032#comment-13253032 ] Leonardo Uribe commented on MYFACES-3524: - Probably there is an error in render response phase. The response was already started and cannot be reset, so the default error handler cannot reset the response and render the error page. You should attach a debugger into your tomcat to see what's wrong. I don't think the solution is in MyFaces in this case. MyFaces returns a blank page whenever there's some error. Nothing on the log, either. - Key: MYFACES-3524 URL: https://issues.apache.org/jira/browse/MYFACES-3524 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.1.6 Environment: JDK 1.6.0_31 Tomcat 7.0.26 tomahawk20-1.1.11 Reporter: Haroldo de Oliveira Pinheiro We were migrating from MyFaces 1.1.8 to MyFaces 2.1.6, when we ran into a really crippling problem: Whenever an uncaught error happens, MyFaces 2.1.6 just returns a blank page, and doesn't show anything on the log, either. Naturally, this error makes it almost impossible to even find out what error is ocurring. Couldn't the error at least be shown in the log? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3520) False evaluation of variables/params with the same name
[
https://issues.apache.org/jira/browse/MYFACES-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253047#comment-13253047
]
Leonardo Uribe commented on MYFACES-3520:
-
The problem with this one is c:forEach relies on VariableResolver, and that is
a bad idea by some reasons:
- It can pass across everything, including other templates and composite
components and breaks encapsulation principle.
- The value is statically stored into the inner value expressions, and that
means they can't be cached and reused across pages.
My advice is replace c:forEach with t:dataTable or t:dataList with
rowStatePreserved=true. They are more flexible as described in:
http://lu4242.blogspot.com/2011/06/jsf-component-state-per-row-for.html
Additionally, avoiding c:forEach eliminates the effect over state size.
Unfortunately, after a lot of changes done in myfaces core, the conclusion is
previous c:forEach behavior is not fixable. It is possible to use the template
context map to store the var and disable EL expression caching, but anyway
c:forEach is too inconvenient.
Change the order of VariableResolver stuff is reasonable but is also not
wanted. In fact, remove any local VariableResolver usage inside facelets
algorithm is preferred, so it is just there for backward compatibility. Note
myfaces changed the way c:set and ui:param works to match better the spec.
So, the question is if we change c:forEach to use template context scope
instead. Sounds reasonable. c:forEach var should not pass through ui:include or
composite components. In this case, ui:include creates another template
context, so with that the problem is fixed, and since the expression is still
resolved through VariableResolver, the change will not break anything.
False evaluation of variables/params with the same name
---
Key: MYFACES-3520
URL: https://issues.apache.org/jira/browse/MYFACES-3520
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.6
Reporter: dennis hoersch
I have an scenario where an xhml is included. The included file has a
parameter with the same name as some outer variable. In the included file the
parameter is ignored and the outer variable is used.
Some xhtml:
c:forEach var=item begin=1 end=3
div
ui:include src=templateContextTestInclude.xhtml
ui:param name=item value=#{item + 10} /
/ui:include
/div
/c:forEach
templateContextTestInclude.xhtml:
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:ui=http://java.sun.com/jsf/facelets;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:c=http://java.sun.com/jsp/jstl/core;
xmlns:t=http://myfaces.apache.org/tomahawk;
body
ui:composition
Item: h:outputText value=#{item} /br/
/ui:composition
/body
/html
I found out that the hierarchy of VariableMappers is asked for a value
before the 'DefaultVariableMapper' tests the current template/page context.
That was not what I expected. Is that how it should be?
In JSF1 it works that way.
(If I change the VariableMapperWrapper locally to test the template/page
context first the behaviour is as I would have expected (don't know if it is
the right place ;-)):
public ValueExpression resolveVariable(String variable)
{
AbstractFaceletContext faceletContext = (AbstractFaceletContext)
FacesContext.getCurrentInstance().getAttributes().get(FaceletContext.FACELET_CONTEXT_KEY);
//Check on page and template context
PageContext pageContext = faceletContext.getPageContext();
if (pageContext != null pageContext.getAttributeCount() 0)
{
if (pageContext.getAttributes().containsKey(variable))
{
ValueExpression returnValue =
pageContext.getAttributes().get(variable);
if (_trackResolveVariables)
{
_variableResolved = true;
}
return returnValue;
}
}
TemplateContext templateContext = faceletContext.getTemplateContext();
if (templateContext != null !templateContext.isParameterEmpty())
{
if (templateContext.getParameterMap().containsKey(variable))
{
ValueExpression returnValue =
templateContext.getParameter(variable);
if (_trackResolveVariables)
{
_variableResolved = true;
}
return returnValue
[jira] [Commented] (TRINIDAD-2228) java.lang.UnsupportedOperationException
[ https://issues.apache.org/jira/browse/TRINIDAD-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13251031#comment-13251031 ] Scott O'Bryan commented on TRINIDAD-2228: - This may be one of those cases where this is a JSF 2.1 issue when using Trinidad. We have a number of those. Can you test this against Mojarra and MyFaces 2.0 to see if it works? If it does, lets change the effected version to Trinidad 2.1.0 (which is trunk). When version 2.1 is released, it will be the one which supports JSF 2.1.. java.lang.UnsupportedOperationException --- Key: TRINIDAD-2228 URL: https://issues.apache.org/jira/browse/TRINIDAD-2228 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.1-core Environment: Ubuntu, Java 1.6, Jetty or Tomcat 7 Reporter: Walter Mourão Assignee: Scott O'Bryan Fix For: 2.0.2-core Attachments: autocomplete.zip, autocomplete1.zip Same project, with Trinidad 2.0.0 works fine, with Trinidad 2.0.1, java.lang.UnsupportedOperationException in pages containing composite components. Stack trace: java.lang.UnsupportedOperationException at javax.faces.view.ViewDeclarationLanguage.retargetMethodExpressions(ViewDeclarationLanguage.java:75) at org.apache.myfaces.view.facelets.tag.composite.CompositeComponentResourceTagHandler.applyNextHandler(CompositeComponentResourceTagHandler.java:181) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53) at org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:57) at org.apache.myfaces.view.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:45) at org.apache.myfaces.view.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:151) at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.buildView(FaceletViewDeclarationLanguage.java:435) at org.apache.myfaces.trinidadinternal.application.ViewDeclarationLanguageFactoryImpl$ChangeApplyingVDLWrapper.buildView(ViewDeclarationLanguageFactoryImpl.java:342) at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:77) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TOBAGO-950) Layout inside a sheet cell: Components still occupies some space, when rendered is set to false
[ https://issues.apache.org/jira/browse/TOBAGO-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13249849#comment-13249849 ] Dom W. commented on TOBAGO-950: --- Thanks for fixing this bug. The behaviour is now as expected. I will close this ticket. Best, Dom Layout inside a sheet cell: Components still occupies some space, when rendered is set to false - Key: TOBAGO-950 URL: https://issues.apache.org/jira/browse/TOBAGO-950 Project: MyFaces Tobago Issue Type: Bug Affects Versions: 1.0.31, 1.0.38 Environment: Firefox 3.6.12, Ubuntu 10.04 64bit Firefox 9.0.1, Ubuntu 11.10 64bit Reporter: Dom W. Assignee: Volker Weber Priority: Minor Fix For: 1.0.39 Attachments: tc-link-rendered.png Even though the rendered attribute is set to false, the tc:link is not fully hidden, i.e. it still uses up some space (a few pixels) . This creates additional empty space, which gets more and more apparent, the more hidden links you have. Example code: tc:panel f:facet name=layout tc:gridLayout rows=fixed;fixed;fixed;fixed;fixed;fixed;fixed;*/ /f:facet tc:label value=tc:link rendered/ tc:link label=Test 1 rendered=false / tc:link label=Test 2 rendered=false / tc:link label=Test 3 rendered=false / tc:link label=Test 4 rendered=true / tc:link label=Test 5 rendered=false / tc:link label=Test 6 rendered=false / tc:link label=Test 7 rendered=true / tc:link label=Test 8 rendered=true / /tc:panel Expected result: There should be as much space between the tc:label and the first visible tc:link, and also between tc:link 4 and 7, as there is between tc:link 7 and 8. Actual result: There is a big gap between the tc:label and the first visible tc:link, and also between tc:link 4 and 7. Please also see the attached image. Greetings, dom -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TOBAGO-760) target attribute in tc:menuitem should be paired with link attribute
[ https://issues.apache.org/jira/browse/TOBAGO-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13249864#comment-13249864 ] Dom W. commented on TOBAGO-760: --- Are there any news on this issue? target attribute in tc:menuitem should be paired with link attribute -- Key: TOBAGO-760 URL: https://issues.apache.org/jira/browse/TOBAGO-760 Project: MyFaces Tobago Issue Type: Improvement Affects Versions: 1.0.39 Environment: N/A for feature enhancement. For the curious: Ubuntu 9.04, Tomcat 5.5 and Tobago 1.0.20, similarly openSuSE 11.1, Tomcat 6 and Tobago 1.0.20 Reporter: Dom W. Assignee: Udo Schnurpfeil The target attribute for the tc:menuitem only works in connection with the action attribute. This has been resolved in issue: https://issues.apache.org/jira/browse/TOBAGO-286 . However, for better usability and also consistency it should be possible to make it also work when specifying the link attribute instead of the action attribute. Thank you very much for your time and consideration. Best regards, D.W. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2254) Trinidad's h:commandButton and h:commandLink renderer overrides do not specify dependency on submitForm()
[ https://issues.apache.org/jira/browse/TRINIDAD-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13250060#comment-13250060 ] Max Starets commented on TRINIDAD-2254: --- h:commandButton and h:commandLink renderers should be calling XhtmlUtils.addLib with submitForm() to ensure that the right js library is included Trinidad's h:commandButton and h:commandLink renderer overrides do not specify dependency on submitForm() - Key: TRINIDAD-2254 URL: https://issues.apache.org/jira/browse/TRINIDAD-2254 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.1-core Reporter: Max Starets Assignee: Max Starets -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TOMAHAWK-1620) Error 404 in myFacesExtensionResource
[ https://issues.apache.org/jira/browse/TOMAHAWK-1620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13247259#comment-13247259 ] Haroldo de Oliveira Pinheiro commented on TOMAHAWK-1620: Problem solved: it was a component that was extending Tomahawk's calendar that was causing the problem. Error 404 in myFacesExtensionResource - Key: TOMAHAWK-1620 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1620 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.11 Environment: JDK 1.6.0_31 Tomcat 7.0.26 Mojarra 2.1.7 tomahawk20-1.1.11 Reporter: Haroldo de Oliveira Pinheiro The MyFaces Extension is returning a 404 error whenever any Tomahawk component tries to load any resource. Through debugging, I've noticed that MyFacesResourceLoader is trying to load the resource through DefaultResourceProvider, which is, in turn, is trying to load from a subpackage 'resource' inside of the component's package. That would have worked OK on previous versions of Tomahawk, in which the resources followed that convention; in this version, though, all resources are inside META-INF, therefore preventing the resources from being found by MyFacesResourceLoader in the way it's programmed now. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3522) collectionType attribute of selectManyCheckbox not processed correctly
[ https://issues.apache.org/jira/browse/MYFACES-3522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13246165#comment-13246165 ] Michael Heinen commented on MYFACES-3522: - Thanks for the quick fix Leonardo!!! Is it fixed for myfaces and for tomahawk selectManyCheckbox? I just saw two checkins for trunk and branch 2.0 but there are two different _SharedRendererUtils implementation, or? javax.faces.component._SharedRendererUtils and org.apache.myfaces.shared_tomahawk.renderkit_SharedRendererUtils collectionType attribute of selectManyCheckbox not processed correctly -- Key: MYFACES-3522 URL: https://issues.apache.org/jira/browse/MYFACES-3522 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.6 Environment: Tomcat 6.0.35 myFaces 2.1.6 Reporter: Michael Heinen Assignee: Leonardo Uribe Priority: Critical Fix For: 2.0.13, 2.1.7 Attachments: z.war The collectionType attribute of h:selectManyCheckbox is not processed correctly. The value attribute of selectManyCheckbox points to a Map with an ArrayList containing Strings as values, representing the selected values. The checkboxes are initially correctly checked, but after ajax submission the model (MapSting,Object) contains StringArrays instead of ArrayLists. This worked well since JSF 1.0, but it does not work with 2.1 anymore. It can be easily reproduced with MyFaces only. I see this as critical because ClassCastException are thrown as a result in application code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTSCRIPT-107) CDI Integration
[ https://issues.apache.org/jira/browse/EXTSCRIPT-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13246181#comment-13246181 ] Werner Punz commented on EXTSCRIPT-107: --- The GSOC Project has reached ists goal and this is satisfactory, but the problem is, that it cannot deal with custom scopes and only works with owb and its integrated scopes. The better bet after consulting the owb people is, to simply restart the container at changes. We do not get the fine grained granularity as with jsf beans but this is a neutral way which in the long run also will work with Weld. CDI Integration --- Key: EXTSCRIPT-107 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-107 Project: MyFaces Extensions Scripting Issue Type: Improvement Reporter: Werner Punz Assignee: Werner Punz Labels: gsoc, mentor Ext-Scripting is an extension framework for the Apache MyFaces project, its goal is to provide scripting language support and dynamic recompilation and reloading (hotplugging) within JSF. The long term goal of Ext-Scripting is to have support for most major frameworks which have hooks into Ext-Scripting. The near term goal is Spring and CDI. While spring support is being worked for in the inofficial 1.1 branch, CDI is an open issue, which might be resolvable in the GSOC 2010. The goal would be to support both implementations within our Ext-Scripting infrastructure. Following goals have to be reached: a) Determine which extension points in the implementations can be used to hook ext-scripting in, and provide a prototype for a simple reload of a single class within those extensions (by using a throw away classloader, but without recompile) b) Provide a neutral easy to use APIs for framework extensions (that would be a separate issue outside of what should be done within GSOC since it has to be done before summer) for 1.1 c) Implement one of those extensions for at least one implemtation, if time allows for both -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTSCRIPT-107) CDI Integration
[ https://issues.apache.org/jira/browse/EXTSCRIPT-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13246183#comment-13246183 ] Werner Punz commented on EXTSCRIPT-107: --- Problem is also while delta spike already has a vendor neutral api to kick the container through, the api has been done only for testcases. So we have to roll our own api until delta spike has added its own. CDI Integration --- Key: EXTSCRIPT-107 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-107 Project: MyFaces Extensions Scripting Issue Type: Improvement Reporter: Werner Punz Assignee: Werner Punz Labels: gsoc, mentor Ext-Scripting is an extension framework for the Apache MyFaces project, its goal is to provide scripting language support and dynamic recompilation and reloading (hotplugging) within JSF. The long term goal of Ext-Scripting is to have support for most major frameworks which have hooks into Ext-Scripting. The near term goal is Spring and CDI. While spring support is being worked for in the inofficial 1.1 branch, CDI is an open issue, which might be resolvable in the GSOC 2010. The goal would be to support both implementations within our Ext-Scripting infrastructure. Following goals have to be reached: a) Determine which extension points in the implementations can be used to hook ext-scripting in, and provide a prototype for a simple reload of a single class within those extensions (by using a throw away classloader, but without recompile) b) Provide a neutral easy to use APIs for framework extensions (that would be a separate issue outside of what should be done within GSOC since it has to be done before summer) for 1.1 c) Implement one of those extensions for at least one implemtation, if time allows for both -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-1904) Exception encoding selectOneMenu when value has an intermediate node null
[
https://issues.apache.org/jira/browse/MYFACES-1904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13246241#comment-13246241
]
Julien Houllier commented on MYFACES-1904:
--
Hi,
I work on a Myfaces JSF 1.1 + TomaHawk + Struts Tiles 1 + Ajax4JSFapplication,
but since Firefox 11 ajax4JSF rendered bad thing at refresh so we decide to
migrate to MyFaces 1.2 (1.2.11)+ TomaHawk + Tiles 2 + RichFaces 3.3,
After long hours to make it work, some screen generates
org.apache.jasper.el.JspPropertyNotFoundException, because of this issue.
I hardly understand why after 4 years a Major issue, which would take few times
to patch, is still open
Any reason ?
I will have to make an empty StringConverter just to be sure my Application
work.
Exception encoding selectOneMenu when value has an intermediate node null
-
Key: MYFACES-1904
URL: https://issues.apache.org/jira/browse/MYFACES-1904
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.3
Environment: geronimo 2.1.2
Reporter: Antoni Reus
I have a managed bean called treeManager, with a selectedNode property
that is null the first time.
I have three input components: 2 inputText, and a selectOneMenu, the JSP code
is this:
...
h:outputLabel for=nodeName value=Nom/
h:inputText id=nodeName value=#{treeManager.selectedNode.name} /
h:outputLabel for=nodeDescription value=Descripció/
h:inputText id=nodeDescription
value=#{treeManager.selectedNode.description} /
h:outputLabel for=ambitType value=Àmbit/
h:selectOneMenu id=ambitType value=#{treeManager.selectedNode.ambit}
f:selectItem itemLabel=Global itemValue=global/
f:selectItem itemLabel=Organisme itemValue=organisme/
f:selectItem itemLabel=Procediment itemValue=procediment/
/h:selectOneMenu
When I try the JSF I get this error.
|javax.faces.FacesException: Exception while calling encodeEnd on component :
{Component-Path : [Class: org.ajax4jsf.component.AjaxViewRoot,ViewId:
/dissenyador/estructures.jsp][Class:
javax.faces.component.html.HtmlPanelGrid,Id: j_id_jsp_305935947_1]}|
| at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:610)|
Caused by: ...
|Caused by: org.apache.jasper.el.JspPropertyNotFoundException:
/dissenyador/estructures.jsp(60,8) '#{treeManager.selectedNode.ambit}' Target
Unreachable, 'selectedNode' returned null|
| at
org.apache.jasper.el.JspValueExpression.getType(JspValueExpression.java:61)|
| at
org.apache.myfaces.shared_impl.renderkit._SharedRendererUtils.findUIOutputConverter(_SharedRendererUtils.java:58)|
| at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.findUIOutputConverter(RendererUtils.java:391)|
| at
org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils.findUIOutputConverterFailSafe(HtmlRendererUtils.java:393)|
| at
org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils.internalRenderSelect(HtmlRendererUtils.java:316)|
| at
org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils.renderMenu(HtmlRendererUtils.java:288)|
| at
org.apache.myfaces.shared_impl.renderkit.html.HtmlMenuRendererBase.encodeEnd(HtmlMenuRendererBase.java:57)|
| at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:607)|
Comments from Simon Kitching on the mailing list:
Interesting. From the stacktrace it look like the problem is when trying
to determine the *type* that this expression returns.
When actually asking for the value, null is simply returned if the
intermediate object is not there.
But when asking what static type of object would be returned from the
bound property, of course there is a real problem if the intermediate
node is not there.
Here's the code from SharedRendererUtils.findUIOutputConverter; the
getType call is the problem:
Class valueType = vb.getType(facesContext); // boom when an
intermediate node in the EL is null
if (valueType == null) return null;
if (String.class.equals(valueType)) return null;//No
converter needed for String type
if (Object.class.equals(valueType)) return null;//There is
no converter for Object class
The HtmlRendererUtils.internalRenderSelect uses
converter = findUIOutputConverterFailSafe
-- which obviously is not quite so fail safe :-)
I'm not quite sure what the converter is being used for during rendering
of the select component, but I do know that the rules about converters
and select-components are quite complex. The HTML select component must
always render strings for its options, but JSF requires typed objects to
be passed between the select *component* and the backing beans. So
conversions are required to be invoked at various times.
I think a JIRA issues should
[jira] [Commented] (MYFACES-3521) javax.faces.ViewState is not updated after ajaxResponse
[
https://issues.apache.org/jira/browse/MYFACES-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245256#comment-13245256
]
Werner Punz commented on MYFACES-3521:
--
!--
(!window.myfaces) ? window.myfaces = {} : null;(!myfaces.core) ? myfaces.core =
{} : null;(!myfaces.core.config) ? myfaces.core.config = {} :
null;myfaces.core.config.autoScroll = true;
//--
This code is evil, you first reset window.myfaces to {} and by that you
eliminate everything already set including the entire ajax impl namespace.
Leave the entire autoscroll stuff out, it does not do anything anyway.
javax.faces.ViewState is not updated after ajaxResponse
---
Key: MYFACES-3521
URL: https://issues.apache.org/jira/browse/MYFACES-3521
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.1.6
Environment: all
Reporter: wojtask
click 2x times on link
h:form
script
var x= new String(a)
/script
script
(1==3)? 'd':'e';
/script
h:commandLink value=link
f:ajax render=@form/
/h:commandLink
/h:form
I'm not sure that is bug but works in jsf-ri.
In real scenario problem occurs for example if AUTO_SCROLL in contex-param is
set to true and rich:tooltip is used.
Rendered HTML markup:
script
!--
new RichFaces.ui.Tooltip(j_id_v:j_id_3y,{ajax:{incId:1}
,target:j_id_v:j_id_3y,offset:[10,10] } )
//--
/script
script
!--
(!window.myfaces) ? window.myfaces = {} : null;(!myfaces.core) ? myfaces.core
= {} : null;(!myfaces.core.config) ? myfaces.core.config = {} :
null;myfaces.core.config.autoScroll = true;
//--
/script
see
https://issues.jboss.org/browse/RF-12130
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3521) javax.faces.ViewState is not updated after ajaxResponse
[
https://issues.apache.org/jira/browse/MYFACES-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245255#comment-13245255
]
Werner Punz commented on MYFACES-3521:
--
!--
(!window.myfaces) ? window.myfaces = {} : null;(!myfaces.core) ? myfaces.core =
{} : null;(!myfaces.core.config) ? myfaces.core.config = {} :
null;myfaces.core.config.autoScroll = true;
//--
This code is evil, you first reset window.myfaces to {} and by that you
eliminate everything already set including the entire ajax impl namespace.
Leave the entire autoscroll stuff out, it does not do anything anyway.
javax.faces.ViewState is not updated after ajaxResponse
---
Key: MYFACES-3521
URL: https://issues.apache.org/jira/browse/MYFACES-3521
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.1.6
Environment: all
Reporter: wojtask
click 2x times on link
h:form
script
var x= new String(a)
/script
script
(1==3)? 'd':'e';
/script
h:commandLink value=link
f:ajax render=@form/
/h:commandLink
/h:form
I'm not sure that is bug but works in jsf-ri.
In real scenario problem occurs for example if AUTO_SCROLL in contex-param is
set to true and rich:tooltip is used.
Rendered HTML markup:
script
!--
new RichFaces.ui.Tooltip(j_id_v:j_id_3y,{ajax:{incId:1}
,target:j_id_v:j_id_3y,offset:[10,10] } )
//--
/script
script
!--
(!window.myfaces) ? window.myfaces = {} : null;(!myfaces.core) ? myfaces.core
= {} : null;(!myfaces.core.config) ? myfaces.core.config = {} :
null;myfaces.core.config.autoScroll = true;
//--
/script
see
https://issues.jboss.org/browse/RF-12130
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3521) javax.faces.ViewState is not updated after ajaxResponse
[
https://issues.apache.org/jira/browse/MYFACES-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245299#comment-13245299
]
Werner Punz commented on MYFACES-3521:
--
Ok now it is clear... semi clear at least, the javascript error probably causes
globaleval to fail and then it bombs out of the response cycle prematurely
which means that the response processing is aborted, due to the syntax, error,
this should not happen, lets see what I can do :-)
javax.faces.ViewState is not updated after ajaxResponse
---
Key: MYFACES-3521
URL: https://issues.apache.org/jira/browse/MYFACES-3521
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.1.6
Environment: all
Reporter: wojtask
Attachments: test_js.rar
click 2x times on link
h:form
script
var x= new String(a)
/script
script
(1==3)? 'd':'e';
/script
h:commandLink value=link
f:ajax render=@form/
/h:commandLink
/h:form
I'm not sure that is bug but works in jsf-ri.
In real scenario problem occurs for example if AUTO_SCROLL in contex-param is
set to true and rich:tooltip is used.
Rendered HTML markup:
script
!--
new RichFaces.ui.Tooltip(j_id_v:j_id_3y,{ajax:{incId:1}
,target:j_id_v:j_id_3y,offset:[10,10] } )
//--
/script
script
!--
(!window.myfaces) ? window.myfaces = {} : null;(!myfaces.core) ? myfaces.core
= {} : null;(!myfaces.core.config) ? myfaces.core.config = {} :
null;myfaces.core.config.autoScroll = true;
//--
/script
see
https://issues.jboss.org/browse/RF-12130
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3513) Invalid chaining of client behavior scripts when using both, explicitly provided event and default event
[
https://issues.apache.org/jira/browse/MYFACES-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244033#comment-13244033
]
Lukas Fryc commented on MYFACES-3513:
-
Thanks for the prompt fix, Leonard!
Invalid chaining of client behavior scripts when using both, explicitly
provided event and default event
Key: MYFACES-3513
URL: https://issues.apache.org/jira/browse/MYFACES-3513
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.5
Reporter: Lukas Fryc
Assignee: Leonardo Uribe
Fix For: 2.0.13, 2.1.7
When two client behaviors are provided and one uses default event while
second has event provided
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:f=http://java.sun.com/jsf/core; xmlns:h=http://java.sun.com/jsf/html;
xmlns:fryc=http://fryc.eu/behavior;
h:body
h:inputText
f:ajax event=change /
fryc:behavior1 /
/h:inputText
/h:body
/html
these scripts are chained wrong:
input id=j_id_3 name=j_id_3 type=text value=
onchange=jsf.util.chain(document.getElementById('j_id_3'),
event,'jsf.ajax.request(\'j_id_3\',event,{\'javax.faces.behavior.event\':\'change\'})''alert(\'xyz\')');
return false; /
Note there is no space between quotes before alert: ...''alert(\'xyz\')');
return false; /
-
There is source code for additional behavior:
@FacesBehavior(eu.fryc.Behavior1)
public class Behavior1 extends ClientBehaviorBase {
@Override
public String getScript(ClientBehaviorContext behaviorContext) {
return alert('xyz');
}
}
facelet-taglib xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-facelettaglibrary_2_0.xsd;
version=2.0
namespacehttp://fryc.eu/behavior/namespace
tag
tag-namebehavior1/tag-name
behavior
behavior-ideu.fryc.Behavior1/behavior-id
/behavior
/tag
/facelet-taglib
-
Note that if you provide events explicitly for both behaviors (or not provide
events at all), chaining works as expected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-195) Two requests at the same time throw an exception when the server just started
[ https://issues.apache.org/jira/browse/TRINIDAD-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13242148#comment-13242148 ] Pae Choi commented on TRINIDAD-195: --- I looked at the SVN, but could not identify the branch for trinidad-1.2.15-core that has this patch. The branches I looked at are: http://svn.apache.org/viewvc/myfaces/trinidad/branches/ http://svn.apache.org/viewvc/myfaces/trinidad/tags/ Where is that branch for this patch? Thank you. Regards, Pae P.S.: Any plan to release the 1.2.15 in near future? Two requests at the same time throw an exception when the server just started - Key: TRINIDAD-195 URL: https://issues.apache.org/jira/browse/TRINIDAD-195 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.14-core , 2.0.0-core Environment: Running OC4J as App server Reporter: Chris Eidhof Assignee: Scott O'Bryan Priority: Minor Fix For: 1.2.15-core , 2.0.1-core 1. Stop your current server 2. Run a page. Make sure to do two request a the same time the first time you request a page from the server 3. See the error message: 500 Internal Server Error java.lang.IllegalStateException: Factory already available for this class loader. at org.apache.myfaces.trinidad.context.RequestContextFactory.setFactory(RequestContextFactory.java:53) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.init(GlobalConfiguratorImpl.java:376) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:213) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:124) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at com.evermind[Oracle Containers for J2EE 10g (11.1.1.0.0) ].server.http.EvermindFilterChain.doFilter(EvermindFilterChain.java:15) at oracle.adfdemo.view.webapp.rich.RedirectFilter.doFilter(RedirectFilter.java:84) at com.evermind[Oracle Containers for J2EE 10g (11.1.1.0.0) ].server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:617) at com.evermind[Oracle Containers for J2EE 10g (11.1.1.0.0) ].server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:368) at com.evermind[Oracle Containers for J2EE 10g (11.1.1.0.0) ].server.http.HttpRequestHandler.doDispatchRequest(HttpRequestHandler.java:882) at com.evermind[Oracle Containers for J2EE 10g (11.1.1.0.0) ].server.http.HttpRequestHandler.doProcessRequest(HttpRequestHandler.java:790) at com.evermind[Oracle Containers for J2EE 10g (11.1.1.0.0) ].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:600) at com.evermind[Oracle Containers for J2EE 10g (11.1.1.0.0) ].server.http.HttpRequestHandler.serveOneRequest(HttpRequestHandler.java:369) at com.evermind[Oracle Containers for J2EE 10g (11.1.1.0.0) ].server.http.HttpRequestHandler.run(HttpRequestHandler.java:160) at com.evermind[Oracle Containers for J2EE 10g (11.1.1.0.0) ].server.http.HttpRequestHandler.run(HttpRequestHandler.java:141) at oracle.oc4j.network.ServerSocketReadHandler$ClientRunnable.run(ServerSocketReadHandler.java:275) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:613) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3518) Datatable (h:dataTable) is not populated with data despite getAll() method returns ResultSet with table rows ( Using Tomcat 7 + MySQL 5.5 + mysql-connector-java-5.1.1
[
https://issues.apache.org/jira/browse/MYFACES-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13242208#comment-13242208
]
Sagi Kovaliov commented on MYFACES-3518:
Thank you Leonardo, is there any workaround I can implement in my code in order
to get DataTable with data ?
Thanks
Sagi
Datatable (h:dataTable) is not populated with data despite getAll() method
returns ResultSet with table rows ( Using Tomcat 7 + MySQL 5.5 +
mysql-connector-java-5.1.18 )
-
Key: MYFACES-3518
URL: https://issues.apache.org/jira/browse/MYFACES-3518
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.1.6
Environment: Windows 7 64bit
Tomcat 7.0.26
myfaces-2.1.6
JRE 6
MySQL 5.5
mysql-connector-java-5.1.18
Reporter: Sagi Kovaliov
Assignee: Leonardo Uribe
Fix For: 1.1.10, 1.2.12, 2.0.13, 2.1.7
Hello, when I use the following BeanClass and xhtml page, Datatable is not
populated with data, despite the method getAll() returns ResultSet that
contains customer names.
Code line System.out.println(crs.getString(Name)) iterates through the
ResultSet and prints customer names from customer table before the ResultSet
is being returned to h:dataTable component. This is what I get in Tomcat log:
..
***
*** WARNING: Apache MyFaces-2 is running in DEVELOPMENT mode. ***
*** ^^^ ***
*** Do NOT deploy to your live server(s) without changing this. ***
*** See Application#getProjectStage() for more information. ***
***
29/03/2012 22:19:57 org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler [http-bio-8080]
29/03/2012 22:19:57 org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler [ajp-bio-8009]
29/03/2012 22:19:57 org.apache.catalina.startup.Catalina start
INFO: Server startup in 4706 ms
29/03/2012 22:19:58 org.apache.myfaces.util.ExternalSpecifications
isUnifiedELAvailable
INFO: MyFaces Unified EL support enabled
Start of Debug
William Dupont
William Dupont
End of Debug
This is the ManagedBean:
package com.corejsf;
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import javax.annotation.Resource;
import javax.faces.bean.*;
import javax.sql.DataSource;
import javax.sql.rowset.CachedRowSet;
@ManagedBean
@RequestScoped
public class CustomerBean {
@Resource(name=jdbc/Sufa) private DataSource ds;
public ResultSet getAll() throws SQLException {
Connection conn = ds.getConnection();
try {
Statement stmt = conn.createStatement();
ResultSet result = stmt.executeQuery(SELECT * FROM customers);
CachedRowSet crs = new com.sun.rowset.CachedRowSetImpl();
crs.populate(result);
System.out.println(Start of Debug);
while(crs.next()) {
System.out.println(crs.getString(Name));
}
System.out.println(End of Debug);
return crs;
} finally {
conn.close();
}
}
}
This is xhtml page:
?xml version=1.0 encoding=UTF-8?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:ui=http://java.sun.com/jsf/facelets;
h:body
h:form
h:dataTable value=#{customerBean.all} var=customer
h:column
f:facet name=header#{msgs.nameHeader}/f:facet
#{customer.Name}
/h:column
/h:dataTable
/h:form
/h:body
/html
It's important to mention that the same code works perfect when I change JSF
implementation to mojarra-2.1.7.
It's seems like a bug.
Thanks a lot
Sagi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3519) Could not load Javascript-Sources in 'Package' org.apache.myfaces.core.impl.xhrCore.engine
[
https://issues.apache.org/jira/browse/MYFACES-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13242504#comment-13242504
]
Leonardo Uribe commented on MYFACES-3519:
-
I checked and there are some small bugs there, due to some important changes.
This bug only can be seen when this param is set:
context-param
param-nameorg.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS/param-name
param-valuetrue/param-value
/context-param
Fortunately, the solution is simple, just fix the paths to:
_ls(#{resource['org.apache.myfaces.core.impl.xhrCore:engine/XhrConst.js']},
null, null, UTF-8, false);
_ls(#{resource['org.apache.myfaces.core.impl.xhrCore:engine/FormData.js']},
null, null, UTF-8, false);
_ls(#{resource['org.apache.myfaces.core.impl.xhrCore:engine/BaseRequest.js']},
null, null, UTF-8, false);
_ls(#{resource['org.apache.myfaces.core.impl.xhrCore:engine/Xhr1.js']},
null, null, UTF-8, false);
_ls(#{resource['org.apache.myfaces.core.impl.xhrCore:engine/IFrame.js']},
null, null, UTF-8, false);
And add two js files (_DomExperimental.js and _ExtTransport.js) that are
included on the normal version.
Could not load Javascript-Sources in 'Package'
org.apache.myfaces.core.impl.xhrCore.engine
--
Key: MYFACES-3519
URL: https://issues.apache.org/jira/browse/MYFACES-3519
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Reporter: dennis hoersch
Assignee: Leonardo Uribe
Hi,
I am testing MyFaces 2.1.6 with ProjectStage=Development. And I have an
Javascript-error: Firefox showes me that 'myfaces.core.impl.xhrCore.engine'
is undefined. After looking around I found that the jsf-uncompressed.js loads
some libraries, i.e.:
_ls(#{resource['org.apache.myfaces.core.impl.xhrCore.engine:XhrConst.js']},
null, null, UTF-8, false);
_ls(#{resource['org.apache.myfaces.core.impl.xhrCore.engine:FormData.js']},
null, null, UTF-8, false);
_ls(#{resource['org.apache.myfaces.core.impl.xhrCore.engine:Xhr1.js']},
null, null, UTF-8, false);
_ls(#{resource['org.apache.myfaces.core.impl.xhrCore.engine:IFrame.js']},
null, null, UTF-8, false);
The replaced JS in Firefox for these entries looks like the following:
_ls(, null, null, UTF-8, false);
The resources are packaged under:
META-INF/internal-resources/org.apache.myfaces.core.impl.xhrCore/engine
The ResourceLoader expects them to be in:
META-INF/internal-resources/org.apache.myfaces.core.impl.xhrCore.engine
After changing it in my local myfaces-jar all libraries could be loaded.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3519) Could not load Javascript-Sources in 'Package' org.apache.myfaces.core.impl.xhrCore.engine
[
https://issues.apache.org/jira/browse/MYFACES-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13242518#comment-13242518
]
dennis hoersch commented on MYFACES-3519:
-
OK, thank you, I wasn't sure if it is a bug :-)
Could not load Javascript-Sources in 'Package'
org.apache.myfaces.core.impl.xhrCore.engine
--
Key: MYFACES-3519
URL: https://issues.apache.org/jira/browse/MYFACES-3519
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Reporter: dennis hoersch
Assignee: Leonardo Uribe
Fix For: 2.0.13, 2.1.7
Hi,
I am testing MyFaces 2.1.6 with ProjectStage=Development. And I have an
Javascript-error: Firefox showes me that 'myfaces.core.impl.xhrCore.engine'
is undefined. After looking around I found that the jsf-uncompressed.js loads
some libraries, i.e.:
_ls(#{resource['org.apache.myfaces.core.impl.xhrCore.engine:XhrConst.js']},
null, null, UTF-8, false);
_ls(#{resource['org.apache.myfaces.core.impl.xhrCore.engine:FormData.js']},
null, null, UTF-8, false);
_ls(#{resource['org.apache.myfaces.core.impl.xhrCore.engine:Xhr1.js']},
null, null, UTF-8, false);
_ls(#{resource['org.apache.myfaces.core.impl.xhrCore.engine:IFrame.js']},
null, null, UTF-8, false);
The replaced JS in Firefox for these entries looks like the following:
_ls(, null, null, UTF-8, false);
The resources are packaged under:
META-INF/internal-resources/org.apache.myfaces.core.impl.xhrCore/engine
The ResourceLoader expects them to be in:
META-INF/internal-resources/org.apache.myfaces.core.impl.xhrCore.engine
After changing it in my local myfaces-jar all libraries could be loaded.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3514) cc:insertChildren must relocate user tag handlers other tags that contains markup too
[ https://issues.apache.org/jira/browse/MYFACES-3514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241044#comment-13241044 ] dennis hoersch commented on MYFACES-3514: - I'm not shure, but at the first look: CompositeComponentResourceTagHandler line 229, has ist to be 'nextHandler'? Or 'handler'? cc:insertChildren must relocate user tag handlers other tags that contains markup too - Key: MYFACES-3514 URL: https://issues.apache.org/jira/browse/MYFACES-3514 Project: MyFaces Core Issue Type: Bug Environment: MyFaces 2.1.6, Tomahawk20 1.1.11 Reporter: dennis hoersch Assignee: Leonardo Uribe Fix For: 2.0.13, 2.1.7 Hello, I just copied the emails of the problem that not all children of composite components will be rendered out of the dev-list in here. -- Hi Leonardo, that was my first attempt too. But as I mentioned earlier, we have also own TagHandlers (no UserTagHandlers, they extends TagHandler) - that ones will be still ignored... Maybe there can be a special marker interface? So that the 'list' is more dynamically? (But I am not very glad with this solution if anyone having own tag handlers must do a special thing to get them work with composite components (?)...) Greetings, dennis Hi Dennis I have checked the code and I think we can consider all UserTagHandler instances as containers of components (just like DecorateHandler and IncludeHandler). That means if cc:insertChildren is used, all instances of UserTagHandler should be executed in the place when cc:insertChildren is called. So we just need to increase the list to: - javax.faces.view.facelets.ComponentHandler.class - InsertChildrenHandler.class - InsertHandler.class - DecorateHandler.class - IncludeHandler.class - TextHandler.class - UserHagHandler.class After looking carefully this issue, it seems we need to include c:if and c:choose too. Could you please create an issue for this one in https://issues.apache.org/jira/browse/MYFACES so I can fix it? regards, Leonardo 2012/3/27 Dennis Hörsch hoer...@his.de: Hi, I was expecting that composite components behave like any other. I am currently updating a big project from JSF1 to 2. We have many usages of JSTL as 'child'-components. And our 'old-fashioned' facelets components now are UserTagHandlers in the end. This ones will also be ignored... I had a look an at CompositeComponentResourceTagHandler and changed it in the way that 'newly' added childs are stored and will later be added to the right component. My simple test scenario works, but I have no clue about Partial State Saving and if there are any other cases that may be affected. I attached it, can you have a look? Thank you, dennis hoersch Am 26.03.2012 22:42, schrieb Leonardo Uribe: Hi Difficult question. You should avoid that trick, or at least use c:if inside you custom tag to make it work properly. Really there are some details that will not work as expected. First of all, c:if code has changed since the original code inside facelets, to ensure proper operation with JSF 2.0 Partial State Saving. It is very complex to explain, but in resume, no component like c:if can be created without rely in some implementation details. The second part is composite component algorithm cannot recognize the tag as a tag containing component instances, so if the composite component uses cc:insertChildren, the part related to the tag will not be applied correctly. The solution in this case is use a composite component or a normal component instead a facelets user tag. Anyway, maybe we can do something better in this part ( org.apache.myfaces.view.facelets.tag.composite.CompositeComponentResourceTagHandler), and try to detect better cases like the one described here. regards, Leonardo Uribe 2012/3/26 Dennis Hörsch hoer...@his.de: Hey, I have a problem with composite components. The scenario is as follows: his:someCompositeComponent id=outer h:inputText id=first ... / his:someTagHandlerTag condition=bla h:inputText is=second ... / /his:someTagHandlerTag /his:someCompositeComponent The problem is, only the first input field is rendered. The second is not. After building the component tree, the first is a child of the 'composite component'-facet of the surrounding UINamingContainer (outer), the second ends as child of the UINamingContainer. The 'HtmlCompositeComponentRenderer' renders only the children of the facet. The 'someTagHandlerTag' is handled by a subclass of TagHandler. If the condition is true, it calls the nextHandler (second-input field) which adds the input
[jira] [Commented] (TOMAHAWK-1616) RendererUtils not in sync with latest MyFaces
[ https://issues.apache.org/jira/browse/TOMAHAWK-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241093#comment-13241093 ] Mathias Werlitz commented on TOMAHAWK-1616: --- This is a serious bug and should have a higher priority. It does not only apply to ui:fragment and sould be fixed as soon as possible. RendererUtils not in sync with latest MyFaces - Key: TOMAHAWK-1616 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1616 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.11 Reporter: Jarek Priority: Minor I've noticed that the bug https://issues.apache.org/jira/browse/MYFACES-3146 (problem with ui:fragment) which has already been fixed in newest MyFaces, is still present when Tomahawk is used. Quick debug showed that in the Tomahawk version RendererUtils.renderChild does not contain the first if (isRendered) check - MyFaces version has it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3514) cc:insertChildren must relocate user tag handlers other tags that contains markup too
[ https://issues.apache.org/jira/browse/MYFACES-3514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241200#comment-13241200 ] Leonardo Uribe commented on MYFACES-3514: - Yes, you're right. I was supposing the junit test would catch any bug. I committed the fix. Thanks for your attention in the details. It helps a lot. cc:insertChildren must relocate user tag handlers other tags that contains markup too - Key: MYFACES-3514 URL: https://issues.apache.org/jira/browse/MYFACES-3514 Project: MyFaces Core Issue Type: Bug Environment: MyFaces 2.1.6, Tomahawk20 1.1.11 Reporter: dennis hoersch Assignee: Leonardo Uribe Fix For: 2.0.13, 2.1.7 Hello, I just copied the emails of the problem that not all children of composite components will be rendered out of the dev-list in here. -- Hi Leonardo, that was my first attempt too. But as I mentioned earlier, we have also own TagHandlers (no UserTagHandlers, they extends TagHandler) - that ones will be still ignored... Maybe there can be a special marker interface? So that the 'list' is more dynamically? (But I am not very glad with this solution if anyone having own tag handlers must do a special thing to get them work with composite components (?)...) Greetings, dennis Hi Dennis I have checked the code and I think we can consider all UserTagHandler instances as containers of components (just like DecorateHandler and IncludeHandler). That means if cc:insertChildren is used, all instances of UserTagHandler should be executed in the place when cc:insertChildren is called. So we just need to increase the list to: - javax.faces.view.facelets.ComponentHandler.class - InsertChildrenHandler.class - InsertHandler.class - DecorateHandler.class - IncludeHandler.class - TextHandler.class - UserHagHandler.class After looking carefully this issue, it seems we need to include c:if and c:choose too. Could you please create an issue for this one in https://issues.apache.org/jira/browse/MYFACES so I can fix it? regards, Leonardo 2012/3/27 Dennis Hörsch hoer...@his.de: Hi, I was expecting that composite components behave like any other. I am currently updating a big project from JSF1 to 2. We have many usages of JSTL as 'child'-components. And our 'old-fashioned' facelets components now are UserTagHandlers in the end. This ones will also be ignored... I had a look an at CompositeComponentResourceTagHandler and changed it in the way that 'newly' added childs are stored and will later be added to the right component. My simple test scenario works, but I have no clue about Partial State Saving and if there are any other cases that may be affected. I attached it, can you have a look? Thank you, dennis hoersch Am 26.03.2012 22:42, schrieb Leonardo Uribe: Hi Difficult question. You should avoid that trick, or at least use c:if inside you custom tag to make it work properly. Really there are some details that will not work as expected. First of all, c:if code has changed since the original code inside facelets, to ensure proper operation with JSF 2.0 Partial State Saving. It is very complex to explain, but in resume, no component like c:if can be created without rely in some implementation details. The second part is composite component algorithm cannot recognize the tag as a tag containing component instances, so if the composite component uses cc:insertChildren, the part related to the tag will not be applied correctly. The solution in this case is use a composite component or a normal component instead a facelets user tag. Anyway, maybe we can do something better in this part ( org.apache.myfaces.view.facelets.tag.composite.CompositeComponentResourceTagHandler), and try to detect better cases like the one described here. regards, Leonardo Uribe 2012/3/26 Dennis Hörsch hoer...@his.de: Hey, I have a problem with composite components. The scenario is as follows: his:someCompositeComponent id=outer h:inputText id=first ... / his:someTagHandlerTag condition=bla h:inputText is=second ... / /his:someTagHandlerTag /his:someCompositeComponent The problem is, only the first input field is rendered. The second is not. After building the component tree, the first is a child of the 'composite component'-facet of the surrounding UINamingContainer (outer), the second ends as child of the UINamingContainer. The 'HtmlCompositeComponentRenderer' renders only the children of the facet. The 'someTagHandlerTag' is handled by a subclass of TagHandler. If the condition is true, it calls the nextHandler (second-input field
[jira] [Commented] (MYFACES-3517) ui:fragment ignores rendered attribute if nested in t:div
[ https://issues.apache.org/jira/browse/MYFACES-3517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241205#comment-13241205 ] Patrick Schmidt commented on MYFACES-3517: -- Attached a sample eclipse project ui:fragment ignores rendered attribute if nested in t:div - Key: MYFACES-3517 URL: https://issues.apache.org/jira/browse/MYFACES-3517 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.6 Environment: MyFaces 2.1.6, Tomahawk 1.1.11, Tomcat 6.0.32 Reporter: Patrick Schmidt Attachments: myfaces-blank.zip When nested inside a t:div, the rendered attribute of ui:fragment ist ignored. This seems to be similar to MYFACES-3239, which was fixed in 2.1.2. Example: t:div ui:fragment rendered=false h:outputText value=This text should not appear / /ui:fragment /t:div -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3518) Datatable (h:dataTable) is not populated with data despite getAll() method returns ResultSet with table rows ( Using Tomcat 7 + MySQL 5.5 + mysql-connector-java-5.1.1
[
https://issues.apache.org/jira/browse/MYFACES-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241985#comment-13241985
]
Leonardo Uribe commented on MYFACES-3518:
-
I checked the code and I finally found the problem. Since 1.1, myfaces
DataModel classes assume rowCount is always defined. Recently, in MYFACES-3270,
I found on the spec that rowCount can be -1, but that only means the model
doesn't know how many rows are. ResultSetDataModel returns in getRowCount() by
default -1.
In MyFaces 1.1.3, a change was done in h:dataTable renderer to include
newspaper mode in tomahawk. For such mode, get the rowCount is critical,
because otherwise there is no way to calculate the newspaper rows and newspaper
columns.
The solution is add some code to iterate when getRowCount() returns -1.
This issue will be fixed on 1.1.x, 1.2.x, 2.0.x and 2.1.x branches.
Datatable (h:dataTable) is not populated with data despite getAll() method
returns ResultSet with table rows ( Using Tomcat 7 + MySQL 5.5 +
mysql-connector-java-5.1.18 )
-
Key: MYFACES-3518
URL: https://issues.apache.org/jira/browse/MYFACES-3518
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.1.6
Environment: Windows 7 64bit
Tomcat 7.0.26
myfaces-2.1.6
JRE 6
MySQL 5.5
mysql-connector-java-5.1.18
Reporter: Sagi Kovaliov
Hello, when I use the following BeanClass and xhtml page, Datatable is not
populated with data, despite the method getAll() returns ResultSet that
contains customer names.
Code line System.out.println(crs.getString(Name)) iterates through the
ResultSet and prints customer names from customer table before the ResultSet
is being returned to h:dataTable component. This is what I get in Tomcat log:
..
***
*** WARNING: Apache MyFaces-2 is running in DEVELOPMENT mode. ***
*** ^^^ ***
*** Do NOT deploy to your live server(s) without changing this. ***
*** See Application#getProjectStage() for more information. ***
***
29/03/2012 22:19:57 org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler [http-bio-8080]
29/03/2012 22:19:57 org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler [ajp-bio-8009]
29/03/2012 22:19:57 org.apache.catalina.startup.Catalina start
INFO: Server startup in 4706 ms
29/03/2012 22:19:58 org.apache.myfaces.util.ExternalSpecifications
isUnifiedELAvailable
INFO: MyFaces Unified EL support enabled
Start of Debug
William Dupont
William Dupont
End of Debug
This is the ManagedBean:
package com.corejsf;
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import javax.annotation.Resource;
import javax.faces.bean.*;
import javax.sql.DataSource;
import javax.sql.rowset.CachedRowSet;
@ManagedBean
@RequestScoped
public class CustomerBean {
@Resource(name=jdbc/Sufa) private DataSource ds;
public ResultSet getAll() throws SQLException {
Connection conn = ds.getConnection();
try {
Statement stmt = conn.createStatement();
ResultSet result = stmt.executeQuery(SELECT * FROM customers);
CachedRowSet crs = new com.sun.rowset.CachedRowSetImpl();
crs.populate(result);
System.out.println(Start of Debug);
while(crs.next()) {
System.out.println(crs.getString(Name));
}
System.out.println(End of Debug);
return crs;
} finally {
conn.close();
}
}
}
This is xhtml page:
?xml version=1.0 encoding=UTF-8?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:ui=http://java.sun.com/jsf/facelets;
h:body
h:form
h:dataTable value=#{customerBean.all} var=customer
h:column
f:facet name=header#{msgs.nameHeader}/f:facet
#{customer.Name}
/h:column
/h:dataTable
/h:form
/h:body
/html
It's important to mention that the same code works perfect when I change JSF
implementation to mojarra-2.1.7.
It's seems like a bug.
Thanks a lot
Sagi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly
[jira] [Commented] (TOMAHAWK-1618) ui:fragment ignores rendered attribute if nested in t:div
[ https://issues.apache.org/jira/browse/TOMAHAWK-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241990#comment-13241990 ] Leonardo Uribe commented on TOMAHAWK-1618: -- Thanks for the sample. It is a bug in tomahawk, and will be fixed updating shared module. ui:fragment ignores rendered attribute if nested in t:div - Key: TOMAHAWK-1618 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1618 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.11 Environment: MyFaces 2.1.6, Tomahawk 1.1.11, Tomcat 6.0.32 Reporter: Patrick Schmidt Attachments: myfaces-blank.zip When nested inside a t:div, the rendered attribute of ui:fragment ist ignored. This seems to be similar to MYFACES-3239, which was fixed in 2.1.2. Example: t:div ui:fragment rendered=false h:outputText value=This text should not appear / /ui:fragment /t:div -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3518) Datatable (h:dataTable) is not populated with data despite getAll() method returns ResultSet with table rows ( Using Tomcat 7 + MySQL 5.5 + mysql-connector-java-5.1.1
[
https://issues.apache.org/jira/browse/MYFACES-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241993#comment-13241993
]
Leonardo Uribe commented on MYFACES-3518:
-
Thanks to Sagi Kovaliov for the example, it helps a lot solving this issue
quickly.
Datatable (h:dataTable) is not populated with data despite getAll() method
returns ResultSet with table rows ( Using Tomcat 7 + MySQL 5.5 +
mysql-connector-java-5.1.18 )
-
Key: MYFACES-3518
URL: https://issues.apache.org/jira/browse/MYFACES-3518
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.1.6
Environment: Windows 7 64bit
Tomcat 7.0.26
myfaces-2.1.6
JRE 6
MySQL 5.5
mysql-connector-java-5.1.18
Reporter: Sagi Kovaliov
Assignee: Leonardo Uribe
Fix For: 1.1.10, 1.2.12, 2.0.13, 2.1.7
Hello, when I use the following BeanClass and xhtml page, Datatable is not
populated with data, despite the method getAll() returns ResultSet that
contains customer names.
Code line System.out.println(crs.getString(Name)) iterates through the
ResultSet and prints customer names from customer table before the ResultSet
is being returned to h:dataTable component. This is what I get in Tomcat log:
..
***
*** WARNING: Apache MyFaces-2 is running in DEVELOPMENT mode. ***
*** ^^^ ***
*** Do NOT deploy to your live server(s) without changing this. ***
*** See Application#getProjectStage() for more information. ***
***
29/03/2012 22:19:57 org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler [http-bio-8080]
29/03/2012 22:19:57 org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler [ajp-bio-8009]
29/03/2012 22:19:57 org.apache.catalina.startup.Catalina start
INFO: Server startup in 4706 ms
29/03/2012 22:19:58 org.apache.myfaces.util.ExternalSpecifications
isUnifiedELAvailable
INFO: MyFaces Unified EL support enabled
Start of Debug
William Dupont
William Dupont
End of Debug
This is the ManagedBean:
package com.corejsf;
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import javax.annotation.Resource;
import javax.faces.bean.*;
import javax.sql.DataSource;
import javax.sql.rowset.CachedRowSet;
@ManagedBean
@RequestScoped
public class CustomerBean {
@Resource(name=jdbc/Sufa) private DataSource ds;
public ResultSet getAll() throws SQLException {
Connection conn = ds.getConnection();
try {
Statement stmt = conn.createStatement();
ResultSet result = stmt.executeQuery(SELECT * FROM customers);
CachedRowSet crs = new com.sun.rowset.CachedRowSetImpl();
crs.populate(result);
System.out.println(Start of Debug);
while(crs.next()) {
System.out.println(crs.getString(Name));
}
System.out.println(End of Debug);
return crs;
} finally {
conn.close();
}
}
}
This is xhtml page:
?xml version=1.0 encoding=UTF-8?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:ui=http://java.sun.com/jsf/facelets;
h:body
h:form
h:dataTable value=#{customerBean.all} var=customer
h:column
f:facet name=header#{msgs.nameHeader}/f:facet
#{customer.Name}
/h:column
/h:dataTable
/h:form
/h:body
/html
It's important to mention that the same code works perfect when I change JSF
implementation to mojarra-2.1.7.
It's seems like a bug.
Thanks a lot
Sagi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3515) Duplicate id using a facet in a composite component
[
https://issues.apache.org/jira/browse/MYFACES-3515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240372#comment-13240372
]
Leonardo Uribe commented on MYFACES-3515:
-
Could you provide an example to be able to reproduce this issue?
Duplicate id using a facet in a composite component
---
Key: MYFACES-3515
URL: https://issues.apache.org/jira/browse/MYFACES-3515
Project: MyFaces Core
Issue Type: Bug
Environment: MyFaces 2.1.6, Tomahawk20 1.1.11
Reporter: dennis hoersch
Hello,
I get an IllegalStateException using a facet in a composite component. The
facet gets the same id as the internal 'composite component'-facet. The facet
is created using CumponentSupport.addFacet(). Here the id of the facet is
generated using the view root instead of the UniqueIdVendor of the parent to
whom the facet is added.
In other places the id is retrieved with something like
FaceletCompositionContext mctx =
FaceletCompositionContext.getCurrentInstance(facesContext);
UniqueIdVendor uniqueIdVendor = mctx.getUniqueIdVendorFromStack();
if (uniqueIdVendor == null)
{
uniqueIdVendor = facesContext.getViewRoot();
}
String uid = uniqueIdVendor.createUniqueId(facesContext, null);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TOMAHAWK-1616) RendererUtils not in sync with latest MyFaces
[ https://issues.apache.org/jira/browse/TOMAHAWK-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240557#comment-13240557 ] wojtask commented on TOMAHAWK-1616: --- I can confirm that RenderUtils.renderChild is broken in Tomahawk -1.1.11 This bug exists in myfaces-shared-project-4.0.8 RendererUtils not in sync with latest MyFaces - Key: TOMAHAWK-1616 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1616 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.11 Reporter: Jarek Priority: Minor I've noticed that the bug https://issues.apache.org/jira/browse/MYFACES-3146 (problem with ui:fragment) which has already been fixed in newest MyFaces, is still present when Tomahawk is used. Quick debug showed that in the Tomahawk version RendererUtils.renderChild does not contain the first if (isRendered) check - MyFaces version has it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3514) cc:insertChildren must relocate user tag handlers other tags that contains markup too
[ https://issues.apache.org/jira/browse/MYFACES-3514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240945#comment-13240945 ] Leonardo Uribe commented on MYFACES-3514: - After thinking about it, I consider use c:if and any user tag (tag that is created adding a source entry pointing to a .xhtml file into taglib.xml) should be just relocated like ui:decorate. It is clear a new interface called org.apache.myfaces.view.facelets.tag.ComponentContainerHandler is necessary to identify such tags and include them in a pluggable way into cc:insertChildren special logic. cc:insertChildren must relocate user tag handlers other tags that contains markup too - Key: MYFACES-3514 URL: https://issues.apache.org/jira/browse/MYFACES-3514 Project: MyFaces Core Issue Type: Bug Environment: MyFaces 2.1.6, Tomahawk20 1.1.11 Reporter: dennis hoersch Hello, I just copied the emails of the problem that not all children of composite components will be rendered out of the dev-list in here. -- Hi Leonardo, that was my first attempt too. But as I mentioned earlier, we have also own TagHandlers (no UserTagHandlers, they extends TagHandler) - that ones will be still ignored... Maybe there can be a special marker interface? So that the 'list' is more dynamically? (But I am not very glad with this solution if anyone having own tag handlers must do a special thing to get them work with composite components (?)...) Greetings, dennis Hi Dennis I have checked the code and I think we can consider all UserTagHandler instances as containers of components (just like DecorateHandler and IncludeHandler). That means if cc:insertChildren is used, all instances of UserTagHandler should be executed in the place when cc:insertChildren is called. So we just need to increase the list to: - javax.faces.view.facelets.ComponentHandler.class - InsertChildrenHandler.class - InsertHandler.class - DecorateHandler.class - IncludeHandler.class - TextHandler.class - UserHagHandler.class After looking carefully this issue, it seems we need to include c:if and c:choose too. Could you please create an issue for this one in https://issues.apache.org/jira/browse/MYFACES so I can fix it? regards, Leonardo 2012/3/27 Dennis Hörsch hoer...@his.de: Hi, I was expecting that composite components behave like any other. I am currently updating a big project from JSF1 to 2. We have many usages of JSTL as 'child'-components. And our 'old-fashioned' facelets components now are UserTagHandlers in the end. This ones will also be ignored... I had a look an at CompositeComponentResourceTagHandler and changed it in the way that 'newly' added childs are stored and will later be added to the right component. My simple test scenario works, but I have no clue about Partial State Saving and if there are any other cases that may be affected. I attached it, can you have a look? Thank you, dennis hoersch Am 26.03.2012 22:42, schrieb Leonardo Uribe: Hi Difficult question. You should avoid that trick, or at least use c:if inside you custom tag to make it work properly. Really there are some details that will not work as expected. First of all, c:if code has changed since the original code inside facelets, to ensure proper operation with JSF 2.0 Partial State Saving. It is very complex to explain, but in resume, no component like c:if can be created without rely in some implementation details. The second part is composite component algorithm cannot recognize the tag as a tag containing component instances, so if the composite component uses cc:insertChildren, the part related to the tag will not be applied correctly. The solution in this case is use a composite component or a normal component instead a facelets user tag. Anyway, maybe we can do something better in this part ( org.apache.myfaces.view.facelets.tag.composite.CompositeComponentResourceTagHandler), and try to detect better cases like the one described here. regards, Leonardo Uribe 2012/3/26 Dennis Hörsch hoer...@his.de: Hey, I have a problem with composite components. The scenario is as follows: his:someCompositeComponent id=outer h:inputText id=first ... / his:someTagHandlerTag condition=bla h:inputText is=second ... / /his:someTagHandlerTag /his:someCompositeComponent The problem is, only the first input field is rendered. The second is not. After building the component tree, the first is a child of the 'composite component'-facet of the surrounding UINamingContainer (outer), the second ends as child of the UINamingContainer. The 'HtmlCompositeComponentRenderer
[jira] [Commented] (MYFACES-3515) Duplicate id using a facet in a composite component
[
https://issues.apache.org/jira/browse/MYFACES-3515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240949#comment-13240949
]
Leonardo Uribe commented on MYFACES-3515:
-
I was not able to reproduce the bug, but I can see the problem. The reason why
we haven't seen it is any call to UIViewRoot.createUniqueId() increase the
unique counter, so as soon as the view gets bigger and bigger, the different
between the unique counter in UIViewRoot and other counters in composite
components gets bigger too. In few words, the probability to see the problem is
very small, but I'm glad someone has been able to see it.
The panel created by ComponentSupport.createFacetUIPanel is special. To be
restored properly and do not create duplicate ids or any other unwanted
conflicts, it requires an unique id. This code is usually called when more than
one component is added to a facet and it is necessary to create a shared
container. Use FaceletCompositionContext.generateUniqueComponentId() is not
possible, because c:if blocks inside a facet will make component ids
unstable. Use UniqueIdVendor is feasible but also will be affected by c:if
blocks inside a facet. The only solution that will generate real unique ids is
use the parent id and the facet name and derive an unique id that cannot be
generated by SectionUniqueIdCounter, doing the same trick as with metadata: use
a double __ and add a prefix (f). Note this id will never be printed into the
response, because this is just a container.
Note in facelets 1.1.x facets requires a container component, but in JSF 2.0 /
2.1, the behavior to handle facets was changed in order to make f:metadata
component work (requires facets can contain more than one component
automatically).
I also have notice a small performance improvement: our calls to
UniqueIdVendor.createUniqueId() increase the unique counter in 1, but when a
seed is passed this is not necessary. That will save one HashMap.get() call per
component create by facelets.
Duplicate id using a facet in a composite component
---
Key: MYFACES-3515
URL: https://issues.apache.org/jira/browse/MYFACES-3515
Project: MyFaces Core
Issue Type: Bug
Environment: MyFaces 2.1.6, Tomahawk20 1.1.11
Reporter: dennis hoersch
Attachments: duplicateIdTest.zip
Hello,
I get an IllegalStateException using a facet in a composite component. The
facet gets the same id as the internal 'composite component'-facet. The facet
is created using CumponentSupport.addFacet(). Here the id of the facet is
generated using the view root instead of the UniqueIdVendor of the parent to
whom the facet is added.
In other places the id is retrieved with something like
FaceletCompositionContext mctx =
FaceletCompositionContext.getCurrentInstance(facesContext);
UniqueIdVendor uniqueIdVendor = mctx.getUniqueIdVendorFromStack();
if (uniqueIdVendor == null)
{
uniqueIdVendor = facesContext.getViewRoot();
}
String uid = uniqueIdVendor.createUniqueId(facesContext, null);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3104) MyFaces 2 with EL 2.2 in Websphere 7
[
https://issues.apache.org/jira/browse/MYFACES-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240152#comment-13240152
]
sajeev commented on MYFACES-3104:
-
We are experiencing the similar issue .
The environment we are using is
WebSphere 7 + GlassFish EL2.2 +MyFaces . With Class loading set to
PARENT LAST. Glassfish EL api and impl jars are stored in WebInf/lib folder.
It seems to me that WebSphere`s implementation of
javax.servlet.jsp.JspApplicationContext i.e
org.apache.jasper.runtime.JspApplicationContextImpl is complied with Jasper EL1
api version .
When we are using the EL2.2 apis in our class path with Parent last setting.
MyFaces loads and links the EL based classes from glass fish api and impl
jars. Were as the org.apache.jasper.runtime.JspApplicationContextImpl loads the
El from the its own jasper EL libraries located in j2ee.jar. as the
JspApplication context is loaded on the container
This mismatch in the loaded class files would cause teh verify error.
Can you suggest any work around (One which dosent involve rebuilding MyFaces
library) for El2.2 support on WebSphere 7
MyFaces 2 with EL 2.2 in Websphere 7
Key: MYFACES-3104
URL: https://issues.apache.org/jira/browse/MYFACES-3104
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.0.4
Environment: WebSphere Platform 7.0.0.13
Host Operating System is Windows XP, version 5.1 build 2600 Service Pack 3
Java version = 1.6.0, Java Compiler = j9jit24, Java VM name = IBM J9 VM
Servlet API : 2.5
JSP API : 2.1
Reporter: mansour
Attachments: MyFacesEL2Sample_was7.zip
We have followed your documentation on the wiki in order to enable EL 2.2
(http://wiki.apache.org/myfaces/HowToEnableEl22), it doesn't work on
Websphere 7.
- we have added the 2 jars (el-api-2.2.jar and el-impl-2.2.jar from Glassfish
implementation) in th classpath of the web application
- we have configured the web.xml like this :
context-param
param-nameorg.apache.myfaces.EXPRESSION_FACTORY/param-name
param-valuecom.sun.el.ExpressionFactoryImpl/param-value
/context-param
[...]
listener
listener-classorg.apache.myfaces.webapp.StartupServletContextListener/listener-class
/listener
The web application starts without errors,
Problem :
1) When the web application starts we have this first exception :
[04/04/11 11:24:39:136 CEST] 000a DefaultFacesC I Reading standard
config META-INF/standard-faces-config.xml
[04/04/11 11:24:39:277 CEST] 000a DefaultFacesC I Reading config
/WEB-INF/faces-config.xml
[04/04/11 11:24:39:823 CEST] 000a ExternalSpeci I MyFaces Bean
Validation support disabled
[04/04/11 11:24:39:855 CEST] 000a ApplicationIm I Couldn't discover the
current project stage, using Production
[04/04/11 11:24:39:855 CEST] 000a FacesConfigur I Serialization
provider : class
org.apache.myfaces.shared_impl.util.serial.DefaultSerialFactory
[04/04/11 11:24:39:855 CEST] 000a DefaultLifecy I Using
LifecycleProvider
org.apache.myfaces.config.annotation.AllAnnotationLifecycleProvider
[04/04/11 11:24:39:933 CEST] 000a FfdcProvider W
com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I: Incident FFDC émis
sur
C:\IBM\SDP75\runtimes\base_v7\profiles\was70profile2\logs\ffdc\server1_48704870_11.04.04_11.24.39.8706071861720806063404.txt
com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated 1341
[04/04/11 11:24:39:933 CEST] 000a webappE
com.ibm.ws.webcontainer.webapp.WebApp notifyServletContextCreated SRVE0283E:
Exception interceptée lors de l''initialisation du contexte : {0}
java.lang.VerifyError:
javax/servlet/jsp/JspApplicationContext.addELResolver(Ljavax/el/ELResolver;)V
at
org.apache.myfaces.webapp.Jsp21FacesInitializer.configureResolverForJSP(Jsp21FacesInitializer.java:123)
at
org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:77)
at
org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:126)
at
org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:111)
at
com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:1681)
at
com.ibm.ws.webcontainer.webapp.WebApp.commonInitializationFinish(WebApp.java:374)
at
com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:299)
at
com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication(WebGroupImpl.java:100
[jira] [Commented] (MYFACES-3511) [myfaces-2.1.7-SNAPSHOT] dynamic switching ui:include doesn't work correct if a facet with more than one child exists inside the ui:include
[ https://issues.apache.org/jira/browse/MYFACES-3511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238147#comment-13238147 ] Rene O commented on MYFACES-3511: - With current SNAPSHOT everything works as expected again. [myfaces-2.1.7-SNAPSHOT] dynamic switching ui:include doesn't work correct if a facet with more than one child exists inside the ui:include --- Key: MYFACES-3511 URL: https://issues.apache.org/jira/browse/MYFACES-3511 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.7-SNAPSHOT Environment: Tomcat 7, myfaces-2.1.7-SNAPSHOT Reporter: Rene O Assignee: Leonardo Uribe Attachments: jsftest.war If you click the ajaxified commandButton the ui:include switches. After a few clicks, the switch doesn't work correct anymore. You must click twice to switch the include, which is a bug. The problem is caused by multiple childs within a facet. If the facet has only one child, everything works as expected. This issue is a regression. See MYFACES-3455 There was the identical problem. A testcase to reproduce this issue is attached. http://localhost:8080/jsftest/simplenavtest.jsf -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ORCHESTRA-60) Orchestra should implement RequestParameterResponseWrapper.encodeRedirectURL()
[ https://issues.apache.org/jira/browse/ORCHESTRA-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238509#comment-13238509 ] Christian Kaltepoth commented on ORCHESTRA-60: -- Hey Leonardo, yes, I think this is the way the API should be used. Calling sendRedirect() for external URLs is possible of cause, but calling encodeRedirectURL() only makes sense to me when being called for internal URLs. So I think it's safe to add the conversationContext parameter in encodeRedirectURL() too. Christian Orchestra should implement RequestParameterResponseWrapper.encodeRedirectURL() -- Key: ORCHESTRA-60 URL: https://issues.apache.org/jira/browse/ORCHESTRA-60 Project: MyFaces Orchestra Issue Type: Bug Components: Conversation Affects Versions: 1.5 Reporter: Christian Kaltepoth Orchestra currently doesn't implement RequestParameterResponseWrapper.encodeRedirectURL(). The API docs of HttpServletResponse clearly state that encodeRedirectURL() should be called before sending a redirect using sendRedirect(). Therefore the conversationContext parameter is currently lost in these situations. Corresponding PrettyFaces issue: http://code.google.com/p/prettyfaces/issues/detail?id=125 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ORCHESTRA-60) Orchestra should implement RequestParameterResponseWrapper.encodeRedirectURL()
[ https://issues.apache.org/jira/browse/ORCHESTRA-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238099#comment-13238099 ] Leonardo Uribe commented on ORCHESTRA-60: - Hi Cristian O, now I get it. sendRedirect() is used for internal and external URLs, but all internal URLs pass first through encodeRedirectURL(), so it is valid to add conversationContext param into that call. The rules for add conversationContext are already in orchestra and applies to encodeURL() too, so the change is valid. Orchestra should implement RequestParameterResponseWrapper.encodeRedirectURL() -- Key: ORCHESTRA-60 URL: https://issues.apache.org/jira/browse/ORCHESTRA-60 Project: MyFaces Orchestra Issue Type: Bug Components: Conversation Affects Versions: 1.5 Reporter: Christian Kaltepoth Orchestra currently doesn't implement RequestParameterResponseWrapper.encodeRedirectURL(). The API docs of HttpServletResponse clearly state that encodeRedirectURL() should be called before sending a redirect using sendRedirect(). Therefore the conversationContext parameter is currently lost in these situations. Corresponding PrettyFaces issue: http://code.google.com/p/prettyfaces/issues/detail?id=125 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ORCHESTRA-60) Orchestra should implement RequestParameterResponseWrapper.encodeRedirectURL()
[ https://issues.apache.org/jira/browse/ORCHESTRA-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13237495#comment-13237495 ] Christian Kaltepoth commented on ORCHESTRA-60: -- Hi Leonardo, thanks for looking into this issue. However I have a different opinion on this topic. I think PrettyFaces is correct when calling encodeRedirectURL() instead of encodeURL(). The docs of encodeRedirectURL() clearly say Encodes the specified URL for use in the sendRedirect() method. PrettyFaces is calling sendRedirect() to redirect inside the web application and therefore must call encodeRedirectURL() to preserve session IDs. That's what the spec defines. I also think that both methods are meant to be used only for URLs that point to the same web application because the docs of both methods mention session IDs as the primary thing that has to be encoded in the URL. Therefore it would be not correct to call any of the encode methods on a URL that doesn't belong to the same application. Therefore I see no reason why the conversion context ID should not be added in encodeRedirectURL(). I'm looking forward to your thoughts on this. Christian Orchestra should implement RequestParameterResponseWrapper.encodeRedirectURL() -- Key: ORCHESTRA-60 URL: https://issues.apache.org/jira/browse/ORCHESTRA-60 Project: MyFaces Orchestra Issue Type: Bug Components: Conversation Affects Versions: 1.5 Reporter: Christian Kaltepoth Orchestra currently doesn't implement RequestParameterResponseWrapper.encodeRedirectURL(). The API docs of HttpServletResponse clearly state that encodeRedirectURL() should be called before sending a redirect using sendRedirect(). Therefore the conversationContext parameter is currently lost in these situations. Corresponding PrettyFaces issue: http://code.google.com/p/prettyfaces/issues/detail?id=125 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2250) Skin pregeneration missing agent versions
[ https://issues.apache.org/jira/browse/TRINIDAD-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236685#comment-13236685 ] Andy Schwartz commented on TRINIDAD-2250: - This patch: https://issues.apache.org/jira/secure/attachment/12519643/trinidad-2250.patch Solves the problem by adding two new methods to Version: + /** + * Converts this Version to the previous version just before this + * version. For example, new Version(1.9).toPreviousVersion() + * results in the version 1.8. + * + * The resulting version is guaranteed to be concrete - ie. + * will contain no wildcards. + * + * Calling toPreviousVersion() on Version.MIN_VERSION returns + * Version.MIN_VERSION. + * + * @return the Version instance corresponding to the version just + * before this version. + */ + public Version toPreviousVersion() + /** + * Converts this Version to the next version just after this + * version. For example, new Version(1.9).toPreviousVersion() + * results in the version 1.10. + * + * The resulting version is guaranteed to be concrete - ie. + * will contain no wildcards. + * + * Calling toNextVersion() on Version.MAX_VERSION returns + * Version.MAX_VERSION. + * + * @return the Version instance corresponding to the version just + * after this version. + */ + public Version toNextVersion() We use these to expand the set of agent versions that we pregenerate - ie. in addition to the start/end of each @agent version range, we also attempt to pregenerate: - The version just previous to the start of the range. - The version just after the end of the range. Looking back at the example above, this means that we would pregenerate for: - 0 (start of #2) - 1 (start of #1 - 3 (end of #2) - 4 (end.toNextVersion() of #2) - 7 (start.toPreviousVersion() of #3) - 8 (start of #3) - Integer.MAX_VALUE (end of #1 and #3) And thus cover the case where we match range #1 but not #2 or #3. Skin pregeneration missing agent versions - Key: TRINIDAD-2250 URL: https://issues.apache.org/jira/browse/TRINIDAD-2250 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 2.0.2-core Reporter: Andy Schwartz Assignee: Andy Schwartz Attachments: trinidad-2250.patch In cases where skins specify overlapping version ranges, skin pregeneration may fail to generate certain style sheets. For example, imagine the skin specifies @agent rules for the following version ranges: 1. min-version:1 2. max:version:3 3. min-version:8 With our current implementation, we only attempt to generate style sheets for the start and end of each version range. For the above example, this would be: - 0 (start of #2) - 1 (start of #1 - 3 (end of #2) - 8 (start of #3) - Integer.MAX_VALUE (end of #1 and #3) If the actual agent version is 7, we should use a style sheet that matches #1, but not #2 or #3. However, we since we only use the start/end points of each version range to determine which style sheets to pregenerate, we fail to pregenerate such a style sheet. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3510) Application components classloader memory leak
[ https://issues.apache.org/jira/browse/MYFACES-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236689#comment-13236689 ] Ruben Martin Pozo commented on MYFACES-3510: I've run the same test with patch2 and the problem keeps happening. The server freezes for 40 seconds in the method TomcatAnnotationLifecycleProvider.isAvailable. I run a little test. I changed that method to always return false since my application is running on a glassfish not a tomcat. And magically everything worked!!!. The classloaders are garbage collected and the server doesn't freeze. Here is what I think is happening. It might sound science fiction but here it goes: I'm running with the flag -XX:+UseConcMarkSweepGC so I'm running a concurrent garbage collector. When there isn't any more room in the permGen for classes, a permGen gc cycle is run. While running this cycle the method TomcatAnnotationLifecycleProvider.isAvailable is trying to know if tomcat is available. To do so, it tries to load a tomcat class. But I don't have this class in my classpath since I'm not running on a tomcat. The JVM looks for the class in the entire classpath but it doesn't find it there. Then the JVM tries to traverse the classloaders graph to ask them for the class but it can't do so since there are some classloader being garbage collected at the same time. So the JVM waits for for concurrent gc to finish and block the thread until that moment. For my application I'll apply the patch you've provided plus the modifications to the TomcatAnnotationLifecycleProvider.isAvailable so the server doesn't freeze. I understand this issue is not directly related to this bug. It couldn't happen before the patch because of the OOM, so this patch kind of unveal this issue Do you want me to open a new bug?. Maybe you could find a different way of detecting the presence of tomcat Application components classloader memory leak -- Key: MYFACES-3510 URL: https://issues.apache.org/jira/browse/MYFACES-3510 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.6 Environment: WIndows Glassfish Embedded Reporter: Ruben Martin Pozo Assignee: Leonardo Uribe Fix For: 2.0.13, 2.1.7 Attachments: MYFACES-3510-1.patch, MYFACES-3510-2.patch, screenshot-1.jpg We've seen an application classloader memory leak due to the new class javax.faces.component._PropertyDescriptorHolder class introduced in version 2.1.6 This class holds a reference to a Method of a component loaded by the application classloader. The memory leak shows up when the _PropertyDescriptorHolder is stored in the _ComponentAttributesMap class that is loaded by the system class loader. You should use a WeakReference instead of storing the direct reference to the Method -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TOBAGO-1101) Firefox 11.0; Button disabled-css-Style fails
[ https://issues.apache.org/jira/browse/TOBAGO-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236708#comment-13236708 ] Udo Schnurpfeil commented on TOBAGO-1101: - Did you test the behavour with other browsers? Firefox 11.0; Button disabled-css-Style fails - Key: TOBAGO-1101 URL: https://issues.apache.org/jira/browse/TOBAGO-1101 Project: MyFaces Tobago Issue Type: Bug Components: Build Affects Versions: 1.0.39 Environment: Firefox 11.0 Reporter: BG RCI Button element: The private css-definition .tobago-button-default (e.g.: color: rgb( 0, 73, 148) ) is not overridden by the Tobago-css-definition .tobago-button-disabled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TOBAGO-1101) Firefox 11.0; Button disabled-css-Style fails
[
https://issues.apache.org/jira/browse/TOBAGO-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236706#comment-13236706
]
Udo Schnurpfeil commented on TOBAGO-1101:
-
When I got your example correctly, this works as designed (and defined by CSS).
When an element has 2 classes e.g. button class=tobago-button-default
tobago-button-disabled, and you have a property set multiple times for both
classes, then the order in the HTML document is relevant to who wins.
In your case: The definition of your personal .tobago-button-default {color:
#004994;} is later than that from the tobago theme (so you can override it)
Result: If you overrite a tobago-button-default property which is also defined
in tobago-button-disabled, you also have to define it in your personal style
file. Same is for tobago-button-error etc.
Firefox 11.0; Button disabled-css-Style fails
-
Key: TOBAGO-1101
URL: https://issues.apache.org/jira/browse/TOBAGO-1101
Project: MyFaces Tobago
Issue Type: Bug
Components: Build
Affects Versions: 1.0.39
Environment: Firefox 11.0
Reporter: BG RCI
Button element:
The private css-definition .tobago-button-default (e.g.: color: rgb( 0, 73,
148) ) is not overridden by the Tobago-css-definition
.tobago-button-disabled.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3510) Application components classloader memory leak
[ https://issues.apache.org/jira/browse/MYFACES-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236707#comment-13236707 ] Leonardo Uribe commented on MYFACES-3510: - No, it is not a bug. There is no other way to detect tomcat different to check if such class exists on the classpath. Instead, what do you need is implement a LifecycleProvider2 for glassfish or a custom LifecycleProviderFactory, to skip TomcatAnnotationLifecycleProvider.isAvailable. Unfortunately, since glassfish is CDDL/GPL licensed, we can't include that integration code in MyFaces. See: https://cwiki.apache.org/confluence/display/MYFACES/Integration+with+application+and+web+servers for more details. It could be good to share your findings later in a blog, other users have reported problems setting up myfaces with glassfish, and maybe that could help Application components classloader memory leak -- Key: MYFACES-3510 URL: https://issues.apache.org/jira/browse/MYFACES-3510 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.6 Environment: WIndows Glassfish Embedded Reporter: Ruben Martin Pozo Assignee: Leonardo Uribe Fix For: 2.0.13, 2.1.7 Attachments: MYFACES-3510-1.patch, MYFACES-3510-2.patch, screenshot-1.jpg We've seen an application classloader memory leak due to the new class javax.faces.component._PropertyDescriptorHolder class introduced in version 2.1.6 This class holds a reference to a Method of a component loaded by the application classloader. The memory leak shows up when the _PropertyDescriptorHolder is stored in the _ComponentAttributesMap class that is loaded by the system class loader. You should use a WeakReference instead of storing the direct reference to the Method -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TOBAGO-1104) Possibility to set the id of the date picker
[ https://issues.apache.org/jira/browse/TOBAGO-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236741#comment-13236741 ] Udo Schnurpfeil commented on TOBAGO-1104: - Added attribute pickerId to tx:date Possibility to set the id of the date picker Key: TOBAGO-1104 URL: https://issues.apache.org/jira/browse/TOBAGO-1104 Project: MyFaces Tobago Issue Type: Improvement Components: Core Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Priority: Trivial Fix For: 1.5.5 This makes the code better testable. Only implemented for Facelets. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2250) Skin pregeneration missing agent versions
[ https://issues.apache.org/jira/browse/TRINIDAD-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236875#comment-13236875 ] Andy Schwartz commented on TRINIDAD-2250: - New version of the patch: https://issues.apache.org/jira/secure/attachment/12519683/trinidad-2250-take2.patch With code review changes recommended by Blake. Skin pregeneration missing agent versions - Key: TRINIDAD-2250 URL: https://issues.apache.org/jira/browse/TRINIDAD-2250 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 2.0.2-core Reporter: Andy Schwartz Assignee: Andy Schwartz Attachments: trinidad-2250-take2.patch, trinidad-2250.patch In cases where skins specify overlapping version ranges, skin pregeneration may fail to generate certain style sheets. For example, imagine the skin specifies @agent rules for the following version ranges: 1. min-version:1 2. max:version:3 3. min-version:8 With our current implementation, we only attempt to generate style sheets for the start and end of each version range. For the above example, this would be: - 0 (start of #2) - 1 (start of #1 - 3 (end of #2) - 8 (start of #3) - Integer.MAX_VALUE (end of #1 and #3) If the actual agent version is 7, we should use a style sheet that matches #1, but not #2 or #3. However, we since we only use the start/end points of each version range to determine which style sheets to pregenerate, we fail to pregenerate such a style sheet. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3510) Application components classloader memory leak
[ https://issues.apache.org/jira/browse/MYFACES-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13235769#comment-13235769 ] Leonardo Uribe commented on MYFACES-3510: - I have attached another patch that uses this structure: private static MapClassLoader, SoftReferenceMapClass?, MapString, _PropertyDescriptorHolder propertyDescriptorCacheMap = new WeakHashMapClassLoader, SoftReferenceMapClass?, MapString, _PropertyDescriptorHolder(); The idea is use a SoftReference to prevent the direct strong reference over propertyDescriptorCache, but use a new key over current classloader to make possible when the application is undeployed to clean the cache. Using yourkit profiler I was not able to see any problem with metadata field, because a cleanup method is called when the application is destroyed on AbstractFacesInitializer. I also tried to check if the SoftReference solves the problem without the cleanup code and it does. I also checked if the solution makes the code slower, but the effect is minimal. Application components classloader memory leak -- Key: MYFACES-3510 URL: https://issues.apache.org/jira/browse/MYFACES-3510 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.6 Environment: WIndows Glassfish Embedded Reporter: Ruben Martin Pozo Attachments: MYFACES-3510-1.patch, MYFACES-3510-2.patch, screenshot-1.jpg We've seen an application classloader memory leak due to the new class javax.faces.component._PropertyDescriptorHolder class introduced in version 2.1.6 This class holds a reference to a Method of a component loaded by the application classloader. The memory leak shows up when the _PropertyDescriptorHolder is stored in the _ComponentAttributesMap class that is loaded by the system class loader. You should use a WeakReference instead of storing the direct reference to the Method -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3510) Application components classloader memory leak
[ https://issues.apache.org/jira/browse/MYFACES-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13235778#comment-13235778 ] Ruben Martin Pozo commented on MYFACES-3510: I've tried the patch and it fixes the problem. The application classloader is gced before throwing the OOM But then something very very strange happen Just after collecting the classloader (I see that in the Java Visual VM tool) the CPU rises up to the 50% (1 core) and the application server freezes for 20-40 seconds. The only thread working is the one copied below. After that time the application displays the JSF page without errors. Any guess??? 2012-03-22 18:21:59 pool-1-thread-3 - Thread t@233 java.lang.Thread.State: RUNNABLE at org.apache.myfaces.config.annotation.TomcatAnnotationLifecycleProvider.isAvailable(TomcatAnnotationLifecycleProvider.java:75) at org.apache.myfaces.config.annotation.DefaultLifecycleProviderFactory.resolveLifecycleProviderFromService(DefaultLifecycleProviderFactory.java:208) at org.apache.myfaces.config.annotation.DefaultLifecycleProviderFactory.getLifecycleProvider(DefaultLifecycleProviderFactory.java:86) at org.apache.myfaces.config.FacesConfigurator.configureManagedBeanDestroyer(FacesConfigurator.java:1043) at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:431) at org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:338) at org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:73) at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:140) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:111) at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:4690) at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:534) at org.apache.catalina.core.StandardContext.start(StandardContext.java:5305) - locked f1a64 (a com.sun.enterprise.web.WebModule) at com.sun.enterprise.web.WebModule.start(WebModule.java:500) - locked f1a64 (a com.sun.enterprise.web.WebModule) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:917) - locked aefd97 (a java.util.LinkedHashMap) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:901) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:755) at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1980) at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1630) at com.sun.enterprise.web.WebApplication.start(WebApplication.java:100) at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130) at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269) - locked 17b599c (a org.glassfish.internal.data.ModuleInfo) at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:286) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240) at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370) at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1067) at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1247) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235) at com.sun.enterprise.admin.cli.embeddable.CommandExecutorImpl.executeCommand(CommandExecutorImpl.java:118) at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:97) at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:88) at com.isb.runtime.embedded.remote.RuntimeRMIServerImpl.forceDeploy(RuntimeRMIServerImpl.java:364) - locked 8c436b (a com.isb.runtime.embedded.remote.RuntimeRMIServerImpl) at com.isb.runtime.embedded.remote.RuntimeRMIServerImpl.requestAccepted(RuntimeRMIServerImpl.java:258) - locked 8c436b (a com.isb.runtime.embedded.remote.RuntimeRMIServerImpl) at com.isb.runtime.embedded.remote.ServerDeployProxy.deployApplication(ServerDeployProxy.java:449
[jira] [Commented] (MYFACES-3510) Application components classloader memory leak
[ https://issues.apache.org/jira/browse/MYFACES-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13235797#comment-13235797 ] Ruben Martin Pozo commented on MYFACES-3510: I've seen you uploaded a new patch while I was writing the comment I'll try the new patch and I'll let you know if this issue keeps happening Application components classloader memory leak -- Key: MYFACES-3510 URL: https://issues.apache.org/jira/browse/MYFACES-3510 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.6 Environment: WIndows Glassfish Embedded Reporter: Ruben Martin Pozo Assignee: Leonardo Uribe Fix For: 2.0.13, 2.1.7 Attachments: MYFACES-3510-1.patch, MYFACES-3510-2.patch, screenshot-1.jpg We've seen an application classloader memory leak due to the new class javax.faces.component._PropertyDescriptorHolder class introduced in version 2.1.6 This class holds a reference to a Method of a component loaded by the application classloader. The memory leak shows up when the _PropertyDescriptorHolder is stored in the _ComponentAttributesMap class that is loaded by the system class loader. You should use a WeakReference instead of storing the direct reference to the Method -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3510) Application components classloader memory leak
[ https://issues.apache.org/jira/browse/MYFACES-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13235894#comment-13235894 ] Leonardo Uribe commented on MYFACES-3510: - The stack trace provided looks normal. A webapp is deployed, so it takes some time to initialize the environment. That is necessary because it is required to parse some files, scan for annotations and merge all that information. Please do not reopen this issue and instead, create another one if necessary, because the stack trace is another different behavior to the one solved in the patch. Application components classloader memory leak -- Key: MYFACES-3510 URL: https://issues.apache.org/jira/browse/MYFACES-3510 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.6 Environment: WIndows Glassfish Embedded Reporter: Ruben Martin Pozo Assignee: Leonardo Uribe Fix For: 2.0.13, 2.1.7 Attachments: MYFACES-3510-1.patch, MYFACES-3510-2.patch, screenshot-1.jpg We've seen an application classloader memory leak due to the new class javax.faces.component._PropertyDescriptorHolder class introduced in version 2.1.6 This class holds a reference to a Method of a component loaded by the application classloader. The memory leak shows up when the _PropertyDescriptorHolder is stored in the _ComponentAttributesMap class that is loaded by the system class loader. You should use a WeakReference instead of storing the direct reference to the Method -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3510) Application components classloader memory leak
[ https://issues.apache.org/jira/browse/MYFACES-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13235919#comment-13235919 ] Ruben Martin Pozo commented on MYFACES-3510: And how do you explain that if I remove the patch the server doesn't freeze when deploying? To test the patch I have to redeploy the app several times so I get to the point when there is no more permGen memory and the soft reference is garbage collected. Then and only then the server freezes and not in any of the other times when I redeployed but there was enough memory So I really think something strange is happening that is, somehow, trigger by this patch. I'll try patch-2 to see if the same thing happens Application components classloader memory leak -- Key: MYFACES-3510 URL: https://issues.apache.org/jira/browse/MYFACES-3510 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.6 Environment: WIndows Glassfish Embedded Reporter: Ruben Martin Pozo Assignee: Leonardo Uribe Fix For: 2.0.13, 2.1.7 Attachments: MYFACES-3510-1.patch, MYFACES-3510-2.patch, screenshot-1.jpg We've seen an application classloader memory leak due to the new class javax.faces.component._PropertyDescriptorHolder class introduced in version 2.1.6 This class holds a reference to a Method of a component loaded by the application classloader. The memory leak shows up when the _PropertyDescriptorHolder is stored in the _ComponentAttributesMap class that is loaded by the system class loader. You should use a WeakReference instead of storing the direct reference to the Method -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3510) Application components classloader memory leak
[ https://issues.apache.org/jira/browse/MYFACES-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13235968#comment-13235968 ] Leonardo Uribe commented on MYFACES-3510: - Garbage collection takes time. The code committed (patch-2) try to cleanup the cache as soon as the app is undeployed. The soft reference is only cleaned up when memory is really necessary, and an OutOfMemoryError is only thrown after clean all soft references. I suppose the GC is responsible of the slowdown, but with the code committed, this effect dissapear. Application components classloader memory leak -- Key: MYFACES-3510 URL: https://issues.apache.org/jira/browse/MYFACES-3510 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.6 Environment: WIndows Glassfish Embedded Reporter: Ruben Martin Pozo Assignee: Leonardo Uribe Fix For: 2.0.13, 2.1.7 Attachments: MYFACES-3510-1.patch, MYFACES-3510-2.patch, screenshot-1.jpg We've seen an application classloader memory leak due to the new class javax.faces.component._PropertyDescriptorHolder class introduced in version 2.1.6 This class holds a reference to a Method of a component loaded by the application classloader. The memory leak shows up when the _PropertyDescriptorHolder is stored in the _ComponentAttributesMap class that is loaded by the system class loader. You should use a WeakReference instead of storing the direct reference to the Method -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3510) Application components classloader memory leak
[ https://issues.apache.org/jira/browse/MYFACES-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236087#comment-13236087 ] Ruben Martin Pozo commented on MYFACES-3510: I'm sorry but I disagree. I've run the test 20 times and every single time the server gets stuck at the same point in the code. That's not justified by the gc but more likely by some collateral problem caused by the soft references being removed If I run the test with the previous version of MyFaces where the memory leak doesn't exist I don't see this behavior and the gc is also unloading classloaders and classes. Tomorrow I'll run the test with patch-2 and I'll let you know the results Application components classloader memory leak -- Key: MYFACES-3510 URL: https://issues.apache.org/jira/browse/MYFACES-3510 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.6 Environment: WIndows Glassfish Embedded Reporter: Ruben Martin Pozo Assignee: Leonardo Uribe Fix For: 2.0.13, 2.1.7 Attachments: MYFACES-3510-1.patch, MYFACES-3510-2.patch, screenshot-1.jpg We've seen an application classloader memory leak due to the new class javax.faces.component._PropertyDescriptorHolder class introduced in version 2.1.6 This class holds a reference to a Method of a component loaded by the application classloader. The memory leak shows up when the _PropertyDescriptorHolder is stored in the _ComponentAttributesMap class that is loaded by the system class loader. You should use a WeakReference instead of storing the direct reference to the Method -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3510) Application components classloader memory leak
[ https://issues.apache.org/jira/browse/MYFACES-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236126#comment-13236126 ] Leonardo Uribe commented on MYFACES-3510: - Well, do you have a better explanation? You could try replace SoftReference with WeakReference. If that change improves the situation, let me know and I'll change the code. Application components classloader memory leak -- Key: MYFACES-3510 URL: https://issues.apache.org/jira/browse/MYFACES-3510 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.6 Environment: WIndows Glassfish Embedded Reporter: Ruben Martin Pozo Assignee: Leonardo Uribe Fix For: 2.0.13, 2.1.7 Attachments: MYFACES-3510-1.patch, MYFACES-3510-2.patch, screenshot-1.jpg We've seen an application classloader memory leak due to the new class javax.faces.component._PropertyDescriptorHolder class introduced in version 2.1.6 This class holds a reference to a Method of a component loaded by the application classloader. The memory leak shows up when the _PropertyDescriptorHolder is stored in the _ComponentAttributesMap class that is loaded by the system class loader. You should use a WeakReference instead of storing the direct reference to the Method -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TOBAGO-1101) Firefox 11.0; Button disabled-css-Style fails
[ https://issues.apache.org/jira/browse/TOBAGO-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234205#comment-13234205 ] Udo Schnurpfeil commented on TOBAGO-1101: - I can't reproduce. Or do I missunderstanding? I've just checked the demo page at http://localhost:8080/tobago-example-demo/faces/overview/intro.jsp (Tobago 1.0.39): The most left button at the bottom is grey (disabled), the other ones are dark red, this is what I've exprected. Firefox 11.0; Button disabled-css-Style fails - Key: TOBAGO-1101 URL: https://issues.apache.org/jira/browse/TOBAGO-1101 Project: MyFaces Tobago Issue Type: Bug Components: Build Affects Versions: 1.0.39 Environment: Firefox 11.0 Reporter: BG RCI Button element: The private css-definition .tobago-button-default (e.g.: color: rgb( 0, 73, 148) ) is not overridden by the Tobago-css-definition .tobago-button-disabled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TOMAHAWK-1615) Auto-ID-generation does not respect rowIndex in facet=detailStamp
[
https://issues.apache.org/jira/browse/TOMAHAWK-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234297#comment-13234297
]
Achim Hensel commented on TOMAHAWK-1615:
Demonstration code:
t:dataTable
id=demoTable
value=#{bean.twoEntryList}
var=valueHolder
rowIndexVar=riv
detailStampExpandedDefault=true
varDetailToggler=detailToggler
t:column
f:facet name=headerHeader/f:facet
h:commandLink action=#{detailToggler.toggleDetail}Toggle
#{riv}/h:commandLink
/t:column
f:facet name=detailStamp
t:outputText id=otid_#{riv} title=T_#{riv}
value=V_#{riv}/t:outputText
/f:facet
/t:dataTable
Actual output (new formatted):
table id=reportList:demoTable
theadtrthHeader/th/tr/thead
tbody id=reportList:demoTable:tbody_element
trtda href=# onclick=return
oamSubmitForm('reportList','reportList:demoTable:0:_id60');
id=reportList:demoTable:0:_id60Toggle 0/a/td/tr
trtd colspan=1span id=reportList:demoTable:0:otid_
title=T_0V_0/span/td/tr
trtda href=# onclick=return
oamSubmitForm('reportList','reportList:demoTable:1:_id60');
id=reportList:demoTable:1:_id60Toggle 1/a/td/tr
trtd colspan=1span id=reportList:demoTable:0:otid_
title=T_1V_1/span/td/tr
/tbody/table
Expected output:
table id=reportList:demoTable
theadtrthHeader/th/tr/thead
tbody id=reportList:demoTable:tbody_element
trtda href=# onclick=return
oamSubmitForm('reportList','reportList:demoTable:0:_id60');
id=reportList:demoTable:0:_id60Toggle 0/a/td/tr
trtd colspan=1span id=reportList:demoTable:0:otid_0
title=T_0V_0/span/td/tr
trtda href=# onclick=return
oamSubmitForm('reportList','reportList:demoTable:1:_id60');
id=reportList:demoTable:1:_id60Toggle 1/a/td/tr
trtd colspan=1span id=reportList:demoTable:1:otid_1
title=T_1V_1/span/td/tr
/tbody/table
Ntice the different IDs of the detailStamp span
(id=reportList:demoTable:0:otid_0 vs. reportList:demoTable:0:otid).
This error also influences the t:inputCalendar component, and irritates the
t:updateActionListener of a t:commandLink.
Auto-ID-generation does not respect rowIndex in facet=detailStamp
---
Key: TOMAHAWK-1615
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1615
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Extended Datatable
Affects Versions: 1.1.11
Environment: JSF 1.1, MyFaces 1.1.5
Reporter: Achim Hensel
Generated IDs of components in a facet=detailStamp of a t:dataTable are
assigned the same row index for all rows. For each ID, the row index 0 of
the first row is used.
Furthermore the content of the variable rowIndexVar is empty, when it is
used in the id-attribute. It is _not_ empty for e.g. the attributes title
or value.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TOMAHAWK-1615) Auto-ID-generation does not respect rowIndex in facet=detailStamp
[ https://issues.apache.org/jira/browse/TOMAHAWK-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234301#comment-13234301 ] Achim Hensel commented on TOMAHAWK-1615: I also get a similar behaviour to TOMAHAWK-587, when I use a t:commandLink in the detailStamp. I assume this is due to the duplicated IDs. Auto-ID-generation does not respect rowIndex in facet=detailStamp --- Key: TOMAHAWK-1615 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1615 Project: MyFaces Tomahawk Issue Type: Bug Components: Extended Datatable Affects Versions: 1.1.11 Environment: JSF 1.1, MyFaces 1.1.5 Reporter: Achim Hensel Generated IDs of components in a facet=detailStamp of a t:dataTable are assigned the same row index for all rows. For each ID, the row index 0 of the first row is used. Furthermore the content of the variable rowIndexVar is empty, when it is used in the id-attribute. It is _not_ empty for e.g. the attributes title or value. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TOBAGO-1101) Firefox 11.0; Button disabled-css-Style fails
[
https://issues.apache.org/jira/browse/TOBAGO-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234307#comment-13234307
]
BG RCI commented on TOBAGO-1101:
We have created a bgrci.css file with item:
.tobago-button-default {
color: #004994;
}
(Blue text)
After this we created a tc:style-element in the overview.tag
?xml…
jsp:root…
f:view…
tc:page..
tc:style style=style/bgrci.css /
With the IE-Browser looks everything’s fine:
Default Button-Text:Blue
Disable Button-Text: Gray
With the Firefox 11.0 is the Text-Style as follows:
Default Butten-Text: Blue
Disable Button-Text: Blue
(Debugging with Firebug 1.9.1)
HTML:
button class=tobago-button-default tobago-button-disabled
style=height:20px; width:75px;
onclick=
disabled=disabled
id=page:_idJsp117
name=page:_idJsp117
type=buttonVorschau/button
Styles:
element.style {
height: 20px;
width: 75px;
}
.tobago-button-default {
background-image: url(../image/button-bg.gif);
color: #004994;
} bgrci.css
(Zeile 252)
.tobago-button-disabled {
color: graytext;
}
Firefox 11.0; Button disabled-css-Style fails
-
Key: TOBAGO-1101
URL: https://issues.apache.org/jira/browse/TOBAGO-1101
Project: MyFaces Tobago
Issue Type: Bug
Components: Build
Affects Versions: 1.0.39
Environment: Firefox 11.0
Reporter: BG RCI
Button element:
The private css-definition .tobago-button-default (e.g.: color: rgb( 0, 73,
148) ) is not overridden by the Tobago-css-definition
.tobago-button-disabled.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2228) java.lang.UnsupportedOperationException
[ https://issues.apache.org/jira/browse/TRINIDAD-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234404#comment-13234404 ] Scott O'Bryan commented on TRINIDAD-2228: - I see. So this appears to maybe be an issue with the latest MyFaces then. Would you agree? Try fixing the EL evaluation and run this again. I agree that the UnsupportedOperationException is not expected, but it may mean the difference between a major issue an a minor one. If this usecase only fails in MyFaces then I can transfer this bug over to core so that it can be addressed in the next release. java.lang.UnsupportedOperationException --- Key: TRINIDAD-2228 URL: https://issues.apache.org/jira/browse/TRINIDAD-2228 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.1-core Environment: Ubuntu, Java 1.6, Jetty or Tomcat 7 Reporter: Walter Mourão Assignee: Scott O'Bryan Fix For: 2.0.2-core Attachments: autocomplete.zip Same project, with Trinidad 2.0.0 works fine, with Trinidad 2.0.1, java.lang.UnsupportedOperationException in pages containing composite components. Stack trace: java.lang.UnsupportedOperationException at javax.faces.view.ViewDeclarationLanguage.retargetMethodExpressions(ViewDeclarationLanguage.java:75) at org.apache.myfaces.view.facelets.tag.composite.CompositeComponentResourceTagHandler.applyNextHandler(CompositeComponentResourceTagHandler.java:181) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53) at org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:57) at org.apache.myfaces.view.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:45) at org.apache.myfaces.view.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:151) at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.buildView(FaceletViewDeclarationLanguage.java:435) at org.apache.myfaces.trinidadinternal.application.ViewDeclarationLanguageFactoryImpl$ChangeApplyingVDLWrapper.buildView(ViewDeclarationLanguageFactoryImpl.java:342) at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:77) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTSCRIPT-160) Prepare 1.0.3 release
[ https://issues.apache.org/jira/browse/EXTSCRIPT-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234438#comment-13234438 ] Werner Punz commented on EXTSCRIPT-160: --- There are two issues a) First we have the wrong parent version for the meta bundles. b) fullCompileWhitelistTest fails strangely in Linux while it works on OSX, this needs to be investigated further Prepare 1.0.3 release - Key: EXTSCRIPT-160 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-160 Project: MyFaces Extensions Scripting Issue Type: Task Components: Core Affects Versions: 1.0.3-SNAPSHOT, 1.0.3-FINAL Reporter: Werner Punz Assignee: Werner Punz prepare the 1.0.3 release which is the rewrite and scala release -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2228) java.lang.UnsupportedOperationException
[ https://issues.apache.org/jira/browse/TRINIDAD-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234511#comment-13234511 ] Walter Mourão commented on TRINIDAD-2228: - I agree it looks like a MyFaces issue but... Trinidad 2.0.0 + MyFaces 2.1.6 works. I will try to do some more testing today with different combinations and will post here so we can be sure about the source of the problem. java.lang.UnsupportedOperationException --- Key: TRINIDAD-2228 URL: https://issues.apache.org/jira/browse/TRINIDAD-2228 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.1-core Environment: Ubuntu, Java 1.6, Jetty or Tomcat 7 Reporter: Walter Mourão Assignee: Scott O'Bryan Fix For: 2.0.2-core Attachments: autocomplete.zip Same project, with Trinidad 2.0.0 works fine, with Trinidad 2.0.1, java.lang.UnsupportedOperationException in pages containing composite components. Stack trace: java.lang.UnsupportedOperationException at javax.faces.view.ViewDeclarationLanguage.retargetMethodExpressions(ViewDeclarationLanguage.java:75) at org.apache.myfaces.view.facelets.tag.composite.CompositeComponentResourceTagHandler.applyNextHandler(CompositeComponentResourceTagHandler.java:181) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53) at org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:57) at org.apache.myfaces.view.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:45) at org.apache.myfaces.view.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:151) at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.buildView(FaceletViewDeclarationLanguage.java:435) at org.apache.myfaces.trinidadinternal.application.ViewDeclarationLanguageFactoryImpl$ChangeApplyingVDLWrapper.buildView(ViewDeclarationLanguageFactoryImpl.java:342) at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:77) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2234) Pregeneration of skin style sheets
[ https://issues.apache.org/jira/browse/TRINIDAD-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234788#comment-13234788 ] Andy Schwartz commented on TRINIDAD-2234: - One more rev: https://issues.apache.org/jira/secure/attachment/12519277/trinidad-skin-pregen-take4.patch This patch simplifies our configuration API by: - Enabling stable style sheet file names by default. And... - Only allowing stable names to be disabled via an internal context parameter. If we run into use cases where using the old non-stable names is critical, we can re-evaluate. Pregeneration of skin style sheets -- Key: TRINIDAD-2234 URL: https://issues.apache.org/jira/browse/TRINIDAD-2234 Project: MyFaces Trinidad Issue Type: New Feature Components: Skinning Affects Versions: 2.0.1-core Reporter: Andy Schwartz Assignee: Andy Schwartz Priority: Minor Attachments: trinidad-skin-pregen-take2.patch, trinidad-skin-pregen-take3.patch, trinidad-skin-pregen-take4.patch, trinidad-skin-pregen.patch Trinidad skinning dynamically generates style sheets at runtime to meet context-specific (ie. platform/agent/locale/accessibility-specific) skinning requirements. While dynamic generation of style sheets is beneficial in that it allows fine tuning of which styles are delivered for particular contexts, it can complicate some use cases. One case that dynamic generation makes particularly difficult is where the application and its resources are split across separate hosts/domains. In this case, resources are typically hosted on a dedicated server that can be: a) Shared across multiple applications, thus improving the likelihood of browser cache hits. And... b) More easily fronted by a CDN (without also having to route all application traffic through a CDN ). Since a single skin definition can result in an arbitrary number of generated style sheets, it is not possible to host Trinidad skin/style sheets on a dedicated server - ie. there is currently no reliable way to pre-generate all possible variants of any given skin. This issue requests that we add a new skin pregeneration feature that would allow all style sheet variants for any skin to be generated prior to application deployment. This would facilitate the the split application/resources scenario described above. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2234) Pregeneration of skin style sheets
[ https://issues.apache.org/jira/browse/TRINIDAD-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234875#comment-13234875 ] Andy Schwartz commented on TRINIDAD-2234: - Okay, one last patch: https://issues.apache.org/jira/secure/attachment/12519287/trinidad-skin-pregen-take5.patch This tweaks the view id from: /-pregenerate-skins to -tr-pregenerate-skins. The -tr prefix further reduces the potential for name collisions and also makes it clear(er) that this is a Trinidad service. Pregeneration of skin style sheets -- Key: TRINIDAD-2234 URL: https://issues.apache.org/jira/browse/TRINIDAD-2234 Project: MyFaces Trinidad Issue Type: New Feature Components: Skinning Affects Versions: 2.0.1-core Reporter: Andy Schwartz Assignee: Andy Schwartz Priority: Minor Attachments: trinidad-skin-pregen-take2.patch, trinidad-skin-pregen-take3.patch, trinidad-skin-pregen-take4.patch, trinidad-skin-pregen-take5.patch, trinidad-skin-pregen.patch Trinidad skinning dynamically generates style sheets at runtime to meet context-specific (ie. platform/agent/locale/accessibility-specific) skinning requirements. While dynamic generation of style sheets is beneficial in that it allows fine tuning of which styles are delivered for particular contexts, it can complicate some use cases. One case that dynamic generation makes particularly difficult is where the application and its resources are split across separate hosts/domains. In this case, resources are typically hosted on a dedicated server that can be: a) Shared across multiple applications, thus improving the likelihood of browser cache hits. And... b) More easily fronted by a CDN (without also having to route all application traffic through a CDN ). Since a single skin definition can result in an arbitrary number of generated style sheets, it is not possible to host Trinidad skin/style sheets on a dedicated server - ie. there is currently no reliable way to pre-generate all possible variants of any given skin. This issue requests that we add a new skin pregeneration feature that would allow all style sheet variants for any skin to be generated prior to application deployment. This would facilitate the the split application/resources scenario described above. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3510) Application components classloader memory leak
[ https://issues.apache.org/jira/browse/MYFACES-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13235068#comment-13235068 ] Leonardo Uribe commented on MYFACES-3510: - I checked the code and it works as it was designed. There is a WeakHashMap in _ComponentAttributesMap: // Cache for component property descriptors private static MapClass?, MapString, _PropertyDescriptorHolder propertyDescriptorCache = new WeakHashMapClass?, MapString, _PropertyDescriptorHolder(); and _PropertyDescriptorHolder holds PropertyDescriptor and Method instances. It is not necessary to use WeakReference inside _PropertyDescriptorHolder, because the Classloader is already weakly reachable. I took an application using tomcat 7.0.23 and then try to start/stop multiple times. If there is a memory leak, an OutOfMemoryException can be seen. It never happened. What could happen is the classloader is not discarded by the gc immediately. But as soons as the jvm as for memory and the gc do its cleanup job, it will found the classloader is weakly reachable and can be discarded from memory. Unfortunately, the screenshot is not enough proof that a memory leak exist. We need to check if an OutOfMemoryException could be caused by this code. Anyway, use a WeakReference is only reasonable if you can gain something, but I don't think it apply in this case. Suggestions are welcome. Application components classloader memory leak -- Key: MYFACES-3510 URL: https://issues.apache.org/jira/browse/MYFACES-3510 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.6 Environment: WIndows Glassfish Embedded Reporter: Ruben Martin Pozo Attachments: screenshot-1.jpg We've seen an application classloader memory leak due to the new class javax.faces.component._PropertyDescriptorHolder class introduced in version 2.1.6 This class holds a reference to a Method of a component loaded by the application classloader. The memory leak shows up when the _PropertyDescriptorHolder is stored in the _ComponentAttributesMap class that is loaded by the system class loader. You should use a WeakReference instead of storing the direct reference to the Method -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3510) Application components classloader memory leak
[ https://issues.apache.org/jira/browse/MYFACES-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13235120#comment-13235120 ] Ruben Martin Pozo commented on MYFACES-3510: What do you mean when you say that the classloader is weakly reachable? JProfiler is only showing strong references. If you mean its weakly reachable because of the WeakHashMap that's not correct since WeakHashMap only uses weakreference for keys not for values as this is the case. I'm getting OOM because we're running out of permGem memory due to the application class loader leak Application components classloader memory leak -- Key: MYFACES-3510 URL: https://issues.apache.org/jira/browse/MYFACES-3510 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.6 Environment: WIndows Glassfish Embedded Reporter: Ruben Martin Pozo Attachments: screenshot-1.jpg We've seen an application classloader memory leak due to the new class javax.faces.component._PropertyDescriptorHolder class introduced in version 2.1.6 This class holds a reference to a Method of a component loaded by the application classloader. The memory leak shows up when the _PropertyDescriptorHolder is stored in the _ComponentAttributesMap class that is loaded by the system class loader. You should use a WeakReference instead of storing the direct reference to the Method -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3510) Application components classloader memory leak
[ https://issues.apache.org/jira/browse/MYFACES-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13235122#comment-13235122 ] Ruben Martin Pozo commented on MYFACES-3510: This is a fragment of the WeakHashMap documentation Implementation note: The value objects in a WeakHashMap are held by ordinary strong references. Thus care should be taken to ensure that value objects do not strongly refer to their own keys, either directly or indirectly, since that will prevent the keys from being discarded. Note that a value object may refer indirectly to its key via the WeakHashMap itself; that is, a value object may strongly refer to some other key object whose associated value object, in turn, strongly refers to the key of the first value object. One way to deal with this is to wrap values themselves within WeakReferences before inserting, as in: m.put(key, new WeakReference(value)), and then unwrapping upon each get. Application components classloader memory leak -- Key: MYFACES-3510 URL: https://issues.apache.org/jira/browse/MYFACES-3510 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.6 Environment: WIndows Glassfish Embedded Reporter: Ruben Martin Pozo Attachments: screenshot-1.jpg We've seen an application classloader memory leak due to the new class javax.faces.component._PropertyDescriptorHolder class introduced in version 2.1.6 This class holds a reference to a Method of a component loaded by the application classloader. The memory leak shows up when the _PropertyDescriptorHolder is stored in the _ComponentAttributesMap class that is loaded by the system class loader. You should use a WeakReference instead of storing the direct reference to the Method -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2228) java.lang.UnsupportedOperationException
[
https://issues.apache.org/jira/browse/TRINIDAD-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13235224#comment-13235224
]
Walter Mourão commented on TRINIDAD-2228:
-
Not good results so far:
myfaces+trinidad 2.0.0=ok
mojarra+trinidad 200=The Trinidad state change listener stops working during
the ajax
myfaces+trinidad 201=java.lang.UnsupportedOperationException
mojarra+trinidad 201+jetty=shows the component, but after the ajax it returns:
/start.xhtml @24,71 completeMethod=#{test.fillAutocomplete}: Property
'fillAutocomplete' not found on type com.wim.autocomplete.Test]
Weird...
java.lang.UnsupportedOperationException
---
Key: TRINIDAD-2228
URL: https://issues.apache.org/jira/browse/TRINIDAD-2228
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 2.0.1-core
Environment: Ubuntu, Java 1.6, Jetty or Tomcat 7
Reporter: Walter Mourão
Assignee: Scott O'Bryan
Fix For: 2.0.2-core
Attachments: autocomplete.zip, autocomplete1.zip
Same project, with Trinidad 2.0.0 works fine, with Trinidad 2.0.1,
java.lang.UnsupportedOperationException in pages containing composite
components.
Stack trace:
java.lang.UnsupportedOperationException
at
javax.faces.view.ViewDeclarationLanguage.retargetMethodExpressions(ViewDeclarationLanguage.java:75)
at
org.apache.myfaces.view.facelets.tag.composite.CompositeComponentResourceTagHandler.applyNextHandler(CompositeComponentResourceTagHandler.java:181)
at
org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58)
at
org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53)
at
javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58)
at
org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58)
at
org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53)
at
javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58)
at
org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53)
at
org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:57)
at
org.apache.myfaces.view.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:45)
at
org.apache.myfaces.view.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:151)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.buildView(FaceletViewDeclarationLanguage.java:435)
at
org.apache.myfaces.trinidadinternal.application.ViewDeclarationLanguageFactoryImpl$ChangeApplyingVDLWrapper.buildView(ViewDeclarationLanguageFactoryImpl.java:342)
at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:77)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3510) Application components classloader memory leak
[ https://issues.apache.org/jira/browse/MYFACES-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13235304#comment-13235304 ] Leonardo Uribe commented on MYFACES-3510: - What I mean with weakly reachable is since the map in propertyDescriptorCache is a WeakHashMap, once the keys are collected, the values are discarded and the Classloader can be discarded from memory too. So, strictly speaking there is no leak. What could happen is in one moment of the time the Classloader cannot be discarded since the weak keys needs to be discarded first. Could you see if there is a leak over org.apache.myfaces.view.facelets.tag.MetaRulesetImpl (used in facelets)?, specifically with: private volatile static WeakHashMapClassLoader, MapString, MetadataTarget metadata = new WeakHashMapClassLoader, MapString, MetadataTarget(); This is a similar case. If this is not a problem, maybe the leak is caused by cache Method instances. Application components classloader memory leak -- Key: MYFACES-3510 URL: https://issues.apache.org/jira/browse/MYFACES-3510 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.6 Environment: WIndows Glassfish Embedded Reporter: Ruben Martin Pozo Attachments: screenshot-1.jpg We've seen an application classloader memory leak due to the new class javax.faces.component._PropertyDescriptorHolder class introduced in version 2.1.6 This class holds a reference to a Method of a component loaded by the application classloader. The memory leak shows up when the _PropertyDescriptorHolder is stored in the _ComponentAttributesMap class that is loaded by the system class loader. You should use a WeakReference instead of storing the direct reference to the Method -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3510) Application components classloader memory leak
[ https://issues.apache.org/jira/browse/MYFACES-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13235308#comment-13235308 ] Leonardo Uribe commented on MYFACES-3510: - I have attached a patch with a possible solution. The idea is change propertyDescriptorCache, adding a soft reference. private static MapClass?, SoftReferenceMapString, _PropertyDescriptorHolder propertyDescriptorCache = new WeakHashMapClass?, SoftReferenceMapString, _PropertyDescriptorHolder(); In this way, we can avoid the strong reference through the static var, and since the garbage collector needs to clean all soft references before throw an OutOfMemoryError, we ensure that cache is cleaned up if memory is required. @Ruben: Could you please try if this patch can solve the problem? Application components classloader memory leak -- Key: MYFACES-3510 URL: https://issues.apache.org/jira/browse/MYFACES-3510 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.6 Environment: WIndows Glassfish Embedded Reporter: Ruben Martin Pozo Attachments: MYFACES-3510-1.patch, screenshot-1.jpg We've seen an application classloader memory leak due to the new class javax.faces.component._PropertyDescriptorHolder class introduced in version 2.1.6 This class holds a reference to a Method of a component loaded by the application classloader. The memory leak shows up when the _PropertyDescriptorHolder is stored in the _ComponentAttributesMap class that is loaded by the system class loader. You should use a WeakReference instead of storing the direct reference to the Method -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2095) Mojara and PWC4011: Unable to set request character encoding to UTF-8
[ https://issues.apache.org/jira/browse/TRINIDAD-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13233422#comment-13233422 ] Tomas Havelka commented on TRINIDAD-2095: - Could you, please, fix this issue? Thx Mojara and PWC4011: Unable to set request character encoding to UTF-8 - Key: TRINIDAD-2095 URL: https://issues.apache.org/jira/browse/TRINIDAD-2095 Project: MyFaces Trinidad Issue Type: Bug Components: Archetype Affects Versions: 1.2.14-core Reporter: Tomas Havelka The problem with annoying warning message with Mojarra and Glassfish still remains. Within each request TrinidadFilterImpl creates the ServletExternalContext multiple times which causes Mojarra to log this message PWC4011: Unable to set request character encoding to UTF-8 many many times (cca 4x per request). This causes the log file is getting large unreasonably. The problem is descibed in this thread http://www.mail-archive.com/dev@myfaces.apache.org/msg37786.html. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTSCRIPT-159) Add scala language support if possible
[ https://issues.apache.org/jira/browse/EXTSCRIPT-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13233428#comment-13233428 ] Werner Punz commented on EXTSCRIPT-159: --- Scala now working in a war environment, sorry EAR, but due to a scala design bug it is not possible for now to enable it there. Add scala language support if possible -- Key: EXTSCRIPT-159 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-159 Project: MyFaces Extensions Scripting Issue Type: New Feature Affects Versions: 1.0.3-SNAPSHOT Reporter: Werner Punz Assignee: Werner Punz Fix For: 1.0.3-FINAL since we are now through with the refactoring how about a first goody, we now should be able to add new languages rather simple, by providing a compiler plugin and adding an engine object for the reloading details (aka class detection, engine type identifier, file endings etc...) As testing case I will add Scala language support now to the core. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2221) Allow ancestor components to transform and filter ComponentChanges added by their descendants
[
https://issues.apache.org/jira/browse/TRINIDAD-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13233430#comment-13233430
]
Prakash Udupa commented on TRINIDAD-2221:
-
See also related TRINIDAD-2239.
Allow ancestor components to transform and filter ComponentChanges added by
their descendants
-
Key: TRINIDAD-2221
URL: https://issues.apache.org/jira/browse/TRINIDAD-2221
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.0-beta-2
Reporter: Blake Sullivan
Assignee: Blake Sullivan
Priority: Minor
Fix For: 2.0.0-beta-2
Attachments: jira2221Main.diff
Original Estimate: 24h
Remaining Estimate: 24h
Components currently directly add changes to the ChangeManager. This causes
issues with composition, where an ancestor may wish to modify the behavior of
its implementation children. The proposal is to add new protected and public
apis to UIXComponentBase:
/**
* Adds a change for a Component, or the Component's subtree, returning the
change actually added,
* or codenull/code, if no change was added. The proposed change may
be rejected by the
* component itself, one of its ancestors, or the ChangeManager
implementation.
* @param change The change to add for this component
* @return The ComponentChange actually added, or
* codenull/code if no change was added.
*/
public final ComponentChange addComponentChange(ComponentChange change)
{
return addComponentChange(this, change);
}
/**
* Called when adding a change to a Component, or the Component's subtree.
* The default implementation delegates the call to the parent, if
possible, otherwise
* it adds the change to the ChangeManager directly.
* Subclasses can override this method to among other things, filter or
transform the changes.
* @param component The component that the change is for
* @param change The change to add for this component
* @return The ComponentChange actually added, or
* codenull/code if no change was added.
*/
protected ComponentChange addComponentChange(UIComponent component,
ComponentChange change)
The also make the current addAttributeChange a convenience function:
/**
* Convenience function for
* codeaddComponentChange(new AttributeComponentChange(attributeName,
attributeValue));/code
* This function is not codefinal/code for backwards compatibility
reasons, however,
* existing subclassers whould override codeaddComponentChange/code
instead.
* @param attributeName
* @param attributeValue
* @see #addComponentChange(UIComponent, ComponentChange)
*/
protected void addAttributeChange(
String attributeName,
Object attributeValue)
{
addComponentChange(new AttributeComponentChange(attributeName,
attributeValue));
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2239) Improve the ancestor based change filtering mechanism by introducing a formal ComponentChangeFilter
[
https://issues.apache.org/jira/browse/TRINIDAD-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13233432#comment-13233432
]
Prakash Udupa commented on TRINIDAD-2239:
-
The noted revision above was not for this issue, the right checkin for this
issue is ASF revision #1302846
Improve the ancestor based change filtering mechanism by introducing a formal
ComponentChangeFilter
---
Key: TRINIDAD-2239
URL: https://issues.apache.org/jira/browse/TRINIDAD-2239
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Components
Affects Versions: 2.0.2-core
Reporter: Prakash Udupa
Assignee: Scott O'Bryan
Fix For: 2.0.2-core
Attachments: Change_Filter_TRINIDAD-2239_For_Trunk.patch
Original Estimate: 24h
Remaining Estimate: 24h
TRINIDAD-2221 provided mechanism for ancestors to decide if ComponentChange
targeting one of its descendants should be added to ChangeManager.
This one is asking for further improvement to this mechanism, by formalizing
the contract more. Proposal is to add the following API:
1. An abstract class
'org.apache.myfaces.trinidad.change.ComponentChangeFilter' that clients /
listeners can implement specializations to accept / reject certain changes on
certain components, and then add to the components.
public abstract class ComponentChangeFilter
{
public abstract Result accept(ComponentChange componentChange, UIComponent
changeTargetComponent);
public enum Result
{
ACCEPT,
REJECT
}
}
2. An abstract implementation
'org.apache.myfaces.trinidad.change.ComponentReferencingComponentChangeFilter'
to solve usecases where such a filter needs to hold component reference.
One such usecase is where ComponentChanges belonging to certain component
subtree is rejected, by keeping a reference to the subtree root component. We
leverage on 'org.apache.myfaces.trinidad.util.ComponentReference' for this
implementation.
3. The following methods on UIXComponentBase to be able to attach / detach
ComponentChangeFilters to the components:
public final void addComponentChangeFilter(ComponentChangeFilter
componentChangeFilter)
public final void removeComponentChangeFilter(ComponentChangeFilter
componentChangeFilter)
Implementation:
In implementation of UIXComponentBase.addComponentChange(UIComponent
component, ComponentChange change), we will not add a ComponentChange if any
of the ComponentChangeFilters that is attached to the target component itself
or any of its ancestors rejects the ComponentChange.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2095) Mojara and PWC4011: Unable to set request character encoding to UTF-8
[ https://issues.apache.org/jira/browse/TRINIDAD-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13233478#comment-13233478 ] Scott O'Bryan commented on TRINIDAD-2095: - Thomas, I don't see this happening in the general case and I don't think that the issue is as you say. I find it more likely that something in the filter chain is causing a getWriter() to be executed while some other piece of software (toplink?) tries to set the character encoding without checking to see if the response has been committed. Bottom line is, the character encoding cannot be set on a committed response as per J2EE. Before we can even HOPE to make progress on this, we'll need a test case and maybe we can either defer the call to getWriter() in the filterchain or suggest that you file a bug against the framework that is trying to set this on a committed response. Mojara and PWC4011: Unable to set request character encoding to UTF-8 - Key: TRINIDAD-2095 URL: https://issues.apache.org/jira/browse/TRINIDAD-2095 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.14-core Reporter: Tomas Havelka Priority: Minor The problem with annoying warning message with Mojarra and Glassfish still remains. Within each request TrinidadFilterImpl creates the ServletExternalContext multiple times which causes Mojarra to log this message PWC4011: Unable to set request character encoding to UTF-8 many many times (cca 4x per request). This causes the log file is getting large unreasonably. The problem is descibed in this thread http://www.mail-archive.com/dev@myfaces.apache.org/msg37786.html. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2095) Mojara and PWC4011: Unable to set request character encoding to UTF-8
[ https://issues.apache.org/jira/browse/TRINIDAD-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13233484#comment-13233484 ] Scott O'Bryan commented on TRINIDAD-2095: - Also, does this happen with JSF2.0? Although technically 1.2.14 is still active, this is community software and the majority of my team is working on Trinidad 2.0. Getting a fix into 1.2.x is totally possible, but we may need some help from members in the community who are still interested in JSF 1.2. I'll be happy to commit the patches. Mojara and PWC4011: Unable to set request character encoding to UTF-8 - Key: TRINIDAD-2095 URL: https://issues.apache.org/jira/browse/TRINIDAD-2095 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.14-core Reporter: Tomas Havelka Priority: Minor The problem with annoying warning message with Mojarra and Glassfish still remains. Within each request TrinidadFilterImpl creates the ServletExternalContext multiple times which causes Mojarra to log this message PWC4011: Unable to set request character encoding to UTF-8 many many times (cca 4x per request). This causes the log file is getting large unreasonably. The problem is descibed in this thread http://www.mail-archive.com/dev@myfaces.apache.org/msg37786.html. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2228) java.lang.UnsupportedOperationException
[
https://issues.apache.org/jira/browse/TRINIDAD-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13233520#comment-13233520
]
Prakash Udupa commented on TRINIDAD-2228:
-
To add to Scott's comments, you might want to review if you need the 'value' to
be required, and if yes, then why is it that it is resolving to null in
development mode.
Looking at the code for 2.1 could give you some idea on what could be going
wrong with your composite component or the client code:
http://grepcode.com/file/repo1.maven.org/maven2/com.sun.faces/jsf-impl/2.1.4/com/sun/faces/facelets/tag/composite/InterfaceHandler.java#116
See how this validation was not done in 2.0...
http://grepcode.com/file/repo1.maven.org/maven2/com.sun.faces/jsf-impl/2.0.0/com/sun/faces/facelets/tag/composite/InterfaceHandler.java#98
the validation is called only when in 'Development' mode, so I think you should
not get this error if you are in 'production' mode.
if (FaceletViewHandlingStrategy.isBuildingMetadata(context)) {
imbueComponentWithMetadata(ctx, parent);
this.nextHandler.apply(ctx, parent);
} else {
if (ProjectStage.Development ==
context.getApplication().getProjectStage()) {
validateComponent(context, parent);
}
java.lang.UnsupportedOperationException
---
Key: TRINIDAD-2228
URL: https://issues.apache.org/jira/browse/TRINIDAD-2228
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 2.0.1-core
Environment: Ubuntu, Java 1.6, Jetty or Tomcat 7
Reporter: Walter Mourão
Assignee: Scott O'Bryan
Fix For: 2.0.2-core
Attachments: autocomplete.zip
Same project, with Trinidad 2.0.0 works fine, with Trinidad 2.0.1,
java.lang.UnsupportedOperationException in pages containing composite
components.
Stack trace:
java.lang.UnsupportedOperationException
at
javax.faces.view.ViewDeclarationLanguage.retargetMethodExpressions(ViewDeclarationLanguage.java:75)
at
org.apache.myfaces.view.facelets.tag.composite.CompositeComponentResourceTagHandler.applyNextHandler(CompositeComponentResourceTagHandler.java:181)
at
org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58)
at
org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53)
at
javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58)
at
org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58)
at
org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53)
at
javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58)
at
org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53)
at
org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:57)
at
org.apache.myfaces.view.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:45)
at
org.apache.myfaces.view.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:151)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.buildView(FaceletViewDeclarationLanguage.java:435)
at
org.apache.myfaces.trinidadinternal.application.ViewDeclarationLanguageFactoryImpl$ChangeApplyingVDLWrapper.buildView(ViewDeclarationLanguageFactoryImpl.java:342)
at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:77)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241
[jira] [Commented] (TRINIDAD-2239) Improve the ancestor based change filtering mechanism by introducing a formal ComponentChangeFilter
[
https://issues.apache.org/jira/browse/TRINIDAD-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13233523#comment-13233523
]
Scott O'Bryan commented on TRINIDAD-2239:
-
I'll add the Trinidad number to these.
Improve the ancestor based change filtering mechanism by introducing a formal
ComponentChangeFilter
---
Key: TRINIDAD-2239
URL: https://issues.apache.org/jira/browse/TRINIDAD-2239
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Components
Affects Versions: 2.0.2-core
Reporter: Prakash Udupa
Assignee: Scott O'Bryan
Fix For: 2.0.2-core
Attachments: Change_Filter_TRINIDAD-2239_For_Trunk.patch
Original Estimate: 24h
Remaining Estimate: 24h
TRINIDAD-2221 provided mechanism for ancestors to decide if ComponentChange
targeting one of its descendants should be added to ChangeManager.
This one is asking for further improvement to this mechanism, by formalizing
the contract more. Proposal is to add the following API:
1. An abstract class
'org.apache.myfaces.trinidad.change.ComponentChangeFilter' that clients /
listeners can implement specializations to accept / reject certain changes on
certain components, and then add to the components.
public abstract class ComponentChangeFilter
{
public abstract Result accept(ComponentChange componentChange, UIComponent
changeTargetComponent);
public enum Result
{
ACCEPT,
REJECT
}
}
2. An abstract implementation
'org.apache.myfaces.trinidad.change.ComponentReferencingComponentChangeFilter'
to solve usecases where such a filter needs to hold component reference.
One such usecase is where ComponentChanges belonging to certain component
subtree is rejected, by keeping a reference to the subtree root component. We
leverage on 'org.apache.myfaces.trinidad.util.ComponentReference' for this
implementation.
3. The following methods on UIXComponentBase to be able to attach / detach
ComponentChangeFilters to the components:
public final void addComponentChangeFilter(ComponentChangeFilter
componentChangeFilter)
public final void removeComponentChangeFilter(ComponentChangeFilter
componentChangeFilter)
Implementation:
In implementation of UIXComponentBase.addComponentChange(UIComponent
component, ComponentChange change), we will not add a ComponentChange if any
of the ComponentChangeFilters that is attached to the target component itself
or any of its ancestors rejects the ComponentChange.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2238) dialog popup via commandButton's action property can only be done once in same page in Trinidad 2.0.1
[
https://issues.apache.org/jira/browse/TRINIDAD-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13233530#comment-13233530
]
Scott O'Bryan commented on TRINIDAD-2238:
-
Hmm. I haven't seen this before. So to clairify your environment, you're
using Mojarra 2.1.4? Any chance we can get you to upload a test case?
dialog popup via commandButton's action property can only be done once in
same page in Trinidad 2.0.1
-
Key: TRINIDAD-2238
URL: https://issues.apache.org/jira/browse/TRINIDAD-2238
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.1-core
Environment: windows,eclipse,firefox,Trinidad 2.0.1,javax-faces-2.1.4
Reporter: mojiayi
Priority: Critical
I use this commandButton to popup a dialog,it's work fine for the first time.
tr:commandButton text=print action=dialog:table useWindow=true
actionListener=#{tableBean.printTableListener}
width=900
height=500 partialSubmit=true/
Once I close this dialog,there is a js error shown in console of parent page.
jsf.ajax.request: source not set
[Break on this error] throw new Error(jsf.ajax.request: source not set);
this js error is occured in line 1700 of file jsf.js in jsf jar.
And if I try to click this button to open this dialog again,dialog will not
popup,nothing happens.Unless a ppr or reopen a page,dialog popup normally.
I think this is a bug of the new version of trinidad,because no such error in
trinidad 1.2.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2228) java.lang.UnsupportedOperationException
[
https://issues.apache.org/jira/browse/TRINIDAD-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13233955#comment-13233955
]
Walter Mourão commented on TRINIDAD-2228:
-
Just tested with 'value' as not required and with 'Production' mode and I've
got the same result...
Using Mojarra I had a different issue during the ajax request: /start.xhtml
@24,71 completeMethod=#{test.fillAutocomplete}: Property 'fillAutocomplete'
not found on type com.wim.autocomplete.Test. The Mojarra error looks like an
EL issue and I will investigate later, but with Mojarra I didn't get the
'UnsupportedOperationException' opening the page.
java.lang.UnsupportedOperationException
---
Key: TRINIDAD-2228
URL: https://issues.apache.org/jira/browse/TRINIDAD-2228
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 2.0.1-core
Environment: Ubuntu, Java 1.6, Jetty or Tomcat 7
Reporter: Walter Mourão
Assignee: Scott O'Bryan
Fix For: 2.0.2-core
Attachments: autocomplete.zip
Same project, with Trinidad 2.0.0 works fine, with Trinidad 2.0.1,
java.lang.UnsupportedOperationException in pages containing composite
components.
Stack trace:
java.lang.UnsupportedOperationException
at
javax.faces.view.ViewDeclarationLanguage.retargetMethodExpressions(ViewDeclarationLanguage.java:75)
at
org.apache.myfaces.view.facelets.tag.composite.CompositeComponentResourceTagHandler.applyNextHandler(CompositeComponentResourceTagHandler.java:181)
at
org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58)
at
org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53)
at
javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58)
at
org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58)
at
org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53)
at
javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58)
at
org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53)
at
org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:57)
at
org.apache.myfaces.view.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:45)
at
org.apache.myfaces.view.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:151)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.buildView(FaceletViewDeclarationLanguage.java:435)
at
org.apache.myfaces.trinidadinternal.application.ViewDeclarationLanguageFactoryImpl$ChangeApplyingVDLWrapper.buildView(ViewDeclarationLanguageFactoryImpl.java:342)
at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:77)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ORCHESTRA-60) Orchestra should implement RequestParameterResponseWrapper.encodeRedirectURL()
[ https://issues.apache.org/jira/browse/ORCHESTRA-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234023#comment-13234023 ] Leonardo Uribe commented on ORCHESTRA-60: - I have checked this one and there is a problem with override RequestParameterResponseWrapper.encodeRedirectURL() . In few words, there is no warrant the same conversationContext should be used for a redirect. This is the javadoc: ... Encodes the specified URL for use in the sendRedirect method or, if encoding is not needed, returns the URL unchanged. The implementation of this method includes the logic to determine whether the session ID needs to be encoded in the URL. Because the rules for making this determination can differ from those used to decide whether to encode a normal link, this method is separated from the encodeURL method. All URLs sent to the HttpServletResponse.sendRedirect method should be run through this method. Otherwise, URL rewriting cannot be used with browsers which do not support cookies. ... What happen if the redirect url is not for the same app? conversationContext query param should not be added. Note encodeURL is used always for URL that are served for the webapp. In PrettyFaces case, since it is a layer to generate pretty URLs, in my opinion it sounds better to use encodeURL. Suggestions are welcome. Orchestra should implement RequestParameterResponseWrapper.encodeRedirectURL() -- Key: ORCHESTRA-60 URL: https://issues.apache.org/jira/browse/ORCHESTRA-60 Project: MyFaces Orchestra Issue Type: Bug Components: Conversation Affects Versions: 1.5 Reporter: Christian Kaltepoth Orchestra currently doesn't implement RequestParameterResponseWrapper.encodeRedirectURL(). The API docs of HttpServletResponse clearly state that encodeRedirectURL() should be called before sending a redirect using sendRedirect(). Therefore the conversationContext parameter is currently lost in these situations. Corresponding PrettyFaces issue: http://code.google.com/p/prettyfaces/issues/detail?id=125 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ORCHESTRA-59) Orchestra does not work with JSF RI
[ https://issues.apache.org/jira/browse/ORCHESTRA-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234025#comment-13234025 ] Leonardo Uribe commented on ORCHESTRA-59: - In this case, it sounds reasonable to override ExternalContext.encodeRedirectURL() and add the conversationContext query param. It is different from ORCHESTRA-60, because the encoded URL is supposed to be used in the JSF application. Anyway, I think a check to ensure the link is local is necessary in this place. Suggestions are welcome. Orchestra does not work with JSF RI --- Key: ORCHESTRA-59 URL: https://issues.apache.org/jira/browse/ORCHESTRA-59 Project: MyFaces Orchestra Issue Type: Bug Components: Conversation Affects Versions: 1.4 Environment: - Glassfish 3.3.1 - JSF RI 2.1.3 (FCS b02) - MyFaces Orchestra 1.4 (JSF 2) Reporter: Tomas Havelka ConversationContext request parameter is missing (it's not appended) in the url. If it's passed manually in the request url, it works. It's because the Mojarra 2.1.3 does not call the HttpServletResponse.encodeURL() in the ExternalContext.encodeRedirectURL() so the conversationContext is not append to the url. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTSCRIPT-158) Dependency detection failes in certain scenarii
[ https://issues.apache.org/jira/browse/EXTSCRIPT-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232538#comment-13232538 ] Werner Punz commented on EXTSCRIPT-158: --- Seems to be a groovy only problem, still under investigation, I assume the dependency scan on the groovy classes runs into proxies or something similar Dependency detection failes in certain scenarii --- Key: EXTSCRIPT-158 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-158 Project: MyFaces Extensions Scripting Issue Type: Bug Components: Core Affects Versions: 1.0.3-SNAPSHOT Reporter: Werner Punz Assignee: Werner Punz in a mixed faces-config, annotation blogging example scenario the dependency detection fails on the latest codebase. This needs to be fixed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTSCRIPT-158) Dependency detection fails in certain scenarii
[ https://issues.apache.org/jira/browse/EXTSCRIPT-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232586#comment-13232586 ] Werner Punz commented on EXTSCRIPT-158: --- Ok the groovy blog example has the same possible dynamic classes as the java example and hence is not getting the correct dependencies. Dependency detection fails in certain scenarii -- Key: EXTSCRIPT-158 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-158 Project: MyFaces Extensions Scripting Issue Type: Bug Components: Core Affects Versions: 1.0.3-SNAPSHOT Reporter: Werner Punz Assignee: Werner Punz In a mixed faces-config, annotation blogging example scenario the dependency detection fails on the latest codebase. This needs to be fixed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2228) java.lang.UnsupportedOperationException
[ https://issues.apache.org/jira/browse/TRINIDAD-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232859#comment-13232859 ] Prakash Udupa commented on TRINIDAD-2228: - It does not look like ChangeManager / TRINIDAD-2121 / TRINIDAD-2073 can be connected here, and there is no contract implied due to using this wrapper. From looking at the code and the stack trace in both cases above, all that the ChangeApplyingVDLWrapper is doing is to delegate buildView() to the underlying VDL f.w.i.w., the composite component definition in autocomplete.xhtml has the value attribute marked as required... cc:interface cc:attribute name=value required=true/ Which I think is triggering the check in Mojarra case to see if 'value' is supplied, and is failing with the above exception because it is not supplied. java.lang.UnsupportedOperationException --- Key: TRINIDAD-2228 URL: https://issues.apache.org/jira/browse/TRINIDAD-2228 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.1-core Environment: Ubuntu, Java 1.6, Jetty or Tomcat 7 Reporter: Walter Mourão Assignee: Scott O'Bryan Priority: Blocker Fix For: 2.0.2-core Attachments: autocomplete.zip Same project, with Trinidad 2.0.0 works fine, with Trinidad 2.0.1, java.lang.UnsupportedOperationException in pages containing composite components. Stack trace: java.lang.UnsupportedOperationException at javax.faces.view.ViewDeclarationLanguage.retargetMethodExpressions(ViewDeclarationLanguage.java:75) at org.apache.myfaces.view.facelets.tag.composite.CompositeComponentResourceTagHandler.applyNextHandler(CompositeComponentResourceTagHandler.java:181) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:291) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53) at org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:57) at org.apache.myfaces.view.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:45) at org.apache.myfaces.view.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:151) at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.buildView(FaceletViewDeclarationLanguage.java:435) at org.apache.myfaces.trinidadinternal.application.ViewDeclarationLanguageFactoryImpl$ChangeApplyingVDLWrapper.buildView(ViewDeclarationLanguageFactoryImpl.java:342) at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:77) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3201) Publish exception in lifecycle methods (process*) instead of re-thrown
[
https://issues.apache.org/jira/browse/MYFACES-3201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232866#comment-13232866
]
Martin Kočí commented on MYFACES-3201:
--
Proposition:
* because we need to queue component and other suitable infos in places where
exception occured : try - catch every signitificant method on UIComponent and
publish exception context
* rethrow the exception to break current phase
* ignore the second attempt to queue the same exception
in pseudo code:
UIComponent.processSomething:
try {
} catch (RuntimeException e) {
context.publishExceptionAndComponentAndOtherInfos
throw e; // will break this phase and causes context.renderResponse()
}
and in LifecycleImpl:
try {
lifecycle.process
} catch (Exception e) // this one is the same as in previous UIComponent code
{
context.publishExceptionButIgnoreIfAlreadyQueued
}
the re-throw of the exception is needed because current phase must be stopped.
No UIComponent methods have a return value to indicate that processing has
failed - we must use an Exception to provide that.
Publish exception in lifecycle methods (process*) instead of re-thrown
--
Key: MYFACES-3201
URL: https://issues.apache.org/jira/browse/MYFACES-3201
Project: MyFaces Core
Issue Type: Sub-task
Components: General
Reporter: Martin Kočí
Requirement: user should see not just a cryptic stack trace, but also the
component that triggered the problem
Problem in current code is that first exception breaks current phase and
exception in queued without component info.
I think that every lifecycle method (processDecodes, processValidator etc.)
should try catch every exception and publish it for later processing with
exception handler.
Spec does not says it directly but we can find:
The exception must not be re-thrown. This enables tree traversal to continue
for this lifecycle phase, as in all the other lifecycle phases from
UIInput.updateModel
ExceptionHandler is the central point for handling unexpected Exceptions
that are thrown during the Faces lifecycle from ExceptionHandler javadoc
process* method can silently do nothing : UIInput.updateModel does it
already.
Publishing event allows handle multiple problem at once: consider buggy
validators/converters - create more than one exception in queue and coder
can see them at once.
The main parameter of ExceptionQueuedContext is UIComponent and the best
place where component is always known is component itself.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTSCRIPT-156) dynamic annotations broken
[ https://issues.apache.org/jira/browse/EXTSCRIPT-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13231092#comment-13231092 ] Werner Punz commented on EXTSCRIPT-156: --- ok for managed beans, renderers etc... they work again, for validators it still is broken dynamic annotations broken -- Key: EXTSCRIPT-156 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-156 Project: MyFaces Extensions Scripting Issue Type: Bug Affects Versions: 1.0.3-SNAPSHOT Reporter: Werner Punz Assignee: Werner Punz The dynamic annotations do not seem to work for now, this needs to be investigated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-1769) datepicker selects wrong day if ENABLE_LIGHTWEIGHT_DIALOGS is true
[
https://issues.apache.org/jira/browse/TRINIDAD-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13230004#comment-13230004
]
Reshmi Choudhury commented on TRINIDAD-1769:
Hi Mathias,
Currently I’m using Trinidad JARs of version1.0.10 and I see the
date-picker-popup of the inputDate-component sets the wrong day into the
input-element only when lightweight dialogs flag is on.
I have made the below changes in the function _getDayLightSavOffset(a0) of
DateField.js inside META-INF\adf\jsLibs as suggested in
http://eldoradosoftware.blogspot.in/2010/11/trinidad-date-picker-issue-with.html
and now I do not see the problem of setting wrong date into the
input-element whether lightweight dialogs flag is on or not.
function _getDayLightSavOffset(a0)
{
var a1=new Date();
var a2=new Date(a0);
var a3=a2.getTimezoneOffset()-a1.getTimezoneOffset();
return(0);
}
Could you please provide a fix in the current version or in the latest released
version for the reported issue.
Thanks in advance.
datepicker selects wrong day if ENABLE_LIGHTWEIGHT_DIALOGS is true
--
Key: TRINIDAD-1769
URL: https://issues.apache.org/jira/browse/TRINIDAD-1769
Project: MyFaces Trinidad
Issue Type: Bug
Environment: Trinidad 1.2.13 / MyFaces 1.2.X / Tomcat
Reporter: elmar kretzer
The date-picker-popup of the inputDate-component
sets the wrong day into the input-element.
E.g.: Select October and click 26. Then
25.10.2007 is set into the input-element.
This error occurs with the following months:
- April
- May
- June
- July
- August
- September
- October
It is related to Ticket https://issues.apache.org/jira/browse/TRINIDAD-790
The provided fix in the ticket does not work if
context-param
param-nameorg.apache.myfaces.trinidad.ENABLE_LIGHTWEIGHT_DIALOGS/param-name
param-valuetrue/param-value
/context-param
and your timezone has a DST offset.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTSCRIPT-155) Some artifacts are not yet reloading
[ https://issues.apache.org/jira/browse/EXTSCRIPT-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13230063#comment-13230063 ] Werner Punz commented on EXTSCRIPT-155: --- Seems like extval needs some specific hook here, because it proxies the renderers and i need to replace my own renderer instead of extvals proxy Some artifacts are not yet reloading Key: EXTSCRIPT-155 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-155 Project: MyFaces Extensions Scripting Issue Type: Bug Affects Versions: 1.0.3-SNAPSHOT Reporter: Werner Punz Assignee: Werner Punz While managed beans and phase listeners reload fine, some artifacts are not yet reloading. Namely renderers and probably others. This needs to be investigated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TOMAHAWK-1599) HtmlCalendarRenderer Throws ClassCastException
[
https://issues.apache.org/jira/browse/TOMAHAWK-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13230084#comment-13230084
]
Klaus Schuster commented on TOMAHAWK-1599:
--
Problem is not fixed in 1.1.11 ! Line 169
HtmlCalendarRenderer Throws ClassCastException
--
Key: TOMAHAWK-1599
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1599
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Calendar
Affects Versions: 1.1.10
Environment: Windows 7 64-bit, JDK 1.6.0_24 64-Bit, Tomcat 6.0.32,
Tomahawk20-1.1.10, JSF 2.1.2
Reporter: Jack Frosch
Assignee: Leonardo Uribe
Fix For: 1.1.11
When migrating from JSF 1.2 to 2.1.2, we moved from Tomahawk12-1.1.8 to
Tomahawk20-1.1.10. Line 200 in
org.apache.myfaces.custom.calendar.HtmlCalendarRenderer is now throwing a
ClassCastException. Here's the line and the line after it:
value = (Date) inputCalendar.getValue();
textValue = converter.getAsString(facesContext, inputCalendar, value);
The problem is, we've been storing a non-Date value in the HtmlInputCalendar
using a custom converter. In 1.1.8, this was no issue because
HtmlCalendarRenderer extracted the value as a Date using our custom converter
that implemented a DateConverter, as Line 127-130 shows from the 1.1.8
HtmlCalendarRenderer:
if (converter instanceof DateConverter)
{
value = ((DateConverter) converter).getAsDate(facesContext, component);
}
Why we've been storing the value as a non-Date type is a long story, but we
are. For legacy reasons, project may want to store a Date in many types other
than java.util.Date. A Long value comes to mind. As the contract for the
value property of UIInput only requires an Object type, this should be
allowed. The cast to a Date type seems to unnecessarily impose a constraint
on what projects use for their projects.
Interestingly, the very next line (Line 201 in 1.1.10) passed the Date value
to the getAsString method, which only requires a java.lang.Object be passed
for the value. The cast is a wasted operation anyway.
Both lines, 200 and 201 could be replaced with this line:
textValue = converter.getAsString(facesContext, inputCalendar,
inputCalendar.getValue());
This would eliminate the ClassCastException and allow projects the greatest
flexibility in how to store the calendar input.
Because the cast is not needed when passing the value to the converter, and
doing the cast will cause a ClassCastException when a non-Date is stored in
the UIInput, I'm logging this as a bug. It definitely breaks our app.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TOMAHAWK-1613) HtmlCalendarRenderer Throws ClassCastException - not fixed
[
https://issues.apache.org/jira/browse/TOMAHAWK-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13230609#comment-13230609
]
Leonardo Uribe commented on TOMAHAWK-1613:
--
Some time ago I studied in deep the problem. Really the problem to deal with
different date types was solved in TOMAHAWK-1508. I'll take some extracts from
that issue to explain it to you:
... I reviewed both components and the problem for use Converter interface
reside in its design vs t:inputCalendar and t:inputDate requeriments. It has
two problems:
- It assume submittedValue is always a String, but for t:inputDate that is not
true. For this case as suggested, we need a property to give the chance to
convert the java.util.Date instance used by the component to other type and
viceversa.
- t:inputCalendar and t:inputDate requires a base date type to manipulate. In
both cases is java.util.Date, but the boundaries between the base date type and
the business type are not clear. For example, in jdk 1.6 java.sql.Date that
extends from java.util.Date override some methods and makes t:inputCalendar and
t:inputDate fail.
In few words, t:inputDate and t:inputCalendar cannot know all different date
types and manipulate them correctly. But we needed some flexibility on the
model to use different date types (plain String, Calendar or use joda library
for date/time).
Unfortunately the Converter interface is not good enough, because it does not
isolate correctly the value in the model and the one used by
t:inputDate/t:inputCalendar to render itself. There are some corner cases
that make it fail.
The right way to do it is introduce a proper converter interface to deal with
the conversion between the value stored in the bean and the value used by
t:inputCalendar / t:inputDate. That is
org.apache.myfaces.custom.calendar.DateBusinessConverter
... Provide a bridge between the java.util.Date instance used by a component
that receive date/time values and
the business value used to represent the value. ...
So, instead use a custom converter, try adding this class:
package myproject.myconverter;
public class CalendarDateBusinessConverter implements DateBusinessConverter
{
public Object getBusinessValue(FacesContext context,
UIComponent component,
java.util.Date value)
{
// ... convert from java.util.Date to Calendar
return calendarValue;
}
public java.util.Date getDateValue(FacesContext context,
UIComponent component,
Object value)
{
// ... convert from Calendar to java.util.Date
return dateValueToUseByDateComponent;
}
}
And register the class
t:inputCalendar
dateBusinessConverter=myproject.myconverter.CalendarDateBusinessConverter
It also receive EL expressions. Anyway, I'll remove the cast for the next
version.
HtmlCalendarRenderer Throws ClassCastException - not fixed
--
Key: TOMAHAWK-1613
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1613
Project: MyFaces Tomahawk
Issue Type: Bug
Affects Versions: 1.1.11
Reporter: Klaus Schuster
The problem mentioned TOMAHAWK-1599 is not fixed.
I could locally fix the problem with changing line 169 in File:
org.apache.myfaces.custom.calendar.HtmlCalendarRenderer.java
from:
value = (Date) inputCalendar.getValue();
to:
if(converter instanceof DateConverter) {
value = ((DateConverter) converter).getAsDate(facesContext,
inputCalendar);
} else {
value = (Date) inputCalendar.getValue();
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3191) Handing exception (in exception handler) from render response phase with forward/redirect is inconsistent
[
https://issues.apache.org/jira/browse/MYFACES-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13229187#comment-13229187
]
Martin Kočí commented on MYFACES-3191:
--
from spec 2.1:
ViewDeclarationLanguage.renderView() : All implementations must: Call
endDocument() on the ResponseWriter.
Order of invocations in render_response Lifecycle.render:
0) before phase listeners
1) ViewDeclarationLanguage.renderView() (calls responseWriter.endDocument())
2) after phase listeners
3) facesContext.getExceptionHandler().handle()
spec mandates endDocument() in 1) but that is semantically incorrect: AJAX
response = XML and it's procedural representation on server is
Lifecycle.render, not ViewDeclarationLanguage.renderView. With point
4) call responseWriter.endDocument() as last statement in Lifecycle.render
can redirect work.
Handing exception (in exception handler) from render response phase with
forward/redirect is inconsistent
-
Key: MYFACES-3191
URL: https://issues.apache.org/jira/browse/MYFACES-3191
Project: MyFaces Core
Issue Type: Sub-task
Components: General
Affects Versions: 2.1.2-SNAPSHOT
Environment: myfaces trunk
Reporter: Martin Kočí
View.xhtml snippet:
h:commandButton value=Submit
f:setPropertyActionListener value=#{true}
target=#{bean.rendered} /
f:ajax render=outputText /
/h:commandButton
h:outputText rendered=#{bean.rendered} id=outputText
value=#{bean.value} /
Bean.java snippet:
public Object getValue() {
throw new NullPointerException();
}
Custom exception handler code:
if (PhaseId.RENDER_RESPONSE.equals(currentPhaseId)) {
try {
nav.handleNavigation(facesContext,
null, /ErrorPage.xhtml?faces-redirect=true);
} finally {
i.remove();
}
}
Modify view and exception handler to achieve following combinations (HTML
request = comment out f:ajax, forward = remove ?faces-redirect=true)
1) HTML request + forward: nothing in log, and malformed output is produced
(no closing tags for /body etc.)
2) HTML request + redirect: OK , redirect to ErrorPage.xhtml is done
3) AJAX request + forward: exception in log, bud no forward to ErrorPage
performed
4) AJAX request + redirect: exception in log, malformed XML produced (?xml
and partial-response 2x in output) , no redirect performed
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3191) Handing exception (in exception handler) from render response phase with forward/redirect is inconsistent
[
https://issues.apache.org/jira/browse/MYFACES-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13229288#comment-13229288
]
Martin Kočí commented on MYFACES-3191:
--
forward vs. redirect
The nature of forward does not allow to perform it in render response phase:
1) view.xhtml is rendered (lifecycle.render)
2) an exception occurs
3) exception handler forwards to ErrorPage.xhtml
4) ErrorPage.xhtml is rendered
step 1) can produce some output (html) elements and send it to client (depends
on size of server buffer). With this combination it is obtainable combination
of both views in client: output from view.xhtml and from ErrorPage.xhtml
The goal is:
1) provide reliable redirect from render response phase (works ok for HTML
request, does not work for ajax)
2) an attempt to forward in render response phase log as error (and ignore it?)
Handing exception (in exception handler) from render response phase with
forward/redirect is inconsistent
-
Key: MYFACES-3191
URL: https://issues.apache.org/jira/browse/MYFACES-3191
Project: MyFaces Core
Issue Type: Sub-task
Components: General
Affects Versions: 2.1.2-SNAPSHOT
Environment: myfaces trunk
Reporter: Martin Kočí
View.xhtml snippet:
h:commandButton value=Submit
f:setPropertyActionListener value=#{true}
target=#{bean.rendered} /
f:ajax render=outputText /
/h:commandButton
h:outputText rendered=#{bean.rendered} id=outputText
value=#{bean.value} /
Bean.java snippet:
public Object getValue() {
throw new NullPointerException();
}
Custom exception handler code:
if (PhaseId.RENDER_RESPONSE.equals(currentPhaseId)) {
try {
nav.handleNavigation(facesContext,
null, /ErrorPage.xhtml?faces-redirect=true);
} finally {
i.remove();
}
}
Modify view and exception handler to achieve following combinations (HTML
request = comment out f:ajax, forward = remove ?faces-redirect=true)
1) HTML request + forward: nothing in log, and malformed output is produced
(no closing tags for /body etc.)
2) HTML request + redirect: OK , redirect to ErrorPage.xhtml is done
3) AJAX request + forward: exception in log, bud no forward to ErrorPage
performed
4) AJAX request + redirect: exception in log, malformed XML produced (?xml
and partial-response 2x in output) , no redirect performed
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
